CA Unified Infrastructure Management Probes

1. CA Unified Infrastructure Management Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Alphabetical List of Probe IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Admin Console Probe GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 How To Articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Configuring Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Set Up Automated Usage Metering and Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3 Configure a Robot for Marketplace Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.4 Set Up adogtw Network Transaction Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.5 The Time Over Threshold Event Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.6 The Time To Threshold Event Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 ad_response (Active Directory Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 ad_server (Active Directory Server Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.3 adevl (Active Directory Events Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.4 adogtw (ADO Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5 aggregate_alarm Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.6 apache (Apache HTTP Server Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.7 apmgtw (CA APM Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.8 audit Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.9 automated_deployment_engine (Automated Deployment Engine) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.10 aws (Amazon Web Services Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.11 azure (Microsoft Azure Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.12 baseline_engine Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.13 billing Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.14 capman_da Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.15 casdgtw (CA ServiceDesk Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.16 cassandra_monitor (Cassandra Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.17 ccm_monitor (Cisco CallManager Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.18 cdm (CPU, Disk, Memory Performance Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.19 celerra (EMC Celerra Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.20 cisco_monitor (Cisco SNMP Device Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.21 cisco_qos (Cisco Class-Based QoS Statistics Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.22 cisco_ucm (Cisco Unified Communications Manager Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.23 cisco_ucs (Cisco UCS Server Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.24 clariion (Clariion Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.25 cluster (Clustered Environment Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.26 controller Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.27 cuegtw (Cloud Monitoring Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.28 db2 (DB2 Database Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.29 dirscan (File and Directory Scan) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.30 discovery_agent Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.31 discovery_server Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.32 diskstat (iSeries Disk Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.33 distsrv (Monitor Distribution Server) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.34 dns_response (DNS Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.35 e2e_appmon (E2E Application Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.36 email_response (Email Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.37 emailgtw (Email Gateway Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.38 ews_response (Microsoft Exchange Server Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.39 exchange_monitor (Microsoft Exchange Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.40 fetchmsg (Fetch System Messages on iSeries) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.41 file_adapter Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.42 fsmounts (File Systems Mount Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.43 google_apps (Google Apps Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.44 hadoop_monitor (Hadoop Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.45 ha (High Availability) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.46 hdb Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.47 health_index Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.48 history (iSeries QHST Data Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.49 hitachi (Hitachi Storage Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.50 hp_3par (HP 3PAR Storage Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.51 hpsmgtw (HP Service Manager Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.52 hub Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.53 hyperv (Microsoft Hyper-V Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.54 ibm_ds_next (IBM Disk Storage System 8000 Series Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.55 ibm_svc (IBM SVC Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.56 ibm-ds (IBM Disk Storage Systems Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.57 ibmvm (IBM Virtualization Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.58 ica_response (Citrix Client Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.59 icmp (Internet Control Message Protocol) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.60 iis (IIS Server Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.61 interface_traffic (Interface Traffic Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19
20
29
29
41
45
47
47
59
60
60
62
66
69
71
72
73
75
76
77
81
83
86
88
88
90
91
94
103
108
110
112
116
121
124
129
132
133
137
143
147
151
152
156
158
163
164
168
170
179
181
182
183
184
186
188
188
190
191
194
197
198
205
208
209
212
214
217
222
224
228
1.4.62 jdbc_response (Java Database Connectivity SQL Queries Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . .
1.4.63 jdbcgtw (JDBC Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.64 jobqs (iSeries Job Queues Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.65 jobs (iSeries Job Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.66 jobsched (iSeries Job Schedule Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.67 journal (iSeries Journal Message Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.68 jvm_monitor (Java Virtual Machine Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.69 logmon (Log Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.70 lync_monitor (Microsoft Lync Server Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.71 maintenance_mode Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.72 selfservice_cm (Self Service Configuration Management) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.73 mongodb_monitor (MongoDB Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.74 monitoring_services Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.75 nas (Alarm Server) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.76 net_connect (Network Connectivity Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.77 net_traffic (Network Traffic Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.78 netapp (NetApp Storage Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.79 nfa_inventory (NFA Inventory) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.80 notes_response (IBM Notes Server Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.81 notes_server (IBM Domino Server Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.82 nq_services (NQ Services) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.83 nsa (Script Agent) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.84 nsdgtw (CA Nimsoft Service Desk Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.85 ntevl (NT Event Log Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.86 ntp_response (Network Time Protocol Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.87 ntperf (Performance Collector) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.88 ntservices (Microsoft Windows NT Services Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.89 oracle (Oracle Database Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.90 outqs (iSeries Output Queue Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.91 perfmon (System Performance Engine Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.92 policy_engine Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93 ppm (Probe Provisioning Manager) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1 ppm Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.1 Probe Provisioning UIs Only Support Viewing Alarm Message Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.2 adevl/ntevl Probe UI Restricts Update Events Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.3 apache Probe UI Does Not Support Summary and Checkpoint Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.4 Adogtw Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.5 cdm Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.6 cluster UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.7 controller Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.8 db2 Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.9 dirscan Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.10 dns_response Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.11 e2e_appmon Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.12 emailgtw Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.13 file_adapter Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.14 ica_response Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.15 iis Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.16 informix Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.17 Jboss Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.18 jvm_monitor Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.19 logmon Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.20 ntevl Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.21 ntservices Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.22 oracle Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.23 perfmon Probe UI Does Not Show Some Fields Under Status Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.24 printers Probe UI Does Not Support 'Add Print Watcher' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.25 rsp Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.26 smsgtw Probe UI Does Not Provide Editable Drop Down for Sending Messages . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.27 sql_response Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.28 sqlserver Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.29 sybase Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.30 sybase_rs Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.31 url_response Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.32 webservicemon Probe UI Know Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.93.1.33 Websphere Probe UI Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.94 prediction_engine Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.95 printers (Printer Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.96 processes (Process Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.97 qos_processor Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.98 reboot Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.99 rsp (Remote System Probe) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
235
237
238
239
240
242
243
246
254
257
258
258
260
260
265
271
273
276
278
279
280
281
283
285
292
294
298
301
311
313
315
316
323
324
324
324
324
325
325
325
326
327
328
328
329
329
330
330
331
332
333
333
334
334
335
336
336
336
337
337
338
339
340
341
342
342
343
346
347
354
355
356
1.4.100 salesforce (Salesforce Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.101 sdgtw (Service Desk Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.102 service_host Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.103 sharepoint (Microsoft SharePoint Server Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.104 sla_engine Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.105 smsgtw (Short Message Service Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.106 sngtw (Service Now Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.107 snmpcollector (SNMP Data Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.107.1 snmpcollector Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.107.2 snmpcollector Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.107.3 snmpcollector Memory and Disk Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.107.4 snmpcollector General Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.107.5 Install snmpcollector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.107.6 Upgrade snmpcollector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.107.7 snmpcollector Known Issues and Workarounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.108 snmpget (SNMP Get) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.109 snmpgtw (Simple Network Management Protocol Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.110 snmptd (Simple Network Management Protocol Trap Daemon Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . .
1.4.111 snmptoolkit (SNMP Toolkit) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.112 spooler Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.113 sql_response (SQL Server Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.114 sqlserver (SQL Server Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.115 sybase_rs (Sybase Replication Server Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.116 sybase (Sybase Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.117 sysloggtw (System Log Gateway) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.118 sysstat (iSeries System Statistics Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.119 tcp_proxy (TCP/IP Proxy Service) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.120 threshold_migrator (Threshold Migrator) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.121 udm_manager Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.122 url_response (URL Endpoint Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.123 usage_metering Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.124 vmware (VMware Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.125 vplex (EMC VPLEX Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.126 webgtw (Web Gateway) Release notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.127 weblogic (Weblogic Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.128 webservicemon (Webservice URL Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.129 websphere_mq (WebSphere MQ Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.130 websphere (WebSphere Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.131 wins_response (Windows Internet Name Service Response Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.132 xenapp (XenApp Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.133 xendesktop (XenDesktop Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.134 xenserver (Citrix XenServer Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.135 xmlparser Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.136 zdataservice (Data Service Probe) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.137 zones (Solaris Zones Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.138 zops (zops Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.139 zstorage (zstorage Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.140 zvm (zvm Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Alphabetical Probe Articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1 ace (Automatic Configuration Engine) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2 ad_response (Active Directory Response Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.1 v1.6 ad_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.1.1 v1.6 ad_response AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.2 v1.6 ad_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.2.1 v1.6 ad_response IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.3 ad_response Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3 ad_server (Active Directory Server Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3.1 v1.8 ad_server AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3.1.1 v1.8 ad_server AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3.2 v1.8 ad_server IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3.2.1 v1.8 ad_server IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3.3 v1.7 ad_server AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3.3.1 v1.7 ad_server AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3.4 v1.7 ad_server IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3.4.1 v1.7 ad_server IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3.5 ad_server Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.4 adevl (Active Directory Events Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.4.1 v2.0 adevl AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.4.1.1 v2.0 adevl AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.4.2 v2.0 adevl IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.4.2.1 v2.0 adevl IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.4.2.2 v2.0 adevl IM Operation and Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
366
367
370
370
372
375
376
378
382
382
384
386
387
390
391
396
400
401
406
408
409
412
419
421
427
429
430
431
433
433
440
441
457
459
459
461
463
466
470
471
477
482
485
486
488
489
490
491
493
493
494
494
497
501
504
508
508
509
512
517
519
526
529
533
535
541
546
546
549
555
558
566
1.5.4.3 adevl Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.4.4 adevl Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.5 adogtw (ADO Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.5.1 v2.7 adogtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.5.1.1 v2.7 adogtw AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.5.2 v2.7 adogtw IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.5.3 adogtw Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.5.4 adogtw Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.6 aggregate_alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.6.1 v1.0 aggregate_alarm AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.6.1.1 v1.0 aggregate_alarm AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.6.1.2 Create Aggregate Alarms from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.7 alarm_enrichment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8 apache (Apache HTTP Server Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8.1 apache AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8.1.1 apache AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8.2 apache IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8.2.1 apache IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8.3 apache Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8.4 apache Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8.5 apache Version 1.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8.5.1 v1.6 apache AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.8.5.2 v1.6 apache IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9 apmgtw (CA APM Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.1 v2.0 apmgtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.2 v1.1 apmgtw IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.2.1 v1.1 apmgtw Advanced Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.2.2 v1.1 Verify apmgtw Probe Function CA APM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.2.3 v1.1 Verify apmgtw Probe Function in CA UIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.2.4 v1.1 View apmgtw Reports in CA APM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.3 v1.0 apmgtw IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.3.1 v1.0 apmgtw Advanced Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.3.2 v1.0 Verify apmgtw Probe Function in CA APM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.3.3 v1.0 Verify apmgtw Probe Function in CA UIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.3.4 v1.0 View apmgtw Reports in CA APM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.9.4 apmgtw Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.10 assetmgmt (Asset Management) - no longer supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.10.1 v1.2 assetmgmt IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.10.2 assetmgmt Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.11 audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.11.1 v1.2 audit IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.11.1.1 v1.2 audit Event Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.11.1.2 v1.2 audit GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.12 automated_deployment_engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.13 aws (Amazon Web Services Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.13.1 v4.0 aws AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.13.1.1 v4.0 aws AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.13.2 v3.5 aws AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.13.2.1 v3.5 AWS AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.13.3 aws Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.14 azure (Microsoft Azure Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.14.1 v2.1 azure AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.14.1.1 v2.1 Azure Apply Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.14.1.2 v2.1 azure AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.14.2 v2.0 azure AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.14.2.1 v2.0 azure AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.14.3 azure Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.15 baseline_engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.15.1 baseline_engine Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.15.2 v2.6 baseline_engine Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.15.2.1 v2.6 baseline_engine Raw Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.15.6 baseline_engine Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.16 billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.16.1 billing Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.16.2 billing Versions 8.0 - 8.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.16.2.1 v8.2 billing IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
566
566
570
570
572
574
582
583
583
583
589
591
595
595
596
598
600
603
607
609
611
611
616
623
624
626
629
631
631
632
632
635
637
637
637
638
638
638
639
639
639
643
645
654
654
655
661
673
675
687
692
693
697
700
705
708
713
714
714
716
719
721
723
724
726
727
729
731
731
732
733
733
1.5.16.2.2 v8.0 billing IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.17 capman_da (Capacity Management Data Adapter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.17.1 capman_da AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.18 casdgtw (CA ServiceDesk Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.18.1 v2.4 casdgtw AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.18.2 casdgtw Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.19 cassandra_monitor (Cassandra Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.19.1 cassandra_monitor AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.19.1.1 cassandra_monitor AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.19.2 cassandra_monitor Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.19.3 v1.0 cassandra_monitor Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.20 ccm_monitor (Cisco CallManager Monitor) - no longer supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.20.1 v1.4 ccm_monitor IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21 cdm (CPU, Disk, and Memory Performance) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.1 cdm AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.1.1 cdm AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.2 cdm IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.2.1 cdm IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.3 cdm Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.4 cdm Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.5 cdm Versions 5.5-5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.5.1 v5.5 cdm AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.5.2 v5.5 cdm IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.5.10 v5.1 cdm IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.5.11 v5.0 cdm AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.21.5.12 v5.0 cdm IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.22 celerra (EMC Celerra Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.22.1 v1.6 celerra AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.22.1.1 v1.6 celerra AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.22.2 v1.6 celerra IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.22.2.1 v1.6 celerra Advanced IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.22.2.2 v1.6 celerra IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.22.3 celerra Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.23 cisco_monitor (Cisco SNMP Device Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.23.1 cisco_monitor IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.23.2 cisco_monitor Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.24 cisco_qos (Cisco Class-Based QoS Statistics Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.24.1 cisco_qos Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.24.2 v1.2 cisco_qos IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.25 cisco_ucm (Cisco Unified Communications Manager Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.25.1 cisco_ucm AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.25.2 cisco_ucm IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.25.3 cisco_ucm Version 1.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.25.3.1 v1.8 cisco_ucm AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.25.3.2 v1.8 cisco_ucm IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.25.4 cisco_ucm Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.26 cisco_ucs (Cisco UCS Server Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.26.1 v2.3 cisco_ucs AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.26.1.1 v2.3 cisco_ucs AC Apply Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.26.1.2 v2.3 cisco_ucs AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.26.1.3 v2.3 cisco_ucs Configure Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.26.2 v2.3 cisco_ucs IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.26.2.1 v2.3 cisco_ucs IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.26.3 v2.1 cisco_ucs IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.26.3.1 v2.1 cisco_ucs IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.26.4 cisco_ucs Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.27 clariion (Clariion Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.27.1 v2.1 clariion AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.27.1.1 v2.1 clariion AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.27.2 v2.0 clariion AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.27.2.1 v2.0 clariion AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.27.3 v1.6 clariion IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.27.3.1 v1.6 clariion IM Operation and Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.27.3.2 v1.6 clariion IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.27.4 clariion Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
736
739
739
742
742
747
747
748
751
754
758
759
759
779
779
783
791
796
818
821
826
826
838
854
865
880
891
913
923
939
949
965
974
987
988
990
991
995
1002
1005
1010
1010
1019
1020
1020
1021
1032
1032
1038
1050
1050
1056
1067
1110
1111
1114
1121
1126
1126
1134
1137
1144
1148
1174
1175
1176
1179
1180
1182
1187
1203
1207
1.5.28 cluster (Clustered Environment Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.28.1 v3.3 cluster AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.28.1.1 v3.3 cluster AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.28.2 v3.3 cluster IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.28.2.1 v3.3 cluster IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.28.4.1 v3.2 cluster IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.28.7 cluster Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.28.8 cluster Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.29 cm_data_import (CM Data Import) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.30 controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.30.1 v7.8 controller AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.30.2 v7.8 controller IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.31 cuegtw (Cloud Monitoring Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.31.1 v1.0 cuegtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.32 data_engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.32.1 v8.3 data_engine AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.32.1.1 v8.3 data_engine AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.32.2 v8.3 data_engine IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.32.9 data_engine IM Basic Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.32.10 data_engine Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.32.11 data_engine Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.33 db2 (DB2 Database Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.33.1 v4.0 db2 AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.33.1.1 v4.0 db2 AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.33.2 v4.0 db2 IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.33.2.1 v4.0 db2 IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.33.2.2 v4.0 db2 Checkpoint Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.33.3 db2 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.34 dcim (Data Center Infrastructure Management Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.35 dirscan (File and Directory Scan) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.35.1 v3.1 dirscan AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.35.1.1 v3.1 dirscan AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.35.2 v3.1 dirscan IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.35.2.1 v3.1 dirscan IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.35.3 dirscan Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.35.4 dirscan Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.36 discovery_agent (Discovery Agent) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.37 discovery_server (Discovery Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.38 diskstat (iSeries Disk Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.38.1 diskstat AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.38.2 diskstat IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.38.3 diskstat Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.38.4 diskstat Version 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.38.4.1 v1.0 diskstat AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.38.4.2 v1.0 diskstat IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.39 distsrv (Monitor Distribution Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.39.1 v5.3 distsrv AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.39.2 v5.3 distsrv IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.40 dns_response (DNS Response Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.40.1 v1.6 dns_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.40.1.1 v1.6 dns_response AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.40.2 v1.6 dns_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.40.2.1 v1.6 dns_response IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1211
1213
1216
1220
1223
1229
1232
1237
1240
1246
1247
1251
1257
1258
1259
1259
1260
1262
1272
1273
1279
1281
1290
1291
1293
1295
1301
1305
1309
1314
1319
1324
1329
1333
1338
1343
1347
1352
1355
1355
1362
1363
1368
1373
1382
1388
1391
1407
1408
1408
1411
1415
1419
1425
1426
1427
1428
1428
1428
1432
1436
1436
1437
1443
1450
1450
1452
1456
1457
1458
1460
1463
1.5.40.3 dns_response Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.40.4 dns_response Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41 e2e_appmon (E2E Application Response Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.1 e2e_appmon AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.1.1 e2e_appmon AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.2 e2e_appmon IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.2.1 e2e_appmon IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.3 e2e_appmon Script Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.4 e2e_appmon API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.5 e2e_appmon Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.6 e2e_appmon Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.7 e2e_appmon Custom Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.8 e2e_appmon Version 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.8.1 v2.2 e2e_appmon AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.41.8.2 v2.2 e2e_appmon IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.42 ecometer_monitor (CA ecoMeter Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.43 email_response (Email Response Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.43.1 v1.4 email_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.43.1.1 v1.4 email_response AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.43.2 v1.4 email_response IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.43.3 email_response Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.44 emailgtw (Email Gateway Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.44.1 emailgtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.44.2 emailgtw IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.44.3 emailgtw Version 2.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.44.3.1 v2.7 emailgtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.44.3.2 v2.7 emailgtw IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.45 ews_response (Microsoft Exchange Server Response Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.45.1 v2.0 ews_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.45.1.1 v2.0 ews_response AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.45.2 v2.0 ews_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.45.2.1 v2.0 ews_response IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.45.3 v1.1 ews_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.45.3.1 v1.1 ews_response AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.45.4 v1.1 ews_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.45.4.1 v1.1 ews_response IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.45.5 ews_response Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.46 exchange_monitor_backend - no longer supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.47 exchange_monitor_reports - no longer supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48 exchange_monitor (Microsoft Exchange Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.1 v5.2 exchange_monitor AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.1.1 v5.2 exchange_monitor AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.2 v5.2 exchange_monitor IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.2.1 v5.2 exchange_monitor IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.3 v5.1 exchange_monitor AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.3.1 v5.1 exchange_monitor AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.4 v5.1 exchange_monitor IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.4.1 v5.1 exchange_monitor IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.5 exchange_monitor Supported Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.6 exchange_monitor Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.7 exchange_monitor Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.48.8 exchange_monitor Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.49 fetchmsg (Fetch System Messages on iSeries) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.49.1 v1.5 fetchmsg AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.49.1.1 v1.5 fetchmsg AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.49.2 v1.5 fetchmsg IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.49.2.1 v1.5 fetchmsg IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.49.3 fetchmsg Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.50 file_adapter (File Adapter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.50.1 v1.4 file_adapter AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.50.1.1 v1.4 file_adapter AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.50.2 v1.2 file_adapter IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.50.3 file_adapter Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.51 fsmounts (File Systems Mount Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.51.1 v1.2 fsmounts AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.51.1.1 v1.2 fsmounts AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.51.2 v1.2 fsmounts IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.51.2.1 v1.2 fsmounts IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.52 google_apps (Google Apps) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.52.1 v2.0 google_apps AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.52.1.1 v2.0 google_apps AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.52.2 google_apps Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1467
1468
1468
1468
1471
1475
1477
1483
1484
1494
1496
1496
1497
1498
1504
1511
1511
1511
1512
1514
1516
1516
1517
1521
1527
1527
1531
1537
1537
1540
1544
1546
1551
1553
1556
1558
1564
1564
1564
1565
1565
1570
1576
1580
1593
1599
1605
1610
1624
1636
1636
1656
1658
1658
1664
1667
1672
1676
1676
1677
1678
1680
1689
1689
1689
1690
1691
1693
1697
1697
1698
1701
1.5.53 ha (High Availability) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.53.1 v1.4 ha AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.53.1.1 v1.4 ha AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.53.2 v1.4 ha IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.53.3 ha Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.53.4 ha Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.54 hadoop_monitor (Hadoop Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.54.1 hadoop_monitor AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.54.1.1 hadoop_monitor AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.54.2 hadoop_monitor Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.55 hdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.56 health_index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.56.1 View Health Scores in CA Unified Service Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.56.2 health_index Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.57 history (iSeries QHST Data Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.57.1 v1.0 history AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.57.1.1 v1.0 history AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.57.2 v1.0 history IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.57.2.1 v1.0 history IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.58 hitachi (Hitachi Storage Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.58.1 v2.0 hitachi AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.58.1.1 v2.0 hitachi AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.58.2 v2.0 hitachi IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.58.2.1 v2.0 hitachi IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.58.3 hitachi Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.58.4 hitachi Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.59 hp_3par (HP 3PAR Storage Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.59.1 v1.1 hp_3par AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.59.1.1 v1.1 hp_3par AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.59.2 v1.0 hp_3par AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.59.2.1 v1.0 hp_3par AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.59.3 hp_3par Apply Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.59.4 hp_3par Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.60 hpsmgtw (HP Service Manager Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.60.1 hpsmgtw Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.60.2 v1.0 hpsmgtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.60.2.1 v1.0 hpsmgtw AC GUI Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.60.3 hpsmgtw Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.61 hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.61.1 v7.8 Hub AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.61.1.1 v7.8 Hub AC UI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.61.2 v7.8 Hub IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.61.2.1 v7.8 Hub IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.61.3.1 v7.7 Hub AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.61.5.1 v7.6 Hub AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.61.7 Hub Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.61.8 Hub Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.62 hyperv (Microsoft Hyper-V Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.62.1 v3.0 hyperv AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.62.1.1 v3.0 hyperv AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.62.2 hyperv Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.63 ibm_svc (IBM SVC Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.63.1 v1.0 ibm_svc AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.63.1.1 v1.0 ibm_svc AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.63.2 v1.0 ibm_svc IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.63.2.1 v1.0 ibm_svc IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.63.3 ibm_svc Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.64 ibm-ds (IBM Disk Storage System Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.64.1 ibm-ds AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.64.1.1 ibm-ds AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.64.2 ibm-ds IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.64.2.1 ibm-ds IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.64.3 ibm-ds Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.65 ibmvm (IBM Virtualization Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.65.1 v2.3 ibmvm AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.65.1.1 v2.3 ibmvm AC Apply Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1702
1705
1710
1711
1716
1717
1718
1718
1719
1723
1736
1736
1737
1739
1739
1739
1742
1744
1747
1749
1750
1752
1755
1758
1761
1764
1765
1766
1767
1769
1771
1773
1776
1779
1779
1779
1782
1784
1784
1785
1794
1800
1810
1823
1830
1835
1849
1862
1868
1874
1888
1902
1903
1903
1904
1910
1915
1917
1917
1919
1922
1926
1928
1935
1936
1938
1940
1945
1947
1953
1953
1955
1.5.65.1.2 v2.3 ibmvm AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.65.1.3 v2.30 ibmvm AC Configure Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.65.2 v2.3 ibmvm IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.65.2.1 v2.3 ibmvm IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.65.4 v2.1 ibmvm IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.65.4.1 v2.1 ibmvm IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.65.6 ibmvm Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.66 ica_response (Citrix Client Response Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.66.1 ica_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.66.1.1 ica_response AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.66.2 ica_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.66.2.1 ica_response IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.66.3 ica_response Version 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.66.3.1 v3.0 ica_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.66.3.2 v3.0 ica_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.66.4 ica_response Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.67 icmp (Internet Control Message Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.67.1 v1.2 icmp AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.67.1.1 v1.2 icmp Applying Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.67.1.2 v1.2 icmp Configure Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.67.1.3 v1.2 icmp AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.67.2 icmp Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.68 iis (IIS Server Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.68.1 v1.7 iis IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.68.1.1 v1.7 iis IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.68.2 v1.7 iis AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.68.2.1 v1.7 iis AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.68.3 iis Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.69 interface_traffic (Interface Traffic Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.69.1 v5.4 interface_traffic IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.69.1.1 v5.4 interface_traffic IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.69.2 interface_traffic Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.69.3 interface_traffic Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.70 jdbc_response (Java Database Connectivity SQL Queries Response Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.70.1 jdbc_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.70.2 jdbc_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.70.3 jdbc_response Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.70.4 jdbc_response Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.70.5 jdbc_response Attribute Substitutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.71 jdbcgtw (Java Database Connectivity Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.71.1 v1.0 jdbcgtw IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.71.1.1 v1.0 jdbcgtw IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.71.2 jdbcgtw Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.71.3 jdbcgtw Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.71.4 v1.0 jdbcgtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.71.4.1 v1.0 jdbcgtw AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.72 jmx - no longer supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.73 jobqs (iSeries Job Queues Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.73.1 v1.1 jobqs AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.73.1.1 v1.1 jobqs AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.73.2 v1.1 jobqs IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.73.2.1 v1.1 jobqs IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.73.3 jobqs Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.74 jobs (iSeries Job Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.74.1 v1.3 jobs AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.74.1.1 v1.3 jobs AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.74.2 v1.3 jobs IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.74.2.1 v1.3 jobs IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.74.3 jobs Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.75 jobsched (iSeries Job Schedule Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.75.1 v1.2 jobsched AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.75.1.1 v1.2 jobsched AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.75.2 v1.2 jobsched IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.75.2.1 v1.2 jobsched IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.76 journal (iSeries Journal Message Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.76.1 v1.0 journal AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.76.1.1 v1.0 journal AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.76.2 v1.0 journal IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1961
1966
1966
1973
1975
1976
1981
1987
1989
1990
1994
2001
2003
2009
2011
2014
2021
2021
2029
2039
2040
2041
2045
2048
2048
2053
2054
2054
2057
2068
2071
2075
2076
2077
2092
2105
2107
2107
2108
2111
2115
2116
2117
2118
2118
2122
2126
2126
2126
2129
2132
2132
2132
2135
2138
2141
2144
2145
2145
2148
2152
2155
2158
2159
2159
2161
2164
2166
2169
2169
2173
2177
1.5.76.2.1 v1.0 journal IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.77 jvm_monitor (Java Virtual Machine Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.77.1 jvm_monitor Preconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.77.2 jvm_monitor AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.77.2.1 jvm_monitor AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.77.3 jvm_monitor IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.77.3.1 jvm_monitor IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.77.4 jvm_monitor Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.77.5 jvm_monitor Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78 logmon (Log Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.1 logmon Upgrades and Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.2 logmon AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.2.1 logmon Advanced AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.3 logmon IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.3.1 logmon Advanced IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.4 logmon Versions 3.5-3.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.4.1 v3.5 logmon AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.4.2 v3.5 logmon IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.4.3 v3.4 logmon AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.4.4 v3.4 logmon IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.5 logmon Hints and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.78.6 logmon Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.79 lync_monitor (Microsoft Lync Server Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.79.1 v2.2 lync_monitor AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.79.1.1 v2.2 lync_monitor AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.79.2 v2.2 lync_monitor IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.79.2.1 v2.2 lync_monitor IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.79.3 lync_monitor Supported Performance Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.79.4 lync_monitor Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.80 maintenance_mode (Maintenance Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.80.1 v8.0 maintenance_mode Raw Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.80.1.1 v8.0 maintenance_mode Raw Configuration Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.81 mongodb_monitor (MongoDB Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.81.1 v1.0 mongodb_monitor AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.81.1.1 v1.0 mongodb_monitor AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.81.2 mongodb_monitor Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.82 monitoring_services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.82.1 v2.2 monitoring_services AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.83 mpse (Monitoring Provisioning Service) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84 nas (Alarm Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.1 alarm_enrichment and nas Probe Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.2 v4.7 alarm_enrichment Raw Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.3 v4.7 nas IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.3.1 The nas Setup Tab v4.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.3.2 The Auto-Operator Tab v4.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.3.3 The Name Services Tab v4.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.3.4 The Notes Tab v4.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.3.5 The Status Tab v4.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.3.6 The Alarm List v4.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.5.2 The Auto-Operator Tab v4.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.5.4 The Notes Tab v4.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.5.5 The Alarm List v4.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.5.6 The Status Tab v4.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.7.2 The Auto-Operator Tab 4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.7.4 The Notes Tab v4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.7.5 The Alarm List v4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.7.6 The Status Tab v4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8 The nas Command Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.1 assign_alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.2 close_alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.3 date_forecast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.4 db_query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2180
2184
2184
2187
2189
2192
2196
2202
2203
2204
2204
2205
2220
2223
2234
2238
2238
2251
2265
2279
2293
2305
2306
2307
2310
2315
2320
2326
2342
2359
2360
2363
2364
2364
2367
2371
2397
2397
2398
2398
2399
2399
2402
2402
2404
2404
2419
2445
2446
2448
2450
2455
2458
2458
2471
2496
2498
2500
2505
2507
2509
2509
2517
2533
2533
2535
2540
2542
2542
2543
2543
2543
1.5.84.8.5 get_alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.6 get_ao_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.7 get_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.8 get_sid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.9 host_summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.10 nameservice_create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.11 nameservice_delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.12 nameservice_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.13 nameservice_lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.14 nameservice_setlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.15 nameservice_update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.16 note_attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.17 note_create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.18 note_delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.19 note_detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.20 note_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.21 Reorganize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.22 repl_queue_post . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.23 repl_queue_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.24 script_delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.25 script_rename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.26 script_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.27 script_run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.28 script_validate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.29 set_loglevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.30 set_visible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.31 transaction_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.8.32 trigger_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.9 The nas Script Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.9.1 The nas Extentions to Lua (All Versions) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.84.10 nas Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85 net_connect (Network Connectivity Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85.1 net_connect AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85.1.1 net_connect AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85.2 net_connect IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85.2.1 net_connect IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85.3 net_connect Versions 3.1-3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85.3.1 v3.1 net_connect AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85.3.2 v3.1 net_connect IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85.3.3 v3.0 net_connect AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85.3.4 v3.0 net_connect IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85.4 net_connect Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.85.5 net_connect Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.86 net_traffic (Network Traffic Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.86.1 net_traffic IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.86.2 net_traffic Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.87 netapp (NetApp Storage Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.87.1 netapp Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.87.2 netapp Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.87.3 netapp MIB Files Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.87.4 netapp IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.87.5 netapp Version 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.87.5.1 v1.3 netapp IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.88 nfa_inventory (NFA Inventory) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.88.1 v1.1 nfa_inventory AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.88.2 v1.0 nfa_inventory AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.89 notes_response (IBM Notes Server Response Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.89.1 notes_response Set Up IBM Notes Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.89.2 notes_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.89.3 notes_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.89.4 notes_response Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.90 notes_server64 (IBM Domino Server Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.90.1 notes_server64 AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.90.2 notes_server64 IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.91 notes_server (IBM Domino Server Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.91.1 notes_server Preconfiguration Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.91.2 notes_server AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.91.2.1 notes_server AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.91.3 notes_server IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.91.3.1 notes_server IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.91.4 notes_server Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.91.5 notes_server Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2543
2544
2544
2544
2544
2545
2545
2545
2545
2545
2546
2546
2546
2546
2546
2547
2547
2547
2547
2547
2547
2548
2548
2548
2548
2548
2548
2549
2549
2554
2565
2565
2566
2569
2574
2581
2590
2590
2598
2627
2633
2653
2654
2656
2656
2663
2664
2664
2667
2671
2672
2682
2682
2692
2693
2696
2697
2697
2698
2701
2705
2705
2706
2706
2706
2706
2708
2711
2713
2717
2720
2720
1.5.92 nq_services (NQ Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.93 nsdgtw (CA Nimsoft Service Desk Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.93.1 nsdgtw Preconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.93.2 nsdgtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.93.3 nsdgtw IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.93.4 nsdgtw Advanced Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.93.5 nsdgtw Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.94 ntevl (NT Event Log Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.94.1 ntevl AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.94.2 ntevl IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.94.3 ntevl Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.94.4 ntevl Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.94.5 ntevl Versions 4.1-4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.94.5.1 v4.0 ntevl AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.94.5.2 v4.0 ntevl IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.94.5.3 v4.1 ntevl AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.94.5.4 v4.1 ntevl IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.95 ntp_response (Network Time Protocol Response Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.95.1 v1.4 ntp_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.95.1.1 v1.4 ntp_response AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.95.2 v1.4 ntp_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.95.2.1 v1.4 ntp_response IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.95.3 ntp_response Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.96 ntperf64 (Performance Collector) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.96.1 v2.0 ntperf64 AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.96.2 v2.0 ntperf64 IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.96.3 v1.9 ntperf64 AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.96.4 v1.9 ntperf64 IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.97 ntperf (Performance Collector) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.97.1 ntperf Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.97.2 v2.0 ntperf AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.97.2.1 v2.0 ntperf AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.97.3 v2.0 ntperf IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.97.3.1 v2.0 ntperf IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.97.5.1 v1.9 ntperf IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.98 ntservices (Microsoft Windows NT Services Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.98.1 v3.2 ntservices AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.98.1.1 v3.2 ntservices AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.98.2 v3.2 ntservices IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.98.2.1 v3.2 ntservices IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.98.3 v3.1 ntservices AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.98.3.1 v3.1 ntservices AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.98.4 v3.1 ntservices IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.98.4.1 v3.1 ntservices IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.98.5 ntservices Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.99 oracle (Oracle Database Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.99.1 oracle Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.99.2 v4.9 oracle AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.99.2.1 v4.9 oracle AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.99.3 v4.9 oracle IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.99.3.1 v4.9 oracle IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.99.4 v4.8 oracle AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.99.4.1 v4.8 oracle AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.99.5 v4.8 oracle IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.99.5.1 v4.8 oracle IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.100 outqs (iSeries Output Queue Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.100.1 v1.1 outqs AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.100.1.1 v1.1 outqs AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.100.2 v1.1 outqs IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.100.2.1 v1.1 outqs IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.100.3 outqs Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.101 packageEditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.101.1 v4.0 PackageEditor IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.101.2 v4.0 Package Editor Configuration File (.cfx) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.102 perfmon (System Performance Engine Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.102.1 v1.6 perfmon AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2721
2721
2721
2723
2729
2733
2734
2735
2735
2744
2754
2758
2758
2758
2766
2776
2786
2797
2797
2798
2802
2803
2808
2808
2809
2809
2809
2809
2809
2809
2810
2813
2816
2819
2831
2833
2835
2837
2846
2848
2851
2851
2852
2855
2859
2862
2867
2869
2872
2874
2878
2879
2880
2891
2894
2902
2914
2922
2925
2933
2933
2957
2957
2959
2961
2963
2965
2965
2966
2971
2973
2973
1.5.102.1.1 v1.6 perfmon AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.102.2 v1.6 perfmon IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.102.2.1 v1.6 perfmon IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.102.3 perfmon Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.103 policy_engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.103.1 v8.2 policy_engine AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.103.1.1 v8.2 policy_engine AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.104 ppm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.104.1 v3.2 ppm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.104.2 v3.1 ppm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.104.3 v3.0 ppm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.104.4 v2.38 ppm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.104.5 Error Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.104.6 ppm Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.105 prediction_engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.105.1 v1.3 prediction_engine AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.105.1.1 v1.3 prediction_engine AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.105.2.1 v1.2 prediction_engine Configure Time to Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.105.3.1 v1.1 prediction_engine Configure Time To Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.105.4.1 v1.0 prediction_engine Configure Time To Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.105.5 prediction_engine Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.105.6 prediction_engine Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.106 printers (Printer Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.106.1 v2.5 printers AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.106.2 printers Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.107 processes (Process Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.107.1 v4.0 processes AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.107.1.1 v4.0 processes AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.107.2 v4.0 processes IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.107.2.1 v4.0 processes IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.107.3.1 v3.9 processes AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.107.4.1 v3.9 processes IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.107.6.1 v3.8 processes IM Raw Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.107.7 processes Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.108 qos_processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.108.1 v1.2 qos_processor - Infrastructure Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.108.1.1 qos_processor IM Configuration v1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.109 reboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.109.1 v1.4 reboot IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110 rsp (Remote System Probe) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.1 v5.1 rsp AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.1.1 v5.1 rsp AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.2 v5.1 rsp IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.2.1 v5.1 rsp IM Advanced Configuration Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.2.2 v5.1 rsp IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.2.3 v5.1 rsp Lua Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.3 v5.0 rsp AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.3.1 v5.0 rsp AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.4 v5.0 rsp IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.4.1 v5.0 rsp IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.4.2 v5.0 rsp IM Advanced Configuration Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.4.3 v5.0 rsp Lua Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.5 rsp Hints and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.6 rsp Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.110.7 rsp Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.111 salesforce (Salesforce Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.111.1 v2.0 salesforce AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.111.1.1 v2.0 salesforce AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.111.2 salesforce Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.112 sdgtw (Service Desk Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.112.1 v1.0 sdgtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.112.2 sdgtw Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2974
2976
2978
2980
2980
2980
2980
2982
2982
2984
2986
2987
2988
2988
2989
2989
2992
2993
2995
2996
2997
2999
3000
3001
3003
3004
3005
3006
3006
3006
3009
3009
3009
3012
3017
3022
3039
3041
3045
3051
3060
3065
3083
3086
3088
3088
3089
3092
3092
3098
3099
3104
3112
3129
3142
3146
3150
3155
3162
3179
3181
3195
3197
3198
3204
3207
3208
3209
3214
3215
3215
3225
1.5.113 service_host (Service Host) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.113.1 service_host Versions 8.1 - 8.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.113.1.1 v8.3 service_host AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.114 sharepoint (Microsoft SharePoint Server Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.114.1 sharepoint Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.114.2 SharePoint 2013 Performance Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.115 sla_engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.115.1 v3.7 sla_engine IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.115.1.1 v3.7 sla_engine IM Advanced Configuration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.115.2 v3.6 sla_engine IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.115.2.1 v3.6 sla_engine IM Advanced Configuration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.116 smsgtw (Short Message Service Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.116.1 v3.1 smsgtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.116.1.1 v3.1 smsgtw AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.116.2 v3.1 smsgtw IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.116.2.1 v3.1 smsgtw IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.116.3 v3.0 smsgtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.116.4 smsgtw High Availability Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.116.5 smsgtw Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.117 sngtw (ServiceNow Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.117.1 v2.1 sngtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.117.2 sngtw Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.117.3 sngtw Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118 snmpcollector (SNMP Data Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.1 snmpcollector Theory of Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.2 v2.2 snmpcollector AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.2.1 v2.2 snmpcollector Configure Monitoring with the Probe Configuration GUI . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.2.2 v2.2 snmpcollector Apply Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.2.3 v2.2 snmpcollector Configure Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.2.4 v2.2 snmpcollector Data Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.2.5 v2.2 snmpcollector AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.3.1 v2.1 snmpcollector Configure Monitoring with the Probe Configuration GUI . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.3.2 v2.1 snmpcollector Apply Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.4.1 v2.0 snmpcollector Apply Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.5.2 v1.6 snmpcollector Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.5.3 v1.6 snmpcollector Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.6 snmpcollector Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.7 snmpcollector Device Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.118.8 SNMP Device Self-Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.119 snmpget (SNMP Get) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.119.1 v1.9 snmpget IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.119.1.1 v1.9 snmpget IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.119.2 v1.8 snmpget IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.119.2.1 v1.8 snmpget IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.119.3 snmpget Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.120 snmpgtw (Simple Network Management Protocol Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.120.1 v1.3 snmpgtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.120.1.1 v1.3 snmpgtw AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.120.2 v1.3 snmpgtw IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.120.2.1 v1.3 snmpgtw IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.120.3 snmpgtw Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.121 snmptd (Simple Network Management Protocol Trap Daemon Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.121.1 v3.1 snmptd IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.121.1.1 v3.1 snmptd IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.121.2 snmptd Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.121.3 snmptd Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.122 snmptoolkit (SNMP Toolkit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.122.1 snmptoolkit DTA Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.122.2 snmptoolkit Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.122.3 v1.3 snmptoolkit IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3225
3225
3225
3227
3228
3229
3230
3235
3238
3238
3242
3244
3246
3249
3249
3255
3258
3265
3274
3278
3279
3279
3280
3286
3287
3289
3289
3297
3305
3306
3310
3311
3316
3323
3332
3333
3337
3337
3342
3350
3355
3360
3360
3366
3373
3382
3388
3390
3392
3393
3394
3406
3406
3414
3421
3426
3434
3435
3435
3437
3440
3442
3444
3444
3445
3451
3457
3459
3459
3460
3473
3473
1.5.122.3.1 v1.3 snmptoolkit IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.123 spooler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.123.1 v7.8 spooler AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.123.2 v7.8 spooler IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.124 sql_response (SQL Server Response Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.124.1 sql_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.124.2 sql_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.124.3 sql_response Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.125 sqlserver (SQL Server Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.125.1 sqlserver AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.125.2 sqlserver IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.125.3 sqlserver Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.125.4 sqlserver Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.125.5 sqlserver Versions 4.9-4.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.125.5.1 v4.9 sqlserver AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.125.5.2 v4.9 sqlserver IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.125.5.3 v4.8 sqlserver AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.125.5.4 v4.8 sqlserver IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.126 sybase_rs (Sybase Replication Server Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.126.1 sybase_rs Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.126.2 v1.4 sybase_rs AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.126.2.1 v1.4 sybase_rs AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.126.3 v1.4 sybase_rs IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.126.4 sybase_rs Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.127 sybase (Sybase Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.127.1 sybase Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.127.2 sybase AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.127.2.1 sybase AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.127.3 sybase IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.127.3.1 sybase IM GUI reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.127.4 sybase Version 4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.127.4.1 v4.2 sybase AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.127.4.2 v4.2 sybase IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.128 sysloggtw (System Log Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.128.1 v1.4 sysloggtw AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.128.2 v 1.4 sysloggtw IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.129 sysstat (iSeries System Statistics Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.129.1 v1.1 sysstat AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.129.1.1 v1.1 sysstat AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.129.2 v1.1 sysstat IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.129.2.1 v1.1 sysstat IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.129.3 sysstat Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.130 tcp_proxy (TCP/IP Proxy Service) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.130.1 v1.1 tcp_proxy AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.131 threshold_migrator (Threshold Migrator) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.131.1 threshold_migrator Supported Probe Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.131.2 v2.1 threshold_migrator AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.131.2.1 v2.1 threshold_migrator AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.131.5 threshold_migrator Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.132 topology_agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.133 udm_manager (UDM Manager) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.133.1 v8.2 udm_manager AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.134 ugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.135 url_response (URL Endpoint Response Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.135.1 url_response Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.135.2 url_response Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.135.3 url_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.135.3.1 url_response AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.135.4 url_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.135.4.1 url_response IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.135.5 url_response Version 4.2-4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.135.5.1 v4.1 url_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3477
3483
3483
3485
3490
3492
3497
3498
3503
3503
3510
3516
3517
3518
3524
3534
3534
3543
3544
3550
3560
3565
3578
3578
3579
3580
3584
3603
3604
3605
3608
3613
3618
3624
3636
3637
3646
3664
3665
3666
3671
3671
3674
3675
3678
3680
3680
3681
3682
3683
3685
3689
3691
3695
3696
3699
3700
3701
3701
3704
3705
3707
3709
3709
3709
3713
3717
3719
3724
3727
3734
3734
1.5.135.5.2 v4.2 url_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.135.5.3 v4.2 url_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.136 usage_metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.136.1 v8.0 usage_metering Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.136.1.1 v8.0 usage_metering IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137 vmware (VMware Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.1 v6.6 vmware AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.1.1 v6.6 vmware AC Apply Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.1.2 v6.6 vmware AC Configure Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.1.3 v6.6 vmware AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.2 v6.6 vmware IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.2.1 v6.6 vmware IM Configure Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.2.2 v6.6 vmware IM Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.2.3 v6.6 vmware IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.3.1 v6.5 vmware AC Configure Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.3.3 v6.5 vmware Apply Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.4.1 v6.5 vmware IM Configure Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.5.2 v6.4 vmware Configure Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.6.1 v6.4 vmware Configure Alarm Thresholds IM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.6.4 v6.4 vmware IM Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.8.1 v6.3 vmware Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.8.3 v6.3 vmware Known Issues and Workarounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.8.4 v6.3 vmware Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.10 v6.1 vmware IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.10.1 v6.1 vmware IM Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.10.2 v6.1 vmware IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.10.3 v6.1 vmware IM Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.10.4 v6.1 vmware Known Issues and Workarounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.11 vmware Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.137.12 vmware Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.138 vplex (EMC VPLEX Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.138.1 vplex AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.138.1.1 vplex Configure Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.138.2 vplex Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.139 wasp (Web Application Server Probe) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.139.1 wasp Versions 8.1-8.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.139.1.1 v8.3 wasp AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.139.1.2 v8.3 wasp IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.139.1.3 v8.2 wasp AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.140 webgtw (Web Gateway) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.140.1 v8.0 webgtw AC Deployment and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.141 weblogic (Weblogic Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.141.1 v1.4 weblogic AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.141.1.1 v1.4 weblogic AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.141.2 v1.4 weblogic IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.141.2.1 v1.4 weblogic IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.141.3 weblogic Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.141.4 weblogic Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.141.5 Weblogic Monitoring (weblogic) Enable IIOP on the WebLogic Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.142 webservicemon (Webservice URL Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.142.1 v1.2 webservicemon AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.142.2 v1.2 webservicemon IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.142.2.1 v1.2 webservicemon IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.142.3 webservicemon Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3740
3746
3756
3757
3760
3767
3768
3772
3779
3779
3783
3793
3793
3795
3797
3801
3802
3805
3811
3821
3821
3823
3825
3829
3833
3833
3842
3842
3844
3846
3847
3849
3852
3859
3860
3863
3864
3865
3867
3870
3878
3879
3881
3882
3884
3899
3900
3901
3904
3907
3912
3912
3913
3922
3936
3946
3960
3973
3974
3975
3975
3977
3980
3987
3989
3990
3991
3991
3992
3998
4021
4024
1.5.142.4 webservicemon Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.143 webservices_rest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.144 webservices_soap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.145 websphere_mq (WebSphere MQ Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.145.1 websphere_mq AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.145.1.1 websphere_mq Advanced Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.145.2 websphere_mq Configure Monitoring Using Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.145.3 websphere_mq Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.145.4 websphere_mq Versions 2.1-2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.145.4.1 v2.0 websphere_mq AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.146 websphere (WebSphere Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.146.1 v1.7 websphere AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.146.1.1 v1.7 websphere AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.146.2 v1.7 websphere IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.146.2.1 v1.7 websphere IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.146.3 websphere Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.147 wins_response (Windows Internet Name Service Response Monitoring) - no longer supported . . . . . . . . . . . . . . . . . . . .
1.5.147.1 wins_response IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.148 xenapp Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.148.1 v1.1 xenapp IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.148.1.1 v1.1 xenapp IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.148.2 xenapp Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.148.3 xenapp Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.149 xendesktop Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.149.1 v3.0 xendesktop IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.149.1.1 v3.0 xendesktop IM Set Up and Configure Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.149.1.2 v3.0 xendesktop IM Apply Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.149.1.3 v3.0 xendesktop IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.149.2 v2.1 xendesktop IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.149.2.1 v2.1 xendesktop IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.149.3 xendesktop Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.150 xenserver (Citrix XenServer Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.150.1 v2.0 xenserver IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.150.1.1 v2.0 xenserver IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.150.2 v2.3 xenserver AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.150.2.1 v2.3 xenserver Configure Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.150.3 v2.3 xenserver IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.150.3.1 v2.3 xenserver IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.151 xmlparser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.151.1 xmlparser IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152 zdataservice (Data Service Probe) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152.1 Overview of Data Service Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152.2 Complete the Prerequisite Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152.2.1 Configure the CIM Server Using CA Top Secret Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152.2.2 Configure the CIM Server Using CA ACF2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152.3 Install the Data Service Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152.4 Upgrade the Data Service Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152.5 (Optional) Configure the Probe Communication Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152.6 Configure the Data Service Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152.6.1 Configure the Data Service Probe v1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152.7 Troubleshooting Data Service Probe Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.152.8 Data Service Probe Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.153 zones (Solaris Zones Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.153.1 v1.3 zones IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.153.1.1 v1.3 zones IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.153.2 zones Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154 zops (zops Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.1 v1.0 zops Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.1.1 Install zops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.1.2 Add a zops Resource Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.1.3 Configure zops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.2 zops Maintenance Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.3 zops Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.3.1 CEC (Central Electronic Complex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.3.2 LPAR (Logical Partitioning) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.3.3 SYSPLEX (System Complex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.3.4 CHANNELS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.3.5 zOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.3.6 CF (Coupling Facility) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.3.7 STC (Started Task Control) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.3.8 SYSTEM TASKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.154.4 zops Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4024
4025
4025
4026
4028
4035
4036
4040
4043
4044
4052
4053
4056
4060
4067
4077
4078
4078
4079
4080
4094
4096
4111
4115
4116
4123
4132
4134
4137
4150
4153
4170
4170
4177
4179
4183
4184
4192
4194
4194
4204
4205
4206
4217
4221
4226
4228
4229
4229
4230
4231
4233
4237
4238
4243
4248
4249
4250
4250
4252
4254
4255
4256
4256
4256
4257
4257
4257
4258
4258
4259
4259
1.5.154.4.1 Recommended zops Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.155 zstorage (zstorage Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.1 v1.0 zstorage Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.1.1 Install zstorage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.1.2 Add a Resource Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.1.3 Configure zstorage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.2 zstorage Maintenance Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.3 zstorage Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.3.1 FCPORT (Fiber Channel Port) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.3.2 HFS (Hierarchical File System) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.3.3 NFS (Network File System) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.3.4 DASD (Direct Access Storage Device) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.4 zstorage Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.155.4.1 Recommended zstorage Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156 zvm (zvm Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.1 Data Collector and Data Service Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.1.1 Install and Configure the Data Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.1.2 Install and Configure the zdataservice Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.1.3 Upgrade the Data Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.1.4 Uninstall the Data Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.2 v1.0 zvm Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.3 v1.1 zvm Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.4 Upgrade, Downgrade, or Uninstall zvm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.5 zvm Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.5.1 Clusters/Hypervisors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.5.2 Guests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.6 zvm Monitoring with Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.6.1 Work with the zvm_template Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.6.2 Recommended zvm Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.156.6.3 How to Update zvm v1.0 Templates after a zvm 1.1 Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6 Unified Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 Probe Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1 Probe Software Developer Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.1 Probe SDK Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.1.1 Getting Started with Probe-SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.1.2 Development Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.1.3 Probe Configuration Files Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.1.4 Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.1.5 Adding Subsystem IDs for a Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.1.6 Probe SDK Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.2 Probe SDK Cookbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.2.1 Setting Up a Probe Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.2.2 Declaring Inventory, Metrics, and Bulk Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.2.3 Configuring Profile Properties and Standard Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.2.4 Producing Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.2.5 Producing Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.2.6 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.2.7 Debugging a Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1.2.8 Miscellaneous Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2 RESTful Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.1 Set Up RESTful Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2 Call Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.1 Account Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.2 ACL Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.3 Alarm Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.4 Computer System Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.5 Configuration Item (CI) Data Retrieval Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.6 Contact Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.7 Custom Property Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.8 Dashboard Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.9 Maintenance Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.10 Origin Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.11 Probe Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.12 QoS Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.13 UIM Infrastructure Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2.2.14 Variable Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4264
4269
4270
4270
4272
4274
4275
4276
4276
4277
4277
4277
4278
4283
4285
4285
4285
4290
4290
4291
4292
4296
4300
4303
4303
4307
4308
4313
4314
4317
4318
4319
4319
4321
4322
4325
4326
4332
4336
4337
4340
4341
4342
4344
4350
4351
4352
4352
4353
4355
4358
4359
4360
4380
4392
4412
4422
4432
4440
4447
4449
4483
4485
4506
4531
4541
CA Unified Infrastructure Management Probes
A probe is small piece of software that performs a dedicated task. CA Unified Infrastructure Management has two types of probes:
Monitoring probes gather availability and performance data. Some 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 named infrastructure or utility probes) provide product utility functions.
Probes can be easily configured 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.
The user information for core CA Unified Infrastructure Management components, such as the UIM database or UMP, is now available at the CA
Unified Infrastructure Management DocOps Space. You can use the following window to search the CA UIM DocOps space from this site.
Join the CA UIM Community today at https://communities.ca.com/community/ca-infrastructu

re-management. Use CA Communities to reach out to users and product experts who can help answer questions and can solve
problems.
Supported Platforms
Compatibility Support Matrix for the latest information about supported platforms
Support Matrix for Probes for additional information about the probe
How To Articles
View common probe use cases.
Release Notes
View a summary of the changes for a probe release.
Alphabetical Probe Articles

View configuration and metric information for each probe.
Unified Dashboards
View information about the Unified Dashboards in UMP.
Probe Development Tools

Information about the APIs and SDKs available to advanced users.
Alphabetical List of Probe IDs
This article is a quick reference guide to help you identify the monitoring capabilities of a particular probe. Be aware that some probe versions are
only supported in Admin Console (AC) or Infrastructure Manager (IM). To view any older versions of a probe guide, see the IM Probe Archive or
the AC Probe Archive.
Probe ID
Name
Group
AC
Articles
IM
Articles
ace
Automatic Configuration Engine
System
AC
IM
ad_response
Active Directory Response Monitoring
Application
AC
IM
ad_server
Active Directory Server Monitoring
Application
AC
IM
adevl
Active Directory Events Monitoring
Application
AC
IM
adogtw
ActiveX Data Objects (ADO) Gateway
Gateway
AC
IM
alarm_enrichment
Alarm Enrichment
Infrastructure
IM
apache
Apache HTTP Server Monitoring
Application
AC
IM
apmgtw
Application Performance Management Gateway
Gateway
AC
IM
applogic_mon
AppLogic Application Monitoring
Application
IM Archive
applogic_ws
AppLogic Platform Grid Monitoring
Application
IM Archive
arcserv_d2d
ARCserv D2D
Application
IM Archive
arcserv_rha
ARCserv RHA
Application
IM Archive
assetmgmt
Asset Management
Infrastructure
IM
audit
Maintain Data Structures for Robot Auditing
Service
IM
automated_deployment_engine
Automated Deployment Engine
System
AC
aws
Amazon Web Services Monitoring
Application
AC
IM Archive
azure
Microsoft Azure Monitoring
Application
AC
IM Archive
baseline_engine
Baseline Engine
SLM
IM
billing
Billing
Service
IM
capman_da
Capacity Management Data Adapter
System
AC
casdgtw
CA ServiceDesk Gateway
Gateway
AC
IM Archive
cassandra_monitor
Cassandra Monitoring
Application
AC
ccm_monitor
Cisco CallManager Monitoring
Application
IM
cdm
CPU, Disk, and Memory Performance
System
AC
IM
celerra
EMC Celerra Monitoring
Storage
AC
IM
cisco_monitor
Cisco Hardware Monitoring
Network
IM
cisco_nxos
Cisco NX-OS Monitoring
Network
IM Archive
cisco_qos
Cisco Class-Based QoS Statistics Monitoring
Network
IM
cisco_ucm
Cisco Unified Communications Manager Monitoring
Application
AC
IM
cisco_ucs
Cisco UCS Monitoring
Application
AC
IM
cisco_unity
Cisco Unity Connection Monitoring
Network
IM Archive
clariion
Clariion Monitoring
Storage
AC
IM
cloudstack
Cloudstack
Application
IM Archive
cluster
Clustered Environment Support
System
AC
IM
cm_data_import
Data Import
Service
AC
cmdbgtw
SLM Database Gateway
Gateway
IM Archive
controller
Controller
Infrastructure
AC
IM
cuegtw
Cloud Monitoring Gateway
Gateway
AC
IM Archive
dap
Data Access and Collection
Service
IM Archive
dashboard_engine
Dashboard Engine
Service
IM Archive
dashboard_server
Dashboard Server
Infrastructure
IM Archive
data_engine
Data Engine
SLM
AC
IM
db2
DB2 Database Monitoring
Database
AC
IM
dcim
Data Center Infrastructure Management Monitoring
System
IM
dhcp_response
DHCP Server Response Monitoring
Network
IM Archive
dirscan
File and Directory Scan
System
AC
IM
discovery_agent
Discovery Agent
Service
AC
discovery_server
Discovery Server
Service
AC
diskstat
iSeries Disk Monitoring
System
AC
IM
distsrv
Distribution Server
Infrastructure
AC
IM
dns_response
DNS Response Monitoring
Network
AC
IM
e2e_appmon
E2E Application Response Monitoring
Application
AC
IM
easerver
EAServer
Application
IM Archive
ecometer
CA ecoMeter
Application
IM
emailgtw
Email Gateway
Gateway
AC
IM
email_response
Email Response Monitoring
Application
AC
IM
ems
Event Management Service
System
AC
ews_response
Microsoft Exchange Server Response Monitoring
Application
AC
IM
exchange_monitor
Microsoft Exchange Monitoring
Application
AC
IM
exchange_monitor_backend
Microsoft Exchange Monitoring Backend
Application
IM
exchange_monitor_reports
Microsoft Exchange Monitoring Reports
Installation
IM
fetchmsg
Retrieve QSYSOPR Messages on iSeries
System
AC
IM
file_adapter
File Adapter
Adapter
AC
IM
flow
Flow Analysis
Network
IM Archive
fsmounts
File Systems Mount Monitoring
System
AC
IM
google_app_engine
Google App Engine Monitoring
Application
IM Archive
google_apps
Google Apps Monitoring
Application
AC
IM Archive
group_server
Group Server
Infrastructure
IM Archive
ha
High Availability
System
AC
IM
hadoop_monitor
Hapdoop Monitoring
Application
AC
hdb
Robot Database Server
Service
IM
health_index
Health Index
SLM
AC
history
iSeries QHST Data Monitoring
System
AC
IM
hitachi
Hitachi Monitoring
Storage
AC
IM
hp_3par
HP 3PAR Storage Monitoring
Storage
AC
hpovsdgtw
HP OpenView SD Gateway
Gateway
IM Archive
hpsmgtw
HP Service Manager Gateway
Gateway
AC
IM Archive
httpd
Web Application
Infrastructure
IM Archive
hub
Hub
Infrastructure
AC
IM
hyperv
Microsoft Hyper-V Monitoring
Application
AC
IM Archive
ibm-ds
IBM Storage Monitoring
Storage
AC
IM
ibm_ds_next
IBM Disk Storage System 8000 Series Monitoring
Storage
AC
ibm_svc
IBM SVC Monitoring
Storage
AC
IM
ibmvm
IBM Virtualization Monitoring
Application
AC
IM
ica_response
Citrix Client Response Monitoring
Application
AC
IM
ica_server
Terminal Server
Application
IM Archive
icmp
Internet Control Message Protocol
Network
AC
iis
IIS Server Monitoring
Application
AC
IM
informix
Informix Database Monitoring
Database
AC Archive
IM Archive
interface_traffic
Interface Traffic Monitoring
Network
IM
iostat
Disk Activity Monitoring
System
IM Archive
jboss
Jboss Monitoring
Application
AC Archive
IM Archive
jdbc_response
Java Database Connectivity SQL Queries Response Monitoring
Database
AC
IM
jdbcgtw
Java Database Connectivity Gateway
Gateway
AC
IM
jmx
JMX Data Extractor
Application
IM
jobqs
iSeries Job Queues Monitoring
System
AC
IM
jobs
iSeries Job Monitoring
System
AC
IM
jobsched
iSeries Job Schedule Monitoring
System
AC
IM
journal
iSeries Journal Message Monitoring
System
AC
IM
jvm_monitor
Java Virtual Machine Monitoring
Application
AC
IM
ldap_response
LDAP Server Response Monitoring
Network
AC Archive
IM Archive
logmon
Log Monitoring
System
AC
IM
lync_monitor
Microsoft Lync Monitoring
Application
AC
IM
maintenance_mode
Maintenance Mode
Service
AC
mongodb_monitor
MongoDB Monitoring
Database
AC
monitoring_services
Monitoring Services
Service
AC
mpse
Monitoring Provisioning Service
Service
AC
mysql
MySQL Server Monitoring
Database
AC Archive
IM Archive
nas
Alarm Server
Infrastructure
IM
net_connect
Network Connectivity Monitoring
Network
AC
IM
netapp
NetApp Storage Monitoring
Storage
IM
net_traffic
Network Traffic Analyzer
Network
IM
netware
NetWare Server Monitoring
System
IM Archive
nexec
Command Execution Monitoring
Service
AC Archive
IM Archive
nfa_inventory
NFA Inventory
Gateway
AC
nis_server
NIS Server
Infrastructure
IM Archive
notes_response
Lotus Notes Client Response Monitoring
Application
AC
IM
notes_server
Lotus Notes Server Monitoring
Application
AC
IM
nq_services
NQ Services
Service
AC
nsdgtw
ServiceDesk Gateway Monitoring
Gateway
AC
IM
ntevl
NT Event Log Monitoring
System
AC
IM
ntp_response
Network Time Protocol Response Monitoring
Network
AC
IM
ntperf
Performance Collector Monitoring
System
AC
IM
ntperf64
Performance Collector Monitoring (64-bit)
System
AC
IM
ntservices
Windows NT Services Monitoring
System
AC
IM
ocs_monitor
Microsoft Office Communication Server Monitoring
Application
AC Archive
IM Archive
oracle
Oracle Database Monitoring
Database
AC
IM
outqs
iSeries Output Queue Monitoring
System
AC
IM
packageeditor
Package Editor
Infrastructure
IM
perfmon
System Performance Engine Monitoring
System
AC
IM
policy_engine
Policy Engine
Service
AC
power
Power Monitoring
Application
IM Archive
ppm
Probe Provisioning Manager
Service
IM
prediction_engine
Prediction Engine
SLM
AC
printers
Printer Monitoring
System
AC
IM Archive
processes
Process Monitoring
System
AC
IM
proxy
Proxy
System
IM Archive
pvs
PVS
Application
IM Archive
qos_processor
QoS Processor
SLM
IM
rackspace
Rackspace
Application
IM Archive
reboot
Reboot Computer
System
IM
remedy_response
Monitor Response Times to Remedy ARS
Application
IM Archive
remedygtw
Remedy Gateway
Gateway
IM Archive
report_engine
Report Engine
SLM
IM Archive
rhev
Red Hat Enterprise Virtualization Monitoring
Application
IM Archive
rsp
Remote System Probe
System
AC
IM
saa_monitor
Cisco IPSLA/SAA Monitoring
Network
IM Archive
salesforce
Salesforce Monitoring
Application
AC
IM Archive
sdgtw
Service Desk Gateway
Gateway
AC
service_host
Service Host
Service
AC
sharepoint
Microsoft SharePoint Server
Application
AC
IM
sla_engine
Calculates Service Level Agreements
SLM
IM
smsgtw
Short Message Service Gateway
Gateway
AC
IM
sngtw
ServiceNow Gateway
Gateway
AC
IM Archive
snmpcollector
SNMP Data Monitoring
Network
AC
snmpget
Simple Network Management Protocol Agent Data Monitoring
Network
IM
snmpgtw
SNMP Gateway
Gateway
IM
snmptd
SNMP Trap Daemon Monitoring
Gateway
IM
snmptoolkit
Simple Network Management Protocol Toolkit
Network
IM
spooler
Spooler
Infrastructure
AC
IM
sql_response
SQL Server Response Monitoring
Database
AC
IM
sqlserver
SQL Server Monitoring
Database
AC
IM
sybase
Sybase Monitoring
Database
AC
IM
sybase_rs
Sybase Replication Server Monitoring
Database
AC
IM
sysloggtw
System Log Gateway
Gateway
AC
IM
sysstat
iSeries System Statistics Monitoring
System
AC
IM
tcp_proxy
TCP/IP Proxy Service
Service
AC
IM Archive
temperature
Temperature
System
IM Archive
threshold_migrator
Threshold Migrator
Service
AC
tnggtw
Framework Integration for Unicenter TNG
Gateway
IM Archive
tomcat
Tomcat Server Monitoring
Application
AC Archive
IM Archive
topology_agent
Topology Discovery Agent
Service
IM
udm_manager
UDM Manager
Service
AC
ugs
Unified Grouping Service
Service
IM
url_response
URL Endpoint Response Monitoring
Application
AC
IM
usage_metering
Usage Metering
Service
IM
variable_server
Variable Server
Infrastructure
IM Archive
vcloud
vCloud Director Monitoring
Application
IM Archive
vmax
EMC VMAX Storage Systems Monitoring
Storage
IM Archive
vmware
VMware Monitoring
Application
AC
IM
vplex
EMC VPLEX Monitoring
Application
AC
wasp
Web Application Server Probe (previously named Web Application Service

Provider)
Service
AC
IM
webgtw
Web Gateway
Gateway
AC
weblogic
Weblogic Monitoring
Application
AC
IM
webservicemon
Webservice URL Monitoring
Application
AC
IM
webservices_rest
Web Service REST SDK
Service
IM
webservices_soap
Web Service SOAP SDK
Service
IM
websphere
WebSphere Monitoring
Application
AC
IM
websphere_mq
WebSphere MQ Monitoring
Application
AC
wins_response
Windows Internet Name Service Response Monitoring
Network
IM
xenapp
Citrix Xenapp Monitoring
Application
IM
xendesktop
Citrix Xendesktop Monitoring
Application
IM
xenserver
Citrix XenServer Monitoring
Application
IM
xmlparser
XML Parser
Adapter
IM
zdataservice
Data Service
Application
zones
Solaris Zones Monitoring
Application
IM
zops
Zops Monitoring
Application
IM
zstorage
zStorage Monitoring
Application
IM
zvm
ZVM Monitoring with Templates
Application
IM
agram shows the location of the navigation pane and details pane in the Admin Console probe configuration interface.
IM
The left navigation pane contains a hierarchical representation of the probe inventory which can include monitoring targets and configurable
elements.
The right details pane usually contains information that is based on your selection in the navigation pane.
Using the Search Function

Use the Search function in the Admin Console GUI to search for devices based on different criteria. After entering the first few characters in the
Search field, select the desired search options to further refine monitoring targets and configuration elements listed in the navigation pane.
Depending on the selected search option, you'll see a displayed message indicating the number of nodes matching the selected search option
(for example, Matches: 5).
Search field: Enter alphanumeric characters to display a list of nodes or locate a specific node that match the entered characters.
Auto-detect is employed in the Search field so you can enter the first few characters of a node's name or IP address and the search
function begins highlighting nodes that match the entered characters. Use of * (wildcard) is not supported.
Show Search Settings/Hide Search Settings: Displays or hides additional node search options. Search settings include:
Show only nodes publishing data: Highlights the device nodes in the navigation pane that have the Publish Data check box
selected on their profiles.
Show only nodes publishing alarms: Highlights the device nodes in the navigation pane that have the Publish Alarms check box
selected on their profiles
Hide unmatched branches: Removes all nodes that do not match the search criteria from the navigation pane. Click to remove the
check mark from this option and the unmatched nodes reappear in the navigation pane.
Scope filter to currently selected node: Finds nodes that match the search criteria underneath the currently selected node. For
example, use the search field to locate all nodes with the Publish Data check box selected on their profiles. Then select this option
and enter additional search criteria to further refine monitoring targets and configuration elements listed in the navigation pane within
the already located nodes.
Show only nodes with configuration (for templates only): Highlights the nodes in the navigation pane that have monitors configured
and included in a template.
General Probe Configuration Icons

The following table describes some of the icons you might see in the Admin Console probe configuration interface.
Icon
and
Name
Description
Help
Click to view probe-specific wiki articles or tooltips.
Open/Closed
folders
An organizational node in the probe inventory that groups related objects.

Click the triangle next to the folder to expand or collapse the contents.
Options
Click to view a list of actions you can perform related to the selected
object. The appearance and location of this icon can vary depending on
your version of CA Unified Infrastructure Management.
Profile or
Resource
A node in the probe inventory that groups related device components.

Click the triangle next to the folder to expand or collapse the contents.
or
This icon can indicate the status of subcomponent discovery:
- Discovery of
subcomponents is complete
- Discovery of
subcomponents is in progress
- Unknown error
- Discovery of
subcomponents failed
How To Articles
These are common how to articles for probes that are typically completed by CA UIM administrators.
Configuring Alarm Thresholds

This article explains how to configure the options that allow monitoring probes to indicate to baseline_engine (or other probes performing a similar
computational function) to compute baselines, publish QoS data to the message bus, and publish alarms when configured alarm threshold criteria
is met.
Contents
Configuring Baselines
Publishing QoS Data
Supported Threshold Types
Running the threshold_migrator Probe
Variable Substitution Supported with ppm 3.20
Configuring Dynamic Alarm Thresholds
For Hubs Running ppm v3.11 and later
For Hubs Running ppm v3.0
Configuring Static Alarm Thresholds
Configuring Time Over Threshold
Configuring Time To Threshold
Create Baselines for Probes Without Using the Web-based GUI
Hubs Running ppm v3.11 and later
Hubs Running ppm v2.38 and v3.0
Create Thresholds for Probes Without Using the Web-based GUI
Configuring Baselines
The baseline_engine probe calculates and provides a baseline for all monitoring QoS metrics in the UIM domain that it belongs to using the
following process:
1. The baseline_engine probe listens for messages with the subject QoS on the message bus.
2. When the Compute Baseline check box is selected for a QoS metric in a monitoring probe GUI, the baseline_engine samples the QoS
data up to 30 times during each interval. This sampling rate provides a statistically accurate baseline while minimizing system resource
use.
3. At the top of each hour, baseline_engine calculates a baseline data point for each QoS monitor that has Compute Baseline enabled.
4. baseline_engine sends the data points to the qos_processor probe, which processes the data and writes it to the UIM database.
Publishing QoS Data

To enable a robot to send a monitoring probe's QoS data to the message bus, there are a few configuration settings required. Depending on the
version of CA UIM you're running and what's being monitored, select one or more of the following check boxes.
Publish Alarms - allows the probe, or the baseline_engine and/or prediction_engine (on behalf of the probe), to generate dynamic,
static, and predictive alarms. These alarms appear on CA Unified Service Manager or Infrastructure Manager.
Publish Data - publishes QoS data from monitoring probes to the UIM message bus.
Compute Baseline - allows the probe, or the baseline_engine and/or prediction_engine (on behalf of the probe), to compute hourly
baselines based on QoS data.

The following threshold limit types are currently supported:
Static - Alarms are sent when the configured time requirements for a QoS metric have exceeded the threshold. A static threshold is effectively a
high pass filter.
Note: If a probes do not support static alarms, you might see an Alarm Thresholds configuration section at the top of the page.
Dynamic - A dynamic threshold is calculated on variance from the calculated static baseline with no averaging. Variances can be set to one of the
following algorithms:
Scalar - A set value past the calculated baseline.
Percent - A set percent past the baseline.
Standard Deviation - A set standard deviation past the baseline.
Running the threshold_migrator Probe

With UIM 8.2, a new threshold_migrator probe is available to facilitate the process of migrating probes to include the standard static alarm
threshold parameters. After migrating probes, the alarming function will be removed from the probe, and baseline_engine will become responsible
for generating static alarms (as well as dynamic, Time Over Threshold, and Time To Threshold alarms) when user-configured thresholds are
breached.
After you run the threshold_migrator for a probe, configuration thereafter will always be performed by using Admin Console rather than
Infrastructure Manager. The probe's configuration will no longer be available in Infrastructure Manager and you cannot revert back to the previous
version of the probe's configuration.
When you access the migrated probe's GUI in Admin Console, you'll see the settings that were previously configured for the probe migrated to the
appropriate static alarm fields.
Note: Before you use the threshold_migrator probe, the latest version of the probe must be deployed to each target device.
For more information about using the threshold_migrator probe and the probes that can be migrated, go to the threshold_migrator (Threshold
Migrator) article.

For some probes, you configure general alarm threshold settings and dynamic alarm thresholds settings, while other probes include a section to
configure static alarm thresholds in addition to dynamic alarm thresholds. Use the following information to configure alarm thresholds, when
required.
Configure the unit of measure based on the aspect of a device the probe is monitoring. For example, when configuring Disk Usage
monitoring with the cdm probe, enter either percent or MBytes for the Send Alarm Based on Threshold setting.
Qualify the type of threshold. Configuration parameters available for different probes include the following:
Enable the highthreshold and/or lowthreshold options to indicate whether either threshold or both thresholds should be evaluated.
When the high and low threshold options are enabled, the high threshold is evaluated first and if it is not exceeded, then the low
threshold is evaluated.
Select an operator value. This value can be greater than, less than, equal to or combinations of these values (for example. greater
than or equal to).
If applicable, select a direction which can be either increasing or decreasing. The direction setting indicates an alarm occurs when
monitored QoS data is greater than or lower than the set threshold.
For each threshold enabled, enter a threshold value.

For each threshold enabled, select the alarm message to be displayed on CA Unified Service Manager or Infrastructure Manager when
monitored QoS data is lower, equal to, or higher than the configured threshold value.
Variable Substitution Supported with ppm 3.20

For some of the text string fields (such as the Custom Alarm Message field), you can enter the key identifier ${ and select variables from a
drop-down list, or you can type a variable. Selecting a variable from a drop-down list makes it easier to supply the correct variable name for a
custom message.
For example, for many of the elements monitored by the cdm probe, you can enter a Custom Alarm Message and Custom Alarm Clear Message.
You can either type the variable name ${qos_name} in the text field, or you can type the key identifier ${ and select qos_name from the
drop-down list. After you enter or select a variable, the actual value for the variable is provided by the baseline_engine when an alarm is
generated by the monitoring probe.
You can select one or more variables for a text string field, as shown in the following sample custom alarm message:
${qos_name} from source ${source} that is targeting ${target} is

${operator} the threshold of ${threshold}.
Note: If you enter ${ and select a variable for a text field where the variables are displayed but not applicable (for example, the
Subsystem field) the system ignores the variable.
Follow these steps:

1. Go to a text string field and enter: ${
A drop-down list of variables the baseline_engine substitutes or probe-specific variables display.
2. Select a variable.
baseline_engine attribute variables have the format ${<variable_name>.
3. Configure the remaining settings and then save your changes.
Configuring Dynamic Alarm Thresholds

Dynamic alarm thresholds can be set at the QoS metric level in probes that publish alarms for a QoS metric.
Important! In order to create dynamic alarm thresholds, you must have the baseline_engine probe version 2.0 or later installed on the
hub robot and configured.
To set a Dynamic alarm, determine the version of the ppm probe running on the hub robot and complete one of the following procedures:
Hub robots running ppm v3.11 and later
Hub robots running ppm v3.0

Follow these steps:
1. In the probe GUI, select a node in the tree to view any associated monitors and QoS metrics.
2. Select the monitor that you want to modify from the available list.
3. Click the Publish Data, Publish Alarms (if available), and Compute Baseline check boxes.
3.
Note: If you cannot select the Compute Baseline check box, click
deployed or activated.
to determine if the baseline_engine needs to be
4. Click the Dynamic Alarm check box. The Dynamic Alarm options become available.
5. Choose an Algorithm to use:
Scalar - Each threshold is a specific value from the computed baseline.
Percent - Each threshold is a specific percentage of the computed baseline.
Standard Deviation - Each threshold is a measure of the variation from the computed 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.
6. Choose an operator for the threshold:
> An alarm occurs when the metric is greater than the set threshold.
>= An alarm occurs when the metric is greater than or equal to the set threshold.
< An alarm occurs when the metric is below the set threshold.
< = An alarm occurs when the metric is below or equal to the set threshold.
= An alarm occurs when the metric is equal to the set threshold.
!= An alarm occurs when the metric is not equal to the set threshold.
7. Set the threshold for each alarm state.
8. (Optional) Enter a different (overriding) Subsystem ID using the Subsystem (override) field. This is only required if the Subsystem ID
shown in the Subsystem (default) field is not correct for your configuration.
This option is available with baseline_engine 2.1 or later.
9. (Optional) Create a custom alarm message for your environment:
a. In the Custom Alarm Message field, enter or select variables (see variable substitution for details) to include in a custom message.
The available variables are:
${baseline} - The baseline calculated for a QoS metric if the Compute Baseline option is selected for the metric. Baselines are not
calculated for static messages, so this value will always be zero for static alarms.
${level} - The numerical severity level of the alarm. Valid values are: 1 (critical), 2 (major), 3 (minor), 4 (warning), or 5 (information)
${operator} - The operator (>, >=, <, <=, ==, or !=) for the alarm severity level.
${qos_name} - The name of the QoS metric.
${source} - The source of the QoS metric that generated an alarm.
${target} - The target of the QoS metric that generated an alarm
${threshold} - Specifies the threshold upon which an alarm is generated.
${value} - Specifies the value contained in the generated QoS message.
b. In the Custom Alarm Clear Message field, enter the message displayed when the alarm and the source of the alarm is returned to a
normal state.
The available variables include:
10. Save your settings.

Follow these steps:
3. Click the Publish Data, Publish Alarms (if available), and Compute Baseline check boxes.
Note: If you cannot select the Compute Baseline check box, click
deployed or activated.
to determine if the baseline_engine needs to be
4. Click the Dynamic Alarm check box. The Dynamic Alarm options become available.
5.
computed baseline.
Greater than (>) - An alarm occurs when the metric increases past the set threshold.
Less than (<) - An alarm occurs when the metric falls below the set threshold.
If you are using baseline_engine 2.1 or later, you can also change the Subsystem ID using the Subsystem (override) field. This is only required
if the Subsystem ID shown in the Subsystem (default) field is not correct for your configuration.

Follow these steps:
3. Click the Publish Data box.
4. Click the Compute Baseline box. The Dynamic Alarm Thresholds section is enabled.
5. Change the drop-down in the Dynamic Alarm Thresholds section from None to Dynamic. The Dynamic Alarm Threshold section
expands and more options become available.
computed baseline.
7. Choose a direction for the threshold:
Increasing - An alarm occurs when the metric increases past the set threshold.
Decreasing - An alarm occurs when the metric falls below the set threshold.
If you are using baseline_engine 2.1, you can also change the Subsystem ID using the Subsystem (override) field. This is only required if the
Subsystem ID shown in the Subsystem (default) field is not correct for your configuration.
Configuring Static Alarm Thresholds

Static alarm thresholds can be set at the QoS metric level in some of the probes that publish alarms for a QoS metric. There are different ways to
configure static alarm thresholds. The following procedures explain the configuration settings used for many of the commonly used probes.
Important! In order to create dynamic alarm thresholds, you must have the baseline_engine probe version 2.0 or later installed on the
hub robot and configured.
To set a Static alarm, determine the version of the ppm probe running on the hub robot and complete one of the following procedures:

Follow these steps:
Click the Publish Data and Publish Alarms check boxes.
3. Click the Static Alarm check box. The Static Alarm options become available.
Note: If you cannot select this check box, click
to determine if baseline_engine needs to be deployed or activated.

< An alarm occurs when the metric is below the set threshold.
< = An alarm occurs when the metric is below or equal to the set threshold.
Note: If you used the threshold_migrator probe to add the static threshold fields for a probe, the operator and configured
threshold are carried over.

6. (Optional) Enter a different (overriding) Subsystem ID using the Subsystem (override) field. This is only required if the Subsystem ID
shown in the Subsystem (default) field is not correct for your configuration.
This option is available with baseline_engine 2.1 or later.
7. (Optional) Create a custom alarm message for your environment:
a. In the Custom Alarm Message field, enter or select variables (see variable substitution for details) to include in a custom message.
The available variables are:
${baseline} - The baseline calculated for a QoS metric if the Compute Baseline option is selected for the metric. Baselines are not
calculated for static messages, so this value will always be zero for static alarms.
${level} - The numerical severity level of the alarm. Valid values are: 1 (critical), 2 (major), 3 (minor), 4 (warning), or 5 (information)
${operator} - The operator (>, >=, <, <=, ==, or !=) for the alarm severity level.
b. In the Custom Alarm Clear Message field, enter the message displayed when the alarm and the source of the alarm is returned to a
normal state.
The available variables include:

Follow these steps:
3. Click the Publish Data and Publish Alarms check boxes.
4. Click the Static Alarm check box. The Static Alarm options become available.
4.
to determine if baseline_engine needs to be deployed or activated.

Greater than (>) - An alarm occurs when the metric increases past the set threshold.
Less than (<) - An alarm occurs when the metric falls below the set threshold.
If you are using baseline_engine 2.1 or later, you can also change the Subsystem ID using the Subsystem (override) field. This is only required
if the Subsystem ID shown in the Subsystem (default) field is not correct for your configuration.

Follow these steps:
3. Click the Publish Data box.
4. Change the drop-down in the Static Alarm Thresholds section from None to Static.
5. Choose a direction for the static threshold:
Increasing - An alarm occurs when the metric is greater than the set threshold.
Decreasing - An alarm occurs when the metric falls below the set threshold.
7. (Optional) If the Subsystem ID listed in the Subsystem (default) field is not correct for your configuration, enter the correct ID in the Sub
system (override) field.

Time Over Threshold (TOT) is an event processing rule that allows you to reduce the number of alarms that are generated when threshold
violation events occur.
To use Time Over Threshold, you must have the following probe versions installed at each hub level where Time Over Threshold functionality is
desired:
alarm_enrichment 4.40 or later
baseline_engine 2.34 or later
nas 4.40 or later
Probe Provisioning Manager (PPM) 2.38 or later
prediction_engine 1.01 or later
To configure a Time Over Threshold alarm, determine the version of the ppm probe running on the hub robot and complete one of the following
procedures:

Follow these steps:
3.
3. Click the Publish Data, Publish Alarms, and Compute Baseline (for a dynamic alarm) check boxes.
4. Click either the Dynamic Alarm or Static Alarm check box.
Note: If you cannot select either of these check boxes, click

activated.
to determine if baseline_engine needs to be deployed or
5. Configure the dynamic or static alarm settings. See dynamic alarms or static alarms for details.
6. For either a dynamic or static alarm, select the Enable Dynamic Time Over Threshold or Enable Static Time Over Threshold check
box.
7. Enter values for the following fields:
Time Over Threshold <TOT> - The length of time a metric must remain over threshold before an alarm is sent.
Sliding Time Window <TW> -The length of time in the sliding window in which metrics are monitored for threshold violations.
Time Units for <TOT> and <TW> - The unit of measurement used by the Time Over Threshold and Time Window parameters.
Limited to minutes, hours, or days.
Automatically Clear Alarm - Enables the Auto-clear functionality.
Clear Delay Time - The length of time used in the Auto-clear timer. If no alarms are sent in the set time period, the alarm is
automatically cleared.
Time Units for <TC> - The unit of measurement used by the Auto-clear. Limited to minutes, hours, or days.
8. Save your changes.
The following changes will take effect immediately:
New Time Over Threshold rules.
Changes to the Clear Delay Time parameter.
Changes to the Time Over Threshold active state.
The following changes will take effect at the next received alarm:
Changes to the Time Over Threshold parameter.
Changes to the Sliding Time Window parameter.

Follow these steps:
1. Select the Publish Data and Compute Baseline check boxes.
2. Configure a dynamic or static alarm threshold.
box.


Time To Threshold is set at the QoS metric level in the probes that publish alarms for QoS metrics.
To use Time To Threshold, you must have the following probe versions installed at the secondary hub level:
Probe Provisioning Manager (ppm) 2.38 or later
To configure a Time To Threshold alarm, determine the version of the ppm probe running on the hub robot and complete one of the following
procedures:

Follow these steps:
3. Select the Publish Data and Publish Alarms (if available) check boxes to publish QoS data from monitoring probes to the message bus.
4. (Optional) Select the Compute Baseline check box if you want baseline_engine to compute hourly baselines based on QoS data.
to determine if the baseline_engine needs to be deployed or activated.
5. Select the Time To Threshold Alarm check box to configure a Time To Threshold alarm.
to determine if the prediction_engine needs to be deployed or activated.
6. Configure the alarm settings.

Time Units: select days or hours as the unit of time.
Prediction Value: an appropriate value for the QoS metric. For example, 50 to indicate the percent for Disk Usage.
Alarm Severity: level of alarm generated.
Critical Level 5
Major Level 4
Minor Level 3
Warning Level 2
Information Level 1

Follow these steps:
3. Select the Publish Data check box to send the QoS data.
Note: You must select the Publish Data check box before you can configure the Time To Threshold settings.
4. Select Time To Threshold Alarm in the Predictive Alarm drop-down menu.

5. Configure the predictive alarm settings.
Time Threshold: enter a number to indicate the number of hours or days within reaching the configured prediction value.
Time Units: select days or hours as the unit of time.
Prediction Value: an appropriate value for the QoS metric. For example, 50 to indicate the percent for Disk Usage.
Alarm Severity: level of alarm generated.
Critical Level 5
Major Level 4
Minor Level 3
Warning Level 2
Information Level 1
Create Baselines for Probes Without Using the Web-based GUI

Instead of using a probe's GUI, you can enter a command and run it from <baseline_engine_dir> to allow the baseline_engine to generate
baselines and thresholds for a monitoring probe.

Use the following commands to set baselines or thresholds for probes.
Note: Run these commands from <baseline_engine_dir>.
To set up baselines for probes without using the web-based configuration, use the following command:
java -cp ".;lib/*" com.nimsoft.threshold.cmd.ThresholdSetter -user <user> -pwd

<password> -probe <path> -f <file name> [-queue]
Note: For linux or unix the path is ".:lib/*"
The options are:

user: The user name
pwd: The password
probe: The path to the baseline_engine probe, for example /domain/hub/robot/baseline_engine.
f: The name of file containing the threshold definitions to load. This file should be in the same format as the thresholds.cache file.
queue: Indicates to send configurations over the BASELINE_CONFIG queue instead of using callbacks.

To set up baselines for probes without the web-based configuration use the following command:
java -cp ".;lib/*" com.nimsoft.threshold.cmd.BaselineSetter -user <user> -pwd

<password> -probe <path> -o <add | delete> [-f <file name> | -id <metricId> ]
[-native] [-queue]
Note: For linux or unix the path is .:bin/*
The options are:

user: The user name
pwd: The password
o: The operation, which can be either add or delete.
f: The name of the file that contains the baseline specifications. If -f is specified, the baseline specifications are listed in the file's fileName
using the format: metricset.txt.file. If -f is not specified, the -id parameter is required.
id: The metric ID of the QoS to baseline.
native: Baseline the QoS using the probe's native sample frequency.
Create Thresholds for Probes Without Using the Web-based GUI

To set up thresholds for probes without the web-based configuration use the following command:

<password> -probe <probepath> -id <metric id> -threshType <static | dynamic> -type
<percent | scalar | stdev> -o <operator> [ -operator1 <operator> | -operator2
<operator> | -operator3 <operator> | -operator4 <operator> | -operator5 <operator> ] [
-level1 <value> | -level2 <value> | -level3 <value> | <-level4> <value> | -level5
<value> ] -subsysId <subsysId> [ -customAlarmMessage <message> ] [
-customClearAlarmMessage <message> ] [ -queue ]
The options are:

user: The user name
pwd: The password
threshType: The type of threshold, which is either static or dynamic.

Static: No alarms are sent sent until sufficient alarms meeting the time requirements have exceeded the threshold.
Dynamic: A dynamic threshold is calculated on variance from the calculated static baseline with no averaging. Variances can be set to
one of the following algorithms
id: The metric ID of the QoS for which thresholds are being defined.
type: The algorithm used to calculate the variance from the calculated baseline. Options are:
Scalar: A set value past the calculated baseline.
Percentage: A set percentage past the baseline.
Standard Deviation: A set standard deviation past the baseline.
o: One of the following operators:
L: less than
LE: less than or equal to
G: greater than
GE: greater than or equal to
EQ: is equal
NE: is not equal
operator1 <operator>: operator1 takes precedence over <operator>
Note: If you specify one operator, you must specify all operators.
level1: Sets the level1 information alarm threshold value.

level2: Sets the level2 warning alarm threshold value.
level3: Sets the level3 minor alarm threshold value.
level4: Sets the level4 major alarm threshold value.
level5: Sets the level5 critical alarm threshold value.
Note: The alarm threshold values are generated in the format 50.0 (for 50%). To generate an alarm, you must specify at least
one level alarm threshold value.
subsysId: The subsystem ID of the QoS for which the thresholds are being defined. Only one subsystem ID can be specified using the
subsysId option.
threshID (Optional): Unique ID which distinguishes between multiple thresholds of the same threshType and id (metric ID).
delete: Remove the threshold identified by the id (metric ID), threshType, and threshID.
customAlarmMessage: A custom alarm message generated as the alarm message when a threshold is breached. Variables include:
${baseline} - The baseline calculated for a QoS metric if the Compute Baseline and Dynamic Alarm options are selected for the metric.
Baselines are not calculated for static messages, so this value will always be zero for static alarms.
${level} - The numerical critical level of the alarm. Valid values are: 1 (critical), 2 (major), 3 (minor), 4 (warning), or 5 (information)
${operator} - The operator (>, >=, <, <=, ==, or !=) for the critical level of the alarm.
${value} - Specifies the value contained in the generated QoS metric.
EXAMPLE: -customAlarmMessage ${qos_name} is at ${value}
customClearAlarmMessage: A custom alarm message generated when the alarm and the source of the alarm are returned to a normal
state. Variables include:



<password> -probe <path> -id <metric id> -threshType <static | dynamic> -type <percent
| scalar | stdev> -o <operator> [-level1 <value> | -level2 <value> | -level3 <value> |
-level4 <value> | -level5 <value>] -subsysId <subsysId> [-queue]
The options are:

user: The user name
pwd: The password
type: The type of algorithm, which can be percent, scalar, or standard deviation.
L: less than
G: greater than
subsysId option.
More Information:
prediction_engine probe article
Set Up Automated Usage Metering and Billing
Automated Usage Metering and Billing is an automated billing process for customers who have:
Licenses based on quantity and minimum commitment (Min-Commit) subscriptions, or
Non-subscription contracts that require periodic auditing for renewals
In the past, customers installed a CA subscription file into their UIM monitoring environment, deployed the usage_metering probe across the
environment, and manually ran the billing probe to collect the information generated by usage_metering. This generated a monthly Billing Report
that customers emailed to CA Sales. Along the way, configuration issues were common, and customers often had to manually collect the storage
capacity information and enter it into the report.
The new Automated Usage Metering and Billing process automates these workflows and eliminates the manual intervention required to upload a
report to CA. To deliver reports, users can either "opt-in" to enable the automatic transfer of billing reports to CA via a secured web gateway
channel, or manually email the reports, which are always stored locally.
This article provides:
An overview of the automated billing process.
Set-up instructions:
1. Meet the prerequisites
2. Deploy webgtw and ppm
3. Configure webgtw
4. Deploy or upgrade usage_metering (if necessary)
5. Deploy or upgrade billing
Instructions on using this process with earlier versions of Nimsoft Monitor.
Automated Billing Process

The automated process works as follows:
1. The usage_metering probe(s) scan your UIM environment to identify usage items within the managed environment.
2. The billing probe collects usage item data from all the usage_metering instances in the environment, performs the calculations required to
generate a billing report, and creates the report. Note that:
The billing probe runs once a week and on the first day of the month at the configured time (default is 2:00 AM) to retrieve usage
metering data and generate a report.
The weekly report shows the progression of usage over the month. The monthly report shows total usage for the previous month.
The reports contain customer information fetched from the webgtw configuration.
All reports are saved in a local folder, stored in the UIM database, and delivered to CA.
3. Immediately after it creates the report, the billing probe delivers the report as a payload for webgtw.
4. Webgtw emails the report to CA.
5. The CA account representative reviews the report and contacts the customer to discuss any overages.
6. CA issues an invoice.
Prerequisites
Before you configure this process, you must:
Ensure your environment has been upgraded to NMS 7.5 or later, or to UIM Server 8.0.
Download the following probes from the web archive to your local archive:
billing 8.00 or later
This package includes the current and prior versions of the subscription files.
webgtw 8.00 or later
ppm 2.39 or later
usage_metering 8.00 or later
Although billing 8.00 is compatible with usage_metering 2.11, usage_metering 8.00 has device
extraction enhancements and is recommended for upgrade.
Obtain your Customer_ID from CA (a 4- to 8-digit number). You need this number to configure the webgtw probe.
Your Customer_ID was emailed to you with your introduction to this new process. If you have not received yours, please send a
request to nimsoftinquiries@ca.com.
Deploy Webgtw and PPM

Webgtw v8.0 and later generates a unique Instance ID and contains the company information that you enter during configuration. These items are
automatically included in your billing reports. CA recommends you deploy and configure webgtw even if you choose not to automatically transfer
of your reports.
PPM v2.39 or later provides the webgtw configuration GUI.
To deploy webgtw and ppm, follow these steps.
1. Determine which robot will host the web gateway probe. If you plan to opt-in to automatic billing report transfer, this system must either:
Have direct access to the internet via https port 443, or
Be able to use a designated proxy server.
2. Using Admin Console, deploy webgtw 8.0 to that robot.
3. The webgtw probe starts, then creates an instance_id, a globally unique ID (GUID) for your UIM Server installation. This ID is used to
identify your reports to CA.
4. Deploy ppm 2.39 to the system that hosts Admin Console (typically the primary hub).
If either webgtw or ppm does not automatically start, activate the probe manually.
Deployment is complete.
Configure Webgtw
Follow these steps.
1. Log in to Admin Console and open the webgtw probe configuration GUI.
2. On the Contact Information node:
Instance ID is your system-generated GUID (read-only).
Customer ID (provided in your initial email from CA), Company name and Contact email address are optional. If you enter the
information here, it is automatically included in your reports.
Terms of Use must be accepted (select Actions > View Terms of Use Agreement to display the terms).
Accepting the terms is the "opt-in" action that enables automatic report transfer. If Terms of Use is not checked, no HTTP
I/O is allowed, and you will need to manually email your reports to CA.
3. If necessary, specify Proxy Configuration:

Specify the proxy server, port, and user credentials.
Select Actions > Ping Test.
Select Actions > Test your proxy configuration.
4. Click Save.
Configuration is complete.
Deploy or Upgrade Usage Metering (if necessary)
The usage_metering probe scans your UIM environment to identify the devices you are monitoring. The results are retrieved by the billing probe,
which must reside on the same robot as usage_metering.
If usage_metering is already deployed in your UIM environment, you do not need to upgrade. Older versions of the UM probe are compatible with
the new process and will provide consistent data for the billing probe. However, CA recommends that you upgrade all instances of the probe to
version 8.0 or later to take advantage of performance improvements.
If you need to:
Upgrade usage_metering, deactivate the billing and usage_metering probes before you upgrade.
Deploy usage_metering, consider the following:
An instance of usage_metering must reside on the same robot as the billing probe. This is called the primary instance.
The probe must perform DNS resolution to uniquely identify a probe's device references. In many cases, the DNS needed to correctly
resolve a device reference is not available to the primary instance. To address this, deploy a secondary instance to a hub that can
access a DNS.
Once usage_metering is deployed, no further configuration is required.
For more information on usage_metering, refer to usage_metering on the CA Unified Infrastructure Management Probes site.
Deploy or Upgrade Billing

The billing probe collects usage item data from usage_metering, then performs the calculations required to generate a billing report.
If billing is has not been deployed or upgraded, deploy billing 8.0. In most environments, billing is deployed to the primary hub; however, it can be
deployed to a secondary hub. For more information on usage_metering, refer to billing on the CA Unified Infrastructure Management Probes site.
Note the following:
Older versions required you to import a subscription file. This is no longer required. The latest subscription files are packaged with the
new version and are used automatically.
As of version 8.0, the billing probe either retrieves the customer name from the webgtw probe or derives it from a legacy billing report. If
webgtw is not active and no legacy reports exist, you will need to manually enter the customer name in the report header.
In most environments, billing is deployed to the primary hub; however, it can be deployed to a secondary hub. See the billing probe
configuration document for more information.
Configuration is not required. By default, the probe runs at 2:00 AM local time once per week, and again on the first day of each month to
generate the report for the prior month.
Billing 8.0 is configured with the Raw Configure utility. To configure earlier versions, use Infrastructure Manager. Configuration via Admin
Console will be available in a future release.
In a future version, CA plans to have webgtw post an informational alarm when the billing report is sent. This notification audit the report
by viewing the file saved on the file system, and if desired contact the Sales Account Rep to discuss the findings. In the mean time you
will need to use your favorite means of reminding yourself to review the published reports.
Maintenance
As they become available, CA recommends you download and deploy new versions of these probes. This gives you the latest subscription files
and ensures that you benefit from improvements made to the probes.
Setting up Automated Billing in Older Deployments

The 8.0 versions of the billing, webgtw and usage_metering probes are compatible with prior versions of Nimsoft Monitor. However, the webgtw
probe does not have a configuration GUI in prior releases, so you cannot accept the terms of use or enter an encrypted password. To work
around these limitations, follow these steps:
1. Create a webgtw configuration file on a virtual machine:
a. Install UIM Server 8.0 on a virtual machine.
b. Start the webgtw probe on the VM.
c. Use Admin Console to enter Proxy Server credentials, read and accept Terms-of-Use, enter Customer Contact info, and enter
Customer ID. Close the GUI.
2. Copy webgtw.cfg (the webtgw probe configuration file) to the production robot where webgtw is deployed.
The production robot now has a unique Instance ID and an encrypted password for webgtw. Because the terms-of-use are accepted, the opt-in
option is accomplished.
Configure a Robot for Marketplace Probes

It is recommended that marketplace probes:
Run on a passive robot (for security reasons). Passive robots do not send messages to the hub; messages are sent only at the hubs
request. Robots can be configured as passive during installation, or converted from active mode to passive mode.
Be run by a non-superuser. The marketplace user should be an OS account user.
Marketplace probes run with the same OS permissions as the marketplace user. If a marketplace user is created with missing or invalid
information then the marketplace probes will not run. If the marketplace user is changed then the marketplace probes will restart and the new
marketplace user permissions will be used.
The sections in this article explain how to configure a robot to create this restricted environment.
When robot configuration is complete, you can deploy marketplace probes to the robot.
Install a Passive Robot and Connect it to a Hub

This section contains robot installation instructions and explains how to connect the new robot to a parent hub.
Optionally, you may want to adjust robot-to-hub communication. By default, the parent hub requests messages from a passive robot
every 15 seconds and allows up to 1000 messages per interval.
Follow these steps:

1. Install a passive robot. For instructions, go to Deploy Robots and refer to the appropriate section.
To install a single Windows passive robot, run the installer as instructed in "Installing a Robot on Windows." The robot installer's Optio
ns dialog allows you to select Passive mode.
To install a single Unix passive robot, run the nmldr utility as instructed in "Installing Robots and Secondary Hubs on Linux or Solaris."
When the installer asks Should this robot run in passive mode?, reply yes.
To install one or more passive robots as part of an XML bulk deployment, see "Deploying Robots in Bulk." In the XML file, add the
following line for each system that will host a passive robot:
<robot_mode>passive</robot_mode>
2. Add the robot to the hub's registered robots list:
a. In Infrastructure Manager, navigate to the hub that will manage the passive robot.
b. Display the hub's probes, then right-click the hub probe and select Configure.
c. Select the Robots tab.
d. Right-click in the Registered Robots pane and select Add Passive Robot.
e. Enter the robots IP address and first probe port (default is 48000).
f. Click Verify, then click OK to exit the dialogs.
The passive robot is installed, and its parent hub is configured to request messages from the robot. Before you deploy marketplace packages to
the robot, make sure you specify the marketplace user.
Change an Active Robot to Passive Mode

This section explains how to change the mode of an existing robot, disconnect it from its hub, and reconnect it as a passive robot.
Follow these steps:
Note: You need the passive robot's IP address in this procedure.
1.
1. Log on to Infrastructure Manager.

2. Change the robot from active to passive mode:
a. In the navigation tree, locate the active robot and display its probes.
b. Right-click the controller probe and select Configure.
c. In Controller Configuration, navigate to Setup > Misc.
d. Set the Robot mode to Passive - must be contacted by hub, then click OK.
3. Remove the robot from hub registered robots list:
a. Navigate to the hub that manages the robot, then navigate to the hub probe.
b. Right-click the hub probe and select Configure.
c. Select the Robots tab.
d. In the Registered Robots pane:
Make a note of the robots IP address.
Right-click on the robot and select Remove.
4.
Add the passive robot to hub registered robots list:

a. In the Robots tab, right-click in the Registered Robots pane and select Add Passive Robot.
b. Enter the robots IP address and first probe port (default is 48000).
c. Click Verify, then click OK to exit the dialogs.
The robot is now in passive mode, and its parent hub is configured to request messages from it. Before you deploy marketplace packages, you
must specify the marketplace user.
Specify the Marketplace User

This section provides instructions to create a marketplace user (non-root user) that will run marketplace probes.
Tip: To simplify administration, CA recommends you create a user account specifically for this purpose, and create the same account on all
systems that will run marketplace probes.
Ensure that the OS user that you use as the marketplace user has file access permissions to the marketplace probe directory. You want
to verify that the marketplace user does NOT have file access to other non-marketplace probe directories, for security reasons. The
marketplace probe is designed to operate as a sandbox with access permissions only to its own files.
Follow these steps:

1. Log in to Admin Console.
2. Navigate to the robot that will manage a marketplace probe and display its probes.
3. Open the controller configuration UI.
4. Select Setup in the left navigation and scroll to the marketplace settings.
5. Enter the Marketplace Username and Password.
Notes:
The password is only required on a Windows robot. The password is visible when you enter it. The username and password
are encrypted in the configuration file.
The Windows user must have "log on as batch job" permissions.
6. Click Save.
The robot configuration for marketplace probe deployment is complete. If you want to adjust the hub-to-robot communication (optional), you can
modify communication settings for passive robots.
Set Up adogtw Network Transaction Logging

This example describes how to set up the adogtw log network transactions to a table in a database. In this example, we assume that the table Ala
rmTransactionLog is created in the database.
1. Add a connection to the database.
2. Add a new profile and select Subscribe.
3. Click the General tab and select the connection that you created.
4. Click the Subscribe tab and select Subject as nas_transaction and Table as AlarmTransactionLog.
5. Activate the profile, save it, and watch the table gets filled.
The Time Over Threshold Event Rule

Contents
Prerequisites
Time Over Threshold Workflow
Alarm Suppression During Time Over Threshold
Alarm Clear Conditions Using Time Over Threshold
Alarm Severity Changes During Time Over Threshold
Additional Time Over Threshold Scenarios
Best Practices for Time Over Threshold
Configure Time Over Threshold
Troubleshooting Time Over Threshold
I see Errors Regarding alarm_enrichment
The Time Over Threshold Configuration Parameters are Unavailable
Prerequisites
To use Time Over Threshold, you must have the following probe versions installed at each hub level where Time Over Threshold functionality is
desired:
alarm_enrichment 4.40 or later
nas 4.40 or later
Time Over Threshold (TOT) is an event processing rule that allows you to reduce the number of alarms that are generated when threshold
violation events occur. You can use Time Over Threshold to filter out data spikes and monitor problematic metrics over a set period. Instead of
sending an alarm immediately after a threshold violation has occurred, Time Over Threshold:
Monitors the events that occur during a user-defined sliding time window.
Tracks the length of time that the metric is at each alarm severity.
Raises an alarm if the cumulative time the metric is in violation during the sliding window reaches the set Time Over Threshold.
Example: Time Over Threshold in a Consecutive Block
This example uses the following settings:
Sliding Window: 30 minutes.

Time Over Threshold: 10 minutes.
Auto-Clear: Not set.
Alarm Severities: Clear, Information, Warning, Minor, Major, and Critical alarm thresholds are set in the probe GUI.
The Time Over Threshold does not have to occur consecutively within a sliding time window. All of the time in a sliding window is counted toward
the Time Over Threshold.
Example: Time Over Threshold in a Nonconsecutive Block
Alarm Severities Set: Clear, Information, Warning, Minor, and Major alarm thresholds are set in the probe GUI.
Time Over Threshold Workflow
1. The baseline_engine probe evaluates QoS metrics from probes against static and dynamic threshold definitions.
2. The baseline_engine probe generates threshold violation messages when thresholds are crossed.
3. The nas probe implements the Time Over Threshold event processing rule to filter out data spikes. This event processing produces a
more accurate reflection of threshold violation behavior.
Alarm Suppression During Time Over Threshold

After a metric reaches a Time Over Threshold state, an alarm is generated for each additional threshold violation. By default, these duplicate
alarms will increase the suppression count for the alarm, but will otherwise not be visible. If suppression is turned off, the duplicate alarms are
treated as new alarms and will be visible in USM or the nas GUI.
Alarm Clear Conditions Using Time Over Threshold

Auto-clear is an optional setting that clears a Time Over Threshold alarm when there are no new threshold violation events for the defined time
period. If auto-clear is turned on, a timer begins after a clear event is received. If no subsequent threshold violation events arrive in the auto-clear
window after the clear event is received, the alarm is automatically cleared (set to level 0). The arrival of a threshold violation event resets the
clear rule, which waits for the next clear event to arrive before the timer starts again.
An auto-cleared Time Over Threshold alarm can be automatically acknowledged (and closed) using the Accept automatic 'acknowledgment' of
alarm option in the nas probe GUI, which is enabled by default. If this option has been disabled, alarms will remain in the alarm history with Clear
(green) Severity and must be manually acknowledged.
Note: Auto-clear times are retained when the alarm_enrichment probe is not active. If the alarm_enrichment probe stops and is then
reactivated, any running Auto-clear timers are restarted with either:
The time of the original Auto-clear, if it is still in the future.
One-minute, if the original Auto-clear time is in the past.
Example: Time Over Threshold Using Auto-Clear

Auto-Clear: 5 minutes
Alarm Severities: Clear, Information, Warning, Minor, and Major alarm thresholds are set in the probe GUI.
Alarm Severity Changes During Time Over Threshold

Time Over Threshold is evaluated at each user-defined event severity. This means that a metric must be at an elevated alarm severity for the
defined Time Over Threshold before the severity changes. The new alarm severity level is then set to match cumulative event severity in the Time
Over Threshold Window.
Each time a threshold violation event arrives, the Time Over Threshold alarm severity is determined as follows:
1. The cumulative time of the threshold violation events within the sliding window with Critical severity is calculated. If that time exceeds the
defined Time Over Threshold, the alarm severity is set to Critical and rule processing is complete.
2. The cumulative time of threshold violation events within the sliding window with a severity that is Major or greater is calculated. If that time
exceeds the defined Time Over Threshold, the alarm severity is set to Major and rule processing is complete.
3. The cumulative time of threshold violation events within the sliding window with a severity that is Minor or greater is calculated. If that time
exceeds the defined Time Over Threshold, the alarm severity is set to Minor and rule processing is complete. Otherwise, the algorithm
continues in this pattern for the remaining severity levels.
Example: Time Over Threshold with Increasing Severity
Alarm Suppression: On.
In this example:
1. Time 20 - A Time Over Threshold alarm is raised after ten minutes of Time Over Threshold event time is accumulated. The alarm
severity is set to 1, because the first Time Over Threshold rule condition that matches is 'event severity is 1 or greater'.
2. Time 25 - The severity is elevated to 2 because the Time Over Threshold rule condition 'event severity is 2 or greater' is now true
3. Time 30 - The severity is elevated to 3 because the Time Over Threshold rule condition 'event severity is 3 or greater' is now true.
Note: Time Over Threshold only evaluates on alarm severity levels that are set in the probe configuration GUI.
Example: Time Over Threshold with Two Set Severities

Alarm Severities: Minor and Major alarm thresholds are set in the probe GUI.
In this example:
1. Time 30 - A Time Over Threshold alarm is raised after ten minutes of Time Over Threshold event time is accumulated. The Time Over
Threshold alarm severity is set to 3, because the first Time Over Threshold rule condition that matches is 'event severity is 3 or greater'.
Example: Time Over Threshold With Multiple Severities
Auto-Clear: 4 minutes.
In this example:
1. Time 8 - A Time Over Threshold alarm is raised after four minutes of Time Over Threshold event time is accumulated. The alarm severity
is set to 1, because the first Time Over Threshold rule condition that matches is 'event severity is 1 or greater'.
2. Time 10 - The severity is elevated to 2 because the TOT rule condition event severity is 2 or greater is now true.
3. Time 16 - The severity is elevated to 3 because the TOT rule condition event severity is 3 or greater is now true.
4. Time 21 - The alarm severity decreases to 2 because there are no longer 4 minutes or more of severity 3 or greater within the 8-minute
sliding window, but there are 4 minutes or more of severity 2 or greater
5. Time 25 - The alarm severity decreases to 1 because there are no longer 4 minutes or more of severity 2 or greater within the 8-minute
sliding window, but there are 4 minutes or more of severity 1 or greater
6. Time 30 - The alarm is cleared because no new violations occur for four-minutes and the auto-clear condition is met.

The static and dynamic threshold limit types are currently supported with Time Over Threshold. See Configuring Alarm Thresholds for more
information.
Additional Time Over Threshold Scenarios

The following examples show extra Time Over Threshold scenarios using specific probe metrics.
Example: URL_response Probe Metric Time to First Byte

Alarm Severities:
Alarm Severity 2 is set to 100 ms.
Alarm Severity 5 is set to 1,000 ms.
In this example:
1. Time 8 -Three-minutes of time to first byte of 100 ms or greater is observed in the sliding window and an alarm of severity 2 is sent.
2. Time 14 - Three-minutes of time to first byte of 300 ms or greater is observed. The alarm increases to severity 3.
3. Time 20 - Three-minutes of time to first byte of 700 ms or greater is observed. The alarm increases to severity 4.
4. Time 25 - Three-minutes of time to first byte of 1000 ms or greater occurs. The alarm increases to severity 5.
Example: CDM Probe Metric Disk Usage
Alarm Severities: The Critical alarm threshold is set to 80% in the probe GUI.
In this example:
1. Time Over Threshold only occurs for four-minutes and no alarm is sent.
Example: CDM Probe Metric Disk Usage (Modified to Send a Time Over Threshold Alarm)
Auto-Clear: 5 minutes.
Alarm Severities: The Critical alarm threshold is set to 80% in the probe GUI.
1. Time 15 -Five-minutes of disk usage at 80% or greater is observed in the sliding window and an alarm of severity 5 is sent.
2. Time 21 - The alarm is cleared after five-minutes of time below the set severity level.
Best Practices for Time Over Threshold

Observe the following best practices when using Time Over Threshold:
Set the auto-clear window to a longer interval than the Time Over Threshold. Setting a smaller Auto-clear window results in an excessive
number of alarms due to rapid Auto-clears.
Set the Time Over Threshold to a longer interval than the sample period for the QoS metric. Setting a smaller Time Over Threshold
produces the same results as leaving the Time Over Threshold rule disabled.
Evaluate your monitored system and determine the appropriate values for both the sliding window and Time Over Threshold. Values that
are too large for your system can result in the suppression of alarms you may need to be aware of.
Configure Time Over Threshold

Note: Any alarms generated from the secondary nas must be passed to the primary nas using replication.
Follow these steps:

3. Click the Publish Data, Publish Alarms, and Compute Baseline check boxes.
4. Click either the Dynamic Alarm or Static Alarm check box.
5. Configure the dynamic or static alarm settings. See the appropriate section in the Configuring Alarm Thresholds article.
box.
Troubleshooting Time Over Threshold

I see Errors Regarding alarm_enrichment
Symptoms:
I have received a Critical alarm stating that the alarm_enrichment probe version is incorrect, or that the alarm_enrichment probe must be
activated.
I see the following error message in the Admin Console probe configuration GUI:
"Time over threshold is not available. Unable to read or write the configuration from the alarm_enrichment probe."
Solution:
Verify that alarm_enrichment probe version 4.40 or later is installed and activated at Hub level.
The Time Over Threshold Configuration Parameters are Unavailable
Symptoms:
I do not see the Time Over Threshold configuration parameters in the Admin Console GUI of my probe.
I do see the Dynamic Threshold configuration parameters.
I have received no additional error messages or alarms.
Solution:
Verify that the correct versions of nas, ppm, and prediction_engine are installed and activated at the Hub level.
More Information:
The Time To Threshold Event Rule

Configure the Time To Threshold alarm for QoS-enabled probes to send an alarm when a QoS metric is predicted to reach a user-defined value
within a configured time period. The Prediction Value has the same implicit units as the QoS metric you are configuring.
Prerequisites
To use Time To Threshold, you must have the following probe versions installed at the secondary hub level:
Time To Threshold is an event violation rule that sends an alarm if a QoS metric is predicted to reach a set value within a user-defined time
period. Setting a Time To Threshold alarm for any of the QoS-enabled probes allows the prediction_engine probe to gather trending information
used to calculate when a particular event might occur. The Time To Threshold settings are configured using the Admin Console.
At any time, the condition that triggers the Time To Threshold alarm can change (for example, files were deleted to free up space) or the Time To
Threshold alarm settings can be reconfigured.
Time To Threshold Workflow

The following diagram shows the process of how QoS data from a QoS-enabled probe is used to generate a predictive alarm.
When you configure the Time To Threshold settings on a QoS-enabled probe, the following actions occur:
data_engine stores raw QoS metric data from the QoS-enabled probes
prediction_engine computes trend information for QoS metrics that have Time To Threshold configured
baseline_engine probe evaluates QoS trend metrics from probes against static threshold definitions
baseline_engine probe generates threshold violation messages when the Time To Threshold trend timeframe and prediction thresholds
are crossed
How a Time To Threshold Alarm is Generated

The process of generating a predictive Time To Threshold alarm includes the following actions:
The QOS-enabled probe sends raw data to the data_engine probe.
The data_engine probe stores the raw data in the S_QOS_DATA and S_QOS_DEFINITION tables.
The prediction_engine keeps samples collected during the hour.
At five minutes past the hour, the prediction_engine probe calculates a linear regression line based on an hourly median for all QoS
metrics with the Time To Threshold alarm configured.
The prediction_engine sends a new QoS metric, as its sample value, containing the number of hours until the configured QoS reaches
the prediction value.
The baseline_engine probe evaluates these QoS metrics from the prediction_engine against the configured static threshold definitions
(time threshold, time units, and prediction value).
The baseline_engine probe sends an alarm of the configured severity if this new QoS metric is less than or equal to the time threshold
(time threshold and time units) configured for each Time To Threshold alarm.
An alarm is sent each hour for the QoS metric as long as the calculated time prediction is less than or equal to the configured time
threshold (time threshold and time units).
A Time To Threshold Alarm is no longer sent when the calculated values indicate that the prediction has been met or that the prediction
is beyond the configured Time Threshold.
For more Information:

Prediction Engine probe article
Release Notes
Release Notes are organized alphabetically by probe name. Release notes contain:
Changes that are made within a probe release
Software and hardware requirements
Installation and upgrade information
ad_response (Active Directory Response Monitoring) Release Notes

An Active Directory (AD) is a directory service, which is integrated in most of the Windows Server operating systems. The Active Directory stores
information about network components and enables clients to find objects within its namespace.
The Active Directory Response (ad_response) probe monitors the availability of the Active Directory. The probe can monitor and report:
Connect response time of AD server.
Object and number of objects found.
Replication of modified objects between servers, sites, and domains.
Contents
Revision History
Probe Specific Software Requirements
Installation Considerations
Upgrade Considerations
Revision History
This section describes the history of the revisions for the ad_response probe.
Note: Salesforce case(s) may not be viewable to all customers.
Version
Description
State
Date
1.61
Fixed Defects:
GA
July 2015
GA
November
2013
The probe did not change the information level in the log file even after changing the log level from 0. Salesforce case:
00145920
The probe did not use the selected authentication type while creating LDAP connection. Salesforce cases: 00144532,
00144708
1.60
Implemented support for Windows Server 2012.
1.53
Fixed issue related to clear alarm.
June 2013
1.52
Fixed defects related to SOC probe restart.
June 2012
1.51
Added Support for SOC.
December
2011
1.50
Removed white spaces
June 2011
Check Profile does not allow duplicate profile name

Allows special character in Password text.
Allows Message ID change in Profile.
1.40
Added support for internationalization
December
2010
1.30
Updated the latest Nimsoft Dot Net API with SSL support.
June 2010
1.21
Added fix in GUI to handle long password.
March
2010
1.20
Added support for extended NIS database information.
February
2010
1.11
If controller is configured to use robot name for QoS, the probe will send configured name in the QoS source. Otherwise the
probe will send the host name in the QoS source.
September
2009
1.10
Migrated ad_response projects to visual studio 2008.
June 2009
Added fix to send source name / host name in lower case with alarm.
Updated bmake and package file for win64 support.
1.06
Updated the package file and added code to change the description of the probe.
Updated code to calculate object age if write mode is enabled.
Updated code to validate the provided domain.
Updated code to validate text inputs(connection) for blank data.
Updated code to change the test connection message.
Updated code to disable the write mode if GC is selected.
Updated code to modify the QoS SampleTime to UTC.
September
2008
1.05
Updated the package file and added default security permission to write.
July 2008
Updated the code to send unique target information in QoS.

Updated the code to have unique profile name.
1.04
Updated the source code to use new Nimsoft Dot Net API.
May 2008
Fixed the issue where the probe binds to secondary NIC

1.03
The probe renamed from active_directory to ad_response.

Note: If upgrading from the Pre-GA release of the Active Directory probe, please see upgrade section below
November
2006
Fixed an exception when a new objects found threshold was added to a new search profile.
Fixed a configurator problem, when the configurator was started from machines without a running controller.
Fixed test connection error message.
Replaced NimbusAPI.dll with a newer version.

The ad_response probe requires:
Nimsoft Monitor Server 7.6 or CA Unified Infrastructure Manager 8.0 or later
Robot 7.6 or later (recommended)
Java JRE version 6 or later (required for Admin Console)
Microsoft .Net Framework 4.5 when the OS is other than the Windows Server 2012.
On 64-bit Windows computers, the probe requires 64-bit Microsoft .NET Framework 4.5 to run as a 64-bit native application.
Note: The probe does not support Windows 2003 platforms.
The installation considerations for the probe are:
The robot where the probe is installed must be on the same domain as the AD server.
The probe requires remote user access with administrator rights so that you can query for any other user.
Upgrading from pre-GA Active Directory probe:
The pre-GA version of the Active Directory probe was simply called "active_directory". From the version 1.11 GA release, this probe has been
renamed to "ad_response". If you have the older version of probe installed, please perform the following steps in order to upgrade correctly.
1. Deactivate the "active_directory" probe.
2. Deploy the "ad_response" probe from local archive.
Note: New license keys are required because the probe name is changed.
3. See that configuration is ok in new probe.

4. Delete the "active_directory" probe. If you do not do so, you would have two probes sampling data from the Active Directory server at the
same time.
ad_server (Active Directory Server Monitoring) Release Notes
Active Directory is the directory service included with the Windows servers to manage the identities and relationships for managing network
environments.
The active directory server (ad_server) probe monitors the selected counters on Active Directory (AD). These counters measure the availability
and response time of the active directory server and perform health checks to prevent outage and degradation conditions.
Contents
Revision History
Supported Locales
Threshold Migration Configuration
Probe Specific Hardware Requirements
Upgrades and Migrations
Known Issues and Workarounds
Revision History
This section describes the history of the revisions for the ad_server probe.
Version
Description
State
Date
1.80
What's New:
GA
June 2015
GA
April 2015
The probe can now be migrated to standard static alarm thresholds using the threshold_migrator probe.
Added support for 32 bit. Salesforce case 00141918
Fixed Defects:
The alarms did not change if a profile created in the IM GUI was edited in the Admin Console GUI. Salesforce case 001
55151
Metrics were not configured properly in the Admin Console GUI. Salesforce case 00155145
The probe did not test Health Monitors. The server returned a referral to the probe. Salesforce case 00165194
1.71
Fixed Defects:
The probe was automatically selecting existing counters for new profiles and also generating QoS for these counter. Sal
esforce case 00158381
New Feature
Added an option in IM GUI to enable or disable alarms.
1.70
New Features:
June 2014
Added localization support for Simplified Chinese, Japanese, Korean, Spanish, German, and B-Portuguese languages
from IM and Web GUI. For localization support through WEB GUI probe must run with NMS 7.6 or later version and
PPM 2.34 or later version.
Added support for health monitoring through VB GUI also.
1.61
What's New:
Added support for monitoring Active Directory Replication Subsystems.
Added support for monitoring Active Directory Lost and Found Objects.
Added support for monitoring Trust Relationships between AD Servers.
Added back the support for Windows Server 2012 R2.
March
2014
1.60
1.50
What's New:
Implemented a new feature through web GUI for monitoring the active directory server health from CA Unified Infrastructure
Management 7.5 onwards.
Fixed an issue where upgrading to version 1.50 failed to start the probe. Software Requirements section is updated with
correct version of .Net Framework, which is required to run the probe.
March
2014
December
2013
Added support for Windows Server 2012 R2.

1.43
Fixed SOC Defect.
June 2012
1.42
CPU utilization reduced.
December
2011
1.41
SOC Support Added.
November
2011
1.30
Updated latest Nimsoft Dot Net API with SSL support.
June 2010
1.20
April 2010
Added fix to differentiate QoS target.

Added fix to send alarm for eventlog profile with long eventID.
Added fix to send QoS definition properly.
1.12
1.11
If controller is configured to use robot name for QoS, the probe will send configured name in the QoS source. Otherwise the
probe will send the host name in QoS source.
Added restart callback.
Added fix for clear alarms.
September
2009
August
2009
Bug fixes in GUI.

Added fix for minor bugs in probe.
Added fix in GUI for 'Section not found' message box.
Added fix for runtime error on probe restart.
1.10
Added fix to check the counters of process profile which are available in config file. Also fixed alarm and qos issues.
Added fix to send source name / host name in lower case with alarm or qos. Updated latest nimsoft dot net api with
version 1.6 which supports non standard ports. Migrated ad_server projects to visual studio 2008.
June 2009
Added fix to show local time of the robot on which probe is deployed.
Added fix for event user id if its value is NULL.
Modified code to show event log counters if only log type is selected.
Added fix to send alarm and QoS even if the event id is not specified.
Added fix to save event id in event profile and include subdirectories option in filesystem profile properly.
Fixed issue when event log vales are not correct.
Set default log level to 0.
Added fix to relogin when sid is expired.
Added fix for probe not running or load configuarion error.
Added fix to disable 'Apply' button on opening configurator.
Added fix not to save config file twice if 'Apply' button is clicked.
Added fix to read loglevel from config file and set it to probe .
Added fix to load / save configurator on tunneling setup properly.
Reverted nimsoft dot net api from version 1.5 to 1.1.
1.02
Fixed issue when QoS is not active after changing interval.
May 2008
Fixed issue when QoS where double QoS was found.

Updated restart and controller information procedures in distributed environment.
1.00
Initial version.
Supported Locales
The ad_server probe now supports the following locale.
Simplified Chinese
March
2008
German
Italian
Japanese
Korean
Portuguese
Spanish
Threshold Migration Configuration

The probe (version 1.80 or later) threshold configurations can be migrated to standard static alarm thresholds using the 2.01 version of the
threshold_migrator probe.
Refer to the threshold_migrator probe document for information on how to migrate a probe.
Note: The changes in the probe after migration are:

The Infrastructure Manager GUI of the probe will not be available and the probe will only be configured on Admin Console.
Probe specific alarm configurations in the probe monitors will be replaced by Static Alarm and Time Over Threshold
configurations.
The alarms will be sent by the baseline_engine probe.
User defined variables will not be available.

The ad_server probe should be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. Probe's OOB configuration requires 256MB of RAM
CPU: 3GHz dual-core processor, 32-bit or 64-bit

The ad_server probe requires the following software environment:
CA Unified Infrastructure Management 8.3 or later
CA Unified Infrastructure Management robot 7.5 or later (7.70 recommended)
Probe Provisioning Manager (PPM) probe version 3.21 or later
Baseline Engine (baseline_engine) 2.60 or later
Java JRE version 6 or later
.Net Framework 4.5, where Robot is installed
.Net Framework 2.0, if CA UIM is installed
Note: .Net Framework 4.5 is required if the robot and CA Unified Infrastructure Management are installed on the same
machine.
The ad_server probe requires the following software environment to migrate with threshold migrator probe:
CA Unified Infrastructure Management robot 7.5 or later (recommended)
baseline_engine (Baseline Engine) version 2.60 or later
The ad_server probe is deployed with a default configuration, with a preconfigured profiles to be monitored. These might require some
adjustments, such as the path for the DSA file. The default WMI counters are configured for a Windows 2003 AD Server. They might not work on
Windows 2000 servers.
You can set Events, Files, Filesystems, Performance counters, Health Monitors, Processes, Services and WMI counters as required and suitable
for monitoring the AD server.

While upgrading the probe from a previous version to 1.70 or later in the non-English locale, take a back-up of your existing ad_server.cfg file in
UTF-8 encoding. The process ensures that the configuration file does not corrupt and the upgraded probe reads the non-English characters
correctly.
Follow these steps:
1. Copy the existing ad_server.cfg file to any other location of your system.
2. Open the copied ad_server.cfg file and save it to UTF-8 without BOM. If the file is with BOM, the probe throws an error while reading the
file.
BOM is a special text at the beginning of the text file for identifying the file encoding. You can use a text editor, like Notepad++ on
Windows and gedit on Linux, for defining your file encoding. You can also use the iconv command on Linux for changing the character
encoding. Alternatively, edit the configuration file on Windows system and copy it back to the Linux system.
3. Upgrade the probe to current version.
4. Deactivate the probe after upgrade.
5. Replace the new ad_server.cfg file with the UTF-8 encoded configuration file.
6. Activate the probe.
The probe reads the Japanese characters of the ad_server.cfg file correctly.
In case, the probe is already upgraded to version 1.70 without taking a back-up of the configuration file, you can delete all such profiles and can
recreate them.
Note: You can configure only two thresholds in probe version 1.71 or later. However, if more than two thresholds were configured in the
previous version(s), they will be available in this version also.

Please note that the configuration tool is unable to renew the login information. This can result in a situation where changes to the probe
configuration cannot be saved.
To avoid this problem, you should save your changes and restart the configuration tool within the configured Login Expiration Time, which is
configured in Security option of Infrastructure Manager.
The Adapter GUI is displaying monitoring counters that are not a part of the monitoring category. This results in a situation, where the
configuration of the the counters is not saved.
To avoid this problem, add the monitoring object and save the configuration, before you configure the counters property.
adevl (Active Directory Events Monitoring) Release Notes

The adevl (Active Directory Events) probe generates alerts that are based on messages from the NT event logs associated with Active Directory.
The probe monitors the event logs of Directory Service, Application, DNS Server, and File Replication Service for new messages and generates
alarm messages according to your setup. You can set up the probe to trigger an alarm when an event of log occurs in Windows. Alternatively, you
can check the event log for new messages at fixed time intervals, which reduces the system load of the probe.
The probe now supports the following locales:
B-Portuguese
Chinese (traditional and simplified)
French
German
Italian
Japanese
Korean
Spanish
Contents
Revision History
Installation Notes
Known Issues
Revision History
This section describes the history of the revisions for the adevl probe.
Version
Description
State
Date
2.01
What's New:
GA
June 2015
GA
September
2014
GA
November
2013
GA
December
2012
Added support for factory templates with CA Unified Infrastructure Management 8.3.
Added functionality to allow user to select log name from the drop-down menu and enter log name in log field.
2.00
What's New:
Added the localization support for B-Portuguese, Chinese (simplified and traditional), French, German, Italian,
Japanese, Korean, and Spanish languages from both IM and Admin Console GUI. For localization support through
Admin Console GUI, the probe must run with PPM 2.38 or later version.
Updated the probe IM GUI and Admin Console GUI for specifying the character encoding in different locales.
Note: Do not use the Raw Configure GUI for updating the probe configuration in the non-English locales as it can corrupt the
configuration file.
1.60
Japanese event logs issue fixed

Added support for Windows server 2012.
1.56
Added Probe Defaults

Fixed a defect where probe GUI is slow in responding, if there was large number of events.
Added functionality to monitor Operational and Admin event logs (introduced from Vista/Windows 2008 onwards).
Fixed memory leaks.
1.54
SOC defect fixed
GA
June 2012
1.53
SOC Support Added
GA
December
2011
GA
June 2010
GA
June 2010
1.41
Made changes to libraries concerning configuration locking.

Fixed the defect in display of logs on 64-bit Windows 2008 Server platform.
1.40
Enhanced the probe to allow generation of variables from message body and also to send alerts on this variables.
Added support to raise an alert only after particular number of instances of an event, within the particular time frame.
1.30
Added support for extended NIS database information
GA
March
2010
1.23
Resolved the problem where only a partial event list was retrieved. The most obvious situation was on computer restart
GA
March
2010
1.22
1.21
Added a fix in evlWmi library for fetching InsertionStrings column value from WMI if Message value is not available.
Fixed a crash in evlWmi library.
GA
December
2009
GA
November
2009
GA
October
2009
GA
September
2009
GA
September
2007
GA
April 2006
GA
August
2004
Added a fix for replacing recurring hard returns with a single delimiter in description field.
Added a feature in the GUI to enable/disable removal of recurring hard returns.
1.20
Added fix in the probe and GUI for replacing hard returns with user-defined delimiter in event description field.
Fixed Day Light Saving time issue.
Stopped using regular expression comparisons to detect duplicate events.
1.10
Added support for adding custom event logs to monitor. Custom logs can be added using raw configure and assigning
appropriate key value paris in section of configuration file.
Added support for using variables like $event_id in suppression key.
Added support for using variables in custom alarm messages.
Added support for using localhost as computer name to get only local machine events.
The probe now supports option to enable/disable propagation of events.
The probe now supports 64 Bit Windows environment.
The probe now supports Windows 2008 operating system.
Updated WMI library for handling custom event logs.
Added key (wmi_timeout) in the setup section of configuration file. This key can be used to set the WMI query timeout in
seconds if there are huge number of events.
Added fix in Windows Vista running service pack version 1 or below to fetch the event indexes using WMI. Vista version
prior to SP2 had an issue where the probe was unable to fetch the event indexes properly.
Added a fix in the evlWmi library for handling computer's FQDN. In some windows platforms when a machine is in a
domain the computer field of event logs shows computer FQDN. Earlier the probe was failing when checking the
Computer field in the Exclude tab.
1.06
1.05
Implemented some fixes from the ntevl probe.

Fixed startup problem.
Do not scan all logs from the beginning on installation, but start scanning from the current location.
1.02
User interface fixed for Windows XP.
Installation Notes
The adevl probe monitors the event logs for new messages and generates alarm messages according to your setup. You can configure the probe
for triggering each time a new message is added to the event log or you can check the event log for new messages at a fixed interval, which will
reduce the system load generated by the probe. Consider the following points while installing the probe:
Restart the probe when the time zone is changed or when you select "Automatically adjust clock for Daylight Saving Time" option on the
system where the probe is deployed.
The Windows event log watcher probe version 3.0x uses WMI to retrieve the event logs. Accessing Windows event logs using WMI may
severely affect the performance of the Windows 2000 system. If the probe is deployed on Windows 2000 system, the probe will raise an
alarm and will stop execution.

The adevl probe should be installed on systems with the following minimum resources:

The adevl probe requires the following software environment:
Nimsoft Management Server 7.6 or CA Unified Infrastructure Management 8.0 or later.

Robot 7.6 or later (recommended).
Probe Provisioning Manager (PPM) probe version 2.38 or later (for Admin Console GUI only).
Java JRE version 6 or later (required for Admin Console version).
Active Directory installed.
Known Issues
The adevl probe has the following limitations:
With all CA Unified Infrastructure Management Versions:
The probe does not support monitoring of forwarded events .
Localization is not supported on Windows ia64 platform.
Do not use the same profile name for ntevl and adevl probes, when deployed on same robot.
Use either IM GUI or AC GUI of the probe to avoid any unexpected issues that can occur during probe configuration.
With CA Unified Infrastructure Management 8.0 onwards:
The probe GUI can stop responding when the Maximum Events to Fetch field value is more than 1000. In case, the probe GUI has
already stopped responding; follow these steps:
1. Open the Raw Configure GUI.
2. Update value of the fetch_number key (under setup section) to 1000 or less.
3. Restart the probe.
With CA Unified Infrastructure Management 7.6 or earlier:
The Raw Configure GUI of the probe is not supported for non-English locales because it can corrupt the entire probe configuration file.
The probe GUI can stop responding when the Maximum Events to Fetch field value is more than 1000. In case the probe GUI has
already stopped responding, follow these steps:
1. Open the IM probe GUI.
2. Update value of this field to 1000 or less (under the Properties tab).
adogtw (ADO Gateway) Release Notes

ActiveX Data Objects (ADO) Gateway is a database gateway probe between CA Unified Infrastructure Management and a database. The probe
reads data from database tables using user-defined SQL statements for monitoring database performance. The probe uses SQL Queries to
monitor the database performance parameters like, the response time and number of rows returned. Based on the database performance, the
probe posts Quality of Service (QoS) messages to the CA Unified Infrastructure Management.
Revision History
Known Issues
Revision History
This section describes the history of the revisions for the adogtw probe.
Version
Description
State
Date
2.71
Fixed a defect in which the alarm target was not setting properly.
GA
April 2013
Fixed an issue which the correct date/time format was not inserting in subscriptions as configured through adogtw
UI.
2.70
Added internationalization support for alarm string messages.
GA
December 2012
2.60
Added NIS (TNT2) Changes.

Fixed a defect related to probe sending alarm without message.
GA
June 2010
2.50
Ported the probe to support windows 64-bit platform.

Added connection alarm clear functionality on probe restarts.
2.48
Configurator fix - alarm level in profile correctly mapped to color and alarm level name.
Added subsystem drop down list for alarm profiles
Fix: added code to expand column id in alarms in QoS profiles
Fix: problem when an alarm text was too long and got clipped by adogtw, and the last sign in the clipped text was a '.
GA
October 2007
2.47
Fix: GUI could cause a runtime error if you entered an integer value as name for a new profile or connection.
Added: hotkeys for common commands.
Added: dropdown for alarm severity instead of textfield in alarm profile dialog.
Data of type Numeric was sent as integer not floating point.
GA
September
2006
2.44
Fixed bug in suppression keys for alarms.
GA
February 2005
September
2009

The adogtw probe should be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. Probe's OOB configuration requires 256MB of RAM'

The adogtw probe requires the following software environment:
CA Unified Infrastructure Management Server 5.1.1 to 7.6 or CA Unified Infrastructure Management 8.0 or later
CA Unified Infrastructure Management Robot 5.23 or later
Java JRE 6 or later
MDAC 2.5 or newer
On Windows XP and Windows 2003 64-bit platforms, the 64-bit ODBC drivers are not available by default. User needs to update the drivers from
the URL: http://www.microsoft.com/en-us/download
Post-installation of these drivers, the probe may still generate the following error logs:
COM Error [0x800a0ea9] Unknown error 0x800A0EA9 - [ADODB.Connection] Provider is not specified and there is no designated default
provider.
COM Error [0x800a0e7a] Unknown error 0x800A0E7A - [ADODB.Connection] Provider cannot be found. It may not be properly installed.
The workaround for this situation is to create the database connection using OLEDB instead of ODBC.
NIS (TNT2) notes
When upgrading from GA to TNT2 version, OR downgrading from TNT2 to GA version, the probe-specific file adogtw_alarm.txt should be
removed from the working directory in order to ensure a smooth upgrade or downgrade.
Known Issues
The Subscribe type profiles cannot be configured.
aggregate_alarm Release Notes

The aggregate_alarm probe lets you configure an expression which includes one or more QoS metrics. When this expression evaluates as true a
single customized alarm is generated.
Revision History
Requirements
Environment
Java Requirement
Hardware Requirements
Contents of aggregate_alarm-1.0.1 Zip File
Download and Deploy
Known Issues
Revision History
This section describes the history of the revisions for the aggregate_alarm probe.
Version
Description
1.01
State
Date
Controlled Release
August 2015
Requirements
Environment
For the aggregate_alarm probe to function properly, verify that the following probes are deployed and running on the primary hub. These probes
are automatically deployed to the primary hub when you run the CA UIM Server Installer v8.31.
Admin Console 8.31
Alarm Server (nas) v4.73 and alarm_enrichment v4.73
Probe Provisioning Manager (ppm) v3.22
CA Unified Management Portal (UMP) v8.31 is optionally required to allow the drop-down lists in the GUI to be populated with data from the UIM
database.
Java Requirement
Java 7 (java_jre1.7) - the hubs where the required probes are running should have java_jre1.7 loaded in the Installed Packages in Admin
Console (typically installed with UIM v8.0 and later)
The aggregate_alarm probe should be installed on systems with the following minimum resources:
Memory: 512 MB of RAM
CPU: 3 GHz dual-core processor, 32-bit or 64-bit
Contents of aggregate_alarm-1.0.1 Zip File

To use the aggregate_alarm probe, you must have CA UIM v8.31 running on your UIM server.
The content of the Zip file includes:
aggregate_alarm-v1.0.1 probe package (Zip)

User Guide (PDF)
Release Notes
Download and Deploy

After you install or upgrade your UIM Server to CA UIM v8.31, you can deploy the aggregate_alarm probe.
Follow these steps:
1. Download the aggregate_alarm-1.0.1.zip file, located at:
https://nimsoftnms.s3.amazonaws.com/Aggregate_Alarm/1.01-CR/aggregate_alarm-1.0.1.zip
2. Extract the content of the Zip file to a temporary folder on your UIM Server.
3. Upload the probe Zip file to the Local Archive in Admin Console.
4. Deploy aggregate_alarm v1.0.1 to a hub robot. It might take a few minutes to finish.
Note: After the deploying the probe, it is recommended to do a browser cache refresh.
Known Issues
None.
apache (Apache HTTP Server Monitoring) Release Notes
The Apache HTTP Server Monitoring (apache) probe monitors all the Apache-based HTTP servers of an organization to detect any performance
issues. It performs HTTP GET queries to the specified Apache web servers and transforms the query result into alarms and Quality of Service for
Service Level Agreements (SLA).
Contents
Revision History
Revision History
This section describes the history of the revisions for this probe.
Version
Description
State
Date
1.62
Fixed Defects:
GA
November
2015
GA
July 2014
When creating a host profile, the probe crashed when the user entered incorrect server status and server address for HTTP
response. Salesforce case 00170024
1.61
Fixed Defects:
The IM GUI help link was opening the old help document instead of the new online probe documentation. Salesforce case
00135559
1.60
Added support for zLinux Operating System.
June 2014
1.55
Config locks not releasing for Apache probe.
October
2013
1.54
Added Probe defaults.
June 2013
1.53
Fixed issue related to probe have segmentation fault.
April 2013
Fixed issue related to QoS not showing up.

1.52
Added Probe Defaults.
March
2013
1.51
Added fixes to web-based Service Oriented Configuration.
January
2011
1.50
Added AIX platform support.

Added support for Web-based Service Oriented Configuration (SOC).
1.41
Added support for internationalization.

Added support for reading alarm tokens from cfg.
1.30
1.20

Added code to remove white spaces from all the section names.
Added code to override the suppression ID of alarm.
1.10
Upgraded project to allow native 64 bit code.

Added timeout option for to pass to cURL library.
December
2010
November
2010
June 2010
March
2010
September
2009
Error message from cURL library can now be used in the agent error alarm by using $curl_error.
Fixed a minor GUI bug. When the text field for hostname/ip lost focus, the content of the url field would update. The
same when you toggle the SSL on | off, the content of the url field would be overridden. Now behavior is that content of
url field is filled out if its empty, and only the http | https part of whatever is in the url field is updated when toggling ssl.
1.02
Added support for SSL certificate verification & validation.

Fixed issues in GUI related to saving configuration file.
October
2008
Fixed issue in GUI display for Vista.

Added logs while sending QoS messages.
1.01
Added support for Linux.
September
2007
1.00
Initial version (Apache)
July 2007

The apache probe requires the following software environment:
Nimsoft Monitor Server 7.6 or CA Unified Infrastructure Management 8.0 or later
Apache http server versions: 2.2.4, 2.0.59, or 1.3.37
apmgtw (CA APM Gateway) Release Notes

The apmgtw (CA APM Gateway) probe sends QoS messages from CA Unified Infrastructure Management probes to your CA Application
Performance Management (APM) database.
Revision History
This section describes the revision history of the apmgtw probe.
Versions
Description
State
Date
2.0
What's New:
GA
September
2015
Beta
August
2015
Added support for configuration of the probe using Admin Console. The probe is now configurable only through
Admin Console
Bug Fixes
2.0
What's New:
Added support for configuration of the probe using Admin Console. The probe is now configurable only through Admin
Console.
1.1
What's New:
Controlled June 2015

GA
Corrected probe GUI and documentation by removing mention of alarms. The apmgtw probe only sends QoS data from
probes to CA APM. The probe does not send alarms.
1.0
Initial Beta Release
Beta
November
2014
Prerequisites
Before you configure the probe, verify that you have completed these prerequisites:
CA APM is installed
CA APM Workstation is installed
Software Requirements
Note: The probe is supported for the following operating systems:
Windows 2008 Server
Windows 2008 Server R2
Red Hat Enterprise Linux
CentOS
The probe supports CA APM Enterprise Manager versions 9.6, 9.7, and 10.0.
The probe is compatible with CA Unified Infrastructure Management versions 8.1, 8.2, 8.3, and 8.3.5.
QoS message names might appear truncated in the Admin Console, Configuration page. It is recommended that you use CA Unified
Infrastructure Management 8.3.5 to view the complete names.
Deployment Considerations
The apmgtw probe can be only deployed on your CA Unified Infrastructure Management primary hub.
Before you use the Admin Console, Configuration page, ensure that PPM probe is configured to use the Web UI for the apmgtw probe.
Follow these steps:
a. Access the Admin Console.
b. Select Probes, PPM, Raw Configure.
c. From the Root folder, navigate to the adapter list folder.
d. Verify whether the apmgtw section exists with the apmgtw key and value 2.00.
If apmgtw section does not exist, use the Add section and Add Key buttons and specify the value 2.00.
e. Restart the probe.
Upgrading Considerations
When you upgrade or redeploy an existing version of the probe, the configuration files are migrated to the recent installation upon activation of the
Admin Console, APMGTW Configuration page. Deactivate and activate the probe for the configuration to take effect.
Troubleshooting
This section describes troubleshooting procedures for the CA APM Gateway (apmgtw) probe.
Problem:
I select a probe and its QoS, but QoS is not shown in CA APM Web View.
The length of the QoS may be too long. Check to see if the corresponding QoS format message in the qos.properties file is more than 150
characters. If the length of the QoS exceeds 150 characters, then apmgtw probe cannot send that QoS to CA APM.
Solution:
Navigate to the qos.properties file: Nimsoft > Probes > Gateway > apmgtw > qos.properties file.
In the metrics section of the qos.properties file, edit the description of the QoS message so that it is fewer than 150 characters.
audit Release Notes

The audit probe maintains data structures for UIM Server auditing. When deployed, the audit probe performs the following tasks:
Adds an audit queue to the hub and stores audit messages in the database.
Monitors changes to your UIM environment and sends audit messages to the Primary Hub.
Audit messages, or events, are generated from the following actions:
User Commands - User activities such as activating probes.
Probe Commands - Probe activities such as distsrv probe package distributions
Contents
Revision History
Probe-Specific Software Requirements
Revision History
Version
Description
Date
State
1.22
Hard-coded requirement for JRE removed
Mar 2013
GA
1.21
Minor changes
Sep 2012
GA
1.20
Minor changes
Mar 2012
GA
1.19
Configuration tool change window update fixed
Aug 2011
GA
1.18
Changes in db library
Mar 2011
GA
1.17
Fixed: failed to handle strings with special characters (escape ' characters for Oracle db)
Nov 17 2010
GA
1.16
Fixed:administration failed on Oracle Linux 32-bit. Calculated time was malformed
Nov 4 2010
GA
1.15
Configuration tool correction to support audit settings from hub
Sep 2010
GA
1.14
Completed Oracle support for audit probe
July 2010
GA
1.13
Fixed Oracle and MySQL support in GUI for when "other database" is used
Jun 28 2010
GA
1.12
Ported probe to Linux and Solaris, added MySQL support
Jun 11 2010
GA
1.11
Built using SSL-supported libraries
Feb 2010
GA
1.10
Added option to configure database and database user
Jan 2010
GA
1.03
Data administration parameters in the Setup dialog are now correctly read
Aug 2009
GA
1.02
Configuration tool fix: numeric sorting on Event ID and Checkpoint ID columns
May 2009
GA
1.01
Configuration tool fixes
Jan 2009
GA
1.00
Initial version.
Dec 2008
GA
Probe-Specific Software Requirements

The audit probe requires:
UIM robot version 3.00 or later.
Controller version 3.50 or later.
The audit probe is only supported on Windows platforms.
automated_deployment_engine (Automated Deployment Engine) Release Notes

The automated_deployment_engine probe is a multi-threaded java-based probe that handles package and probe deployment in Admin Console.
It also can be used to deploy robots and probes using an XML file.
Contents
Revision History
Revision History
Version
Description
State
Date
8.31
Version number update to support CA UIM 8.31
GA
August
2015
8.20
What's New:
GA
March
2015
GA
December
2014
GA
September
2014
GA
June 2014
Support for request.cfg deployment with robot v7.70. Upon startup, controller looks for request.cfg, a user-created text
file that enables automatic deployment of the specified probes to the robot. Previously, these requests could only be
facilitated by distsrv, which still handles them by default. To have a v7.70 robot direct the requests to ADE, use the Raw
Config utility to add the deploy_addr parameter to robot.cfg, and specify the UIM address of the ADE probe:
deploy_addr=/<domain>/<hub>/<robot>/automated_depl
oyment_engine
Build number validation for archive import (negative, non-numeric,0), which maintains consistency in the archive by
preventing ADE from importing packages with bad build numbers.
Package included in UIM Server 8.2 distribution.
Fixed Defects:
Improved reliability with large deployments.
Improved performance with remote robot deployment (deploying a robot whose specified parent hub is NOT the hub
where ADE is deployed).
8.10
Remote robot deployment reliability has been improved for slow networks.
ADE probe package dependency resolution has been fixed when using EQ as the dependency type.
Solaris native installer init script now returns correct error code when being called.
ADE restarts properly when called from Infrastructure Manager and Admin Console.
2.00
ADE 2.0 is a Java-based redesign of distsrv with scalability, flexibility, and maintainability in mind.
Admin Console now uses ADE for package deployment, which is two to five times faster than with distsrv. (Infrastructure
Manager continues to use distsrv).
ADE uses an archive cache to do quick package lookups and file extractions. Files that have been extracted are
maintained in a cache to speed up package deployment. This cache is cleared at startup.
ADE Archive stays in sync with the file system, and the archive-sync solution is much more scalable than distsrv
package forwarding. Processing is distributed, rather than going through a single master distsrv.
1.31
Added support for AIX and zLinux.

Package included in NMS 7.6 distribution.
aws (Amazon Web Services Monitoring) Release Notes

The aws (Amazon Web Services) Monitoring probe remotely monitors the health and performance counters of various AWS services over a cloud
network. The probe lets you create profiles that monitor your AWS user account and fetches all the service data from the AWS CloudWatch. The
probe lets you configure various monitoring parameters on each service. Based on the configured parameters, the probe generates Quality of
Service (QoS) data and issues status alarms.
Note: The probe from version 2.01 and later is configured only through the Admin Console GUI.
Amazon Web Service (AWS): The AWS provides a decentralized IT infrastructure to multiple organizations. You can create an account
on the AWS cloud and can use its services as per your IT infrastructure requirements. The various capabilities of AWS include storage,
web-scale computing, database access, and messaging.
The probe provides monitoring of the following AWS services:
Health: The probe monitors the overall health status of the AWS services for all geographical locations. Alarms are generated based on
the status of all the AWS services.
Amazon Simple Storage Service (S3): This AWS service provides an interface for storing and fetching data at any time instance. The
probe generates QoS data based on the time consumed in storing and retrieving files.
Amazon Elastic Compute Cloud (EC2): This AWS service provides a flexible web-scale computing interface. The probe generates QoS
data and alarms that are based on the performance of various EC2 instances.
Amazon Elastic Block Storage (EBS): This AWS service provides a scalable storage volume facility for the EC2 instances. The probe
generates QoS data and alarms that are based on the operations that are performed on the storage volumes.
Amazon Relational Database Service (RDS): This AWS service manages relational databases that are stored in a cloud network.
AWS-RDS handles many database administration tasks and lets you perform other operations like setting up and scaling the database.
The probe generates QoS data and alarms that are based on the system metrics and database operations.
Amazon ElastiCache: This AWS service provides the AWS instances with an option of storing temporary data in a scalable cache
memory, and thus, increasing the processing speed. The probe generates QoS data based on the time consumed in accessing the cache
service and other parameters like amount of data stored and time taken to fetch the data.
AWS Custom Metrics: AWS provides some default metrics for all its services. Another feature of AWS is that you can create and
configure your own customized metrics, and store these metrics in the AWS CloudWatch for viewing, or monitoring purpose. These
metrics, which AWS does not generate, are called custom metrics. The probe lets you configure the custom metrics for QoS generation.
AWS Simple Queue Service (SQS): This AWS service lets you transmit data to other services using message queues. The probe lets
you configure the message queue properties for QoS generation.
AWS Simple Notification Service (SNS): This AWS service lets you manages the notification messages that a publisher sends and a
subscriber receives through a communication channel. The probe monitors the communication channel and generates QoS data based
on the status of the notifications.
AWS Elastic Load Balancing (ELB): This AWS service lets you route the traffic that comes from various applications across multiple
available EC2 instances. The AWS Monitoring probe monitors the ELB layer at group level and generates QoS data based on the status
of ELB layer.
AWS AutoScaling: This AWS service lets you accumulate different EC2 instances in a group. You can create an autoscaling group
according to the usage of the EC2 instances in various applications.The probe monitors the instance status at group level.
Important! Amazon charges the AWS account which the probe uses to monitor the AWS services. You must consider this fact while
configuring the probe for monitoring various AWS services.
Contents
Revision History
Prerequisites
Alarm Threshold Requirements
Fixed Defects
Known Issues
Revision History
This section describes the history of the revisions for the aws probe.
Version
Description
State
Date
4.02
Fixed Defects:
GA
September
2015
The probe displayed a profile in Failure state despite of a successful credential verification. Salesforce cases 00169402,
70000878.
Updated the documentation to describe that Namespace and Dimension are required in the scripts to display the custo
m metrics on the probe GUI. Salesforce case 00167924
Note: For more information, see the Custom Metrics section in the aws AC GUI Reference article.
4.01
Fixed an issue where NULL QoS value were generated for S3 service.
GA
June 2015
4.0
What's New:
GA
May 2015
GA
December
2014
Added the ability to create monitoring configuration templates. The templates allow you to apply consistent monitoring
configurations across multiple profiles using filters. The monitoring configurations apply across multiple instances of a
service and multiple profiles of the aws probe.
Note: Template Editor is available from probe version 4.0 or later on UIM 8.3 and above. Health and Custom Metrics
are not supported on Template Editor.
Factory templates for all monitors are available for Unified Dashboard.
Note: Factory Templates do not support Simple Storage Service (S3).
Added the ability to create AutoScale Groups on USM groups.
3.51
Removed the ReplicaLag monitor for the RDS service from the GUI from version 3.51 onwards, for all databases except
MySQL.
Note: When upgrading the probe from version 3.00 ~ 3.50 to version 3.51, you must delete the ReplicaLag key from the Raw
Configure option to stop unwanted alarms for databases other than MySQL.
3.50
Addition of ELB, SNS, SQS, and AutoScaling services.
GA
December
2014
3.01
Changed default value of Statistics field from Maximum to Average for EBS, RDS, ElastiCache services, and Custom
Metrics monitoring.
GA
September
2014
3.00
Addition of EBS, RDS, ElastiCache services, and Custom Metrics monitoring.
GA
September
2014
GA
June 2014
GA
June 2013
Beta
December
2009
2.01
First release of the probe for Admin Console GUI.

The probe is now available only through the web-based GUI and not through the Infrastructure Manager (IM) GUI.
Upgrade from previous versions to version 2.0x and later is not supported.
Removed the QOS_MACHINE_DEPLOYMENT_TIME metric.
The probe requires PPM probe version 2.34 for execution.
Note: Probe is supported from CA UIM 7.6 and later only.
1.10
Added Regional support for gathering metrics for QoS and Alarm.
Added configuration capabilities for Message Alarms for 7 Cloud watch Metrics.
Re-structuring of QoS Names.
Added option to configure the Log level.
Added the t1.micro instance option for Deployment sampler.
1.00
First version of the Amazon AWS probe.
Prerequisites
This section contains the prerequisites for the aws probe.
An AWS user-account with valid user-credentials, such as, Access Key and Secret Access Key.
EC2 Administrative Rights to allow the probe to access the AWS resource. When you assign the administrator access to a user, the
following policy is assigned, by default:
{
"Version": <version_number>
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}

The probe requires:
One or more Amazon AWS user-accounts, and EC2 administrative privilege.
The aws probe version 2.01 and later requires the following software environment:
Nimsoft Monitor Server 7.6 or CA Unified Infrastructure Management 8.0 or later.
This section lists the upgrade considerations for the aws probe.
The aws probe version 2.0x and later is available through Admin Console GUI only and not through the Infrastructure Manager (IM) GUI.
QoS names of the following AWS metrics have changed in version 2.0x:
Old QoS Name
New QoS Name
QOS_FileWriteTime
QOS_AWS_FILE_WRITE_TIME
QOS_FileReadTime
QOS_AWS_FILE_READ_TIME
QOS_DiskReadOps
QOS_AWS_DISK_READ_OPS
QOS_DiskReadBytes
QOS_AWS_DISK_READ_BYTES
QOS_DiskWriteOps
QOS_AWS_DISK_WRITE_OPS
QOS_CPUUtilization
QOS_AWS_CPU_UTILIZATION
QOS_NetworkIn
QOS_AWS_NETWORK_IN
QOS_NetworkOut
QOS_AWS_NETWORK_OUT
QOS_DiskWriteBytes
QOS_AWS_DISK_WRITE_BYTES
Removed the QOS_MACHINE_DEPLOYMENT_TIME metric in version 2.0.

You must deploy Probe Provisioning Manager (PPM) probe version 2.34 or later for configuring the aws probe version 2.0x or later.
When you install the probe version 2.01 then manually move the existing configurations, in case you are using the probe of version
earlier than version 2.01.
Delete all the versions of the probe that are earlier than version 2.01 as upgrade from a previous version to version 2.01 is not supported.
For viewing the new metrics that are introduced in the aws probe version 3.0, on the USM portal, you can perform any one of the
following actions:
Upgrade NMS 7.6 (or earlier) to CA UIM 8.0 and later.
Install the ci_defn_pack version 1.01 probe. You are required to restart the nis_server when you deploy the ci_defn_pack.
Important! You can install the ci_defn_pack probe from https://support.nimsoft.com
Alarm Threshold Requirements

The PPM probe maintains a table of subsystem IDs that are mapped to the probes. As of the current release, the subsystem IDs for this probe will
default to 1.1.19. The aws probe supports the following types of alarms:
Dynamic Alarms Thresholds
Static Alarm Thresholds
Time Over Threshold
Time To Threshold
If you are using either dynamic or static alarm thresholds, you can change the default entry to the appropriate subsystem ID.
Note: If you have upgraded NMS 7.6 to CA UIM 8.0 then you do not have to perform the following procedure.
Follow these steps:

1. In the Admin Console, click the black arrow next to the probe, select Configure.
3. Change the Static and Dynamic Subsystem (override) fields to 2.19.1.1..
Fixed Defects
This section contains the fixed defects for the aws probe.
Added a note in the S3 node that the file, for which you want to generate the QoS data, must be present in the AWS base folder.
Added a note in the Overview topic that the probe from version 2.01 and later is configured only through the Admin Console GUI and the
Infrastructure Manager GUI for the probe is not available.
Enhanced the description of the Profile Name field in the Add New Profile section in aws node.
Known Issues
When you save the configuration the probe restarts and data collection for AWS services starts again. This re-discovery of services slows
the GUI processing. You must re-load the GUI after the probe restarts.
When migrating to version 4.0 or later of the probe, you must manually clear the AutoScale alarms in USM. The new alarms generated by
the probe are displayed in the created AutoScale group in USM.
azure (Microsoft Azure Monitoring) Release Notes

The Microsoft Azure Monitoring (azure) probe remotely monitors the health and performance of Microsoft Azure infrastructure and services. The
probe enables you to connect to Microsoft Azure using certificates and discover monitorable Azure resources.
The probe fetches all the service data from different geographical locations and lets you create profiles that monitor your cloud services including
virtual machines (VMs), websites and storage. The probe lets you configure various monitoring parameters for each of these services. Based on
the configured parameters, the probe generates Quality of Service (QoS) metrics. You can also configure dynamic and static threshold values for
the QoS metrics to receive alarms.
Contents
Revision History
Prerequisites
Revision History
Version
Description
State
Date
2.10
What's New:
GA
June
2015
GA
Dec
2014
Beta
Dec
2014
GA
Aug
2010
On upgrading the probe from version 2.01 to 2.10 or later, only one Azure Subscription can be associated with a profile.
Ability to create monitoring configuration templates. The templates allow you to apply consistent monitoring configurations
across multiple profiles using filters.
Factory template for monitors available on the Azure Dashboard.
Support for dynamic variables using CA UIM 8.3 or later.
Fixed Defect:
Azure service health data was not populated on the probe GUI. Salesforce case 160988
2.01
2.00
Fixed an issue where the password was appearing as plain text in the probe logs.
Added support for monitoring the health and performance of Microsoft Azure infrastructure and services including virtual
machines (VMs), websites and storage.
Note: Probe is supported from CA UIM 7.6 and later only.
1.01
Fixed a bug in the default sampler template

Added support for localized alarm messages.
1.00
First version of the Azure probe.
Prerequisites
This section contains the prerequisites for the azure probe.
Jul
2010
An Azure user-account with valid user-credentials

A valid Azure subscription
Azure Management Certificate
A valid Key Store file.
This section lists the upgrade considerations for the azure probe.
The azure probe version 2.0x and later is available through Admin Console GUI only and not through the Infrastructure Manager (IM)
GUI.
For viewing the metrics that are available in the azure probe version 2.0x and later, on the USM portal, you can perform any one of the
following actions:
Upgrade your NMS version to NMS 7.6 or CA UIM 8.0 or later.
Note: The QoS of probe version 1.0 are no longer supported by the probe version 2.0x and later.
The 2.10 or later versions of the probe allow you to create configuration templates. The templates are applicable only to the specific
instance of the probe on the robot. Both new and existing profiles can be configured using templates.

The azure probe is installed on systems with the following minimum resources:
Memory: 4GB of RAM.
CPU: 2.93-GHz dual-core processor 64 bit

The azure probe runs on Red Hat Enterprise Linux 6.1 and Microsoft Windows 2008 R2 only. The probe requires:
CA Unified Infrastructure Management Server version 7.6 or CA Unified Infrastructure Management 8.0 or later
.NET Framework 3.5 Service Pack 1.
baseline_engine Release Notes

The baseline_engine probe follows QoS messages on the UIM message bus, samples this data and calculates baselines (normalized QoS
reference levels) on an hour-of-day and day-of-the week over a twenty-eight day period. This probe is scalable and leaves a low-memory footprint
for calculating baselines across enterprise-class IT environments. The baseline_engine's logging detail can be controlled at a fine level of
granularity, with individual settings for logging information such as maximum limit overages, caching, calculation performance, script handling
components, and skipped metrics.
To select the Compute Baseline option for applicable probes, make sure ppm v2.38 (or later), baseline_engine v2.34 (or later), and
prediction_engine v1.01 (or later) probes are installed and running on the hub robot. You must select the Compute Baseline option in a probe's
GUI before a baseline can be generated.
Revision History
Requirements
Probe Dependencies
Supported Platforms
Known Issues
Revision History
Version
Description
State
Date
2.6
What's New:
The baseline_engine v2.6, prediction_engine v1.31, and ppm v3.22 probes are included in the CA UIM Server v8.31
installer and are installed on the primary hub during installation.
GA
August
2015
GA
March
2015
GA
December
2014
GA
September
2014
GA
June 2014
baseline_engine supports the use of variables in the Custom Alarm Message and Custom Alarm Clear Message fields.
These variables are probe-specific.
2.5
What's New:
When you install ppm v3.11, baseline_engine v2.5, prediction_engine v1.2 are also installed on the hub robot.
baseline_engine supports the use of Custom Alarm Message and Custom Alarm Clear Messages.
A user cannot select the Compute Baseline check box if the baseline_engine probe is not installed or not running on
the hub robot. Help text for the Compute Baseline check box indicates whether baseline_engine is not installed or not
running.
2.4
What's New:
Updated the hub queue names to address character limitation.
A user must select the Compute Baseline check box on a probe's GUI before a baseline can be generated.
baseline_engine v2.4, prediction_engine v1.01, and ppm v3.0 should be installed on hub robots to allow users to
configure dynamic, static (if applicable), and Time To Threshold alarm and threshold settings for monitoring probes. (nas
and alarm_enrichment must be deployed to the primary hub to allow users to configure Time Over Threshold alarm and
threshold settings.)
2.34
What's New:
baseline_engine v2.34, prediction_engine v1.0, and ppm v2.38 should be installed on hub robots to allow users to
configure dynamic, static (if applicable), and Predictive Alarm settings for monitoring probes. (nas and alarm_enrichment
must be deployed to the primary hub to allow users to configure Time Over Threshold alarm and threshold settings.)
You can configure the baseline retention period (retentionPeriod) to be in the range of 3 to 12 weeks.
The command used to create baselines and thresholds for probes was modified.
The Setup Folder has two new configurable key-values: projection and predictiveAlarmSubject.
2.2
Added support for static thresholds.

Fixed issue in which the baseline_engine probe was not generating correct messages, leading to incorrect output in the
Alarm Console.
Performance improvements.
2.1
Dynamic threshold alarms no longer have different subsystem IDs than static threshold alarms.
GA
April 2014
2.0
Initial release of the probe.
GA
March
2013
Requirements
By default, the baseline_engine probe stores four weeks of historical QoS metric and baseline data on the local disk of the system that hosts it.
The following memory and disk allocations are recommended:
Number of Metrics to baseline
Memory Allocation
Disk Allocation
>10,000 metrics (default configuration)
1 GB
100 MB
10,000 to 50,000
1.5 GB
200 MB
50,000 to 100,000
2 GB
400 MB
The baseline_engine probe requires the following software environment:
CA Unified Infrastructure Management (UIM) 8.0 or later
ppm v2.38 or later
Robot version 5.23 or later
Console (typically installed with UIM 8.0 and later)
Probe Dependencies
The following table shows the versions of prediction_engine, ppm, nas, and alarm_enrichment probes that you should be running with the
different versions of baseline_engine. If the versions of these probes are mismatched, meaning you deploy baseline_engine v2.6 with an earlier
version of prediction_engine and ppm on a hub robot, the system will not be able to properly produce baselines for probes.
baseline_engine
prediction_engine
ppm
qos_processor
nas and alarm_enrichment
Released with CA UIM Version
2.6
1.31
3.22
1.25
4.73
8.31
2.5
1.2
3.11
1.24
4.67
8.2
2.4
1.1
3.0
1.23
4.6
8.1
2.34
1.01
2.38
1.23
4.4
8.0
Supported Platforms
Refer to the Compatibility Support Matrix for the latest information about supported platforms. See also the Support Matrix for Probes for more
specific information about the probe.
The baseline_engine probe and qos_processor probe are distributed as part of CA UIM. The deployed versions of baseline_engine and
qos_processor should match the versions included with version CA UIM running on the UIM Server. The qos_processor probe saves the
baseline data to the UIM database. See the Probe Dependencies table in the article for more details.
If you install baseline_engine on secondary hubs, see the baseline_engine deployment information for more details about multi-tier
deployment.
The baseline_engine probe is available as part of NMS from version 6.50 and later, or UIM v8.0 and later.
The baseline_engine will not install or operate on versions of NMS earlier than 6.50.
For baseline_engine v2.2 and earlier, by default the projections key in the Setup folder is set to False. If you upgrade to baseline_engine v2.3 or
later on a hub where a previous version of baseline_engine was running, the projections key-value defaults to False. After the upgrade, if you
decide to change the projection key value to True, change the setting before the baseline_engine calculates any baselines. See the
"baseline_engine Raw Configuration" article for the version of baseline_engine you're running for more details.
Note: If a primary hub and a secondary hub are running different versions of the baseline_engine probe, for consistent behavior you
should set the projections key-value for all baseline_engines to False.
Known Issues
Restart Required After Upgrading to UIM 8.1 From UIM 7.5
Hub Queue Names Character Limit
java_jre1.7 Required

Problem:
I have upgraded from UIM 7.5 to UIM 8.1. Some of the installed probes, such as prediction_engine, appear grayed out which means the probes
are not working.
Solution:
After upgrading from UIM 7.5 to UIM 8.1, restart the UIM Server. Probes should function properly after the restart.
Note: When upgrading to UIM 8.2 from UIM 8.1, you are note required to restart the UIM Server when the upgrade is complete.
Hub Queue Names Character Limit

Problem:
Hub queue names are not displayed properly.
Solution:
With baseline_engine v2.4, the queue names have been updated to address the 64-character limit.
Problem:
The prediction_engine and baseline_engine probes require the hub on which it is installed to have a Java environment pointing to java_jre1.7. If
there is a mismatch between the version of Java the secondary hub's environment is pointing to and the probe's Java dependency, some of the
java-based probes (including prediction_engine and baseline_engine) might not start.
In addition to the probe not starting, you might also see an error similar to the following:
Sep 19 17:23:10:955 [2624] Controller: Max. restarts reached for probe 'baseline_engine' (command = <startup java>)"
This error appears in the probe's log file:
baseline_engine.log file located at:
/Nimsoft/Probes/SLM/baseline_engine
prediction_engine.log file located at:
/Nimsoft/Probes/SLM/prediction_engine directory
In some instances, if prediction_engine and baseline_engine are already running on a secondary hub and you deploy another java-based probe
that requires the environment to point to a version of Java earlier than java_jre1.7, prediction_engine and baseline_engine might fail to start after
the deployment. In this case, no errors appear in the log files for prediction_engine and baseline_engine.
Solution:
In either situation, redeploy java_jre7 to the secondary hub and then restart the entire robot.
Important! If prediction_engine and baseline_engine were calculating baselines or new metrics and an error condition arises, these
calculations will be inaccurate from the time the error condition began. After prediction_engine and baseline_engine are restarted,
baselines generated by baseline_engine will be accurate after sufficient samples have been collected and the predictive alarm metrics
will begin again at the top of the next hour after restarting the robot or the prediction_engine probe.
billing Release Notes
The billing probe collects data from the usage_metering probe, analyzes it, maps it to CA Unified Infrastructure Management subscriptions,
calculates the billable items, and creates a billing report with summary and detail information.
Contents
Revision History
Hardware and Software Requirements
Revision History
Version
New Features and Fixed Defects
State
Date
8.20
Includes a new subscription pack for Big Data probes
GA
April 2015
GA
September
2014
GA
June 2013
GA
March
2013
GA
November
2012
This probe version is intended to be installed in tandem with usage_metering v2.11 or v8.0.
8.00
Generates billing reports on a scheduled basis.

Supports automated upload of billing reports using the webgtw probe.
Includes the latest subscription files bundled with the billing probe. The subscription files are automatically imported and
configured for the billing probe on startup, removing the need to configure separate offline subscription files.
This probe version is to be installed in tandem with usage_metering v2.11 or v8.0.
2.11
Helps usage_metering v2.11 to address a SQL Constraint Violation that can occur during report generation if scans do
not complete before the start of the next day.
Fixed a defect that could cause report generation to take too long when a large amount of usage data was collected.
This version is to be used with usage_metering v2.11.
2.10
Supports distributed instances of usage_metering.

Modified report layout.
2.00
Probe collects and analyzes data from usage_metering probe and creates a billing report.
Hardware and Software Requirements

Hardware
1 Ghz CPU
2048 MB RAM
Software
Robot 5.70 or higher
java_jre package (for Windows and Linux) version 1.70 or higher
solaris_jre package (for Solaris) version 1.70 or higher
The billing probe is typically deployed to the primary hub. The usage_metering probe must reside on the same robot as the billing probe, and
must be configured as the primary instance of usage_metering. See the topic v8.0 usage_metering Deployment for information on primary and
secondary instance types.
capman_da Release Notes

The capman_da probe allows CA Capacity Command Center (CA CCC) to collect data for the following CA UIM probes:
clariion (CLARiiON), v1.65
cdm (CPU, Disk, and Memory), v5.21 and later
ibmvm (IBM VM), v2.14 and later
vmax (VMAX), v1.30
vmware (VMware), v6.30 and later
Revision History
Version
Description
State
Date
2.9
Initial version.
GA
June 2015
2.9.2
Updated version.
GA
December 2015
Security Requirements
The capman_da probe requires open TCP communication to the Data Manager. All firewalls between CA UIM and CA CCC should be configured
to allow TCP traffic to flow freely, from the CA UIM primary hub robot and the capman_da probe, to the Data Manager.
By default, the Data Manager uses thrift service port 8082. Verify that the Data Manager thrift service port on your system is set to 8082.
Data Collection Requirements

The CA UIM probes must be deployed and configured to collect data. The capman_da probe is installed on the primary hub.
If the capman_da probe is not installed on the primary hub, it does not have visibility to all QOS_Messages published within the
UIM deployment.
Since the matching_metric_type is set to 5:1, you must enable the VMAX probe monitors, using the QoS mapping names.
General Use Considerations

The capman_da probe configuration is available through the Admin Console user interface only, and not through the Infrastructure Manager (IM)
user interface.
casdgtw (CA ServiceDesk Gateway) Release Notes
The casdgtw probe is a gateway between the CA Unified Infrastructure Management and the CA Service Desk. The probe works by subscribing
to alarm assignments. If an alarm is assigned to the user specified in the probe's Setup, the alarm is entered as a Service Desk Call Request.
Contents
Revision History
Revision History
This section describes the history of the revisions for the casdgtw probe.
Version
Description
State
Date
2.42
Added support for CASD version 12.9
GA
November
2014
2.41
Fixed the activity log related defect, where the probe is saving the activity logs even when the option is not selected on the
probe GUI.
GA
December
2013
GA
December
2013
GA
April 2013
GA
December
2012
GA
September
2012
GA
February
2012
GA
December
2011
GA
September
2011
GA
June 2011
2.40
Added support for establishing connection between the probe and CASD Server over HTTPS protocol.
Enhanced probe performance while creating, updating, or closing tickets.
Earlier the probe was behaving abruptly as the number of processed alarms increased significantly resulting in huge cfg
size. Some of the commonly reported issues were: unable to create incidents, creating incidents but not displaying
incident Id, CFG is not getting updated properly, probe is creating duplicate tickets for one alarm and acknowledging the
alarm is not updating the ticket status.
Provided Backward Compatibility while upgrading probe for already created incidents.
2.34
Fixed unnecessary periodic logging at CASD side on every update.

Fixed last successful check timestamp issue for closed incidents.
2.33
2.32
Added capability to assign alarm generated tickets to specific group and reassign them to another group, on when alarm
severity changes.
Modified the probe to provide the ability to add CA Service Desk login activity during the creation, update and closure of
incidents generated from Alarms.
Fixed the problem of old CA Service Desk Incident Statuses not getting removed from closed ticket status list.
Made Incident ID custom field case insensitive.
Fixed issues with the CASD users not able to view the tickets even when they were having the same Incident Area as
the ticket.
2.31
Added support to configure and use a separate set of field mappings that can be used independently during create,
update, and closure of incidents.
Added support to automatically resolve text to associate UUID values.
2.30
Updated configuration section for addition of Owning System and Ticket Status fields.
Updated configuration section for Editing or Closing an Incident to reflect Owning System configured.
Added sections to map a customs value instead of a single Alarm Field.
Added support to select individual mapped field to sync Incident with updates to Alarm in NMS.
Added support to sync all mapped Incident fields with updates to Alarm in NMS.
2.22
2.21
Added Support for Urgency Mapping For CASD version 12.5

Modification done for CI mapping
Added support for alarm severity mapping with service desk severity/priority
2.11
String Nimbus replaced with nimsoft
GA
March
2011
2.10
Added support for:
GA
February
2011
Mapping of alarm severity with service desk severity.

Mapping of alarm content with service desk summary.
Mapping of alarm hostname with service desk configuration items.
Status check for configuration item.
2.01
Added support for Linux and Solaris.
GA
December
2010
GA
February
2006
Added support for TNT2 & internationalization.

Modified the closed incident retreival query
Fixed the Test connection issue.
Fixed the crash on Linux machine.
Added support for two way synchronization of incidents/alarms.
Added support for checking CASD server disconnection.
Added support for probe restart functionality after CASD server is detected up and running.
Added support for offline management for alarms.
Added support for assigning incident id to custom fields after alarm is assigned.
Added support for timezone handling for synchronization process.
Added support for configurable CASD user to whom alarms will be assigned.
Added support for field mapping for custom Field1Field5 and User Tag1, User Tag2.
1.01
SDgtw was renamed to casdgtw to avoid naming conflict with other providers' Service Desk products.
Added timeout for SD function calls to the config.

The casdgtw probe should be installed on systems with the following minimum resources:

The casdgtw probe requires the following software environment:
Nimsoft Monitor Server 7.1 to 7.6 or CA Unified Infrastructure Management 8.0 or later
CA Service Desk server
cassandra_monitor (Cassandra Monitoring) Release Notes

The Cassandra Monitoring (cassandra_monitor) probe constantly monitors the internal performance and resource usage throughout a node in a
Cassandra cluster. Each node in the Cassandra cluster should be installed with the probe for a comprehensive monitoring experience. The probe
uses operating system commands, Cassandra API calls, and the JMX layer that is supported by Cassandra. The information is presented to the
cluster administrator as metrics, alarms, and reports in CA Unified Infrastructure Management. You can select and schedule an extensive range
of checkpoints to meet the needs of your specific monitoring requirements.
Contents
Revision History
Revision History
Version
Description
State
Date
1.0
Initial version
GA
March 2015

The machines on which the probe is deployed must be functioning Cassandra nodes. The nodes must be running Apache Cassandra version
2.1.x, or DataStax Cassandra Community Edition version 2.1.3.

The probe requires the following software environment:
CA Unified Infrastructure Management Server v7.6 or later
Note
We recommend that the CA Unified Infrastructure Management (UIM) Server and Unified Management Portal (UMP) are the same
version.

Java Virtual Machine (JVM) version 1.6 or later (deployed as part of the probe package)
1. Install the package into your local archive.
2. Drop the package from your local archive onto the targeted robot.
3. Use Admin console to access the probe configuration GUI or raw configure options.
None

This probe cannot be configured through Infrastructure Manager (IM).
ccm_monitor (Cisco CallManager Monitoring) Release Notes

The Cisco CallManager Monitoring (ccm_monitor) probe is a tool for managing the health and performance of CallManager systems and services.
Cisco CallManager is the software-based call-processing component of the Cisco IP Telephony solution that manages IP telephony devices and
call services over the data network. The CallManager is a Cisco Windows 2000 system that runs on a Media Convergence Server (MCS). It
provides functions such as managing call setup, controlling devices, and collecting statistics on call quality. It can manage IP phones, media
processing devices, voice gateways, and multimedia applications.
Contents
Revision History
Feature List
Requirements
Supported Platforms
Considerations
Revision History
Version
Description
State
Date
1.53
Fixed a program failure when using user-defined object(s).
Beta
Apr 2011
1.52

Fixed QoS Message issue (no qos_max found for Disk and Memory Usage).
GA
Dec 2010
1.40
Sep 2010
1.30
Added support for Windows x64 platform.

Fixed usage of SNMP request timeout.
Jan 2010
1.26
Rebuilt with new pt library (increased timout to 300 sec on remote list_services).
Nov 2008
1.25
Added possibility to disable AllObjectMode for perfmon.
Mar 2008
1.24
Fixed potential problem with SNMPQueryFree not being called (could leave open UDP ports).
Feb 2008
1.23
Added logging when checking monitors.

Fixed potential program failure.
Jan 11 2008
1.22
Fixed program failure (after upgrade from 1.0x or 1.1x to 1.20 or 1.21).
Jan 10 2008
1.21
Added support for delta computations.

Fixed potential program failure.
Dec 2007
1.10
Fixed User-defined objects (Add/Remove objects when probe restarts).

Fixed User-defined objects containing dots ('.') (I.e IP-addresses).
Added QoS on checkpoints "CallManager Memory"
Increased timeout in Phonetable dialog.
Nov 2007
1.09
Fixed delivery of QoS on "Disk Usage" and "Memory Usage".

Fixed deltaAttempted and deltaCompleted when calls not yet have been made.
Fixed Heartbeat alarm message.
Fixed User-defined objects (Add/Remove objects when probe restarts).
Fixed User-defined objects containing dots ('.') (I.e IP-addresses).
Added QoS on checkpoints "Available Physical Memory", "Total Memory", "Memory in use".
Added "General Setup" option "Disable ntservices" (probe will not fetch ntservices metrics).
Sep 2007
1.08
Improved UI support for environmental checkpoints. Fixed unit settings for 'CallManager Memory' object.
Fixed problems with QoS and USER OBJECTS.
Added ping timeout override possibilities where this may be a problem.
Fixed issues with UI update where profile-name and host settings differed.
Dec 2006
1.06
Fixed problems with SNMP detection. Fixed issues with CallManager 4.1.x performance objects.
Mar 2006
1.04
Initial version
Dec 2005
Feature List
This probe monitors a set of checkpoints on defined agents running the CCM software. The probe includes a set of predefined checkpoints
available on most hosts running the CCM software. These checkpoints are grouped in different classes, and you can choose to hide checkpoints
that are not available on the hosts.
The probe also includes a GUI, which can be used to:
Configure the general properties of the probe.
Define the hosts to be monitored. Group folders can be created to place the hosts in logical groups.
Activate the checkpoints to be monitored and set the monitoring conditions for these checkpoints.
Create alarm messages.
Monitor the different checkpoints. The measured values will be presented as a graph.
View call summary on a per hour and per day basis.

Extend the monitoring checkpoints to include your own Cisco performance objects.
The probe is QoS enabled, supporting the Nimsof SLA system. It will send QoS data on profiles where it has been enabled.
Requirements
This section contains the requirements for the ccm_monitor probe.
Cisco CallManager 3.x, 4.x, Nimsoft probes: >=perfmon 1.11, >=ntservices 2.21.
None
Supported Platforms
Please refer to the:
Compatibility Support Matrix for the latest information on supported platforms.
Support Matrix for Probes for additional information on the probe.
Considerations
This section contains the considerations for the ccm_monitor probe.
The ccm_monitor package will require the correct version of perfmon and ntservices in the local archive prior to the probe installation. Please
ensure that you have the correct version in your local archive. The distribution server will automatically install the required packages during the
installation of the ccm_monitor.
Warning messages from perfmon in the CCM event-log
To resolve this problem, run the following commands at a command prompt in the %SystemRoot%\System32 folder to unload and reload the IIS
performance dynamic-link libraries (DLLs). After you run these commands, the warning messages are not logged:
unlodctr w3svc
unlodctr msftpsvc
unlodctr asp
unlodctr inetinfo
lodctr w3ctrs.ini
lodctr ftpctrs.ini
lodctr axperf.ini
lodctr infoctrs.ini
After you run these commands, you must restart your computer for the changes to take effect. The problem is described in the following
knowledge base article: Q267831
How to disable perfmon AllObjectMode:
If the probe does not receive values of the performance counters Cisco CallManager.CallManagerHeartBeat and Cisco TFTP.HeartBeat during
the first poll interval, the perfmon AllObjectMode will be set automatically.
To disable this functionality:
The perfmon_all key needs to be set to -1 using Raw Configure. This key is located in the section /profiles/. If the key doesn't exist, create it and
set to -1.
cdm (CPU, Disk, Memory Performance Monitoring) Release Notes

The cdm probe monitors CPU, disk, and memory to detect performance bottlenecks.
The probe provides two main benefits:
Generate alarms: Based on configured threshold values it generates alarms to take corrective actions immediately.
Generate trending data: The trending data is sent as Quality of Service (QoS) data to the data_engine probe. This facilitates capacity
planning for the monitored system. For example, you can see how disks are filling up over time and plan batch jobs based on CPU
utilization.
Contents
Revision History
Known Issues
Revision History
This section describes the history of the probe updates.
Note: Support case(s) may not be viewable to all customers.
Version
Description
State
Date
5.61
Fixed Defects:
GA
December
2015
Beta
December
2015
Probe was consuming high CPU when disks were mounted during run-time. Support case number 70004776
On RHEL platform, the cluster disks were displayed as local or network disks on the cdm Infrastructure Manager (IM). S
upport case number 00160058
Note: You must use cdm version 5.61 with the cluster version 3.33 to view the cluster disks on the cdm Infrastructure
Manager (IM).
5.60
What's New:
Added two new alert metrics, CpuErrorProcesses and CpuWarningProcesses, to define the number of top CPU
consuming processes in the probe
Added support to enable the default QoS for Memory Usage in percentage.
Fixed Defect:
Updated the cdm IM GUI Reference to state that the probe uses the mount entries as in /proc/mounts file in Linux to
display the file system type of devices that are remounted to a different location. Salesforce case 246152
5.51
What's New:
GA
September
2015
GA
July 2015
GA
June 2015
GA
May 2015
GA
April 2015
GA
March
2015
Added support to ignore iostat devices from monitoring, using regular expressions on Linux, Solaris, and, AIX platforms.
Salesforce case 00168980
Added support to ignore the devices configured through super package. Salesforce cases 70000803, 00167576
Fixed Defects:
Added two new keys sliced_cpu_interval and sliced_memory_interval in the Raw Configuration section of the probe.
These keys are supported for AIX platform. Salesforce case 00160805
Note: See Options Configured Using Raw Configure section in the v5.5 cdm IM Configuration article for more
information related to these keys.
The probe generated the local file system disk missing alarm message for all type of disks (Network, Local, and,
Shared). Salesforce case 00162388
Note: The probe generates the updated message only on a fresh deployment of the probe.
The probe crashed when disk delta QoS were enabled and alarms were configured through custom profile. Salesforce
case 00169654
The probe calculated the value of Physical Memory Utilization metric incorrectly. Salesforce case 70000322
The probe generated false reboot alarms. Salesforce cases 00161914, 70001349, 00168047
5.50
What's New:
Three new Metrics QOS_LOAD_AVERAGE_1MIN, QOS_LOAD_AVERAGE_5MIN and QOS_LOAD_AVERAGE_15MI
N have been added on Linux, Solaris, AIX and HP-UX platforms.
Added a section in the Troubleshooting article to explain that using entitled capacity can lead to CPU usage above 100
percent on AIX platforms. Salesforce case 00164529.
Fixed Defects:
On Solaris platform, some robots sent reboot alarms on restarting. Salesforce cases 00157066 .
The probe was unable to generate data related to computer uptime. Salesforce case 00157375.
5.42
What's New:
Upgraded support for factory templates.
5.41
What's New:
Upgraded OpenSSL to version 1.0.0m.
Rolled back the alarm severity level changes made to the cdm version 5.30 to make these levels consistent with version
5.21.
Note: Refer to the Upgrades and Migrations section for more information related to alarm severity level changes.
5.40
What's New:
Added support to subtract buffer/cache memory usage from the used physical memory for HP-UX and Solaris platforms.
Fixed Defect:
The probe did not save the monitor configurations for a clustered disk when configured through the Admin Console GUI.
5.31
Added support for factory templates.
5.30
New features added in this release:
Beta
March
2015
GA
February
2015
Beta
February
2015
GA
January
2015
GA
December
2014
GA
October
2014
Added a Filesystem Type Filter field to specify regular expression and automatically select matching file system(s) to be
monitored.
Added clustered environment monitoring to the Admin Console GUI of the probe.
Added a Enable Space Monitoring checkbox to allow the probe to monitor network disk usage metrics.
Fixed Defects:
Disk space alarms in custom profiles were generated with zero values when disks were not available or not mounted. S
alesforce case 00155117
The probe generated messages with different severity levels for the same alarm in Windows and Linux environments. S
The probe generated File system not available alarm in linux and solaris environments even if the file system was
ignored. Salesforce case 00152438
5.21
A new key QOS_DISK_TOTAL_SIZE has been added in fixed_defaults under disk in the Raw Configuration section of the
probe. The key is supported for Windows, Linux and AIX platforms. Salesforce case 00155861
Fixed defects:
The probe displayed the debug log even though the log level was set to 0. Salesforce case 00143837
The probe crashed on AIX platform when deployed for the first time. Salesforce case 00156478
5.20
Fixed an issue where the probe was publishing some host names with non ASCII characters. Salesforce cases: 00150465,
00153872
Two new Metrics QOS_IOSTAT_KRS and QOS_IOSTAT_KWS have been added on Linux platform and four new Metrics Q
OS_IOSTAT_RS, QOS_IOSTAT_WS, QOS_IOSTAT_KRS and QOS_IOSTAT_KWS have been added on AIX platform.
Note: These new Metrics are configurable only through Admin Console GUI.
5.11
Fixed Defects:
The probe was generating false boot alarms. Salesforce cases: 00148483, 00149480, 00137376, 00150365, 00146355,
00148673, 00148121, 00148737
Warning messages were shown in logs. Salesforce cases: 00151892, 00150149
Incorrect alarm messages were shown in logs for CPU data. Salesforce case 00151892
5.10

Added the device iostat monitoring functionality for Linux, Solaris, and AIX platforms through the Infrastructure Manager
GUI from CA UIM 8.0 onwards. This feature is configurable through the Raw Configuration Section only.
Added the Regular expression feature in the Custom Tab for custom local disk (for Windows platform) and custom local
and NFS (for linux, solaris and AIX platforms). This feature is configurable through the Infrastructure Manager GUI only.
For making the Device Id of shared drive and local drive identical, a key allow_remote_disk_info has been introduced in
the Raw Configuration section. Salesforce case 00146394
Fixed Defects:
The Device Id and Metric Id were missing for QOS and alarms when file system was mounted on Linux through CIFS. S
On restarting, the probe was unable to mark CIFS drive as network drive and hence generated wrong Device Id and
Metric Id.
5.02

New QoS metrics for aggregated inbound/outbound/total traffic for all the network cards on a server.
New disk metrics for monitoring disk size and disk read/write throughput, as well as system and user memory utilization.
Note: These new features are supported on Windows, Linux, and AIX platforms and are configurable only through
Admin Console GUI.
We now support extended hostnames (more than 8 characters) for HP-UX 11i v2 or later. Salesforce case 00136356
4.91
Fixed Defects:
July 2014
Probe was suppressing all alarms for different iostat metrics. Now, a different suppression key is used for different iostat
alarms of a given device. Salesforce case 00139484
Note: User has to manage the already suppressed alarms manually.
Probe was not generating QoS for any iostat metric when the Set QoS Source to robot name instead of computer
hostname option is selected in the controller probe. Salesforce case 00137858
Note: PPM version 2.35 or later is required for these fixes to work as the iostat feature is configurable only through
Admin Console GUI.
4.90
June 2014
4.81
Fixed an issue of QoS definition which were getting generated even if the respective QoS messages were inactive.
March
2014
4.80
March
2014
Device iostat monitoring functionality for Linux, Solaris, and AIX platforms through Admin Console GUI from NMS 7.5
onwards.
Support for monitoring the CIFS (shared Windows disk mounted on Linux) and GFS (clustered environment disk) file
systems.
4.78
4.77
Fixed the issue of alarms, which are generated through CPU custom profile and the cpu_total profile are having same metric
id though having different suppression key.
Fixed a defect for storing the password in encrypted format while mapping a new shared disk. Earlier the probe was
storing password in clear text format. You can delete and then map again the existing shared disks for encrypting their
passwords.
February
2014
January
2014
Fixed a defect of wrong subsystem Id when the probe is deployed on Linux environment. Earlier the probe was using
subsystem Id of 3.3.xx series, by default, which is reserved for the nas probe. Now it is using 1.1.xx series of subsystem
Id, by default.
4.76
Fixed erroneous defects of the probe defaults
October
2013
4.75
Fixed a defect related to erroneous missing D drive alarms.
October 2
013
4.74
Fixed a defect by removing extra logs, which are being logged by the probe.
Updated default configuration of the probe.
4.73
Fixed an issue of sending a false alarm when cluster disk is out of scope.
September
2013
July 2013
Added fix to issue related to when edit alarm message show 0% threshold for memory alert.
Fixed a defect causing default values for low and high thresholds of 'Disk usage change and thresholds' are coming
incorrect.
4.72
Added fix to issue related to When editing CDM disk usage values, percentage jumping to MB.
May 2013
Fixed a defect causing probe to use 100% CPU in case of hot adding a CPU in a Linux VM.
4.71
Fixed a defect to set the threshold to 0.
April 2013
Added a Timeout feature to overcome hang situations for NFS.

Fixed an issue where CDM sent large uptime in case windows performance monitor returns a negative value.
Fixed a defect where cdm clear message does not contain disk name.
4.70
Added functionality for calculating CPU related statistics calculations considering LPAR in AIX.
June 2012
Added functionality to monitor space for windows share.

Added target override for memory based QoS.
4.60
Fixed an issue where CDM does not alarm on stale filesystems.

Corrected System Load Clear alarm text
4.55
Fix default setting for NFS space check.
March
2012
August
2011
4.54
Fixed internationalization defects. Changed share authentication test order to 'user/password', 'impersonation', 'implicit'.
Fixed percent / inode conversion integer overflow situation on disk profile configuration.
June 2011
Alarm message variable cleanup.

Changed text of processor queue length / system load alarm checkbox, including 'Alarm on' to clarify its use.
Added 'type' variable for cpu and memory alarm situations.
Fixed default alarm assignment on new custom cpu profile.
Boot alarm fix.
Fixed incorrect cluster disk alarm source introduced in version 4.43.
Added option to allow QoS source as target name where appropriate.
Service Oriented Configuration uninstall section issue fixed.
Added 'label' variable for windows disk alarms.
Fixed source and target for QOS_COMPUTER_UPTIME Quality of Service message to be consistent with the source
and target of other Quality of Service messages.
Fixed cpu usage calculations for Quality of Service measurements when QoS Interval multiple larger than 1.
Fixed swap Quality of Service message for situations where swap size is 0.
Made probe permission consistent between platform sections in the package.
Corrected individual CPU calculations for alarms.
Fixed problem detecting change in number of active cpus on solaris systems.
Fixed an issue where Previous cpu list is still exist in cases of detecting change in number of active cpus on solaris
systems
4.44

Fixed the QoS interval reported when using interval multiples.
January
2011
Fixed problem with 0 last values in clear alarms.

The 0-paging is no longer interpreted as unable to fetch paging data on Solaris.
4.43

December
2010

4.41
Modified the caption for field "Send short QoS source".
September
2010
4.40
September
2010
Added support for separate polling intervals for alarms and QoS.
Added support to configure target for Total CPU QoS.
Added support to send QoS source as short name (For Windows) or full name (For Linux).
Added support to ignore filesystems by giving regular expression.
Added a user interface to configure default values for discovered disks.
Added code to remove white space from all sections.
Added fix for memory leak.
4.30
Enhanced the probe to use /proc/mounts on Linux systems.

CPU Alerting support for User, System, Wait, Idle.
4.22
Active state of disk missing alarm read from default disk settings.
June
2010
May 2010
Added support for sending alarms only after the required samples are received.
4.21
The 'ignore_filesystem' and 'ignore_device' are now also implemented for Windows systems.
Fixed the issue where custom disk profile uses the percent/MB setting from the global profile.
4.20

Modified for easier upgrade in cloud environment; when cluster disk is discovered, a local profile for the disk will be used
as default configuration for the cluster disk.
Fixed the disk samples problem also for cluster disks.
Added support for custom profiles.
Added support for 'nfs_space_check' key in the default disk parameter section
March
2010
February
2010
4.11
Fixed number of samples for disk monitoring not being read properly.
September
2009
4.10
Added support for Linux systems with glibc 2.2.
September
2009
4.05
Fixed CPU data gathering issue on AIX systems.

Fixed CPU data gathering issue on TRU64 systems.
September
2009
Fixed upgrade problem with QoS values for memory paging.

4.04
4.03
Multi CPU difference calculation is corrected.
Solaris: Fixes error situation that could occur if a parse error happens in the first sample collected.
June
2009
May 2009
Solaris: Fixes parsing problem on 128 cpu systems.

Removed support for HP-UX 11.00
AIX: Fixes parsing problem with vmstat output causing paging value errors.
AIX: Suppressing internal alarm for initial memory data collection.
CPU multi diff test for clear alarm fixed so that clear works for this alarm situation even if the CPU multi max alarm
check is not enabled.
No initial clear on disabled checkpoints.
Using default disk profile for discovered cluster disks.
Extended cluster support.
Added support for Windows on Itanium 2 systems (IA64).
3.82
Fixed GUI startup problem for AIX version 6.
March
2009
3.81
Rebuild following NimBUS library fixes.
December
2008
3.80
Added connection_status callback function to support improved share status information. Implemented Ctrl+S in
configuration tool to save window setup.
Renamed Processor Queue Length to System Load for UNIX/Linux. Note that the same Quality of Service table
(Processor Queue Length) is still used.
Modified Processor Queue Length calculation for Windows - the Queue length is now divided by the number of
processors.
Enabled decimal point use for System Load alarm threshold and Quality of Service messages.
Changed usage display to convert to appropriate unit in disk table.
Added "rebooted" alarm option and alarm message.
Added the following alarm variables:
(for all) robotname, hostname.
(for disk) size_mb, size_gb, free_mb, free_gb, free_pc, limit_mb, limit_gb, limit_pc.
(for inodes) total_num, free_num, free_pc, limit_num, limit_pc.
Fixed disk_history problem with hidden disks.
Added option for sending Quality of Service message on network disk availability.
Added QoS for network disk availability.
Added option to monitor disk usage change.
Added log size option
October
2008
3.72
Enabled inode threshold configuration for deactivated probe.

Updated OS type recognition to be able to detect Windows Vista and Windows 2003 Server correctly.
September
2008
Fixed inode history initialization for discovered disk.

Fixed share name handling.
Modified configuration tool to present updated message list for Queue Length alarm message.
Added sanity check for interval and sample values.
Corrected reading of default settings for inode QoS and use of percentage.
Corrected configuration tool alarm coloring on disk configuration as the coloring did not exactly represent probe alarming
behavior.
Added the option to gather memory paging QoS series both in kilobytes per second as well as pages per second.
Note: For version 3.72 and higher of this probe, NimBUS Robot version 3.00 (or higher) is a prerequisite. You are advised to
carefully read the document "Upgrading the NimBUS Robot" before installing/upgrading.
3.54
Corrected handling of Windows disk quotas.
May 2008
3.53
Fixed alarm message problem with missing network disks.
April 2008
3.52
Fixed deadlock situations for AIX_5, SOLARIS_8_sparc and TRU64.

Fixed: Interchanged memory and disk data-collections intervals.
3.51
Modified logic to determine when clear alarm should be sent for nfs mounted file systems.
When a new disk is detected the probe will do a full restart to correctly initiate the disk. UNIX: Added monitoring of
inodes on filesystems. Note: Linux systems with ReiserFS filesystems may show 0 inodes (the same result should be
visible with the command 'df -i').
3.43
Windows: Added sanitycheck on cpu data.

HP-UX: modified calculations of swap space usage.
March
2008
January
2008
October
2007
Modified QOS table name for memory paging when paging is calculated in pages per second. In previous versions
QOS_MEMORY_PAGING was used for memory paging regardless if the calculations where done in kilobytes per
second or pages per second. Now QOS-MEMORY_PAGING_PGPS will be used when pages per second is specified.
Note that for users already using this option old data may need to be moved to the new table and that SLA's and SLO's
may need to be modified.
3.42
UNIX: Added new versions to supported platform list:
May 2007
HPUX_11: 32bit (PA-RISC)

LINUX: 32bit (Glibc >=2.3)
SOLARIS_10: 32bit (x86) 3.42
Additional logging for new and missing disks.
3.32
AIX: Fix bug which caused physical memory information in the get_info callback to be incorrect.
February
2007
3.31
AIX: Added support for flag 'mem_buffer_used' in setup. If set to 'yes' the used memory will include the file cache and be
consistent with the data from the 'vmstat' utility. Default is 'no' to be compatible with other platforms which to not report
file cache as used memory as it is still available to programs.
January
2007
Windows: Swap memory usage now reflects the pagefile usage.

Solaris 8 and higher: support for checking filesystems over 2TB.
3.26
3.25
3.25 display problems fixed
AIX_5: Do not report buffer cache as used physical memory.
July 2006
July 2006
Fixed problem with reporting physical memory over 4GB on Windows 2000/XP/2003.
Fix on Solaris, Tru64 and AIX: Allocated a bigger buffer for CPU monitoring data. The maximum number of CPU's
increased from 32 to 128.
3.23
Updated discovery template.
June
2006
3.22
3.21
Tru64: Fix physical memory detection on systems with over 4GB RAM
Added monitoring of physical memory usage.
June
2006
May 2006
Corrected memory statistics on HP-UX, Tru64 and SGI.

Added option to use pages/second as unit for paging instead of Kilobytes/second. Note that changing this may upset
your QoS series.
Added new discovery template.
Added recognition of local file systems without drive letter on Windows XP and Windows 2003 Server.
Enabled monitoring of disk space usage of network file system (NFS). Note that enabling this might cause slow
operation of the probe when there are network problems.
Linux: Fix error finding paging data on 2.6 kernels. Also changed counter so that only swap paging is counted, not other
VM related IO.
3.17
Linux: Fix detection of installed physical memory over 4GB.

Unix: Utility calling routine changed to send a SIGKILL to the child process directly when the child needs to be stopped.
Eliminates the need for a separate SIGCHLD handler to avoid zombie process.
3.12
Fixed bug where a specific configuration on multi-cpu systems would cause a segmentation fault.

The cdm probe should be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. The probe OOB configuration requires 256MB of RAM

The cdm probe requires the following software environment:
Probe v5.0 and later requires:
Probe Provisioning Manager (PPM) probe version 2.38 or later (required for Admin Console)
For Iostat monitoring:
sysstat package must be installed on Linux and Unix platforms
NMS 7.6 or CA UIM 8.0 or later
Probe v4.9 and earlier requires:
Nimsoft Monitor Server 5.1.1 or later
Robot 5.23 or later
For Iostat monitoring:
sysstat package must be installed on Linux and Unix platforms
NMS 7.5 or NMS 7.6
Probe Provisioning Manager (PPM) probe version 2.35 (required for Admin Console)
February
2006
April 2005
For AIX 5.x users
The memory gathering routines use libperfstat , which must be installed. It is found in the bos.perf.perfstat and bos.perf.libperfstat file-sets. To
verify that you have the correct file-sets installed, you can run:
# lslpp -l | grep perf
The system displays the following output depending on the installed versions:
bos.perf.libperfstat
bos.perf.perfstat
5.1.0.35
5.1.0.35
COMMITTED
COMMITTED
Performance Statistics Library

Performance Statistics
Installing the probe:

If you do not see bos.perf.libperfstat and bos.perf.perfstat in the output from the command, you must install those files.
2. To ensure a successful installation of the probe package (drag and drop), it is required that a java.exe (version not critical) exists in the
path.
4. Double-click the probe for initial configuration. The installation wizard is launched automatically. The wizard prompts you for the path to
the correct version of IBM JVM and other environmental files required by the probe.

When upgrading the cdm probe from a previous version to version 5.00, the new metrics are not visible on the Admin Console GUI.
Install the PPM probe version 3.12 or later on the main robot to view the new metrics.
For viewing the metrics that are available in the cdm probe version 5.50 and later, on the USM portal, you must:
The cdm probe versions prior to version 5.30 had different severity levels for the same alarm on different platforms. Changes had been
made in version 5.30 to make the severity level same for an alarm on different platforms. These changes have been rolled back in the
cdm version 5.41. This version has the same configuration as the versions prior to 5.30 for the alarm severity levels. The following table
summarizes the changes made in the alarm severity levels on different versions of cdm.
Alarm Name
Platform
Severity Level prior

to version 5.30
Severity Level on upgrading to version 5.30, 5.31 or

5.40 (Overwritten on Upgrade)
Severity Level with version 5.41 (Not

Overwritten on Upgrade)
CpuWarning
Windows
Minor
Warning
Minor
PagefileWarning
Windows
Minor
Warning
Minor
PagingWarning
Windows
Minor
Warning
Minor
PhysicalWarning
Windows
Minor
Warning
Minor
SwapWarning
Windows
Minor
Information
Minor
DiskWarning
Windows
Minor
Warning
Minor
InodeWarning
Windows
Minor
Warning
Minor
BootAlarm
Windows
Warning
Information
Warning
InternalAlarm
Linux
Major
Minor
Major
Note: Upgrading to version 5.41 will have no impact on your existing cdm probe configuration irrespective of the probe version running
in your environment.
In case,
You are running cdm version 5.30, 5.31, or 5.40
Your severity levels have already changed on upgrading to any of these versions
You want to roll back to severity levels of the version prior to 5.30
Contact CA support for a customized probe package.
Known Issues
The 32-bit versions of this probe are unable to monitor terabyte (TB) sized disks.
On Windows platform, the first interval data is not retrieved for the Top CPU consuming processes when the probe starts executing. From
second interval onward, the probe displays the alarm correctly.
When running this probe in a clustered environment, you should not set the flag /disk/fixed_default/active to yes since this will cause
problems with the disks that appear and disappear with the resource groups. This flag is unavailable through the GUI, and only reached
through raw configure method or by directly modifying the cdm.cfg file.
The probe returns only the first eight characters of the system host name when deployed on HP-UX 11i v1 or earlier. For example, if your
system host name is hpuxsys123, then the probe returns hpuxsys1. The probe uses this trimmed host name as the QoS target.
Version 4.8x: The UMP GUI displays the consolidated list of the iostat QoS metrics for all the monitored devices. Each QoS name
contains the device name for locating the device-specific QoS.
Version 4.0x: Changed behavior when running in a cluster together with cluster probe version 2.2x. The probe will receive information
about cluster disk resources from the cluster probe and create monitoring profiles for these based on the 'fixed_default' settings. These
profiles are automatically registered with the cluster probe to ensure continuous monitoring on cluster group fail over. The cluster group is
used as Alarm and Quality of Service source instead of the cluster node.
Note: When upgrading to a newer version of the cdm probe, the old monitoring profiles for the cluster disks are overwritten with the new
ones.
celerra (EMC Celerra Monitoring) Release Notes

The EMC Celerra Monitoring (celerra) probe monitors the health and performance of Celerra storage systems. EMC Celerra storage systems
support environments from mainframes to desktops and every flavor of server, application, cloud, and business service.
Contents
Revision History
Migration Considerations
Preconfiguration Requirements for Migration
NAS Subsystem ID Requirements
Revision History
Version
2.01
2.00
Description
Removed support for templates using Template Editor interface.
What's New:
State
Date
Beta
September
2015
Beta
September
2015
GA
April 2015
GA
October
2014
GA
July 2014
The probe is now available only through the Admin Console.

Alarms for metric monitors are now configured using standard static thresholds.
configurations across multiple profiles using filters.
Added factory template for monitors available on the Celerra Unified Dashboard.
Added support for dynamic variables using CA Unified Infrastructure Management 8.31 or later.
Added support for localization.
The following monitors in Control Station are no longer available:
cs_zUserName
cs_zPassword
cs_zIPAddress
Added support to define or modify the maximum size of the log file.
Note: The probe requires CA UIM 8.1 or later.
Fixed Defect:
The probe did not parse device data correctly and displayed inaccurate data. Salesforce case 00158809
1.65
What's New:
Changed the heap size to: -Xms512m -Xmx1024m. Salesforce case 00156337
1.64
What's New:
Provided Source Override option to allow users to provide their own QoS source instead of using the default source.
Added support for VNX and VNX2.
Certified the probe for:
VNX Models: VNX5300 and VNX5700
VNX2 models: VNX5400 and VNX8000
1.63
Fixed Defects:
Fixed a defect where QoS Name field is shown as blank.
Fixed a defect where probe was sending clear alarm on every interval.
Fixed a defect where configured monitor was not assigned to the new file system. Salesforce case 00115057
1.62
Fixed an issue where the probe was not able to generate QoS data for Disk Groups.
April 2014
1.61
Fixed Metric Id issues.
September
2013
1.60
Fixed defect of celerra subsystem id.
September
2013
Fixed defects around localization.

1.50
Certification of probe functionality on the EMC VNX platform.
September
2011
1.40
Added "Total Count" metrics for storage capacity and number of disks, etc.
August
2011
Enabled caching of CI metric values.

Critical data gathering bug fix from code reading (static vs. dynamic values).
Critical bug fixes.
CI enabled as per TNT2.
1.15
Critical bug fixes.
May 2011
CI enabled as per TNT2.
1.02
Bug fixes
March
2011
1.00
Initial release
February
2011
0.99
Fixed the issue in which right-clicking didnt add to template.
January
2011
Fixed the column headers on the resource group view.

Implemented a consistent usage of Kbytes, Bytes, GBytes, etc.
Implemented correct unit labels on ss_* measurement fields as well as sssp_* measurement fields.
Updated the Celerra.cfx template file to include all the recently added QOS measurements.
0.98
Added fix to allow QOS measurements to be correctly captured and passed along to the Service Level Management
console.
January
2011
Changed the source of the QOS measurements being captured, from the Control Station IP address to the Resource
Name.
0.97
Added top level Network node.

Added second data set for demonstration and testing.
January
2011
0.96
Implemented bug fixes.
January
2011
0.95
First version of the probe.
December
2010

The celerra probe must be installed on systems with the following minimum resources:
Memory: 2-4 GB of RAM. The OOB configuration of the probe requires 256 MB of RAM
CPU: 3-GHz dual-core processor 32-bit or 64 bit

The celerra version 2.00 or later requires the following software environment:
CA Unified Infrastructure Manager 8.1 or later
Java JRE 7 or later
Celerra Control Station Linux release 3.0 (NAS 6.0.36)
ssh connectivity to EMC Celerra management node
Install the CI Definition Pack version 1.12 or later to view the metrics on the USM portal. You must restart the nis_server probe after you
deploy the ci_defn_pack.
Install the Wasp Language Pack version 8.40 or later to view the correct celerra object on the USM portal. You must restart the wasp pro
be after you deploy the wasp_language_pack.
Install the MPS Language Pack version 8.33 or later to view the metric type on the Admin Console. You must restart the service_host pr
obe after you deploy the mps_language_pack.
Important! You can download ci_defn_pack, wasp_language_pack, and mps_language_pack from https://support.nimsoft.com.
The version 1.65 or earlier requires the following software environment:
CA Unified Infrastructure Management Server 7.5 to 7.6 or CA Unified Infrastructure Management 8.0 or later
Celerra Control Station Linux release 3.0 (NAS 6.0.36)
Java JRE 6 or later
ssh connectivity to celerra management node
Probe Provisioning Manager (PPM) probe version 2.38 or later (for Admin Console GUI only)
The migration considerations for the probe from the 1.65 to a later version are listed as follows:
Migration is only supported for profiles created in the Infrastructure Manager GUI of the probe.
Downgrade is not supported from version 2.00 to an earlier version of the probe.
Alarms generated in previous versions of the probe are not suppressed after migration to version 2.00 or later.
The Infrastructure Manager GUI of the probe is no longer available.
Templates and configuration done through templates in version 1.65 or earlier are not supported in version 2.00 or later.
Any custom QoS will automatically be reset to the default QoS for the monitor. You also cannot create custom QoS or alarm messages
for the probe.
Preconfiguration Requirements for Migration

You must preconfigure the probe after you migrate from an older version of the probe to version 2.00 or later.
Follow these steps:
1. Deactivate the data_engine probe.
2. Execute the following query in the database:
update s_qos_data
set ci_metric_id = null
where probe = '?'
The query nulls out the ci_metric_id column in the s_qos_data table for the target probe entries.
3. Activate the data_engine probe.
As the probe publishes QoS messages, data_engine updates the null records with the correct keys.
4. Download and deploy the following packages on the robot with the probe:
ci_defn_pack 1.12 or later
wasp_language_pack 8.40 or later
mps_language_pack 8.33 or later
5. Restart the following probes:
baseline_engine
nis_server
wasp
service_host
6. Delete all the files in the util directory in the windows local temp directory.
Repeat this step for each instance of UIM accessing the robot.
7. (Optional) Delete the old alarms in the USM portal to stop viewing duplicate alarms.
8. (Optional) Set up new subsystem IDs in the nas probe, if you are using CA UIM 8.31 or earlier.
For more information, see NAS Subsystem ID Requirements.
9. (Optional) Deploy ppm version 3.23 or later to view the new subsystem IDs in the Admin Console.
You can skip step 9 if you skip step 8.

Alarms are classified by their subsystem ID, identifying which part of the system the alarm relates to. These subsystem IDs are kept in a table
maintained by the NAS probe.
Note: You must deploy ppm version 3.23 or later to view the new subsystem IDs in the Admin Console.
If you are using celerra 2.00 with CA UIM 8.31 or earlier, you must add the following subsystem IDs manually using the NAS Raw Configuration
menu:
Key Name
Value
2.14.1.1
Control Station
2.14.1.2
Data Mover
2.14.1.2.1
Block Map
2.14.1.2.2
File System
2.14.1.2.3
System Stats
2.14.1.3
Network ICMP
2.14.1.4
Network IP
2.14.1.5
Network TCP
2.14.1.6
Network UDP
2.14.1.7
Storage System
2.14.1.7.1
Disk Group
2.14.7.1.2
Spindle
2.14.1.7.3
Storage Processor
2.14.1.8
Storage Volume
2.14.1.8.1
Volume Disk
2.14.1.8.2
Volume Group
2.14.1.8.3
Volume Meta
2.14.1.8.4
Volume Slice
2.14.1.8.5
Volume Stripe
To update the Subsystem IDs using Admin Console, follow these steps:
1. In the Admin Console, click the icon next to the NAS probe, select Raw Configure.
2. Click on the Subsystems folder.
3. Click on the New Key Menu item.
4. Enter the Key Name in the Add key window, click Add.
The new key appears in the list of keys with a blank value.
5. Click in the Value column for the newly created key and enter the key value.
6. Repeat this process for all of the required subsystem IDs for your probe.
7. Click Apply.
The Subsystem IDs are updated to the NAS probe.
To update the Subsystem IDs using Infrastructure Manager, follow these steps:
1. In Infrastructure Manager, right click on the NAS probe, select Raw Configure.
3. Click on the New Key... button.
4. Enter the Key Name and Value
5. Click OK.
7. Click Apply.
Note: Ensure that you enter the key names as-is including the period (.) in the end for correct mapping.
cisco_monitor (Cisco SNMP Device Monitoring) Release Notes

The cisco_monitor probe sends SNMP GET queries to the specified SNMP enabled Cisco devices. The probe then changes the query result into
configured alarms and quality of service (QoS) messages for Service Level Agreement (SLA). You can create and configure a profile to integrate
the device with the CA UIM monitoring solution.
The probe supports SNMPv1, SNMPv2c and SNMPv3. The probe includes a set of predefined SNMP OID variables available on most Cisco
devices, such as CPU and memory usage, state of temperatures, fans, power supply and voltages.
Contents
Revision History
Revision History
Version
Description
State
Date
3.37
What's New:
GA
January
2016
The unit for Cisco Buffer Misses monitor is changed to count in the probe and USM. Support case number 00115932
Updated Known Issues and Workarounds for an issue where the probe was unable to apply the default variables to new
profiles. Support case number 246752
3.36
Fixed the defect of cisco_monitor probe for displaying the host name of the device in the IP address field of the USM. This
issue happens when a monitoring profile is configured using the host name instead of the IP address. Now, the probe
automatically resolves the IP address for the given host name and displays it in the USM.
January
2014
3.35
Fixed SNMPV3 issues
September
2013
3.34
Fixed: cisco_monitor probe shows incorrect status color (yellow) when it should be green.
June 2013
3.33
Fixed: QOS not logged for all environment checkpoints.

Fixed: Cisco devices show in USM by IP instead of name.
Fixed: Temperature State, Power Supplies State not handled properly.
April 2013
3.32
Fixed: Cisco_Monitor checkpoint status is incorrect for checkpoints of type status.

Fixed: Unchecking the Encrypt Community String still encrypts the community string.
3.31
Fixed issues realted to pressing OK when Items in Array is 0 was giving warning on GUI.
For Fan State and Temperature State, Average use to come.
January
2013
August
2012
Unable to configure interval other than the 4 listed values via Bulk Configuration.
3.30
Feature added to send alarms based on x average value for checkpoints.

Feature addition to specify wildcard or regex in profile_name value.
3.22
3.21
Fixed SOC issues.

Added password validation msg for SNMPv3 in GUI.
The help button will now display online help instead of CHM.
August
2012
June 2012
March
2012
3.20
Added password validation msg for SNMPv3 in GUI.
March
2012
3.11
Implemented IPv6 Compatibility.
December
2011
Snmp query related bugs fixed.

Updated libraries.
3.10
Implemented IPv6 Compatibility.

SNMP query related bugs fixed.
3.04
Fixed add/edit profile dialog

(display the configured privacy protocol)
October
2011
March
2011
(do not require passphrase for SNMPv3 NoAuthNoPriv).

3.03
Stepped version and rebuilt due to wrong build released as v3.02.
March
2011
3.01
Fixed the qos target in case of memory_usage_perc checkpoint.
March
2011
3.00
Added support for high and low threshold alarms in checkpoints.

Added a button in toolbar to fetch current values.
January
2011
Added default configuration template.

Added bulk configuration template.
2.92
Added fixes for web-based Service Oriented Configuration.
January
2011
2.91
Minor code optimization in case of alarm sending.
October
2010
Fixed memory leaks in callbacks.

Added fix to properly create host profile during drag-n-drop of IP/ hostname from Wordpad.
Support for Web based Service Oriented Configuration (SOC).
2.90
Initial internationalized version.
October
2010
2.80
Added support for SOLARIS_10_amd64 and SOLARIS_10_i386.
June 2010
2.72
Fixed memory leak introduced in version 2.70.
February
2010
2.70
December
2009
2.60
Updated get_oids to fix inconsistent GUI behaviour when using ping sweep.
Fixed an issue when the GUI hangs in host not responding case.
Added code to change the format of wordpad file similar to interface_traffic or net_connect probe.
Added fix to delete selected profile(s) from the right pane.
Added fix to only update the OID (checkpoint) that is being modified.
Added configured callback timeout in GUI.
December
2009
2.54
2.53
Added fix in GUI to properly save the configuration.
July 2009
Fixed GUI crash
April 2009
Added support for $group variable.

Fixed some minor UI issues.
Fixed the issue of digit grouping.
Fixed the issue of delta value alarms and QoS sent on first interval.
Changed values from actual to delta in case of buffer misses checkpoints.
Receive many alarms in case of fan state checkpoint.
SNMPv3 upgrade issue.
Added some GUI fixes.
Added snmp walk for power, voltage and fan state.
Added checkpoints for buffer misses.
Support for win/linux 64 platforms and solaris.
QoS and bulk add support.
Drag and drop support from wordpad to GUI.
Added SNMP v3 support.
Known issue in 2.52 beta version:
Query non-responding hosts slows the GUI.
2.05
Added SNMP Timeout and Retries options.
July 2008
2.04
Changed QoS definition used by variable "Memory Percent Free" (more information found further down).
May 2008
Fixed rounding issues.

Fixed minor GUI issues.
2.02
2.01
Fixed issue regarding dashboards (and Probe Utility) not working correctly when communicating with probe.
Fixed issue regarding disable QoS.
March
2006
GA
December
2005
Added and changed several icons in GUI.

The cisco_monitor probe must be installed on systems with the following minimum resources:
Memory: 4 GB of RAM. The OOB configuration of the probe requires 256 MB of RAM.
CPU: 3-GHz dual-core processor 32, or 64 bit.

The cisco_monitor probe requires the following software environment:

When upgrading the cisco_monitor probe from a previous version to version 3.37, the default variables do not apply to new profiles. You
must reset the default parameters for the concerned checkpoints if you are upgrading the probe to version 3.37.
cisco_qos (Cisco Class-Based QoS Statistics Monitoring) Release Notes
The cisco_qos probe performs SNMP GET queries to Cisco SNMP devices supporting the Cisco class-based QoS MIB, transforming the query
result into alarms and/or Quality of Service for SLA purposes. Users can configure the profile to their requirements in order to integrate the device
seamlessly into the Nimsoft monitoring solution. The probe supports SNMPv1, SNMPv2c and SNMPv3.
Contents
Revision History
Revision History
This section describes the history of the revisions for the cisco_qos probe.
Version
Description
State
Date
1.23
Fixed Defects:
GA
February
2015
The probe was restarting randomly. Salesforce case 00130736

The probe was not able to increase the log size greater than 100 KB. Salesforce case 00149552
1.22
Fixed SOC defect.
1.21
1.20
June
2012
GA
January
2011
GA
December
2010

1.11
Changes to libraries with respect to configuration locking.
1.10
Made changes to libraries with respect to configuration locking.
GA
June
2010
1.10
GA
March
2010
1.08
Fixed automatic re-mapping of indexes.
GA
January
2010
1.07
Added QoS and Alarm Identification settings (Host Address or Profile Name)
GA
July 2009
1.06
Increased SNMPWalk limitationfrom 300 to 3000 entries.
1.05
Fixed discovery and configuration of service policies in cases where the same service policy is applied in both directions
(input and output) on the same interface.
November
2010
April 22
2009
GA
April 17
2009
GA
April 2
2009
Changed suppression id of alarms to reflect servicepolicy direction.

Changed QoS target names to reflect servicepolicy direction.
Fixed displaying of classmap thresholds.
1.04
Initial version.

The target SNMP agent must support the MIB-II ifTable and CISCO-CLASS-BASED-QOS-MIB.
To verify whether the target SNMP agent is QoS MIB compatible or not:
1.
1. Open the MIBs of the target SNMP agent in any MIB Browser tool.
2. Only those MIBs of the target SNMP agent that match the MIBs supported by CA UIM are displayed.
Probe v1.0 or later requires:
CA Unified Infrastructure Management Server 7.6 or CA Unified Infrastructure Management 8.0 or later
Java JRE 6 or later

Prior to version 1.05, the probe did not take into account that the same service policy could be applied in both directions (input and output) on the
same interface. When upgrading to version 1.05, alarms will get new suppression ids and QoS targets will change in order for the probe to take
the service policy direction into account.
cisco_ucm (Cisco Unified Communications Manager Monitoring) Release Notes

The Cisco Unified Communications Manager Monitoring (cisco_ucm) probe monitors the health and performance of Cisco UCM systems. UCM is
the software-based call-processing component of the Cisco IP Telephony solution. The application manages IP telephony devices and call
services over the data network.
You can use the probe to perform the following functions:
Define the hosts to be monitored
Groups folders can be created to place the hosts in logical groups.
Set the monitoring conditions for checkpoints.
Create your own alarm messages.
Create and monitor CAR profiles.
The probe can also be extended to monitor any available Cisco performance counters.
Contents
Revision History
List of Supported Products
Known Issues
Revision History
This section describes the history of the revisions for the cisco_ucm probe.
Version
Description
State
Date
1.84
Fixed Defects:
GA
January
2016
GA
February
2015
Updated the Known Issues section with limitation on backend database support to insert CAR details in NIS SLM
database. Support case number 246464
The thresholds were not updated on any of the monitors when modified templates were reapplied. Support case number
246048
For more information, see the Upgrade Considerations.
The probe displayed a yellow triangle and did not send alarms for missing checkpoints. Support case number 246088
For more information, see the Upgrade Considerations.
1.83
Fixed Defects:
Fixed a defect in which the probe was not able to overwrite the default value for the Logfile Size field. Salesforce case
00144671
Fixed a defect in which the default authentication message in profiles was incorrectly displayed as MsgError instead of
MsgAuthError. Salesforce case 00144674
Fixed a defect in which the profile status was always displayed green irrespective of the session state. Salesforce case
00144690
Fixed a defect in which the starting and stopping states in alarm messages were displayed as running. Salesforce case
00147705
1.82
Fixed a defect where the probe Infrastructure Manager (IM) GUI displayed AXL support and the document mentioned
AXL as a prerequisite. Salesforce case 00138332
GA
July 2014
1.81
Added an option for configuring the log file size through the IM probe GUI. Salesforce case 00131408
GA
July 2014
GA
June 2014
GA
January
2014
GA
November
2012
1.80
Added support for:

Cisco Unified Communications Manager (Call Manager) version 10.x
Cisco Unity Connection version 10.x
Cisco Unified Presence version 10.x
1.71
Fixed the defect of not resolving the server host name by the probe. Therefore, the probe generates an error that the
server is not responding.
Fixed the defect of not showing the Cisco RIS Data Collector service status on the probe GUI.
1.70
Added support for viewing phone list information

Added support for viewing product information monitored by a profile
Added support for configuring QoS and Alarm source
Added support for configuring negative values as threshold
Removed the extra activation check box from CAR Monitor screen
Removed Wildcard functionality while creating template.
Fixed memory leak.
Fixed high cpu utilization.
Added Probe Defaults for this probe.
1.64
Added a combo box for time zone offset
GA
June 2011
1.63
Fixed the timezone defect.
GA
May 2011
GA
February
2011
GA
December
2010
Added new feature to take input of the data engine address from the user.
1.61
Fixed collection of monitor values.

Improved collection and handling of auto-monitors.
Fixed duplicate naming issue in template (same counter name used in different objects).
Fixed missing data_engine issue (CAR/CDR data into SLM DB).
Fixed GUI issues on CAR report form.
Allow negative Timezone offset in CAR Profile
1.60

1.50
Added a fix to check the existence of service on the host node(s) when deploying services on that host node(s).
GA
December
2010
Added support for call data record analysis.

Implemented Automatic monitoring of new instances
Enhanced the cisco_ucm probe callbacks with data formatting supported by SDP.
Fixed minor GUI defect.
1.42
Added support for Cisco Unity Connection's NIS database information.
GA
June 2010
1.41
Added fix in GUI to properly save the monitor key while using templates.
GA
June 2010
1.40
GA
June 2010
1.25
Added fix in GUI for proper saving of the monitor key properly while using templates.
GA
April 2010
1.30
Added support for Cisco Unity Connection (2.x, 7.x).
GA
March
2010
1.24
Added code to create and deploy a template with wild card functionality based on instance.
GA
March
2010
Fixed the discovery of categories and counters.

1.23
Added wild card functionality.
GA
January
2010
1.22
Added fix to remove host node name from the monitoring object key.
GA
January
2010
GA
November
2009
Added fix to show QoS blank if it is disabled or set OFF.

Added fix to redeploy template properly.
Added sample template.
1.21
Added $state variable in message pool.

Added alarm message when host authentication fails.
Added fix in GUI to select multiple call manager process node and create one profile for each node.
1.20
Added template driven features.
GA
September
2009
1.11
Fixed QoS description for QOS_PROCESS_CPU
GA
June 2009
1.10
Fixed potential program failure (on concurrent calls to GetServiceStatus and CollectSessionData)
GA
April 2009
1.09
Fixed initialization of curl library.
GA
March
2008
Added logging of thread ids.

Added additional logging at log level
Fixed potential program failure when doing delta calculations. Improved handling of returned values from the axl web
service.
1.07
Fixed memory leak.
GA
December
2007
1.05
Fixed library issues.
GA
November
2007
GA
September
2007

Fixed potential hang/crash after "Add Profile" wizard.
Fixed response on authentication failures in "Add Profile" wizard.
Fixed memory leak (when no services was being monitored).
Fixed crashing issue when monitoring large number of checkpoints.
Fixed $variables in message pool.
Added error messages when no nodes where found during Add Profile Wizard.
Fixed Drag'n'Drop of Profiles between Groups.
Fixed various minor GUI issues
1.02
Changed handling of QoS's

Fixed update of connection state in GUI.
Fixed memory leak (if wrong username/password/)
Initial version

The cisco_ucm probe is installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. The OOB configuration of the probe requires 256MB of RAM

The cisco_ucm probe requires the following software environment:
List of Supported Products

The cisco_ucm probe supports the following Cisco Unified products:
Cisco Unified Communications Manager (Call Manager) 6.x, 7.x, 8.x, 9.x, 10.x
Cisco Unity Connection 7.x, 8.x, 9.x, 10.x
Cisco Unified Presence 7.x, 8.x, 9.x, 10.x
Cisco Contact Center Express 8.x
The probe has the following installation considerations:
Install the Cisco Unified Communication Manager (UCM) Monitoring probe on the same system as the FTP server.
Specify valid user credentials with administrative privileges to the Cisco UCM server.
The following services are needed by the probe:
Cisco AXL Web Service: This service is required only for Cisco Unified Communication Manager version 6.x to 8.x.
SOAP Real-Time Service APIs
SOAP Performance Monitoring APIs
Cisco Unified Communication Applications other than Cisco UCM can also support AXL Serviceability interface. For more information,
refer the official Cisco support and documentation.
The probe upgrade from an earlier version to 1.84 or later has the following considerations:
The probe does not update the thresholds when modified templates are reapplied before upgrading the probe.
After upgrading the probe, reapply the required templates.
The probe displays a yellow triangle and does not send alarms for missing checkpoints.
Set the failureCounterValue key in the Setup section of Raw Configuration to 1.
Known Issues
The probe has the following known issues:
Reporting functionality
Deploy the probe on a Windows Robot to operate Custom CAR Analysis Reporting.
Only Microsoft SQL Server is supported as the backend database to insert CAR details to the SLM NIS Database. For more information,
see the Set Up General Configuration sections of cisco_ucm AC Configuration or cisco_ucm IM Configuration articles, as applicable.
cisco_ucs (Cisco UCS Server Monitoring) Release Notes

This section contains the release notes for all versions of the Cisco UCS Server Monitoring (cisco_ucs) probe.
Contents
Revision History
Requirements
Considerations
Upgrading to v2.30
Migration Instructions
Error with IPv6 Address
Delay in QoS Data Publication
Cannot Rename Resource Profiles in Admin Console
Subsystem ID Alarm Message Displays a Subsystem ID of 2.5.3 Instead of 2.5.3.1.
Revision History
Version
Description
State
Date
2.33
What's New:
GA
August
2015
GA
March
2015
Added support for Cisco UCS Manager 2.2.

Added support for Admin Console configuration.
Added the ability to apply monitoring with templates in Admin Console.
Added documentation about how to format IPv6 addresses when used for a Uniform Resource Identifier (URI); use the Java
convention of enclosing an IPv6 address in square brackets. For more information, see the v2.3 cisco_ucs AC Configuration
and v2.3 cisco_ucs IM Configuration guides.
Added Operability and Visibility monitors to the following resources:
Chassis Memory Unit Environment Stats
Rack Memory Unit Environment Stats
Chassis Processor Environment Stats
Rack Processor Environment Stats
For more information about the above metrics, see cisco_ucs Metrics.
Fixed Defects:
Fixed a documentation defect in which information was missing about how to configure profiles (also known as resources) to
use LDAP authentication. Salesforce case 00144109
Fixed a defect in which the probe was intermittently unable to connect to the Cisco UCS environment. Salesforce cases 001
47793, 00156057, 00156322, 00157056
Fixed a defect in which delta values were incorrectly calculated.
Note: Monitors of the enumerator type only support current values and cannot calculate delta values.
2.15
Corrected an issue where available checkpoint metrics for Cisco UCS pools were not visible in the GUI. Salesforce case
00150525
2.15
Corrected an issue where device names with an "&" character were not displaying correctly.
GA
June
2014
GA
Dec
2013
GA
Jun
2013
Beta
Sep
2011
Corrected an issue where fault events that are less than 24 hours old were not received as alarms.
Corrected an issue where triggered alarms were not detected.
Corrected an issue with the display fault alerts.
2.14
Added the ability to set the number of retries for connecting to the Cisco UCS Manager server
Added functionality to handle API responses from the UCS Manager server which use special characters that are not escaped
properly.
2.01
Restructured probe using probe framework

Added support for UCSM 2.1
Added template to populate UMP Vblock Cisco UCS dashboard
Added network traffic statistics for Rackmount and Chassis
1.40
Added support for using "Ratio" on checkpoints.

Added support for using "delta per second" value definition.
Added IO Module metrics (Chassis and FEX).
Added Ethernet metrics for FEX IO Module backplane ports.
Added settings for UCSM XML API timeout, UCSM Ping timeout and probe logsize in GUI.
1.30
Fixed "% Usage" of pools.

Added support for Rack mounted units (Servers and Fabric Extenders).
Added metrics for Interface Cards (Server Blades inside Chassis).
Added support for multiple selection of thresholds (on "state" monitors).
Added support for Storage Controllers + Disks/Luns/Raid batteries attached to the server blades.
Fixed display of the various port types in the Fabric Interconnect modules (introduced in ucsm 1.4).
Fixed "Low-level" threshold issue (seen when a single monitor was configured).
Jun
2011
1.22
Fixed "% Usage" of pools.
Feb
2011
Fixed template deployment (avoid creating extra monitor with dn = *) Fixed various minor GUI issues.
Fixed refresh of inventory (GUI) when creating new profiles.
Changed logical grouping of ports on Fabric Interconnects.
Added option for importing UCS Threshold Policies into probe template.
Added "Aggregated Bandwidth" for the various Port types on Fabric interconnects modules.
Added metric ID for Server Blade "Association" metric.
Decreased number of queries to the UCS Manager when creating automonitors.
Fixed display of automonitors when using static override.
Added options for setting source of Alarms/QoS (Host Address or Profile Name).
Added metrics for UCS Service Profiles.
Added metrics for MAC Pools, Server Pools, UUID Pools, WWNN/WWPN Pools.
Fixed metric IDs for operState and adminState of class etherPIo.
Fixed refresh of inventory tree (GUI).
Added metric "Association" for UCS Server Blades (indicates if a service profile has been associated with the blade).
Added optional alarm message variables for affected object and cause, available for UCS fault translation into CA Unified
Infrastructure Management alarms.
1.14
Fixed automonitoring on Linux/Solaris (potential program failure).
Jan
2011
1.13
Fixed template monitor 'Overall Status' for ethernet ports in FabricInterconnects.
Dec
2010
Fixed automonitoring issue when no alarm threshold is set and user activates monitoring.
1.12
Fixed display of Equipment Tree when number of Chassis objects exceeds 10.
Nov 9
2010
Fixed potential program failure on realloc (w2K864).
1.10
Added automonitoring feature.
Nov 2
2010
Added support for wildcard templates.

Added support for Backplane/Fabric Ports on Chassis IO Modules.
Added "% Used" metric for Fabric Interconnect LocalStorage.
Added metric for Hypervisor and VM Status.
1.11
Fixed clear alarm issue for automonitors.

Fixed missing metric ids (used in extended NIS DB info).
Fixed display of selected message token for "low" thresholds (GUI only).
Added templates for Chassis, Blades, Fabric Interconnects and VMs.
Removed unwanted log entries.
Fixed potential program failure (seen on Solaris).
Nov 2
2010
1.02

Sep
30
2010
Only refresh cookie every 10 minutes in regular probe operation.

Added QoS support on state values.
Enabled licensing.
1.01
Fixed subsystem ID for faults.

1.05
Initial version of the probe.
Sep
20
2010
Sep 9
2010
Requirements
This section contains the requirements for the cisco_ucs probe.
None
Cisco UCS Manager: The probe is compatible with UCSM 1.4, 2.0, and 2.1.
CA Unified Infrastructure Management Server 5.1.1 or later
CA Unified Infrastructure Management robot version 5.32 or later
Java Virtual Machine version 1.6 or later (deployed as part of the probe package)
Infrastructure Manager v4.02 or later
.NET v3.5 on the hardware running the Infrastructure Manager application
Cisco Unified Computing System Manager (Cisco UCSM) v1.4 and later
Considerations
This section contains the considerations for the cisco_ucs probe.
The cisco_ucs probe is capable of monitoring the state of VMWare ESX Hypervisors and VMs installed on the UCS blade servers. This requires
that secure communication is set up between VMWare vCenter and Cisco UCS Manager (using the vCenter extension files). For more
information, see the Cisco documentation at http://www.cisco.com.
Upgrading to v2.30
Versions 2.30 is the first version of the probe to include support for applying monitoring with templates in Admin Console. To upgrade and then
apply monitoring with templates in Admin Console requires that all previous configuration be deleted. Because of this, we recommend that you
delete probe versions earlier than 2.30 and deploy a new v2.30 probe.
If you want to configure the probe using only Infrastructure Manager, you can upgrade from an earlier version to v2.30 without deleting any
previous configuration. However, not all features of v2.30 and later are supported in Infrastructure Manager.
Migration Instructions
Migration from versions of the cisco_ucs probe earlier than 2.01 to versions 2.01-2.10 is possible. The migration of configuration is limited to:
Migrating the templates (for Infrastructure Manager only)
Migrating the message definitions (for Infrastructure Manager only)
After migration to versions 2.01-2.10, resources configured in the previous version of the probe must be reconfigured (refer to the online help
topic Create a New Resource). After the resources are configured then migrated templates can be used to set up the monitoring of QoS metrics
and alarms.
Follow these steps to migrate from versions before 2.01 to the 2.01-2.10 version of the probe:
1. Download the cisco_ucs_migration probe from the internet archive to your local archive.
2. Download the cisco_ucs 2.01 or later probe from the internet archive to your local archive.
3. Drag and drop the 2.01 or later cisco_ucs probe to the robot where the previous cisco_ucs probe resides.
As part of this process the previous cisco_ucs.cfg file will be backed up as cisco_ucs.cfg.pre.2.00.
4. The probe is now ready to be configured with Resources and the templates from the previous probe will be available.
Known limitations/issues related to the version 2.01 or later migration process:
Resources will not be migrated.
Localized message tokens will not be available.
After reconfiguration of resources and monitors completes, any thresholds that are broken will trigger new alarms. It is a best practice to
remove any alarm messages from the previous cisco_ucs probe in the alarm console after the migration process.
Fabric Interconnect - Local Storage Monitors are not available.
Group configuration option does not exist in version 2.01.

Symptom:
When I configure a profile using an IPv6 address, I get a stack trace error that includes the exception: Caused by:
java.lang.NumberFormatException: For input string: "f0d0:1002:0051:0000:0000:0000:0004:443".
Solution:
Follow the Java standard of enclosing the IPv6 address in square brackets.
For example: The input string [f0d0:0:0:0:0:0:0:10.0.00.0] works. But the input string f0d0:0:0:0:0:0:0:10.0.00.0 causes a stack trace error that
includes the exception: Caused by: java.lang.NumberFormatException: For input string: "f0d0:0:0:0:0:0:0:10.0.00.0".

Symptom:
After I change the value definition for an alarm, the probe delays in sending QoS data to the Discovery Server.
Solution:
You can expect a delay in QoS publishing to correspond with the value definition for the alarm. For example: If you set the value definition to an
"average of n," the probe will wait n cycles before it sends any QoS data to the Discovery server. If you set the value definition to "delta," the
probe will wait two cycles before it sends any QoS data to the Discovery server.
If you want to decrease the time it takes for the probe to publish QoS data, lower the value definition so that it results in a shorter interval.
Cannot Rename Resource Profiles in Admin Console

Symptom:
Users cannot rename resource profiles in Admin Console with probe versions later than 1.4.
Workaround:
Rename profiles using raw configure.
Subsystem ID Alarm Message Displays a Subsystem ID of 2.5.3 Instead of 2.5.3.1.

Symptom:
The subsystem ID alarm message displays a subsystem ID of 2.5.3 instead of 2.5.3.1.
Workaround:
None at this time.
clariion (Clariion Monitoring) Release Notes

The Clariion Monitoring probe monitors the performance and availability of EMC clariion CX4 storage systems. The clariion probe uses navisec
CLI (a command-line tool available from EMC) that collects and stores data and information from the monitored clariion systems at customizable
intervals. You can define alarms that are generated when the specified thresholds are breached.
The clariion probe can monitor the following storage components:
Fast Cache
Hosts
LUNs
RAID Groups
Storage Groups
Thin Pools
Mirror Views
Storage Processors
Notes:
The 2.0 and later versions of the probe are available only through the Admin Console GUI and not through the Infrastructure
Manager (IM) GUI.
Standard static alarm threshold parameters are supported for the 2.10 version or later of the probe using CA UIM 8.2.
Static alarms replace all probe-specific alarm configurations in the probe monitors.
Contents
Revision History
EMC Clariion Supported Versions
Revision History
Version
Description
State
Date
2.11
Fixed Defect:
GA
January
2016
GA
June 2015
Beta
March
2015
Some metrics use multiple collection intervals to calculate metric value. The probe generated false alarms for these
metrics on each restart. Support Case Number 246156
2.10
What's New:
The probe version 2.0 and later is available only through the Admin Console GUI and not through the Infrastructure
Manager (IM) GUI.
The probe now includes the standard static alarm threshold parameters.
Note: On upgrading the probe from a previous version to 2.10, all the probe specific alarm configurations in the probe
monitors are automatically replaced by Static Alarms. The probe does not support rollback of these alarm configurations. The
following features are not yet supported in version 2.10:
Custom QoS creation and migration
Automonitors
Templates
For more information, refer to the Upgrade Considerations section below.
Added the following new metrics:
six LUN Metrics: Read IOPs, Write IOPs, Read Bandwidth, Write Bandwidth, Bandwidth and LUN Utilization.
one Mirror View Metrics: State Number
four SP Metrics: Blocks Read, Blocks Written, Total Reads and Total Writes.
Fixed Defect:
Updated Navisphere CLI version in Software Requirements. Salesforce case 00166569
2.00

The probe is now available only through the Admin Console GUI and not through the Infrastructure Manager (IM) GUI.
Added support to upgrade existing profiles from a previous version of the probe.
1.65
Fixed Issues:
March
2015
Corrected the metrics value of: LUN metrics- LUN Service Time, Storage Processor metrics- Utilization, Total IOPs,
AverageBusyQueueLength, Service Time and Response Time. Salesforce cases: 00148680, 00155222
Disabled the following LUN metrics: LUN Response Time and LUN Queue Length.
Added one new LUN metrics: Utilization
The probe was unable to monitor LCC state on VNX 5600. Salesforce case 00149979
The heap size for the clariion probe has been changed to: -Xms512m -Xmx1024m. Salesforce case: 00152761
1.64
Fixed a defect where the Source Override feature was not working properly. Salesforce case 00099959
Added support for VNX and VNX2.
October
2014
Certified the probe for:

VNX Models: VNX5300 and VNX5700
VNX2 Models: VNX5400 and VNX8000
Added three new LUN metrics: LUN Response Time, LUN Service Time and LUN Queue Length.
Added five new SP metrics: Utilization, Total IOPs, AverageBusyQueueLength, Service Time and Response Time.
Added three new SPE metrics: Management Modules, IOModules and Standby Power Supplies.
Added two new DAE metrics: Link Control Cards and Fans.
Certain metric names have been changed to achieve consistency in the way CA UIM reports metrics vs EMC.
1.62
Fixed a defect where the Infrastructure Manager (IM) GUI was not able to fetch and display the profile information when the
probe was opened from a remote machine.
July 2014
1.61
Fixed the defect of not displaying the disk metrics for a LUN. The metrics were available at device itself but not for the
LUNs, where are built from a pool. Now, the probe displays all disk metrics for LUN also.
January
2014
Fixed the defect of passing the Test button even when the NaviSecCli command fails. Now, the probe fails the
subsequent commands and the Test button when the NaviSecCli command fails.
Fixed the defect of not reflecting the updated message severity, when the Clariion system is not responding. Now, the
probe shows the updated message details when details are updated in the message pool irrespective of the Clariion
status.
1.60
1.60
Fixed Disk State for hot spare drives; now reports "Hot Spare Ready". Upgrading the probe to the 1.6 version overwrites the
existing (incorrect) Disk State configuration.
Added default templates.
Added simulation mode using recorded data.
December
2012
November
2012
Fixed parsing issue with some VNX naviseccli output.

Fixed null pointer exception when parsing info about removed drives.
Added check to avoid re-sending alarms for old Clariion logs at probe startup.
Added metrics for Thin LUN IOPS, Throughput.
Fixed incorrect Empty disk status on last non-empty drive.
1.50
1.40
Certification on VNX hardware platform.

Added usage metering metrics and CIs.
Fixed major defects.
1.30
1.20
Added code to process CI metrics.

New metric for Disk State.
New relay to convert Clariion Events to NMS alarms.
September
2011
August
2011
May 2011
March
2011
Use bundled jre package.

1.10
GA version of the probe.
December
2010
1.04
Fixed a problem with enabling monitors using only the checkbox.
December
2010
1.03
Added support for templates.

Added new Thin Pool metrics, including Percent Full, Percent Available, Percent Subscribed, Consumed Capacity, and
User Capacity.
December
2010
Added new RAID Group Percent Free metric.

Added new LUN metrics, including Currently Trespassed and Trespasses (Past Hour).
Added new Mirror View State metric.
Added new FAST Cache category with metrics for Mode, Percent Dirty (SP A & SP B), Size, and State.
Added a checkbox to enable or disable relaying Clariion faults as Alarms.
1.02
Added configurable scope to probe GUI.

Updated thin pool processing for FLARE 30.
November
2010
Made scope configurable for navicli commands.

1.00
EMC Clariion Supported Versions

The probe is certified on EMC Clariion CX4-480.

The version 2.10 of the probe requires the following software environment:
October
2010
Java JRE version 7 or later (for Admin Console only)

Navisphere CLI version 7.33 or later
The version 2.0 and earlier of the probe requires the following software environment:
Navisphere CLI version 7.33 or later
The upgrade considerations for the probe from versions 2.0 and later are listed as follows:
You must delete all the files in the util directory of the windows local temp directory.
This process must be repeated for each instance of UIM that accesses the robot. The process clears the cache and avoids opening the
Infrastructure Manager GUI.
The following features are not supported:
Automonitors
Templates
Navisphere CLI must be installed on the same system as the clariion probe.
cluster (Clustered Environment Monitoring) Release Notes

The cluster probe monitors Microsoft, Red Hat, HP-UX service guard and Veritas clusters.
Note: A cluster comprises of one or more resource groups and cluster nodes. A resource group is shared between the cluster nodes.
Only one cluster node has the control of a resource group at any given time. A resource group is a collection of shared resources like
disk drives, IP addresses, host names, and applications.
The cluster probe enables failover support for a set of CA UIM probes in clustered environments. The probe configurations that are saved in a
resource group remain the same, even when that resource group moves to another cluster node. The cluster probe sends alarms when a
resource group or cluster node changes state.
The probe version 3.30 and later provides Logical Volume Manager (LVM) support for HP-UX platform. If you upgrade to cluster version 3.30,
cdm LVM disk profiles are created in cluster.
Contents
Revision History
Supported Probes
Set up Cluster Monitoring in cdm
Known Issues
Revision History
Version
Description
State
Date
3.33
Fixed Defects:
GA
December
2015
On RHEL platform, the cluster disks were displayed as local or network disks on the cdm Infrastructure Manager (IM). S
upport case number 00160058
Note: You must use cdm version 5.61 with cluster version 3.33 to view the cluster disks on the cdm Infrastructure
Manager (IM).
When node service was stopped, cluster probe marked resources offline and kept sending _restart command to other
probes. Support case number 70002275
3.32
October
2015
Fixed Defects:
On Linux platform, the cluster disks were displayed as local disks on the cdm Infrastructure Manager (IM). Salesforce
case 00135028
GA
The probe displayed incorrect status of clustered disks on the IM. Salesforce cases 00169389, 00170460
Updated the Supported Probes section in Release Notes to describe the cluster configuration that is supported by
sqlserver, oracle, and ntperf. Salesforce case 00169432
3.31
What's New:
GA
June 2015
Beta
May 2015
Updated support for factory templates.

Fixed Defects:
Fixed an issue where the probe did not clear package halted\failed alarms when the failover is unsuccessful in HP-UX
clusters and the package starts on the primary node.
3.30
What's New:
Added Logical Volume Manager (LVM) support for HP-UX platform
Added Log Size field
Provided an option to select the protocol key as TCP or UDP for raw configuration. By default, the protocol key is TCP.
3.20
What's New:
March
2015
Added support for HP-UX service guard A.11.19.00 cluster

Added support for factory templates
Fixed Defects:
Fixed a defect where cdm disks were not getting activated/deactivated on failover. Salesforce case 00133038
Fixed a defect where on Red Hat cluster another node was coming for quorum disks. Salesforce case 00144966
Fixed the defect where the probe used to give an error message The node has no valid cluster probe address and you
cannot add any resources until this is resolved. Salesforce cases: 00151733, 00142247, 00137235, 00115400,
00121291
3.13
Added support for configuring the probe through the Admin Console (web-based) GUI.
September
2014
3.12
Fixed memory leak issue.
September
2013
3.11
Fixed issue that is related to leaks
June 2013
Fixed issue where the probe is unable to define any monitoring profile
Fixed an issue where the probe does not clear alarms after failover to next node
3.10

Added resource information for a resource group in the alarm message
December
2012
Added support for RHEL 5.0x64 bit

3.01
Updated cluster information in cdm for RHCS.
September
2011
3.00
Added support for Red Hat cluster.

Fixed message synchronization for the NTServices probe.
August
2011
2.72
Fixed group synchronization when not using node IPs in cluster.cfg (applied fix from v2.66 into 2.7x release).
March
2011
2.72
Fixed the group synchronization when not using node IPs in cluster.cfg (applied fix from v2.66 into v2.7x release).
January
2011
2.66
Fixed the group synchronization when not using node IPs in cluster.cfg
January
2011
2.71
Applied fixes from v2.65 into 2.7x release.
January
2011
2.65
Fixed a potential program failure on SOLARIS (logging of NULL pointer terminates probe on SOLARIS).
January
2011
2.70
December
2010
2.64
Fixed a potential program failure on SOLARIS (no node IP in cfg causing failure).
September
2010
2.63
Added fix in the GUI to use named APIs instead of IP.
September
2010
2.62
Changed the haclus -list to haclus -value ClusterName

Fixed the cluster compatibility issue on IA64 platform
August
2010
Fixed the issue of wrong IP in NAT environment in the GUI and the probe.
Fixed the issue of double cluster group devices listing in CDM
Fixed the issue of cluster drives being reported as local in CDM on non-owner nodes
Added a validation while adding shared sections or subsections in GUI
Removed whites spaces from the cluster names at the time of discovery
Version 2.62 withdrawn because of potential communication errors when configuring.
2.61
2.60
Added support for AIX platform.

June 2010
April 2010
Added support for Resources Failed and Resources Not Probed in hastatus.
2.52
Fixed the issue of Drive reported as Disk3Partition1 in case the device is down on the cluster
March
2010
2.51
Fixed the CDM mount point handling issue in the Microsoft cluster plugin dll.
March
2010
2.50
Added support for merging configuration when configuration is done across different cluster nodes
Added support for configuring shared resources individually and in bulk.
2.30
2.21
Added a callback get_cluster_group_all to get the complete status of cluster

Built with new libraries
Added QoS messages for state changes on Node and Group state
Added levels of alarm severity that is based on Node and Group state
Added support for fetching of cluster resources
Added support for identifying clustered disks
Added option of removing Resource Groups no longer part of the cluster
Changed callback get_nodename
Fixed retrieval of evs_name (correct case) for Exchange 2007 in get_EVS
Fixed issue regarding "illegal SID" upon cluster probe synchronization
Fixed fetching of resource type in calls to get_EVS and get_cluster_resources
Fixed callback get_EVS (input argument nodename is no longer case sensitive)
Added support for Windows on Itanium 2 systems (IA64)
Fixed synchronizing issue in NAT environments. (Add the key use_local_ip = 1 in /setup section (use "raw configure"))
March
2010
March
2010
July 2009
2.04
Fixed problem with change of alarm subsystem IDs
June 2008
Fixed association of same profile to multiple Service Groups (This is not allowed).
2.03
Fixed minor GUI issues
April 2008
Fixed GUI refresh. Fixed logging on Solaris

Fixed program failure on Solaris
Fixed handling of Service Groups in PARTIAL state for VCS
Fixed probe security settings for LINUX and SOLARIS
Fixed OS key for Solaris plug-in (wizard failed)
Added the port library on Solaris (load plug-in failed)
Added support for Veritas Cluster Server (VCS) on Windows, Linux, and Solaris
1.64
Fixed synchronization issues
September
2007
Fixed memory leak (IP=NULL)

1.62
Fixed saving of Resource Groups containing slash (/)
1.61
June 2007
Share "partially online" resource group setting with exchange_monitor probe
June 2007
Added support for identifying Exchange Virtual Servers

Added support for NimBUS exchange_monitor in A/A, A/P, and N+I node cluster configurations
1.50
Fixed several GUI issues
September
2006
Added multiple profile selection

Removed "add node", "delete node" and "add resource group" options
Added support for edit/disable alarms
Fixed several run-time error situations
Changed source field on node alarms
Added support for shared sections and probe profiles that are found in /cluster_setup section of other probes
1.26
Fixed issue with resource groups not having their states set correctly when alarms were turned off
April 2006
Fixed issues relating to synchronization between cluster probes, especially when adding new resources
Fixed security issue when synchronizing probe configuration between nodes
1.22
Cosmetic GUI changes. Added Refresh to menu. Fixed text for clear alarms
December
2005
Supported Probes
The following table lists the supported probes and their corresponding supported cluster environment:
Important! Use the cluster probe with other probes only when you configure the cluster probe on a robot in a clustered environment.
Supported Probe
cdm
The probe supports only disk profile monitoring on cluster version 2.20 and later.
Supported Cluster Node Configuration
Active/Passive
N+I node cluster
Note: For more information, see the Set up Cluster Monitoring in cdm section.
dirscan
2-node Active/Passive
N+I node clusters if the profile names are
unique
exchange_monitor
The probe supports only Microsoft Cluster Server (MSCS) monitoring on cluster version 1.61
and later.
logmon
Active/Active
Active/Passive
N+I node cluster
unique
nperf
unique
ntservices
unique
oracle
unique
processes
unique
sqlserver
unique

The cdm probe receives information about the cluster disk resources from the cluster probe. Monitoring profiles are created for the resources that
are based on the fixed_default settings in the cdm probe. The profile is automatically registered with the cluster probe to ensure continuous
monitoring on cluster group failover. In the cdm probe, the cluster IP is used as Alarm and Quality of Service source instead of the cluster node.
You can change the source to cluster name or group name through Infrastructure Manager (IM).
This section lists the upgrade considerations for the cluster probe.
Any cluster disk profiles that are created in the probe version 3.31 or earlier are not supported on probe version 3.32 or later. Configure a
cluster disk in the cdm probe and then create cluster disk profile in the cluster probe.
Restart the cdm probe to see the cluster disks.
Any cdm disk that is converted from local to cluster and is enabled for monitoring, is deactivated.

The cluster probe must be installed on systems with the following minimum resources:
Memory: 2 GB to 4 GB of RAM
CPU: 3-GHz dual-core processor, 32-bit, or 64-bit.

The cluster probe requires the following software environment:
Note: To run the probe version 3.32 on Admin Console, you require:
CA UIM 8.31 or later
ppm probe version 3.23 or later

ci_defn_pack 1.03 or later (required for HP-UX platform on CA UIM 8.1 or earlier)
Note: Restart the nis_server when you deploy the ci_defn_pack probe.
Known Issues
The cluster probe has the following limitation in Admin Console:
Cluster profiles for cdm, logmon, and processes probes can only be created on the node where the cluster probe is started.
controller Release Notes

The controller probe is a core component of the CA Unified Infrastructure Management robot.
Controllers schedule, start, and stop the probes that the robot manages. Controllers keep configured probes running according to the
probe configurations.
Controllers maintain contact with parent hubs and handle CA UIM operations, including hub state, name-lookup services, and licenses.
Controllers respond to directives in the robot.cfg and the controller.cfg files, and to commands issued over the registered port TCP/48000.
To install or upgrade a robot, see Installing on the CA Unified Infrastructure Management wiki space.
Revision History
Version
Description
State
Date
7.80
GA
What's New:
Support for OpenSSL
TLS cipher suites
When using TLS 1.1 or 1.2 cipher suites, include an alternative fallback to
SSLv3. Fallback for backwards

SSL. Example: AES12
8-SHA256:RC4-SHA, where AES128-SHA256 is TLS v1.2 and
RC4-SHA is SSLv3.0
compatibility between older robots and new hubs, or probes connected to a robot using
OpenSSL 1.0.1m implemented

Windows IA64 is no longer supported
Fixed Defects:
The spooler probe restarts
When a controller probe configured in proxy mode is restarted, the spooler probe also restarts.
The controller SID is automatically renewed after the hub login expiration time has passed .
The controller SID from the hub expired when the
Login Expiration Time elapsed. Expiration
prevented the controller from acquiring a new license for a probe from a distsrv on a remote hub. A new
license is needed when a probe with an expired license is restarted. Now, the remote controller is automatically
logged in to the hub and acquires a new SID when the SID expires.
The controller starts java probes on AIX.
On AIX systems, the controller failed to start java probes. The AIX system call to start java probes now allows them
to start. The process name now appears on AIX systems as
full_command_to_start_java_p
robe instead of nimbus(probename).

The controller preinstall exit code is correctly interpreted.
Preinstall exit codes are:
0 - okay
1 - warn but continue
2 - warn and abort this section
3 - warn and abort the rest of the installation
The controller handles a probe restart without crashing.
The robot v7.70 crashed when all the following conditions were true:
A probe was running.
The robot had
start_after probes that were not installed.
The controller restarted its probes due to an origin or
marketplace settings change.
June
2015
7.70
Important: SSL communication mode options are more meaningful with the release of controller v7.70. The controller
creates the robot.pem certificate file during startup. The file enables encrypted communication over the
GA
March
2015
GA
December
2014
GA
November
2014
GA
June
2014
GA
March
2014
OpenSSL t
ransport layer. The treatment of the robot.pem certificate file has changed. For details, see Impact of Hub SSL Mode
When Upgrading Nontunneled Hubs in the hub Release Notes. Changes in treatment impact communication for:
Hubs set to mode 0 (unencrypted)
Hubs set to mode 2 (SSL only)
Hub managed components
What's New:
User tags are propagated by the hub and the controller. Hub and controller alarms and messages now contain user
tags. Previously, the hub and controller read user tags os_user1 and os_user2 from the file robot.cf
g. Now, the hub reads user tags from the file hub.cfg. The General Configuration section in the Admin Console
hub configuration UI allows users to specify os_user1 and os_user2. On a hub system, the hub spooler for
the hub probe adds user tags to probe alarms and messages. On a robot system, the robot spooler adds the user tags.
Note: The os_user_include option, which enabled the hub to read user tags from
was removed from the hub v7.70. Hubs and robots at v7.70 do not read user tags from
hub robot had defined user tags, they will remain in
robot.cfg,
robot.cfg. If the
robot.cfg after upgrade, but they are ignored. To add

hub.cfg.
user tags to hub probe alarms and messages, specify the user tags in
Package included in CA UIM 8.2 distribution

Fixed defects:
Existing memory leaks were addressed
Attempts to save changes to the robot configuration when the file system is full retain the original configuration.
The controller does not assign probes to ports used by hub tunnels. Ports are assigned to the correct interfaces based
on strict binding mode.
Robot correctly installs package files on zLinux.
Robot stops all child processes when shutting down.
Robots that are configured for proxy_mode return to their designated parent hub after failover.
If an available port could not be found, the robot could consume 100 percent of CPU.
The hdb probe could crash on Windows due to issues with
logmon configuration.
Issues when the robot mode was changed from passive to active.
7.63
OpenSSL 1.0.0m
Removed a potential crash condition during a shutdown
Improvements to port free checks under various circumstances
7.62
The get_info callback includes MAC address information for AIX, Solaris, and HP-UX (in addition to Linux and
Windows).
Resolved core dump issue on a controller shutdown
Fixed a defect that caused the robot to unregister from the hub on shutdown.
Resolved a socket leak in the
get_info callback on Linux

7.60
New native robot installers and ADE support for AIX and zLinux
Robot 7.60 for zLinux
Robot first probe port defaults to 48000
Package included in NMS 7.60 distribution
7.05
7.10
Added support for Microsoft Windows 2012 Server and Microsoft Windows 8.
GA
Removed dependency on .NET framework 2.0
December
2013
Integrated installation of Visual C++ 2008

Package included in NMS 7.00 and 7.10 distributions
cuegtw (Cloud Monitoring Gateway) Release Notes

The Cloud Monitoring Gateway (cuegtw) probe pools the CUE API using valid user credentials to collect data and generate alarms.
Note: The support integration of Cloud Monitor (Watchmouse) in UMP 2.6 and cuegtw probe is for English only locale.
Contents
Revision History
Prerequisites and System Requirements
Preconfiguration Requirements
Revision History
This section describes the history of the revisions for the cuegtw probe.
Version
Description
State
Date
1.06
Fixed Defects:
GA
April 2014
GA
February
2014
Fixed a defect in which different MetIds were getting generated for Alert, Reminder and Clear alarms for the same
profile.
1.04
Fixed Defects:
The cuegtw probe stops sending alerts after certain time. The user has to restart the probe frequently to receive the
alerts continuously.
The cuegtw probe was taking any random port number instead of the port number as configured in the port settings of
the Controller probe.
1.03
The Setup tab help button incorrect link defect has been fixed.
1.02
Different time zone issues where probe doesn't display messages when the API and probe are in different time zones.
Implementation of clear alarm when API sends the ok message for a profile.
Truncated Message issue where some alarms are truncated because of alarm message length.
Cursor Implementation in probe.
Alarm sequence issue: Alarms not displayed in the proper sequence in an earlier version.
GA
June 2012
1.01
This version resolve a critical proxy issue where user use automatic script files for configuration or http calls redirect through
proxy server.
GA
March 2012
1.00
Beta
December
2011
Prerequisites and System Requirements

For this probe to work appropriately, you must have a valid CUE API user account.
January
2013
Note: The support integration of CA Unified Infrastructure Management Cloud User Experience Monitor or CUE in UMP 2.6 and cuegtw
probe is only for English locale.
The Cloud Monitoring Gateway probe requires the CA Unified Infrastructure Management Cloud Monitor API user credentials to fetch RSS feeds.

The cuegtw probe should be installed on systems with the following minimum resources:

The cuegtw probe requires the following software environment:
Java JRE 6 or later (typically installed with NMS 5.0 and above)
db2 (DB2 Database Monitoring) Release Notes

The DB2 Database Monitoring (db2) probe monitors DB2 instances, databases, table spaces, and applications. The probe uses the DB2
snapshot and tablespace statistic APIs to extract information about your DB2 servers.
The probe monitors around 280 DB2 snapshot and statistic counters, and calculates values such as:
i_agents_created_ratio
i_piped_sorts_rejected
i_pct_active_connections
db_pool_hit_ratio
db_avg_sort_time
db_pct_sort_overflows
db_avg_sort_heap
db_pct_hjs_overflows
db_pool_sync_reads
db_pool_sync_writes
db_pool_sync_idx_writes
db_pool_sync_idx_reads
db_pool_avg_async_read_time
db_pool_avg_async_write_time
db_pool_sync_write_time
db_pool_avg_write_time
db_avg_direct_read_time
db_avg_direct_write_time
db_cat_cache_hit_rto
app_avg_sort_time
app_pct_sort_overflows
app_pool_hit_ratio
app_avg_direct_read_time
app_avg_direct_write_time
app_cat_cache_hit_rto
app_pkg_cache_hit_rto
app_locklist_util
bp_pool_hit_ratio
bp_pool_avg_async_read_time
bp_pool_avg_async_write_time
bp_pool_sync_write_time
bp_pool_avg_write_time
bp_avg_direct_read_time
bp_avg_direct_write_time
bp_pool_sync_reads
bp_pool_sync_writes
bp_pool_sync_idx_writes
bp_pool_sync_idx_reads
ts_usable_pages_pct
ts_used_pages_pct
ts_free_pages_pct
ts_max_used_pages_pct
Contents
Revision History
Authorization and Environment Variable Requirements
Known Issues
Revision History
Version
Description
State
Date
4.09
Fixed Defects:
GA
October
2015
GA
October
2014
The probe was unable to generate an alarm when the current state of a monitored tablespace was not "NORMAL". Sale
sforce case 00150521
The probe was unable to restart after a new connection was created. Salesforce case 00154620
The size of the niscache was growing to around 1GB in a day. Salesforce cases 00165738,00148339
4.08
Fixed Defects:
Fixed the core dump issue on AIX that occurred each time the probe was deactivated. Salesforce case 00132849
4.07
Fixed Defects:
Fixed a defect in which the Status Tab did not show the correct color code of the profile.
April 2014
4.06
Added support for TNT2 compliance where Device Id and Metric Id are generated correctly.
March
2014
Added support for keeping probe alive in case of missing client software.
Fixed defect where probe alarm message value was missing in UMP alarm console.
4.05
Fixed Defects:
GA
June 2013
Fixed issue where the "Request Failed" and "Warning" message were getting displayed on probe GUI.
Fixed incorrect values coming on AIX platform for sql queries having columns with INTEGER data types.
4.04
Fixed: A spelling error "Time form" to "Time from" in the Checkpoint GUI.
GA
January
2013
4.03
Added probe default feature.
GA
November
2012
GA
September
2012
Fixed: Threshold not getting deleted from checkpoint.

Fixed: Threshold message not getting displayed.
4.02
Added feature to save connection "Timeout" settings in GUI.

Added feature to retain value of "Status Auto-Update" flag in GUI.
4.01
Added "All Database Status" checkbox in setup tab in GUI which provide choice to customer to select default or all
database status. Added "Clear Alarm on Restart" checkbox which will allow users to control clearing of alarms at probe
startup. Replaced database password showing in cleartext with "********" in logs. Verified probe compatibility with
DB210.1 on AIX6.1 and AIX7.1 Fixed issue where few of the chekpoints were giving false positive and negative value
alarms.
August
2012
4.00
The connection configuration now supports ODBC DSN as well as manual configurations of connectivity parameters.
July 2011
The probe does not support connection and sql timeout alarms.
Added support for custom checkpoints.
3.41
Fixed: Unable to insert data into SLM.
March
2011
3.40
December
2010

3.34
Fixed a semaphore leak issue in the probe. The issue occurred when the probe tried to attach to db2 instance using
improper credentials.
October
2010
3.33
Added support for alarms & QOS' on all active databases in i_check_dbalive checkpoint. Earlier, the probe reported only
for default database configured in the profile's connection. Existing QOS series for i_check_dbalive checkpoint will no
longer work; instead, a new series will be created.
October
2010
Fixed an issue where the probe stops reporting checkpoint values and throws DB2 error SQL1092N.
3.32
Fixed issue related to alarm sending an alarm when DB2 server is down.
Fixed issue related to releasing DB2 database context resource after its use.
September
2010
Fixed an issue in db_status checkpoint, the issue is related incorrect status reporting.
3.31
Support for alarms.cfg.
September
2010
3.30
July 2010
Updated GUI for config locking.

3.21
Added fix for GUI crash in alarm message window.
July 2010
3.20
Added a new checkpoint i_pct_active_connections for monitoring percentage of active connections to total available
connections.
March
2010
3.13
Fixed an issue where the probe used to report incorrect value for db_since_last_backup checkpoint.
September
2009
3.12
Fixed probe crash when instance node selection button is clicked on the connection configuration page.
July 2009
Fixed UI validation issues when selecting instance node on the connection configuration page.
Added missing message variables for checkpoints
Fixed a crash in probe stop callback
Fixed an issue where probe was wrongly getting attached to dummy DB2 instance and throwing SQL1096N error
Optimized GUI performance when loading config file
Fixed minor GUI issues
Removed 64 Bit porting warnings
Object Viewer introduced
New checkpoints 'db_log_util_rto', 'db_since_last_backup'
3.04
Migrated V2 QoS compatibility.

V2 Migration problem solved.
3.02
Solaris support added.

Tablespace checking on SMS tablespace only where it makes sense.
3.01
Configuration file template corrected.
December
2008
August
2008
July 2008

The db2 probe must be installed on systems with the following minimum resources:

The db2 probe requires the following software environment:
Java JRE 6 or later (required for Admin Console)
DB2 Client V8.1 FP13 or higher
DB2 versions 10.1 and 10.5
Authorization and Environment Variable Requirements

The probe requires one of the following authentications for the user account:
SYSADM
SYSCTRL
SYSMAINT
You must also set the LD_LIBRARY_PATH environment variable in the controller to the DB2 library directory. The default values for the variable
are as follows:
Windows platform: C:\Program Files\IBM\SQLLIB_01\lib
Note: Restart the Nimbus Watcher service to initialize the DB2 environment variables after installing DB2 client on Windows
platform.
Linux, IBM AIX, or Sun Solaris platforms: /opt/ibm/db2/V10.5/lib64
Increase the DB2 instance configuration parameter MON_HEAP_SZ by at least 128. This change also requires you to restart the DB2
server.
You must follow these actions to access the DB2 server.
Set the DB2INSTANCE for default local instance
Catalog the remote or additional local instances in the DB2 node directory
Catalog the monitored databases in the database directory.
The probe supports DB2 client library versions greater than or equal to the target DB2 server version. For example, to monitor DB2
server version 9.5, you must use the DB2 client libraries of version 9.5 or higher on the machine where the probe is deployed.
Known Issues
The db2 probe has the following known issue:
db2 Limit on AIX
On AIX platforms, DB2 supports maximum ten shared memory segments per process when using a local connection. Since each profile requires
two memory segments, only a maximum of 5 profiles can run at a given time. When this limit is exceeded, the DB2 returns a SQL1224N error
message. The workaround proposed by IBM is to catalog the instance and the related databases as remote connections, as there are no such
limitations imposed for this connection type.
Important! This workaround changes the way you interact with your DB2 if you are using local session.
Follow these steps:

1. Catalog the local instance as a remote node. CATALOG TCPIP NODE node_name REMOTE hostname SERVER
port_number_or_service_name
2. Catalog all local databases as remote databases. CATALOG DB local_database_name AS alias_name_for_local_database AT NODE
node_name
3. Uncatalog local databases. UNCATALOG DB local_database_name
For more information, refer the official IBM DB2 documentation.
dirscan (File and Directory Scan) Release Notes

The File and Directory Scan (dirscan) probe monitors files in specified directories. Alarms can be sent on the number, age, and space that is used
by files.
This probe monitors files and directories for the following:
Existence of directories
Shared directories (Windows systems only)
Named files or file patterns in a directory (option to include subdirectories)
The probe is configured by defining one or more profiles. Each profile identifies a particular directory and the required files. You can configure
different parameters that can be checked. All the following parameters can generate alarm messages if the specified threshold is breached:
Number of files
The number of files that are found in the specified directory matching the specified pattern.
Age of file
The age of the files that are found in the specified directory matching the specified pattern.
Space that is used by files
The space that is used by all files that are found in the specified directory matching the specified pattern.
Size of files
The size of the files that are found in the specified directory matching the specified pattern.
Read response time
The time that is required to read the specified file.

Directory check
Verifies if the specified directory is present.
Directory age
The time that has passed from the previous change in the directory.
File integrity
Verifies if the files that are specified for file integrity monitoring have changed.
The probe also generates QoS data for the following parameters:
Number of matching files
Age of oldest/newest matching file
Space that is used by matching files
File read response time
File integrity
Contents
Revision History
Threshold Configuration Migration
Changes After Migration
Known Issues
Revision History
This section describes the history of the revisions for the dirscan probe.
Version
Description
State
Date
3.14
What's New:
GA
September
2015
GA
July 2015
GA
March
2015
GA
October
2014
Added support for IBM iSeries version V7R2.

3.13
What's New:
Added sendresponsetime key in Raw Configure > Setup to send QoS value in seconds instead of byes/seconds for
QOS_DIR_RESPONSE_TIME. Refer Upgrade Considerations for more information.
Fixed Defects:
The probe adds a '\' at the end of directory path and cannot identify the directory. Salesforce case: 00160487
The probe does not save pattern configurations for file monitoring. Salesforce cases: 00167616, 00165924, 00164986,
00163884
3.12
What's New:
The probe can be migrated to standard static thresholds using the threshold_migrator probe. The Admin Console GUI
will be configurable using the standard static threshold block and the Infrastructure Manager GUI will no longer be
available.
3.11
Fixed a defect where the probe was unable to generate the Used Space Delta alarm.
3.10
Fixed Metric Id defects
June 2014
3.09
Fixed the defect of scheduler by allowing user to clear specific hours of one particular day of a week. Earlier the probe can
select or clear the specific hours for an entire week.
April 2014
3.08
June 2013
3.07
Directory search with % parameters without directory exist check issue fixed
May 2013
3.06
Directory search test with % parameters issue fixed
April 2013
3.05
Fixed issue with fetch current in GUI.
May 2012
Improved error handling.

Removed clear on restart.
Fixed alarm message defaults in the configuration tool.
3.04
Corrected NISTOKEN string for Used Space Delta Alarm Message.

Fixed Directory variable expansion for directory check.
March
2011
Fixed NULL QOS value for age of file when their is no file in the directory.
3.03
Removed dirScan file integrity profile file number limit.

Fixed the defect of sending NULL QoS for number of files in a directory, when zero files are found.
March
2011
File Integrity : Added Support for run time pattern matching.

Addition of schedular functionality to the dirscan probe on per watcher basis.
Monitoring directory/file size change (say x unit) in last number of cycles (say y cyles) and sending appropriate alarms.
Added feature to monitor the probe on the basis of current time stamping for windows.
3.02
January
2011
2.91
June 2010
2.90
March
2010
2.81
Fixed the problem which would sometimes cause the probe to crash when running multiple profiles.
March
2010
2.80
September
2009
2.73
Changed the behavior for the integrity profiles: If the MD5 signature for a file is not set, it will be generated and stored in the
configuration file during the probe startup or restart process.
July 2009
2.72
Fixed directory variable for file age alarms.
June 2009
Fixed clear for file size, file age and file response alarms.
Fixed crash situation on stop and restart.
Disabled 'Fetch' button in configuration tool for settings not supported by the test command.
Fixed token for 'DirAge' alarm message.
Cleanup of code for mapping/unmapping shares.
Added option for Quality of Service message on directory existance.
Reorganized configuration tool, separating directory scan and file integrity profiles.
Fixed directory scan problem on shares introduced in version 2.43.
Fixed file and directory variables for clear messages so that these are consistent with other alarm situations.
Added scan type for file size: largest, smallest or individual file.
Added scan type for response time: longest, shortest or individual.
Modified browse/doubleclick behaviour.
Improved error handling on memory allocation situations.
2.53
December
2008
2.52
Problem with generated directory names containing the '/' character as directory separator on Windows is resolved.
Configuration tool fixed to disallow empty profile name.
September
2008
Configuration tool crash on profile copy fixed.

The default messages in the message pool are no longer overwritten on redistribution of the probe. For upgrade from
version 2.22 and earlier, see the installation notes.
Added support for 64-bit Windows (x64)
Added support for LINUX on 64bit PowerPC (glibc = 2.3)
Added support for 64bit platforms on AIX, HP-UX, SOLARIS and LINUX.
Please note that, for version 2.52 and higher of this probe, Robot version 3.00 (or higher) is a prerequisite. You are
advised to carefully read the document "Upgrading the NimBUS Robot" before installing/upgrading.
2.43
Fixed variable expansion in command strings.

Fixed problem with passwords that where corrupted on profile edit.
October
2007
This version turns off profile monitoring if directory does not exist.
Clear messages are now sent for file read response.
Added cluster probe support.
Clear messages are sent on response time within limit and also when the file no longer exists.
Modified logic in the directory browser so that the '[..]' entry will not appear at the share level.
Fixed handling of more than one directory specified and of directory recursion.
Added new alarm message used for alerting when unable to open a file for obtaining a response time.
2.42
Fixed a number of minor memory leaks.
May 2007
Fixed problem with uninitialized memory causing occasional program failure.

Modified algorithm for clearing of age and size alarms, also changed suppression keys and format of dirscan.file.
Fixed problem with Recurse into subdirectories.
Fixed problem when changing option of Age of file from checking All files to only check Newest file.
UNIX: Added new versions to supported platform list
AIX_5: 64bit
HPUX_11: 64bit (PA-RISC & Itanium)
SOLARIS_8: 64bit (Sparc)
SOLARIS_10: 64bit (x86_64)
SOLARIS_10: 32bit (x86)
GUI changed for Age of file constraint. Added radio button for Age of all files. This replaces checkbox for 'Send alarm for
each breaching file'. Choosing Age of all files disables the button for Fetch current values. Fixed clearing of alarms if
multiple files recover from breaching Age of file constraint. Breaching files that no longer exist will also send clear with
reported age 0 min.
2.29
2.27
Age constraint alarm can now be sent either for each breaching file, or oldest/newest if only a single alarm is desired.
Alarm messages fix.
Added extra log information at loglevel 2 during file scanning.
2.26
Remove clear flag for the messages section in the cfx file which would clear out custom messages.
The flag was added in v2.22 because of a change in the message format.
See Installation Notes below if upgrading from a version prior to 2.22 for information on what to change in the cfx file to
upgrade the messages correctly.
November
2006
August
2006
July 2006
2.25
Windows: Fix problem with username/password not being set correctly when testing a connection
July 2006
Age constraint alarm is sent for each file breaching the threshold (not just oldest/newest). QoS data is still for the
oldest/newest however.
Solaris, AIX and Linux: Added utility (stat64) for reading file sizes over 2GB.
GUI: user and password information for shared drives would not show up when editing an existing profile.
2.22
New GUI layout.
April 2006
Regenerates MD5 digest from GUI.

Fixed problem with the "Fetch current values" button on "Read Reponse Time".
Changed description of QoS for file age.
2.21
Added support for file integrity check using MD5 digest. Added support for using Date/Time primitives (strftime parameters)
when specifying directory names.Support for customizing alarms and "Clear" messages.
November
2005
2.20
Changed QoS definition for file age to use unit "s". Added support for file size alarms on large files on Windows.
November
2004

The probe (version 3.12 or later) can be migrated to standard static thresholds using the threshold_migrator probe. You can refer the
threshold_migrator probe document for information about how to migrate a probe.
Important! The IM GUI of the probe is not available if the probe is migrated using threshold_ migrator. Opening the IM GUI then
displays a message that the probe can only be configured using the Admin Console and redirects you to the Release Notes of the
probe.

The changes in the probe after migration are:
Dynamic values in alarms and automated rollback will not be available.
The Infrastructure Manager GUI of the probe will not be available and the probe will only be configured using Admin Console.
Some probe specific alarm configurations in the probe monitors will be replaced by Static alarms and Time over Threshold configuratio
ns.
Refer dirscan Metrics for details.
The static message variables will also be migrated and only the standard variables such as value and threshold will be used.
The variable syntax will change from $<variableName> to ${<variableName>}.
Any relational operators in the probe configuration will be reversed.
QOS_DIR_AGE: Alarm is generated for the newest file after migration if configuration is set to individual file before migration.
QOS_DIR_RESPONSE_TIME: Alarm is generated for the longest file after migration if configuration is set to individual file before
migration.
Dynamic variables, such as $File and $Number are only available in dirscan version 3.13 or later.
Dynamic variables are available when you upgrade a migrated 3.12 version of the probe to a later version. You must manually add the
variables to the custom alarm messages to use them.

The dirscan probe is installed on systems with the following minimum resources:
CPU: 3-GHz dual-core processor 32, or 64 bit

The dirscan probe requires the following software environment:
The 3.12 version or later of the probe (for migration with threshold_migrator probe) requires the following software environment:
CA UIM 8.31 or later
baseline_engine probe version 2.60 or later
Version 2.22 implemented a new layout of the message pool. If upgrading from a version prior to 2.22, you need to modify the dirscan.cfx file in
the package.
Follow these steps:
1. Get the latest version of the probe from the Internet Archive
2. Double-click the dirscan package in the Archive node of the Nimsoft Infrastructure Manager
3. Select the tab for your platform and click on dirscan.cfx
4. Right-click and select Edit file.
5. Locate the <messages> section and add the 'clear' keyword after the closing bracket. Click OK
6. Repeat for each platform you intend to distribute the updated probe to
7. Distribute the update to all systems running v2.22 or older
Note: All custom messages will be cleared and default messages in the new format will be inserted.
The description of the QoS for file age, QOS_DIR_AGE was previously defined as Age of oldest/newest matching file. In version 2.22, this has
been changed to Age of matching file.
The probe has the following upgrade considerations:
The 3.13 and later versions of the probe have a key sendresponsetime key in Raw Configure > Setup with the default value as '0'. You
can set this key to '1' to send the QoS value in seconds instead of byes/seconds for QOS_DIR_RESPONSE_TIME.
Known Issues
The dirscan probe has the following limitations:
The log file incorrectly displays a logon failed message when the probe fails to authenticate the specified user credentials. In this
scenario, the probe applies the user credentials used for probe deployment.
The dirscan probe has the following limitations in the Admin Console GUI:
Schedules are not supported.
Existing profile(s) cannot be copied to create new profiles.
Recalculation of checksum using Recalculate checksum is not available for pattern based files.
Non Windows remote directories cannot be monitored. (applicable to both Admin Console and Infrastructure Manager GUI)
discovery_agent Release Notes

The Discovery Agent (discovery_agent) is released as a part of the core Unified Infrastructure Management Server release.
Fixed Defects and Revision History

This table lists the known issues, fixed defects, and revision history for all releases of discovery_agent.
Version
Description
State
Date
8.20
Included in CA UIM 8.2:
GA
March
2015
Discovery Server has been enhanced to include callbacks that allow you to cleanly delete devices from both the UIM
and UDM tables in the UIM database. With the introduction of UDM, manual deletion of devices using SQL commands
was prohibited, as it can cause the UDM tables to be out of sync with the rest of the UIM database. Using the callbacks
introduced in this release provides you with a mechanism to delete devices without causing syncing issues.
Discovery Server has been enhanced to work in conjunction with the vmware probe to provide partial graph publishing.
To enable this feature, additional configuration in the vmware probe is necessary.
Fixed: Discovery Agent v8.2 contains fixes which improve the collection of ICMP ping discovery results.
Discovery supports subnets with a CIDR notation number of /16 or larger only. Entering range scopes larger than
65,536 addresses when defining a discovery range may result in one of the two following behaviors:
When using the snmpcollector probe to query for a list of devices, defining a range greater than /16 will generate an
exception with an error message indicating that the query is not supported.
When using the Discovery Wizard to define one or more subnets using the same CIDR notation, defining a range
greater than /16, or entering multiple /16 ranges will generate an out of memory exception error.
WMI and SSH discovery provide more detailed host system information than SNMP. We recommend that you use WMI
or SSH discovery in addition to SNMP.
A bug in MySQL 5.5 causes a slow restart of discovery_server. Upgrading MySQL to version 5.6.13 or later resolves the
issue.
If you are unable to find a device in USM by IP address, it may be that the device has multiple IPs, and discovery
identified it by a different address.
As part of 7.0 discovery server and discovery agent enhancements, a device with multiple IP addresses is now shown
as a single device in USM, and as multiple distinct devices per IP address. If you can not locate a device in USM by IP
address, try searching for it by name.
The NIS Manager link in Infrastructure Manager does not work because it has been removed from the product. Use the
Discovery Wizard, available in the USM portlet to configure discovery components.
SSH password authentication is disabled with OpenSUSE 12.x.
Discovery Agent uses password authentication to connect to a target device over SSH. Discovery Agent cannot
communicate with a device where SSH is configured for other authentication methods, such as keyboard-interactive.
Discovery Agent also does not support public key authentication or challenge-response authentication.
For details, see the CA Unified Infrastructure Management - 8.2 Release Notes.
8.10

Discovery publishes details of each network interface.
UDM Manager is coupled with Discovery Server to integrate UDM as a key part of inventory management:
Discovery Server writes inventory to both UDM Manager and NIS/TNT2 tables.
Discovery Server uses log4j as its logger to capture UDM logging.
Logsize is no longer specified in discovery_server.cfg. Logsize is set in the new log4j.xml file.
Some data resides only in UDM (for example, USM relies on UDM as the sole source for some interface data views).
Improvements to the discovery of AIX and HP-UX systems make it possible to deploy robots to these systems using
USM.
Improvements to device correlations enable Discovery Server and Discovery Agent to avoid false matches and the
merging of non-matching devices into one device.
Enhancements to interface origins: By default, an interface inherits its origin from its associated device. If the interface
origin is enriched through the QoS processor, that origin can now be associated with the interface in UDM.
65,536 addresses when defining a discovery range may create an out of memory condition.
issue.
If you are unable to find a device in USM by IP address, it may be that the device has multiple IP addresses and
discovery identified it by a different address.
as a single device in USM, not as multiple distinct devices per IP address. If you cannot locate a device in USM by IP
The NIS Manager Link in Infrastructure Manager does not work because it has been removed from the product. Use the
Discovery Wizard, available in the USM portlet, to configure discovery components.
communicate with a device where SSH is configured for other authentication methods, as as keyboard-interactive.
Fixed: Device correlation in Discovery Server and Discovery Agent is improved to avoid false matches and incorrectly
merging non-matching devices into one device.
GA
December
2014
8.00
GA
September
2014
GA
June 2014
GA
March
2014
GA
December
2013
GA
September
2013
USM is enhanced to display more detailed agent status during the discovery phase.
Discovery Wizard and Discovery Agent support seed device discovery. When entering Ranges in the wizard, if you
specify information about one or more seed devices, discovery agent can:
Automatically discover the local subnets that it collects from the seed devices.
Find other devices connected to the seed devices to accelerate the discovery of known devices in the network. See
Define Scopes for more information about seed device discovery.
Enabled integration with CA Capacity Management by providing more detailed processor attributes for host systems
when the discovery agent is configured for WMI, SSH, and/or SNMP discovery. Note that WMI and SSH discovery will
provide more detailed processor information than SNMP. The new host system attributes published by the discovery
agent are:
ProcessorDescription
NumberOfPhysicalProcessors
NumberOfProcessorCores
NumberOfLogicalProcessors
WMI and SSH discovery provide more detailed host system information than SNMP.
Unable to find device in USM by IP Address. Click here for workaround information.
A bug in MySQL 5.5 causes a slow restart of discovery server.
NIS Manager Link in Infrastructure Manager does not work because it has been removed from the product. Use the
Discovery Wizard, available in the USM portlet, to configure discovery components.
SSH password authentication is disabled with OpenSUSE12.x.
Fixed: Reintroduced population of CM_SNMP_SYSTEM and CM_SNMP_INTERFACE tables with discovery agent
results in order to restore pre-7.0 Service Oriented Configuration (SOC) functionality and enable ACE to automatically
configure the interface_traffic and cisco_monitor probes.
Fixed: Discovery Server and Relationship Service do not properly handle Discovery Agent and Topology Agent moving
from its primary hub to its secondary hub. Now, a single Discovery Agent instance is maintained in the database with its
configuration data.
Fixed: Discovery Server failed to get discovery information for a robot managing probes that did not have the group field
set. This information is now obtained.
Fixed: An alarm was issued if an attach queue was not created for the probe_discovery subject, even if a post queue
was configured. Now, an alarm is issued only if neither an attach queue nor a post queue is configured for
probe_discovery.
Fixed: Discovery Server correlation has been adjusted to account for Cisco ASA routers. New exclusions were added to
the MAC address correlation configuration to account for Cisco ASA internal data interfaces.
Fixed: Discovery Server failed to resubscribe to a hub due to malformed nametoip requests.
7.60
Included in NMS 7.60:

Fixed: Under some networking configurations on Unix systems (particularly Solaris), the discovery agent encountered
an error expecting certain information. This caused the discovery agent to terminate before all results were published.
The Agent will now gather the information as best it can and continue discovering and publishing.
7.50

Discovery Agent has been enhanced to allow for discovery of SNMP Devices on non-default port.
Callback has been added to the discovery_server probe to allow all devices from an agent to be deleted from the
database.
Fixed: Discovery_agent could hang during ICMP Discovery.
7.10

Added support for IPv6. The discovery_agent probe can run on a pure IPv4 system or on a dual-stack IPv4/IPv6
system. To discover IPv4 and IPv6 systems, discovery_agent must run on a dual stack system.
Added correct operating system name and version detection for Microsoft Windows Server 2012 R2.
Eliminated support for Microsoft Windows Server 2003 (all forms).
7.00

Discovery configuration settings moved to Discovery Wizard.
New probe_discovery queue.
Probe GUI discontinued.
6.50
GA
March
2013
GA
December
2012
GA
September
2012
GA
June 2012
GA
March
2012
GA
December
2011
Runs all discovery protocols within a single interval.

Service discovery deactivated by default.
Additions to support Discovery Wizard (in USM).
3.50

Replaced underlying technology for performing WMI queries. Can now connect directly to Windows machines running
Vista or later. Eliminated dependency on RSP probe. WMI discovery queries can only be performed when the Discovery
Agent runs on a Windows machine
Improved the collection of the Fully Qualified Domain (Host) Name (FQDN). Adjusted various protocol queries to collect
better FQDN data
Improved support for the Automatic Deployment Engine (ADE)
Enhanced the Discovery Agent GUI:
Improved the status display--status now displays during a discovery run instead of just waiting until a run completes.
The UI provides messages when the Discovery Agent is not running or is waiting to receiving its configuration from the
Discovery Server.
Improved status counts.
Cleaned up various unused or inaccurate UI components.
Sorted protocols alphabetically
Removed unused or unneeded protocols from the Discovery Agent
Improved logging levels and messages.
3.41

To better support the Automatic Deployment Engine (ADE) and UMP, enhanced discovery to get and save processor
architecture (32/64-bit) and Linux distribution information.
Updated to use new version of Nimsoft SDK to better handle running on a system with multiple IP addresses.
Fixed DE10756: The computers found by LDAP protocol have incorrect OS type and DNS name
Fixed DE13658: Discovery_agent is unable to use SNMP V3 credentials.
3.40

Improved configuration and handling of service definitions for Service Discovery. In the corresponding version 3.40,
Discovery Server ships with a pre-defined set of service definitions for well-known network services. Discovery Agent
3.40 allows the user to enable or disable individual service definitions and configure how new definitions are handled.
3.31
Add top level support for SNMP ENTITY-MIB

Requires 3.29 or later version of discovery_server
Only information from the top-level entity is saved (e.g. the router or switch). Information about lower level entities is not
saved (e.g. power supply)
The following attributes are saved in CM_DEVICE_ATTRIBUTE:
vendor_name:
ent_phys_serialnum
ent_phys_descr
ent_phys_firmwarerev
ent_phys_hardwarerev
ent_phys_softwarerev
Fixed DE9666: Help fix discovery agent waiting forever on "waiting for configuration from discovery_server".
3.30
Updated for NMS 5.61.
3.29
November
2011
First plugin-based version of Discovery Agent to support probe based discovery and better enable service oriented
configuration in Unified Service Manager
2.39
Updated for NMS 5.12.
GA
August
2011
2.20
Changed AD indication to LDAP in GUI.
GA
October
13 2010
2.19
Optimized ICMP discovery.
GA
October 7
2010
2.00
Ported Discovery Agent to Java.
GA
May 2010
discovery_server Release Notes

The Discovery Server (discovery_server) is released as a part of the core Unified Infrastructure Management Server release.
Revision History
This table lists the known issues, fixed defects, and revision history for the discovery_server probe.
Version
Description
State
Date
8.31
GA
August
2015
Added AWS probe support for auto-scaling groups. More information about auto-scaling groups is available at Create
and Manage Groups in USM and http://aws.amazon.com/autoscaling/.
USM has been enhanced to allow users to set an alias for devices and network interfaces. To support this, the set_user
_properties probe command was updated to set the UserAlias property.
Improved support for nfa_inventory probe. For more information, refer to the nfa_inventory probe Release Notes on
the CA UIM Probes space.
8.20
GA
March
2015
GA
March
2015
Discovery Server has been enhanced to include callbacks that allow you to cleanly delete devices from both the UIM
and UDM tables in the UIM database. With the introduction of UDM, manual deletion of devices using SQL statements
was prohibited since it can cause the UDM tables to be out of sync with the rest of the UIM database. Using the
callbacks introduced in this release provides you with a mechanism to delete devices without causing syncing issues.
Discovery Server has been enhanced to work in conjunction with the vmware probe to provide partial graph publishing.
To enable this feature, additional configuration in the vmware probe is necessary.
65,536 addresses when defining a discovery range, may result in one of the two following behaviors:
When using the snmpcollector probe to query for a list of devices, defining a range greater than /16 will generate an
exception with an error message indicating that the query is not supported.
When using the Discovery Wizard to define one or more subnets using the same CIDR notation, defining a range
greater than /16, or entering multiple /16 ranges will generate an out of memory exception error.
issue.
If you are unable to find a device in USM by IP address, it may be that the device has multiple IP addresses, and
discovery identifies the device by a different address.
Discovery Wizard available in the USM portlet to configure discovery components.
communicate with a device where SSH is configured for other authentication methods, such as keyboard-interactive.
Fixed: Multiple cases where devices are not showing up as duplicate devices in USM because they are not being
correlated.
Fixed: An issue in which discovery_server is not applying enriched origins to NIS cache devices. Salesforce case
00153429.
Fixed: An issue in which discovery_server fails to re-subscribe to a hub after the hub connection is dropped. As a result
of this error, changes to the hub and/or its robots are not persisted in the database.
Fixed: An issue in which SNMP devices from the discovery_agent are not fully persisted to the database if a field (e.g.,
system description) is greater than 255 bytes. As a result of this error, the device is not populated in the
CM_SNMP_SYSTEM table. Furthermore, the device is not persisted in UDM, which prevents it from being visible in
USM.
Fixed: An issue in which the Discovery Server probe does not restart. This error is experienced regularly in
Infrastructure Manager, and only intermittently in Admin Console.
Fixed: An issue in which NIS cache devices with an invalid IP address are not persisted, including their associated
configuration items and metrics.
Fixed: An issue in which configuration items and metrics are not persisted in the database.
Fixed: Multiple cases where elements are being persisted into the UIM database, but not to UDM.
See the CA Unified Infrastructure Management - 8.2 Release Notes for more information.
8.12

Fixed an issue in which the remove_master_devices_by_cs_keys callback fails on computer systems from VMware
probe.
Fixed an issue in which discovered SNMP devices were not fully persisted to the database if a field (e.g. system
description) was greater than 255 bytes.
Fixed an issue in which discovery_server 8.10 was not applying enriched origins to NIS cache devices.
Fixed an issue in which the Discovery Server probe was not restarting from Infrastructure Manager and only
intermittently restarting from Admin Console.
Fixed an issue in which NIS cache devices without a valid IP address did include their associated configuration items
and metrics when imported.
Fixed an issue in which discovery_server 8.10 was not correlating devices based on enriched origins.
8.10
GA
December
2014
Device correlation in Discovery Server and Discovery Agent is improved to avoid false matches and incorrectly merging
non-matching devices into one device.
Discovery publishes details of each network interface.
UDM Manager is coupled with Discovery Server to integrate UDM as a key part of inventory management:
Discovery Server writes inventory to both UDM manager and NIS/TNT2 tables.
Discovery Server uses log4j logging to capture UDM log information.
Logsize is no longer specified in discovery_server.cfg. Logsize is set in the log4j.xml file.
Some data resides only in UDM (for example, USM relies on UDM as the sole source for some interface data views).
Improvements to the discovery of AIX and HP-UX systems make it possible to deploy robots to these systems using
USM.
Improvements to device correlation enable Discovery Server and Discovery Agent to avoid false matches and the
merging of non-matching devices into one device.
Enhancements to interface origins. By default, an interface inherits its origin from its associated device. If the interface
origin is enriched through the QoS processor, that origin can now be associated with the interface in UDM.
65,526 addresses when defining a discovery range may create an out of memory condition.
issue.
If you are unable to find a device in USM by IP address, it may be that the device has multiple IP addresses, and
discovery identified it by a different address.
Discovery Wizard available in the USM portlet to configure discovery components.
communicate with a device where SSH is configured for toehr authentication methods, such as keyboard-interactive.
Fixed: Device correlation in Discovery Server and Discovery Agent is improved to avoid false matches and incorrectly
merging non-matching devices into one device.
8.00

Fixed: Reintroduced population of CM_SNMP_SYSTEM and CM_SNMP_INTERFACE tables with discovery agent
results in order to restore pre-7.0 Service Oriented Configuration (SOC) functionality and enable ACE to automatically
configure the interface_traffic and cisco_monitor probes.
Fixed: Discovery Server and Relationship Service do not properly handle Discovery Agent and Topology Agent moving
from its primary hub to its secondary hub. Now a single Discovery Agent instance is maintained in the database with its
configuration data.
Fixed: Discovery Server failed to get discovery information for a robot managing probes that did not have the "group"
field set. This information is now obtained.
Fixed: An alarm was issued if an attach queue was not created for the probe_discovery subject, even if a post queue
was configured. Now an alarm is issued only if neither an attach queue nor a post queue is configured for
probe_discovery.
Fixed: Discovery Server correlation has been adjusted to account for Cisco ASA routers. New exclusions were added to
the MAC address correlation configuration to account for Cisco ASA internal data interfaces.
Fixed: Discovery Server failed to resubscribe to a hub due to malformed nametoip requests.
September
2014
7.60
June 2014
Expanded SNMP device characterization for AIX operating system information, Cisco Unified Communications devices,
and HP Tipping Point devices.
Added excluded_ip_addresses configuration parameter to IP address correlation. The parameter value supports a
comma-separated list of any combination of individual IP addresses, IP address ranges, and IP subnets in CIDR
notation (for example, 1.2.3.4, 10.1.2.3-99, 172.1.2/24).
Added excluded_fqdns and excluded_domains configuration parameters to FQDN (fully qualified domain name)
correlation.
Fixed: Discovery server includes a new version of the SDK to provide better performance on systems with multiple
network interfaces running on different subnets.
Fixed: In some cases the IP address was used as the computer name instead of the name provided by a probe.
Fixed: When a robot running a discovery agent moved from one hub to another, an extra discovery agent record was
created. Now the same discovery agent record (including the agents discovery configuration) is maintained after the
robot moves to another hub.
7.50
March
2014
Added functionality to support VMware App Views.

Enabled port to be specified in a SNMP authentication profile.
Expanded SNMP device characterization for Alcatel devices.
Expanded LUA script functionality to add device_label as a possible value that can used as the computer system name.
Removed the default setting for the CM_COMPUTER_SYSTEM caption field so that users can customize it.
Added a probe command to delete all devices discovered by a specified discovery agent.
Fixed: Discovery server startup error on SQL Server with Windows Authentication enabled.
7.10
December
2013
Added correct operating system name and version detection for Microsoft Windows Server 2012 R2.
Eliminated support for Microsoft Windows Server 2003 (all forms).
Reintroduced LUA script functionality to enable user customization of name, dedicated setting and OS info.
Expanded SNMP device characterization to better detect OS type, OS version and device role (the dedicated setting).
Fixed: Discovery Server failed on MySQL during startup when there were duplicate entries in DS_ROBOT_XREF.
Fixed: discovery_server 7.0 did not respond appropriately to origins with spaces/commas.
7.00
Included in NMS 7.0
September
2013
New probe_discovery queue for collecting a richer set of element data from probes.
Enhanced device correlation.
Probe GUI discontinued.
Changed handling of expired systems to only delete systems with no QOS data.
Fixed: Discovery did not identify multiple IPs of network devices (e.g. routers or switches) as one device.
Fixed: Devices displayed multiple times in USM.
Fixed: Some devices listed two origins when the names match.
Fixed: Duplicate Origins on remotely monitored systems.
Fixed: CM_Computer_System: nimbus_type changed to 0 when robot moved to another hub.
Fixed: discovery_server failed to insert records as origin field size is exceeded.
6.60
Added functionality to support the snmp_collector probe.
June 2013
6.50
Included in NMS 6.5
March
2013
Accepts imported device information from the cm_data_import probe and saves to the information to the NIS database.
Enhancements to support Discovery Wizard (in USM).
3.50
Included in NMS 6.2

Improved the collection of the Fully Qualified Domain (Host) Name (FQDN). Adjusted Lua script prioritization rules to
select best FQDN data.
Removed handlers for protocols the Discovery Agent no longer supports.
Fixed: cm_computer_system was missing trigger upon delete for cm_nimbus_robot on Oracle and MySQL.
December
2012
3.41
Included in NMS 6.1
September
2012
To better support the Automatic Deployment Engine (ADE) and UMP, enhanced discovery to get and save processor
architecture (32/64-bit) and Linux distribution information.
Updated to use new version of Nimsoft SDK to better handle running on a system with multiple IP addresses.
3.40
Included in NMS 6.0
June 2012
Enabled up to 200 discovery agents to be controlled by the discovery server without requiring an increase in the number
of threads or amount of memory used.
Provided a default level of Service Discovery by adding pre-defined service definitions for well-known network services
such as HTTP, FTP, email, etc.
Enabled discovery server to run on a different robot other than the primary hub.
Reduced memory usage to support up to 5000 robots using the default maximum Java heap size of 1GB.
Added further improvements to reduce the number of sockets and database connections to help overall Nimsoft Server
performance.
Fixed database transaction deadlocks seen with Microsoft SQL Server; fixed other SQL error cases.
Fixed SOC defect.
3.29
Add top level support for SNMP ENTITY-MIB

Requires 3.31 or later version of discovery_agent.
March
2012
Only information from the top-level entity is saved (e.g. the router or switch). Information about lower level entities is not
saved (e.g. power supply).
Improved origin handling to better support custom origins in multi-tenancy environments.
Reduced number of threads and database connections to help overall Nimsoft Server performance.
Re-established regular interval for collecting data from hubs and robots to ensure that full updated data is collected on a
timely basis.
Improved accuracy and consistency of data written to the database.
Improved performance of database updates.
Fixed: Some customers no longer show their devices in USM/Dynamic Dashboard. Handle origin changes in discovery.
Fixed: Systems are missing from dynamic views due to many CM_DEVICE entries with null cs_id.
Fixed: discovery_server maps robots with same IPs incorrectly in data centers that have robots with different names, but
the same IP address.
Fixed: Help fix discovery agent waiting forever on waiting for configuration from discovery_server.
3.28
Included in NMS 5.61
December
2011
Increased default maximum Java heap size to 1GB (from 256MB) to support up to 2000 robots.
3.25
November
2011
First plugin-based version of discovery_server to support probe based discovery and better enable service oriented
configuration in Unified Service Manager.
2.79
August
2011
diskstat (iSeries Disk Monitoring) Release Notes

The iSeries Disk Monitoring (diskstat) probe monitors disks that are assigned to an Auxiliary Storage Pool (ASP) on IBM iSeries systems. The
probe identifies disks through disk properties such as ASP number, Disk Type and, Disk Unit Number. The probe enables you to monitor disk
performance and track disk activities such as disk usage, disk capacity, and the number of read and writes completed per second.
Contents
Revision History
Revision History
Version
Description
State
Date
1.07
Fixed Defects:
GA
January
2016
GA
September
2015
The probe was unable to expand the $resource_name, $asp_number, and $disk_unit_number variables in the alarm
message. Support case number 00245283
1.06
What's New:
1.05
Fixed configuration tool profile save problem caused by a problem with the 'Disk usage in %' QoS setting.
GA
August
2012
1.04
More logging and improved handling of missing data on calculations.
GA
January
2012
1.00
Initial version
GA
June 2011

The probe is installed on systems with the following minimum resources:

IBM iSeries 5.1 or above
distsrv (Monitor Distribution Server) Release Notes

The Distribution Server is an important part of the CA Unified Infrastructure Management that maintains distributable packages, licenses, and
Alarm Console Maps.
Revision History
Version
Description
State
Date
5.30
Web-based configuration GUI added (no version change)
GA
Sept
2013
5.30
Defect fixes
June
2013
5.22
For Windows: fixed problems for the probe when encountering 'problem' packages.
July
2012
Configuration tool: changed save operation to save all settings in one request to the controller.
5.21
New libraries
Dec
2011
5.20
Implemented cancel of jobs entered on remote distribution server.
Sep
2011
Added handling of SID expired situation on distribution over tunnels (while using remote distsrv).
Support for IPv6. (Future use.)
5.14
Threading stability fix for Linux platforms
July
2011
5.13
Fixed intermittent problem on Linux platforms introduced in beta version 5.12 where distsrv could stop responding after some time.
Jun
28
2011
5. 12
Increased limitations for license size.
Jun
22
2011
Changed field type of the server field in the forwarding profile dialog to allow unlisted values.
'attempt_number' cleanup done to avoid looping and added specific error message added for situations where the distribution
result can not be obtained.
Fixed package sort by date in configuration tool.
Fixed dependency checking on forwarded distribution.
Added a small delay between processing forwarding profiles.
Separated license read/write locks.
Added option to enable/disable forwarding.
5.11
Fixed session request reconnect problem during distribution.
Jan
27
2011
5.10
Threading implemented for job_status and job_list callback functions.
Jan
19
2011
Improved error handling for session requests.

Version recognition fix.
Added 'file' argument to 'archive_put_start' to enable more consistent archive management.
Fixed problem with forwarding interfering with the last change parameters from the 'get_info' callback.
5.04
Fixed archive list 'since' parameter problem on 64-bit Solaris.
Dec
2010
5.03
Parameter size limit for tasks increased. Also added limit checking.
Nov
2010
5.02
Initial support for internationalization of alarm texts.
Oct
2010
Added support for extended NIS data model.

Confguration tool fix for package forwarding; improved parsing logic for package list.
5.00
Modified licensing forwarding logic.
Jul
2010
4.95
Dependencies in remote distributions did not behave well. Problems were found and fixed:
Jun
2010
Memory leak on package dependencies with version check.

Repeated unneccessary download requests for dependency packages.
Improved dependency package download logic.
unzip library function not thread safe on Solaris.
This caused both occasional errors on registering a distribution job as well as various error messages on distribution. A critical
section was added to the function where packages are unpacked to avoid this problem.
There was a memory usage error on package dependency version checking which occasionally caused distsrv to crash. Even
though the problem was generic we have seen this problem only on Solaris. The effect of this problem was that distsrv would
'forget' a number of queued and ongoing distributions.
4.91
Enhanced support for multiple Network Interface cards (NICs) on the computer. Nimsoft communication is now supported in other
NICs than the default Robot interface.
Mar
2010
Support for encrypted SSL Nimsoft communication.

License check fixed for dependency packages.
Implemented 'get_info' callback.
4.90
Updated Libraries
Dec
2009
4.80
Replaced security setting on remote (internal) commands with security keyword.
Oct
2009
Changed callbacks from secondary distsrv back to primary to ensure asynchronous behavior.
Added caching of IP addresses on robot name lookup.
Added option to use local archive on remote distributions.
Store information on completed distributions in embedded database.
Added option to trigger forwarding immediately on a detected change.
Fixed situation where package was repeatedly forwarded.
'All versions' option for package forwarding added.
Fixed potential crash situation on 'archive_list'.
Improved error message on dependency which is not satisfied.
Rewritten package dependency checking on distribution. Multi-level dependencies are handled with new (3.53) robots.
4.74
Fixed license_check call that caused probe failure on unlicensed probes.

Fixed archive_rename and added archive copy callback functions.
Fixed problem with package file extension '.ZIP'.
Changed dependency error messages so that the correct version formatting is used.
For UNIX/Linux: added cr/lf handling code for distribution and package update.
Added support for 'start_after' keyword in probe definition.
Modified forwarding of 'Map' packages so that the existing version is replaced.
Removed extra text at end of archive_get_pkginfo output on Windows.
Aug
2009
4.72
Support for no_shutdown and temp_directory when creating a probe from an existing probe.
Dec
2008
Fixed license forwarding.

Changed default configuration tool window placement.
Fixed problem with setting probe security.
4.71
Added option to forward licenses.
Sep
2008
64bit support (64-bit UNIX support)

Fixed problem with configuration file not being saved when using archive configuration on a package with a version number.
Fixed problem with deleting package without version, where the package with the highest version would be deleted.
Included Archive Configure option that will work with logmon 2.20.
Fixed version comparison problem for package forwarding.
Fixed problem with updating a configuration file in a package with version.
Fixed problem with package dependencies to exact version.
Please note that, for version 4.71 and higher of this probe, NimBUS Robot version 3.00 (or higher) is a prerequisite. You are
4.18
Fixed version comparison problem for package forwarding.
May
2008
Fixed problem with updating a configuration file in a package with version.

Fixed problem with package dependencies to exact version.
4.17
Fixed problem with deleting package without version, where the package with the highest version would be deleted.
Feb
2008
4.16
Changed version recognition logic to allow mapping of empty version string to package without version. Modified
'archive_create_from_probe' and 'archive_config_from_probe' to write to the correct package version file.
Nov
2007
Modified 'license_check' callback to return additional license information.

Fixed 'archive_list_configs' for archive configuration support.
Added information to the package so that the package archive will be removed on probe removal.
Modified distribution to give correct dependency errors on 'built in' packages (robot, perl library).
Modified 'archive_config_put' to enable package configuration with the normal probe configuration tools.
Modified 'license_check' call to accept remote calls without security id.
Added 'list_archive_configure' call for controlling package configure support.
Modified package forwarding so that all communication with each remote distsrv uses a separate session.
Added option to always forward license with package forward. Add 'always_forward_license = yes' to the setup section of the
probe configuration file to enable this functionality.
Changed callbacks that pull probe or probe configuration back into the archive to allow overwriting an existing package. The
version of the original package will be used, but the build number incremented. Dependency check version comparison fix.
Modified package forwarding mechanism to always check the package with highest version.
Default for 'keep history' reduced to 7 days.
Modified dependency check to avoid "_0.0" version error when dependency package not found.
Fixes for check of dependency/version.
Changed logging of checksums.
Modified logic for sending back installation status on remote distributions.
Added option to set log file truncation size.

Fixed install_list configuration bug. install_list//retry_attempts was written to retry_attempts and install_list//retry_timeout was read
from retry_timeout.
Fixed missing status update when a hub was distributed via remote distsrv.
Implemented minimum configurator dialog box size.
Denied column reordering in all list views.
Fixed unhandled exception when entering alpha characters in Forward interval, Keep history and CRC error retry count text
boxes.
Fixed dialog box icons.
Changed server list in the forward package dialog to drop down list.
Removed log filename from configurator.
Changed attempts and retry sliders to text boxes. Added retry range 0 - 20 and delay range 1 - 1440.
Added resize function to the forward package dialog.
Changed add package dialog from toolbox dialog to fixed dialog.
Fixed bug: Remote installation package transfer does not work correctly.
Fixed deadlock on UNIX systems when deleting licenses.
Modified code to recognize all 'Windows*' os types as 'win32' on creation of a probe or config package.
Added logging of error situations on package creation.
Linux fix for opening packages in the archive.
Support for Package dependencies '.NET Framework' and 'Windows Installer' added. Fixed 'configurator_get' to allow use of
version. Added logic to determine if license information needs to be updates in the configuration file. Modified dependency check
algorithm. 4.02 17 Jan 2006 Fix in archive put related to multiple package versions. Added 'block_size' to setup section of
configuration file to allow configuring the block size used for transferring files. The default block size was increased from 4 to 32
Kb. Added recognition of 'Windows Server 2003' OS when pulling a probe or probe configuration into the archive. Modified startup
order to avoid license validation errors right after startup.
4.00
Added support for multiple package versions. UNIX port to Linux and AIX
Feb
2006

Robot version 3.00 (or higher) is required for distsrv versions 4.71 or later.
When distributing distsrv, it cannot detect its own completion, so you will see an 'Installation Aborted' message even if there was no error. You
can verify that the new version of the distribution server is running by starting its configuration window and looking at the version on the status bar.
dns_response (DNS Response Monitoring) Release Notes

The DNS Response Monitoring probe queries your Domain Name Server (DNS) and monitors the response time from the server. The probe can
also query the DNS looking for A records (normal hostnames), MX records (mail servers), and NS records (name servers). The dns_response
probe queries your DNS server and measurse the time it takes to get a response.
It will send alarms if the query fails, or if the response times are above the defined thresholds. The probe is QoS enabled and will send QoS data
on profiles where the QoS option has been enabled. The probe uses the 'host' utility, which is shipped with the probe package.
Contents
Revision History
Revision History
Version
Description
State
Date
1.68
Fixed Defects:
GA
July 2014
Added an option for configuring the log file size through IM probe GUI. Salesforce case 00131070
1.67
Made configurable DNS type A or Any in case user has configured type A through GUI.
April 2014
1.66
Modified probe defaults
June 2013
1.65
Added Probe Defaults for the probe
February 2013
1.64
Fixed UDP issue.
March 2012
1.63
Fixed dns_response to support override of the source field.
January 2012
1.62
Fixed SOC issues.
December 2011
1.60
March 2011

Fixed probe crash situation on setup nameserver test.
1.50
Updated the probe to use c-ares DNS library v1.6.0. The probe no more uses host utility to perform dns queries.
September 2010
Added support for performing reverse lookup along with forward lookup from a single profile.
Added support for TXT DNS query type.
Added support for specifying DNS port.
Added support for CHAOS DNS query class.
Prohibited the use of white space in GUI configurator and fixed some minor GUI issues.
1.41
Made changes to library with respect to configuration locking.
June 2010
1.40
Added NIS (TN2) changes.
May 2010
1.31
Upgraded host utility to BIND 9.6.1-P1 for Windows XP/2003/2008.
May 2010
1.30
Upgraded host utility to bind 9.6.0 patch 1.
September 2009
Added native 64 bit support.

1.26
Minor cosmetic GUI adjustments for timeout and retry.
August 2008
Updated the code clear alarms on start.

Added a fix for crash when deactivating the probe.
Added a fix in GUI to only accept numeric values for run interval.
Added a fix for alarm message.
1.25
Minor cosmetic GUI adjustments for timeout and retry.
June 2008
Updated the code to store the timeout value.

Updated to code to send alarms on dns error when threshold are not set.
Minor cosmetic GUI adjustments.
Corrected the ability to store the timeout value.
Added thread logging and improved thread synchronization.
1.23
Corrected ability to switch to using default nameserver if 'Use nameserver' is defined.

Fixed sending of alarms. If the alarm check boxes are cleared no alarms are sent.
August 2006
1.21
Allow blank default nameserver field (uses system defined nameservers).
1.22
New GUI layout with message pool.
June 2006
March 2006
The probe is now using the 'host' utility instead of 'nslookup'. This utility is distributed with the probe.
Fixed problem with "Non-English" operating system.
May now run on various unix-systems as well.

The dns_response probe should be installed on systems with the following minimum resources:
Memory: 2-4 GB of RAM. This probe OOTB configuration requires 256 MB of RAM.

The dns_response probe requires the following software environment:
Robot 5.23 or later
Note: For SOC functionality, NM Server 5.6 or later and UMP 2.5.2 or later is required.
A 'host 'utility is distributed with the package. This utility is based on bind 9.6 package.
The Tru64 (OSF1_4 alpha) package contains host based on bind 9.3. The 'host' utility is only on 32-bit Windows platforms.
When upgrading from versions prior to 1.23, alarm messages must be cleared manually before upgrading. The probe will malfunction if these
messages are not cleared before upgrade.
Note: Upgrading from versions prior to 1.23, alarm messages must be cleared manually before upgrading. The probe will malfunction if
these messages are not cleared before upgrade. On Upgrade from GA to TNT2 version OR Downgrade from TNT2 to GA version, the
probe-specific file alarms.txt should be removed from the working directory to ensure smooth upgrade and downgrade.
e2e_appmon (E2E Application Response Monitoring) Release Notes

The E2E Application Response Monitoring (e2e_appmon) probe runs the precompiled NimRecorder scripts to monitor the application response
time and its performance parameters. Each transaction runs for the specified time limit and generates QoS from the script. The probe also
measures the total run time of each transaction and availability of the client applications.
With version 2.22 and later, the probe supports Time Over Threshold (TOT) feature for the custom QoS and alarms.
With version 2.23 and later, the probe also supports Google Chrome for web-based scripting.
Note: This probe replaces the old wintask probe.
Contents
Revision History
Probe Features
User Access Prerequisites
Google Chrome Support
Upgrade and Migration Considerations
Revision History
Version
Description
State
Date
2.24
Fixed Defects:
GA
November
2015
GA
July 2015
GA
March
2015
GA
November
2014
When viewing data on UMP, the probe did not override the default alarm source. Salesforce case 00165820
Updated the Software Requirements in the probe Release Notes to describe the ppm probe dependency. Salesforce
case 70003306
2.23
What's New:
Added support for executing web-based scripts on Google Chrome.
Note: This feature is supported only on NimRecorder 5.2 and later. Refer to the Google Chrome Support section for more
information.
2.22
What's New:
Added support for Static Threshold for custom metrics.
Fixed Defects:
The probe did not show up on the robot even though it was successfully distributed. This issue occurred on a Windows
7, 32-bit operating system. Salesforce cases 00152965, 00159264
2.21
Added support for Windows 8 and Windows Server 2012 R2.

Upgraded the NimRecorder to version 5.1.
2.20
Added NimRecorder 5.0, which is compatible with both 32-bit and 64-bit environments and removed Wintask64. The
scripts that are recorded with Wintask64 are compatible with NimRecorder 5.0 also.
March
2014

2.10
Added a feature to allow selecting multiple files during package building session.
Beta
June 2013
Added a feature to remember user preferences versus last used dir In package builder.
Added a feature to Packaging Screen Default Support.
Added a validation to select at least one script file to create package.
Wintask64 added to support 64-bit applications.
2.00
Added a feature to create a script package from the e2e_appmon probe.

Upgraded the NimRecoder to version 4.0
1.93
Fixed the scheduling functionality of the probe.

Fixed an issue where alarm is generated after upgrade.
March
2013
November
2012
1.92
Fixed source override for script generated messages when a source is specified in the profile.
May 2012
Fixed tray icon update for suspend mode.

Updated NimRecorder to version 3.8.
Added code to transfer the probe id from the probe to the script starter and set probe id for script generated messages.
1.91
Enabled QoS source override for script generated QoS.
June 2011
Added support for 64-bit windows version.

Note: Only the Internet Explorer 32-bit version is supported.
1.90

December
2010
1.82
Option for immediate registry reset after logon.
September
2010
1.81
NimRecorder updated to version 3.7a.
September
2010
1.80
Added NIS(TNT2) Changes.
June 2010
1.71
Resolved problem with multiple desktops (RDP connections) in e2e_starter. Turned off legal notices before automatic
login and reset on probe termination. Fixed crash situation on callback using missing data.
January
2010
Fixed problem with starting script before login was completed on Windows 2008.
1.71
1.63
NimRecorder updated to version 3.7.

Fixed logon and script start problems on Vista.
NimRecorder updated to version 3.5a.
1.62
NimRecorder updated to version 3.5:

Improved update mechanism.
January
2010
October
2008
August
2008
Correct installation even if NimBUS is installed to a non-standard directory.

Modified e2e_starter.exe to be independent from NimBUS registry settings.
Changed to global event for communicating between the probe and starter utility.
Added utility for Windows Vista to be able to perform controlled logon and log out.
1.61
Added source override option for QoS and Alarm messages.
February
2007
1.60
NimRecorder v3.3 which supports IE7
January
2007
1.52
Added check for running 'e2e_starter'. Default check interval is 3 minutes.
December
2006
1.51
Apply correct version number

Includes NimRecorder v3.2.
October
2006
Improved error handling in e2e_starter.

1.11
1.10
Clean up script after timeout fix.

Updated WinTask binaries to version 3.1a
June 2006
May 2006
Clean up in nimmacro.dll.
1.00
Initial version. Functionality as for the replaced wintask probe. Subsystem set to 1.2.3.7.
Probe Features
The e2e_appmon probe provides the following features:
Alarms: You can specify threshold values to generate the alarms when these values are breached.
QoS: You can select the QoS option to generate the QoS messages on total run time for profiles.
February
2006
Scripts: The e2e_appmon probe runs scripts at specified intervals to monitor the availability and the response time of the target
applications. With the NimRecorder (shipped with e2e_appmon_dev probe), you can make your own scripts. Use the e2e_appmon API to
include checkpoints in your scripts. The scripts must be compiled on the machines where they are run.
Important! Do not run other applications or tasks on the monitoring computer, as it disrupts the probe monitoring and
measurement process.
Note: The e2e_appmon probe has limitations to use Optical Character Recognition (OCR) in the scripts. So, instead of using
OCR, you can use the bitmap synchronization (synchronization on an image) to use the text logo.
Sample Script: The probe is deployed with a sample script. Activate the probe and run the sample script. Compile the script on the
target computer before executing it. If you execute the script before compiling, an error message displays. For example, the error
message is: Error at line 348: Impossible to load the module.
A script is compiled based on each operating system configuration. Hence, the compiled script can run only on similarly configured
computers.
Probe Editions: The e2e_appmon probe is available in the following two editions:
The runtime edition of the probe enables you to run precompiled scripts.
The developer edition of the probe, the e2e_appmon_dev, lets you create scripts and include checkpoints in those scripts. The
e2e_appmon_dev probe measures intermediate time of each process along with the total runtime of the script. Some help files to aid
develop scripts are also included.
The NimRecorder: You can use NimRecorder, which is included in the probe package, to create your own scripts. The NimRecorder can
be launched from Start > All Programs > Nimsoft Monitoring > E2E Scripting. The NimRecorder has the following menu options:
Compile *
Help *
Open Script *
Run Script
Script Editor *
Spy *
Uninstall NimRecorder
Note: The options marked with an asterisk (*) are available only in the developer edition of the probe or after installing the
NimRecorder manually.
The e2e_appmon probe is now available with NimRecorder 5.2 to create and execute scripts for 64-bit platforms. The NimRecorder 5.2
also supports web-based scripting for Internet Explorer, Google Chrome, and Mozilla Firefox. Refer the NimRecorder 5.2 help for
supported platforms and browser versions and other relevant information. You can access the NimRecorder help from the Start > All
Programs > Nimsoft Monitoring > E2E Scripting > Help location. This help file is also available from the Help menu available in the
NimRecorder application.
Note: Google Chrome support is available only with NimRecorder 5.2 and later.

The e2e_appmon probe is installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. The OOB configuration of the probe requires 256 MB of RAM
CPU: 3-GHz dual-core processor 32 bit or 64 bit

The e2e_appmon probe requires the following software environment:
The following points must be considered while installing the probe:
When migrating from the earlier wintask probe, disable the wintask probe.
On the first startup of e2e_appmon, the probe reads and takes the wintask probe configuration.
Note: The QoS object names are changed. The instances of the probe running on a computer with the earlier wintask probe now
generate QoS on a different object. The probe instances that are installed on a clean robot will have the new QoS object names. You
can change this option in the Variables tab of the probe.
The probe is initially inactive. Specify the user credentials with which the probe connects to the system. Once you provide the user
credentials and activate the probe, the current session exits, and the probe initiates a login as the specified user.
Important! Ensure that no screensaver is active as it interferes with the running of the scripts.
User Access Prerequisites

All the users included in the probe profile must have administrative access (read and write permissions) to the <CA UIM Installation Directory>.
The WTBho Class, a NimRecorder add-on, must be enabled on Internet Explorer, Mozilla Firefox, and Google Chrome for executing the
web-based scripts.
Notes:
Verify that the environment is properly set up during the first run. For instance, the 'internet connect' wizard may need to be
run.
No instances of Internet Explorer should be open during the installation.
To enable WTBho, follow one of these steps on your browser:

(Internet Explorer) Select Tools > Internet options > Programs. Click Manage add-ons and enable WTBho from the displayed list.
(Firefox) Select Add-ons > Extensions, and enable the NimRecorder extension.
(Chrome) Select Settings > Extensions, and enable the NimRecorder extension
After you enable WTBho, restart NimRecorder.
Google Chrome Support

For Google Chrome to support NimRecorder script execution, install the NimRecorder extension to your browser.
Note: The Google Chrome support is available only with NimRecorder 5.2 and later.
1. Go to the chrome webstore.

2. Select Extensions from the list.
3. Search NimRecorder in the chrome web store.
4. Install the extension from the webstore.
Upgrade and Migration Considerations

Recompile your existing scripts using the new NimRecorder while upgrading the e2e_appmon probe older than 1.62 version. The new
NimRecorder is deployed with probe package for recompiling the existing scripts. The scripts become compatible with the new
NimRecorder once recompiled. The NimRecorder is available at the Start > All Programs > Nimsoft Monitoring > E2E Scripting.
Notes:
Recompile your existing scripts, whenever the NimRecorder version is updated.
Send an email to info@wintask.com for troubleshooting your script-related issues and support on NimRecorder 5.2.
Uninstall any previous version of the NimRecorder and ensure that the bin directory under the Nimsoft/e2e_scripting directory does not
exist anymore. Delete the bin directory, if exists, and then install the latest version of the probe. Take backup of all existing scripts before
uninstalling the NimRecorder.
In case, you are upgrading the e2e_appmon_dev probe from 2.0x to 2.2x and the probe does not upgrade the NimRecorder to
NimRecorder 5.2. Navigate to <Nimsoft Installation drive>/Nimsoft/probes/Application/e2e_appmon/install and double-click the nim
recorder52.msi for installing it manually.
Note: If you are upgrading the e2e_appmon from earlier wintask probe, refer the e2e_appmon probe 2.0 documentation or earlier.
email_response (Email Response Monitoring) Release Notes

The email_response probe tests Internet e-mail response by sending e-mail messages and reading from a mailbox, using the SMTP and
pop3/imap protocols. The probe sends email through the Microsoft Exchange environment and monitors the average send/receive and round-trip
response time.
The observed response times can help administrators identify the delay in email
Revision History
Alarm and Quality of Service Messages
Revision History
Version
Description
State
Date
1.44
Provided the option (via Raw Configuration) to disable GSSAPI Authentication with Exchange Server.
GA
August 2013
1.43
Added probe defaults.
GA
February 2013
1.42
Added SMTP authentication for sending mails.
GA
January 2013
1.41
Support added for SOC.
GA
November 2012
1.40

December 2010
1.30
Added native support for Linux (32-bit & 64-bit).

Added native support for Windows.
Added a feature probe for configuring pop/imap port number.
Added a feature for disabling SSL certificate validation.
Fixed an issue in the GUI configurator related to probe sending late alarms when late alarms are disabled.
Fixed an issue where the probe tries to connect to port 143 when 'Force SSL' is selected.
Prohibited the use of whitespace in the GUI configurator.
September 2010
1.21
June 2010
1.20
May 2010
1.16
Fixes for issues:

Variables not working in alarm messages.
Probe sends RoundTrip late alarm when unchecked.
Updating the "message" field, is not recognized as a change in the GUI.
Probe generating late alarms when disabled.
$ variable lists not displayed.
September 2009
1.15
Fixes for authentication and SSL on SMTP send.

Added 'Protocol Debug' option in configurator.
Handle '554 Relay access denied' error when sending email.
December 2006
Added flag to turn off TLS protocol support.

Added support to change default logfile size.
Bounce fix.
Fixed for smtp authentication.
Additional logging on log level 3.
Modified error handling of 'disappearing' messages on server.
Fixed problem with several profiles checking the same mailbox.
November 2006
Added SMTP login and option to specify return address
March 2005
1.08

The email_response probe requires the following software environment:
CA Unified Infrastructure ManagementServer 7.6 or CA Unified Infrastructure Management 8.0 or later

The email_response probe should be installed on systems with the following minimum resources:
Alarm and Quality of Service Messages

Alarm messages can be generated based on the mail roundtrip time.
Quality of Service (QoS) messages can be generated based on the time it takes to send an email and the time it takes for the email to reach the
user's mailbox (i.e. the roundtrip time).
When creating a profile to receive mail from Microsoft Exchange, in some cases the probe is unable to log on if the Exchange user has an alias
defined.
emailgtw (Email Gateway Monitoring) Release Notes

The Email Gateway Monitoring (emailgtw) probe converts alarms from the NAS server into emails sent to defined recipients. The emails are sent
based on predefined criteria for alarms, such as, severity, origin, and time. For Windows robots, you can use the SMTP server or the Exchange
server to send emails. For robots on other operating system, you can only use SMTP to send emails.
Revision History
Revision History
Version
Description
State
Date
2.74
Fixed Defects:
GA
January
2016
GA
September
2015
GA
December
2014
The probe crashed when you manually executed the script. Support case number 70005789
2.73
Fixed Defects:
The probe now includes the entire alarm string in the email messages. Salesforce case 00160416
Updated the preconfiguration requirements in the Release Notes about installing SMTP Server certificate for using TLS
functionality. Salesforce case 00154509
2.72
Fixed Defects:
Fixed a defect where the probe did not support characters more than 1024 in the Email field in the Profiles section for
the exchange server, and the SMTP server. Salesforce case 00145450
Fixed a defect where the probe was crashing frequently. Salesforce case 00148576
2.70
2.60
Added Exchange Server support for Windows OS

Japanese description of windows event log garbled issue fixed.
Exchange 2007 mail relay issue because of unnecessary authentication is fixed. SMTP authentication should be
avoided when user/password not supplied in probe GUI.
2.41
2.40
Added fix for SMTP authentication.

Added NIS (TNT2) changes.
Fixed memory leak.
March
2013
December
2012
December
2010
September
2010
2.32
Added References: to message.
July 2010
2.31
Added a fix to support blank username and password.
September
2009
2.30
Changed the c-client library to imap2007e.

Added support for the platforms: AIX_5_64, HPUX_11_64, LINUX_23_64, SOLARIS_8_sparcv9, win64.
Added backup email address support to track mails sent by emailgtw.
Fixed configurator crash when testing promary server.
Fixed configuration tool problems with profile names contianing only numerics.
Changed configuration tool to allow specifying port number together with the smtp server name in the format :
Changed date expansion for date variables.
SSL Send authentication fix. This was earlier fixed in version 2.11, however the smtp library has been upgraded,
thereby loosing this fix. The problem is now corrected by always trying to authenticate if user/password is specified.
August
2009
2.21
Fix: In html mode a newline had gotten into the email body, causing some mail servers (seen on qmail) to return an
error.
January
2009
Fix: The AO-timestamp (which is only for internal use in the NAS) was erroneously a part of the text template, and has
been removed. The HTML template did not have this field and is not modified.
2.20
Fixed problem with subject being reset to default subject for some recipients in a group.
Added option to group recipients so that one email is sent with multiple recipients in the TO: field instead of a separate
email to each recipient.
January
2008
Content type will be set to text/html if a tag is found. If the use_html flag is set then this is added automatically.
Added new variables which display the time at the alarm sender's time (calculates timezone offsets and generates a
time string).
Note: Use of the new variables requires that Robot 2.68, Hub 4.20 and NAS 3.03 has been installed accross the
infrastructure as the required fields are not present in older component versions.
Fixed problem where sending to multiple recipients could cause a crash due to a memory error.
Retry with authentication if the mail server returns error '554 Relay access denied'.
2.10
Fix: Retry connection when connection to Hub drops. Send alarm when there are connection issues.
Fix: Bug in error handling could cause a loss of connection to the Hub.
2.08
Windows: Retry connection to server on connection errors. This is an amplification of the error handling for error code
10048 in the previous release.
October
2007
September
2006
Add option to ignore TLS for servers that announce the capability but don't actually support it. Windows: Retry
connection to server if error code 10048 is returned. This can happen on servers with a large number of sockets in use.
Fix: Strip newlines from subject before sending email, otherwise the mail header gets corrupted. This can cause html
mail to appear as plain text.
2.04
Fix: $ signs were treated as variables even though they did not match any known variable names and getting removed from
the message. Only known variables (see list in the Variable Substitution section below) will be blanked, leaving all other
strings containing a $ in the expanded message.
March
2006
2.03
GUI setup dialog has 'Use HTML format' checkbox added which sets the 'use_html' parameter in the config.
February
2006
2.02
Fix: SMTP Server test now verifies connection even if no authentication credentials are specified. Used to verify
connection to open SMTP servers.
December
2005
Flag use_html can be set to 'no' in RawConfigure to get cleartext mail. A cleartext template (template.txt is included)
should be set if use_html=no.
2.01
Added $count variable, which is $suppcount + 1, to match alarm list. Template.html uses $count in place of $suppcount
to avoid confusion.
December
2005
The probe has been rewritten and no longer requires Perl.

SMTP authentication is now supported.
Multiple SMTP servers can be specified for redundancy.
Alarm severity and subsystem for "SMTP server unavail able" alarm can be configured, but not the alarm text (which
uses the error message from the SMTP server).
NimBUS Users email addresses, as set in NimBUS User Administration, are used if no profile is present. If neither
profile or NimBUS User email exist then the address is used as-is.
Profiles can override the default message template and email subject.
Confusing Active flag has been renamed. Report checkbox now specifies if the profile should recieve reports. All profiles
are active as long as they are defined.
GUI has been redesigned.
1.51
Added new variable $hostname_strip which strips out the domain part of the hostname. The template.html file uses this new
variable by default. Fixed a bug where a dot (.) as the 76th character on a line would be removed. This caused IP addresses
to be changed in some cases.

The emailgtw probe should be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. Probe OOB configuration requires 256MB of RAM
March
2005

The emailgtw probe requires the following software environment.
Access to an SMTP server (does not have to be local)
Exchange server versions supported are 2007 and 2010
OpenSSL installation for Linux platform
For Exchange server, Microsoft Outlook must be installed and set as the default mail client (supported version of Microsoft Outlook is
2007 and 2010).
Note: 64-bit version of Outlook must be installed on 64-bit machines. User access settings (UAC) must be at lowest level if you
are using Outlook 2010. This setting applies to Windows Vista and later versions.
This section contains the preconfiguration requirements for the probe.
The nas (Alarm Server) probe must also be configured to send alarms to the email gateway. For more information on the nas
configuration, see The Auto-Operator Tab article under the nas (Alarm Server) documentation.
The SMTP certificate must be installed on the host machine where the probe is deployed. This is required to use Transport Layer
Security (TLS).
The Linux robot where the probe is deployed must have OpenSSL certificate installed to use the TLS functionality to connect to the
SMTP server.
To configure the probe using IPv6 format, ensure that the following prerequisites are met:
The CA UIM system can run the secondary hub on IPv4 or IPv6 environment but the primary hub can only run on IPv4 environment.
To configure the probe on a remote hub that runs the probe on IPv6 environment, follow these steps:
Create a queue of type attach with subject *.
Create a queue of type get to fetch data from IPv4 hub by calling the queue that is created on IPv4 hub.
To configure the probe on a remote hub that runs the probe on IPv4 and IPv6 environment, follow these steps:
Create a queue of type get to fetch data from IPv6 hub by calling the queue that is created on IPv6 hub.
Create a queue of type post to push all the data to CA UIM IPv4 primary hub.
Create a queue of type post for pushing all data with Subject/Queue as an email to CA UIM secondary IPv6 hub.
To configure the probe with the Exchange server, Outlook client with an existing MAPI profile must exist on the same system where the
probe is deployed. The MAPI profile must be a user in the Exchange server that the probe uses to send emails.
Version 2.20 of this probe allows you to expand the time strings offset to the sender's local time if they are in a different timezone. This
requires Robot 2.68, Hub 4.20 and NAS 3.03 since the offset was unavailable prior to those versions.
Version 2.00 of this probe allows you to use the email field for a user in the CA UIM User Administration instead of the user profile. If you
want to override the default template and email subject, you will need to create a profile.
Version 1.60 of this probe allows you to send emails to defined users when an alarm is assigned to them. If you are using a queue on the
Hub, the Subject must be changed from "EMAIL" to "EMAIL,alarm_assign". If you are not using a queue, you can check the appropriate
box in the configuration utility and the probe will subscribe to the alarm_assign messages as well as the EMAIL messages.
Note: The profile name must be an exact match with the CA UIM user name for correct operation of email on assignment.
Version 1.41 of this probe requires version 2.03 of the Perl RunTime or SDK to run properly. Run the following perl script to know the
installed version:
#!perl
use Nimbus::API;
print "$Nimbus::API::VERSION\n";
Some SMTP servers validate the From: address. If this is the case with your SMTP server, ensure that the specified "Sender email
address" is valid.

The known issues for the probe are:
The probe supports only text authentication during a TLS handshake. Encrypted authentication fails in this case.
To configure the probe with the Gmail SMTP server, follow these steps:
Clear the Ignore TLS check box in the SMTP tab.
Login to your Gmail account.
Go to the link https://www.google.com/settings/security/lesssecureapps
Enable the Access for less secure apps option.
ews_response (Microsoft Exchange Server Response Monitoring) Release Notes

The Microsoft Exchange Server Response Monitoring (ews_response) probe tests the performance of your Microsoft Exchange Server
connection by sending and receiving test emails using webmail. These test emails reflect the actual end-user experience of the Exchange Web
Server.
The probe can also return email from another instance of the probe for end-to-end monitoring of round-trip time of the email. The probe measures
email round-trip for internal and external email accounts and generates QoS. You can configure alarms when unknown emails are detected in the
mailbox and the threshold value of the email round-trip time is breached.
The probe supports Exchange Server 2010, 2010 SP1, 2010 SP2, 2010 SP3, and 2013 SP1.
Note: The probe only supports basic and NTLM (NT LAN Manager) authentication.
Contents
Revision History
Installation Consideration
Revision History
Version
Description
State
Date
2.03
What's New:
GA
July
2015
Added support for Exchange Server 2013 SP1 monitoring.
1.11
What's New:
GA
June
2014
Beta
June
2014
Added support for monitoring Exchange Server 2010 SP3.

Support for monitoring Exchange Server 2007 is discontinued.
1.10
What's New:
Added support for monitoring Exchange Server 2010 SP2.
1.05
What's New:
March
2014
Added support for JRE 1.7x.
1.04
Fixed Defects:
January
2014
The Bounce Back emails were being sent back to wrong recipients. The probe was sending the Bounce Back emails to the
first email ID from the address list.
The default Roundtrip error message was displaying variable in place of value of the variable.
1.02
Implemented Clear Alarm Functionality for Mail Lost Alarm
January
2013
1.01
Fixed Defects:
July
2012
Provided a fix to send email to self.

Provided a fix to run probe on different robots.
Provided a fix to copy a user.
Provided a fix to send turnaround QoS for an unknown. user on a known email server.
Provided a fix to identify the QoS on per profile basis.
Provided a fix to identify emails returned from auto reply and auto forward
1.00
Initial Release
June
2011

The ews_response probe should be installed on systems with the following minimum resources:

The ews_response probe requires the following software environment:
Notes:
The 1.11 and earlier versions of the probe require the following software:
The EWSJavaAPI_1.2.jar to install the Exchange Web Server Java API. For more information, see the Install Exchange Web
Services (EWS) Java API section in the v1.1 ews_response AC or IM configuration articles, as applicable.
Installation Consideration
The ews_response probe requires access to a user account on the Microsoft Exchange Server to monitor connection and send test emails.
exchange_monitor (Microsoft Exchange Monitoring) Release Notes

The exchange_monitor probe checks the health of your Exchange Server. Alarm messages can be generated based on the values of the
parameters being checked. Quality of Service (QoS) messages are generated on a set of performance related statistics.
Contents
Revision History
Monitoring Support
Revision History
This section describes the history of the revisions for the exchange_monitor probe.
Version
Description
State
Date
5.20
What's New:
GA
September
2015
GA
June 2015
GA
October
2014
The probe can be migrated to standard static thresholds using the threshold_migrator probe. The Admin Console GUI is
configurable using the standard static threshold block and the Infrastructure Manager GUI is no longer available.
Removed support for Exchange Server 2003.
Removed support for exchange_monitor backend probe.
Updated units for some counters.
Note: For more details on the units and counters, see Upgrades Consideration section.
Fixed Defect:
Various metrics or Server Checkpoints were not being reflected from the probe configuration. Salesforce case 00152627
5.14
Fixed Defects:
Mailbox growth size and Mailbox growth alarms were displaying in NAS and the Alarm View on USM, but were not
visible on the device on USM. Salesforce case 00159622
The Admin Console GUI was displaying numerics, instead of logical symbols for operators. Salesforce case 00154187
The probe was not detecting the exchange server when only Transport roll was installed on the server. Salesforce case
00156643
Incorrect QoS values were generated for Messages Completed Delivery Per Second. Salesforce case 00158587
Note: The QoS values will only be generated on fresh deployment of the probe.
5.13
Fixed Defect:
Added new keys for allowing user to configure the Microsoft Exchange Server path for both 2010 and 2013 versions. Salesfor
ce cases: 00131700 and 00141867
5.12
Fixed Defect:
Added an option for configuring the log file size through the IM probe GUI . Salesforce case 00131514
July 2014
5.11
Added new thresholds for 2010 exchange server as per Microsoft recommendation.
Implemented new counters of Exchange Delivery Health Monitor for exchange server 2013.
September
2013
Implemented new counters of Exchange Transport Health Monitor for exchange server 2013.
Added support for monitoring remote systems over Internet Protocol version 6 (IPv6).
5.01
Fixed a defect where few counters are active on 2k10/2k13 in upgrade scenario even if they were inactive with previous
version.
March
2013
Fixed a defect where Ntevl profiles for 2k10/2k13 are getting displayed in status tab even for 2k7 servers.
"Mailbox Searches Per Sec- Store" and "Directory Access LDAP Searches Per Sec-2013" alarm_required has been
changed to yes.
For "Logical Disk Percentage Free Space" counter default alarm changed to PerformanceValueBelowLimit.
5.0
Added support for Exchange Server 2013.

GUI to display Counters specific to current installed Exchange Version only
January
2013
Changed Perfmon Value not found alarms severity from Critical to user configurable with default as information.
4.01
Removed cluster probe interaction for Exchange 2010.

Fixed few defects related to false alarms of Perfmon value not found.
4.0
Implemented sampling on perfmon counters.

Added DAG monitoring capability
August
2012
August
2012
Added functionality to consider dynamic instances of perfmon counters. This fixes perfmon-not found false alerts.
3.51
Fixed an issue where log level changes are not effective after reloading the probe's configuration changes.
Fixed an issue where activating counter in Profile Tab is not reflected in the Status Tab.
March
2012
Fixed an issue where the probe restarts every minute when qos=no.
Fixed an issue where initially only Status Tab is highlighted and other Tabs are disabled(for around 5min(approx). This
occurs as the counter list grows and probe checks presence of every counter instance.
Fixed an issue where incorrect clear alarms message were sent when no threshold is set.
Fixed an issue where incorrect alarm messages were sent when counter threshold is same as current value.
Fixed an issue where incorrect alarm messages were sent when counter threshold compare type is changed from
configuration.
Activated the counter User Count (Information Store) - 2003,2010.
Fixed an issue where incorrect clear alarms sent for Counters are giving wrong messages.
Fixed an issue where few Counters for 2k7 are activated by default when deployed on Exchange 2k10 Set up.
Fixed an issue where Probe is getting restart on putting login credentials (File Monitoring) and when directory path is left
empty while creating file monitoring profile.
Fixed an issue where Alarms/Qos coming for a deactivated profile (File Monitoring).
Fixed an issue where Messages are coming with a wrong Logic in 2k7 counters and some of the 2k10 counters Fixed
an issue where Alarm were getting cleared for wrong file (File Monitoring).
3.50
Support added for SOC. Added support for monitoring new performance counters on exchange 2010 server for Mailbox,
Client Access, and Common Counters. Added support for monitoring file/folder resources on shared cluster drives. Ported the
probe for native 64 bit environment. Fixed an issue where the probe was not able to register with the controller when
activated,the issue occurs when the reports cfg file grows in MB's.
December
2011
3.42
Fixed an issue found in exclude instance feature implemented in previous version.
September
2011
3.41
Fixed Current Bandwidth filter setting in discovery template.

Fixed issues in monitoring IMAP and POP3 services.
August
2011
Fixed issue in activating service profiles on exchange 2010 server.

Added a fix in the probe's GUI to disallow configurations when running on passive clusters.
Added an alarm when performance counter value fetching fails for any active profile.
Fixed handle leak issue.
3.30
June 2010
Fixed an issue in pt library and probe, related to raising alarms on exchange events.
3.21
Added support for Exchange Server 2010.
December
2009
3.20
Added code for packing origin and server roles when sending data to exchange backend probe.
Added code in GUI to disable 'Gather report information' checkbox and 'Force update of information' button if Mailbox
role is not enabled on the exchange server.
3.17
Fix: Due to changes in the underlaying LDAP libarary, some memory variables were improperly initialized and could
result in no LDAP data gathered. This fix applies to the data collector for the exchange server 2003.
December
2009
June 2009
Upgraded project to VS2008 runtime.

3.16
Added fix in data collector
April 2009
Fixed missing traffic summary, mailbox activity and partner traffic.

There is a limit of 1000 mailboxes that are fetched out. Removed the limit.
If there were more than 1000 public folders, only 1000 public folders were shown. Removed the limit.
If there were more than 1000 messages, only 1000 messages were shown in message tracking logs. Removed the limit.
Added fix for handling special character.
3.15
Added a fix for the error 'Input string was not in a correct format'. This resolves the issue of not retrieving all the
mailboxes available on the exchange server 2007.
January
2009
Added a fix which converts deleted_message_size_extended attribute from bytes to kilobytes for exchange server 2007.
Added a fix for not writing 'size' attribute of the mailbox with size greater than 1 GB for exchange server.
In rare situations, probe could come across distribution group with its exchange legacy key missing. This was
unexpected and could cause crash situation for the data collector on exchange server 2003.
3.13
3.12
Removed dependency to .NET 3.5. The new exchange_report data collector should now work with .NET 2.0.
The dependencies to the files 'Microsoft.Exchange.Data.tlc' and 'Microsoft.Exchange.Management.dll' has been
removed. The previous dependency caused problems on Exchange Servers 2007 with SP1 installed.
August
2008
July 2008
Bugfix: We have discovered a bug in the WMI asynchronous invocation method. This has been fixed.
3.11
Bug: A flag were not being properly reset, which could cause unwanted result. The key in /register/run_check controls if
the probe should enable/disable profiles based on the server it is being run on. This mode is only intended to be run the
first time you deploy the probe to a new exchange server. The flag were not properly set to off. The result would be that
profiles could be turned back on, even if you turned them off through the exchange_monitor GUI.
June 2008
Bug: The Exchange Server 2003 profile "VM Total 16MB Free Blocks" had a typo in it, cmd_type. It should have been
cmp_type. The result was that this profile would get wrong compare. Default threshold would be > 3, when it should
have been < 3..
3.10
New: Implemented data collector for exchange server 2007 servers, to use with existing exchange_monitor_backend
and exchange_monitor_reports.
Updated GUI to reflect the new data collector. GUI will query exchange_monitor probe, which will respond with server
type (2003 or 2007). The code bases for exchange_monitor 2003 and the exchange_monitor 2007 have been merged
together. This probe should run on both 2003 and 2007 servers.
The exchange_monitor probe will have 2 different data collectors shipped with it in the same package. One works with
2003 servers, using WMI, WebDAV and LDAP as previous version prior to 3.xx.
The new data collector is a .NET component which uses Exchange PowerShell cmdlets and LDAP to report similar
information as the old report collector.
Please note when setting up reports:
Exchange Server 2007 reports: Exchange Server 2007 with mailbox server role installed.
Exchange Server 2003 reports: Exchange Server 2003 backend servers.
Message tracking will need to be enabled.
Optimized: probe engine will ignore profiles which are not marked to be used for the server type.
Profiles shipped with the probe are all marked with server type. This means, some profiles are designed for Exchange
Server 2003, some profiles are designed for Exchange Server 2007 specific roles. Profiles can be run on more than 1
server type and more than 1 server role.
If the probe is running on a 2003 server, it will ignore 2007-only profiles even if they are marked active = yes. If it is
running on 2007 servers, it will ignore 2003-only profiles even if they are marked active = yes.
2003 server specific feature:
New feature: If you enable exchange_monitor_reports data collection, it will by default report the size of the EDB
exchange server database files (all versions prior to 3.10). You can now change it to use SLV/STM file, or use the sum
of both file sizes. This can be done from the GUI, on the reports tab.
June 2008
3.02
This Release Note covers both the 2.69 and 3.02 versions of the exchange_monitor probe and that
2.69 supports Exchange Server 2003 only
May 2008

Please make sure that you, dependent on which version of the Exchange Server you want to monitor, download and
install the correct version of the probe.
Modified profile names for 2007.
Please note that when upgrading a probe, the previous version of the probe should first be completely removed.
Modified/added/removed perfmon counters for exchange server 2007.
Added code to validate all QoS definitions and messages that are sent from the probe. A problem was seen at one site,
where they would cause the data_engine queue to stop. This was difficult to reproduce in our test lab.
Data collection has been disabled (for exchange monitor web reports). It is intented to build new reports to support
exchange server 2007 roles concept.
Added code to read the windows registry and try to detect server version installed, and, if it is a exchange server 2007,
which roles are installed.
Depending on the results, activate/disable default monitoring checkpoints that match the server version.
This check is only run once.
Dashboards is not supported in this initial exchange server 2007 version. It is intented to build new dashboards to
support exchange server 2007 roles concept.
Added new checkpoints to try and adapt to exchange server 2007 roles concept.
Bugfix: In some conditions, the use of performance objects could cause the exchange_monitor probe to crash. This has
been fixed..
2.69
Please note that this Release Note covers both the 2.69 and 3.02 versions of the exchange_monitor probe:
Increased capacity of counters used to calculate traffic summary reports for a day. The previous counter were too small
at some sites, which could lead to negative values. See exchange_monitor_backend 1.11 release note for more details.
We have added a flag which controls the WMI invocation method. In all previous versions, synchronous method were
used. It is still default, but the value in /setup/wmi_method can be set to "async", in order to change method invocation
to asynchronous. We believe this will fix a rare WMI timeout problem. This key is only visible in the raw configurator. If
you click the Test button from the GUI, the value stored in the cfg will be used, as it is impossible to tune it from the
standard GUI.
Bugfix: The routine that was used to determine if it was time to run a complete report check had a flaw in it. It could
occur if a mailbox report generation had been started just before midnight local time to the probe, and the report were
finished collecting data just after midnight, it could cause the timestamps on the other fields (mailbox activity, traffic
summary, public folders etc) to be updated incorrectly. This will cause the exchange_monitor probe NOT collect any
new data for another 24 hours for these reports. If you are unlucky, this could last more than 24 hours, and then
suddenly the probe would recover by itself. This fault has been attempted fixed in the current version.
The exchange_monitor probe will now only read new data from a report collection, instead of reading the entire file
content again (e.g. traffic summary is only read once every 24 hours, but previously this information was being re-read
every 10 minutes by the exchange_monitor probe). This will result in less cpu cycles used.
Added an extra parameter to the callback "get_report", called "user_friendly_date", accepts string "yes", which will make
the datetimes returned by this callback to be formatted in user friendly format, like in the exchange_monitor_backend
GUI. This is only to help troubleshoot.
Bugfix: Attempting to fix memory allocation/deallocation mismatch problem, which could case program fault on some
systems.
Optimized: Attempting to filter out other exchange servers during the exchange_monitor GUI WMI Test button query, to
enhance execution time of this test
April 2008
2.67
Bugfix: When doing a base search for a delegate, who had a distinguished name which contained a comma (" , ") in the
name, this comma was not encoded into the request properly. This resulted in an invalid syntax LDAP error and also
caused the probe collector to crash.
January
2008
Bugfix: Report collector now utilize LDAP Paged searching, when querying active directory. This has been done to
support the default AD LDAP policy of max 1.000 records returned from a LDAP query. We page 100 records per query.
Your AD server(s) can't have any less sizelimit than 100 records.
Bugfix: Report collector now utilize ranged attribute retrieval, to overcome the default AD LDAP policy of 1.000 attribute
values (Windows 2000 domain controller) and 1.500 (Windows 2003 domain controller).
Bugfix: Report collector does not natively support Unicode. The SQL database supports Unicode. AD uses Unicode. Our
LDAP library returns UTF-8 encoding. There was a problem converting from UTF-8 to internal ANSI encoding.
Bugfix: The exchange monitor probe can now query multiple active directory domains for groups and user objects, that
belong to a given exchange server. This information needs to be entered through the GUI. One server must be chosen
as what we call "default", which means, that is the server we will be using when querying the
configurationNamingContext AD partition. This partition should be replicated equally to all servers. But we allow you to
choose the "default" one to query for configurationNamingContext.
Bugfix: Fixed a bug where users who were orphaned mailboxes, would appear on the "password never set" report.
Feature: In version 2.65 we introduced the optimization of re-using LDAP connections between searches during the
same data collection. We added an checkbox to enable/disable this feature. Disabling it means a new connection will be
used for each LDAP Query. We added this checkbox, because we are unsure of the LDAP timeout policies that exists
out there (how long one can IDLE before the connection is shut down by the server).
Optimized: The exchange monitor probe and exchange monitor backend probe can now communicate smarter with
each other, which may reduce the amount of network bandwidth used between the two.
Rewrote the code logic that parses group membership and delegate information. Because of the current limitations of
the database model we chose, there are some limits/issues. See below.
The data collector will still lookup delegates. Delegating to public folders or groups will not work. Delegating to exchange
users that reside (have mailboxes) on other exchange servers in your organization, should appear on the delegate
report, but you will not find any actual mailbox data (such as size, deleted items etc). To get this additional information,
you will need to setup an exchange monitor probe for those servers
2.65
If WMI impersonation error occurred, the test could still take up to "test_timeout" seconds before completing.
Optimized: Upgraded LDAP library to CLDAP from Novell for more security.
Optimized: Re-using LDAP connection between queries.
You can now change ldap ports, specify ldap search timeout and turn on or off ssl encryption for ldap connections.
When querying base DN of your domain for max password age and domain name, search scope has been changed to
LDAP_SCOPE_BASE.
Fix: Field introduced in 2.62 to optionally specify Conf.DN were not cleared if you were switching between 2 virtual
servers in a cluster on the same server.
Fix: Corrected loglevel on some logging information.
When reporting is turned on, the probe will try to query Active Directory for the attribute
"configurationNamingContext", in order to detect correct configuration tree DN.
GUI: Added a field to manually override the configuration tree DN, in case our query fails.
When the GUI checkbox named 'Filter stores and databases for other servers' was checked, the probe would supply an
incorrect filter when the exchange monitor probe was running outside a cluster. This could cause the
exchange_monitor_reports engine to filter data incorrectly.
The GUI would try to perform duplicate checks to see if the probe was active, in order to decide if the callback
"isCluster" should be run. One of these checks performed a check which would cause the GUI to crash if you were
running Nimbus server 3.21. The duplicate check has been removed
October
2007
2.60
Enhancement: We have implemented/enhanced the exchange monitor probe for better cluster support. But you will also
require cluster probe >= 1.60 if you wish to monitor exchange server running in a Microsoft Cluster. These two probes
will now communicate with each other, allowing for exchange monitor probe to "know" when it is in a cluster, and thus,
use the virtual exchange servers IP and name when generating both alarms and QoS messages, and then you will get
continued QoS data series when an virtual exchange server changes between nodes, and you will be able to view the
same dashboard, no matter where the virtual exchange server may be running.
April 2007
Probe should now be able to monitor exchange in any of the common cluster setups that we know of. For more
information, see cluster probe.
Fix: Report collector should now handle mailbox users that have delegates on other exchange servers within the same
domain (not only users on the same server).
Fix: We added default message templates that you can edit via the GUI for when message tracking is disabled, or when
we were unable to determine if message tracking is enabled or disabled. Message tracking logs are used to compute
the top 20 web reports.
Feature: Implemented code to support WebDAV requests over HTTPS. A checkbox is available in GUI to turn on/off
SSL, and it is also possible to change the default SSL port if your server requires another port for HTTPS.
Improved code logic when communicating with Active Directory over LDAP. We are now finding out where public folder
stores are located on IIS, and whether public folder instances (reported via WMI) are replicated locally or not. This
should give more accurate reports on public folders. Report collector now properly filters information and should no
longer report other exchange servers users and/or stores as if they belong to the server we are currently generating a
report for. Even when 2 virtual exchange servers are running on the same node in a cluster, this information is now
correct.
Fix: We have revised the QoS definitions for this probe. Some of the QoS data series generated from this probe use the
same counters as for example the CDM probe, but both probes reported different QoS definition names. We have
revised the QoS definitions in this probe, and they should now be consistent with those QoS definitions coming from
other probes
2.53
Optimized: GUI: Each of the 3 test buttons (for testing HTTP(WebDav), LDAP and WMI) are now being executed in
separate threads on the probe, which means the probe will not hang and still respond to controller etc, and it will also
still perform its other normal duties (if any), like checking services, processes etc.
December
2006
The GUI will make async. calls to the probe, meaning, it will not freeze up when its waiting for TEST output, you still
have to wait for it to complete, but can in case you don't want to wait, you can close the GUI. The GUI timeout value has
been increased from 60 seconds to default 300 seconds (5 minutes). If you for any reason need a higher timeout value,
it can be edited in the raw configure, the key "test_timeout" in /setup section will be respected by the GUI when asking
the probe to run a TEST.
Fix: The GUI can't turn on "gather report information" unless it has successfully run the 3 test buttons without failures.
You can however configure and use the test buttons even though "gather report information" is not turned on. This is
done to prevent the probe from starting report information before all the credentials are set up.
Fix: After running a full report generation, the exchange_monitor probe will not run the generation again until its next
scheduled run, even if one or more of the reports have missing data. You can however force the report to run again by
either clicking the "Force update of report information" in the GUI, or restarting the probe, or using the probe utility and
calling the command "reset_report". This has been done to prevent the probe report generator to eat system resources
if it for any reason can't get all the data it needs to make a full report.
Fix: More output has been placed in the exchange_monitor report engine program.
Fix: A bug that caused the database whitespace report calculations to be incorrect.
Fix: The checkbox to enable/disable monitoring of mailbox growth is now properly read back from the config file. There
was a bug that caused this checkbox to be turned on each time you loaded the GUI.
Fix: The input text-fields to type in LDAP, WMI and HTTP(WebDav) information has been slightly increased.
Fix: The test button for testing HTTP (WebDav) incorrectly had a header saying it was a WMI test.
2.52
Added clear alarms for the internal alarms occurring when exchange_monitor is not able to contact one of its supporting
probes.
September
2006
Configurator fix for handling cluster setup.

Corrected error handling on finding performance object instances.
Ignored initial error on missing value for aggregate counters
2.50
Added cluster support. This requires the cluster probe version >= 1.50. (See the cluster probe for more details).
July 2006
2.01
Modified test routines.
June 2006
2.00
Added gathering of report data.
June 2006
Fixed comparison type problem for expanded profile instances.

1.02
Added source for alarm filter discovery.
Monitoring Support
February
2006
From version 5.1 and later, the probe supports monitoring of:
Exchange Server 2013 SP1 on Windows Server 2012 and Windows Server 2012 R2.
Exchange Server 2013 SP3 on Windows Server 2012.
The probe also supports the following versions of Microsoft Exchange:
MS-Exchange Server 2003
MS-Exchange Server 2007 (Mailbox, ClientAccess, Hub- and Edge Transport roles)
MS-Exchange Server 2010 (Mailbox, ClientAccess, Hub- and Edge Transport roles)
MS-Exchange Server 2013 (Mailbox, ClientAccess roles).

The probe version 5.20 or later can be migrated to standard static thresholds using the threshold_migrator probe version 2.11 or later with PPM
version 2.23 or later. You can refer the threshold_migrator probe document for information about how to migrate a probe.
Notes:
The Threshold Migration takes 3:30 mins for default probe configuration.
The IM GUI of the probe is not available if the probe is migrated using threshold_ migrator. Opening the IM GUI then displays a
message that the probe can only be configured using the Admin Console and redirects you to the Release Notes of the probe.

Automated rollback will not be available.
Some probe specific alarm configurations in the probe monitors are replaced by Static alarms and Time over Threshold configurations.
The static message variables are migrated and only the standard variables such as value and threshold will be used.
The variable syntax changes from $<variableName> to ${<variableName>}.
The alarms are sent by the baseline_engine probe.
DAG Monitors with State or Boolean units will not be migrated. The probe will continue to send these alarms.
The dynamic variable ${value} changes to ${last_value} in alarm messages for Perfmon probe.
After migration, the QoS sent by the probe will contain the average values and not the current value, if sampling is selected.
Operator Reversal after Migration
Any relational operators in Number of Files and Space used by files in the probe configuration will be reversed. While alarms were initially
generated for files not meeting the relational criteria, now the alarms are generated for files meeting the reversed criteria. Since the operator is
reversed, the $operation variable is replaced by the actual operator so that the meaning of the message is not affected.
The operators before and after migration are listed as follows:
= (equal to) becomes != (not equal to)
!= (not equal to) becomes = (equal to)
< (less than) becomes >= (greater than equal to)
<= (less than equal to) becomes > (greater than)
> (greater than) becomes <= (less than equal to)
>= (greater than equal to) becomes < (less than)

The exchange_monitor probe should be installed on systems with the following minimum resources:

The exchange_monitor probe requires the following software environment:
For probe version 5.20 or later, install the following probes to view the metrics on the USM portal:
ci_defn_pack version 1.12 and later
mps_language_pack version 8.33 and later.
Note: You must restart the nis_server and service_host probe after you deploy these probes.
The exchange_monitor probe uses the following probes to provide data to check Exchange Server health. The following probes and component
requirements must installed on the robot where the exchange_monitor probe is installed.
perfmon probe 1.18 or later
The perfmon probe acts as a data repository. The probe fetches and holds performance object values from one or more computers,
requested by other probes on your system.
ntservices probe 2.32 or later
The ntservices probe monitors the list of installed services, detecting which of them are running.
ntevl probe 2.15 or later
The ntevl probe monitors the event logs for new messages.
processes probe 2.53 or later
The processes probe monitors the operating system for certain processes, defined by a set of profiles in the probe configuration file.
Note: These probes are automatically installed on the robot from the archive, else the exchange_monitor probe displays an error to
download and install the dependent probes.
From version 5.20, the units of the following counters have been updated.
Failures Due to Maximum Local Loop Count
Message Bytes Received per second
Message Bytes Sent per second
Inbound: LocalDeliveryCallsPerSecond
Inbound: MessageDeliveryAttemptsPerSecond
Inbound: Recipients Delivered Per Second
Hub Selection: Resolver Failures
Hub Selection Organization Mailbox Failures

Hub Selection Routing Failures
Messages Scanned per Second
Inbound: LocalDeliveryCallsPerSecond
Inbound: MessageDeliveryAttemptsPerSecond
Inbound: Recipients Delivered Per Second
DNS Errors
Directory Access: LDAP Searches/sec
Number of active Database copies
Number of passive Database copies
Number of mounted Database copies
Number of non mounted Database copies
MTPSend DNS Errors
CopyQueueLength-DAG
ReplayQueueLength-DAG
DatabaseRedundancyCount
Ensure that you review the following installation considerations:
Install the probe on each Exchange Server to be monitored.
The exchange_monitor probe generates QoS table names dynamically and the names may have more than 64 characters. This
character length can create issues when inserting data into SLM database.
When SLM database is created by a Nimsoft Server earlier than 3.35, the first column, name, in S_QOS_DEFINITION table of the SLM
database has a size of 64 bytes. The size must be 255 bytes. The QoS definitions with length greater then 64 characters will be
discarded by the latest data_engine probe or may cause earlier versions of data_engine to repetitively fail. This issue can be resolved by
changing the column size to 255 characters. You can change the size using the following query in a database tool.
Design table S_QOS_DEFINITION table and change size of the name co

lumn to 'varchar(255)'.
You can also run a query on the database that is available with the CA UIM Technical Support.
Report information is gathered as follows:
2003: Using WMI, LDAP, and HTTP requests.
2007, 2010 and 2013 mailbox: Using LDAP, and Exchange PowerShell cmdlets.
The following identification methods are required for Mailbox Growth, Access Protocols and exchange_backend probe.
Exchange cmd-let identification
HTTP identification
LDAP identification
Note: LDAP is also required to login to the Active Directory server to enable the Collect Reports section.
WMI identification
The data collector for exchange mailbox server role requires Microsoft .NET Framework v2.0 and Microsoft Powershell v1.0.
Important! CA has ended the support for exchange_backend probe.
The probe accesses the Microsoft Exchange Server installation path to collect values of certain monitoring parameters. Configure the Microsoft
Exchange Server installation path for the probe to successfully collect values of the parameters being monitored from the server. If the server path
is not configured correctly, the probe will not be able to send any QoS data for DAG monitoring.
Follow these steps:
1. Open the Raw Configure GUI of the probe and navigate to the dag section.
2. Define the Microsoft Exchange Server installation directory path:
For 2010 - exchange_2010_path key value.
Important! The installation path must end with a forward slash (/).
3. Click OK to save the configuration.

4. Restart the probe to apply the configuration changes.
The Microsoft Exchange Server installation path is configured.
To enable DAG monitoring, see the exchange_monitor Configuration article of your probe version.
Important! The cluster probe is not required for DAG monitoring.

The known issues of the probe are:
This multi-threaded probe fails to collect data from Exchange Server on Windows Server 2008 R2 (which uses the Windows Vista kernel)
due to security issues.
Data collector process fails to execute due to errors in impersonation.
Exchange users can delegate rights to other objects such as public folders, groups, and users.
Current versions of report collector, database model, and web pages do not support any other delegates than other mailbox users. If you
delegate control to users that have mailboxes on other exchange servers, the delegates must have mailboxes on same exchange server
as users delegating rights.
Group membership - The probe does not understand the difference between local, domain, and universal groups (distribution lists). It also
takes each group to be a "member" of an exchange server, although the group belongs to the AD domain. Such groups can have
members across AD server. The data collector only retrieves users that have mailboxes on same exchange server that the probe is
running on. If you monitor 3 servers, and have a universal group with members from all 3 servers, the group is displayed 3 times on
reports page. Each "instance" shows you members for that exchange server.
Dynamic groups and Integration with Sharepoint portal services is not supported.
The new report collector, written in .NET, utilizes Powershell commands. On default installations, this generates a lot "informational"
messages in the PowerShell event log. This may fill up the Microsoft PowerShell event log.
Old static dashboards do not work with Exchange Server 2007 and 2010. The report URL in discovery template should be modified after
discovery and addition to a dashboard.
The probe does not maintain the state of previously selected profiles and reverts back the profile active states depending upon underlying
exchange server version.
All custom profiles are deleted automatically when the probe is upgraded to a newer version.
fetchmsg (Fetch System Messages on iSeries) Release Notes

The Fetch System Messages on iSeries (fetchmsg) probe monitors message queues on IBM iSeries systems. The probe sets up a message
space and retrieves messages from specified queues to monitor them. The probe can generate alarms when the specified threshold conditions
are breached. For example, you can generate alarm messages when specific messages appear. You can also check messages which require an
answer for missing responses.
Note: The probe does not generate any QoS messages.
Contents
Revision History
Revision History
Version
Description
State
Date
1.51
What's New:
GA
September
2015
GA
May 2013
GA
January
2012

Fixed Defects:
The probe sends new alarms for messages which had already generated alarms when the hub probe restarts. Salesforc
e case 00159894
The probe does not open the Infrastructure Manager GUI when the <excludes> section is not present at the end of the
configuration file. Salesforce case 00158667
1.50
Time frame functionality : To avoid multiple alarms for duplicate messages

Exclude Functionality : To avoid alarms for unwanted messages
1.43
Fix for Clear Alarm incorporated
1.42
NIS cache fix incorporated
January
2012
1.41
January
2011
1.30
Added Configurable suppression key.

Added New alarm metric functionality.
December
2010
Added support for Internationalization.

Implemented clearing of old suppression keys from last file on termination to avoid resending unneccessary clear on
these on next probe startup.
1.26
Added fix to avoid duplicate clear alarms.
March
2010
1.25
Changed message read algorithm to allow repeated reads. This is needed when keeping track of unanswered
messages in the situation when there are more newer messages than the configured 'messages to read' parameter.
November
2009
Changed configuration tool to allow configuring log size.

Fixed behaviour where alarms for Inquiry type messages where cleared when they were acknowledged even when 'Is
unanswered' was not being watched.
Fixed problems in regular expression engine with advanced expressions.
1.24
1.23
Internal update - modified to use version 4 nim library.
Added option to include / exclude impromptu messages (Messages without ID).
August
2009
July 2009
Improved code to recognize message answers correctly.

1.21
Stores away suppression keys of alarm sent to be able to clear those after a full restart of the computer.
Added support for additional message queues.
November
2007
New base library used.

Uses different set of API calls to fetch messages.
lose list also on error situation.
Modified check logic.
Modified max severity from 100 to 99.
Modified code to be able to limit the number of messages the probe will fetch at any point in time.
Improved handling of messages with missing parameters.
1.09
Added logging on log level 3 on last message read logic.

Inverted list in All messages tab. Now the most recent messages are at the top with the default sorting.
January
2006
Added 'messages_to_read' internal parameter to be able to handle situations where the number of messages in
QSYSOPR is to large to be viewed normally.
Saves the key of the messages in the .last file to enable the probe to only read the newest messages.
Support added for the '@' character in comparison strings. Note that this requires robot version 2.41 also.
1.07
Enabled profile ordering and message answering fields when probe version is unknown.
Added option to limit messages handled by severity.
Added hidden options to set maximum length for message text (max_message_length) and maximum length of help text
(max_help_length).


file_adapter Release Notes
April 2005
Considerations
Known Issues
Revision History
The file_adapter probe imports QoS data from the files that are defined in the profiles (for example, files that are generated by third-party
applications). When a matching file is found, it is parsed and one QoS message is produced per row.
The QoS message is formatted according to the profile defined for that file. Once a file has been processed, it is moved to a specified directory
and the probe is ready for a new data file.
Considerations
This section contains the considerations for the file_adapter probe.
Known Issues
The file browse function in the configuration tool does not work for UNC paths when user authentication is required.
Input values are accepted when starting with a digit event if other characters are present in the field. The value is determined from the digits up to
the other character.
Revision History
Date
Description
State
Version
Dec 2010
GA
1.40
Jun 2010

Fixed error that is related to output file format after successful import.
1.30
Oct 2008
Case insensitive pattern/regexp file comparisons on Windows
1.21
Sep 2008
Added support for comment lines in the import file.

Added a profile description.
Wildcards and pattern matching on directories and file names are included.
Moved QoS definitions to main window.
1.20
Jul 2007
Improved functionality and GUI.

Note: This version has a memory leak; it is recommended that you restart the probe if this is a problem!
1.10
Oct 2005
Rereading configuration on restart implemented. Improved configuration GUI.
1.02
fsmounts (File Systems Mount Monitoring) Release Notes

The File Systems Mounts Monitoring Probe monitors which file systems are mounted, and raise alarms when there are mismatches between what
is mounted and what is configured on the system.
Revision History
Revision History
Version
Description
State
Date
1.24
Fixed Defect:
GA
March 2015
Probe was generating alarms for zfs file systems in Solaris for the incorrect storage location etc/vfstab. Salesforce
case 00142827
1.23
Fixed the Help link on the probe GUI.
GA
November
2014
1.22
Fixed typo in ignored mount points config (/var/lib/nfs/rpc_pipes).
GA
January
2013
1.21
Added support for Linux 64bit
GA
August 2012
1.20

GA
March 2011
1.11
Made changes to libraries with respect to configuration locking
GA
June 2010
1.10
GA
March 2010
1.02
Check if (v)fstab file has been modified and rescan if it has been
GA
March 2010
1.01
Fixed small memory leak.

GA
June 2008

The fsmounts probe requires the following software environment:
CA Unified Infrastructure Management
Server 7.1 to 7.6 or CA Unified Infrastructure Management 8.0 or later
google_apps (Google Apps Monitoring) Release Notes
Google Apps is a set of applications that Google provides and maintains, such as, Google Drive and Google Mail. You can own a Google Apps
domain where you can create many user accounts. A Google Apps domain comprises of a set of end-user accounts, features, applications
available to the end-users, per-user pricing, and resource quotas. Google Apps currently offers three types of domains or editions- free,
educational, and premier.
For more information, refer to http://www.google.com/apps/intl/en/business/index.html
The google_apps probe gathers status information about the general Google applications from http://www.google.com/appsstatus and raises
alarms when any application service is unavailable. The status information is represented through the following codes:
0: App Normal
1: App Information Available
2: App Service Disruption
3: App Service Outage
4: App Status Unknown
The google_apps probe also monitors the Google Apps domain reports. The probe generates QoS data that describes all the metrics like the daily
performance of the domain-specific services and the operations that are performed on each user account.
Important! The google_apps probe is now available through Admin Console GUI only and not through the Infrastructure Manager GUI.
Upgrade from previous version to version 2.00 is not supported.
The google_apps probe collects data on the Google-published application status, available from http://www.google.com/appsstatus.
The probe is also capable of measuring and alarming on aspects of a specific domain. Google provides a set of domain reports from which the
probe gathers metrics. The probe is also capable of performing various end-user operations, like creating a document, and measuring the latency
of the operations.
Contents
Revision History
Revision History
This section describes the history of the revisions for the google_apps probe.
Version
Description
State
Date
2.00
What's New:
GA
January 2015

Note: The probe is compatible with CA Unified Infrastructure Management 8.0 and later only.
1.01
A license is now required for this probe.
GA
July 2010
1.00
Initial release.
Beta
March 2010

The probe requires:
CA Unified Infrastructure Management 8.0 or later.
Valid credentials of the Google Apps domain account.
This section contains the considerations for the google_apps probe.
The google_apps probe version 2.00 and later is available through Admin Console GUI only and not through the Infrastructure Manager
(IM) GUI.
Upgrade from previous versions to version 2.00 is not supported.
You must deploy Probe Provisioning Manager (PPM) probe version 2.38, or later for configuring the Google_Apps probe version 2.0x.
For viewing the new metrics that are introduced in the google_apps probe version 2.0, on the USM portal, you can perform any one of the
following actions:
Upgrade CA Unified Infrastructure Management 7.6 (or earlier) to CA Unified Infrastructure Management 8.0
Install the ci_defn_pack version 1.00 probe. you are required to restart the nis_server when you deploy the ci_defn_pack.
hadoop_monitor (Hadoop Monitoring) Release Notes
The Hadoop Monitoring probe handles all the common monitoring and data collection tasks (collecting QoS measurements and topology
information) on a Hadoop cluster through a namenode, and gathers reports about all nodes in the cluster. The probe collects and stores data and
information from the monitored system at customizable intervals. The probe generates alarms when the specified thresholds are breached. You
can view the metrics, alarms, and reports in CA Unified Infrastructure Management.
Contents

Revision History
Version
Description
State
Date
1.0
Initial version.
GA
December 2014

Machines to which the Hadoop Monitoring probe are deployed must be capable of functioning as a Hadoop node.

The Hadoop Monitoring probe requires the following software environment:
Note
We recommend that the CA Unified Infrastructure Management Server and Unified Management Portal (UMP) are the same version.

2. To ensure a successful installation of the probe package (drag and drop), it is required that a java.exe (version not critical) exist in the
PATH.
4. Double-click the probe for initial configuration. At first-time probe configuration, initiated by double-clicking the probe in Nimsoft
Infrastructure Manager, the installation wizard automatically will be launched. The wizard will prompt you for the path to the correct
version of IBM JVM and other environmental files required by the probe (see probe documentation).
None.

The Hadoop Monitoring (hadoop_monitor) is available through the Admin Console GUI only and not through the Infrastructure Manager
(IM) GUI.
To view the new metrics introduced on the Hadoop Monitor probe on the USM portal, you must install the ci_defn_pack version 1.01
probe. You are required to restart the nis_server when you deploy the ci_defn_pack.
Important!
You can install the ci_defn_pack probe from https://support.nimsoft.com
ha (High Availability) Release Notes

The ha probe allows you to manage queues, probes and the NAS AutoOperator in a High Availability setup. The probe runs on the standby Hub.
If it loses contact with the primary Hub it initiates a failover after a defined interval. When the primary Hub comes back online the probe will
reverse the failover (failback)
Contents
Revision History
Considerations
Revision History
Version
1.45
Description
Added support for a tunnel between the primary and secondary hub (the ha probe resides on the secondary hub).
State
Date
GA
June 2014
GA
March
2014
Removed support for 32 bit Operating Systems.

The HA probe now defaults to 'queue_activate_method=queue_active' to enable and disable queues using hub
callbacks.
1.44
Added support for a wait interval before the probe begins failback after re-establishing communication with the primary hub.
Added Admin Console GUI.
1.41
Fixed startup sequence so it checks if a state change is required in the initial run.
GA
March
2011
1.40
GA
December
2010
1.30
GA
September
2010
1.25
Probe now caches IP and port of remote address to avoid repeated lookups on the "static" data.
GA
September
2009
GA
June 2008
Cache is refreshed every hour.

Fixes problem, where the hub is busy and times out on the name lookup; in the worst case causing an incorrect failover.
Configuration tool maps hub address to the spooler address automatically, as this provides better alive status.
1.23
Fixed bug where subsystem id was ignored for alarm messages.

Fixed heartbeat message timing issue. Changed default subsystem id to 1.2.3.8.
1.20
Changed how queues are activated/deactivated to avoid potential problems with Hub restarting in the middle of the operation.
GA
April 2008
Added option to take a probe down when failing over with the new section "probes_down".
Fixed minor memory leak when restarting the probe.
Added configuration tool.
Changed name of section from "queues" to "queue_up".
Added section "queue_down" for queues which need to be deactivated when failover occurs. This is useful where the
secondary hub has a post queue for e.g. QoS data to the primary hub. To avoid duplicate entries this has to be deactivated. It
is reactivated after the primary hub comes back online.
Port to Linux, Solaris 8 (sparc) and AIX 5. No functional changes.
Changed control mechanism to active heartbeat checks. Queue is no longer required.
Initial Release.
This probe has no additional hardware requirements.
When installing of a 64-bit Linux platform, these 32-bit libraries are required:
Debian/Ubuntu -- ia32-libs
Redhat/CentOS -- glibc-2.12
Considerations
The probe must be installed on the standby Hub.
The probe is not activated after distribution. It must be configured, then activated manually.
If your NAS does not have the subsystem ID 1.2.3.8 defined, add it to the subsystems list in the nas or change the messages configurations to
use the string "HA" in place of the subsystem ID.
When updating to version 1.20 the old "queues" section is renamed to "queues_up".
To take advantage of the spooler address change, the configuration must be saved from the configuration tool after probe update.

Ensure that the ha probe is installed on the secondary hub, not the primary hub.
In the setup section these keys are the most relevant:
remote_hub - This is the primary Hub's full Nimsoft address in the form /Domain/Hub/Robot/hub
hb_seconds - This is the number of seconds between heartbeat messages. Minimum value is 5 seconds to avoid "denial of service" on
the primary Hub.
wait_seconds - This is the number of seconds the probe should wait before initiating a failover. The failover is ended immediately when
the primary Hub comes back online.
reset_nas_ao - This allows you to specify whether or not to (de)activate the nas AutoOperator on the failover system. Specify 'yes' or 'no'.
The default is 'yes'.
In the probes_up section, you can specify a list of probes that are to be activated on the local Hub when a failover occurs. When the remote_hub
comes back online these probes are deactivated again. The keys are of the form probe_0, probe_1 and so on while the values are the names of
probes to be started/stopped.
In the queues_up section, you should specify the queues which are to be started during a failover. The same queue definitions must be set on
both the primary and secondary Hubs. The keys are of the form queue_0, queue_1 and so on while the values are the names of queues to be
started/stopped.
In the queues_down section, you should specify the queues which are to be stopped during a failover. The keys are of the form queue_0,
queue_1 and so on while the values are the names of queues to be started/stopped.
In the Messages section, you can change the alarm messages and their severities that are sent when a problem occurs. The severities are
numeric values from 0 (clear) through 5 (critical).
Take the following steps to ensure that the fail over process occurs correctly.
hdb Release Notes

The hdb probe is a core component of a CA UIM robot, which provides a lightweight database-like service. Hdb allows monitoring probes such
as logmon to store useful data on disk. Hdb is deployed with the controller and spooler probes during robot installation or update. The hdb versi
on is always in sync with the controller and spooler probes.
See the controller Release Notes for release information for the robot.
Revision History
Version
Date
State
7.80
June 2015
GA
7.70
March 2015
GA
7.63
December 2014
GA
7.62
November 2014
GA
7.60
June 2014
GA
7.05
March 2014
GA
7.10
December 2013
GA
health_index Release Notes

The health_index probe gathers alarms from the UIM message bus and calculates a health score for all devices and components with the Health
Index feature enabled.
Revision History
Requirements
Health Score Requirement
Known Issues
Unified Service Manager Graph Could Show Time Intervals Missing Health Scores (Fixed in health_index v1.11)
No Health Index Scores are Calculated on Systems Configured as a Secondary Hubs

Unable to Connect to nisApi_wasp to Receive Metrics
Service Runtime Exception
Revision History
This section describes the history of the revisions for the health_index probe.
Version
Description
State
Date
1.11
Fixed defects:
Policy data is properly transmitted to the health_index probe over a secure http connection when UMP is
configured to use https.
GA
August
2015
Controlled
Release
June 2015
GA
March
2015
Minor fixes to the log file and the configuration request timeout.
1.10
1.0
Initial release.
Requirements
The health_index probe should be installed on systems with the following minimum resources:
health_index v1.11
Robot version 5.7
Admin Console v8.31
Policy Engine (policy_engine) v8.2
Verify CA Unified Management Portal v8.31 is installed and running on a hub or robot
health_index v1.0
Admin Console v8.2
Policy Engine (policy_engine) v8.2
Verify CA Unified Management Portal v8.2 is installed and running on a hub or robot
Health Score Requirement

To generate a health score for a device, you must access the Policy Editor in CA Unified Management Portal (UMP) and create a policy. The
health index feature is enabled for all policies by default. For each policy you create a policy filter (on the Filters tab) to include all the devices that
you want to generate a health score as targets of the policy. See the Enable Health Index article for more information.
The health_index probe is installed on the primary hub by CA UIM Server installer v8.2 or later.
Known Issues
Unified Service Manager Graph Could Show Time Intervals Missing Health Scores (Fixed in health_index v1.11)
It's possible that from time to time, in environments with a large number of robots (over 40), health_index may reach an internal timeout condition
when retrieving configuration information from the UIM database. If this happens, health scores will not be calculated for that calculation interval. If
gaps are noticed in the health_index data, one potential work around is to increase the number of times health_index executes a calculation cycle.
To increase the frequency of calculation cycles, you could set the Policy Refresh Interval to 15 minutes and the Calculation Interval to 30 minutes.
No Health Index Scores are Calculated on Systems Configured as a Secondary Hubs

When the nas probe is running on a secondary hub, replicated alarms coming from nas are database files that are stored directly in the UIM
database (circumventing the UIM message bus). Since these replicated alarms are not put on the UIM message bus they are not collected by
health index. Alarms generated by devices targeted by a policy with health index enabled must be put on the UIM message bus to allow the
health_index probe to calculate a health score. Otherwise, when no alarms are collected on the UIM message bus, no health score is given (No
Metrics Found) or the health score for devices appear as 100.
The workaround solution is to edit the nas probe to turn off alarm replication and forwarding by deleting the nas replication/forwarding
configuration. Also, in the Hub configuration, ensure that queues are properly set up to post alarms from the secondary hub to the main hub,
QOS_MESSAGE, QOS_DEFINITION, and QOS_BASELINE.
Unable to Connect to nisApi_wasp to Receive Metrics

When UIM is installed but UMP has not been installed, UMP has not started fully, or if there is a problem with the UMP installation, the following
error is logged to the health_index log file:
ERROR nisapi.MetricConfigLoader - Unable to connect to nisapi to receive metrics
Make sure that UMP is installed and has fully started. You can also restart the wasp probe.
Service Runtime Exception

You might see the following error in the health_index log file when the policy_engine probe is not functioning properly:
ERROR exceptions.PBMServiceRuntimeException - Received status (4) on response (for sendRcv) for <probe> = 'nametoip'
Check the policy_engine log file for problems or issues. Then restart the policy_engine probe and verify that you can configure the policy_engine
probe from Admin Console.
history (iSeries QHST Data Monitoring) Release Notes

The history (iSeries QHST Data Monitoring) probe monitors history messages from the QHST logs. The logs contain messages related to system
failure, warning messages, security issues, and so on. The logs are present on the same iSeries servers that host the probe. The probe only read
s the QHST log files, and automatically detects new logs and new messages as they are written to the log files. The log contains the history of
the system activities that are as follows:
Status of the system
Jobs running on the system,

System operated messages.
Contents
Revision History
Known Issues
Revision History
This section describes the history of the revisions for the history probe.
Version
Description
State
Date
1.06
What's New:
GA
September
2015
1.05
Fixed a defect in which the profile did not save the Description and Use Message option on saving the probe
configuration.
GA
May 2014
1.04
Niscache usage correction.
GA
January 2012
1.02
Fixed the issue in configuration tool where profile parameters were not saved correctly.
GA
December 2010
GA
December 2010
Beta
November 2010
1.01
The Job field split into job_name, job_user and job_number.

Job matching is done against the job_name value.
Changed the Initial scan interval to 10 minutes.
1.00


Known Issues
The known issues for the probe are:
Messages which remain in the queue for longer duration are not detected by the probe until after the next flush, hence the probe triggers
alarms long after the event was originally sent to QHST.
hitachi (Hitachi Storage Monitoring) Release Notes

The Hitachi Storage Monitoring (hitachi) probe is a remote monitoring probe that is insatlled on the robot. The probe monitors the Hitachi USP-V,
USP-VM, Adaptable Modular Storage (AMS), Virtual Storage Platform (VSP), and Hitachi Unified Storage (HUS) Series disk storage
systems. The probe uses an SMI-S interface to collect comprehensive metrics about storage arrays, pools, LUNs, disks, and more. You can
define alarms which are sent when specified thresholds are breached.
You can define alarms to be issued and propagated when specified thresholds are breached.
Revision History
Enable Performance Metrics
Upgrades Considerations
Large Config File May Cause Startup Problems
Revision History
This section describes the history of the revisions for the hitachi probe.
Version
Description
State
Date
2.05
Fixed Defects:
GA
October
2015
GA
May 2015
The probe generated incorrect values for the IO counters. Salesforce Case: 00141985
The Arrays did not expand if hub/domain or robot name contains "(" OR ")". Salesforce Case: 00155090
Updated the Add a Monitor section in the IM Configuration article to state that you can configure the templates using
drag-and-drop from the right pane only. Salesforce Case: 0070000610
2.04
What's New:
Added support for Hitachi Virtual Storage Platform (VSP) systems.
2.03
Added QoS for Used Managed Space and Percent Used Capacity.
October
2014
2.01
What's New:
Added functionality to configure the probe using the Admin Console and SNAP UI.
Limitations:
Removed the option of managing QoS list by the user.
User is not able to drag-and-drop entire template, user has to drag-and-drop individual monitor of the template.
December
2013
1.11
Improvements to QoS metrics.
September
2013
1.10
Added support for AMS and HUS. Fixed LUN statistics correlation.
August
2013
1.03
General release version supporting USP-V and USP-VM.
December
2012
1.00
November
2012
The hitachi probe requires:
Hitachi Storage System USP-V, USP-VM, AMS, VSP, or HUS series.
SMI-S Provider
The SMI-S Provider service is supplied with the Device Manager software from Hitachi with the Hitachi Command Suite 7.
Hitachi Storage Navigator user account privileges for VSP
The user account must belong to one of the following built-in user groups:
Storage Administrator (View & Modify) User Group - Users have full read and write permissions to access the SMI-S function from the
management software.
Storage Administrator (View Only) User Group - Users have read- only permissions to access the SMI-S function from the
management software.
If the probe is deployed in a non-English locale, change the Startup key value to -Xms512m -Xmx1024m -Duser.language=en
-Duser.country=US.
Update the Startup key value through Raw Configure. The updated key value removes the issue of adding an extra digit while reporting
disk size and percentage.
Refer the following link for Hitachi SMI-S Provider configuration:

http://www.hds.com/assets/pdf/hitachi-storage-command-suite-hitachi-device-manager-software.pdf
Contact your Hitachi provider for additional administrative configuration assistance.

The hitachi probe should be installed on a system with the following minimum resources:
Memory: 2-4GB of RAM

This section describes the software requirements for this probe.
NImsoft Monitor Server 7.6 or CA Unified Infrastructure Management 8.0 or later
Microsoft .NET Framework 2.0 or later on the system where the CA UIM is installed

Note: You cannot enable or disable the collection of the statistics on the storage system using the probe GUI. This action is typically
restricted to storage system administrators.
You must enable statistics reporting on the Hitachi array to receive data for performance metrics from the Hitachi system. Statistics reporting
affects performance metrics for array, LUN, and port. If the statistics reporting is not enabled for the Hitachi array, the probe does not show the
performance metrics in the GUI. Monitoring storage arrays with a large number of logical volumes and disks, from a single probe can affect the pe
rformance of the probe. In such cases, increase virtual memory appropriately.
Some of the performance metrics are as follows:
Statistic Time
Total IOs
Kbytes Transferred
Read IOs
Read Hit IOs
Write IOs
Write Hit IOs
Upgrades Considerations
Consider the following points when upgrading the probe to 2.0 series:
The probe migrates only Resources and Templates.
The probe does not migrate Auto-monitors and static monitors. Therefore, the probe generates alarms and QoS only for resource
availability before configuring the checkpoints.
The Backup file contains the following information:
The old and new QoS definitions.
The template and template key.
Merged values of Setup and Startup tags.
Other keys which are already present in the old CFG file.

Some known issues and workarounds of the probe are:
Large Config File May Cause Startup Problems

Symptom:
The probe does not load the complete configuration.
Solution:
The probe may or may not load the complete configuration if the hitachi.cfg file approaches 3 MB (Megabytes) in size.
Use these best practices to configure monitors to avoid a large hitachi.cfg file:
Use Auto Configurations to create Auto Monitors, where possible.
Convert an Auto Monitor to a static monitor only when necessary to handle a specific case.
Avoid too many inactive monitors on an array. Each array has its own section in the hitachi.cfg file. Monitoring configuration for multiple
arrays increases the hitachi.cfg file size.
hp_3par (HP 3PAR Storage Monitoring) Release Notes

The HP 3PAR Storage Monitoring (hp_3par) probe enables you to monitor the performance and usage of HP 3PAR StoreServ Storage systems.
The probe allows you to obtain performance and storage utilization statistics on the following storage objects:
Physical Disks
Logical Disks
Controller Nodes
Common Provisioning Groups(CPGs)
Virtual Volumes
Ports
Note: You can only configure the probe through Admin Console.
The probe includes the standard static alarm threshold parameters using CA Unified Infrastructure Management 8.2 or later.
Contents
Revision History
Enable and Disable the CIM Server for HP 3PAR
Revision History
Version
Description
State
Date
1.11
What's New:
GA
September
2015
June 2015
Added support for HP 3PAR StoreServ 7400 Storage systems.

1.00
First release of the probe with Admin Console GUI.

The probe configuration is available ONLY through Admin Console GUI and NOT through the Infrastructure
Manager (IM) GUI.
The probe includes the standard static alarm threshold parameters.

The hp_3par probe must be installed on systems with the following minimum resources:
HP 3PAR StoreServ (tested on HP 3PAR INServ F200)

The hp_3par probe requires the following software environment:
Install ci_defn_pack version 1.06 or later on the primary hub robot (with nis_server probe) to view the metrics on the USM portal. Restart
nis_server after you deploy ci_defn_pack.
The probe has the following preconfiguration requirements:
The CIM server is required as a data collector for interfacing with the HP 3PAR storage system using the SMI-S provider. You must start
the CIM server on your system to enable communication between the probe and the HP 3PAR storage system using the SMI-S provider.
In UIM 8.2, the NAS probe must be updated with the correct subsystem IDs.
For more information, see the applicable section.
Enable and Disable the CIM Server for HP 3PAR

The CIM server is a protocol included with HP 3Par storage servers to allow SMI-S connections. You can start, stop, and modify CIM services
using the following commands on the HP 3Par console:
To enable the CIM Server via the CLI, use startcim command:
# startcim
To disable the CIM Server via the CLI, use stopcim command:
# stopcim
To display the overall CIM Server status, use the showcim command:
# showcim

maintained by the NAS probe. If you are working with CA UIM 8.2, you must add the following subsystem IDs manually using the NAS Raw
Configuration menu. However, if you have upgraded to CA UIM 8.31 or later, then you do not have to manually add the following subsystem IDs:
Key Name
Value
2.10.2.1.
Resource
2.10.2.2.
Physical Disk
2.10.2.3.
Logical Disk
2.10.2.4.
CPG
2.10.2.5.
Virtual Volume
2.10.2.6.
Port
2.10.2.7.
Controller Node
1. In the Admin Console, click the icon next to the NAS probe, select Raw Configure.
7. Click Apply.

4. Enter the Key Name and Value
5. Click OK.
7. Click Apply.
hpsmgtw (HP Service Manager Gateway) Release Notes

The HP Service Manager Gateway probe generates an incident in the HP Service Manager (HPSM). Generating an incident helps the service
manager user to take corrective actions for resolving the issue. The incident is generated when an alarm is assigned to the designated HPSM
user. This probe is also able to track the incident status for acknowledging the alarm.
The hpsmgtw probe supports the following functionalities:
Generate the incident in the HPSM, when an alarm is assigned to the designated HPSM user.
Updates the incident information, when the alarm information is updated.
Updates the incident status, when the alarm is acknowledged.
Tracks the incident status in the HPSM and when the incident gets closed in HPSM, its corresponding alarm gets acknowledged in the
NMS.
Note: The HP Service Manager Gateway probe is released in a continuation of the hpovsdgtw 1.21 probe for supporting the HP
Service Manager 9.3.
Contents
Revision History
Revision History
Version
Description
State
Date
1.01
Fixed the alarm closing issue from HPSM to NMS.
GA
September 2013
1.00
Initial Release.
Beta
September 2013

The hpsmgtw probe must be installed on systems with the following minimum resources:
The hpsmgtw probe requires the following software environment:

CA Unified Infrastructure ManagementServer 7.6 or CA Unified Infrastructure Management 8.0 or later
Robot 7.1 or later
Java JRE 6 or later
HP Service Manager 9.30
The preconfiguration requirements for the HP Service Manager Gateway probe are:
The user credentials to access the HPSM application for working with incidents.
The CA Unified Infrastructure Management user to assign alarms, which triggers a new incident in the HPSM application.
Note: We recommend that you create a separate user in Infrastructure Manager for assigning the alarms. Refer to the Infrastructure
Manager guide for creating a user.
hub Release Notes

A hub serves as the communication center for a group of robots. A hub binds robots into a logical group with the hub as the central connection
point. Hubs are commonly set up based on location (such as a lab or building) or by function (such as development). A hub can also connect
other hubs into a hierarchy of hubs.
To install or upgrade a hub, see Installing on the CA Unified Infrastructure Management wiki space.
Contents
Revision History
Best Practices
Known Issues
Impact of Hub SSL Mode When Upgrading Nontunneled Hubs
SSL Communication Mode
Changes to SSL Communication in Controller v7.70
Communication Issues Between v7.70 and v7.63 (and Earlier)
Revision History
Version
Description
State
Date
7.80
GA
What's New:
Added support for OpenSSL
TLS cipher suites
When using TLS 1.1 or 1.2 cipher suites, include an alternative fallback to
SSLv3. Fallback ensures

SSL. For
example, AES128-SHA256:RC4-SHA, where AES128-SHA256 is TLS
v1.2 and RC4-SHA is SSLv3.0
backward compatibility between older robots and a new hub, or probes that connect to a robot using
OpenSSL 1.0.1m implemented

Windows IA64 and RHEL/CentOS-5 are no longer supported
User tags are automatically copied from robot.cfg to hub.cfg when upgrading to hub v7.80. During a restart
of the hub, user tags are copied:
If user tags do not exist in the
hub.cfg file
If the os_user_retrieve_from_robot option is true (default)

After the user tags are copied, the os_user_retrieve_from_robot option is set to
false in the hub.cfg file.
Clear the user tags in the hub.cfg file later by setting the os_user_retrieve_from_r
obot option to true, and restart the hub.

For alarms that the hub sends about robots, the default behavior for user tags is equivalent to hub v7.63. In hub
v7.63, the user tags are set to the tags of the robot representing the alarm. This behavior only applies to the
special case of hub robot alarms, and not to other alarms and messages.
The output information contains the robot user tags in the user_tag_1 and user_tag_2 fields. A
dded context user tags represent the hub user tags. Context user tags provide the user tags from the source of
the alarm, and are included in the message.
A new configuration option in the hub.cfg file, os_user_robot_alarms_use_hub_t
ags, allows you to revert to the behavior of hub v7.70.

If the option is 0 or the option is not defined, hub v7.63 behavior applies to
user_tag_1 and user
_tag_2.
If this option is set to 1, the behavior of hub v7.70 applies.
Note: User tag changes do not affect robot alarms that come directly from the robot. Hub
generated robot alarms, which occur when a robot or probes start or stop, are affected.
Removed ability to set SIDs with pu command. In past releases, the -S option of the pu command could be used
to set an explicit session identification (SID). This capability has been removed to prevent a security bypass through
SID injection.
Output character limit extended in pu executable. In the pu executable before v7.80, field output from callbacks
was limited to around 35 characters. A long output string might become unusable. To resolve the issue, the output
limit is extended to 300 characters.
June 2015
7.71
Hub v7.71 fixes an issue in hub v7.70 with assigning ports for tunnel client connections. Before v7.70, the tunnel client
connections would consistently use the 48xxx port range (based on the controller default first_probe_port setting of
48000). An issue in hub v7.70 caused the tunnel client connections to use a system assigned port number. System
assigned port numbers do not reliably fall in the 48xxx range. This caused issues with firewalls where the tunnel ports
were explicitly allowed and expected to be in the specific range.
GA
March 2015
With hub v7.71, the default port range for tunnel client connections again falls in the 48xxx range. As in previous
versions, the specific ports for tunnel connections can be overridden by enabling Ignore Controller First Probe Port (wh
ich enables the hub to use its own setting) and by specifying the desired port setting tunnel/ignore_first_probe_port = 1
and tunnel/first_tunnel_port = portnumber in the hub configuration file, hub.cfg:
In the Admin Console hub configuration UI, navigate to Advanced, Tunnel Settings. Under Tunnel Advanced
Settings, enable Ignore Controller First Probe Port. Specify the desired First Tunnel Port.
In the Infrastructure Manager hub configuration UI, navigate to Tunnels. Enable Ignore first probe port setting
from controller, and specify the desired First Tunnel Port.
7.70
Important: We recommend that you connect hubs with tunnels (see Best Practices for Hub-to-Hub Communication).
Hubs require tunnel connections. Without tunnels, hubs set to mode 0 (no encryption) cannot communicate with hubs set
to mode 2 (SSL encryption). See Impact of Hub SSL Mode When Upgrading Nontunneled Hubs.
New Features:
December
2014
SuSE10 and SLES11 are no longer supported.

Hubs allow robots to retain the origin of their designated parent hub when failing over to a secondary hub.
The origin is attached to each QoS message generated by a probe and routed through its robot.
By default, the origin is the name of the designated parent hub of the robot. The origin is attached to messages
by the hub spooler.
The default origin that is used upon hub failover has changed. When a robot with no specified origin failed over
to another hub, the origin was changed to the failover hub. Now, the origin is the name of the robot designated
parent. Specify the origin in the hub attribute in robot.cfg.
Note: CA UIM administrators can override the default value by defining the origin in the robot
configuration file robot.cfg. In multi-tenant environments, an admin can specify the origin for
origin attribute exists in robot.c

fg, the robot spooler attaches it to the message. The hub spooler does not alter the origin. This
grouping data and control user access to the data. If the
behavior has not changed.
Note: The os_user_include option, which enabled the hub to read user tags from
robot
.cfg, has been removed. Now, the hub does not read user tags from robot.cfg. If the hub
robot has defined user tags, they remain in robot.cfg after the upgrade, but the tags are ignored.
To add user tags to hub probe alarms and messages, specify the user tags in hub.cfg.
User tags are propagated by the hub and controller. User tags are now propagated in alarms and messages by
os_user1 and os_u

ser2 from robot.cfg. Now, the hub reads user tags from hub.cfg. The General Configuration secti
on in the Admin Console hub configuration UI allows users to specify os_user1 and os_user2. On a
both the hub and the controller. Previously, both the hub and controller read user tags
hub system, the hub spooler adds these values to probe generated alarms and messages. On a robot system, the
robot spooler adds the tags.
Hub v7.70 can be configured to send an alarm for dropped messages. Probe messages use the subject for
routing in the message bus. The spooler drops messages If a subject is not configured in a hub attach or post
queue.
If a subject is not configured in a hub attach queue or a post queue, the spooler drops the message. Hub v7.70 can
send an alarm when a message is dropped. This behavior is disabled by default. To enable it, specify the following
parameter in hub.cfg:
subjects_no_destination_alarm_interval=seconds
Consistent enforcement of username and password limitations

The username must be 1 through 255 characters long.
.The username cannot contain control characters, right or left arrows (< or >), or forward slashes (/).
The password must be 5 through 254 characters long.
Improved behavior of SSL mode
If a hub controller sets SSL
mode=0, the controller does not create a robot.pem file at startup. Any
SSL connections.
CA UIM components that are installed on that system do not accept
Improved DNS lookup during tunnel setup

DNS lookup, which maps the host name to an IP address, retries on DNS failures. Tunnels are more tolerant of
temporary or intermittent network failures.
Fixed defects:
General stability and robustness are improved.

The original configuration is retained when changes to the hub configuration cannot be saved because the file
system is full.
Hub support for LDAP over SSL is improved.
Files and directories in hub/q are properly cleaned up when queues are removed.
The tunnelsetup command properly imports tunnel client certificates.
The controller does not assign probes to ports used by hub tunnels. Ports are assigned to the correct interfaces
based on strict binding mode.
Proxy_mode routes all callbacks to the probes through the controller port. Robots which are configured for p
roxy_mode, return to the designated parent hub after failover.
7.63
August 2014
OpenSSL 1.0.0m is implemented

LDAP reliability is Improved when an SSL connection to the LDAP service is required.
Stability for long queue names is Improved (Salesforce case 00145363)
The CA UIM Server 8.1 distribution includes the package.
Fixed defects:
Circular message queues caused memory resource leaks (Salesforce case 00147673)
If the baseline_engine and the prediction_engine are deployed to a hub, a file descriptor resource leak can
occur.
A potential crash condition that is caused by invoking the
tunnel_get_info callback.
A potential crash condition when stopping a robot

7.61
Improved tunnel stability
June 2014
Package included in CA UIM Server 8.0 distribution

7.60
Improved socket management between two hubs that are connected by a tunnel
Long-running callbacks over a tunnel connection cause fewer communication errors
March
2014
Queue status alarming has been refined to reduce false positives

LDAP directories with large numbers of groups are handled more efficiently when paired with UMP 7.6
7.50
Tunnel and queue connect and disconnect alarms are retroactively reset to the Information level matching their
actual meaning and impact.
The hub detects when the total resources in use threaten tunnel or hub viability. The hub reacts by either resetting
the tunnel or restarting the process, without data loss.
The origin for probes local to a hub can be set independently from the origin of the hub.
Enhanced LDAP and user level security and improved support of LDAP environments with large numbers of groups
Improved tunnel stability
Fixed defects:
A core dump on Solaris when hubup response contents are malformed
A significant number of sockets are temporarily left in the
with many child robots
CLOSE_WAIT state when hubs communicate
Duplicate tunnel connections between the same client and server permanently disconnect the tunnels due to the
exhaustion of threads
7.11
Improved the method for determining the status of
get-attach queues that carry low volumes of data
Tunnel server TCP sockets are more efficient

A problem that could cause the number of sockets to grow unbounded is addressed
Fixed defects:
High-volume deployments when the hub is used as an LDAP proxy hub
High-volume deployment when hub is used with the snmpcollector probe
January
2014
Best Practices
While most hubs perform well with little interaction from the administrator, you can modify various configuration settings for better
performance.
Hub-to-hub communication
Use tunnels to keep the communication connectivity intact between hubs.
Tunnels
Caching the SSL sessions can significantly speed up the server to client connection time.
To get tunnel alarms, increase the alarm level that is sent if a connection is lost or cannot be made.
Queues
Increasing the Bulk
Size of the queue allows the hub to transfer multiple messages in one packet. Increase the Bulk
Size when:
The size of a get or a post queue never shrinks to zero
Too many messages are queued
Known Issues
The ppm probe provides functionality for the Admin Console probe configuration UIs. The ppm probe does not run on AIX hubs. To
configure robots and probes on AIX hubs, use the Raw Configure utility in Admin Console, or use Infrastructure Manager.
If the communication with a robot fails in Linux, review your network configuration:
A valid entry for the local system in the /etc/hosts file for a robot, hub, server, or UMP system
The entry for the local system must be a fully qualified host name and IP address.
If only the loopback address is defined, for example,
address.
localhost 127.0.0.1, the controller is unaware of its own IP
IP address problems result in network communication failure.

The ade robot distribution to Windows targets sometimes fails to activate the hdb and spooler probes. To resolve the issue, do a v
alidate security on the affected probes (hdb and spooler)

Origin issue on failover in hub v7.1 through v7.63:
Robots do not retain the configured origin when they connect to a failover hub
If robots are added to the inventory by automated discovery, USM cannot auto-deploy the robots to AIX or zLinux systems. Use
one of the following alternative methods:
Run the native installer manually or with a third-party tool. See Deploy Robots in Bulk with a Third-Party Tool and Native Installers.
Use the Automated Deployment Engine (ade) probe with an XML file. See Deploy Robots with an XML File and the ADE Probe.
Import an XML file in USM. See Deploy Robots with an XML File in USM.
In high-volume deployments, hub v7.10 might have issues when the hub is used in the following situations:
As an LDAP proxy hub
When used with the SNMPCollector probe
These problems are addressed in hub v7.11 and later
Inactive queues might negatively affect hub v7.10. when the hub is used as a tunnel server:
The number of Windows file handles and Unix file descriptors might grow over time
The growth rate increases greatly when the tunnel server is servicing get queues that carry little or no data
Get queues can reset regularly
As the number of resources in use becomes large, the hub might automatically restart. The hub returns to normal operation, and
no data loss is expected. These problems are addressed in hub v7.11 and later.
Impact of Hub SSL Mode When Upgrading Nontunneled Hubs

The 7.70 release of the CA UIM hub and robot have improved the robustness of SSL communication. The hub SSL mode specifies the
communication mode of hub-managed components. SSL mode is primarily used for robot-to-hub communication. SSL mode is used for
hub-to-hub communication when hubs are not connected with tunnels.

Before hub v7.70, in a nontunneled domain, hubs that are configured for unencrypted communication can decode encrypted messages. In
a multiple hub domain, upgrading to v7.70 breaks this communication.
Note: Any tunnels set up between hubs will remain after you upgrade, and communication will continue. We strongly recommend that you
connect all CA UIM hubs with tunnels to ensure the integrity of hub-to-hub communication.
SSL Communication Mode

CA UIM hubs have three communication mode options:
SSL mode 0 No encryption
The OpenSSL transport layer is not used
SSL mode 1 Compatibility mode
The hub and robot communicate either without encryption or with OpenSSL encryption
SSL mode 2 OpenSSL
OpenSSL Encryption only

When the hub is set to mode 1, the managed components first attempt to communicate through SSL. If a request is not acknowledged,
the component sends unencrypted requests to the target.
SSL communication is enabled through the UIM_HOME/robot/robot.pem certificate file. The controller creates the robot
.pem file during startup. The robot.pem file contains the key to decode encrypted CA UIM messages.
Changes to SSL Communication in Controller v7.70
SSL communication modes are more meaningful in controller v7.70 because of changes to the treatment of the robot.pem certificate
s.
Note: The following information about controller v7.63 also applies to previous versions.
Controller v7.63 always creates robot.pem and always acknowledges receipt of encrypted communication, regardless of the
parent hub mode.
The first SSL encrypted request from a v7.63 controller in mode 1 to a v7.63 hub in mode 0 succeeds. The hub uses the r
obot.pem file to decode the message.

An unencrypted request from the hub to the controller also succeeds because the compatibility controller accepts it.
Components that are configured for unencrypted communication, and lack the OpenSSL transport layer, can decode encrypted
messages, and can encrypt responses.
Controller v7.70 creates robot.pem only when the hub communication mode is 1 or 2.
An encrypted request from a v7.70 controller in mode 1 to a v7.70 hub in mode 0 fails. The hub cannot decode the message. The
controller sends subsequent requests unencrypted.
An unencrypted request from the hub to the controller succeeds.
Controller v7.70 honors the meaning of no encryption and of SSL:
All communication for mode 0 components is unencrypted
Mode 0 components cannot decrypt messages from mode 2 (SSL only) components.
Communication Issues Between v7.70 and v7.63 (and Earlier)

If the parent hub is set to mode=0 (unencrypted), controller v7.70:
The controller does not create the robot.pem file
If the robot.pem file exists, the controller deletes it
When hubs that are upgraded to v7.70 communicate with earlier versions, and hubs are set to the same mode:
Hubs set to mode 0 communicate unencrypted
Hubs set to mode 1 use SSL encryption
Hubs set to mode 2 also use SSL encryption
The following diagram illustrates communication when all hubs are at or below v7.63, and when all hubs are v7.70. In the diagram:
Blue lines in the diagram represent SSL communication
Red lines in the diagram represent unencrypted communication
Solid lines in the diagram indicate successful communication
Dashed lines in the diagram are unacknowledged
Arrow direction indicates the initiator and receiver relationship.
A v7.63 hub in mode 0 cannot initiate communication with a mode 2 hub. Two-way communication is enabled once the relationship
is established.
The behavior when the modes are mixed is as follows:

Version 7.63 and earlier:
Encrypted messages from hubs in mode 1 and 2 are decrypted
Hubs in mode 1 acknowledge unencrypted messages from hubs in mode 0
Hubs in mode 2 discard unencrypted messages from hubs in mode 0
Version 7.70 and later:
Hubs in mode 1 decrypt encrypted messages from hubs in mode 2
All requests between hubs in mode 0 and hubs in mode 2 are not acknowledged and are discarded
Encrypted requests from a mode 1 hub to a mode 0 hub are ignored. Unencrypted requests between the hubs are acknowledged.
hyperv (Microsoft Hyper-V Monitoring) Release Notes

The Microsoft Hyper-V Monitoring probe allows you to monitor the health and performance of the Microsoft Hyper-V servers. The probe collects
the necessary information about the following systems:
Host Operating System (OS)
Corresponding hypervisor system (Windows 2008/2012/2012 R2 Server + Hyper-V / Windows 2008 Server Core + Hyper-V)
Virtual Machines configured on the Host OS.
Note: Version 3.0 or later of the probe is available only through the web-based GUI. The Infrastructure Manager (IM) GUI is only
available for version 2.2 or earlier.
The probe allows you to define alarms and their corresponding threshold values. You can compare the actual data at customizable intervals using
generated QoS messages. The probe then generates alarms when the corresponding threshold values are breached.
The probe monitors the following entities on the host:
CPU
Memory
Disk
Network
Resource Pool
The probe also monitors the following entities of each Virtual Machine (VM) on the host:
CPU
Memory
Disk
Network
The 3.10 and later versions of the probe allow you to create configuration templates. The templates are applicable to only the specific instance of
the probe on the robot. Only existing profiles can be configured using templates.
Contents
Revision History
Known Issues and Limitations
Revision History
This section describes the history of the revisions for the hyperv probe.
Version
Description
State
Date
3.10
What's New:
Beta
May 2015
Added factory template for monitors available on the Hyper-V Unified Dashboard.
Added support for dynamic variables using CA Unified Infrastructure Management 8.31 or later.
Note: The following features are not yet supported in version 3.10:
Localization
Monitoring NT Events and Services
Groups
3.00
Beta
March
2015
GA
September
2014
The following features are not supported in version 3.00:
Localization
Groups
Templates from the Infrastructure Manager GUI.
The static standard threshold block is available for the probe.
Note: Probe is supported from CA Unified Infrastructure Management 8.0 and later only.
2.20
Fixed an issue where GUI response time was very high with large number of monitors.
Fixed a defect where Resource Pool name was appearing blank. The value of Resource Pool is now similar to the value
of caption field.
Fixed a defect where probe was generating null value for the instances in network counters of Legacy Network adapter
in Windows 2012 R2. The value is now similar to the value of instances in network counters of Virtual Network adapter.
Added support for alarm generation of Events.
2.11
2.10
Improved probe performance by restricting fetching of events to maximum of 600.

Added support for monitoring Windows Server 2012 R2 Hypervisor.
June 2014
June 2014
Added support for the following locale: Simplified Chinese, Japanese, Korean, Spanish, French, German, and
Portuguese.
2.00
Added support for monitoring Windows Server 2012 Hypervisor.
September
2013
1.12
Probe is now NIS2-enabled.
April 2010
1.11
General availability release.
September
2009
1.10
Initial commercial release.
June 2009

The hyperv probe must be installed on systems with the following minimum resources:

The hyperv version 3.10 or later requires the following software environment:
CA Unified Infrastructure Management Robot 7.7 or later (recommended)
ppm 3.12 or later
The version 3.00 of the probe requires the following software environment:
The version 2.2 or earlier requires the following software environment:
CA Unified Infrastructure ManagementServer 7.6 and CA Unified Infrastructure Management 8.0 or later

.Net Framework 3.5
The migration considerations for the probe from the 2.20 to a later version are listed below:
Downgrade is not supported to version 2.20 or earlier from any later version of the probe.
You must delete all the files in the util directory in the windows local temp directory.
You must perform this process for each instance of UIM accessing the robot.
The following features are not supported in version 3.0 or later:
Localization
Groups
Templates created in version 2.2 or earlier are not supported in version 3.0 or later. However, you can create new templates from the Te
mplate Creator interface in hyperv version 3.10 and later using the Admin Console.
The following static text alarms have been discontinued:
Host Name
Resource Pool Name
Resource Pool Status
Physical Network Adapter Name
Virtual Machine Name
The CPU Load Percentage QoS has been discontinued.
Alarms from previous versions of the probe must be manually cleared.
Known Issues and Limitations

The known issues of the version 3.0 or later of the probe in the Unified Monitoring Portal are listed below:
The Write Throughput (Disk) alarm for Virtual Machines is displayed separately.
Some Host CPU metrics are displayed twice.
The probe has the following limitations:
Clustered Hyper-V environments are not supported.
ibm_ds_next (IBM Disk Storage System 8000 Series Monitoring) Release Notes
The IBM Disk Storage System 8000 Series Monitoring (ibm_ds_next) probe monitors IBM DS8xxx storage systems and stores the monitoring
information at specified intervals. You can specify thresholds and define alarms that are generated when the specified thresholds are breached.
The probe uses an SMI-S interface to communicate with the IBM DS storage system. Install the SMI-S provider on the storage system to enable
communication with the probe. The SMI-S is a standard for managing heterogeneous storage systems in a SAN (Storage Area Network).
The probe can monitor the following components:
Arrays
Disks
Pools
Ports
Ranks
Volumes
Contents
Revision History
Prerequisites
Revision History
Version
Description
State
Date
1.0
What's New:
Beta
December
2015
First release of the probe.

The probe configuration is available ONLY through Admin Console GUI and NOT through the Infrastructure Manager
(IM) GUI.
Prerequisites
The prerequisites for the ibm_ds_next probe are as follows:
A user account with Monitor role in the IBM DS8000 Storage System

The probe must be installed on systems with the following minimum resources:
Memory: 4 GB of RAM. The OOB configuration of the probe requires 512 MB of RAM
CPU: 3-GHz dual-core processor 32-bit, or 64-bit

Probe Provisioning Manager (ppm) version 3.24 or later
Baseline Engine (baseline_engine) version 2.70 or later
Prediction Engine (prediction_engine) version 1.31 or later
ci_defn_pack version 1.16 or later on the primary hub robot (with the nis_server probe)
This is required to view the metrics on the USM portal. Restart the nis_server probe after you deploy the ci_defn_pack.
mps_language_pack version 8.38 or later
This is required to view the metric type on the Admin Console. Restart the service_host probe after you deploy the mps_language_pac
k.
Unified Dashboards version 2.96 or later
ibm_svc (IBM SVC Monitoring) Release Notes

The ibm_svc probe is used to monitor the IBM System Storage SAN Volume Controller (SVC) and IBM V7000 storage systems. The probe can
monitor the following components: vDisk, mDisk, mDisk Group, Node, Cluster, Host, IO Groups, and, Port.
The ibm_svc probe retrieves the following performance data to generate alarms and QoS:
CPU Utilization: The total CPU utilization of the storage system.
Interfaces: The connection speed of the interfaces with the Fiber Cables (FC), iSCSI, and the SAS hosts.
Volumes: The read/write speed and latency of the volumes.
MDisks: The read/write speed and latency of the MDisks.
Note: The performance data is available at system and node levels.
The probe uses SMI-S provider and Command Line Interpreter (CLI) to retrieve status, configuration, and statistics data of the IBM SVC storage
server. The probe supports user authentication through SSH only. So, you require a password or a valid SSH key file to access CLI.
Contents
Revision History
Help Button in IM Redirects to Legacy Document
Revision History
Version
Description
State
Date
1.05
Fixed Defects:
CR
October
2015
The probe generated incorrect alarms for Mdisks. Salesforce cases 00151468, 00156360
The probe connected to the wrong port and was unable to retrieve the resource data. Salesforce case 00164563.
The probe was unable to limit the log file to the specified size. Salesforce case 00169660
Updated the overview section in the Release Notes and the ibm_svc (IBM SVC Monitoring) article to state that the
probe supports user authentication only through SSH. Salesforce case 70002124
1.04
Fixed an issue where the IO, Latency and Throughput QoS metrics for MDisks and VDisk were displayed as 0. Salesforce
case 00134834
GA
July 2014
1.03
Added option to select IBM SVC or IBM V7000 storage system for monitoring in the Probe Configuration section.
GA
June
2014
1.02
Added support for monitoring the IBM V7000 storage systems.
Beta
May 2014
1.01
Initial Release

The ibm_svc probe is installed on systems with the following minimum resources:
December
2013

The ibm_svc probe requires the following software environment:
.Net Framework 3.5, on the system where the probe configuration GUI is running

You must enable statistics reporting on the storage array to receive data for performance metrics from the IBM SVC system. Statistics reporting
affects performance metrics for the array, LUN, and port. Some of the performance metrics are as follows:
Average Read Latency
Average Write Latency
Read Throughput
Write Throughput
Read IOPS
Write IOPS
Total IOPS
Total Throughput
Read Throughput
Total Bytes
Total IOs
Read IOs
Write IOs
Note: Only the storage system administrators can enable or disable these statistics on the storage system using the probe GUI. In
order to turn on performance metrics for your storage array, contact your IBM_SVC provider for instructions and any information about
potential performance degradation.
Important! Performance may be affected when monitoring storage arrays with a large number of logical volumes and disks from a
single probe. In such cases, try increasing virtual memory appropriately.

Some known issues and workarounds of the probe are:
Help Button in IM Redirects to Legacy Document

Symptom:
The Infrastructure Manager GUI of the probe opens the legacy document when the Help button is clicked.
Solution:
Visit v1.0 ibm_svc IM Configuration for the current documentation.
ibm-ds (IBM Disk Storage Systems Monitoring) Release Notes

The IBM Disk Storage System Monitoring (ibm-ds) probe monitors IBM DS3xxx, IBM DS4xxx, and IBM DS5xxx storage arrays. The probe stores
the monitoring information at customizable intervals. You can define alarms to be generated when specified thresholds are breached.
The probe uses an SMI-S interface to communicate with the IBM DS storage system arrays. Install the SMI-S provider to enable communication
between the probe and the storage system. SMI-S is a standard for managing heterogeneous storage systems in a SAN (Storage Area Network).
Storage Array
Controllers and Ports
Storage Pools
Array Groups
Logical Volumes
Disks
Contents
Revision History
Revision History
Version
Description
State
Date
2.07
What's New:
GA
December 2015
GA
September 2014
GA
July 2014
GA
January 2014
Added support to use SSL connection to the IBM DS server.

Fixed Defects:
The probe was getting disconnected from the SMI-S service. Support case number 00155728
The probe was unable to retrieve data from the storage system. Support case number 00159919
2.05
2.04
Added QoS for Used Managed Space and Percent Used Capacity for array.
Fixed a defect in which the probe was displaying the following errors when tested with correct information of the
IBM_DS resource:
The hostname or IP address is wrong or illegal
The port number is wrong
The handler class is wrong
2.03
Fixed a defect in which the probe was running only in Demo Mode.
2.01
Probe can be configured on Admin Console and Snap UI.
December 2013
QoS Management is removed.

User can drag and drop the checkpoints of the template in Auto Configuration.
1.10
Added support for IBM DS5xxx. Renamed the probe to ibm-ds. Many usability improvements and defect fixes.
May 2013
1.01
December 2011
1.00
First release of ibm-ds4k probe.
November 21
2011
1.00
Initial release.
November 10
2011

This section contains the following hardware requirements for the probe:
IBM DS3xxx, IBM DS4xxx, or IBM DS5xxx series storage array
Memory: 2-4GB of RAM

The ibm-ds probe requires the following software environment:
The SMI-S Provider for IBM DS3xxx, IBM DS4xxx and IBM DS5xxx, supplied by NetApp (formerly known as LSI). It is available for
download here (login required). Additional SMI-S configuration information is available from IBM in the document "Configure SMI-S
providers for storage - IBM".
Consider the following points when upgrading the probe to version 2.0 and later:
1. The probe migrates only Resources and Templates.
2. The probe does not migrate Auto-monitors and Static monitors. Therefore, the probe generates alarms and QoS only for resource
availability before configuring the checkpoints.
3. The Backup File contains the following information:
The old and new QoS definitions.
Templates and their keys.
Merged values of Setup and Startup tags.
All ibm_ds.cfg keys.

Performance may be affected when monitoring storage arrays with a large number of logical volumes and disks from a single probe. In such
cases, try increasing virtual memory.

The known issues of the probe are as follows:
In 2.05 and earlier versions of the probe, the Use SSL field is available, but not functional.
If the ibm-ds.cfg file exceeds 2 MB, then start up problems may occur. Each array contains its own monitor configuration section. So if
each array has multiple monitors, the configuration file can grow quickly. CA recommends you to maintain only active monitors on an
array to stop the configuration file from growing unnecessarily, as inactive monitors use up configuration space. The default auto
configuration template contains the most popular active monitors, and provides a good starting configuration.
The probe does not support IPv6 internet addresses. You can use IPv4 internet addresses, wherever required. Some operating systems
(such as Windows 2008 R2) might be configured to resolve hostnames to IPv6. To avoid this issue, provide the IPv4 internet address
instead of a hostname.
ibmvm (IBM Virtualization Monitoring) Release Notes

The IBM Virtualization Monitoring (ibmvm) probe monitors the health and performance of the IBM virtualization enabled systems. The probe is
capable of monitoring the managed systems connected to Hardware Management Console (HMC) interfaces.
Contents
Revision History
Probe Specific Environment Requirements
Upgrading to v2.30
Unknown Status for VMs Displays in USM
Probe is Unresponsive
Network Interfaces Do Not Appear to be Detected by the Probe
Revision History
This table describes the history of probe updates.
Version
Description
State
Date
2.33
What's New:
GA
August
2015
Limited
Availability
July 2014
Improved structural and topological architecture of the probe to improve performance and to more accurately reflect
PowerVM environments.
Added the ability to apply monitoring with templates in Admin Console.
Added documentation about how to format IPv6 addresses when used for a Uniform Resource Identifier (URI); use
the Java convention of enclosing an IPv6 address in square brackets.
For more information, see the v2.3 ibmvm AC Configuration and v2.3 IM Configuration guides.
Changed the following metrics to now be grouped with the HOST_DISK resource rather than with a separate
resource HOST_DISK_UTILIZATION:
Disk Bandwidth Used
Disk Data Transfer Rate
If you have custom reports and dashboards using these metrics, you will need to update their resource from
HOST_DISK_UTILIZATION to HOST_DISK.
For more information, see the ibmvm Metrics.
Fixed Defects:
Fixed a defect in which self-monitoring alarms for data collection problems were sent with the wrong subsytem ID
and auto-monitors for LPARs were created against inactive LPARs resulting in alarms being sent due to
unavailability of data. Salesforce case 00161243
Fixed an issue in which delta values were incorrectly calculated.
2.1
Added additional QoS metrics. For more information, see ibmvm Metrics
2.00
Probe is now compatible with Admin Console.

Updated UI in Infrastructure Manager and Admin Console for virtual environments.
Added support for multiple shared processor pools (MSPP).
GA
March
2014
1.26
Changed Probe Help button to access online help
GA
August
2012
1.23
Retry if the SSH connection to the HMC fails

Retry if we get incomplete output from lslparutil
Fix locale issue causing thresholds to be incorrectly parsed
Send clear alarm when HMC comes back online
Updated to use Nimsoft JRE startup
Handled empty output from lslparutil
Improved error handling when unexpected output is encountered.
Beta
June 2011
1.21
Fixed HMC version identification
April 20
2010
1.20
Added Java implementation, including:

Added scalability and performance improvements
Reduced impact on the HMC (minimized the number of commands that the probe will run)
Added support for configuration items and metrics (NIS2).
Note: Java 1.5 (or newer) is now required.
April 1
2010
1.12
Fixed CPU Pool metrics to reflect the average value during the last interval, instead of the average value since system
start.
September
2009
1.10
Commercial Release
Added a Physical Processors Consumed checkpoint to indicate how many physical processors an LPAR has used
Fixed the percent entitlement used checkpoint to use the difference between last two samples
Fixed the percent entitlement used checkpoint to gather cycle times for all LPARs
Applied checkpoints filtering based on the host type and version. This is done to disallow showing checkpoints which are
not supported for specific host and version in the GUI.
Currently the filtering is applied on checkpoints for HMC version 7, following are the checkpoints:
1. Current LPARs Supported
2. Managed System to Firmware LPAR ratio
3. Maximum LPARs Supported post next restart
4. Managed System to Firmware LPAR ratio post next restart
5. Uptime.
June 2009

The probe requires:
A Hardware Management Console (HMC) virtualization environment. Integrated Virtualization Manager (IVM) environments are not
supported.
PowerVM enabled on an IBM system I/P series server with Hardware Management Console (HMC).
Note: Version 2.30 of the ibmvm probe supports up to Power7+ with Hardware Management Console (HMC) version 7.9.0.
Advanced accounting enabled on Shared Ethernet Adapters (SEA) before the IBM Virtualization Monitoring probe can report any
statistics. To enable advanced accounting on the SEA, enter the following command:
chdev -dev <SEA device name> -attr accounting=enabled
The HMC server enabled for SSH access, and the SSH user must have the HMC Operator level of access. This allows you to use the
viosvrcmd command on the HMC server to gather data from the Virtual I/O Server (VIOS) for many of the checkpoints.
The Processor Entitlement Consumed and Physical Processors Consumed checkpoints require the lslparutil command. Run the chlparutil
-r config -s 300 command on the HMC server.
Note: Older HMC versions might only support -s 3600 to collect utilization metrics every hour. The data will remain the same
for the duration of the hour, until a new sample is recorded by the HMC server.

The following sections describe the required software for specific versions of the probe.
v1.3 and Later:
CA Unified Infrastructure Management server 7.0 or later.
Robot version 5.23 or later.
Java Virtual Machine version 1.6 package or later (deployed as part of the probe package).
For Infrastructure Manager users:
CA Unified Infrastructure Management 4.06 or later.
Microsoft .NET framework 3.5 on the system running the Infrastructure Manager and IBM Virtualization Monitoring probe GUI.
v1.26 and Earlier:
Java Virtual Machine 1.6 or later (typically installed with NMS 5.0 and above)

The probe should be installed on systems with the following minimum resources:
Upgrading to v2.30
Versions 2.30 is the first version of the probe to include support for applying monitoring with templates in Admin Console. To upgrade and then
apply monitoring with templates in Admin Console requires that all previous configuration be deleted. Because of this, we recommend that you
delete probe versions earlier than 2.30 and deploy a new v2.30 probe.
If you want to configure the probe using only Infrastructure Manager, you can upgrade from an earlier version to v2.30 without deleting any
previous configuration. However, not all features of v2.30 and later are supported in Infrastructure Manager.

Unknown Status for VMs Displays in USM
In USM, the power indicators for all VMs display a question mark, which is the icon for "unknown status". This is an issue with the UI.

Issue:
Solution:

Symptom:
Solution:
Probe is Unresponsive
Symptom:
The IBM Virtualization Monitoring probe may be unresponsive under heavy load, during scheduled re-discovery, or immediately after applying a
monitoring template to multiple large devices.
Workaround:
If the probe is unresponsive, wait several minutes and try again.
Network Interfaces Do Not Appear to be Detected by the Probe

Symptom:
Network interfaces do not appear to be detected by the probe. If the log level is set to 2, I see a message similar to the following:
Mar 26 08:23:13:382 [pool-1-thread-1, ibmvm] The network adapter ent0 b

elonging to 8203-E4A*0539AC2 does not return valid output from 'entstat
' command.
Mar 26 08:23:13:382 [pool-1-thread-1, ibmvm] entstat: 0909-003 Unable t
o connect to device ent0, errno = 19
Workaround:
This is not an issue. A node for network interfaces will only appear if the device can be monitored.
ica_response (Citrix Client Response Monitoring) Release Notes

The Citrix Client Response Monitoring probe (ica_response) tests the Citrix terminal server client connection performance by executing the login
and logout commands. The probe can also launch an application or run a macro script for monitoring application performance, which is hosted on
the Citrix server.
The probe defines a monitoring profile for each Citrix ICA server with all necessary data for the connections. The probe connects to the Citrix ICA
servers as specified in the profiles, logs in, and monitors the time to perform the different tasks.
The probe also supports QoS (Quality of Service) data, for generating trending data over a period. The QoS data reflects the actual accessibility
as experienced by end users attempting to log in to the Citrix ICA servers. The probe generates the QoS data on following metrics:
Connect time
Session time
Login time
Logout time
Startup published application time
Run macro script time
ICA ping
Total profile time
Note: The upgrade from the probe version 3.01 to version 3.02 is seamless. The macro functionality also works fine on upgrade.
Contents
Revision History
Prerequisites
Known Issues
Revision History
This section describes the history of the revisions of this probe.
Version
Description
State
Date
3.03
Fixed Defect:
GA
December
2015
GA
December
2015
GA
December
2014
Beta
December
2014
The Session QoS generated null value as the probe initiated multiple Logoff events. The probe also created multiple
QoS with null value for Macro Failure and Macro Timeout events. Salesforce case 245373
3.02
Fixed Defects:
The probe did not connect to the Citrix server in some instances. This issue occurred when the Published Application optio
n was enabled from the Connection section in the General tab for a profile. Salesforce case 00155845
3.01
What's New:
Automated the process of registering the 'nimbus_ica.dll' library on the system.
3.00
What's New:
Added support for TNT2 compliance where Device Id and Metric Id are getting generated.
Added support for Citrix receiver 4.1
Added Support for Windows 7 and Windows Server 2012 R2
2.52
Fixed issue: Fixed an issue in which the probe could not find the file specified (while running the exe).
GA
October
2012
2.51
Support for Macro recording and positive value for Macro QoS added.
GA
June 2012
2.50
Support for citrix online plugin 12.3 for desktop and web client. Feature added to support ICA Client 12.3.All existing features
should work with this client except macro recording.
June 2012
2.42
Added fix for blue screen problem. Improved logging to know if unwanted processes are killed Fixed screen shot taking
functionality Improved logging to know about calling logoff method. Also improved logging for success and failure of
Logoff method.
GA
February
2012
GA
October
2011
Fixed issue related to show Logoff value (more than 20000), after mentioning logoff delay greater than zero
Fixed run time error (while browsing ica file and macro file).
2.41
Added fix null QoS Values.

Added validation on GUI on Profile-->General tab
Feature added to support ICA Client 11.2
2.40
Added fix for ica_response probe does not send clear messages.
October
2011
Added fix to Prohibit use of whitespace in configuration.

Migration of code to Citrix ICA Client Version independent to Support for 64-bit Windows Server 2008 R2 and 32 bit
machines.
2.31
Added fix to validate blank and duplicate profile.
GA
October
2009
GA
October
2008
GA
August
2008
GA
April 2007
Added fix to send logon failure alarm if the user credentials are wrong.
Added fix to logoff ICA client properly on probe restart and stop.
Added alarms for timeout and connection disconnected.
2.27
Added QoS Total profile time that measures time taken for the total operations for the profile. Gives NULL if:
Connect fails
Logon fails
Macro fails
Published application fails
ICA file fails
Logoff fails
Session exit fails
2.19
Added ICA client user to run the ica_response_poll executable in a verified ica client environment. More information in
the ica_response nimbus documentation.
Set fixed resolution to 640x480 for macro recording and playback.
Fixed issue with macro recording and playback.
Added unique SessionGroupID for each profile. Used LogoffSessions with SessionGroupID to terminate hanging
sessions on the server.
Corrected bug in IcaResponse, in state WaitLogOff, see use of m_waitUntil.
The time when screen dumps are taken before a session timeout can be set by manually adding
start_capture_before_session_timeout = , where n is the number of seconds before a session timeout.
Added function for screen dump of client area when session times out. Screen dump can be configured to manually add
save_screenshot_on_timeout = true key in the profile section.
Known issues:
Minimum screen resolution for the macro recorder is 1280 x 1024 pixels.
Screen resolution does not work in Win2000 (does not resize properly and the user must use scrollbars), verified ok
on XP.
2.16
Fixed long delay when ICA Macro file browser is launched. This method is dependent on a new version of the controller,
with support for drive listing. With an old controller, the delay will be unchanged.
Fixed problem with address settings when use ICA file is selected.
Known issues:
on XP.
2.14
Fixed missing logon timeout alarms.
GA
Added messages for logon response warning and connect response warning.
March
2007
Fixed OS detection bug in remote file viewer.

Added possibility to select encryption level from GUI.
Fixed screen resolution bug in macro recorder.
Fixed browser address disappearance when the GUI is restarted.
Fixed problems with macro recorder connect, when a profile is configured to use HTTP or UDP browsing protocol.
Known issues:
on XP.
Gui does not work on Vista due to a problem with loading Strip.ocx
Included Nimbus.dll in the package.
Fixed problems with language settings in the GUI application.
Replace server/farm address radio buttons with browser address and browser protocol fields.
2.11
Replace server/farm address radio buttons with browser address and browser protocol fields.
December
2006
Note: Minimum screen resolution for the macro recorder is 1280 x 1024 pixels.
2.10
Fixed missing connect function in the macro.
GA
November
2006
GA
September
2006
GA
July 2006
Fixed a timing glitch between connect event and macro start.

Note: Minimum screen resolution for the macro recorder is 1280 x 1024 pixels.
Fixed a connect failed alarm bug.
2.08
Fixed bugs in the macro functionality.

Fixed version reporting in the GUI and logfile.
2.07
Fixed missing connect_response alarm.

Fixed a bug in the compare algorithm.
Added possibility to select start point for the macro.
Fixed Object Not Set error when a macro is loaded from a file, and "Play step" button is pushed.
Fixed a bug when a published application is selected in combination with a server address.
Fixed send QoS and alarms when a session timed out occurs. The QoS and alarms will now be sent immediately when
they are available.
2.05
Default QoS configuration turned off in default profile and 'Template profile'.
GA
June 2006
GA
December
2004
Removed '$profile:' from concurrent sessions messages in messagepool.

Added removal of Status directory when you delete the probe.
Added probe unregister when the probe terminates.
Added validation of profile id in ica_response_poll.exe command line.
Fixed unexpected deletion of alarm settings.
Fixed Save QoS bug and Save Connect timeout in the probe configuration.
Fixed problem with Kill process failed. Exception: Index was outside the bounds of the array.
Added text to describe which machine is being browsed in the file browser dialog.
Added profile names in clear messages.
Added profile id -1 as default profile. This profile is invisible in configuration, but can be edited with Raw configure.
Fixed unexpected exception when Nimbus.dll was not found.
Fixed send mouse events bug.
Fixed memory leak problem when a session timeout occurs. Wfica32.exe was not terminated.
Added configuration options: Select farm or server address. configuration options: Published application logoff delay.
Changed client name on the ICA Client Object to use the client name from the probe machine.
Fixed Run-time error '380' problem, when the probe configuration was minimized.
Fixed connect to farm problem in the probe configuration.
Note: It is strongly recommended to manually replace the messagepool section in .cfg file, with the messagepool section
from .cfx file.
1.75
Support for configuration through a tunnel.
Prerequisites
The Citrix Client Response Monitoring probe requires one of the following Citrix client software:
For Desktop Client:
Citrix Receiver 14.1.X or later
or
CitrixOnlinePluginFull File Version 12.3 is installed on client system.
For Web Client:
CitrixOnlinePluginWeb File Version 12.3 is installed on client system.
Notes:
If the IM and Robot are installed on two different systems, then the Citrix client software is installed on both the systems.
The same version of Citrix Receiver or Citrix Plugin should be present at both places: where the probe is installed and where
the probe GUI has to be opened.

The ica_response probe should be installed on systems with the following minimum resources:
Memory: 2-4 GB of RAM. Probe's OOB configuration requires 256 MB of RAM.
CPU: 3 GHz dual-core processor, 32-bit or 64-bit.
The ica_response probe requires the following software environment:

One of the following Citrix client software:
For Desktop Client:
Citrix Receiver 4.1.X or later
CitrixOnlinePluginFull File Version 12.3 is installed on client system
For Web Client:
CitrixOnlinePluginWeb File Version 12.3 is installed on client system.
Note: If the IM and Robot are installed on two different systems, then the Citrix ICA Client or Citrix Receiver must be installed on both
the systems.
Known Issues
There is an issue with Citrix Receiver due to which the server connect process hangs sometimes. The probe handles this situation by
automatically killing the Receiver processes in background. As a result of this, you might get an error message pop-up for Citrix Receiver
on the machine where the probe is installed. You are recommended to ignore the pop-up by clicking OK.
icmp (Internet Control Message Protocol) Release Notes

The Internet Control Message Protocol (icmp) probe tests network connectivity using echo request/response messages and generates Quality of
Service (QoS) messages based on the response data. The probe can monitor up to 50,000 resources in 5 minutes.
Contents
Revision History
Adjust icmp Memory
Revision History
This section describes the history of the revisions for the icmp probe.
Version
Description
State
Date
1.2
What's New:
GA
December
2014
GA
May 2014
GA
May 2014
Added the ability to create monitoring configuration templates. These templates allow you to apply consistent monitoring
configurations across multiple devices by using filters.
Added discovery filters to control the list of devices that are retrieved from the discovery server which governs the
available monitoring targets that appear under the Profiles node.
1.1
What's New:
Added the Apply Filter functionality to view a particular resource from existing resources.
Added the Static Alarm Thresholds option to let the user set static thresholds for particular monitor.
1.0

Memory: 2 GB for 50000 resources.
CPU: 2.13-GHz dual-core processor, 64-bit.

The icmp probe is used to monitor network devices.
Note: It is recommended that the CA Unified Infrastructure Management server and Unified Management Portal (UMP) are the same
version but not required.
Probe v1.2 requires:

CA Unified Infrastructure Management server version 8.1 or later installed on the primary hub.
CA Unified Infrastructure Management discovery_server is running on the primary hub
alarm_enrichment v4.6 and nas v4.6 probes are running on each hub with a robot running the icmp probe
prediction_engine v1.0 or later is running on each hub with a robot running the icmp probe
ppm v3.0 probe must be running on each hub with a robot running the icmp probe.
CA Unified Infrastructure Management Unified Management Portal (UMP)
Adjust icmp Memory

The memory and disk requirements for the icmp probe can vary according to the number of network devices you want to monitor in your
environment. You might need to adjust the Xms and/or Xmx memory depending on the number of devices you are monitoring.
Follow these steps:
1. Open Raw Configure for the icmp probe.
2. Go to the Startup tab and click the Options key value.
By default, the key value is -Xms32m -Xmx2048m -XX:MaxNewSize=716177408 -XX:+UseParallelOldGC.
3. Change the argument -Xms32m so that the number following Xms indicates the minimum RAM (in megabytes) the probe requires to
execute. For example, if the probe will be monitoring less than 50000 devices, then you can reduce the number from 32 megabytes to a
lesser value.
4. Change the argument -Xmx2048m so that the number following Xmx is the maximum amount of memory in megabytes consumed by the
probe.
For example, if the probe is monitoring 10000 resources, then you can modify the key value to use only 1 GB of your total system RAM
(-Xms32m-Xmx1024m-XX:MaxNewSize=357910446-XX:+UseParallelOldGC).
5. Click Apply and close Raw Configure.
6. Restart the icmp probe.
The icmp probe is downloaded and installed just like other CA Unified Infrastructure Management probes by downloading the probe from the
Internet Archive into your local Archive.
After you download the probe to your local Archive, you only need to install (drag from the Archive to the Robot) the icmp probe.
Note: On Linux/Unix systems the /etc/hosts file should contain an entry with the FQDN for the installation system.

This section describes the known issues and workarounds, if any, for the icmp probe.
Probes Required for Alarm Settings
Template Requires a Host Filter and an ICMP Filter
Discovery Server Cannot Complete Discovery
Probes Required for Alarm Settings

Problem:
I do not see all the alarm settings while trying to configure the monitoring settings for a template or an individual device profile.
Solution:
Verify that the following probes are running on each hub with a robot running the icmp probe:
ppm v3.0
alarm_enrichment v4.6 and nas v4.6
prediction_engine v1.0 or later
Template Requires a Host Filter and an ICMP Filter

Problem:
I inadvertently deleted the Host Auto Filter and now I receive an error message when I attempt to access a template.
Solution:
At least one host filter and icmp filter must exist for each template. If you delete one of these filters and save your changes, the template is no
longer acceptable. Delete the template and create a new one.
Discovery Server Cannot Complete Discovery

Problem:
While defining a New Range Scope on the Scopes tab in the Discovery Wizard, you cannot enter a range of subnets that is greater than /16
(such as /8). Discovery Server cannot perform the discovery if you enter subnets greater than /16.
Solution:
Discovery supports subnets with CIDR notation numbers of /16 or larger only. Entering range scopes larger than 65,536 addresses when defining
a discovery range may create an out of memory condition. Discovery server is not able to support the large number of subnets that get returned.
iis (IIS Server Monitoring) Release Notes

The IIS Server Monitoring (iis) probe for Internet Information Servers performs HTTP GET queries to the selected Microsoft IIS servers. The probe
then transforms the query result into alarms and/or quality of service for SLA purposes.
Monitors IIS http response times
Supports a DLL add-on for server-side monitoring of individual requested resources, and displays running and statistical data.
Can display hanging and problematic IIS scripts.
Delivers a variety of system-related and IIS-related performance data.
Custom OS monitoring objects can be set.
Can deliver server side status data when installed to the IIS server machine.
Can monitor application pools.
Contents
Revision History
Supported Platforms
Installation Notes
Installation Notes for IISRequest.dll
Installing ISAPI filter on a 64-bit OS
Activating the ASP Counters on IIS 7 or above
Installing Metabase Compatibility Component on IIS 7 or above
Notes on IISRequest.dll
ISAPI Filter on a 64-bit OS
Activating ASP Counters on IIS 7 or Above
Metabase Compatibility Support on IIS 7 or Above
Revision History
Version
Description
State
Date
1.71
What's New:
GA
June
2015
GA
Jun
2014
The probe can be migrated to standard static thresholds using the threshold_migrator probe.
Added a new device ID key (useRobotDevIDForLocalhost). This key can be set as Yes to migrate the probe to standard
static thresholds. This option is available only through Raw Configuration GUI to monitor local IIS servers. The value of this
key is No by default.
Note: Refer to Set Device ID Key Using Raw Configure section in the v1.7 iis AC Configuration article for the impact of
setting this key value.
1.70
What's New:
Added support for monitoring application pools. Perfmon 1.53 or later is required for this functionality.
Note: The Application Pool monitoring feature is applicable for IIS 7.0 or later.
1.60
Added 64 bit support.
Nov
2013
1.55
Added Probe Defaults for remote servers also.
Jun
2013
1.54
Implemented Probe defaults, which works only when the probe is deployed on IIS server machine.
Updated copyright information.
Feb
2013
1.53
Fixed issue of run time GUI crash while uncheck monitoring of checkpoint.
Jan
2013
1.52
SOC Support Added
Dec
2011
1.51
Added support for "IIS Status Value"; having multiple IPs on the host
Aug
2011
1.50
Added support of filterport on per-host basis

Added support to define the severity of alerts
Added support for IIS7.5
Removed printing password from log file
Added support for reading alarm tokens from cfg
Dec
2010
1.40
Oct
25
2010
1.32
Fixed memory management issue
Oct
19
2010
1.31
Changes to libraries with respect to configuration locking.
Oct
14
2010
1.30
Jun
2010
1.30
Mar
2010
1.24
Fixed Server data (requests) not shown after adding ISAPI Filter.
Fixed potential probe crashing issues.
Fixed initialization of curl library.
Fixed initialization of variables
Sep
30
2009
1.22
Collect data also when perfmon is not available.

Updated status of host in GUI when IIS server is not reachable.
Updated logging.
Removed limitation on portnumber in the isapi filter.
Sep 4
2008
1.21
QoS and Alarm source for 'localhost' profiles changed to actual host name.
Monitoring interval defaults to profile interval instead of global probe interval.
Changed QoS series name for disk and memory usage because of inconsistencies with QoS data supplied by the 'cdm' probe.
Server side DLL add on now available for 64 bits versions of Windows. IIS6 no longer need to be run in IIS 5.0 isolation mode.
The DLL is now available for 32 and 64 bits versions of Windows Vista, with IIS7.
Jan
2008
1.12
Added keyword 'localhost' for hostname, will cause performance collection without authentication.
Added possibility of setting IIS filter port number in cfg file.
Added support for all custom performance objects
Changed key separator from . to ,
Feature: Http server authentication added.
Fix: Removed ptPerfmonInstances call.
QoS definition fix (IIS)
Jul
2007
1.00
Initial version
Oct
2006

The probe (version 1.71 and later) threshold configurations can be migrated to standard static alarm thresholds using the threshold_migrator
probe. Refer to the threshold_migrator probe document for information on how to migrate a probe.
Notes:
If you want to migrate the probe to standard static thresholds for local IIS servers, using the threshold_migrator probe, you
must set the device ID key, useRobotDevIDForLocalhost, to yes in the probe Raw Configuration.
The Infrastructure Manager (IM) GUI of the probe will not be available and the probe will only be configured using Admin
Console (AC).
Probe specific alarm configurations in the probe monitors will be replaced by Static alarm, Time To Threshold, and Time
Over Threshold configurations.

The iis probe should be installed on systems with the following minimum resources:

The iis probe requires the following software environment:
CA Unified Infrastructure Management Server version 7.5 to 7.6 or CA Unified Infrastructure Management 8.0 or later
Java JRE 6 or later
Performance Collector probe (perfmon) 1.18 or later, and 1.53 or later for monitoring application pools.
The iis probe requires the following software environment to migrate with threshold migrator probe:
Supported Platforms
Installation Notes
You can install the IIS Server Monitoring probe for monitoring the IIS server while considering the following points:
Provide admin access to the probe in Admin Console by using the Settings > Probe Security option.
Alternatively, use the Security > Probe Administration option in the Infrastructure Manager.
Restart the Performance Collector probe after installing or upgrading the IIS Server Monitoring probe.
Use the 'localhost' as the hostname for monitoring the local IIS server to skip the performance authentication.
Ensure that the remote registry is enabled on the IIS server for remote monitoring.
Installation Notes for IISRequest.dll

The IISRequest.dll is an ISAPI filter add-on for the IIS server and used by the IIS Server Monitoring probe. This add-on supports several versions
of the IIS server and Operating Systems. You can go through the readme.txt file for supported versions and for details about how to add this
functionality. The readme.txt is available at Nimsoft Installation Directory > Nimsoft > Applications > iis location.
Installing ISAPI filter on a 64-bit OS

If the IIS web server is running on a 64-bit version of Windows, the IISRequestNM64.dll or IISRequest64.dll library file is used. You must have the
Microsoft Visual C++ 2005 Redistributable Package on the server running IIS (web server, not probe). You can download this Microsoft Visual
C++ 2005 Redistributable Package from the following link:
http://www.microsoft.com/downloads/details.aspx?familyid=90548130-4468-4BBC-9673-D6ACABD5D13B&displaylang=en
Activating the ASP Counters on IIS 7 or above
Refer to the following link: http://www.iis.net/ConfigReference/system.webServer/isapiFilters
Installing Metabase Compatibility Component on IIS 7 or above

The IIS Server Monitoring probe displays a wrong status when monitoring local IIS 7 server. The probe requires the Metabase Compatibility
component for displaying correct status which is not available on IIS 7, by default. Refer to the following link for installing this component:
http://www.iis.net/learn/manage/managing-your-configuration-settings/metabase-compatibility-with-iis-7-and-above
3. Add IIS probe in Infrastructure manager, security, probe administration with admin access and * mask.
4. A restart of the perfmon probe is needed if this was an IIS probe upgrade, and perfmon still has handles running.
5. If there are authentication problems, and if the IIS probe is running locally on the IIS server computer, you can use 'localhost' as the
profiles hostname to skip performance authentication.
6. Double-click the probe for initial configuration.
7. For remote monitoring, make sure that the remote registry is enabled on the IIS server.
Notes on IISRequest.dll
IISRequest.dll is the iis ISAPI filter add-on for iis probe.
The iis probe request add-on supports several versions of the IIS server and Operating Systems. After probe installation, a readme.txt will
typically be found in the C:\Program Files\Nimsoft\Applications\iis directory. Please see the readme.txt file for supported versions, and how to add
this functionality.
ISAPI Filter on a 64-bit OS

If the IIS web server is running on a 64-bit version of Windows, the IISRequestNM64.dll or IISRequest64.dll should be used as described in the
readme.txt the is installed with the probe. It is also necessary to have the Microsoft Visual C++ 2005 Redistributable Package installed on the
server running IIS (web server, not probe). The link to download this package is:
http://www.microsoft.com/downloads/details.aspx?familyid=90548130-4468-4BBC-9673-D6ACABD5D13B&displaylang=en
Activating ASP Counters on IIS 7 or Above

Please refer to the following link:
http://www.iis.net/ConfigReference/system.webServer/isapiFilters
Metabase Compatibility Support on IIS 7 or Above

The probe shows the wrong status for the IIS 7 local server. It shows "IIS is not on local server."
To get the correct status, the probe requires Metabase which by default is disabled on an IIS 7 server. To install it follow the instructions included
in this link:
http://www.iis.net/learn/manage/managing-your-configuration-settings/metabase-compatibility-with-iis-7-and-above
interface_traffic (Interface Traffic Monitoring) Release Notes

The Interface Traffic Monitoring (interface_traffic) probe monitors network traffic on SNMP agents using standard MIB-II queries. The probe
queries the SNMP agent on the defined host for interface traffic data. The probe uses a combination of SNMPGet requests in predefined
intervals. This period is calculated as the interval * number of samples. You can define a warning threshold and a critical threshold.
The probe can monitor one or more interfaces for traffic congestion and inactive interfaces. The probe can be configured to monitor the network
interface on a Windows or UNIX systems, or router or switch. The probe then reports whenever the traffic breaches a predefined threshold. The
probe also supports Quality of Service (QoS) messages for the Service Level Agreement (SLA) family.
Note: Probes that support SNMP on Linux (interface_traffic, snmptd, and snmpget) use an SNMP library. This library can cause newer
Linux systems to issue the following message in the Linux console log:
process interface_traff is using obsolete setsockopt SO_BSDCOMP

AT
The SNMP library supports older versions of glibc which require the flag for sockets to work correctly. The network portion of the glibc
library sends this message. The message shows that an unsupported flag is being sent to the setsockopt function. The library ignores
this flag so you can also ignore it.
Contents
Revision History
Revision History
This section describes the history of the revisions for interface_traffic probe.
Version
Description
State
Date
5.45
Fixed Defects:
GA
October
2015
GA
July 2015
GA
April 2015
The probe generated false alarms for the operational state of interface. Salesforce cases 70000904, 70000825
The probe used the default values instead of the specified timeout and retry values in a profile. Salesforce case
00168659
The probe incorrectly calculated the current percentage of interface errors when monitoring errors and discarded
packets. A key, incerrdistototal, has been added in Raw Configuration to calculate this value correctly. Salesforce case
00159962
Note: For more information about this key, see the interface_traffic Troubleshooting article.
5.44
Fixed Defects:
Incorrect utilization was displayed for some interfaces. Salesforce case 00152619
Probe crashed when editing virtual interfaces. Salesforce case: 00162089
Incorrect alarm displayed for IndexShift in USM. Salesforce case: 00161338
5.43
What's New:
Added support for pure IPv6.
Fixed Defects:
Fixed an issue in which the probe did not save multiple changes to an existing interface. Salesforce case 00157651
Improved the formula to remove negative values of QoS/alarm. Salesforce case 00145339
Fixed an issue in which the probe was displaying the default name in the alarm message and not the updated one. Sale
5.42
Fixed Defects:
GA
January
2015
GA
August
2014
GA
June 2014
GA
September
2013
GA
July 2013
GA
March
2013
GA
March
2013
GA
December
2012
GA
December
2012
GA
September
2012
GA
September
2012
Fixed an issue in which, when the probe was configured to use the host address as the QoS identifier instead of profile,
the metrics were generated using the profile name as the QoS identifier. Salesforce case 00148492
Incorrect percentage was calculated for the alarm messages. Salesforce case 00145415
Enhanced the logsize upper limit to 2 GB. Salesforce case 00150857
5.41
Added a functionality to display the interface description in the Name column and interface alias in the Description column on
the probe GUI. The feature also gets the interface description as QoS target in SLM database and USM view (like version
5.32) along with SNMP_v3 support. Salesforce case 00129782
Note: Refer to the Considerations section to understand the upgrade scenarios.
5.40
Added a functionality in the probe to avoid the issue of getting different entries in SLM and different graphs for the same
interface. This issue was identified while upgrading from version 5.32 to version 5.33. Salesforce case 00122371
Note: On upgrading the probe from version 5.33 to version 5.40, for backward compatibility with version 5.33 behavior which
uses ifname value instead of ifdescription value on SLM, you must uncheck the Use IfDescription for CI Name check box. By
default, this checkbox is enabled.
Fixed a defect were the clear alarm token is changed from #network.interface_traffic.in_octets_fail to
#network.interface_traffic.in_octets_ok. (Salesforce Case: 00125910)
5.33
Fixed: An issue where $ifDescr is returning $ifName value.

Fixed: Wrong interface_traffic into USM
Fixed: SNMP_v3 Authentication issue
5.32
Added issue related Network devices show up twice for cisco_monitor and interface_traffic.
Fixed: Major issue the alert for lower threshold value in traffic tab got disabled, for all the interfaces while upgrading.
Fixed: RunTime Overflow Error "6". Fixed minor issues in SOC conguration.
5.31
Fixed issue in negative value of interface traffic QoS data.

Fixed issue in Check Data Integrity - message dropped; samplemax found in data comes while inserting QoS into
database.
5.30
Added a feature to break non-unicast packets to multicast and broadcast packets.

Added a feature to add the single threshold.
Added a feature to send alarm only once if interface is down or unavailable.
Fixed: Actions that are prevented are implied by an error dialog.
Fixed: Issue in adding devices in bulk in interface_traffic probe.
Added a feature to check the interface speed periodically.
Added a feature to send clear alarm if the interface is removed from monitoring.
Ability to add the interface name, description, or user-defined name for QoS target and QoS source.
Added a feature to configure extreme alarm messages and severity from GUI.
Added a feature to add a profile even if the SNMP query fails.
Added a feature to specify default settings for interface name (with regexp functionality) and/or interface speed.
5.26
5.25
Fixed an issue where $ifDescr and $ifName values are not correct in Dr.Nimbus.
Changed from "Using Both values and % of the maximum speed" to "Using Bytes/second and % of maximum speed".
Unchecking Include Alarm/Qos settings still save the settings.
5.24
Community strings are not encrypted on selecting Encrypt community string in Setup >Advanced tab.
Save inactive interface definitions check box has no effect.
Set Default from Interface do not save for Default General
5.23
Fixed the problem of highlighting Send alarm option(after unchecking Enable Monitoring). The newly added profile now
has all the default settings.
Fixed UMP configuration issues.
5.22
Fixed QOS Issue which was not shown enabled on GUI.
GA
August
2012
5.21
Added functionality to ignore alarms when interface op state is down/not present/lower layer down.
GA
July 2012
5.20
Fixed a defect "maxspeed(ifSpeed) cannot be determined" false alarm.
GA
June 2012
GA
March 27
2012
GA
March 16
2012
GA
December
2011
GA
October
2011
GA
April 2011
Added a callback get_profile_status which accepts regular expressions in profile name and returns information of all the
active profiles matched and it's interfaces.
Added support to AIX for 64 bit.
Fixed "Temporarily out of resources" issue in get_system_info callback.
Added functionality to ignore operational state alarms when admin state of an interface is not as expected.
Removed autocold start of probe after 1 week in Unix like OS.
GUI fix: QoS Settings for Interface Traffic are not saved when Publish QoS is not active.
GUI fix: Cannot clear Low or High Threshold values on traffic tab.
5.11
GUI fix: Added a functionality to remove the inactive interfaces from the list.
Number of interfaces are now showing the actual number of interfaces displayed in the list of a particular host.
The help button will now display online help instead of CHM.
5.10
GUI fix: Added a functionality to save Alarm / QoS settings for inactive interfaces.
Added interfaces multi-edit functionality on right click.
Added the functionality to apply the default settings when they are saved using Set Default button in the interface
definition dialog box.
5.01
Implementation of IPv6 Compatibility.

Snmp query related bugs fixes.
Updated libraries.
5.00
Implementation for IPv6 Compatibility.

Snmp query related bugs fixed.
4.95
Fixed "No traffic" threshold.

(The "No traffic" threshold was in previous versions erroneously compared to the "% of max speed" value, if other traffic
alarms were specified in "% of max speed").
4.94
Fixes for Service Oriented Configuration (SOC).
GA
March
2011
4.93
GA
January
2011
4.92
Fixed get_samples callback (The issue was that GUI was not able to fetch samples from probe on 64-bit UNIX Robots).
GA
January
2011
GA
December
2010
4.91
Added support for handling of extreme values in Error and Discarded Packets section.
Fixed minor bugs in the probe GUI.
4.90
Added new feature for handling of extreme values in Traffic and Processed Packets section. Added fix to make "does
not exist in the MIB" alarm message configurable.
GA
December
2010
GA
November
2010
GA
June 2010
GA
January
2010
GA
January
2010
GA
December
2009
GA
July 2009
GA
June 2009
GA
April 2009
GA
April 2009
GA
November
2008
GA
May 2008
Added support to specify the traffic limit required to trigger "No Traffic" alarm.
Added support to monitor (Alarm and QoS) Error packets and Discarded packets as percentage (%) of total processed
packets.
Added fix to allow one threshold value (both thresholds not mandatory now) in Traffic section.
Added support for a callback to get total number of active and inactive interfaces..
Added support for all known interface operational status (total 7 as per IF-MIB).
Added code to remove white space from all sections.
Added fix in alarm threshold field to show the correct value.
Added fix to avoid reloading of host profiles in the tree on expanding the group.
Added fix to uncheck 'alarm when no traffic is detected' checkbox on unchecking 'Enable Monitoring' checkbox of
'Traffic' tab.
Added fix to set interface speed after every interval of timer.
Added support for SNMP V2 and V3 credential details to perform bulk discovery.
Added option in bulk configuration window to remap interfaces after an index shift.
Added code to allow decimal numbers in threshold fields of 'Traffic' tab.
Added a checkbox 'Send QoS in Kbps' in Setup tab.
Added button in toolbar to execute interface status callback.
4.80

Increased SNMPWalk limitation from 300 to 3000 entries (added key /setup/max_oids in config file).
Support for Web based Service Oriented Configuration (SOC).
4.70
4.64
Fixed occasional crash situation.

Fixed probe restart when monitoring number of interfaces.
Fixed potential probe restart situation.
4.62
Fixed memory leak. (Introduced in version 4.60).

Fixed probe restart when the profile has no active interfaces configured and probe tries to send clear alarm.
4.60
4.52

Always send QoS of interface traffic as Bytes/second in addition to kbit/second. This is due to other Nimsoft components
requiring the Bytes/second dataseries.
You may disable the above functionality (if you know that Bytes/sec is not needed) by adding the following configuration
key using Raw Configure: /setup/only_kbits = 1.
4.51
4.50
Fix potential program failure when using "Monitor" interface.

Added Alarm/QoS options on interface administrative status.
Added option of sending QoS messages on interface traffic in kbit/sec.
Fixed use of alarm severity other than 'major' on "Processed Packets" alarms.
Added support for x64 Windows platform.
Added support for 64bit platforms on SOLARIS, LINUX.
Added support for LINUX on 64bit PowerPC (glibc = 2.3).
Discontinued support for Solaris 2.5, 2.6 and 7.
4.40
4.36
Added support for "Virtual Interfaces".

Changed interface checksums to MD5.
Added utility "Generate Checksums" (update checksums on multiple profiles).
4.35
Fixed "No Traffic" alarm when ifSpeed is unknown.

Added alarm when ifSpeed is unknown and probe is configured to alarm on Traffic in % of ifSpeed
Fixed remapping of interfaces where ifName is used instead of ifDescr.
4.34
Fixed 'Rediscover Interfaces' and 'Query Agent' for SNMPv3 AuthPriv agents.
GA
April 2008
GA
March
2008
GA
October
2007
GA
September
2007
GA
September
2007
GA
March
2006
GA
May 2005
Fixed fetching of operstate on inactive (in probe config) interfaces for SNMPv3 AuthPriv agents.
Fixed 'Monitor' window for SNMPv3 AuthPriv agents. Added logging of thread id's.
4.32
Added critical sections around SNMPQueryCreate if SNMPv3

Added terminating -1 to SNMPQueryCreate.
Added platforms (missing in v4.30) LINUX and SOLARIS 8,9,10 (sparc).
Added support for privacy (SNMPv3).
Added SNMPv3 support in "bulk-configure".
Added SNMPv3 support in "add-range".
Fixed saving of default interface definitions.
Updated libraries.
4.25
Fixed saving of Defaults.

Updated libraries.
4.23
4.22
Fix: Do not save alarm and QoS settings of inactive interfaces (when inactive interfaces are set to be saved) Fixed fetching of
operstate on inactive interfaces when using SNMPv3.
Fixed fetching of High Performance counters when using SNMPv1 (bug introduced in version 4.20)
Added support for SNMPv2c and SNMPv3.
Added retries setting for SNMP Get requests.
Added timeout setting for SNMP Get requests.
Fixed community string issue when longer than 20 characters.
Improved Message Pool Manager to handle SubsystemIds.
Added possibility to send Traffic QoS messages as % of max interface speed.
Added possibility to send Packet QoS messages as total packets counted.
Added possibility to set default interface settings per interface type.
Added possibility to override outbound and inbound speeds.
Added possibility to hide community strings from GUI.
Added NoTraffic on 'Any interface' alarm option.
Rediscover/Merge has been enhanced with UI feedback when interfaces has different names than configured.
Fixed samplemax on Traffic QoS messages when no traffic was detected on interface.
Fixed bulk-configurator.
Fixed alarm not being sent when configured to alarm in UP state.
Fixed dashboard filter settings.
Dashboard discovery template enhanced to use 'friendly' names of devices and interfaces.
4.12
Fixed update problems with the uptime variable in 'get_samples' command.

Fixed default interface settings to keep the 'unit' variable.
Added $group as a variable to be used in the message pool.
Added support for a user defined text per interface ($user1).
4.02
Added NULL QoS values for traffic metrics when interface was reported 'down'.
Added support for more operational states.
Fixed problem when configuring probe through a NimBUS tunnel.

The interface_traffic probe should be installed on systems with the following minimum resources:
The interface_traffic probe requires the following software environment:

The target SNMP agent must support the MIB-II ifTable.
Notes:
For SOC functionality, server 5.6 or later and UMP 2.5.2 or later is required.
SNMP v3 requires that your network community strings are at least 8 characters long.
This section contains the considerations for the interface_traffic probe.
Starting with version 5.43, the probe supports IPv6. The probe must be deployed in pure IPv6 environment to monitor IPv6 interfaces.
The Setup window in version 5.41 or later version of the probe has the Use IfDescription for CI Name and Use Alias checkboxes. You
must consider the following scenarios for these checkboxes:
Use
IfDescription
for CI Name
Use
Alias
Functionality
Not Selected
Not
Selected
The probe GUI displays the interface name in the Name column and interface description in the Description colum
n. The interface name is visible as the QoS target in USM view and SLM database. The current version of the
probe will function as version 5.33 of the probe.
Selected
Not
Selected
If you have upgraded from a previous version, the settings of the previous version remain intact until you
rediscover the interfaces. After you rediscover the interfaces, the default settings of version 5.41 or later are
applied.
The probe GUI displays the interface name in the Name column and interface description in the Description colum
n. However, the interface description is visible as the QoS target in USM view and SLM database. This is the
default configuration in version 5.41 or later.
Not Selected
Selected
The probe GUI displays the interface description in the Name column and interface alias in the Description colum
n (like version 5.32). The interface name is visible as the QoS target in USM view and SLM database (like version
5.33) along with SNMPV3 support. Hence, it is not recommended to select only the Use Alias option.
Selected
Selected
The probe GUI displays the interface description in the Name column and interface alias in the Description colum
n. The interface description is visible as the QoS target in USM view and SLM database (like version 5.32) along
with SNMP_v3 support.

Before configuring a template on UMP, please ensure that probe is deployed on the robot.
This issue relates to the name of the interface in the alarm message.
The probe was displaying the default name of the interface in the alarm message, even after the the name has been manually updated.
The ifName(default name) of the interface cannot be altered. In order to view the updated name in the alarm message, use '$name' vari
able .
This issue relates to profiles (devices) added to interface_traffic before v4.35:
A problem regarding automatic re-mapping of indexes after an index shift has been detected on devices that use ifName (from ifXTable)
instead of ifDescr as interface name(s). In order for the probe to operate properly (if an index shift occurs), a "Rediscover Interfaces"
(available in the probe GUI) should be issued to generate new checksums of interface names.If ifDescr is not unique on the device and
ifName contains only 1 character (i.e. "1") as the name for an interface, it could lead to false "interface index change" alarms. The
workaround is to set ifName on the affected interface(s) to a string with at least 2 characters, and then do a "Rediscover Interfaces" from
the probe GUI.
The following issue is identified in version 5.32:

The probe GUI displayed the interface description in the Name column and interface alias in the Description column. This issue is
resolved in version 5.33 where the interface name is displayed in the Name column and interface description is displayed in the Descript
ion column.
The following issue is identified in version 5.33:
For the same interface, there were different entries in the SLM database and different USM graphs. The workaround is that a check box
Use IfDescription for CI Name is added in the General Setup tab in version 5.40.
jdbc_response (Java Database Connectivity SQL Queries Response Monitoring) Release

Notes
The Java Database Connectivity SQL Queries Response Monitoring (jdbc_response) probe monitors the connection to the JDBC database.The
probe executes custom SQL queries to the database servers through the JDBC client interface and measures the response time.
The probe currently supports monitoring SQL queries on the following databases:
Microsoft SQL Server
MySQL
Oracle
PostgreSQL
From version 1.2 onwards, the probe also supports:
IBM DB2
IBM Informix
Contents
Revision History
Revision History
This section describes the history of the revisions for the jdbc_response probe.
Version
Description
State
Date
1.23
Fixed Defects:
GA
December
2015
GA
April 2015
Probe created new connections with the spooler without closing them. Support case number 246871
Probe was unable to create a connection to the database. Support case number 246114
Note: If you still face any issues with the connection, see Unable to Create JDBC Connection .
Response time QoS was in increasing order. To address this issue, a new key, exclude_connection_time is
introduced in the probe configuration file. Use Raw Configuration to set the value of this key to yes. Salesforce case
246886
1.22
Fixed a defect in which the probe did not generate any QoS data on the Linux systems even though the alarms were
triggered. Salesforce case 00158270
1.21
Fixed a defect in which the connection error alarm did not clear after the connection is successfully established. Salesforce
case 00150260
GA
January
2015
1.20
Upgraded the probe to support IBM DB2 and IBM Informix databases.
GA
September
2014
Provided Source Override option to allow users to provide their own QoS source instead of using the default source. Salesfor
ce case 00141979
1.15
Upgraded the probe to support PostgreSQL database for monitoring.
GA
January
2014
1.14
Fixed Defects:
GA
December
2013
GA
June 2012
Implementation of Device ID and Metric ID for QoS and Alarms.

Probe is supporting proxy mode.
1.12
Fixed SOC issues for Password Added clear alarm for connection error.
1.11
Fixed Defects:
March
2012
Provided a fix to ensure that each profile runs at a specified time interval.
Provided a fix to ensure that Alarms and QoS are generated as per Jdbc Response time.
Provided a fix for Clear alarms to be generated on selection of Clear Severity for Jdbc Response Time , Jdbc Row
Count and Jdbc Value.
Provided a fix to remove default Sample Connection and Sample Profile
Provided a fix to generate Sample Rate in QoS messages
Provided a fix to change QoS target in database as profile name and connection name
1.10
Fixed Defects:
GA
February
2012
Provided a fix to ensure that each profile runs at a specified time interval.
Provided a fix to ensure that Alarms and QoS are generated as per Jdbc Response time.
Provided a fix for Clear alarms to be generated on selection of Clear Severity for Jdbc Response Time, Jdbc Row Count
and Jdbc Value.
Provided a fix to remove default Sample Connection and Sample Profile.
1.05
Fixed SOC issues.
GA
December
2011
1.02
Source added to profile.
GA
December
2009
1.01
Initial release.
GA
September
2009
Beta
September
2009
Please note that the QoS names have been changed since the Beta version as follows:
The QoS definitions have been changed from QOS_SQL_RESPONSE, QOS_SQL_ROWS, and QOS_SQL_VALUE to
QOS_JDBC_RESPONSE, QOS_JDBC_ROWS, and QOS_JDBC_VALUE
1.00
Initial BETA build.

The jdbc_response probe should be installed on systems with the following minimum resources:

The jdbc_response probe requires the following software environment:
Robot version 7.6 or later (recommended)
Probe Provisioning Manager (PPM) version 2.38 or later (required for Admin Console)
The jdbc_response probe, by default, installs the JDBC drivers for Microsoft SQL Server and Oracle databases. To monitor other databases, the
appropriate driver, as a JAR file, must be downloaded and stored on a system from where the probe can access it.
For making connections and running SQL queries, a User name and Password is required for the databases being monitored.
Download the drivers for the following databases and store at the default location of the driver files. The default location of the JDBC driver JAR
file is [CA UIM Installation Directory] \probes\database\jdbc_response\lib folder.
IBM DB2: Download the latest version of IBM DB2 JDBC driver JAR file from http://www-01.ibm.com/software/data/db2/linux-unix-windo
ws/downloads.html
IBM Informix: Search for and download the latest version of IBM Informix JDBC driver JAR file from http://www-01.ibm.com/software/
Note: You must register on the IBM website before you can download the IBM DB2 or IBM Informix driver JAR files.
MySQL: Download the latest version of MySQL JDBC driver JAR file from http://www.mysql.com/products/connector/
PostgreSQL: Download the latest version of PostgreSQL JDBC driver JAR file from http://jdbc.postgresql.org/
Important! Restart the probe after storing the driver files in the probe installation directory.
jdbcgtw (JDBC Gateway) Release Notes

The jdbcgtw probe is a gateway between CA Unified Infrastructure Management and a database. The probe reads data from tables using
user-defined SQL statements and posts messages and alarms on the CA Unified Infrastructure Management server. The probe can also monitor
database performance by running SQL queries and post QoS messages to the server with response time and number of rows returned by the
query. The jdbcgtw probe is similar to the adogtw probe, but uses JDBC to connect to the database rather than ADO.
Revision History
Version
Description
State
Date
1.04
Fixed Defect:
GA
April 2015
GA
July 2014
Fixed an issue in which the probe was not expanding the column names with string-numerical characters in alarm
messages. Salesforce case 00152463
1.03
Fixed Defect:
Fixed a defect in which the source was not overridden by Source of Sender.
1.02
Fixed Defects:
GA
May 2014
GA
January
2014
Beta
September
2010
The QoS definitions were getting generated after every elapsed time interval.
QoS and alarms were getting generated with incorrect DevID and MetID.
Runtime error was being thrown when a new connection profile was created with a name same as an existing
connection profile.
1.01
Fixed Defect:
Defect fixed for the query alarm message. The alarm messages were getting truncated after using a variable.
1.00

CA Unified Infrastructure Management Server 7.6 or CA Unified Infrastructure Management 8.0 or later
jobqs (iSeries Job Queues Monitoring) Release Notes

The iSeries Job Queues Monitoring (jobqs) probe monitors the job queues on IBM iSeries systems. The job queues are identified through
parameters such as queue name, library, and status. The probe generates alarm messages when specific jobs are running, not running, or
appear in a specific number of instances.
The probe allows you to perform the following tasks:
Track job queues to ensure that business processes are running smoothly, efficiently, and at the optimum time.
Diagnose and resolve issues related to job queues when these fail to run as expected.
Contents
Revision History
Revision History
Version
Description
State
Date
1.14
What's New:
GA
September 2015

1.13
Fixed an issue in which the same Metric Id/Metric Type Id was generated for different QoS.
GA
June 2014
1.12
Fixed issues with web-based Service Oriented Configuration
GA
January 2011
GA
Deember 2010
1.11
Adjusted QoS Definitions

1.01
Added New alarm and QoS metric functionality
GA
November 2010
GA
April 2009
GA
November 2007
Implemented support for Internationalization

Internal update: Modified to use nim library version 4.
1.05
Added support for extended record length in V6
1.04
Fixed alarm message list handling in the configurator

Turned off QoS in the example profile
Fixed configurator crash situation on profile edit
Fixed list positioning on profile edit
Added logging of information in the library list
Adds the library QGY to the library list
Additional logging added on log level 2 and 3
Initial release.


IBM iSeries (AS/400) 5.1 or above
jobs (iSeries Job Monitoring) Release Notes

The iSeries Job Monitoring (jobs) probe helps you monitor all jobs running in the IBM iSeries system. The jobs are identified through parameters
such as name, type, subtype, subsystem, and queue name. You can monitor if any given job is slowing down the system or is consuming
valuable system resources that a high-priority job requires for its execution. That is, you can monitor whether the job utilizes system resources
such as CPU usage, processing units, and memory units than that is expected.
The probe allows you to create and configure profiles for monitoring these jobs. You can also generate alarm messages when any given job has
failed to execute as planned. For example, you can generate alarm messages for jobs that are running, not running or appearing in a specific
number of instances in the system. The probe also supports the generation of quality of service (QoS) messages that are used for identifying the
performance issues occurred while executing the jobs. This helps you drill down to the cause that triggered the issue and take preventive
measures by scheduling the execution of jobs in such a way that the system resources are utilized efficiently.
Contents
Revision History
Revision History
This section describes the history of the revisions for the jobs probe.
Version
Description
State
Date
1.37
What's New:
GA
September 2015
GA
June 2011

Fixed Defects:
Probe configuration interface does not open after deployment in some instances. Salesforce case 00159214
1.3
Added quality of service message for IO request rate; added support for SOC.


The jobs probe can be deployed on a robot that is installed on the IBM iSeries systems. The probe requires the following software environment:
Nimsoft Monitor Server 7.5 to 7.6 or CA Unified Infrastructure Manager 8.0 or later
jobsched (iSeries Job Schedule Monitoring) Release Notes

The iSeries Job Schedule Monitoring probe monitors the scheduled jobs on IBM iSeries systems. The jobsched probe generates alarms and
quality of service (QoS) messages for the scheduled jobs in the following cases:
Unexpected status of the jobs
Failed scheduled jobs, or
Runtime of the scheduled jobs.
The probe also generates information about the scheduled jobs such as job name, job queue status, job creation date and job description.
Contents
Revision History
Revision History
Version
Description
State
Date
1.25
What's New:
GA
September
2015
GA
September
2014

1.24
What's New:
Added support for Static Alarm Thresholds.
Fixed Defects:
Fixed a defect where DevID and MetID are not matching for alarm and QoS.
1.23
Fixed problem with answer messages casuing probe crash
GA
August
2012
1.21
Added fixes to web-based Service Oriented Configuration
GA
January
2011
1.20
Modified behaviour for collection of QoS data: A QoS message should be sent only once for a completed schedule run
instead of on each probe interval
December
2010
Added new alarm and QoS metric functionality

Added support for Internationalization
Added support for Web-based Service Oriented Configuration (SOC)
Internal update: Modified to use nim library version 4
Added saving of jobs runtime, endtime and timemarker to config file to avoid repeated alarms at deactivate/activate.
1.17
Added alarm for too short execution time
GA
Updated documentation
Added resize of alarm message list
Various updates and fixes found during initial probe testing
New base library used
Initial version.
The preconfiguration requirements for the iSeries Job Schedule Monitoring for enabling Static Threshold Alarm is as follows:
Set "standard_static_threshold" key to "true" in Raw Configure.


The jobsched probe can be deployed on a robot that is installed on the IBM iSeries systems. The probe requires the following software
environment:
November
2007

journal (iSeries Journal Message Monitoring) Release Notes

The iSeries Journal Message Monitoring (journal) probe monitors the journal messages and journal files on the IBM iSeries system hosting the
probe. The probe allows you to configure specific journals for monitoring. The probe can generate alarms when the specified threshold conditions
are breached. For example, you can generate alarm messages when specific messages appear.
The Audit Journal (QAUDJRN in the QSYS library) is an example of a journal file monitored by the probe.
Contents
Revision History
Revision History
This section describes the history of the revisions for the probe.
Version
Description
State
Date
1.08
What's New:
GA
September
2015

1.07
GA
September
2014
1.06
Niscache usage fix
GA
January
2012
1.05
Support for raw_journal_code and raw_entry_type flags in the profile and test callback to allow matching against
encoded versions of these variables
March
2011
Advanced option in the profile dialog of the configuration tool to allow the raw journal code and entry type field values
Fixed GUI problem where profile dialog indicated changes even when there were none introduced in version 1.04
Added a 'Fetch' button and an 'Immediate fetch' option to determine if messages should be fetch immediately on journal
or time restriction selection. This setting is save together with window size and default journal/time restriction.
1.04
Replaced spaces with '_' characters in record field names

Added option to configuration tool to save current window size and default journal/time restriction
March
2011
Added additional fields in the message list for the encoded Journal code and Entry type fields
Made available the encoded Journal code and Entry type fields as 'JC' and 'ET' variables
Reduced the Entry type drop down list in the profile dialog to contain only entry types relevant for the selected Journal
code
Added tool tip to the Journal code and Entry type fields in the profile dialog to show the encoded field value.
1.03
Configuration tool improvements

Field layout lookup for data records from other files
Data field variables made available for alarm message use.

February
2011

Probe Provisioning Manager (PPM) probe version 2.38, or later (required for Admin Console)
jvm_monitor (Java Virtual Machine Monitoring) Release Notes

The Java Virtual Machine Monitoring (jvm_monitor) probe monitors CPU, threads, and memory usage on Java Virtual Machines (JVM). The probe
uses a Java Management Extension (JMX) connection to gather monitoring data from the java application server at customizable intervals. You
must set up the hosts and configure the application server to establish a JMX connection.
The probe uses Java MBeans to dynamically create monitors for a resource. You can configure the monitors to define alarms and QoS when any
unwanted events occur. The probe generates only numeric values in QoS messages.
Contents
Revision History
Installation Prerequisites
Verify Java
Verify Java on Unix System
Verify Java on Windows System
Known Issues
Revision History
This section describes the history of the revisions for the jvm_monitor probe.
Version
Description
State
Date
1.47
Fixed Defects:
GA
December
2015
GA
April 2014
GA
March
2014
QoS definitions were not configured when Auto Configuration was used to configure multiple profiles simultaneously. Su
pport case number 00162768
At alternate intervals, the probe generated the clear alarm for Key Not Found instead of the alarm that was configured
for threshold breach. Support case numbers 246676, 245746
The probe did not rotate the logs after the maximum log size was reached. Support case numbers 256320, 00149443
The probe displayed exponential notation for monitored values instead of the actual values. Support case number 2457
93
Updated a Known Issue where the probe does not display baseline and dynamic thresholds in monitors in CA UIM 8.31
or earlier. Support case number 246759
Updated value of max heap size in document. Support case number 00161358
Note: For more information about modifying the heap size, see jvm_monitor Troubleshooting.
Updated the jvm_monitor IM GUI Reference and metrics documents with information on the measuring units of
monitors. Salesforce case 00148759
1.46
Fixed Defect:
Fixed a defect in which no counter values were being displayed by live monitors.
1.45
What's New:
Fixed Defect:
Fixed an issue of communication error while fetching mbeans (minExceptions,host=localhost,path=/examples,
name3,host=localhost,path=/examples) of the Environment, Context node and their corresponding monitors.
1.44
Fixed the defect of not releasing the configuration file lock, when the Configuration file locking option is selected in the
controller probe. The probe is locking the configuration file permanently when accessed for the first time. User has to
restart the robot for releasing the lock. Now, the probe releases the lock when user closes the probe GUI.
1.43
Fixed: Trouble adding monitor points to templates.
October
2013
GA
January
2013
Fixed: Error "Key Already Exists" for different monitors when added in template.
1.42
Fixed SOC issues.
GA
June 2012
1.41
Fixed the 'OK' button is disabled defect upon re-editing a monitor.
GA
March
2012
GA
February
2012
GA
December
2011
Fixed the issue of "Auto monitor functionality" while monitoring from wildcard search. The monitors that were not
activated are also visible in auto monitors and the monitor that was activated was unchecked in auto monitors.
Fixed the no responsiveness issue of the probe when updating the version.
Added support for updating the cfg file by updating JVM_Monitor Probe Version
Added Resource Name facility while defining new Resource.
1.40
Fixed the unresponsiveness of probe when updating the version.

Added support for updating cfg file by updating JVM_Monitor Probe Version
Added Resource Name facility while defining new Resource.
1.30
Added new mechanism for Mbean handling

Added support for monitoring templates and auto-monitoring feature.
Added support for SSL secured rmiregistry
Added check to prohibit use of whitespace in configurator.
Fixed potential thread leak case.
1.20
GA
January
2011
1.10
GA
June 2010
1.02
Fix for password encryption and tree node name collisions which caused missing tree nodes and data.
GA
December
2009
1.01
Initial version.
GA
September
2009

The jvm_monitor probe should be installed on systems with the following minimum resources:

The jvm_monitor probe requires the following software environment:
Java JRE 6 or later
Installation Prerequisites
The probe is distributed using drag and drop. To ensure a successful distribution of the probe you must do the following:
A Java Virtual Machine (JVM) of version 6 or later must be installed on the system running the jvm_monitor probe.
The JVM path must contain the java executable.
For more information, see Verify Java.
The JVM environment must be set up on hosts that you want the probe to monitor. For more information, see the Set Up the Hosts secti
on in jvm_monitor Preconfiguration.
Verify Java
You must verify that Java Runtime Environment (version 6 or later) exists in the specified path on the system where the probe is installed. Check
the probe log file if the probe does not start. The following line appears in the log file if java is not installed or is not included in the path:
'java' is not recognized as an internal or external command, operable

program or batch file.'
For more information about updating the Java path in the probe, see jvm_monitor Troubleshooting.
Verify Java on Unix System

Follow these steps:
1. Log in to a shell as root user and go to opt/nimbus/bin path.
2. Enter the command java - version to verify if the java version is greater than or equal to 1.6.
3. Restart CA UIM to read the path by entering the following two commands in the shell:
./niminit stop
./niminit start
4. Open the Controller probe GUI in the Infrastructure Manager and click the Robot environment button in the Status tab.
5. Double-click Path in the list and verify that CA UIM has java included in the path.
Verify Java on Windows System

Follow these steps:
1. Open the command window and enter the command java - version to verify if the java version is greater than or equal to 1.6.
Note: If the command does not work, you must manually place the java.exe in the path. This is done in the Control Panel >
System > Advanced > Environment Variables. Run the java - version command again.
2. Open the Service Controller from the CA UIM Program Group in the Start menu.
3. Click Force Stop and then Start to enable CA UIM to include java in the path.
4. Open the Controller probe GUI in the Infrastructure Manager and click the Robot environment button in the Status tab.
5. Double-click Path in the list and verify that CA UIM has java included in the path.
Known Issues
The 1.47 and earlier versions of the probe have the following known issues:
The Find functionality is not available in the Infrastructure Manager GUI. Find allows you to directly navigate to the position of a monitor
in the tree.
Baseline and dynamic thresholds for monitors in Admin Console GUI are only available for CA UIM 8.35 or later. In earlier CA UIM
versions, the probe displays an undefined field, which must be ignored.
Older versions of probe cannot be upgraded to version 1.3x.
You can upgrade a probe from version 1.20 to 1.40 as the configuration values are compatible.
The following default monitors of probe version 1.20 have been removed in probe versions 1.30 and later:
ClassLoading.LoadedClassCount
Memory.HeapMemoryUsage.used
OperatingSystem.CPU Usage
Threading.ThreadCount
logmon (Log Monitoring) Release Notes

The Log Monitoring (logmon) probe scans ASCII-based systems and application log files by matching specified expressions. Alarms are
generated when the log file content matches the defined expression.
The probe monitors the following items:
Unix system (line-oriented) and database (record-oriented) log files
Content of HTML web pages: You can use the URL Endpoint Response Monitoring (url_response) probe with the logmon probe to
monitor the text in a web page.
Text output after executing specified commands
Text messages in CA UIM queues
Files from remote shared folders
The probe also extracts and stores metric data from the matched log file entry in the QoS database.
Contents
Revision History
Supported Locales
Known Issues
Revision History
This section describes the history of the revisions for logmon probe.
Version
Description
State
Date
3.55
Fixed Defects:
GA
January
2016
GA
September
2015
GA
August
2015
GA
June 2015
The probe did not correctly convert variable characters to defined file encoding in URL mode. Support case number
00245330
The probe did not support white spaces in paths for batch files. Batch files include commands that can be monitored. Su
pport case numbers 00270650, 00246042
3.54
What's New:
Fixed Defects:
The probe was unable to read UTF-16LE files. Salesforce case 00169492
The probe was crashing with exit code functionality. Salesforce case 00169505
The probe was unable to retrieve complete command output in the command mode. Salesforce case 00169863
Updated document regarding localization support. Salesforce case 70002007
Updated the document regarding alarms in the url mode. Salesforce case 00163388
3.53
Fixed Defect:
The probe restarts when a variable was added to the sub-system id. Salesforce cases 00170003, 00169384, 00167502,
00168440, 00168601, 00166738, 00168537
3.52
What's New:
Removed localization support on AIX platform.
Fixed Defects:
Fixed an issue in which the probe was unable to detect File encoding when File encoding was selected from GUI. Sal
3.50
What's New:
June 2015

The probe now has an option to generate alarms only on the first match of regular expression (defined in Watcher Rule),
in a specified interval.
Fixed Defects:
The regular expressions were not working with the defined threshold. Salesforce cases 00156818, 00159939, 00158632
The probe was not generating correct exit code on windows, unix, linux, solaris, and aix. Salesforce case 00157528,
00160884
Exit code variables were not expanding on USM. Salesforce case 00161303
Improved CPU usage of the probe. Salesforce case 00153268
3.49
What's New:
March
2015
Added support for factory templates
3.48
Fixed Defects:
December
2014
Entries for the QoS variable having multiple targets were getting overlapped on the USM. Salesforce case 00149257
No Exit code alarm was generated on Windows OS in case command was not found. Salesforce case 00150798
View option in the GUI did not show updated file content. Salesforce case 00147856
Probe stopped working when the number of characters in the match expression is greater than 1020. Salesforce
case 00145499
No alarms were generated when the threshold applied on a watcher variable is breached. Salesforce case 0013715
5
The probe did not identify the UTF-16 log files. Salesforce case: 00139268
3.47
3.45
Added a timeout option for the Command mode profiles to kill the command process and all its child processes after a
defined time limit.
What's New:
November
2014
October
2014
Added the localization support for AIX 64-Bit operating systems.

Fixed Defect:
Fixed a defect where the probe is reading the log file always from beginning when running in update mode. This issue
occurred when the probe reads some unprintable characters. Salesforce case 00136466
Fixed a defect where the probe was writing text Debug to the log file when the log level is zero.
Fixed a defect where the probe was not identifying the PCRE space characters (/s) in a regular expression. This issue
was also causing the probe crash on Linux and Solaris operating systems. Salesforce case 00138780
3.44
What's New:
September
2014
Added a Timeout option to kill an executing script.

Fixed Defect:
Fixed a defect where the -R option, which makes the monitoring start from the end of the file, was not working.
Fixed a defect where the probe was not starting due to dependency on ICU library files. Salesforce case 00141353
3.42
Added the localization support for Simplified Chinese, Japanese, Korean, Spanish, German, French, Italian, and
B-Portuguese languages from VB and Admin Console GUI. For localization support through Admin Console GUI probe
must run with NMS 7.6 or later version and PPM 2.34 or later version.
Added the support for zLinux environment.
Updated the probe VB GUI and Web GUI for configuring the format interval and for specifying the character encoding in
different locales.
Note: Do not use the Raw Configure GUI for updating the probe configuration in the non-English locales because it can
corrupt the entire probe configuration file.
June 2014
3.32
Enhanced the probe for making file missing/open alerts user-configurable with its clear alarms on probe restart.
February
2014
3.31
Fixed the probe functionality issue when both the abort on match and the match on every run options are selected
together.
December
2013
3.30
Enhanced the Format Rule feature for making it functional across check intervals. The number of intervals is
user-configurable.
December
2013
Implemented a new alarm when the log file is missing or not readable.
Fixed Defects:
Fixed an issue for not over writing the alarm subject.
3.27
Fixed issue related to Invalid entries in callback crashes probe.

Fixed issue related to Probe PID changing.
September
2013
3.26
Fixed issue related to locale.
June 2013
3.25
The probe is now available in Admin Console GUI.
March
2013
3.25
Fixed issue related to logmon send empty QoS.
March
2013
Fixed issue where Text profiles returns "0" instead of matching string as it used to.
3.24
February
2013
3.23
Fixed memory leak issue on Windows, Linux, and AIX machines.
February
2013
3.22
GUI changes in probe to display Japanese characters correctly.
December
2012
Alarm display in Japanese character in IM alarm sub console and UMP alarm sub console.
Regular Expression in Japanese.
View File having Japanese character correctly.
Open file with Japanese character in file name.
Fixed a defect when probe contains more than one watcher and format rules
3.21
Fixed crash issue on Linux.
August
2012
3.20
Added fix for variable expanding in message string.
August
2012
Added option to override alarm severity for max alarm message.

Added fix to clear max alarm only if error condition is returned to normal.
Added fix to support abort on match functionality in URL mode.
Added support for exit code monitoring when mode is set as command.
Extended format rule limitation to 200 lines.
Added support to refer entire text block as a variable.
3.13
Fixed SOC issue.
June 2012
3.12
Fix Issue with QOS generation in test profile through GUI.
March
2012
GUI fix: Test profile screen will now be opening even if the watcher contains a numeric name.
The help button will now display online help instead of CHM
3.11
Fixed localization issue in soc
March
2012
3.03
January
2011
3.02
Support for reading alarm tokens from cfg.
December
2010

3.01
Added fix to read a new file from beginning for the first time when "Updates" mode is selected and "Match on every run"
option is enabled. For example, when files are monitored based on time/day using %m,%M etc.
October
2010
3.00
Added support for wildcard characters in file-name.

Added support to configure severity and message for "Match on every run" option per watcher.
September
2010
Added Support for internationalization.

Fixed the crash due to stack overflow.
2.92
Fixed a problem with variables, when using with format definitions.
September
2010
2.91
June 2010
2.90
Added NIS (TNT2) Support.
May 2010
2.85
Fixed the suppression key problem that was introduced in version 2.82.
May 2010
2.84
Windows: Converted Command executable to short path name.
March
2010
Fixed interaction between logmon and url_response probes

2.83
Fixed problem with large suppression keys in max alarms alarm situation.
Enabled Source override for max alarm situation.
February
2010
Improved url_response probe interaction.

Fixed File browsing issue for AS400 environment.
2.80
Added a feature to test a profile or individual watchers within a profile for regular expression.
Added a fix to set proper timeout.
December
2009
2.72
Fixed issue in underlying library where the probe would fail to find the correct file location when the file had been both
truncated and appended to.
September
2009
2.71
Added a fix for monitoring files on non-domain machines in windows.
September
2009

Monitoring of files using UNC path is now possible.
Suppressing logic to avoid sending excessive alarms.
Fixed the issue of message variables not getting filled properly.
Message variable expansion fixed when match on every run is selected.
When both QoS and Alarm are selected for a profile only Variable QoS or number of matches (if selected) are sent.
Modified layout of QoS tab for Watchers in the GUI.
2.62
Modified thread pool behaviour to avoid timing problems.
April 2009
Added logging to show when a thread has been started.

Retry after 5 seconds if a thread is not available (was 60 seconds).
Fixed log file preview function to enable viewing the last section of large log files.
Removed numeric input checking on variable 'limit'.
Fixed configurator failure on creation of new QoS from watcher.
Disabled 'View' button for mode 'command'.
Fixed error situations in file browser.
2.56

Modified pt-lib call to be able to detect log file changes when the file date was unchanged.
2.54
Fix problem assigning variable from regex which contains just one character.
Fix problem expanding date primitives in path. Fix problem with last line in a multi-line format rule being skipped.
Bring 2.5x into line with changes made in the 2.4x series.
Fix potential problem with parsing of variables from a matched line.
Added support for 64-bit Windows (x64).
December
2008
September
2008
2.41
Fixed potential problem extracting variables from a matched line.
July 2008
Added dynamic buffer allocation for suppression keys.

Corrected several minor issues with the configuration tool:
Advanced tab greyed out for url type profiles
Wrong tooltip for 'Send clear alarm'
-Move up/down changed active state and upper/lower case profile name problems.
2.39
Fixed a timing problem which could cause a line in the log file to be skipped by the next scan if it was written during the
current scan of the file.
May 2008
Does not post messages when not specified to do so.

QoS target defaults to profile.watcher when not specified.
Corrected parameter transfer on url View.
Modified handling of Exclude rules to minimize cpu usage when scanning files.
Allow wildcards in path names as well as file names.
2.23
Fixed memory leak when probe is restarted.

Fixed potential thread deadlock upon failure to save last_run time.
December
2007
Fixed issue with file offset being stored incorrectly when probe is stopped/restarted.
UNIX: Fixed incorrect time display in logfile and potential heap corruption issues due to a non-threadsafe system call.
Increased size of buffers used to store profile and watcher names. Fixed memory leak when alarm message was over
1024 characters.
Fixes segmentation violation due to failed compilation of a regex. Log an error message when a regex fails to compile.
Added support for editing archived configurations.
Enhanced configuration tool resize.
Fixed problem with $FILENAME expansion.
Added support for referring environment variables.
2.19
Add advanced option "sendclear" to watchers. If set it will send a clear alarm if the current watcher is as expected and
the watcher has a suppression key set. Note this requires that the suppression key is unique enough that it will not clear
an alarm unexpectedly. Using a variable that is unique for each alarm situation in the suppression key is advised.
October
2007
2.18
Apply changes to log level and log size after restart of the probe.
September
2007
GUI: When copying a profile the excludes are also copied.

2.17
Store last run for profiles in logmon.dta so expansion of LASTRUN() is correct even after a restart.
Fix problem with Format rules not triggering.
August
2007
Fix problem reading directories with / as path separator on windows systems.

Fix problem with abort on match flag. Fix problem with date expansion in filenames/commands.
GUI fix when trying to view contents of a web page
2.14
Library change (and platform list corrected)
May 2007
2.02
Fixed problem where alarm flag would be reset to 'yes' on every restart.
February
2007
Fixed potential hang situation where a thread would fail to release a lock.
Added support for URL authentication when windows authentication is used with a proxy configuration.
Probe has been re-written as a multi-threaded daemon.
Profiles are checked in a thread, allowing for higher throughput and configurable intervals for each profile.
A new mode 'url' is available, which fetches a web page through the url_response probe and performs checks on the
page.
Variables in a watcher can be read from positions in the regular expression in addition to the fixed character or column
specifications used prior to this release.
Variables can have a threshold set, where an alarm is sent only if the variable is outside the expected value.
Variables can generate Quality of Service (QoS) messages, either with their values (if numerical) or with the result of the
check against an expected value (both numerical and strings).
A watcher is no longer bound to sending either Alarm, QoS or user defined messages. One or more types of message
can be selected for each watcher.
Added ability to run a command when a watcher matches.
1.67
Fixed problem with using time formatting together with wildcards in filenames.
Extended timeout for getting 'queue' data.
December
2006
Fixed crash caused by long log messages. Now long log messages will be cut after 1024 characters.
The introduction of wildcards caused the two modes of 'queue' and 'command' to not function any longer. The wildcard
check is now only performed if the mode is set to scanning files, and for the modes of 'queue' and 'command' it is
working as before wildcards was introduced. 'command' was also not showing up in dropdown list. This is fixed.
1.63
Added possibility to send number of matches per run as QoS.

Fixed core dump on True64 (long regexp).
September
2006
Fixed GUI problem when minimizing/restoring window.

Fixed spelling error in GUI.
Changed name of Checkpoint ID field to Suppression key.
Fixed missing subsystem ID when copying profiles.
Stripped off unnecessary text in $PROFILE variable.
Fixed problem with blank fields and tabs.
Added possibility of using wildcards in filenames.
Fixed blank variable problem.
Fixed problem with long matching lines.
1.61
Added FILENAME message variable.

Resolved problems with large amounts of new log-data arriving while scanning for updates on a log file.
Supported Locales
From logmon version 3.42 and later, the probe supports the following encoding files for various locales:
Note: Localization is supported only on Windows and Linux systems.
Encoding
Name
UTF-8
Unicode (UTF-8)
UTF-16BE
UnicodeBigUnmarked
UTF-16LE
UnicodeLittleUnmarked
Shift_JIS
Japanese (Shift-JIS)
ISO-2022-JP
Japanese (JIS)
ISO-2022-CN
Chinese(ISO)
ISO-2022-KR
Korean (ISO)
GB18030
Chinese Simplified (GB18030)
GB2312
Big5
Chinese Traditional (Big5)
EUC-JP
Japanese (EUC)
EUC-KR
Korean (EUC)
ISO-8859-1
Western European (ISO)
ISO-8859-2
Central European (ISO)
windows-1250
Central European (Windows)
windows-1252
Western European (Windows)
June 2005
Important! Do not use the Raw Configuration GUI when the probe is deployed in a non-English locale.

The probe (version 3.49 or later) threshold configurations can be migrated to standard static alarm thresholds using the threshold_migrator probe
on CA UIM 8.2 or later. Refer the threshold_migrator probe document for information about how to migrate a probe.
The Infrastructure Manager (IM) GUI of the probe will not be available and the probe will only be configured using Admin Console (AC).
Probe specific alarm configurations in the probe monitors will be replaced by Static Alarm, Time To Threshold, and Time Over Threshold
configurations.
Any section of the probe with an applied policy will no longer be available for configuration through the probe. The policy must be
removed to configure the probe using the Admin Console GUI.
The probe has the following preconfiguration requirements:
The probe requires at least one of the following components for monitoring:
ASCII-based log files
URL of the web page
Command Outputs
Messages in the CA UIM Hub queues
The url_response probe for monitoring web page content.
Note: AIX platform does not support url_response mode, hence must be disabled for both Admin Console and Infrastructure
Manager.

The logmon probe should be installed on systems with the following minimum resources:

The logmon probe requires the following software environment:
glibc 2.5 or later (required for Linux platforms)
Known Issues
The probe does not support monitoring log queues with multiple encodings. If the sysloggtw probe monitors syslog devices with different
encodings, the probe might not be able to identify the characters from the SYSLOG.IN queue.
The probe does not support Byte Order Mark (BOM) in the monitored files. If BOM is present in the files, the first character might be a '?'.
The probe only generates alarms for a file if the probe continuously receives pattern matches, as in Queue mode or from a continuous
running command, from the monitored file.
Command for some system calls (fgets) fail, resulting in wrong exit code by the probe.
Signal 13 and 15 result in exit code 141 and 143. The signals are used to kill a process.
The logmon Probe Provisioning UI does not allow user to view the file for URL mode.
The probe does not support URL mode, Command mode and Run Command on Match on IBM iSeries platform.
The probe has the following limitations when deployed in a non-English locale:
While monitoring an ASCII-based file using the ASCII characters for matching, you cannot use Japanese characters in the alarm
message text. The probe cannot identify Japanese characters in alarm messages in such cases.
The probe garbles the file name when clicking the Tail/View File button, while monitoring a Japanese log file.
The probe GUI shows garbled text on clicking the Tail/View File button to view the log file text.
The Raw Configure GUI of the probe is not supported for updating the probe configuration because it can corrupt the entire probe
configuration file.
The localization is supported only on Windows 32-Bit, Windows 64-Bit, and Linux 64-Bit.
The probe does not support queue with multiple encodings.
lync_monitor (Microsoft Lync Server Monitoring) Release Notes

The Microsoft Lync Server Monitoring (lync_monitor) probe is used to monitor the health and performance of Microsoft Lync Server 2010 and
2013. This probe is delivered with a default configuration, containing some selected set of profiles to be monitored. You can also define your own
profile.
The profiles are grouped in seven predefined groups or categories, as stated below:
Eventlogs: Monitor Windows event logs for specific event contents.
Files: Monitor specific files on the server.
Filesystems: Monitor file systems for specific patterns on the server.
Performance counters: Monitor performance counters.
Processes: Monitor different processes running on the server.
Services: Monitor LYNC related services. The different services are listed below:
WMI: Monitor specific WMI classes.
Each of these categories can contain several profiles. Each of the profiles can contain several counters.
Contents
Revision History
Installation Notes
Revision History
Note: Salesforce case(s) may not be viewable to all.
Version
Description
State
Date
2.20
What's New:
GA
June 2015
Added support for IPv6.
Fixed Defects:
The probe displayed the hostname instead of IP address as the source in alarms. Salesforce case 00159505
2.1
GA
March 2014
2.0
Support Lync Server 2013.
GA
Sept 2013
1.0
Initial release
Dec 2012

The probe (version 2.20 or later) threshold configurations can be migrated to standard static alarm thresholds using the 2.01 version of the
threshold_migrator probe.
Notes:
During migration, the process cannot be stopped and the probe must not be configured. The probe will restart once the process
is complete.
configurations.
User defined variables will not be available

The lync_monitor probe should be installed on systems with the following minimum resources:

The lync_monitor probe requires the following software environment:
Microsoft Lync Server 2010 or 2013.
Microsoft .Net Framework 2.0 on the probe and the manager machines. On 64-bit Windows machine, the probe requires 64-bit Microsoft
.Net Framework 2.0 to run as 64-bit native application.
The lync_monitor probe requires the following software environment to migrate with threshold_migrator probe:
Upgrade to version 2.20 of the probe has the following consideration:
The probe will support upgrade of more than two thresholds for each profile. However, since the probe supports just two thresholds for
each profile, new thresholds cannot be configured for an upgraded profile. You must either delete thresholds until the number is less than
two, or create a new profile.
In order to monitor the lync server, CA Unified Infrastructure Management robot (version 3.02 or above) should be installed on the server.
1. Install 'lync_monitor' package into your local archive.
2. Drop the package from your local archive to the targeted robot.
3. Double click the probe in the Nimbus Manager.
4. Configurator opens with a default set of profiles in an inactive state.
5. Activate the profiles to start monitoring.
Note: For each activated 'Eventlog' profile, the probe scans windows events on the lync server from the last scanned event entry to
match the given criteria. If the system generates large number of events between the intervals, then scanning large number of events
may affect the performance of the system.
Installation Notes
The probe dynamically generates Quality of Service table names. Some of these table names might contain more than 64 characters, which can
create problems when inserting data into the SLM database. When a CA Unified Infrastructure Management earlier than 3.35 creates the SLM
database, the name column, in the S_QOS_DEFINITION table of the SLM database, is 64 bytes. You must update the size of the name column
to 255 bytes. The latest data_engine qos discards definitions that are greater than 64 characters. If you do not update the size of the name
column, earlier versions of the data_engine might fail.
Update the size of the name column to 255 bytes manually by using a database tool:
Design the table S_QOS_DEFINITION table and change the size of the name
column to 'varchar(255)'.
Update the size of the name column to 255 bytes by running the following query on the database (Note that this query will not work on SQL
Server 2000):
-- Added code to change field width of the name column of the S_QOS_DEF
INITION table
-- A constraint needs to be dropped first to be allowed to do so
declare @const varchar(500),@sql varchar(500)
--Remove temp table, if exists.
IF Exists(SELECT * FROM tempdb.dbo.sysobjects WHERE [ID] = OBJECT_ID('t
empdb.dbo.##Objects')) DROP TABLE ##Objects
--Creating new temp table.
create table ##Objects (iname varchar(255),is_pk int)
-- Inserts indexes that are primary key on the table.
insert into ##Objects SELECT [name],is_primary_key FROM sys.indexes WHE
RE object_id = OBJECT_ID(N'[dbo].[S_QOS_DEFINITION]')
-- Adding values to variables.
select @const = iname from ##Objects where is_pk = 1 set @SQL = 'ALTER
TABLE [dbo].[S_QOS_DEFINITION] DROP CONSTRAINT [' + @const + ']'
-- Dropping the PK constraint.
EXEC (@SQL)
-- Cleaning up temp table.
drop table ##Objects
-- Altering table, modifing name, and addeding new PK.
ALTER TABLE [S_QOS_DEFINITION] ALTER COLUMN [name] [varchar](255) not n
ull
ALTER TABLE [dbo].[S_QOS_DEFINITION] ADD PRIMARY KEY CLUSTERED (
[name] ASC
) ON [PRIMARY]
maintenance_mode Release Notes

Requirements
Known Issues
Fixed Defects
Revision History
The maintenance_mode probe sets user specified maintenance windows for devices. During these maintenance windows, alarms with the
following severity levels do not display in the Alarm Console or USM:
Critical
Major
Minor
Warning
Informational and clear alarm messages are still displayed during a maintenance window.
Note: Alarms are only suppressed at the primary nas level.
Requirements
No minimum hardware requirements.
The maintenance_mode probe requires the following minimum software environment:
CA Unified Infrastructure Management Server 7.5 or later.
Unified Management Portal version 7.5 or later.
nas probe version 4.32 or later.
The maintenance_mode probe is installed as part of an CA UIM installation.
Known Issues
No known issues.
Fixed Defects
No fixed defects in this release.
Revision History
Version
Description
State
Date
1.10
Minor documentation changes.
GA
September 2014
1.10
Fixed issue with maintenance_mode functionality on Microsoft clusters.
GA
June 2014
1.0
Initial release.
March 2014
selfservice_cm (Self Service Configuration Management) Release Notes
mongodb_monitor (MongoDB Monitoring) Release Notes

MongoDB is a cross-platform document-oriented database. This database stores data in JSON-like (BSON) documents with dynamic schemas.
The dynamic schemas make the integration of data in various applications much easier and faster. MongoDB provides high performance,
availability, and scalable services. Although MongoDB supports a "standalone" or single-instance operation, usually production MongoDB
deployments are distributed.
The mongodb_monitor (MongoDB Monitoring) probe constantly monitors the internal performance and resource usage throughout a node in a
MongoDB cluster. Each node in the MongoDB cluster should be installed with the probe for a comprehensive monitoring experience. The probe
uses operating system commands and MongoDB API calls that are supported by MongoDB. The information is presented to the cluster
administrator as metrics, alarms, and reports. You can select and schedule an extensive range of checkpoints to meet the needs of your specific
monitoring requirements.
Contents
Revision History
Revision History
Version
Description
State
Date
v1.0
Initial version
GA
June 2015

The machines on which the probe is deployed must be functioning MongoDB nodes.

Note
We recommend that the CA Unified Infrastructure Management (CA UIM) Server and the CA Unified Management Portal (UMP) are the
same version.

MongoDB version 2.6.X, running on Unix.
3. Use Admin Console to access the probe configuration GUI or raw configure options.
None
This probe cannot be configured through Infrastructure Manager (IM).
monitoring_services Release Notes

The Monitoring Services (monitoring_services) probe is released as a part of the core Unified Infrastructure Management Server release. For this
reason, release notes for the Monitoring Services probe are included in the Unified Infrastructure Management Release Notes. See Upgrading &
Release Notes on the CA Unified Infrastructure Management wiki.
nas (Alarm Server) Release Notes

The Alarm Server (nas) stores and administers alarm messages for the UIM Alarm product. The nas package in the Archive contains two probes nas and alarm_enrichment:
The alarm_enrichment probe is a pre-processor probe for the nas probe. The alarm_enrichment probe attaches itself to a permanent
queue and receives alarm messages distributed by the Hub. The messages flow into the alarm_enrichment probe, where alarm storms
are detected. The alarm_enrichment probe also enriches messages with additional information read from external data sources using a
Configuration Management Database (cmdb). The alarms are renamed to alarm2 and are then sent to the nas probe for further
processing. The alarm_enrichment probe is also responsible for processing the Time Over Threshold event rule.
The nas probe is a service probe that attaches itself to a permanent queue and receives alarm2 messages from the alarm_enrichment
probe. The nas probe acts upon the incoming alarm message, storing information about the message into the UIM database.
Both probes must be activated on the hub for alarms to properly process.
Contents
Probe Revision History

Requirements
Supported Platforms
Considerations

Version
8.4
Description
Revised nas version to match the CA UIM version.
State
Date
GA
January
2015
4.75
Made additional performance improvements for viewing USM alarm information in large-scale environments.
Controlled
Release
Sep
2015
4.73
Improved performance while viewing USM alarm information in large-scale environments.
GA
Aug
2015
Controlled
Release
Jul
2015
GA
Mar
2015
4.72
Fixed an issue in which alarm_enrichment rules based on empty probe ID values no longer worked in nas 4.67. Salefo
rce case 00161140
Fixed an issue in which the On Interval AO setting would not respect alarm count filters. Salesforce case 00162735
Custom tags are now truncated at 255 bytes. This fixes an issue in which custom tags exceeding 255 bytes were not
inserted into the UIM database. Salesforce case 00162186
4.67
Added secondary nas support for maintenance mode.

Fixed an issue in which AO profiles using action modes On every AO interval or On every interva l would execute
before reaching the correct count if nas restarted. Salesforce case 00150567
Fixed an issue in which trigger state functionality for auto operators would not change (flags would remain grey even
when alarms matched the filter). Salesforce case 00155195
4.60
Fixed an issue in which long alerts (exceeding four-thousand characters) from the ntevl probe could cause an error
with the NiS bridge. Salesforce case 00142103
GA
Dec
2014
GA
Sept
2014
GA
Jun
2014
GA
Mar
2014
GA
Jan
2013
GA
Nov
2012
GA
Jul
2012
Fixed an issue in which mysql UIM database passwords longer than nine characters would not work with mysql 5
authentication. Salesforce case 00142835
Fixed an issue in which some Lua scrips could cause memory leaks in nas versions 4.36 and 4.40. Salesforce case
00149127
Changed the nas probe configuration GUI to reflect updated Trigger Message Counters; Greater than now appears as
Greater than or equal. Salesforce case 00144345
4.40
Added support for the Time Over Threshold event rule.

Fixed an issue in which a long nimalarm system argument (exceeding 500 characters) could cause a nas buffer
overrun.
Fixed an issue in which nimalarm was not packaging the Values PDS correctly in some cases.
4.36
Fixed a Lua script issue that could cause a nas startup failure after a segmentation fault.
Fixed an issue in which nas would not send email when the On_Interval setting was selected.
Fixed an issue in which AO would not act on overdue_age profiles correctly.
Fixed an issue in which the alarm_enrichment probe would repeatedly retry messages if the required alarm fields were
not provided.
4.32
Fixed "temporarily out of resource" errors during callbacks to the nas probe.
Added support for maintenance mode.
4.20
hostname set incorrectly during shutdown

Repeated restarts from the nas GUI causes program hang
Alarm enrichment requires lower case column names in overwrite-rules
Help button on nas using wrong help file location.
4.10
4.01
Alarms not stored in replication database when message suppression is turned off
Fixed I18N issue, required for UMP
Fixed pre-population query in alarm_enrichment cache.
4.00
Added a pre-processing alarm_enrichment probe to substitute data in alarms from CMDB
GA
Jun
2012
3.75
Added handler to fix SqliteBusyHandler terminating request
GA
Mar
2012
3.74
Fixed: Lua call to note_create fails only on RHEL 6.1
GA
Feb
2012
3.73
Fixed I18N issue affecting UMP and Localized GUIs
GA
Jan
2012
GA
Oct 31
2011
GA
Oct 13
2011
GA
Jun 24
2011
3.72
Fix for a NAS initialization problem

Fully synchronizes Alarms on both sides of replication links.
3.71
3.70
Defect fixes
IPv6 support added
Fixed column width of schedules in AO profiles (now resizeable).
3.63
Fixed defects relating to the GUI, MySQL, and Unix
GA
Jun 23
2011
3.62
Defect fixes
GA
Jun
2011
3.61
Improved handling of duplicate message-ids (constraint violations) in incoming alarms
GA
Mar
2011
GA
Feb 4
2011
GA
Feb 3
2011
3.60
Added support for arguments to scheduled scripts.

Implemented storm protection to protect the nas from alarm storms.
3.54
Auto-configured NAS to activate I18N support on fresh installs
3.53
Defect fixes
GA
Jan
2011
3.52
Fixed a problem with Oracle restart
GA
Nov
2010
GA
Sep
2010
GA
Jun
2010
GA
May
2010
3.51
Fixed problem with long message texts not being inserted/updated by NiS bridge
Added support for internationalized/tokenized alarms.
Added support for a Oracle NiS database.
3.44
3.42
Added support for NiS databases other than MS-SQL

Fixed problem with alarm suppression counter reset.
Fixed minor UI issues.
3.41
Defect fixes
GA
Mar
2010
3.40
Added NMS libraries with SSL support
GA
Jan
2010
3.31
Various defect fixes
GA
Nov
2009
3.28
Fixed a variety of internal defects
GA
Aug
2009
3.27
Fixed buffer overrun possibilities
GA
Jul
2009
3.26
Defect fixes
GA
May 29
2009
GA
May 26
2009
GA
Mar
2009
GA
Feb
2009
3.25
Defect fixes
Added support to alter the NAS subscribers 'subject'
Added support for 'raw configuration' of cross-domain replication
Added support for the 'state' method in pre-processing scripts.
3.24
3.23/3.18
Removed restriction for the 'clear' severity as a candidate for pre-processing.

Supports controlled server shutdown
Fixed possible deadlock situations for subscriber subsystem during certain database constraint violations.
3.22
Defect fixes
GA
Nov
2008
3.16
Added possibility to create custom pre-processing rules and event laundering.
GA
Sep
2008
3.15
Improved replication over low-bandwitdh communication lines
GA
Aug
2008
3.14
Fixed problem with operator period crossing Sunday night

Fixed name-resolution issues due to lookup aging.
GA
Jun
2008
3.12
Fixed issues with restart and reconnecting to the hub queue
GA
Apr 24
2008
3.11
Changed permission requirements
GA
Apr 4
2008
3.10
Embedded scripting language for advanced message correlation and auto-operator functions
GA
Feb 15
2008
Improved the transaction log

Introduced an activity log
Introduced alarm summary information
Improved the auto-operator scheduler
Introduced the concept of operating periods for auto-operator profiles and filters
Introduced the concept of 'invisible alarms'.
Added alarm-message approximation for messages without suppression information.
Improved the scheduling services.
Introduced NAS replication services.
Introduced possibility to add notes to alarms.
Improved the IP to name resolution services.
2.75
Enhancements
GA
Feb 4
2007
2.74
Added origin, domain, hub, robot and probe information to network transactions.
GA
Dec
2006
GA
May
2006
GA
Jan
2006
GA
Sep
2005
GA
Mar 31
2005
GA
Mar 4
2005
GA
Dec
2004
GA
Nov
2004
2.72
Fixed UI issue with the calendar configuration

Fixed problems with large alarm messages crashing the NAS
Fixed issues with zombie processes on UNIX.
2.71
2.70
Fixed issue with auto-operator and the ability generate a command after alarm ack
Added a calendar feature controlling filters and auto-operator methods
Functionality extensions.
2.68
2.67
Fixed problems with import/export and hubnames containing the label "hub"
Added NimBUS domain, hub and probe as possible matching criteria.
Added new auto-operator action type: post-message
Fixed various issues related to the auto-operator clearing alarms
Added possibility to expand variables in SMS phone field.
2.66
Improved Import/export functionality

Added assign possibilities for exported messages.
2.65
Fixed problems with locking on UNIX platforms

Fixed GUI issue with import/export.
2.64
Fixed defects
GA
Jun
2004
2.63
Modified the name lookup algorithm to permanently exclude more than 3 consecutive lookup failures
GA
Mar 23
2004
2.62
Added support for automatic and manual database reorganization
GA
Jan
2004
GA
Oct
2003
2.61
Simplified the IP/name resolution method

Added support for 'robotip' from new spoolers
Changed suppression key to handle NAT environments.
2.60
Enhanced the auto-operator and filter time-specification properties
GA
Jul
2003
2.51
Added support for 'Copy' auto-operator method in UI
GA
Feb 17
2003
2.50
Added support for different ip/name lookup methods
GA
Feb 13
2003
2.47
Fixed problem with export/import (slave alarm servers)
GA
Nov
2002
2.46
Fixed synchronization problems with mirrored alarm servers
GA
Aug
2002
2.45
Added suppression time when escalating an alarm. Fixed problems with get_alarms from Alarm Console
GA
Jun
2002
2.42
Added support for time variables in auto-operator message decoder
GA
May
2002
2.41
Prepared code for Nimsoft 2.51 release
GA
Feb 14
2002
2.40
Fixed problems with "assignment"
GA
Feb
2002
2.39
Improved handling of corrupted/invalid messages
GA
Jan 17
2002
2.38
Fixed problems with name/ip caching mechanism
GA
Jan 15
2002
2.37
Use "default" robot-name in alarm messages
GA
Dec
2001
2.36
Improved "default" hostname algorithm
GA
Nov
2001
2.35
Added transaction-log administration, fixes to auto-operator and transaction-log browsing
GA
Oct
2001
2.34
Corrected network trans. logging tokens/data
GA
Jul
2001
2.33
Fixed problems related to clearing/ack. Termination/shutdown problems fixed.
GA
Jun
2001
2.3
Fixed problems related to Auto-Operator
GA
May
2001
2.0
Added Auto-Operator as a thread.
GA
Apr
2001
Requirements
This section contains the requirements for the nas probe.
None
Supported Platforms
The nas probe is supported on all UIM hub platforms, except for AIX--which is unsupported for nas. This includes 32-bit hub platforms.
Note: Refer to the Compatibility Support Matrix for the latest information on supported UIM platforms.
Considerations
This section contains the considerations for the nas probe.
The nas requires a permanent queue on the Hub. If you are upgrading an existing alarm server, the queue will already be defined.
net_connect (Network Connectivity Monitoring) Release Notes

The net_connect probe measures network connectivity that is based on 'ping' (ICMP ECHO) and TCP connections to a list of user-defined
services such as NetBIOS, telnet, ftp, http. The probe supports Service Level Management by sending Quality of Service (QoS) messages.
Contents
Revision History
Revision History
This section describes the history of the revisions for net_connect probe.
Version
Description
State
Date
3.21
Fixed Defects:
GA
December
2015
GA
November
2015
GA
August
2015
The probe did not retrieve the Hostname of the specified IP Address of the monitored host. Support case number
00267015
The probe did not save the changes in Infrastructure Manager when managing services through Bulk Configuration. Sup
port case number 00270819
Set the default state of the Response Time monitor to ON to display data on the Unified Dashboard automatically.
3.20
What's New:
Added support for monitoring hosts with dynamic IP address.
Fixed Defects:
When viewing data on USM, the net_connect probe DEV files conflicted with the interface_traffic probe DEV files and
displayed random device information. If both the hostname and IP address are provided for a monitored host, the
net_connect probe used only the hostname to display data. Salesforce cases 00165874, 70007073
You can create a key in the probe to display data on USM, using the host IP address. For more information, see the Kno
wn Issues and Workarounds section.
When monitoring only the services of a host, and not the ICMP connectivity of a host, the probe did not generate any
QoS data. Salesforce case 70002909, 70004940
The probe did not resolve the $group variable if it was used in a tree structure. Salesforce case 70002994
The probe was deleting the monitoring profiles created using the drag-and-drop feature. Salesforce case 70002993
3.11
What's New:
Note: Refer Threshold Configuration Migration section for more information.
Fixed Defect:
User was not able to set the default host parameters in the Infrastructure Manager version of the probe. Salesforce case
00169100
3.10
What's New:
GA
July 2015
GA
January
2015
GA
July 2014
Added three new fields (Max Ping Threads, Max Service Threads, and Max PacketLoss Threads) under Setup
Properties > Advanced > Performance Properties section in IM GUI, and under net_connect > General Configuration
section in AC GUI to provide flexibility to the user in configuring separate number of threads for ping, services, and
packet loss feature.
Probe will now send single ping for connectivity check and response time calculation instead of separate pings for both.
Added Log Size field to define the size of the log file.
Fixed Defects:
User was not able to monitor the IPv6 host. Salesforce case 00154639
Multiple alarms were received and the alarm message contained the text: 'jitter is above threshold limit' even when no
threshold was defined. Salesforce case 00162039
User was not able to change the message for jitter alarms. User can now edit already existing (default) jitter alarms, but
cannot create new jitter (OK and Fail) alarms using Message Pool Manager in IM GUI. These two default jitter
messages will be sent by the probe for all the profiles. User cannot configure custom jitter alarm using Host or Service
properties (The probe does not support this functionality). User can also edit message text of default jitter alarms, which
will reflect in the Alarm Console. It is recommended not to delete any default jitter alarm, as these are the only 'jitter OK'
and 'jitter Fail' alarms sent by the probe. User will not be able to add these jitter alarms again from probe GUI. Salesforc
e case 00137628
3.05
Fixed Defects:
Probe stopped working with services that did not have Active key. Salesforce case 00141024
After re-applying default settings to a profile, a newly created message did not get saved in the configuration file. Salesf
orce case 00146089
Runtime error occurred when a service monitor was edited. Salesforce case 00148572
After the value of the Failed intervals field was changed once, the value did not get changed if it was changed again. Sal
If a service was added using drag-and-drop function, some default sections were not saved in the configuration file. Sale
3.04
Fixed a defect where probe was constantly in error state and not generating PID. Salesforce case 00119246
Fixed a defect where the QoS Target associated with old profiles was not changing to Profile Name if the probe version
was upgraded. Salesforce case 00135038
Fixed a defect where the probe stopped rotating the log file if the log size was set higher than 2 GB. Salesforce case 00
128940
3.03
Fixed Defects:
April 2014
For an inaccessible service on a host machine, the probe was not delaying the retry attempt for the time specified in the
Delay Between Retries field.
User was not able to change the severity of the alarm Failed to execute profiles in scheduled time interva l. This alarm is
now configurable through GUI.
The probe failed to restart when the Monitor ICMP connectivity (ping) check box was unchecked and the probe was
restarted.
3.02
Fixed the issue where the probe was generating the faulty "connection failed" alarms and "NULL" QoS for devices
without publicly defined hostname, such as switches. Now, the probe uses the IP address for devices that do not have a
publicly defined hostname and generate appropriate alarms and QoS.
January
2014
Fixed an issue where jitter and packet-loss alarms were not clearing.
Fixed an issue where the probe sends 0 as the response time for all pings instead of the actual response time.
Fixed an issue where the net_connect probe sends QOS value 0 for devices that do not ping.
Fixed an issue where the net_connect probe sends duplicate QOS when packet-loss monitoring is enabled.
3.00
Added support for cfg having large (25000) profiles.

Reduced time of load for large profiles.
2.93
Fixed an issue of CPU usage and clock drift (QOS with negative response time).
November
2013
July 2013
Added entries in CiManager for unit of Packet latency and Packet Jitter.
2.93
Fixed an issue where $contactInfo value is missing

Fixed the timeout issue. Default timeout changed from 10 to 2 sec.
May 2013
2.92
Fixed an issue where in parent-child relationship probe is processing the child even when the parent node is down.
April 2013
Fixed an issue where a configured service on a host was not running.

2.91
Fixed ping fail alerts.
April 2013
Fixed fail to schedule alerts.

Fixed: Probe GUI crashes when user close in between abort process in ping sweep.
Fixed: Child Profiles not getting deleted from right pane.
2.90
Revamped probe for scalability

The issue of failing to execute in scheduled time interval has been fixed.
December
2012
The higher CPU issue fixed.

Revamped the probe for scalability for False Alarms, that is probe reporting +ve ping as -ve ping due to time out at
higher number of profiles.
Revamped the probe scalability for failing to execute profile at scheduled time interval.
Revamped the probe scalability and resolved some issues relating to crash of the probe.
Also changed the config parameters default value, that is max_socket = 100 (global level) and timeout = 10 Sec. (at
profile level).
2.81
Fixed a probe crash on restart and empty callbacks call from probe utility.
July 2012
Fixed an issue with the timer functionality.

Fixed an issue with QOS messages not coming for the profile.
Fixed an issue for multiple Alarms coming for a profile.
2.80
Fixed an issue to sort profile on basis of IP address. Supported sorting for both IPv4 and IPv6 address.
June 2012
Added new callback to return active profiles and their services.

Wild card or regex is supported in profile name.
Thread Model change for Profile execution.
2.73
Fixed an issue where change in QoS source for one profile also changes other profiles.
April 2012
Resolved a restart problem.

Fixed issue when probe is not using packet size setup in ping functionality.
2.72
Implemented Source Override when even ping is disabled.

Fixed crash issue when profile is active and monitor icmp check box is unchecked.
2.71
Implementation of IPv6 compatibility.

Updated libraries.
January
2012
December
2011
2.70
Implementation of IPv6 compatibility.
October
2011
2.66
Fixed a crash situation.
October
2011
2.65
Fixed an issue where the probe was reporting incorrect jitter values in alarm and QoS.
Fixed a crash occurring due to insufficient wait time used by the probe to wait on profile & service threads graceful exit.
September
2011
The probe now supports a new raw configurable attribute named thread_timeout for setting the thread timeout value in
seconds.
The probe looks for the new attribute under setup section of configuration file. By default the probe uses 30 as timeout
value to wait on the threads to gracefully exit on probe stop/restart situations.
Added option for changing QoS source.
Note: Do not change the source unless you have good reasons. The Robot address is the "correct" source for this
probe.
2.63
Added support for configuring packet loss alarms & QoS separately.
Added packet jitter value to the values PDS sent with alarms.
The key name for this value in the alarm is packet_jitter.
Added support for expanding group value for chained host profiles.
Added an alarm when profile execution exceeds regular profile execution interval.
August
2011
2.62
Fixed the SOC xml Junit test issue.
April 2011
Fix: GUI bug when using bulk configurator to configure services. If text field 'Delay between retries' is empty,
configuration of services would silently fail.
Changed default ICMP packet size to 32 bytes, default delay between packets to 30 seconds, default packets to send in
packet loss to 10.
Added alarm on jitter.
Added option in UI to configure service threads.
Updated bulk configuration UI for missing configuration parameters.
2.53
2.60
Texts in Service-oriented configuration (SOC) now being presented properly.

Added option to continue checking services, even if "Monitor ICMP connectivity" fails.
Added option to send QoS for Latency and Jitter with packet loss monitoring, when delay between packet is set.
March
2011
February
2011
Added new check boxes for Latency and Jitter in SOC GUI.
2.52
2.51

Added functionality to copy the Result of the show status window to clipboard.
January
2011
December
2010

Support for Web-based Service Oriented Configuration (SOC).
2.50
2.42
Initial support for internationalized alarm texts.

Changed thread pooling implementation to schedule all the profiles from queue.
Added minor bug fix in GUI.
2.41
2.40
Probe version released with NMS version 4.30.

Added a log message on negative response time. Also stopped sending NULL QoS when negative response time is
calculated due to host time issues.
October
2010
September
2010
August
2010
August
2010
Added fix to provide number of retries before sending alarm with delay between retries.
Added fix to properly clear service alarms.
Redesigned bulk configuration window.
Added option in GUI to set default service parameters.
2.34
Added fix to remove error message in logs in ssh service by sending SSH identification string.
June 2010
Added fix to use new API when both IP and hostname are available to avoid name-lookup.
Added fix in probe to send proper hostname in callback.
Added fix in GUI to update hostname and ip address on test.
Added fix in probe to break the loops on restart/stop.
Added fix in probe to initialize the buffers, before checking the response while monitoring the services.
Added fix in probe to change "Bind to network interface" on restart.
Added fix for crash in GUI when profile was renamed and deleted.
Commented code for group expansion.
Added code to add contact info field in bulk configuration.
Added a field for delay between packets in profile form.
Fixed constant QoS value.
2.26
Added a fix to not clear the alarm in every interval before sending the challenge response failure alarm.
February
2010
2.25
Fixed memory leak (introduced in version 2.23).
February
2010
2.24
Added a fix for intermittent probe restart when running a service request.
Updated callback to test the response using IP address when both hostname and IP is specified.
February
2010
2.23
Added a fix to resolve correct IP address when hostname is specified in profile.
December
2009
2.15
Fix for not always using correct IP address when hostname is specified in profile. (Fix available in version 2.15 and from
version 2.23, not versions in between).
December
2009
2.22
Updated to latest NIS database layout.
December
2009
2.21
Fixed problem with profiles that never got rescheduled.

Added a fix to schedule the profiles which failed to execute in previous run.
December
2009
Added a fix for crash on restart or while stopping the probe.

2.13
Added fix to stop proper timers.

Added fix to schedule all the profiles from queue.
2.12
Fixed problems with threadpool and multi-core cpu.
August
2009
June 2009
Fixed problems with "blank" challenge response input.

2.10
Fix: If a connection test fails, the QoS for packet loss is NULL not 100(%).
April 2009
Added support for the following platforms:

AIX_5_64
HPUX_11
HPUX_11_64
HPUX_11_ia64
LINUX_23_64
LINUX_23_ppc64
SOLARIS_8_sparcv9
SOLARIS_10_i386
SOLARIS_10_amd64
Win64
Win64_ia64
2.05
Fixed problem with the challenge response timeout not being read. Note the following issue:
The Timeout field on the service properties dialog requires a value. If empty, the GUI will crash!
2.04
2.03
Fixed problem with abnormal CPU usage of Linux.

Performance improvements done to handle 5000+ profiles.
Fix bulk configurator to accept less than 1 second timeout on service alarm and host ping timeout.
March
2009
January
2009
January
2009
Update supported platform list.

Note: Version 2.03 of the net_connect probe requires version >=3.x of the robot to run on the Windows platform.
2.00
Port challenge response feature added.
May 2008
Ability to paste into the IP Address field added.

Contact info field added to host properties, to be used in alarm messages.
ICMP packet loss feature added.
Added ability to add Services in the Bulk configurator.
Added ability to enter IP addresses with leading zeros.
Added search button to find IP or Name.
The Port scan windows can be resized.
Bug fixes: default value of ip address 0.0.0.0 removed.
1.82
Update UNIX platform list.

Added payload data to ICMP packet.
March
2008
1.80
Fix: GUI could cause a runtime error if you entered an integer value as name for a new profile.
Fix: ping test response times should be correct now
September
2006
Fix: drag-n-drop bug that would allow you to drag a host from GUI and drop it in another program, it would disappear
from net_connect GUI
Fix: IP-addresses should be easier to edit.
Feature: Bulk configuration tool.
Feature: "Group" variable can be used in alarm messages.
Feature: Ability to generate alert when ping latency threshold exceeds a customizable limit.
Feature: When adding a profile with a name that already exists, program will suggest a new name.
Feature: The new host dialog has improved code to detect and suggest parent group/folder.
Feature: Simple port scan utility.
Added more standard port numbers to probe definition.
Fixed name-resolution problem in UI.
1.70
Added ping sweep functionality.

Added support for overriding the global QoS setting per profile.
February
2005
Fixed minor UI issues.

Added support for profile groups in UI.

The probe (version 3.11 or later) threshold configurations can be migrated to standard static alarm thresholds using the threshold_migrator 2.10
version or later with CA UIM 8.31 or later. For more information on how to migrate a probe, see the threshold_migrator (Threshold Migrator) docu
ment.
Probe specific alarm configurations in the probe monitors will be replaced by Static Alarm and Time Over Threshold configurations.
The QOS_NET_CONNECT, which monitors the ping response, will not be migrated

The net_connect probe must be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. Probe OOB configuration requires 256 MB of RAM
CPU: 3GHz dual-core processor, 32-bit, or 64-bit

The net_connect probe requires the following software environment:
The net_connect probe requires the following software environment to migrate with threshold_migrator probe:

Ping sweep feature not working for IPv6.
Probe generates the "failed to execute in schedule time" alarm. Refer net_connect Troubleshooting for the workaround.
To display data on USM using the host IP address, create a key, is_devid_ip, in the probe Raw Configuration under Profiles > Host sec
tion. Set the key value as "yes" and the probe will create DEV files based on the host IP address.
net_traffic (Network Traffic Monitoring) Release Notes

The net_traffic (Network Traffic Monitoring) probe monitors the network bandwidth usage in terms of packets per second, and bytes per second.
For example, you can monitor the actual bandwidth usage of NetBIOS, web usage, and so on. To obtain this information, you can define a
profile that contains the criteria such as source, destination (host or network) addresses, port or service information, and so on.
The probe supports Service Level Management by sending alarms and Quality of Service (QoS) messages.
Contents
Revision History
Revision History
Version
Description
State
Date
1.43
Fixed Defect:
GA
December
2015
GA
October
2014
Probe was displaying current value instead of accumulated value. A key, use_accumulated_value_in_qos, has been
added in Raw Configuration to enable you to change the value as required. Support case number 00168839
Note: For more information about this key, refer Upgrade Considerations.
1.42
What's New:
Added support for Solaris 64-bit SPARC.
Fixed Defect:
Fixed a defect where the probe did not start on the Linux x64 system. Salesforce case 00127020
1.41
Fixed a defect where maxSample value in QOS message is not reflected for 10 GBps interface.
April 2013
Fixed a defect for Manual dump creation.

Fixed the Help field to show the updated version.
Fixed a defect where the Profile Name does not display completely in Profile Utilization.
1.40
Added the probe defaults.

Fixed a crash issue with Trigger Activation on DumpManager.
December
2012
1.30
Added support for 64-bit Linux platform.

March
2011

Fixed Handle Leak present in version 1.22.
1.22
Fix: Deployment problems related to 64-bit Unix platforms.
July 2008
Fix: Deployment problem related to 64-bit Windows platforms.

1.20
Added: Promiscuous mode selectable.
May 2008
Added: 64 bit support.

Added: 'friendly' names to network devices.
Added: source and destination ports in profile definitions.
Added: alarm on no traffic.
Fix: Crash on post install release version.
Fix: non thread safe sleep function.
Fix: packet dump file io performance issue.
Fix: security issue with callback deletion of files.
1.15
Added: Post-install event that will try to select a adapter based on traffic sniffed and save it to CFG. Probe will not
support blank adapter in CFG file.
August
2006
Removed: Automatic detection of adapters.

Fix: GUI: Check/uncheck "Monitor bandwidth usage" now properly activates "Apply" button.
Fix: GUI: removed hotkeys S and P.
Fix: GUI: bandwidth field is split into 2 fields, one for speed and a dropdown for Kbps/Mbps/Gbps.
Fix: GUI: more human readable names for installed adapters is shown in GUI (Windows).
Fix: probe start/stops properly.
Fix: you can no longer type in network adapter manually.
Fix: GUI: Port column in sniffer sorts correctly.
Fix: GUI: should now use the IP address of currently selected adapter (on the probe), if "My computer" is used as a filter
in sniffer mode.
Fix: QoS samples should now be correct. You can now use 1 second QoS interval if you really want to.
Feature: probe maintains a 'state', and doesn't die if network card doesn't exist. sends an alarm and keeps running.
Doing so allows user to reconfigure the probe from GUI.
Feature: added support to override default snaplen in config file.
Feature: define traffic triggers that initiates automatic packet dump.
Feature: GUI will attempt to locate your ethereal installation and set it as your favorite network analyzer tool.
Feature: GUI: "filter properties" window (under profiles) has been redesigned (to be more consistent with "Filters" in
sniffer).
Fix: Program should no longer crash if you close the sniffer window without stopping a live sniffer session.
Fix: Problem with IP statistic values fed from probe. Values did not sum up to 100%.
Fix: Problem if you click on 'Network utilization (user profiles)' button when you already have this window open and
maximized.
Fix: Program should no longer crash if the path specified to your external analyzer tool no longer exists.
Fix: Text input fields for Bandwidth and Network bandwidth fields did not properly activate 'Apply' button until after they
lost focus.
Feature: Added hotkeys.
1.14
Ported to Solaris and Linux.

The net_traffic probe is installed on systems with the following minimum resources:
March
2004

The net_traffic probe requires the following software environment:
Windows packet driver included with the installation. (WinPcap 3.1, libpcap 0.9[.x]).
Ensure that winpcap library does not exist on the 2008 32 bit system where net_traffic probe will be installed.
Consider the following upgrade scenarios:
Upgrading the probe from version 1.41 or earlier to version 1.43
Set the value for use_accumulated_value_in_qos as yes in the Raw Configuration interface to enable probe to send accumulated value in the
QoS data. By default, the key value is set to no to send the current value in the QoS data.
netapp (NetApp Storage Monitoring) Release Notes

The NetApp Storage Monitoring (netapp) probe sends SNMP GET queries to specified NetApp devices. The probe then transforms the query
results into alarms and Quality of Service messages for Service Level Agreement (SLA). The netapp probe uses a set of predefined SNMP OID
templates available on most NetApp devices. You can configure a profile to integrate the NetApp device into the CA UIM monitoring solution.
The probe supports SNMPv1, SNMPv2c, and SNMPv3. You can configure the probe for NetApp Ontap 7.2x to 8.1 c-mode and 7-mode operating
system.
Important! The probe only supports English characters.
Contents
Revision History
SNMPv3 Support
Revision History
Version
Description
State
Date
1.38
Fixed Defects:
GA
December
2015
GA
October
2015
GA
July 2014
GA
September
2013
GA
June 2013
Updated the metrics document with information on latency value calculations. Support case numbers 00162025,
00165092
The probe did not use case-sensitive discovery of monitoring objects. The same value was displayed for different
objects with the same name. Support case number 244877
Updated the probe to optionally enable case-sensitive discovery of monitoring objects. For more information, see the Co
nfigure General Properties and Create Agent Profile sections of the netapp IM Configuration.
The probe displayed incorrect indicators for monitor status in probe interface. Support case number 70007002
1.37
Fixed Defects:
The units for LUN Latency checkpoint did not match on the UMP and SLM database. Salesforce case 00165092
The probe used to restart after seven days. Salesforce case 0070001695
While creating a new custom monitor, the probe was unable to sort OIDs appropriately when the number of OIDs
exceeded nine. Salesforce case 00167324
Incorrect alarms were generated for 'Not between' operator as only one of the two defined threshold values was getting
saved. Salesforce case 00155465
1.36
Fixed Defects:
Fixed an issue in which the Volume Names were sometimes displayed in HEX ASCII code in the Alarms and Logs. Sale
1.35
Fixed Defects:
Fixed an issue where LUN Size Used and LUN Percent Used were showing up as zero and exclamation sign on some
values.
Need to capture LUN Latency - System Metric from NetApp Probe.
Fixed an issue where the probe was unable to create Static monitor.
Fixed the failure of Threshold monitoring.
Fixed the failure to apply Auto-configuration.
Fixed a defect in count based metrics.
Fixed the Snmp V3 authentication issue.
1.34
1.33
Fixed Netapp where the probe was having issue with get values with Netapp C mode.
Fixed netapp where logs showing Error messages for the calculation of multiple OIDs.
Fixed netapp agent reports value of zero on formulas using more than one OID variable.
March
2013
Fixed netapp where agent profile does not appear to make use of default global timeout/retries settings.
Fixed a defect where netapp displays incorrect value for average based checkpoints.
Fixed a defect where netapp gives incorrect unit labels for QoS definition
"QOS_STORAGE_PERCENT_CAPACITY_USED_VOL".
1.32
1.31
Fixed a defect where checkpoint of type formula base on more than one OID was giving wrong values.
Fixed a defect for issues with Netapp Monitoring.
Fixed a defect where log file size was not changing.
January
2013
December
2012
Fixed a defect where description in Netapp - Total Capacity - aggregates - Monitor Properties is incorrect - and should
say 'GB'
Fixed a defect where formula used to calculate Total Raw Capacity was using 1000 instead of 1024.
Merged monitoring frequency latency changes.
1.30
1.24
Added support for NetApp Ontap 8.1 Cluster-mode operating system

Merged memory leak changes and a crash issue.
Merged monitoring latency changes.
Merged changes to display string corresponding to integer value of state OID.
Merged changes to display correct snapshot index.
Added Probe Defaults for the probe.
November
2012
November
2012
1.22
Following fixes are covered in this release:
June 2012
Two new threshold operations ('=a or =b' and '!=a and !=b')
Scale limit for SNMP query of more than 300 OID indexes fixed.
Custom Monitors not working properly or correctly documented.
Online HELP was not properly launching from IM GUI
Improved DEBUG and ERROR logging.
ONTAP API QOS metrics not showing correctly in Infrastructure Manager GUI
netapp.cfg flag to force graceful probe restart at a designated hour of the day
Added new monitors: CP Time, LUN Read Latency, LUN Write Latency, and Other Latency monitors to DTA
configuration file.
Note: Version 1.21 was an interim hot fix release which is deprecated by 1.22.
1.20
Following fixes are covered in this release:
March
2012
QOS metrics delivery stops for certain configurations after running for a limited time due to a deadlock.
netapp.exe process continued to consume memory due to leak.
HEX data showing up in 'target' (aka instance name) field in published QOS metrics in the data engine for LUN volumes.
1.12
Following fixes (and minor enhancements) are covered in this release:
December
2011
QOS showing 0 when string value is being used as a number

Qtree metric shows unable to access MIB
QOS showing 0 when string value is being used as a number
Qtree metric shows unable to access MIB
Fix for the upgrade issue reported by David Miller (Hotfix) Do not have case number or DE number.
Corrected the unit for QOS_STORAGE_TOTAL_CAPACITY_AGGR to GBytes.
Creating a new custom monitor is not intuitive - usability issue. (Check for doc update, if any)
Data does not sort when clicking on column header in probe config UI
Display appropriate QOS in the QOS Name field for Monitor Properties (so QOS names are randomly picked by user
unknowingly.) The IOPs, Disk Read and Disk Write Monitors into the Netapp Basic Monitors template (for UMP storage
dashboard to show data)
Fix for system Status (and any string type monitor value compare thresholds) giving false positive.
1.10
Support for ONTAPI is added.

Added monitors for LUN size used and LUN Percent Used using ONTAPI.
October
2011
Added monitor for Total Raw Capacity using ONTAPI.

Added monitors for Latency.
Added support to get delta per second for monitor values.
Enhanced templates with additional monitors.
Support for default templates.
1.00
Initial version of NetApp with the GUI.

The netapp probe is installed on systems with the following minimum resources:

The netapp probe requires the following software environment:
March
2011
Consider the following information before you deploy and use the probe:
SNMP v3 requires that your network community strings are at least eight characters long.
ONTAPI requires user with administrator privileges.
The monitors dependent on ONTAPI are available only when ONTAPI Settings are configured. The requirement also applies to the Auto
Configuration node.
The netapp Basic Monitors template is available as the default template for the 7-mode. The netapp C-mode Basic Monitors template
is available as the default template for the c-mode.
Consider the following information before you upgrade the probe from version 1.36:
The Default Templates Settings from the previous version are not retained.
The default template is applied when the Default Templates Settings screen is opened and OK is pressed.
SNMPv3 Support
The netapp probe is enabled to monitor agents based on the SNMPv3 protocol. Ensure the following guidelines are met when monitoring the
SNMPv3 agents.
If your probe instance is monitoring multiple SNMPv3 hosts, ensure that the EngineID of all hosts are unique. Duplicate EngineID may
cause sporadic connection timeouts and failure alarms.
The probe does not allow you to create duplicate profiles for an SNMPv3 agent. Do not use the Raw Configure option or add directly in
the configuration file for creating multiple profiles for the same SNMPv3 agent. This can result in some unpredictable results by the probe.
nfa_inventory (NFA Inventory) Release Notes
The NFA Inventory probe is the integration point between CA Network Flow Analysis and CA Unified Infrastructure Management (CA UIM). The
integration allows you to view NetFlow/IPFIX/Jflow/Sflow data in context with SNMP data for an interface inside of the Unified Management Portal
(UMP).
The views displayed are:
Stacked Protocol Trend - In
Stacked Protocol Trend - Out
Top Hosts
Top Conversations
The integration enables customers to drill from CA UIM to CA NFA for additional diagnostic detail, and back to CA UIM from within CA NFA.
Multi-tenancy is supported.
interfaceMappingDelay - the time in minutes after an inventory update to perform the mapping of interface groups to origins. The
minimum value is 1, the maximum value is 15, and the default value is 5.
interfaceMappingBatchSize - The number of interfaces to request origins for in a batch. The minimum value is 1, the maximum value is
20000, and the default value is 1000.
Contents
Revision History
Probe Specific Configuration Requirements
Revision History
Version
Description
1.1
Added support for Single Sign-on (SSO) between USM 8.31 and NFA 9.3.2:
SSO without LDAP or SAML2
State
Date
GA
July 2015
GA
May 2015
SSO with LDAP only

SSO with SAML2
Added support for Multi-tenancy.
1.0
Initial version.

Only one instance of the probe is supported.
The probe must run within the same hub domain as the Discovery Server.
The probe must be configured with the same origin as SnmpCollector.
Current versions of CA NFA, UDM, Discovery Server, and wasp must all reside in the same hub domain.

The CA NFA Inventory probe requires the following software environment:
CA Unified Infrastructure Management Server v8.31 or later, including SNMP Collector 2.1 or later
Note
It is recommended that the CA Unified Infrastructure Management Server and CA Unified Management Portal (UMP) are the same
version.

CA Network Flow Analysis R9.3.2 or later
3. Use Admin Console to access the probe configuration user interface.
None.
The NFA Inventory (nfa_inventory) configuration is available through the Admin Console user interface only and not through the Infrastructure
Manager (IM) user interface.
notes_response (IBM Notes Server Response Monitoring) Release Notes

The IBM Notes Server Response Monitoring (notes_response) probe monitors the performance of the services that the Notes server accesses
from the IBM Domino server. For example, you can use this probe to monitor the performance of the email server, to check the time taken to open
the database, availability of the Notes server, and so on.
You can also generate alarms and QoS based on the results of the monitoring process.
Revision History
Known Issues
Revision History
Version
Description
State
Date
2.32
Fixed Defects:
GA
December
2015
GA
April 2013
Updated Probe Specific Software Requirements section of the Release Notes to include the information about the
type of operating system (32-bit or 64-bit) to be used while deploying the probe. Also, added a Known Issue to mention
the probe version that is compatible with 32-bit servers installed on a 64-bit system. Support case number 00169666
Updated the content for Set up IBM Notes client. Support case number 70000934
2.31
Fixed a defect where server of address format cn=???/ou=???/o=??? was not getting processed
2.30

March
2013
2.20
June 2010
2.12
Added fix to load a proper 'mail_response' alarm level value to the messages listview.
January
2010
2.11
Implemented code locking when calling Lotus Notes APIs. The change is implemented to avoid deadlocks when multiple
profiles execute in parallel.
October
2009
Built with new API and new compiler. Note that the requirements have changed to Notes Client >= 7.0.2 and Robot >=
3.00
2.04
Normalized latency value so that they can not become negative.

API call memory management revised.
February
2008
Always re-create notes-nimbus.ini from notes.ini on running the setup wizard.

2.01
Threaded version.
Improved handling of error situation.
July 2006
1.18
Fixed message text problem.
September
2005

Memory: 2-4 GB of RAM. The OOB configuration of the probe requires 256 MB of RAM.

Robot version 7.6 or later (recommended)
Notes client version 7.0.2 or later
Domino Server version 7.0.2, 8.0 and 8.5 (Release 8.5 (359))
Important! Ensure one of the following:

When you deploy the probe on the system with IBM Notes client, both the client and the system must be 32-bit.
When you deploy the probe on the system with IBM Notes server, both the server and the system must either be 32-bit or
64-bit.
Known Issues
The probe has the following known issue:
You cannot use the probe version 2.31 or earlier to monitor 32-bit servers that are installed on a 64-bit system, either locally or remotely.
notes_server (IBM Domino Server Monitoring) Release Notes

The IBM Domino Server Monitoring (notes_server) probe monitors the performance of the IBM Domino Server. The probe monitors server
latency, server availability, server statistics variable values, and named views of the log.nsf file.
When installing notes_server probe on 64-bit Windows, both the notes_server and the notes_server64 probes are installed. The notes_server64
probe is a native 64-bit program that only reads 64-bit IBM Domino server. Use the notes_server probe to monitor 32-bit IBM Domino server or
IBM Domino client. If you notice that other executable has turned red after deployment, you can delete the same.
Contents
Revision History
Revision History
Version
Description
State
Date
1.53
Fixed Defects:
GA
November
2015
GA
July 2013
The notes_server64 probe could not be configured. Support case numbers 00166940, 00167461
Updated the probe documentation for Regular Expression support when you configure the probe to monitor the Statistics
variable. Support case number 70000737
1.52
Fixed crash issue
1.51
Added probe defaults

Added 64 bit Support
1.40

Added support for reading alarm tokens from cfg
March
2013
March
2011
1.30
June
2010
1.20
Built with new API and new compiler.
December
2009
Note that the requirements have changed to Notes Client >= 7.0.2 and Robot >= 3.00.
1.10
Setup Wizard fix.
March
2005

The notes_server probe must be installed on systems with the following minimum resources:

The notes_server probe requires the following software environment:
IBM Domino server versions 7.X, 8.0 and 8.5 (tested with IBM Domino server versions 7.0.2, 8.0 and 8.5 (359))
IBM Domino client version 7.0.2 or later
Note: The IBM Domino server and IBM Domino client must be installed on the same system where the notes_server probe is deployed.
nq_services (NQ Services) Release Notes
The nq_services probe makes services internally available to CA Network Flow Analysis and other CA NetQoS products to allow these products
to interrogate CA Unified Infrastructure Management (CA UIM) for data.
Contents
Revision History

Revision History
Version
Description
State
Date
1.0
Initial version.
GA
August 2015

The probe must be deployed on the same robot as the ugs v8.30 probe.
The probe requires no user configuration.

The nq_services probe requires the following software environment:
CA Unified Infrastructure Management Server v8.31 or later, including SNMP Collector 2.1 or later
Note: It is recommended that the CA Unified Infrastructure Management Server and CA Unified Management Portal (UMP) are
the same version.
CA Network Flow Analysis R9.3.2 or later
None.

None.
nsa (Script Agent) Release Notes

The nsa probe is used as a tool for system integration, reporting, and on-site enhancements allowing for direct integration with:
CA Unified Infrastructure Management (UIM)
ADO
SNMP
Basic system and network functions
nsa does not require a run-time environment (including UIM), and contains all functionality within a single binary.
The user may encrypt sensitive data (for example, UIM or database login passwords) and may incorporate this into the scripts.
Contents
Revision History
Revision History
This section describes the history of the revisions for the nsa probe.
Version
Description
State
Date
2.06
Fixed an issue in which extra lines of text occurred in the CLI when the probe was active. Salesforce case 00158212
GA
April 23, 2015
GA
March 3, 2015
2.05
Fixed an issue in which running nimbus.alarm() using an 88-character suppkey crashes nsa. Salesforce case 0009
2078
Fixed an issue in which SNMP v3 failed to create SNMP objects. Salesforce case 00117304
2.04
Fixed an issue in which the nsa probe segmentation faults when probe-based authentication is used on custom probes
on SLES11 64 bit.
GA
September 9,
2014
2.01
Fixed the linking with MySQLConnector for C on Linux. Earlier, these had runtime dependencies on MySQL libraries.
GA
December 31,
2010
GA
November 29,
2010
GA
June 30, 2010
GA
December 30,
2009
GA
September 30,
2009
GA
August 14, 2009
2.00
Added the nsa Debugger -D option.

Fixed action.email() and action.sms() to return true when ok.
Added Oracle support.
Added support for variable removal by using setvariable("var",nil)
Added MySQL support. nsa now attempts to load libmysql.dll / dynamically when a mysql connection string is
passed.
Added NSA_VERSION and NSA_PID as global constants.
Added the file.mkdir() method.
Added the nimbus.encrypt() and nimbus.decrypt() methods.
1.12
Fixed an issue with database.open when using an encrypted (-p/-P) string.

Added the file.checksum method.
1.11
Added support for utilizing dynamic libraries.

Added the pds.copy() method.
Enhanced the subscriber callback to include PDS handles to the udata and header data structures.
1.10
Fixed an issue with converting deep PDS structures to Lua tables.

Fixed memory leak in the mid, left, and right string functions.
Added pdsTable support.
Changed the require lookup path for modules (LUA_CPATH).
Fixed an issue with snmp.set.
Fixed an issue with snmp.addvariable.
Added security level to the probe.addcallback function.
Added exit code from the executed command in action.command.
1.0
Initial Release.
No additional hardware requirements.
The nsa probe requires the following software environment:
The MySQL Connector for C 6.0.2 for your platform (http://www.mysql.com/downloads/connector/c/#downloads) if you want to use
MySQL.
The nsa package is installed by dropping it onto the target Robots in Infrastructure Manager, and installs to the SDK directory.
nsdgtw (CA Nimsoft Service Desk Gateway) Release Notes

The CA Nimsoft Service Desk Gateway (nsdgtw) probe is a gateway between CA Unified Infrastructure Management (CA UIM) and CA Nimsoft
Service Desk (CA NSD). The probe allows you to create CA NSD incidents with bi-directional synchronization when alarms are assigned to the
CA UIM user. The probe also automatically acknowledges the corresponding CA UIM alarms when the incidents are closed in CA NSD.
The probe supports testing of the following:
Network access to the CA NSD.
Login session on CA NSD along with user name and password verification.
The nsdgtw probe does not generate any QoS. Therefore, there are no probe checkpoint metrics to be configured for this probe.
Contents
Revision History
Known Issues
Revision History
This section describes the history of the revisions for the nsdgtw probe.
Version
Description
State
Date
1.23
Fixed Defects:
GA
December
2015
GA
July 2014
GA
April 2013
GA
August
2012
GA
June
2012
GA
March
2012
The probe did not generate incidents in CA NSD when the alarm message included special characters. Added optional
ability in Admin Console to remove invalid characters from alarms before the probe creates an incident. Support case
numbers 00148396, 00154262
For more information, see the Configure General Properties section in nsdgtw AC Configuration.
The probe did not accept whitespace character in the Requester Organization field. Support case number 00167819
What's New:
Added ability to set up proxy settings for connection to CA NSD through Admin Console.
For more information, see the Set Up CA NSD Connection section in nsdgtw AC Configuration.
1.22
Fixed Defects:
Fixed a defect in which the probe was sending unnecessary calls to NSD against the CLEAR alarms whether a ticket is
associated or not. Salesforce case 00136199
Fixed a defect for probe locking feature available through controller probe. Salesforce case 00108629
Fixed a defect in which the probe was not generating ticket for alarm message containing special characters. Salesforce
case 00117647
1.21
Fixed probe startup issue on Linux machine.

Fixed unwanted logging issue at NSD side.
1.20
Features added:
User can now configure "Resolved" ticket status to trigger alarm closure along with "Closed" ticket status.
Alarm closure can now close the ticket and user can configure what status ("Resolved" or "Closed") should be set on the
ticket if the alarm closes.
User has now an option to either map alarm severity with ticket severity, with ticket priority or having no mapping at all.
The ticket priority or severity can also be changed to a configurable value when an alarm is cleared/acknowledged.
Fixed defects:
Incorrect "Time Origin", "Time Arrival" and "Time Received" shown on the NSD ticket.
Incorrect field mapping for affected device service desk.
The "Message:" prefix would not occur in the "Symptom Description" field of NSD incident ticket
1.15
Fixed defects:
Unable to open "Field Mapping" in nsdgtw probe after we remove all the Standard fields from the Field Mapping list.
Unable to remove the field mapping when it is in edit mode.
1.14
Modified the probe to ensure that the severity for incidents is updated correctly based on the severity mappings
configured for the probe.
Also corrected the logic to save the last incident check timestamp to ensure that all alarms are successfully
cleared/acknowledged and none are skipped or missed during processing.
1.13
Modified the probe to ensure that all the NMS Alarms are cleared out when multiple incident tickets are closed within
service desk.
GA
February
2012
1.10
Added support for standard field mapping.
GA
June
2011
GA
May 10
2011
Added new field requester organization with dollar variable support for multi-tenancy support.
1.06
Removed auto assign filter for suppression count causing recursive incident creation.
Custom mapping section added in cfx file.
1.05
Alarm filters modification done.
GA
May 2
2011
1.04
Added hostname instead of source name in symptom details.
GA
April 2011
Added default severity mapping.

Added default gateway timezone to GMT.
Added check now feature in configuration GUI.
Added alarm filters for auto assignment of alarms.
Added drop down list for custom fields mapping.

The nsdgtw probe can be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. The OOB configuration of the probe requires 256MB of RAM

The nsdgtw probe requires the following software environment:
Test the Auto Operator function of Nimsoft Alarm Server (NAS) and the Auto Assignment feature of the probe. CA recommends you to ensure
that rules in both the features do not assign an alarm to the same CA UIM user. Erroneous assignment rules can create additional or duplicate
tickets.
Some assignment considerations are as follows:
If you assign an alarm to Service Desk user, then un-assign and assign it back, a duplicate incident is created.
If you have Auto Alarm Assignment turned on in nsdgtw with some filter, no alarms are assigned in NMS. However, an incident is created
in the Service Desk. Now, if you try to assign the same auto alarm in NMS, a duplicate incident is created in Service Desk.
If you already have NAS auto-operator set for certain conditions, CA recommends you to not use Auto Alarm Assignment. In case both
(NAS auto-operator and auto-alarm assignment) catch similar filter criteria for an alarm, it results in duplication of incidents.
If Offline Management is turned off and user performs alarm assignment to Service Desk user while probe is turned off, no incident is
created in Service Desk. For more information on Offline Management, see nsdgtw Advanced Configuration.
Known Issues
The Alarm Severity and SLA section saves the mapping details to the configuration file of the probe. The probe uses the mapping details
but does not display the mapping details.
The probe does not generate incidents in CA NSD when the alarm message includes special characters. You can select Discard Invalid
Characters in the General Configuration section of the hostname node in Admin Console. The probe automatically handles invalid
characters when configured using Infrastructure Manager (IM) GUI.
Proxy settings for connection to CA NSD are only available through the Admin Console interface of probe version 1.23 or later.
ntevl (NT Event Log Monitoring) Release Notes

The NT Event Log Monitoring (ntevl) probe monitors the event logs of the host system where the probe is deployed. As a system administrator,
you can use the probe to view the event logs. You can create a monitoring profile to filter the events that you want to monitor and generate alarms
for unexpected events. The probe also generates QoS to store historical event data and generates trends over time to analyze the system and
application performance. The probe does not have any option for adding a network system for monitoring the events.
Note: An event is a significant activity in a system or application, which requires user attention. Microsoft Windows logs all such events
and make them available to the user through the Event Viewer tool. This process helps the user to identify and troubleshoot the
hardware or software issues in the system.
Contents
Revision History
Supported Locales
System Specifications
Known Issues
Revision History
This section describes the history of revisions for ntevl probe.
Version
Description
State
Date
4.21
Fixed Defect:
GA
December
2015
Beta
December
2015
GA
October
2015
GA
July 2015
Updated information about monitoring security logs for Microsoft Domain Controllers in documentation. Support case
number 70006645
What's New:
Added support to exclude System, Application and Security logs for monitoring.
4.20
Fixed Defect:
ERROR eventlog was not mapped with the correct UIM alarm severity. Support case number 70007434
What's New:
Re-designed the probe to improve scalability.
The new probe design is applicable for Windows Vista and later.
4.12
Fixed Defect:
Alarm variables were not expanding for non ASCII Characters. Salesforce case 00166695
The probe crashed due to incorrect logging in the probe. Salesforce case 00162278
4.11
What's New:
Added a note in Admin Console GUI article that describes how Event Count alarm will work only if at least one event is
triggered for the matching profile. Salesforce case 00159016
4.10
Beta
June 2015
4.03
GA
March
2015
4.02
What's New:
Added the Enable Position File Backup Interval check box on the Properties tab. Salesforce case 00145842
Fixed Defects:
Messages appeared in reverse order when the probe was run on Windows Server 2003 Standard x64 Edition R2
(SP2). Salesforce case 00149339
Probe CPU consumption was very high. Salesforce cases: 00146816, 00152031, 00151572, and 00150479
January
2015
4.01
What's New:
September
2014
Updated the probe IM GUI and Admin Console GUI for specifying the character encoding in different locales.
corrupt the probe configuration file.
Fixed Defects:
Fixed the issue of removing quotes, double quotes, and comma from the event message text when generating alarms.
Salesforce cases: 00142620, 00140474
Fixed the issue of not displaying Critical alarm severity in the drop-down list, when the probe is hosted on Windows
Server 2008 operating system. Salesforce case 00132207
Fixed the defect of IM probe GUI where the probe is not saving updated log level in the probe configuration file. Salesfor
ce case 00140301
Fixed the issue where is the probe is not resolving the $severity_str variable value. Salesforce case 00140472
Fixed the defect where the probe is adding extra characters to the date string while displaying event details on IM probe
GUI and in alarms. Salesforce cases: 00134035, 00133326
3.91
Fixed the memory leak issue where the probe is not able to handle the events when the events count is in 10 digits or
more. This issue was causing high CPU and memory utilization by the probe.
April 2014
Fixed the defect of Browse button on the VB GUI of the probe under the Event selection tab. The Browse button was
getting tempered when user clicks the button for selecting a batch file.
Fixed defect of the Description field on the VB GUI of the probe under the Event Properties dialog by allowing user to
paste text in the field.
3.90
What's New:
December
2013
Added support for displaying locale specific severity strings.

Added XML view of the event in the probe GUI.
Fixed Defects:
Defect fixed related to probe defaults by deactivating the allerrors profile, which was causing flood of alarms after
deploying the probe.
Defect fixed related to two QoS definitions, which the probe was generating even if all the profiles are inactive by
default.
Defect fixed related to alarms not being sent when domain name is provided in lower case.
3.85
3.84
Fixed defect related to the Japanese event logs, where the event description is not displaying on the probe GUI.
Fixed the suppression key override issue, which was truncating the suppression text after 50 characters and appending
the profile name.
September
2013
July 2013
Fixed issue related to Alarms generated from ntevl probe are getting de-duplicated.
3.83
Incorrect event type display issue on japanese text suppported system fixed
April 2013
Fixed: Log Window does not maximize

Latest event not displayed in Probe GUI, Issue fixed now.
Fixed a defect where select_events does not correctly work from probe utility
invalid characters - slow performance.
3.81
Added functionality to monitor Operational and Admin event logs (introduced from Vista/Windows 2008 onwards).
December
2012
Fixed a defect where probe GUI is slow in responding in case of large number of events.
Fixed memory leaks.
3.70
Added functionality to allow generation of variables in post message.

Added functionality to provide run command on matching of criteria in watchers.
Fixed the issue of high CPU usage in event mode.
Added 2 byte character support.
Fixed issue of exclusions in alphabetical order missing.
September
2012
3.63
3.62
Fixed Soc defects

Fixed a crash occurring when filtering out events.
Added support for adding new variables in profiles without configuring thresholds.
3.61
Fixed windows event message NOT displayed in Alarm Console on UMP.

Added support for converting event description to a localized form.
July 2012
November
2011
October
2011
Fixed a crash which use to occure when event description is more than 2K sizeerror handling from BEA weblogic server
3.60
Support for critical event logs in Windows 2008.
June 2011
Operator(<, >, <=, >=, =, !=) support for alarm counter.

Support for -Z option to reset the position and start the probe normally.
Fixed DST time difference in Windows NT 5.2.
Fixed SOC defect.
3.51
3.50
Added fixes for web-based Service Oriented Configuration

February
2011
December
2010

Added fix for probe stopping to work after an event storm.
Added fix for repeated message problems.
Added suppression fix.
Fixed number of instances logic to allow old behavior.
2.36
Applied a fix to remove extra white space which was appearing after removing newline characters.
2.35
August
2010
July 2010

3.41
June 2010
Fixed defect in display of logs on 64-bit Windows 2008 Server platform.

3.40
Enhanced the probe to allow generation of variables from message body, and also to send alerts on this variables.
May 2010
Added support to raise an alert only after a particular number of instances of an event within a particular time frame.
3.30
March
2010
3.23
Resolved the problem where only a partial event list was fetched. The most obvious situation was on computer restart.
December
2009
3.22
Added a fix in evlWmi library for fetching InsertionStrings column value from WMI if Message value is not available.
November
2009
3.21
Fixed a crash in evlWmi library.

November
2009

3.20
Added fix in the probe and GUI for replacing hard returns with user defined delimiter in event description field.
Fixed Day Light Saving time issue.
October
2009
Stopped using regular expression comparisons to detect duplicate events.

2.34
Latest Version For Windows 2000

Fixed an issue in the Exclude tab where the excluded events were not automatically activated after upgrading the probe
from versions that did not have an option to activate or deactivate such events.
Now, after upgrading from previous version, the probe activates all the excluded events, by default.
September
2009
3.10
Updated configuration file for event logs, added preconfigured event logs (Application, System and Security) in section.
Updated WMI library for handling custom event logs.
September
2009
Added key (wmi_timeout) in the setup section of configuration file. This key can be used to set the WMI query timeout in
seconds if there are huge number of events.
No propagation alarm functionality issue fixed.
Added fix in Windows Vista running service pack version 1 or below to fetch the event indexes using WMI. Vista version
prior to SP2 had an issue where the probe was unable to fetch the event indexes properly.
Added a fix in the evlWmi library for handling computer's FQDN. In some windows platforms when a machine is in a
domain the computer field of event logs shows computer FQDN. Earlier the probe was failing when checking
watchers/excludes computer field.
3.02
Fixed an issue in the Exclude tab where the excluded events were not automatically activated after upgrading the probe
from versions that did not have an option to activate or deactivate such events.
July 2009
Now, after upgrading from previous version, the probe activates all the excluded events, by default.
Added support for checking underlying OS version detection, if the OS version is Windows 2000 or below the probe
triggers an alarm and stops execution
3.01
Fixed a probe crash on probe deactivate.
April 2009
Fixed some minor GUI issues.

Optimized GUI & probe code performance.
Added support to prevent alarm flooding in upgrade Added a $evlData variable to get the data associated with the
event.
Changed the library from evl to evlWmi (wmi event interface)
2.31
Fixed the problem of probe not starting on Windows 2000.
April 2009
Fixed some minor UI issues.

Added support for alarm queuing to avoid NAS overloading.
Added severity_str as a message variable.
Fixed some the win64 porting issues/warnings.
Modified the msgEnterVar code to use NimBUS apis instead of custom code.
Fixed the clear exclude issue in evl.lib.
Active/Inactive checkbox for the exclude profiles.
Fixed the bug with the profile ordering in GUI.
Event message field lookup revised for Vista/2008.
2.23
2.21

Improved error handling on finding log file sizes.
Note: For version 2.21 and higher of this probe, NimBUS Robot version 3.00 (or higher) is a prerequisite. You are
December
2008
September
2008
2.15
Modified regular expression comparison code to avoid problems with large string comparisons in exclude profiles.
September
2007
2.14
Opens registry with the minimum necessary access rights to avoid generating security events on Windows 2003 Server.
January
2007
2.13
Added possibility to enter 'localhost' in the computer field of the watch and exclude profiles to only match on events from the
local machine to the probe.
November
2006
2.10
Modified initial configurator sorting of events. Added option to allow starting the configurator without fetching the event list.
January
2006
2.02
Support added for variables in alarm message, suppression key and subsystem. The variables are: profile, description,
source, event_id, category, message, log, severity, user, computer and time_stamp.
Quality of service message added for number of events found.
Supported Locales
From version 4.0 and later, the ntevl probe supports the following non-English locales:
December
2004
B-Portuguese
French
German
Italian
Japanese
Korean
Spanish
The probe supports the following system encoding for the different locales:
Encoding
Name
UTF-8
Unicode (UTF-8)
UTF-16BE
UnicodeBigUnmarked
UTF-16LE
UnicodeLittleUnmarked
Shift_JIS
Japanese (Shift-JIS)
ISO-2022-JP
Japanese (JIS)
ISO-2022-CN
Chinese(ISO)
ISO-2022-KR
Korean (ISO)
GB18030
GB2312
Big5
Chinese Traditional (Big5)
EUC-JP
Japanese (EUC)
EUC-KR
Korean (EUC)
ISO-8859-1
Western European (ISO)
ISO-8859-2
Central European (ISO)
windows-1250
Central European (Windows)
windows-1252
Western European (Windows)
System Specifications
The probe version 4.2 is tested for the following operating system configurations in both event and poll modes.
Note: However, CA recommends using event mode over poll mode when event generation rate is over 400 events/sec.
Operating system
RAM
Number of processors (rate)
Number of cores
Windows 2008R2, 64 bit
8 GB
2 (3GHz)
Windows 2012, 64 bit
4 GB
1(3GHz)

The ntevl probe should be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. The OOB configuration requires 256 MB of RAM


The ntevl probe requires the following software environment:
Probe version 4.0 and later requires:
WMI service is enabled
Probe version 3.9 or earlier requires:
Nimsoft Monitor Server 5.1.1 to 7.6 or CA Unified Infrastructure Management 8.0 or later
Robot 5.1 or later
WMI service is enabled
Notes:
For Windows version older than Windows Vista and Windows 2008, when events are requested by WMI query, latest event is
fetched and displayed as the first record.
For Windows 2008 and Windows Vista (till service pack 1), the oldest event is displayed as the first record.
For Windows Vista (service pack 2, and above), latest events are displayed first.
If the current OS is Windows Vista (service pack version <= 1), the probe retrieves the oldest record information by executing
WMI query instead of calling API(GetOldestEventLogRecord). In Vista, the call to GetOldestEventLogRecord always
returns 1.
The ntevl probe monitors the event logs for new messages and generates alarm messages according to the defined setup. You can configure the
probe for triggering each time a new message is added to the event log. Also, you can check the event log for new messages at a fixed interval to
reduce the system load. Consider the following points while installing the ntevl:
Restart the probe when the time zone is changed or when "Automatically adjust clock for daylight saving changes" is selected or cleared.
The Windows event log watcher probe version 3.0x uses WMI to retrieve the event logs. Accessing windows event logs using WMI may
severely affect the performance of the Windows 2000 system. If the probe is deployed on Windows 2000 system, the probe raises an
alarm and stops execution.
When upgrading the probe from any previous version to 4.00 or later, delete the conf_ntevl.exe file from the temp > util folder.
Important! During upgrade, if event_record_id in ntevl pos file differs from the ID of the event viewer (windows application), then the
probe first reads the previously generated events and sends an alert on newly generated events if -Z option is not provided in argument.
Known Issues
The probe v4.0 and later have the following limitations:

The probe does not support monitoring of forwarded events.
The probe does not display events generated by any unregistered publishers.
The Raw Configure GUI of the probe is not supported for non-English locales because it can corrupt the probe configuration file. Use
only standard probe GUI for any updates.
Note: In case you are using CA UIM 8.0 or later, you can use Raw Configure GUI only through the Admin Console.
If monitoring profile contains locale-specific characters, then that monitoring profile cannot be viewed in any other locale from the IM
probe GUI. You can use the Admin Console GUI to view the profile on a different locale.
CA recommends using event mode over poll mode when the number of events generated is more than 400 events/sec and if log file size
is larger than 10496 KB.
If you run the probe in multi-threaded environment, probe alerts order can differ from event generation order. This happens only when
generation rate is high for monitoring an event.
The IM probe GUI displays an error message and Admin Console GUI can stop responding when the Maximum Event to Fetch field
value is more than 1000. You can update value of the field to 1000 or less to resolve the issue. The actual event count can vary for
different system configuration.
Do not use same profile name for ntevl and adevl probes, when deployed on same robot.
Use either IM GUI or AC GUI of the probe to avoid any unexpected issues that can occur during probe configuration.
The events of Microsoft Windows applications and services can display different category in the probe GUI as compared to the Event
Viewer tool of Windows. For example, the event (event Id is 701) shows the event category as Online Defragmentation in Event Viewer
tool and Performance in the probe GUI.
You get a Package Editor error when you start the ntevl probe along with any other i18n supported probe for the first time.
The probe GUI can display an error message while viewing event details when the Maximum Event to Fetch field value is more than
1000.
With CA UIM 8.0 or later, follow these steps:
1. Open the Raw Configure GUI.
2. Update value of the fetch_number key (under setup section) to 1000 or less.
With NMS 7.6 or earlier, follow these steps:
1. Open the IM probe GUI.
2. Update value of the Maximum Event to Fetch field to 1000 or less (under the Setup > Properties tab).
The Admin Console version of the probe has the following additional limitations:
The probe does not show the details section of events having XML content.
ntp_response (Network Time Protocol Response Monitoring) Release Notes

This probe tests the Network Time Protocol (NTP) or Simple Network Time Protocol (SNTP) server response. The probe measures the quality of
a network connection through the following parameters:
Response time
Offset
Jitter
No contact with the server
Server is not updated from any peer
Server is not fully initialized
The ntp_response probe checks the current time from NTP (Network Time Protocol) or SNTP (Simple Network Time Protocol) servers, and also
measures the response time of the query. The probe can also request status information from NTP servers. Starting with version 1.4 onwards, the
ntp_response probe also supports NTPv4.
Alarms can be generated on response time and, in the case of NTP servers, offset and jitter (in comparison with their time reference). Alarms can
also be generated on error situations
Contents
Revision History
Revision History
This section describes the history of the revisions for the (ntp_response) probe.
Version
Description
State
Date
1.40
What's New:
GA
February
2015
GA
April 2014
GA
April 2013
GA
November
2012
Added support for NTPv4.

Added a feature to select the NTP server version when configuring the probe.
1.32
1.31
To view the updated alarm subsystem Id as 1.1.3.7, reinstall the probe after removing any previous version of the probe from
the target robot. In case of upgrading the probe version, the alarm subsystem Id remains same as 2.5.
Fixed a defect to send clear alarm when response time is less than threshold.
Fixed a defect on sending QOS_DEFINITIONS on inactive profiles and when QOS are not checked.
Deactivated the test profile in the probe defaults.
1.30
Added Solaris support for the following:

SPARC 64 bit (10/11)
SPARC 32 bit
x86_64 bit (10/11)
x86_32 bit
1.24
Fixed SOC issues.
GA
June
2012
1.23
Introduced source override for Alarm and QoS.
GA
April 2012
1.22
Fixed SOC issues.
GA
December
2011
GA
March
2011
GA
March
2011
GA
June
2010
1.21

Fixed token id mappings with alarm messages.
1.20

Added fix to properly deploy the probe on 64-bit Linux machines
1.10
Added support for Windows 64-bits.

Added support for Linux (both 32-bits and 64-bits).
Added fix for proper severity level in alarms.
Added fix to send alarms on negative values of offset and jitter limits also.
1.04
Added sending of initial clear alarm on all profiles on startup and reconfigure.
GA
May 2010
1.0
Fixed problem which sometimes caused program failure in the configurator when using the 'Test' button.
GA
April 2004

The ntp_response probe should be installed on systems with the following minimum resources:


The ntp_response probe requires the following software environment.
Robot 7.1 or later (Recommended)
Java JRE 6 or later
Probe Provisioning Manager (ppm) probe version 2.38 and above (for Admin Console GUI only)
Note: For SOC functionality, NM server 5.6 or later and UMP 2.5.2 or later is required.
ntperf (Performance Collector) Release Notes

The Performance Collector (ntperf) probe can monitor performance counters on Windows NT. The probe is configured to send alarms on
unexpected values and generate quality of service (QoS) messages. While installing ntperf probe on 64-bit Windows, both the ntperf and ntperf64
probes are installed. The ntperf64 probe is a native 64-bit program that will only read 64-bit objects. Use the ntperf probe for 32-bit performance
objects.
Contents
Revision History
Supported Locales
Revision History
Version
Description
State
Date
2.02
What's New:
GA
August
2015
Added support to send QoS source as short name (only host name) or fully qualified domain name.
Added support of dynamic variables (object, counter, and instance) in static and dynamic threshold messages. This is
applicable on CA Unified Infrastructure Management 8.31 or later.
Added a note in IM and AC GUI Reference articles to recommend the user to provide a value in the Threshold
Operator and Threshold Value fields, as the probe is unable to send an alarm if these fields are blank. Salesforce case
00167095.
Fixed Defect:
The probe was displaying duplicate instances for a counter of a specific object. Salesforce case 00164171
2.01
What's New:
GA
June 2015
Beta
May 2015
Added localization support for B-Portuguese, Chinese (simplified and traditional), French, German, Italian, Japanese,
Korean, and Spanish languages for Admin Console GUI only.
Added a note in Infrastructure Management and Admin Console GUI Reference articles as the probe generated alarms
when the reverse of the defined operator was met. Salesforce case 00153155
2.00
What's New:
Added localization support for B-Portuguese, Chinese (simplified and traditional), French, German, Italian, Japanese,
Korean, and Spanish languages for Admin Console GUI only.
Fixed Defect:
The QoS_WIN_PERF_DELTA value was always calculated as 0, if the Counters and Objects were defined and the Instances
were left blank. Salesforce case 00153243
1.90
What's New:
March
2015

1.89
Fixed Defect:
January
2015
The probe was unable to fetch the current value for the Token Request counter of the AD FS object. Salesforce case
00150809
1.88
Fixed Defect:
October
2014
The probe was not calculating delta value of some counters. Salesforce case 00137816
1.87
Fixed Defect:
April 2014
Fixed the defect in which the clear alarm message text is same as the corresponding priority alarm message text.
Fixed the defect where the counter value was different in clear alarm message text from the actual value.
1.86
Fixed Defect:
March
2014
Fixed a defect of incorrect Metric Id for the QOS_WIN_PERF_MAX, which is now having the same Metric Id as the
QOS_WIN_PERF. This updated Metric Id helps in plotting the UMP graph correctly.
1.85
Fixed Defect:
June 2013
Fixed a defect of not displaying the counter and instance values on the probe GUI.
1.84
February
2013
1.83
Fixed SOC Defects.
June 2012
1.82
Fixed issue with fetch current in GUI. Improved error handling.
May 2012
Removed clear on restart.

Fixed alarm message defaults in the configuration tool.
1.81
1.80

January
2011
December
2010

1.72
Modified the Profile properties dialog to make it resizable.
November
2010
1.71
June 2010
1.70
May 2010
Fixed an issue where the probe issues a clear alarm for all the profiles even if no alarm has been raised previously.
1.61
Added cluster_setup section to the default probe configuration file to enable cluster support for ntperf64.
May 2010
Delta calculation changed from using the averaged value to the actual value.
Fixed problem where the delta alarm needed to be enabled for the delta QoS messages to be sent.
1.60
Added sampling support for value.

Added message pool feature in GUI.
September
2009
Added max value support for Value QoS.

Fixed some minor bugs in UI and probe.
Added configurable scaling factor for object values.
Added support for counter type used by Microsoft ISA Server.
1.50
April 2009
1.42
December
2008
1.41
Rebuild with new NimBUS libraries.

Repackaged so that both ntperf and ntperf64 are installed on 64-bit Windows.
September
2008
Note: Please note that, for version 1.41 and higher of this probe, NimBUS Robot version 3.00 (or higher) is a prerequisite.
You are advised to carefully read the document "Upgrading the NimBUS Robot" before installing/upgrading.
1.29
Altered handling of profiles where no object or counter is specified. With the new behaviour the probe will look for
objects and counters with no name.
September
2007
Changed ntperf to be dedicated for 32-bit objects and ntperf64 for 64-bit counters.
1.27
Fixed problem with calculation of some disk data.
May 2007
Does not show duplicate counter instance names.

Windows: Added native Win64 support.
Optimization: skip objects not asked for.
Added logging on log level 4 to discover properties of specific performance objects.
Improved handling of empty performance objects.
Performance scan is skipped if no active profiles are defined.
1.23
Fixed high CPU usage occurring sometimes when switching clusters.
June 2006
Fixed probe crash when specifying non-existent objects in GUI.

Added one more Windows counter type that generates QoS.
1.21
To be able to store Quality of Service information for separate object instances in separate QoS tables, an additional
configuration option is added to the profile: 'When object has instances, add instance name to QoS table name'.
1.12
Configuration fix for reading/storing profile descriptions.

Re-use buffer size on configuration requests to optimize probe response on queries.
Lifted '%' sanity check limit.
Supported Locales
The ntperf probe version 2.0 and later supports the following non-English locales:
B-Portuguese
French
German
March
2006
January
2005
Italian
Japanese
Korean
Spanish
Note: The non-English locales are supported only on the Admin Console.

version 1.00 and later on CA UIM 8.31 and later.
Important! The Infrastructure Manager GUI of the probe will not be available if the probe is migrated using threshold_ migrator.
Opening the IM GUI will display a message informing that the probe can only be configured using the Admin Console and will redirect
you to the probe Release Notes.
For more information on how to migrate a probe, see the threshold_migrator (Threshold Migrator) probe document.
Notes:
If both ntperf and ntperf64 probes are deployed on same robot, you are recommended to configure either ntperf or ntperf64 at
a time for successful migration.
configurations.
Any relational operators in the probe configuration will be reversed.
User defined variables will not be available.

If you migrate the probe using threshold_migrator, the relational operators in the probe reverse their logic. While alarms are initially generated for
files not matching the relational criteria, the alarms now are generated for files matching the reversed criteria.
For example, if the probe was configured to generate an alarm for a threshold value that was not less than or equal to the QoS value, it will now
generate the alarm for the threshold value greater than the QoS value.The operators before and after reversal are listed below:

The ntperf probe should be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. The probe OOB configuration requires 256 MB of RAM.
CPU: 3GHz dual-core processor, 32-bit or 64-bit.

The ntperf probe requires the following environment:
Java JRE version 6 or later (for Admin Console GUI)
Microsoft .NET Framework 2.0 is required on 64-bit versions of Windows XP and Windows Server 2003
The probe requires the following software environment to migrate with threshold migrator probe:

The ntperf probe has the following limitations:
For some counter types that work on difference of the previous value, first value of QoS is always null, as there is no previous value to
measure delta.
In European languages, ',' is referred as '.' in decimal values. Currently this functionality is not supported. You must enter '.' for all
decimal values.
The probe GUI and the Alarm messages also display the ',' as a '.'.
When you create a monitoring profile, the Object Selection Tab lets you select the performance object for monitoring along with its
threshold values. When you select an Object and a Counter, there can be instances with similar names. You must add a new key value in
your system registry to show instances in the application_pprocessID format.
This registry key impacts only .NET applications being monitored.
You require administrator rights on your system to modify the registry.
Follow these steps to add a new key value in the system registry and show instances in the application_pprocessID format:
1. Open regedit in your system.
2. Navigate to the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\.NETFramework\Performance
3. Right-click in the blank space and select New > DWORD (32-bit) Value.
4. Enter the following parameters for the new value:
Value name: ProcessNameFormat
Value type: REG_DWORD
Value: 1 (0x00000001)
Thus, the new key is added in the system registry.
ntservices (Microsoft Windows NT Services Monitoring) Release Notes

The ntservices probe monitors the list of NT services installed on the Windows system where the probe is deployed. The probe uses Remote
Procedure Calls (RPC) to detect which services are running. The service state is compared with the defined desired state for each service on this
system. If the actual state differs from the expected state, the probe can either do one or both of the following options:
Report the mismatch in an alarm message

Try to force the service into the desired state
Some examples of the NT services are: ActiveX Installer, Application Information, Bluetooth Support Service, Computer Browser, and Credential
Manager.
Contents
Revision History
Known Issues
Revision History
This section describes the history of the revisions for the ntservices probe.
Note: Salesforce case(s) may not be viewable to all customers
Version
Description
State
Date
3.24
Fixed Defect:
GA
December
2015
GA
October
2015
GA
July 2015
GA
June 2015
The probe crashed when the user customized the configuration file by clearing the <Services> tag. Salesforce cases
70006602, 70006788, 70006179
3.23
Fixed Defect:
The probe did not generate clear alarms in the following situations: Salesforce case 00169873
Specified expected running state was 'not stopped' and retrieved actual state was Started.
Specified expected running state was 'not running' and retrieved actual state was Stopped.
3.22
Fixed Defects:
Fixed a defect where the probe displayed garbled special characters in the Service Name in the French language. Sales
force case 00164218
3.21
Fixed Defects:
The probe does not revert back to earlier configuration after policy based templates are deactivated.
The probe did not accept baseline configurations from policy based templates.
Field descriptions in factory templates display numbers instead of actual descriptions.
3.20
June 2015
3.18
March
2015
3.17
Fixed a defect where an application error, Event ID 1000, was generated while upgrading the probe version. Salesforce case
00140528
August
2014
3.16
Fixed a defect where a service with angular brackets in the service name was not being monitored. The angular brackets are
now supported in the service name. Salesforce case 00127106
July 2014
3.15
Fixed issue where stopping/starting of the existing or newly created services which are of automatic type was not
generating the clear alarm even if the expected state was identical with the actual state. Salesforce cases: 00128528,
00128511, and 00122930
June 2014
Fixed issue where different Metric Ids were getting generated for the clear alarm and its corresponding priority alarm.
3.11
This is now available in Admin Console GUI.
March
2013
3.11
Fixed a crash for a service which is active but not present on system services.
Fixed a defect where apply button is not active at QoS value changed.
3.10
Added a feature for overriding the default suppression key profile name.
Added support to monitor (send Alarms and QoS) for "Not Responding" service status.
January
2013
December
2012
Fixed a defect where pause and resume functionality was not working.
Added Probe Defaults for the probe.
2.94
2.93
Fixed SOC Issue.

Changed remote authentication test order to 'user/password', 'impersonation', 'implicit'. This functionality is used from
other probes.
June 2012
May 2011
Reverted default settings for profile created for detected services.

Fixed QoS interval in QoS message if interval multiples is used.
2.91
2.90
Added fixes for web-based Service Oriented Configuration

Added support to automatically activate all services set to automatic start when deployed.
Added support for enabling/disabling QOS for newly added services.
January
2011
December
2010
Fixed crash in GUI when last profile is deleted.

Prohibited use of whitespace in configurator.
Fixed defect in probe to use $profile_name in alarm messages.
Added support in probe to set QoS interval in multiple of alarm interval.
Added option to override clear alarm message and added support for $robot variable.
Added a configurable option to raise alarm only once on state change.
2.71
June 2010
2.70
March
2010
2.60
Added support for handling 'not stopped', 'not running' fields in the Expected Running state.
Added support for displaying newly added services and raising alarms when a new service is added or started.
August
2009
Added support for raising an alarm/raising an alarm & removing service from profile when a service is removed from the
system.
Fixed an issue where alarm doesn't get cleared when a service is restarted.
Added support for automatically adding services to profile based on "All"/"Running, "Automatic" criteria.
Added support for using $robot variable in alarm messages.
Fixed an issue related to probe not sending clear alarm when automatically add new services feature is disabled.
Fixed an issue in probe installation/upgrade. Now the probe modifies service states "start pending", "continue pending",
"pause pending" and "paused" as "running" and state "stop pending" as "stopped".
2.50
2.43

Increased default ping timeout used when fetching remote services data for other probes.
2.41
Rebuild with new NimBUS libraries.

April 2009
December
2008
September
2008
2.34
Moved privilege handling from thread to main process to avoid potential crash situation.
Threaded 'list_services' call to be able to better support using this call from other probes for fetching remote computer
data.
Modified authentication order when fetching remote computer data.
April 2008
2.32
Added flag bOkToSendClear, to avoid sending clear for services with Action = force state, at restart
Fixed config read - global settings were only read on probe restart.
October
2007
Known issue:
When other probes use the ntservices probe to fetch service information from remote services, situations can occur where
the probe is taking a long time serving request. In this situation the probe will be unavailable for other requests. For this
reason, do not set the list_services timeout to high.
2.30
Added menu to delete profiles.

Added column sorting of alarm messages list.
September
2007
Added field profile_name that can be edited and used in alarm strings.
Added alarm monitoring of service account (log on as) credentials.
Added list of active profiles, service state and credentials callback for dashboard use.
Added configurable timeout to list_services callback.
Added option to ignore number of restart attempts.
2.21
Read of "action = ignore" for profile corrected.
December
2005
2.11
Modified restart counter algorithm.Bottom of Form.
June 2004

The ntservices probe must be installed on systems with the following minimum resources:

The ntservices probe requires the following software environment:
Probe Provisioning Manager (ppm) probe version 3.10 or later (required for Admin Console)
Known Issues
There is a key delete_profile_section in the setup section of configuration file. If the value for this key is set to yes, all service profiles
are deleted from the probe. The services are again configured depending on the configurations in the Default values for added
services section of the probe GUI.
The Admin Console probe version has the following additional limitations:
ntservices Probe UI does not dynamically reload the state of the services. You must reload the configuration after changes are made to
the service through services.msc (Windows OS).
oracle (Oracle Database Monitoring) Release Notes

The Oracle Database Monitoring (oracle) probe allows you to monitor your Oracle databases to detect, diagnose, and resolve Oracle performance
issues when they occur. This information is presented to a database administrator as reports, and as alarms when database performance crosses
a specified threshold.
You can set up multiple configurable monitoring profiles to extract vital information about your database servers at specified intervals. Database
administrators can use this information to tune and optimize database performance, and do capacity planning.
The probe monitors local or remote Oracle database instances, periodically scans through monitoring profiles, and applies checks to the
instances. The probe successfully monitors:
32-bit Oracle client on a 32-bit OS
64-bit Oracle client on a 64-bit OS
Note: The oracle probe also provides monitoring support for Real Application Cluster (RAC) and is configurable only through Admin
Console.
With version 4.8 and later, the oracle probe introduced multi-tenancy support. The probe allows you to monitor Oracle 12c container database
(CDB) and pluggable database (PDB). Oracle 12c database introduces multitenant option with new CDB and PDB concepts. A CDB is similar to a
conventional database containing controlfiles, datafiles, data dictionary, redo logs, tempfiles, undo, and so on. A PDB only contains information
specific to its objects.
Contents
Revision History
Monitoring Capabilities
Prerequisites
Add Environment Variables
Add CDB/PDB Connection Entries
Provide Access Rights for a Database User
Upgrades
Oracle Supported Versions and Clients
Known Issues
Revision History
This section describes the history of the revisions for the oracle probe.
Version
Description
State
Date
4.91
Fixed Defects:
GA
September
2015
GA
June 2015
When creating a profile from Admin Console, all the profile checkpoints are now inactive, by default. Salesforce case
00159509
When opening the probe in a deactivated state, the probe displayed incorrect upgrade message text. Salesforce case
00160547
The probe displayed incorrect status of the activated checkpoints in the Status tab. Salesforce case 00168455
On a non-Windows OS, the probe now displays the Device ID of the monitored Oracle database. Salesforce case
70002729
4.90
What's New:
Added support for AIX 6 and 7 platforms.
4.81
What's New:
Updated the probe Help link.
December
2014
4.80
What's New:
November
2014
Added support for Oracle 12c Container Database (CDB) and Oracle 12c Pluggable Database (PDB).
Added a checkpoint to monitor the number of PDBs in a specific CDB.
Fixed Defects:
Fixed a defect where the Profile Timeout alarms were visible in alarm console even though the probe connection was
successful. The alarms did not clear even if Clear Alarm on Restart check box is selected. Salesforce case 00144941
4.71
4.70
Fixed a defect where the Oracle probe GUI flickered on clicking Profiles/Checkpoints in the Status tab. Salesforce case
00143137
Added support for Oracle 12c.
Removed support for the Oracle versions 9i and 10g.
4.61
Fixed Defects:
October
2014
September
2014
July 2014
TNS alarms were visible in alarm console even after the probe connection was successful. The alarms did not clear
even if user changes the connection and Clear Alarm on Restart check box was selected. Salesforce cases:
00122633, 00132174, 00121391
SQL timeout alarms were getting generated irrespective of the checkpoint and had incorrect suppression key.
For the tablespace that has autoext as Y, probe was calculating wrong value of FREESP variable. Due to the wrong
calculation, the messages displayed incorrect values. Salesforce case 00132777
The probe package of 32-bit was getting installed on 64-bit AIX system. (Salesforce Case: 00132673)
Instance name was not coming in the check_dbalive alarm message where the connection was unsuccessful. Salesfor
ce case 00131416
4.60
New Feature:
March
2014
Implemented the Oracle RAC features including 20 new checkpoints for RAC.
Defects Fixed:
Fixed a defect where global cache checkpoints are not returning any value for oracle 11.
Note: RAC can be configured only through Admin Console GUI.
4.56
New Feature:
March
2014
Added a callback to determine whether dependencies are present on the system where probe is deployed so that the
probe runs successfully.
Note: This feature is only applicable for Admin Console GUI.
4.55
Defects Fixed:
January
2014
Defect fixed related to the Oracle probe not displaying metrics for all tablespaces. The UMP was not displaying QoS as
a chart in the metric tree for all Oracle native checkpoints.
Defect fixed related to QOS_ORACLE_tablespace_alloc_free Pct and QOS_ORACLE_tablespace_free Percent
checkpoints, generating alarms for each tablespace with almost identical values.
4.52
4.51

Fixed Profile showing template checkpoints if a group is used.
Fixed ORA-00923 and ORA-24333 error coming in locked_users and rollback_segments checkpoints for Oracle 11g
profiles.
Fixed missing no_next_extents messages in the cfg file.
Fixed Status tab not showing current values of monitored checkpoints.
February
2013
January
2013
4.50
Fixed Incorrect alarm message in database_size checkpoint.
June 2012
Added support for AIX 5.

Fixed issue with improper functionality of Suspend/Resume profile.
Changed default alarm message of redo_logs checkpoint.
Fixed issue of oracle probe crashing in Solaris.
Added support to modify connection failure message.
Fixed the value of autoextend field in tablespace_alloc_free checkpoint.
Update the resource_util checkpoint query for the oracle bug "Incorrect (always increasing) values showed in
v$resource_limit for the transactions field [ID 412314.1]".
Added support to skip DBA/SELECT_CATALOG_ROLE checking.
Fixed issue in checksum calculation during custom template creation.
Fixed issue of the checkpoint threshold in profile, if the checkpoint is marked as static into the profile.
Fixed exceptions in Exclude test.
4.43
Modified the Query for the dataguard_gap checkpoint.

Suppression key (alarm key) & qos key is changed for dataguard_gap checkpoint. When the probe upgrades from
previous versions, the QoS series for this checkpoint break due to changes in the QoS target key.
November
2011
Added new i18 tokens for the dataguard gap.

4.42
Added support for oracle client 11.2 on SOLARIS Sparc.

Fixed an issue occurring on Unix platforms where multiple probe executable were getting spawned instead of a single
executable.
4.41
While creating a custom checkpoint $instance variable is visible in Variable Window.
August
2011
June 2011
Custom checkpoint can now be updates when opened through Status Tab.
Fixed the issue of sending null QOS for dict_cachehit_ratio
Supports Oracle client 11.2 for Linux 32-bit & 64-bit systems.
This version does not support oracle client 11.2 for solaris sparc system.
Fixed Memory Leak issue
Fixed an issue in tablespace_free checkpoint where the probe was incorrectly calculating free tablespace % for temp
tablespaces.<\li>
Fixed one more issue in the tablespace_free checkpoint where the free tablespace calculation was incorrect.
Internationalization corrections.
4.31
Added validation if custom query is blank.

Added code to fetch query from file in edit mode.
September
2010
Fixed other minor GUI issues that are related to a custom checkpoint.
Added field in the custom query tab to select predefined connections.
Added support for the role-based login.
Added support for alarms.cfg.
Added functionality for delta calculation in custom checkpoint.
Added code to prohibit the use of whitespace in configurator.
Added support to confirm if the user has enough rights to run the query.
Removed validation of adding at least one threshold while creating a checkpoint.
Fixed GUI crash defects.
Fixed defect to return valid checksum after restart for Custom query.
Fixed defect for metric remaining_extents takes way too long to complete.
Fixed defect; so, correct binary is deployed in 64-bit Linux.
Fixed defects in v4 framework library.
4.20
June 2010
Fixed an issue where the probe was reporting incorrect values in the GUI.
4.11
Fixed a crash in the probe by applying fix to v4 helper library.

Fixed defect that is related to tablespace_free checkpoint.
4.10
Added a checkpoint active_connection_ratio for monitoring percentage of active connections to total available
connections.
March
2010
March
2010
4.04
Fixed an issue in the database size checkpoint where total database size was reported incorrectly.
January
2010
4.03
Fixed defects in few checkpoint variables and alarms.
January
2010
Added fix for memory leak.

Added fix for a SQL query timeout.
4.02
Fixed defect in GUI.

Fixed defects in few checkpoint variables.
December
2009
Probe now sends NULL QoS for all the QoS defined in the QoS list when no data is received.
3.91
Configuration for no_next_extent, invalid_objects, and tablespace_deficit corrected.

Known issue: The Oracle RAC system statistics that are used for 'gc_' checkpoints, starting with Oracle 10.1, are no
longer available. Therefore these checkpoints return no value when activated.
3.90
Added Support for Solaris.
September
2008
July 2008
Added numbers of objects alarm for these checkpoints:

no_next_extent
invalid objects
tablespace deficits
Hotfix for Locking users
Note: Profiles with these checkpoints must be removed and recreated, because of new functionality.
3.75
Hotfix for Checkpoint Invalid Objects
March
2008
Note: While the package contains Solaris binaries, Solaris is not a supported platform now. Installation of this probe on
Solaris is not recommended.
3.74
Memory leak corrected.
February
2008
3.73
Added new NimBUS libraries.
January
2008
3.71
Removed support for Oracle 8.0.x.
December
2007
3.70
Corrected minor problems with filters

Added support for Oracle 11g
3.64
Crash in some checkpoints if instance not available fixed

QoS error with session_waits fixed
November
2007
November
2007
Error with profiles containing "." fixed

Problem with sga_memory_free - objects containing ":" fixed
Queries for Oracle 10g do not try to use rules based optimizer any more
3.62
QoS errors fixed

Problem in period setting (scheduling) corrected
One-time run error (scheduling) fixed
Profile timeout suppression key corrected
Calculation of free space for temporary and undo-tablespaces corrected
buf_cachehit_ratio problem fixed
July 2007
3.60
Multiple QoS per checkpoint
June 2007
exclude lists
# of samples for alarming
new checkpoint long_queries
auto-update (GUI)
new checkpoint tablespace_size
new checkpoint database_size
new parameter log-size
new parameter "Alarm Source"
buf_cache_hit_ratio query adjusted for Oracle 10.2
3.53
3.52
A clear is only issued if an alarm has been sent.

High CPU load for gc_ checkpoints in Oracle 8 solved
Negative values in sort_ratio problem solved
January
2007
December
2006
datafile_status problem with SYSTEM tablespaces solved (v$datafile_header now used instead of v$datafile)
datafile_status and dbfile_io object threshold saving on UNIX systems problem solved
tablespace_alloc_free - query changed
3.50
Internal - Config file template added

LINUX built with Oracle 10 libraries
3.05
3.04
"tablespace_free" calculation for multi-file tablespaces corrected.

Linux enabled
August
2006
July 2006
June 2006
Remaining_extents - problem with 'UNKNOWN' values fixed

QoS time corrected
buf_cache_hitratio fixed
checkpoint execution time report
Interval value calculation corrected
QoS source name corrected to robot name
'invalid_objects' suppression key corrected
new 'buf_cachehit_ratio' formula
Multi-threading - every profile runs in a separate thread
Scheduling - every checkpoint can have its own schedule
Multiple thresholds - every checkpoint can have more than one threshold
Message pool - messages can be customized and reused among checkpoints
Connection retry - for every connection there can be number of attempts defined, before the probe raises an alarm
Resizable GUI windows - all windows with lists are resizeable
2.17
Instance name at "locked_users" checkpoint message

Added Linux support for package.
2.16
Instance name at "locked_users" checkpoint message

Linux support fix
2.12
10g tolerancy
new checkpoint lock_waits
user_locks and locked_users changed
error in buf_cachehit_ratio_users fixed
check for % in password removed
start parameter -n to change probes name
keeping time_cnt through restart (24hour cycle)
GUI - new button "info" to display GUI and executable version numbers
March
2006
November
2005
March
2005
The oracle probe monitors the following information about either local or remote database instances:
Database uptime
Tablespace growth
Database growth
Tablespace status
Index status
Data-file status
Rollback segment status
Fragmented segments
The extents that can't extend
The data dictionary cache-hit ratio
The data buffer cache-hit ratio
The Redo copy latch-hit ratio
The library cache-hit ratio
The sort-hit ratio
PGA resource consumption (monitor memory consumption of Oracle users)
The rollback segment contention
The number of invalid objects
The number of chained rows
The number of users currently logged onto the server
The MTS response time
The number of MTS waits
The enqueue resources
The UGA memory usage
User locks and locked users
Lock waits event time
The user buffer cache-hit ratio
System waits and user waits
Datafile i/o
System statistics
Global cache service utilization for RAC
Global cache fusion ratio for RAC
Global cache lock get time for RAC
Global cache lock conversion timeouts for RAC
Global cache average lock get time for RAC
Global cache corrupt blocks count for RAC
Global cache lost blocks count for RAC
Number of Long running queries
Tablespace size
Database size
Resource utilization %
Dataguard status
Dataguard gap
Dataguard timegap
Tablespace temp free
Active users
Flash recovery area memory free
Active connection ratio
The number of PDBs in a CDB

The oracle probe must be installed on systems with the following minimum resources:
Memory: 2-4 GB of RAM. Probe OOB configuration requires 256 MB of RAM.

The oracle probe requires the following software environment:
Windows: Oracle Client (Net Services) 11.x or 12.x
Linux and Solaris: Oracle Client 11.x or 12.x
Note: Oracle INSTANT CLIENT is not supported.
Role-based login is also supported for e.g. sys as sysdba

From NMS 7.5 and later, RAC is supported but can only be configured from Admin Console.
Prerequisites
Before deploying the oracle probe on your robot, you must perform the following activities:

Add the Oracle libraries in the system PATH environment variable and configure the Oracle client appropriately before installing the oracle probe.
You can update the variables by using the controller GUI or by editing the nimbus script at /etc/init.d.
Note: Restart the robot after updating the nimbus script.
Setting the ORACLE_HOME path is mandatory to generate the correct Device ID, routing the QoS messages and alarms to the correct device,
and viewing data on the Unified Service Manager (USM).
On Windows platform:
Set the ORACLE_HOME path to the directory where the client is installed. For example, C:\oracle\product\11.2.0\client_1.
On UNIX or Linux platform:
1. Set the ORACLE_HOME path to the directory where the client is installed. For example, /home/oracle/app/oracle/product/12.1.0/client_1.
2. Set the ORACLE_SID path to the service identifier name that you configured by using the Oracle client.
3. Set the LD_LIBRARY_PATH path to the Oracle library directory. For example, /home/oracle/app/oracle/product/12.1.0/client_1/lib.
Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) security mechanism implemented in the Linux kernel. SELinux has
three basic modes of operation: Enforcing, Permissive and Disabled. In Permissive mode, SELinux is enabled but does not enforce the security
policy, only warns and logs actions. The Current Enforcing Mode must be Permissive on Linux platform.
Follow these steps for setting the Current Enforcing Mode to Permissive:
1. Open SELinux Management and the SELinux Administration window appears.
2. In the Current Enforcing Mode list, click Permissive.
3. Close the SELinux Administration window.

The oracle probe version 4.8 and later support multi-tenancy monitoring. Add CDB/PDB details in the tnsnames.ora file on your system before
creating a connection with the database.
You must ensure that the required database details are present in the tnsnames.ora to monitor a CDB, as shown in the example.
CDB1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.112.16.128)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = CDB1)
)
)
where CDB1 is the service name.

You must add the PDB details to the tnsnames.ora to monitor a PDB, as shown in the example.
PDB1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = oracle-cdb)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = PDB1)
)
)
where PDB1 is the service name.

A non-root probe user must have appropriate access rights to the Oracle database to run the oracle probe for monitoring. Only a root user or a
sysdba can grant permissions to the user.
To grant access rights, connect to the Oracle server as a sysdba and run the following queries:
create user nimmon identified by nimmon;

grant connect to nimmon;
grant select_catalog_role to nimmon;
grant select on gv_$sort_segment to nimmon;
grant select on sys.ts$ to nimmon;
For a CDB connection, prefix c## or C## to the user name and grant required permissions to the user.
create user c##nimmon identified by nimmon;
Upgrades
When upgrading the oracle probe from previous versions to version 4.80 or later, the PDB_Count checkpoint is added as a template and is
available in all the profiles. By default, the checkpoint is disabled. Enable the checkpoint to monitor the number of PDBs in a particular CDB. This
checkpoint will work only for those profiles that are linked to a CDB connection. For other profiles, no result is displayed even if the checkpoint is
enabled.
Oracle Supported Versions and Clients

The following matrix summarizes client and server combinations that are supported by the Oracle Database Monitoring probe.
Server Version
Client Version
12.1.0
11.2.0
11.1.0
12.1.0
Yes
Yes
Yes
11.2.0
Yes
Yes
Yes
11.1.0
Yes
Yes
Yes
Known Issues
The probe may not connect to the database after you install or upgrade the Oracle client. Restart the probe after installing the client for a
successful connection.
The oracle probe must not be configured on both the Infrastructure Manager (IM) GUI and Admin Console (AC) GUI.
The probe configuration for both the IM GUI and AC GUI is separate. For example, any profile that is created in the IM GUI is not
available on the AC GUI and must be recreated.
While upgrading the oracle probe from version 4.56 and earlier to version 4.60 or later, ensure that the PPM, service_host, and MPSE
are restarted for the RAC functionality to become usable.
The users cannot create custom alarm messages. Hence, they need to select an existing alarm message.
In Oracle RAC, from Oracle 11.1 and above, the term global cache is replaced by gc in all checkpoints. Therefore, if any custom query
in Oracle 11g or 12c includes the term global cache, then no value is returned. The RAC functionality is supported and configured
through Admin Console GUI only.
On Windows 64-bit platform, the probe cannot be installed into the default directory - "Program Files (x86)". A bug in Oracle Client is
causing connection errors, if the application home directory name includes special characters, like "(" (Oracle Bug 3807408).
Error ORA-12705 together with log entry "OCIEnvCreate failed with rc = -1" can happen, if environmental variable NLS_LANG is set.
Solution is to set this variable to empty space in the controller environment.
On 64-bit Linux, user may get a warning message of insufficient access rights when connection test is performed, even if all the required
access rights are provided. The connection can still be used to schedule the profile. Please ensure all the required access rights are
provided to the user.
In custom checkpoints, if query tries to fetch data from a table with more than 32 columns, probe will limit the number of columns to 32.
If a custom QoS is added to an existing monitoring profile, the Unified Management Portal (UMP) creates a separate node, Custom, in
the Metric section. It does not display the user-defined description and unit.
If a custom checkpoint is added to an existing monitoring profile, the Unified Management Portal (UMP) creates a separate node,
Dynamic, in the Metric section. It does not display the user-defined description and unit.
The Admin Console GUI of the probe has the following additional limitations:
On version 4.90 of the probe, custom QoS in a checkpoint do not generate alarms if the default QoS of the checkpoint is deleted. This is
applicable for AIX 6 and AIX 7 platforms.
While upgrading the oracle probe from version 4.56 and earlier to version 4.60 or later, ensure that the PPM, service_host, and MPSE
are restarted for the RAC functionality to become usable.
The users cannot create custom alarm messages. Hence, they need to select an existing alarm message.
The oracle probe must not be configured on both the Infrastructure Manager (IM) GUI and Admin Console (AC) GUI.
Dynamic Population of Message Text field with the corresponding Message field selected in the drop-down list at runtime is a limitation
of the PPM. On creating a checkpoint with a new threshold, first select message and save it. After the reload operation, the message text
field gets updated with the corresponding message text.
If you see PPM-023 error and Unable to Retrieve Configuration issues, click Retry or reopen the AC GUI.
In Oracle RAC, from Oracle 11.1 onwards, the term global cache is replaced by gc in all checkpoints. Therefore, if any custom query in
Oracle 11g or 12c includes the term global cache, then no value is returned.
To discover RAC-specific nodes, the ppm probe should be deployed on the same subnet as the oracle probe.
On Windows 64-bit platform, the probe cannot be installed into the default directory - "Program Files (x86)". A bug in Oracle Client is
causing connection errors, if the application home directory name includes special characters, like "(" (Oracle Bug 3807408).
Error ORA-12705 together with log entry "OCIEnvCreate failed with rc = -1" can happen, if environmental variable NLS_LANG is set.
Solution is to set this variable to empty space in the controller environment.
On 64-bit Linux, user may get a warning message of insufficient access rights when connection test is performed, even if all the required
access rights are provided. The connection can still be used to schedule the profile. Please ensure all the required access rights are
provided to the user.
If the oracle probe is deployed on a non-Windows OS, the Unified Management Portal (UMP) displays the metrics and alarms on the
robot and not on the Oracle server.
In custom checkpoints, if query tries to fetch data from a table with more than 32 columns, probe will limit the number of columns to 32.
If a custom QoS is added to an existing monitoring profile, the Unified Management Portal (UMP) creates a separate node, Custom, in
the Metric section. It does not display the user-defined description and unit.
If a custom checkpoint is added to an existing monitoring profile, the Unified Management Portal (UMP) creates a separate node,
Dynamic, in the Metric section. It does not display the user-defined description and unit.
If a checkpoint has multiple QoS and you activate or deactivate one QoS, the other QoS of the checkpoint are also activated or
deactivated.
If a checkpoint has multiple alarms and you activate or deactivate one alarm, the other alarms of the checkpoint are also activated or
deactivated.
If you enable a checkpoint in the Checkpoints node, the checkpoint is enabled for all the monitoring profiles and all alarms are
generated.
In custom checkpoints, if you edit a message variable, it adds a new message variable in the Message Variable table. To edit a message
variable in custom checkpoint, delete and create a new message variable.
outqs (iSeries Output Queue Monitoring) Release Notes
Output queues are objects defined in the IBM iSeries system to contain the spooled files or printer output files that are queued for printing. Output
queues are created by a user or by the system. Spooled files are created from the application program, from a system program, or by pressing
the Print key from your keyboard.
The iSeries Output Queue Monitoring (outqs) probe uses profiles to monitor output queues in the IBM iSeries systems. You can create and
activate profiles to monitor the number of spooled files present in an output queue. When you configure a profile, you can set a threshold value to
generate an alarm or QoS message. The probe generates alarms or QoS messages when the total number of files in an output queue
outnumbers or equals the threshold value specified in the profile. The probe scans all the output queues in the system against the profile. This
ensures you that the system is not overloaded with continuous print requests.
Contents
Revision History
Revision History
This section describes the history of the revisions for the outqs probe.
Version
Description
State
Date
1.16
What's New:
GA
September 2015
GA
September 2014

1.15
What's New:
Added support for Static Threshold alarm.
Fixed Defects:
Fixed a defect in which DevID and MetID were not matching for QoS.
1.02
Support for robot distribution to Debian and Ubuntu added.
December 2012
New GUI in USM; previous Windows-based GUI deprecated.
1.01
GUI allows uppercase and numeric characters in Windows domains.
October 2012
1.00
Initial release.
July 2012


The outqs probe can be deployed on a robot that is installed on the IBM iSeries systems. The probe requires the following software environment:
Required robot installer archive packages: robot_msi, robot_rpm, robot_deb, robot_sol
Probe Provisioning Manager (PPM) 2.38 or later (required for Admin Console)

IBM iSeries system 5.1 or above
perfmon (System Performance Engine Monitoring) Release Notes

The System Performance Engine Monitoring (perfmon) probe remotely retrieves performance counter values from a set of Windows computers.
The probes that use perfmon to monitor Windows performance counters are as follows:
cisco_unity
exchange_monitor
iis
The perfmon probe automatically retrieves the values for the associated probe that is deployed in the robot. The associated probes then use
these values to generate applicable QoS data and alarms.
Contents
Revision History
Revision History
Version
Description
State
Date
1.61
Fixed Defect:
GA
June 2015
Beta
June 2015
GA
June 2014
The probe returned an incorrect value of the LDAP Read Time monitor for exchange_monitor. Salesforce case
00162939
1.60
What's New:
1.53
What's New:
Added a callback (get_all_values) which returns all values of the given perfmon instance. This callback accepts
counter name, object name (maximum two objects), and the instance name and returns a table containing values of the
specified object. If there are multiple instances with the same name, then values of all instances are returned. The probe
uses this callback while monitoring the application pool.
1.52
Removed dependency for x64 redistributable for 64-bit probes.
October
2013
1.51
Changed remote authentication order: 'user/password', 'impersonation', 'implicit'. Improved error handling on performance
object parsing. Fixed crash issue.
September
2012
1.50

Added support for Windows on Itanium-2 systems (IA64).
March
2011
1.33
Rebuild following Nimsoft library fixes.
1.32
Added logsize configuration option and removed logfile configuration option.

Added vs2008_redist_x86 dependency for 64-bit section because the starter.exe binary is 32-bit.
December
2008
September
2008
Changed netpingsimple to netping due to issue with identifier.

On list_counters, display counter names even if the 'noshow' flag is set on the counter type.
1.18
Modified termination handling in starter.exe.

Added configuring of ping timeout through configurator.
September
2007
Changed order of remote connect attempts - try with specified credentials first.
1.16
Corrected problem with ping timeout.

Fixed problem with calculation of some disk data.
August
2007
Does not show duplicate counter instance names.

Added option to set user to run as.
Modified list callbacks to avoid memory leak situations.
Modified monitor_direct callback also to avoid memory leak situations.
Added extra checking of the fetched performance objects to handle corrupt objects better.
Skip objects not asked for during scan to improve performance.
Added native Win64 support.
1.11
Configurable ping_timeout. Default set to 500 ms. Setting this to 0 turns ping completely off.
Fixed hang situation related to finding processes.
1.09
Added support for turning on 'fetch_all_object' mode with a callback function.

Scans object name list in descending order to avoid problems with old object versions.
November
2006
March
2006
Retries ping several times before giving up on a server.

Added raw-configure option to be able to handle situations where all objects must be fetched to get a particular object.
1.07
Corrected problem with large instance names. Modified program logic to ensure fast response to interactive requests.

The perfmon probe must be installed on systems with the following minimum resources:
CPU: 3-GHz dual-core processor 32, or 64-bit

Nimsoft Monitor Server 7.5 to 7.6 or CA Unified Infrastructure Manager 8.0 or later
.Net Framework 3.5
Required robot installer archive packages: robot_msi, robot_rpm, robot_deb, robot_sol.
At least one of the following probes that use perfmon must be deployed on the robot:
cisco_unity
exchange_monitor
iis
December
2005
policy_engine Release Notes

The policy_engine probe evaluates queued policies at the configured Policy Evaluation Schedule interval and notifies the ace probe when probes
need to be configured by templates attached to a policy, and when probes need to be deployed to devices targeted by a policy.
Revision History
Requirements
Revision History
This section describes the history of the revisions for the policy_engine probe.
Version
Description
State
Date
8.2
Initial release.
GA
March 2015
Requirements
The policy_engine probe should be installed on systems with the following minimum resources:
This section describes the software required to use the Policy Editor and create policies.
For policy_engine v8.2 running with CA UIM v8.31
ace v8.3
Admin Console v8.31
udm_manager v8.31
Verify CA Unified Management Portal (UMP) v8.31 is installed and running. With UMP, the following required probes are also deployed
ump_policyeditor v8.31
wasp (Web Application Server Probe) v8.31
For policy_engine v8.2 running with CA UIM v8.2
ace v3.5
Admin Console v8.2

udm_manager v8.2
Verify CA Unified Management Portal (UMP) v8.2 is installed and running. With UMP, the following required probes are also deployed
ump_policyeditor v8.2
wasp (Web Application Service Provider) v8.2
policy_engine is installed on the primary hub with CA UIM Server installer v8.2 or later.
ppm (Probe Provisioning Manager) Release Notes

When using Admin Console, the Probe Provisioning Manager (ppm) provides support for configuring probes. It drives the GUIs displayed within
Admin Console and maps changes initiated by the user to the probes native configuration files. Use raw configure to modify ppm parameter
settings.
Note: An administrator cannot upgrade ppm to a new version. Instead, deploy a newer version of the ppm probe after deleting existing
versions of ppm.
Contents
Revision History
Probes That Use PPM
ppm Hardware Requirements
ppm Software Requirements
ppm Dependencies
Functions Supported
Upgrade to a Newer Version of ppm
Backward Compatibility
Performance Considerations
Revision History
This section describes the history of the revisions for the ppm probe.
Version
Description
State
Date
3.22
What's New:
This version of ppm is installed on the primary hub when you run UIM Server Installer v8.31.
GA
August
2015
If you deploy ppm v3.22 to hub robots, baseline_engine v2.6 and prediction_engine v1.31 are also deployed to the
same robot.
You can enter ${ in the Custom Alarm Message and Custom Alarm Clear Message fields to select variables for the
custom alarm message from a drop-down list.
3.20

Release
3.11
What's New:
Settings for alarm severity now includes more operators.
GA
April 2015
GA
January
2015
GA
December
2014
GA
September
2014
You can create a custom alarm message or a custom clear alarm message.
The
icon for the Compute Baseline, Dynamic Alarm, or Time To Threshold Alarm check boxes provides a
message that indicates when the baseline_engine or prediction_engine probes are not installed or running.
3.05
What's New:
Minor documentation updates.
3.0
Modified the static alarm, dynamic alarm, and Time To Threshold alarm threshold GUI for monitoring probes.
Alarm threshold GUI includes a Compute Baseline, Publish Alarm, and Publish Data check boxes. Select these
check boxes to configure alarm thresholds and the severity of the alarm generated when a threshold is breached.
2.38
Localization support for the ntevl and adevl probes

New metrics in Disk, Network & Memory section for the cdm probe
Support for configuring Time Over Threshold and Time To Threshold thresholds and alarms.
2.32
5 new Adapters
GA
June 2014
2.27
Update to dynamic threshold GUI for QoS probes.
GA
April 2014
2.26
Added support for CDM-Iostat and ad_server features.
GA
March
2014
GA
December
2013
GA
May 2013
2.21
Fixed defects
Miscellaneous UI text/messaging/L10N cleanup
15 New Adapters
dirscan, logmon and printers enhancement with CTD V2
2.03
Fixed defects
Miscellaneous UI text/messaging/L10N cleanup
exchange_monitor adapter now includes support for the DAG feature
2.02
Support for additional probes.
GA
April 2013
2.01
First general release of the probe included as part of the NMS 6.5 Installer.
GA
March
2013
Probes That Use PPM

The following probes have GUIs that are displayed using the ppm probe:
Probe
Minimum Version
ad_response
v1.60
ad_server
v1.43
adevl
v1.60
adogtw
v2.71
apache
v1.51
v8.1
casdgtw
v2.34
cdm
v4.81
celerra
v1.50
cisco_ucm
v1.80
cluster
v3.12
controller
v5.70
cuegtw
v1.04
data_engine
v7.90
db2
v4.05
dhcp_response
v3.22
dirscan
v3.05
distsrv
v5.30
diskstat
v1.05
dns_response
v1.64
e2e_appmon
v2.20
email_response
v1.42
emailgtw
v2.70
exchange_monitor
v4.01
ews_response
v1.02
fetchmsg
v1.50
file_adapter
v1.40
fsmounts
v1.22
ha
v1.44
history
v1.04
hpsmgtw
v1.01
hub
v5.82
ica_response
v3.0
ica_server
v1.3
iis
v1.53
informix
v4.11
jboss
v1.33
jdbcgtw
v1.01
jobqs
v1.12
jobs
v1.36
jobsched
v1.23
journal
v1.06
jvm_monitor
v1.44
ldap_response
v1.33
logmon
v3.23
lync_monitor
v1.0
mysql
v1.47
nap
v4.10
net_connect
v2.90
nexec
v1.35
notes_response
v2.31
notes_server
v1.52
nsdgtw
v1.21
ntevl
v3.90
ntp_response
v1.31
ntperf
v1.87
ntperf64
v1.87
ntservices
v3.15
oracle
v4.54
outqs
v1.14
perfmon
v1.51
printers
v2.53
processes
v3.75
rsp
v2.93
sharepoint
v1.51
smsgtw
v3.01
sngtw
v2.0
spooler
v5.70
sql_response
v1.60
sqlserver
v4.82
sybase
v4.13
sysloggtw
v1.40
sysstat
v1.10
tcp_proxy
v1.10
threshold_migrator (New with UIM 8.2)
v1.0
tomcat
v1.22
url_response
v4.13
webgtw
v1.00
weblogic
v1.35
webservicemon
v1.25
webshpere
v1.63
ppm Hardware Requirements

The ppm probe should be installed on systems with the following minimum resources:
2-4 GB of RAM. Probe OOB configuration requires 256 MB of RAM.

3 GHz dual-core processor, 64-bit.
ppm Software Requirements

The ppm probe is a Java-based probe that requires the following software environment:
CA UIM Server version 7.1 or later
CA UIM v8.0 or later
With CA UIM v8.31, hub version 5.82 or later running on a platform that supports Java
With CA UIM v8.0 through v8.2, hub version 5.7 running on a platform that supports Java
When running ppm v3.0 and later, Java Virtual Machine version 1.7 is required. (This is deployed as part of the probe package)
When running ppm v2.38, Java Virtual Machine version 1.6 package or later is required. (This is deployed as part of the probe package.)
Note: Deploy the ppm probe only to hub robots.
ppm Dependencies
The following table shows the probes required to configure dynamic, static, Time Over Threshold, and Time To Threshold alarms for each release
of CA UIM v8.0 and later. It is recommended to deploy and run the versions of the probes supported by the version of CA UIM you are running on
your UIM server. This ensures that you can configure alarm and threshold settings, and the alarms are successfully generated when thresholds
are breached.
CA UIM Version
Version of ppm
Version of
baseline_engine
Version of
prediction_engine
Version of nas
Version of
alarm_enrichment
8.31
3.22
2.6
1.31
4.73
4.73
8.2
3.11
2.5
1.2
4.67
4.67
8.1
3.0
2.4
1.1
4.6
4.6
8.0
2.38
2.3
1.01
4.4
4.4
Functions Supported
As shown in the ppm Dependencies table, ppm, baseline_engine, prediction_engine, nas, and alarm_enrichment probes have inter-dependencies
that require certain versions of each probe to be installed on hub robots. Starting with ppm v2.38, the supported versions of the ppm,
baseline_engine, and prediction_engine probes must be running on all hub robots to successfully generate QoS alarm messages.
ppm 3.22
CA UIM v8.31 should be running on the UIM Server. If you run ppm v3.22 with an earlier version of CA UIM, you might not see all of the
alarm and threshold fields, and as a result the alarms may not be generated correctly.
UIM Server Installer v8.31 installs ppm v3.22, baseline_engine v2.6, and prediction_engine v1.31 to the primary hub.
You must manually deploy ppm v3.22 separately on all hub robots. When you deploy ppm v3.22, baseline_engine v2.6 and
prediction_engine v1.31 are also deployed to the same robot.
Alarm Server (nas) and alarm_enrichment probes must be deployed and running on the primary hub if you want to configure Time Over
Threshold alarms. Install nas v4.73 and alarm_enrichment 4.73 with the nas package on the primary hub.
If baseline_engine and prediction_engine are deployed on a hub but these probes are not running, then no alarms should be generated.
Select the Compute Baselines, Dynamic Alarm, or Time To Threshold Alarm check boxes to configure dynamic, static (if applicable), or
Time To Threshold alarm and threshold settings.
If alarm or threshold fields are inactive on a monitoring probe's GUI, click the field help
icons next to the Compute Baselines,
Dynamic Alarm, or Time To Threshold Alarm check boxes to determine which required probe is not deployed or deactivated on a robot.
To configure the Time to Threshold alarm and threshold, select the Time To Threshold Alarm check box and configure the remaining
settings.
If you deploy baseline_engine to a secondary hub, make sure you create a new hub queue or amend existing hub queues to forward the
new QOS_BASELINE messages to the primary hub. See the Recommended Multiple Hub Probe Deployment section for details.
You can create custom alarms.
Enter ${ in the custom alarm fields to see a list of variables that baseline_engine will substitute. These variables are probe-specific.
ppm v3.11
CA UIM v8.2 should be running on the UIM Server. If you run ppm v3.11 with a version of CA UIM earlier than CA UIM v8.2, you might
not see all of the alarm and threshold fields, and as a result the alarms may not be generated correctly.
You must manually deploy ppm v3.11 separately on all hub robots. When you deploy ppm v3.11, baseline_engine v2.5 and
prediction_engine v1.2 are also deployed to the same robots.
ppm, baseline_engine, and prediction_engine must all be deployed and running if you want to configure dynamic, static (if applicable), or
Time To Threshold alarm and threshold settings for monitoring probes.
If baseline_engine and prediction_engine are deployed to a hub but these probes are not running, no alarms are generated.
If alarm or threshold fields are inactive on a monitoring probe's GUI, click the field help
icons next to the Compute Baselines,
Dynamic Alarm, or Time To Threshold Alarm check boxes to determine which required probe is not deployed or deactivated on a robot.
settings.
You can create custom alarms.
ppm v3.0
CA UIM v8.1 should be running on the UIM Server. If you run ppm v3.0 with a version of CA UIM earlier than CA UIM v8.1, you might not
see all of the alarm and threshold fields, and as a result the alarms may not be generated correctly.
You must manually deploy ppm v3.0 separately on all hub robots. In addition, manually deploy baseline_engine v2.4 and
prediction_engine v1.1 to the same robots.
settings.
Run ppm v3.0 on hub robots in a CA UIM v8.1 environment. If you run ppm v3.0 with earlier versions of CA UIM, you might not see all of
the alarm and threshold fields, and as a result the alarms may not be generated correctly.
ppm v2.38
CA UIM v8.0 should be running on the UIM Server. You cannot run ppm v2.38 with NMS systems.
You must manually deploy ppm v2.38 separately on all hub robots. In addition, manually deploy baseline_engine v2.24 and
prediction_engine v1.0 to the same robots.
Threshold alarms. Deploy nas v4.4 and alarm_enrichment 4.4 to the primary hub.
To configure the Time to Threshold alarm and threshold, select Time To Threshold Alarm in the Predictive Alarm drop-down men and
configure the remaining settings.
ppm must be installed on every hub robot that hosts a probe that will be configured using Probe Provisioning. If ppm is missing, Monitoring
Services generates an error message that is displayed in Admin Console.
Note: When you manually deploy ppm to hub robots, you must also download and install JRE 7 separately on each hub robot.
Upgrade to a Newer Version of ppm

An administrator cannot upgrade ppm to a newer version. Instead, deploy a newer version of ppm after deactivating and removing the installed
version of ppm.
Backward Compatibility
Versions of ppm, starting with v2.38, are supported on UIM servers running CA UIM v8.0 and later. It is recommended that you run the version of
ppm released with the version of CA UIM you are running on the UIM Server.
Each release of ppm, starting with ppm v2.38, can run with CA UIM v8.0 and higher. However, only the features supported in the release of ppm
running on a hub robot that manages the probe you are configuring are visible.
The features available in earlier versions of ppm are brought forward and are available in newer versions. The following list shows the version of
ppm released with CA UIM and indicates the new features introduced in each version of ppm.
CA UIM v8.31 with ppm v3.22
You can enter '${' to see a drop-down list of variables available for custom alarm messages. The variables displayed in the drop-down list
are variables the baseline_engine will substitute or are probe-specific variables.
You can create custom alarm messages. If the Compute Baseline, Publish Alarm, or Publish Data check boxes are not selectable, click
the help icon for these check boxes. The help message indicates when the baseline_engine or prediction_engine probes are not installed
or not running.
Provides a Compute Baseline, Publish Alarm, and Publish Data check box. Select the Compute Baseline check box if you want
baseline_engine to compute baselines. Select the Publish Alarm and Publish Data to allow the QoS messages and alarms to be placed
on the UIM message bus.
Includes a redesign for static and dynamic alarm fields, and allows you to configure Predictive Alarm and Time Over Threshold alarm
settings.
Note: ppm v2.38 (and later) is not supported on servers running NMS 7.6.
Performance Considerations
Items that can affect the performance of ppm include:
With CA UIM v8.2 and earlier, the number of instances of the cdm probe in your environment (running more than 250 instances of the
CDM probe) might impact performance.
Note: The number of instances of the cdm probe running in your environment is no longer an issue when you install CA UIM
v8.3 and cdm v5.31.
The number of probe targets ppm is managing.

The number of concurrent requests to targeted probes (requests might be blocked until the current set of requests are fulfilled).
The response time of targeted probes.
The footprint of the adapter used for managing a targeted probes configuration.
Except for the adapter footprint, there are no settings that can influence ppm behavior for concurrent requests or how long it takes targeted
probes to respond. In the case of concurrent requests, requests will be blocked until the ppm can handle and respond to the request.
Some of the settings to modify when performance of ppm is slow is the logging level or the maximum memory size. To change these settings, use
the Raw Configure tool available through either the Admin Console or Infrastructure Manager. See the wiki article for the release of ppm deployed
to hub robots for more information about modifying the logging level and maximum memory size settings.
ppm Known Issues

Contents
Probe Provisioning UIs Only Support Viewing Alarm Message Definitions
adevl/ntevl Probe UI Restricts Update Events Information
apache Probe UI Does Not Support Summary and Checkpoint Features
Adogtw Probe UI Known Issues
cdm Probe UI Known Issues
cluster UI Known Issues
controller Probe UI Known Issues
db2 Probe UI Known Issues
dirscan Probe UI Known Issues
dns_response Probe UI Known Issues
e2e_appmon Probe UI Known Issues
emailgtw Probe UI Known Issues
file_adapter Probe UI Known Issues
ica_response Probe UI Known Issues
iis Probe UI Known Issues
informix Probe UI Known Issues
Jboss Probe UI Known Issues
jvm_monitor Probe UI Known Issues
logmon Probe UI Known Issues
ntevl Probe UI Known Issues
ntservices Probe UI Known Issues
oracle Probe UI Known Issues
perfmon Probe UI Does Not Show Some Fields Under Status Section
printers Probe UI Does Not Support 'Add Print Watcher'
rsp Probe UI Known Issues
smsgtw Probe UI Does Not Provide Editable Drop Down for Sending Messages
sql_response Probe UI Known Issues
sqlserver Probe UI Known Issues
sybase Probe UI Known Issues
sybase_rs Probe UI Known Issues
url_response Probe UI Known Issues
webservicemon Probe UI Know Issues
Websphere Probe UI Known Issues
Probe Provisioning UIs Only Support Viewing Alarm Message Definitions

Contents
Manage Messages in Raw Configure

ad_response Probe Does Not Have the Same Metric ID and Only Two Counters Can be Added
Manage Messages in Raw Configure

Symptom:
Alarm Message Definitions can only be viewed within Probe Provisioning. The ability to manage message (edit, create, delete) is not currently
supported.
Solution:
To edit, create, or delete messages, use the Raw Configure menu.
ad_response Probe Does Not Have the Same Metric ID and Only Two Counters Can be Added
Symptom:
The ad_response Probe Adapter UI currently does not have the same metric Id for different categories search, replication and response.
In ad_response probe adapter GUI only two counters can be added as compared to VB GUI ad_response probe.
Solution:
Use Infrastructure Manager.
adevl/ntevl Probe UI Restricts Update Events Information

Symptom:
The adevl and ntevl Probe Provisioning UI currently restricts user from viewing updated events information.
Solution:
apache Probe UI Does Not Support Summary and Checkpoint Features

The apache Probe Provisioning UI does not support Apache Summary Graphs and Show/Hide checkpoints that are unavailable.
Adogtw Probe UI Known Issues

Contents
Adogtw Probe UI Does Not Support Subscribe Section
This section describes the known issues with the Adogtw probe configured using Admin Console.
Adogtw Probe UI Does Not Support Subscribe Section

Symptom:
The Adogtw Probe Provisioning UI does not provide the ability to create a subscribe profile section.
Solution:
cdm Probe UI Known Issues

This section describes the known issues with the cdm probe configured using Admin Console.
Contents
cdm Probe Provisioning UI Does Not Support 'Custom Profiles'

cdm Probe UI Does Not Support Changing the 'Internal Alarm' Message
cdm Probe Provisioning UI Does Not Support 'Custom Profiles'

Symptom:
The CDM probe supports the usage of Custom Profiles. At this time, the CDM Probe Provisioning UI does not expose this capability.
Solution:
cdm Probe UI Does Not Support Changing the 'Internal Alarm' Message
Symptom:
The Internal Alarm message cannot be changed through the CDM Probe Provisioning UI.
Solution:
Use either Raw Configure or Infrastructure Manager. Raw Configure is supported through both the Admin Console and the Windows based IM.
cluster UI Known Issues

Linux-based Cluster Environment Not Supported
The cluster adapter does not support a Linux-based cluster environment.
This issue is fixed with ppm v3.20.
controller Probe UI Known Issues

Contents
controller Probe UI Does Not Support Changing Robot Mode to 'Passive'

controller Probe UI Always Allows Setting of QoS Source to Robot Name Instead of Computer Hostname
This section describes the known issues with the controller probe configured using Admin Console.
controller Probe UI Does Not Support Changing Robot Mode to 'Passive'

Symptom:
Changing the robot mode to passive via Probe Provisioning is not supported.
Solution:
Use Infrastructure Manager for the controller in scenarios where passive mode is required.
controller Probe UI Always Allows Setting of QoS Source to Robot Name Instead of Computer Hostname
Symptom:
The "QoS source to robot name instead of computer hostname" setting for the controller can be set through the Probe Provisioning UI. This
setting should only be enabled if controller has been configured to use a Specific Name for the Robot Name.
Solution:
Ensure that a Specific Name is being used for the Robot Name prior to setting this option.
db2 Probe UI Known Issues

Contents
db2 Probe UI Does Not Support Schedules
db2 Probe UI Does Not Suspend/Resume Feature
db2 Probe UI Does Not Support Status Tab/Group Functionality
db2 Probe UI Does Not Support Custom Alarm Feature
db2 Probe UI Does Not Support Template Feature
This section describes the known issues with the db2 probe configured using Admin Console.
db2 Probe UI Does Not Support Schedules

Symptom:
The db2 probe supports the usage of 'schedules.' At this time the db2 Probe Provisioning UI does not expose this capability.
Solution:
db2 Probe UI Does Not Suspend/Resume Feature

Symptom:
The db2 probe supports the usage of 'Suspend/Resume' feature. At this time the db2 Probe Provisioning UI does not expose this capability.
Solution:
db2 Probe UI Does Not Support Status Tab/Group Functionality

Symptom:
The db2 probe supports the usage of 'Status Tab/Group.' At this time the db2 Probe Provisioning UI does not expose this capability.
Solution:
db2 Probe UI Does Not Support Custom Alarm Feature

Symptom:
The db2 probe supports the usage of 'Custom Alarm' feature. At this time the db2 Probe Provisioning UI does not expose this capability.
Solution:
db2 Probe UI Does Not Support Template Feature

Symptom:
The db2 probe supports the usage of Templates. At this time the db2 Probe Provisioning UI does not expose this capability.
Solution:
Use Infrastructure Manager if this feature is needed.
dirscan Probe UI Known Issues

Contents
dirscan Probe UI Does Not Support Schedules
dirscan Probe UI Does Not Support Copy Profile Features
dirscan Probe UI Does Not Support 'rechecksum on pattern files' Feature
dirscan Probe UI Does Not Support 'remote file' Feature
This section describes the known issues with the dirscan probe configured using Admin Console.
dirscan Probe UI Does Not Support Schedules

Symptom:
The dirscan probe supports the usage of schedules. At this time, the dirscan Probe Provisioning UI does not expose this capability.
Solution:
dirscan Probe UI Does Not Support Copy Profile Features

Symptom:
The dirscan probe supports the usage of copy profiles by right clicking on the profile. At this time the dirscan Probe Provisioning UI does not
expose this capability.
Solution:
dirscan Probe UI Does Not Support 'rechecksum on pattern files' Feature

Symptom:
The dirscan probe supports the functionality of rechecksum on pattern files which is still at this time not exposed in the dirscan probe provisioning
UI.
Solution:
dirscan Probe UI Does Not Support 'remote file' Feature

Symptom:
If the probe runs on a Windows computer, remote shares can be monitored when the directory is specified with the format //<computer
name>/<sharename> or //<computer name>/<share name>/<directory>. At this time the dirscan Probe Provisioning UI does not expose this
capability.
Solution:
dns_response Probe UI Known Issues

Contents
dns_response Probe UI Does Not Support 'Direct Profile Creation' Feature
dns_response Probe UI Allows all Port Numbers Rather Than Allowing 53 for UDP Protocol Only Feature
This section describes the known issues with the dns_response probe configured using Admin Console.
dns_response Probe UI Does Not Support 'Direct Profile Creation' Feature

Symptom:
The dns_response Probe Provisioning UI does not allow user to create a new profile unless Default Nameserver present in General Setup
Section.
Solution:
First enter details of default nameserver in the Setup section and then create a Profile
dns_response Probe UI Allows all Port Numbers Rather Than Allowing 53 for UDP Protocol Only Feature
Symptom:
The dns_response Probe Provisioning UI currently allows user to enter all port numbers for UDP Protocol however it works fine for port 53 only.
Solution:
Its mentioned in help document, UDP Port works fine on port 53 only.
e2e_appmon Probe UI Known Issues

This section describes the known issues with the e2e_appmon probe configured using Admin Console.
Contents
e2e_appmon Probe UI Does Not Support Script Recording
e2e_appmon Probe UI Does Not Support Script Recording
Symptom:
The e2e_appmon probe has the capability to record scripts. However, script recording is currently not available when configuring this probe with
Admin Console.
Solution:
emailgtw Probe UI Known Issues

Contents
emailgtw Probe Provisioning UI does not Support Viewing or Editing Template Files
emailgtw Probe Hangs if Non-Existent Template File is Specified
This section describes the known issues with the emailgtw probe configured using Admin Console.
emailgtw Probe Provisioning UI does not Support Viewing or Editing Template Files
Symptom:
Viewing and editing of template files for the emailgtw probe is not currently supported using Probe Provisioning.
Solution:
None within Probe Provisioning (alternate is to use Infrastructure Manager).
emailgtw Probe Hangs if Non-Existent Template File is Specified

Symptom:
If a non-existent template is specified in the configuration for the emailgtw probe, the probe will hang.
Solution:
No validation currently exists to prevent this via Probe Provisioning. If this problem occurs, stop the probe, remove the invalid entry via Raw
Configure, and then restart the probe.
file_adapter Probe UI Known Issues

Contents
file_adapter Probe UI Does Not Support Status Being Displayed on UI
file_adapter Probe UI Does Not Support Adding Custom QoS
This section describes the known issues with the file_adapter probe configured using Admin Console.
file_adapter Probe UI Does Not Support Status Being Displayed on UI

Symptom:
The file_adapter probe supports the status being displayed on the UI. At this time the file_adapter Probe Provisioning UI does not expose this
capability.
Solution:
file_adapter Probe UI Does Not Support Adding Custom QoS
Symptom:
The file_adapter probe supports the feature of adding custom QoS. At this time the file_adapter Probe Provisioning UI does not expose this
capability.
Solution:
ica_response Probe UI Known Issues

This section describes the known issues with the ica_response probe configured using Admin Console.
Contents
ica_response Probe UI Does Not Support Script Reading
ica_response Probe UI Does Not Support Script Reading

Symptom:
The ica_response probe has the capability to read scripts. However, script reading is currently not available when configuring this probe with
Admin Console.
Solution:
iis Probe UI Known Issues

This article describes the known issues with the iis probe configured using Admin Console.
iis Probe UI Does Not Support Testing Host Credentials

iis Probe UI Requires Individual Monitor Activation for Hosts
iis Probe UI Does Not Support Group Renaming
iis Probe UI Does Not Support Displaying 'Summary Database Status'
iis Probe Adapter UI Does Not Currently Have the Same Metric ID for Localhost With IP Profile
iis Probe UI Does Not Support Testing Host Credentials

Symptom:
The IIS Probe Provisioning UI does not provide a Test button to verify the Windows Authentication details for a Host.
Solution:
None.
iis Probe UI Requires Individual Monitor Activation for Hosts

Symptom:
The IIS Probe Provisioning UI does not provide a either an Activate All or Deactivate All action for a Hosts monitors.
Solution:
Each monitor must be activated or deactivate individually.
iis Probe UI Does Not Support Group Renaming

Symptom:
The Rename Group feature is not currently supported via Probe Provisioning.
Solution:
As a workaround, a new group can be added, followed by moving hosts to that group, and finally the removal of the original group.
iis Probe UI Does Not Support Displaying 'Summary Database Status'

Symptom:
Displaying "Summary Database Status" is not currently supported via Probe Provisioning.
Solution:
None within Probe Provisioning (alternate is to use Infrastructure Manager).
iis Probe Adapter UI Does Not Currently Have the Same Metric ID for Localhost With IP Profile
Symptom:
The iis Probe Adapter UI does not have the same metric ID for localhost with IP profile.
Solution:
Create a profile with localhost name.
This issue has been resolved with ppm v3.20.
informix Probe UI Known Issues

Contents
informix Probe UI Does Not Support Schedules
informix Probe UI Does Not Suspend/Resume Feature
informix Probe UI Does Not Support Status Tab/Group Functionality
informix Probe UI Does Not Support Custom Alarm Feature
informix Probe UI Does Not Support Template Feature
This section describes the known issues with the informix probe configured using Admin Console.
informix Probe UI Does Not Support Schedules

Symptom:
The informix probe supports the usage of 'schedules.' At this time the informix Probe Provisioning UI does not expose this capability.
Solution:
informix Probe UI Does Not Suspend/Resume Feature

Symptom:
The informix probe supports the usage of 'Suspend/Resume' feature. At this time the informix Probe Provisioning UI does not expose this
capability.
Solution:
informix Probe UI Does Not Support Status Tab/Group Functionality

Symptom:
The informix probe supports the usage of "Status Tab/Group.' At this time the informix Probe Provisioning UI does not expose this capability.
Solution:
informix Probe UI Does Not Support Custom Alarm Feature

Symptom:
The informix probe supports the usage of 'Custom Alarm' feature. At this time the informix Probe Provisioning UI does not expose this capability.
Solution:
informix Probe UI Does Not Support Template Feature

Symptom:
The informix probe supports the usage of Templates. At this time the informix Probe Provisioning UI does not expose this capability.
Solution:
Jboss Probe UI Known Issues

Contents
Jboss Adapter UI Does Not Support Creation of Templates, Auto Monitor and Auto Configuration
Jboss Adapter UI Does Not Support Any Other QoS Except Default
This section describes the known issues with the Jboss probe configured using Admin Console.
Jboss Adapter UI Does Not Support Creation of Templates, Auto Monitor and Auto Configuration
Symptom:
The Jboss Probe Provisioning UI does not provide the ability to create Templates, Auto Monitor and Auto Configuration.
Solution:
Jboss Adapter UI Does Not Support Any Other QoS Except Default
Symptom:
The Jboss Probe Provisioning UI does not support any other QoS except Default.
Solution:
jvm_monitor Probe UI Known Issues

Contents
jvm_monitor Adapter UI Does Not Support the Creation of Templates, Auto Monitor and Auto Configuration
Jboss Adapter UI Does Not Support Other QoS Except Default
This section describes the known issues with the jvm_monitor probe configured using Admin Console.
jvm_monitor Adapter UI Does Not Support the Creation of Templates, Auto Monitor and Auto Configuration
Symptom:
The jvm_monitor Probe Provisioning UI does not provide the ability to create Templates, Auto Monitor and Auto Configuration.
Solution:
Jboss Adapter UI Does Not Support Other QoS Except Default

Symptom:
The jvm_monitor Probe Provisioning UI does not support any QoS except Default.
Solution:
logmon Probe UI Known Issues

This section describes the known issues with the logmon probe configured using Admin Console.
logmon Probe UI Does Not Support 'View File' Feature

logmon Probe UI Does Not Support Test Profile Functionality Fully
logmon Probe UI Does Not Support Add New QoS Definition Option in QoS Tab for QoS Name Field
logmon Probe UI Does Not Support File Not Found Alarm Feature
logmon Probe UI Does Not Support 'View File' Feature

Symptom:
The logmon Probe Provisioning UI currently does not allow user to view the file.
Solution:
This issue is resolved with ppm v3.20.
logmon Probe UI Does Not Support Test Profile Functionality Fully

Symptom:
When testing a profile through the Probe Provisioning UI, the exposed Test Profile functionality does not include support for specifying a Test
String. Only Test File is supported at this time.

Solution:
If you need to test profile functionality fully, use Infrastructure Manager.
logmon Probe UI Does Not Support Add New QoS Definition Option in QoS Tab for QoS Name Field
Symptom:
The logmon Probe Provisioning UI does not support Add New QoS Definition in QoS tab for QoS Name field in the drop-down list.
Solution:
When using Infrastructure Manager, the new QoS definitions can be added through Quality of Service Definitions section only.
logmon Probe UI Does Not Support File Not Found Alarm Feature
Symptom:
The logmon Probe Provisioning UI does not support File Not Found Alarm Feature.
Solution:
ntevl Probe UI Known Issues

Contents
ntevl Probe UI Does Not Support Event Feature Completely
This section describes the known issues with the ntevl probe configured using Admin Console.
ntevl Probe UI Does Not Support Event Feature Completely

Symptom:
The ntevl probe does not show the details section of events having XML content.
Solution:
ntservices Probe UI Known Issues

Contents
ntservices Probe UI Does Not Support Dynamic State of Service
ntservices Probe UI Does Not Remove Service from Services List When Added to Profiles
This section describes the known issues with the ntservices probe configured using Admin Console.
ntservices Probe UI Does Not Support Dynamic State of Service

Symptom:
The ntservices probe has an option to start or stop a service. The Probe Provisioning UI will not dynamically reload the state of the services.
Solution:
To update the state of the service, reload the configuration after changes are made to the service.
ntservices Probe UI Does Not Remove Service from Services List When Added to Profiles
Symptom:
When adding services to a profile in the ntservices Probe Provisioning UI, the list of available services is not pruned down by the selection
process.
Solution:
To update the list of services the probe needs to be restarted.
oracle Probe UI Known Issues

Contents
oracle Probe UI Does Not Support Schedules
oracle Probe UI Does Not Suspend/Resume Feature
oracle Probe UI Does Not Support Status Tab/Group Functionality
oracle Probe UI Does Not Support Custom Alarm Feature
oracle Probe UI Does Not Support Template Feature
This section describes the known issues with the oracle probe configured using Admin Console.
oracle Probe UI Does Not Support Schedules

Symptom:
The oracle probe supports the usage of 'schedules.' At this time the oracle Probe Provisioning UI does not expose this capability.
Solution:
oracle Probe UI Does Not Suspend/Resume Feature

Symptom:
The oracle probe supports the usage of 'Suspend/Resume' feature. At this time the oracle Probe Provisioning UI does not expose this capability.
Solution:
oracle Probe UI Does Not Support Status Tab/Group Functionality

Symptom:
The oracle probe supports the usage of 'Status Tab/Group.' At this time the oracle Probe Provisioning UI does not expose this capability.
Solution:
oracle Probe UI Does Not Support Custom Alarm Feature

Symptom:
The oracle probe supports the usage of 'Custom Alarm' feature. At this time the oracle Probe Provisioning UI does not expose this capability.
Solution:
oracle Probe UI Does Not Support Template Feature

Symptom:
The oracle probe supports the usage of Templates. At this time the oracle Probe Provisioning UI does not expose this capability.
Solution:
perfmon Probe UI Does Not Show Some Fields Under Status Section
Symptom:
The perfmon Probe Provisioning UI does not show some fields like Object, Counter and Instance under Status tab.
Solution:
If you need it, use Infrastructure Manager.
printers Probe UI Does Not Support 'Add Print Watcher'

Symptom:
The printers probe supports the addition of print watcher by right clicking in the status tab of the probe. At this time, printers Probe Provisioning UI
does not expose this capability.
Solution:
rsp Probe UI Known Issues

This section describes the known issues with the rsp probe configured using Admin Console.
rsp Probe UI Does Not Provide Custom WMI Profile Creation

rsp Probe UI Does Not Provide Ntevents Monitoring
rsp Probe UI Does Not Provide Monitoring Through Template
rsp Probe UI Does Not Provide Discovery Using Range
rsp Probe UI Does Not Provide Custom WMI Profile Creation

Symptom:
The rsp Probe Provisioning UI does not provide creation of custom WMI profiles.
Solution:
rsp Probe UI Does Not Provide Ntevents Monitoring

Symptom:
The rsp Probe Provisioning UI does not provide ntevents monitoring.

Solution:
This issue is resolved with ppm v3.20.
rsp Probe UI Does Not Provide Monitoring Through Template

Symptom:
The rsp Probe Provisioning UI does not provide monitoring through template.
Solution:
rsp Probe UI Does Not Provide Discovery Using Range

Symptom:
The rsp Probe Provisioning UI does not provide discovering range of IPs.
Solution:
smsgtw Probe UI Does Not Provide Editable Drop Down for Sending Messages
Symptom:
The smsgtw does not support an editable drop down menu for sending sms messages.
Solution:
If you want to send sms messages for smoke testing purposes, then you can create a profile with the test number needed, or use Infrastructure
Manager.
sql_response Probe UI Known Issues

Contents
sql_response Probe UI Does Not Support Schedules
sql_response Probe UI Does Not Support SQL Query 'from file' Functionality
sql_response Probe UI Does Not Support Running the Profile and Showing it's Features
sql_response Probe UI Only Supports OLEDB SqlServer Connection
sql_response Probe UI Does Not Support Win/Domain Authorization
This section describes the known issues with the sql_response probe configured using Admin Console.
sql_response Probe UI Does Not Support Schedules

Symptom:
The sql_response probe supports the usage of schedules. At this time, the sql_response Probe Provisioning UI does not expose this capability.
Solution:
sql_response Probe UI Does Not Support SQL Query 'from file' Functionality
Symptom:
The sql_response probe supports getting the details of a file in the SQL query tab. At this time, the sql_response Probe Provisioning UI does not
expose this capability.
Solution:
sql_response Probe UI Does Not Support Running the Profile and Showing it's Features
Symptom:
The sql_response probe supports getting the details of a profile by right clicking on it and selecting "run now". At this time, the sql_response
Probe Provisioning UI does not expose this capability.
Solution:
sql_response Probe UI Only Supports OLEDB SqlServer Connection

Symptom:
The sql_response probe only supports OLEDB SqlServer connection.
Solution:
For ODBC and the rest of the OLEDB connections like Oracle, Informix, Db2, Sybase, use Infrastructure Manager.
sql_response Probe UI Does Not Support Win/Domain Authorization

Symptom:
The sql_response probe does not support Win Domain Authorization for DB connectivity.
Solution:
sqlserver Probe UI Known Issues

Contents
sqlserver Probe UI Does Not Support Schedules
sqlserver Probe UI Does Not Suspend/Resume Feature
sqlserver Probe UI Does Not Support Status Tab/Group Functionality
sqlserver Probe UI Does Not Support Custom Alarm Feature
sqlserver Probe UI Does Not Support Template Feature
This section describes the known issues with the sqlserver probe configured using Admin Console.
sqlserver Probe UI Does Not Support Schedules

Symptom:
The sqlserver probe supports the usage of 'schedules.' At this time the sqlserver Probe Provisioning UI does not expose this capability.
Solution:
sqlserver Probe UI Does Not Suspend/Resume Feature

Symptom:
The sqlserver probe supports the usage of 'Suspend/Resume' feature. At this time the sqlserver Probe Provisioning UI does not expose this
capability.
Solution:
sqlserver Probe UI Does Not Support Status Tab/Group Functionality

Symptom:
The sqlserver probe supports the usage of 'Status Tab/Group.' At this time, the sqlserver Probe Provisioning UI does not expose this capability.
Solution:
sqlserver Probe UI Does Not Support Custom Alarm Feature

Symptom:
The sqlserver probe supports the usage of 'Custom Alarm.' At this time the sqlserver Probe Provisioning UI does not expose this capability.
Solution:
sqlserver Probe UI Does Not Support Template Feature

Symptom:
The sqlserver probe supports the usage of Templates. At this time the sqlserver Probe Provisioning UI does not expose this capability.
Solution:
sybase Probe UI Known Issues

This section describes the known issues with the sybase probe configured in Admin Console.
Contents
sybase Probe UI Does Not Support Schedules

sybase Probe UI Does Not Support the Suspend/Resume Feature
sybase Probe UI Does Not Support the Status Tab/Group Functionality
sybase Probe UI Does Not Support the Custom Alarm Feature
sybase Probe UI Does Not Support Templates
sybase Probe UI Does Not Support Schedules
Symptom:
The sybase probe supports the usage of 'schedules.' However, this feature is currently not visible in the sybase Probe Provisioning UI.
Solution:
sybase Probe UI Does Not Support the Suspend/Resume Feature

Symptom:
The sybase probe supports the usage of 'Suspend/Resume' feature. However, this feature is currently not visible in the sybase Probe
Provisioning UI.
Solution:
sybase Probe UI Does Not Support the Status Tab/Group Functionality

Symptom:
The sybase probe supports the usage of 'Status Tab/Group.' However, this feature is currently not visible in the sybase Probe Provisioning UI.
Solution:
sybase Probe UI Does Not Support the Custom Alarm Feature

Symptom:
The sybase probe supports the usage of 'Custom Alarm.' However, this feature is currently not visible in the sybase Probe Provisioning UI.
Solution:
sybase Probe UI Does Not Support Templates

Symptom:
The sybase probe supports the usage of templates. However, this feature is currently not visible in the sybase Probe Provisioning UI.
Solution:
sybase_rs Probe UI Known Issues

This section describes the known issues with the sybase_rs probe configured in Admin Console.
Contents
sybase_rs Probe UI Does Not Support Schedules

sybase_rs Probe UI Does Not Support the Suspend/Resume Feature
sybase_rs Probe UI Does Not Support the Status Tab/Group Functionality
sybase_rs Probe UI Does Not Support the Custom Alarm Feature
sybase_rs Probe UI Does Not Support Templates
sybase_rs Probe UI Does Not Support Schedules

Symptom:
The sybase_rs probe supports the usage of 'schedules.' However, this feature is currently not visible in the sybase_rs Probe Provisioning UI.
Solution:
sybase_rs Probe UI Does Not Support the Suspend/Resume Feature

Symptom:
The sybase_rs probe supports the usage of 'Suspend/Resume' feature. However, this feature is currently not visible in the sybase_rs Probe
Provisioning UI.
Solution:
sybase_rs Probe UI Does Not Support the Status Tab/Group Functionality

Symptom:
The sybase_rs probe supports the usage of 'Status Tab/Group.' However, this feature is currently not visible in the sybase_rs Probe Provisioning
UI.
Solution:
sybase_rs Probe UI Does Not Support the Custom Alarm Feature

Symptom:
The sybase_rs probe supports the usage of 'Custom Alarm.' However, this feature is currently not visible in the sybase_rs Probe Provisioning UI.
Solution:
sybase_rs Probe UI Does Not Support Templates

Symptom:
The sybase_rs probe supports the usage of templates. However, this feature is currently not visible in the sybase_rs Probe Provisioning UI.
Solution:
url_response Probe UI Known Issues

This section describes the known issues with the url_response probe configured using Admin Console.
Contents
url_response Probe UI Does Not Provide Schedules

url_response Probe UI Does Not Allow Test Profiles In Proxy Environment in UNIX
url_response Probe UI Does Not Provide Schedules

Symptom:
The url_response Probe Provisioning UI does not provide schedulers to the profiles.
Solution:
url_response Probe UI Does Not Allow Test Profiles In Proxy Environment in UNIX
Symptom:
The url_response Probe Provisioning UI does not allow test profiles in proxy environment in Unix.
Solution:
webservicemon Probe UI Know Issues

This section describes the known issues with the webservicemon probe configured using Admin Console.
Contents
Cannot Configure SOAP Request Settings
Cannot Configure SOAP Request Settings

Symptom:
You cannot configure SOAP settings for the webservicemon probe using Admin Console.
Solution:
Use Infrastructure Manager to configure the SOAP settings.

Contents

Websphere Adapter UI Does Not Support Creation of Templates, Auto Monitor and Auto Configuration
Websphere Adapter UI Does Not Support Any Other QoS Except Default
Websphere Adapter UI Does Not Support the Rescan Host Option
Weblogic Probe UI Known Issues
SSL certificate implementation can only be seen and configured using Weblogic Adapter UI
Weblogic Adapter requires Truststore password in order to generate Certificate Expire Alarms
Websphere Adapter UI Does Not Support Creation of the Templates, Auto Monitor and Auto Configuration

This section describes the known issues with the Websphere probe configured using Admin Console.
Websphere Adapter UI Does Not Support Creation of Templates, Auto Monitor and Auto Configuration
Symptom:
The Websphere Probe Provisioning UI does not provide the ability to create Templates, Auto Monitor and Auto Configuration.
Solution:
Websphere Adapter UI Does Not Support Any Other QoS Except Default
Symptom:
Websphere Adapter UI does not support any other QoS except Default.
Solution:
Websphere Adapter UI Does Not Support the Rescan Host Option
Symptom:
The Websphere Probe Provisioning UI does not support the rescan host option which allows the user to scan the profiles in the host server after a
pre-configured interval (15 minutes) and loads any profiles available in the host server under the respective Resources nodes in the probe GUI.
Solution:
Weblogic Probe UI Known Issues

This section describes the known issues with the Weblogic probe configured using Admin Console.
SSL certificate implementation can only be seen and configured using Weblogic Adapter UI
Symptom:
SSL authentication screen can only be viewed using Adapter UI
Solution:
Use the Raw Configure options to configure SSL in Infrastructure Manager.
Weblogic Adapter requires Truststore password in order to generate Certificate Expire Alarms
Symptom:
The Weblogic Probe Provisioning UI requires Truststore password to generate Certificate Expire alarms.
Solution:
Use the Thin Client.
Websphere Adapter UI Does Not Support Creation of the Templates, Auto Monitor and Auto Configuration
Symptom:
The Weblogic Probe Provisioning UI does not provide the user to create the Templates, Auto Monitor and Auto Configuration.
Solution:
prediction_engine Release Notes
The prediction_engine probe gathers the trending information used to calculate when a particular event might occur. The primary function of the
prediction_engine probe is to let you configure Time To Threshold predictive alarms for monitoring probes. You can configure a Time to Threshold
predictive alarm by accessing a probe's GUI in Admin Console or by entering the time to threshold (TTT) Command from within the
prediction_engine probe directory.
To configure Time To Threshold settings for applicable probes, make sure ppm v2.38 (or later), baseline_engine v2.34 (or later), and
prediction_engine v1.01 (or later) probes are installed and running on the hub robot.
Revision History
Requirements
Probe Dependencies
Supported Platforms
Known Issues
Revision History
This section describes the history of the revisions for the Prediction Engine probe.
Version
Description
State
Date
1.31
What's New:
Minor changes to ensure the Time To Threshold configuration is saved properly.
GA
August
2015
1.3
What's New:
Software enhancements to extend functionality to probes that were previously blacklisted.

Release
The prediction_engine v1.3, baseline_engine v2.6, and ppm v3.20 probes are included in the CA UIM Server v8.3
installer and are installed on the primary hub during installation. Deploy ppm v3.20 on all hub robots that are
controlling monitoring probes. When you deploy ppm v3.20, baseline_engine v2.6 and prediction_engine v1.3 are
included and installed on the same hub.
1.2
What's New:
When you deploy ppm v3.11 to hub robots that are controlling monitoring probes, baseline_engine v2.5 and
prediction_engine v1.2 are included and installed on the same hub.
GA
March
2015
GA
December
2014
GA
September
2014
A Time To Threshold Prediction graph is displayed in Unified Service Manager for metrics that have a configured
predictive alarm threshold. For each metric, two predictive QoS messages are generated: one that indicates when
the predictive alarm might be breached, and another to indicates the predictive value at the current time.
1.1
What's New:
Configuring the Time To Threshold settings on the probes' GUI has been slightly modified.
The probe GUI for configuring static, dynamic, and Time To Threshold alarms has changed. To configure Time To
Threshold settings, select the Publish Data and Publish Alarms (new) check boxes to allow the probe to send its
QoS metrics and generate an alarm. To configure Time To Threshold, instead of selecting Time To Threshold from
the Predictive Alarm drop-down menu, you now select the Time To Threshold Alarm check box. Then select the
appropriate alarm and threshold settings.
ppm v3.0 and baseline_engine v2.4 must be deployed and running on the hub robots where prediction_engine v1.1
is deployed in order to get the correct QoS alarms.
1.01
Initial release of product.
Requirements
The Prediction Engine probe should be installed on systems with the following minimum resources:
The prediction_engine probe requires the following software environment:
Probe Dependencies
The prediction_engine probe uses the baseline generated by the baseline_engine probe to generate predictive QoS messages. Then
prediction_engine relies on the nas and alarm_enrichment probes to process and forward predictive alarms on the UIM message bus when
configured predictive alarm thresholds are breached. In addition, prediction_engine requires the ppm probe running on the hub robot to enable
Admin Console to display the appropriate configuration fields.
The following table shows the versions of baseline_engine, ppm, nas, and alarm_enrichment probes that you should be running with the different
versions of prediction_engine. If the versions of these probes are mismatched, meaning you deploy prediction_engine v1.3 with an earlier version
of baseline_engine and ppm on a hub robot, the system will not be able to properly produce predictive alarms.
Released with CA UIM
prediction_engine
baseline_engine
ppm
nas and alarm_enrichment
8.31
1.31
2.6
3.22
4.73
8.2
1.2
2.5
3.11
4.67
8.1
1.1
2.4
3.0
4.6
8.0
1.01
2.34
2.38
4.4
Supported Platforms
Refer to the Compatibility Support Matrix for the latest information about supported platforms. See also the Support Matrix for Probes for more
specific information about the probe.
The versions of ppm, baseline_engine, and prediction_engine probes you deploy to hub robots should match the versions of these
probes running on the primary hub.
ppm, baseline_engine, and prediction_engine must all be deployed and running on hub robots if you want to configure dynamic, static (if
applicable), Time To Threshold alarm and threshold settings for monitoring probes.
Known Issues

Problem:
I have upgraded from UIM 7.5 to UIM 8.1. Some of the installed probes, such as prediction_engine, appear grayed out which means the probes
are not working.
Solution:
After upgrading from UIM 7.5 to UIM 8.1 restart the UIM Server. Probes should function properly after the restart.
Problem:
The prediction_engine v1.0 (and later) and baseline_engine v2.34 (and later) probes require the hub on which it is installed to have a Java
environment pointing to java_jre1.7. If there is a mismatch between the version of Java the secondary hub's environment is pointing to and the
probe's Java dependency, some of the java-based probes (including prediction_engine and baseline_engine) might not start.
In addition to the probe not starting, you might also see an error similar to the following:
Sep 19 17:23:10:955 [2624] Controller: Max. restarts reached for probe 'baseline_engine' (command = <startup java>)"
This error appears in the probe's log file:
baseline_engine.log file located at:
/Nimsoft/Probes/SLM/baseline_engine
prediction_engine.log file located at:
/Nimsoft/Probes/SLM/prediction_engine directory
In some instances, if prediction_engine and baseline_engine are already running on a secondary hub and you deploy another java-based probe
that requires the environment to point to a version of Java earlier than java_jre1.7, prediction_engine and baseline_engine might fail to start after
the deployment. In this case, no errors appear in the log files for prediction_engine and baseline_engine.
Solution:
In either situation, redeploy java_jre7 to the secondary hub and then restart the entire robot.
Important! If prediction_engine and baseline_engine were calculating baselines or new metrics and an error condition arises, these
calculations will be inaccurate from the time the error condition began. After prediction_engine and baseline_engine are restarted,
baselines generated by baseline_engine will be accurate after sufficient samples have been collected and the predictive alarm metrics
will begin again at the top of the next hour after restarting the robot or the prediction_engine probe.
printers (Printer Monitoring) Release Notes

The Printer Monitoring probe monitors printers installed on the computer. Remote printers are included when an appropriate user name/password
is supplied.
Contents
Revision History
Note: For SOC functionality, CA Unified Infrastructure Management Server 5.6 or later and UMP 2.5.2 or later is required.
Revision History
This section describes the history of the revisions for the printers probe.
Version
Description
State
Date
2.53
Fixed Printer Status QoS Message
GA
November 2012
2.52
GA
January 2011
2.51
GA
December 2010
2.50
GA
September 2010
2.40
GA
May 2010
GA
April 2009
GA
December 2008
Fixed the issue DE1856 queue status to printer status
2.31
Separate alarms and clearing for different printer alarms.

UI to change the alarm intensity.
Configurable printers alarms.
Support for windows 2008.
Message customization for local and remote printers(proper source of alarms/QoS).
Auto printer monitoring for new printers.
Added support for logsizeAdded support for Windows on Itanium 2 systems (IA64).
2.22

The printers probe requires the following software environment:
Java JRE 6 or later
processes (Process Monitoring) Release Notes

The processes probe monitors the host's operating system for certain processes, defined by a set of profiles in the probe configuration file. This
probe monitors the processes to detect error situations. The probe also displays the details of the matching process as per conditions set by the
user and executes scripts when a warning condition occurs.
The probe can report processes under the following conditions on the system where the probe is deployed:
A process is expected to run, but has stopped.
A process is not expected to run, but is running.
A process does not run as expected.
The number of process instances is not the expected value.
The CPU usage for a process is above threshold.
The handle counts for a process are above threshold (Windows only).
The memory usage for a process is above threshold.
The thread usage for a process is above threshold.
With version 3.9 onwards, the processes probe introduced monitoring of IPC Counters that share data across multiple and commonly specialized
processes using communication protocols. The probe allows you to configure the QOS and Alarms for the following counters:
Semaphores
Message Queues
Shared Memory Segments
Monitoring of IPC Counters is supported by AIX, Linux, Solaris, and Windows platforms.
Contents
Revision History
Revision History
Version
Description
State
Date
4.01
Fixed Defects:
GA
July 2015
GA
June 2015
The probe was not using customized clear message text in alarms. Salesforce case 00163151
The probe was unable to monitor processes and generate alarms if the used memory was greater than 100 MB. Salesforc
e case 00162654
When the probe reported a process as down, it did not generate process down alarm with modified message text. Salesfo
rce cases: 00161389, 00160183
Processes profile script was not executing properly. Salesforce case 00158405
On Unix platform, the QOS_Definition for the IPC counters QOS_IPC_SHARED_MEMORY_SEGMENTS_UTILIZATION,
QOS_IPC_MESSAGE_QUEUES_UTLIZATION, QOS_IPC_SEMAPHORE_SETS_UTILIZATION and QOS_IPC_PROCE
SS_UTILIZATION sent an incorrect value for the hasmax field. Salesforce case: 00167456
4.00
What's New:
3.92
Fixed Defects:
Fixed a defect where all the eight IPC Counters were applying to the template on the Windows OS instead of applying of only
the two supported ones ('Number of Processes' and 'Number of Semaphore Sets').
March
2015
3.91
March
2015
What's New:
Added IPC Counter monitoring for Message Queues, Semaphores, Shared Memory Segments for Linux, Solaris, AIX, and
Windows platforms.
Fixed Defects:
Fixed a defect where the probe did not clear the process up and down alarms. Salesforce cases: 00156008, 00156866,
00157484, 00154035, 00156940, 00156992, 00156510
Note: While upgrading the probe version from 3.83 to 3.91, process up and down alarms do not clear from
alarm console automatically. User has to acknowledge these alarms manually
Fixed a defect where the probe did not clear alarm from alarm console for CPU usage. Salesforce cases: 00155806,
00153144
3.83
Fixed Defects:
February
2015
Fixed a defect where the probe version 3.81 did not clear the process up or down alarms on the Alarm Console. Salesforce
case 00146533
3.82
Fixed Defects:
December
2014
Fixed a defect where only one process_down alarm was generating for all closed instances of a process. Salesforce case
00135021
Fixed a defect where suppression key is missing for process restart alarm. Salesforce case 00143378
Fixed a defect where the probe version 3.81 did not clear the process up or down alarms on the Alarm Console, when the
process was stopped. Salesforce case 00146533
Fixed a defect where the probe version 3.81 did not clear the Expected Instances alarms, when the process returns to the
expected instance number. Salesforce case 00148604
Fixed a defect where the probe did not clear the alarms when the process returns to the expected instance number. Salesf
orce case 00151678
3.81
Fixed an issue where certain alarms were being suppressed on selecting the Track Processes by Process Identifier checkbox,
while creating a profile. Salesforce case 00144501
October
2014
3.80
June 2014
3.77
Fixed Defects:
April 2014
Fixed an issue where a message was not getting deleted from the message pool even when the user tries to delete the
message without clicking Apply/OK.
Fixed an issue where alarm is generated with the default text and not the modified text when the user edits the default
MsgProcessRestart message, and restarts the probe and the process.
3.76
Fixed Defects:
February
2014
User was not able to add custom messages with clear severity in the Message Override list.
User was not able to get alerts with correct username (UID was getting displayed instead of username) when the
username characters are more than 8.
3.75
Fixed issue regarding probe defaults.
November
2013
3.74
Updated the probe defaults.
November
2013
Fixed memory leak issue on AIX.

Fixed an issue related to process name which starts with square bracket.
3.71
Fixed: GUI bug in processes related to exclude schedule.

SOC Defects Fixed
January
2013
3.70
Functionality to use user/ruser in ps command for UNIX added.
June 2012

Fixed incorrect metric definitions.
3.63
Fixed an issue for process stop action alarm related to expanding $errmsg variable.
June 2011
3.62
Fixed hang situation on individual process monitoring.
June 2011
3.61
High individual process CPU usage fix.
June 2011
3.60
Fixed incorrect cpu utilization issue.
May 2011
Added support process handle count monitoring in Windows environment deployments. This feature is not applicable for
non-windows platforms.
Added support for clearing alarms on restart for the profiles that are no more in the alarm state.
Fixed an issue related to $expected_user alarm variable expansion.
Added support for monitoring thread count for processes on AIX, LINUX & SOLARIS.
Added support for overriding QoS target at profile level.
Fixed a crash in thread count monitoring.
Fixed Service Oriented Configuration defect.
Additional error checking on fetching performance data.
3.52

Fixed CFX File.
3.51
Added option to limit processes seen to a configurable zone (Solaris).

January
2011
December
2010

Fixed memory leak.
3.40
Applied fix to resolve the issue: TNT2 metric different for clear alarms.
Fixed Desktop Handle leak.
3.30
3.21
Applied a fix related to process name display on UNIX platforms.
Fixed an issue related to process restart alarm.
August
2010
April 2010
April 2010
Fixed ci_metric_type for minimum memory usage alarm.

3.20

Added scheduler support for individual profiless QoS and Alarms.
March
2010
Added support for action command on alarms for CPU profile.

3.14
Added support for alarm clear when the monitored process goes down.
March
2010
3.13
Truncated process command line on windows to 4000 bytes.
February
2010
3.12
Added a fix to the data collector in the processes probe.

Alarm for incorrect instance not sent of the process is in the exclude list.
October
2009
Added the missing MsgCpuUsageMin and MsgCpuUsageRange alarms to the cfx file.
Added support for LINUX_22.
Overwrite of subsystem ID for all alarms is now possible.
Handling of process names greater than 32 characters in case of Solaris.
Script execution on alarm conditions.
Fixed the exclude functionality. No alarms or QoS will be sent for processes that are excluded.
Support for $robot variable in messages.
Added 'default' flag for alarm messages.
Improved error handling for fetching performance data.
Added default clear message. Fixed configuration tool and probe to enable the use of the clear message.
Fixed minor GUI bug when using the new grouping of profiles feature. Sometimes, when the user double clicks a process
in the status tab, and that profile is monitored by a profile, the profile would not be displayed unless the group were active
and selected in the profiles tab.
2.90
Added option to group profiles together. Group name can be used as part of alarm messages. Groups can be
activated/deactivated without having to activate/deactivate all profiles within a group. Profiles can be moved between
groups.
April 2009
Added option to clone a profile (create a new profile with same settings as the source).
Added option to select many rows in profiles list box.
Added option to 'track processes by process ID'. This opens up a new feature, to alert when a process has been restarted.
It also opens the possibility to send in individual QoS samples for otherwise similar processes. Processes which you can't
normally separate using the standard methods like regexp or command line arguments.
Added option to monitor process instances between a given range.
Added option to alert if avg. cpu falls below a given threshold (similar as thread count and memory usage).
Added option to invert the test for process owner (to be able to alert when a process is NOT running under a given user).
Easier than inverting a regexp method.
Fix: The GUI and the probe were treating the "proc_cmd_line" key differently which caused confusion. Probe accepted the
string without the key "scan_proc_cmd_line", while the GUI did not. Now the GUI will interpret these keys the same way
the probe does.
Fix: Improved various GUI input validation fields. Such as text fields which accept only numerical values should now only
accept that.
Improvement: When the GUI is talking to a processes probe which runs on a Windows system, it will display both the
working set (VM) and the pagefile memory in two separate columns for processes.
Fix: Trailing blank space in command line arguments caused profile matching to fail on Windows platforms.
2.73
December
2008
2.72
Probe update
November
2008
2.71
Fixed configuration tool problems with renamed profiles.

Fixed shortcut keys for create and delete profile.
September
2008
Fixed active state for on action input fields.

Added support for LINUX on 64bit PowerPC (glibc = 2.3).
Added support for 64bit AIX, HP-UX, SOLARIS and LINUX.
Note: For version 2.71 and higher of this probe, NimBUS Robot version 3.00 (or higher) is a prerequisite. You are
2.53
Windows: Program failure on > 4k command lines fixed.
October
2007
2.52
Windows: Case independence of regular expressions fixed.

Windows: Command line process lookup improved for 32-bit processes.
September
2007
Known issues:
The probe is unable to get the command line of 64-bit processes on Windows and of all processes on Windows Vista.
Since version 2.40, it is possible to try and retrieve process information again if the probe believes the data to be corrupt.
This limit has been defined to a default value of 1 (which means, try 1 more time and then give up). It can be tweaked in
the raw-configure to any number between 0 and 10.
2.51
UNIX: Added new versions to supported platform list:
May 2007
HPUX_11: 32bit (PA-RISC)

SOLARIS_10: 32bit (x86)
Windows: Optimized code for fetching CPU usage per process.
2.40
Fix: Improved logic to try and detect corrupted process information on some rare situations on HPUX. If the probe detect
corrupted data, there is a retry function that tries to retrieve process information again.
January
2007
Fix: The test button in the GUI, for testing a profile against running processes did not respect the 'Excluded processes' list.
This has been fixed.
Fix: The GUI sometimes didn't show if a process was being monitored, even if it the probe was monitoring the process.
The reason for this was that the GUI was trying to match profiles against the process list from the probe. The process list
returned to the GUI (from the probe) was a snapshot of current running processes. The process match against profiles
logic has been moved to the probe, so the list displayed in the GUI should always show the processes that are actually
being monitored by the probe. A process may also be monitored by more than 1 profile, which in previous versions the GUI
was unable to handle.
GUI: New input field to allow custom log file size.
GUI: The help button in the dialog for Profile Monitoring dialog is now pointing to Profile setup in the documentation.
Fix: Probe should no longer be case sensitive on all windows platforms when matching process owner, process name or
command line arguments.
GUI: Added a new menu item on the right-click context menu of the listview control that displays profiles. Prompts you to
give a new profile name. If you select OK and the name does not already exist, the profile will be renamed once you save
your config file.
GUI: The 'Expected Instances' field in the Profile Monitoring dialog has been changed to allow more processes. The limit
has been increased from 999 to 9999.
Windows: skip command line detection for 'System' process to avoid intermittent memory access violations.
2.35
Solaris: logging prints errno variable even when no error has occurred, making it seem as if there is a problem when there
isn't.
September
2006
Unix: Improved handling of child processes (fixes a problem with the signal handler hanging the probe in some cases)
Unix: Improved handling of forked processes
2.32
AIX: Fix problem getting the process list on v5.3
February
2006
2.30
Added process recognition by resource.
March
2005
Message variables are made available to more alarm situations. The current set of variables are: arguments,
command, description, errmsg, executable, max_restarts, pid, proc_cmd_line, process, start_dir, watcher
Instances
instances_expect
instances_found
instances_op
process_count
process_count_type
Processes
cpu_average
cpu_total
expected_cpu_usage
expected_size
expected_user
max_samples
op
samples
size
thread_limit
threads
user
time_delta
which
Window
window_name
window_class
window_text

The processes probe should be installed on systems with the following minimum resources:
Note: By default, the /usr/ucb package is installed with Solaris 10. It is mandatory to install this package manually with Solaris 11 to get
the probe working.
Important! If you install 32-bit OS in a Solaris system with 64-bit architecture, then the probe stops functioning and the status indicator
on the GUI turns red.

The processes probe requires the following software environment:

While upgrading the probe version from 3.83 to 3.91, process up and down alarms are not cleared from alarm console automatically.
User has to acknowledge these alarms manually.
For viewing the metrics that are available in the processes probe version 3.9 on the USM portal, you can perform any one of the following
actions:
Upgrade your NMS version to NMS 7.6 or CA UIM 8.0 or later.
Install the ci_defn_pack probe version 1.02. You must restart the nis_server when you deploy the ci_defn_pack.

Some known issues of the probe are:
Two profiles that monitor the same process are assigned the same suppression key (which is based on the process name). The probe
generates alarms for both the profiles, but the USM recognizes only one (based on suppression key).
The probe alarms are ambiguous if the monitoring profile of two or more processes have similar names. By default, the probe does a
regex check for processes names. For example, the probe considers NOTEPAD and NOTEPAD++ as similar names and hence
generates or clears ambiguous alarms.
The workaround for both these issues is to select the Track Processes by Process Identifier checkbox in the General Setup section of the
probe. When selected, the probe uses the profile name to generate suppression keys, allowing the USM to display the alarms accurately.
As with the previous release version 2.40, the probe can attempt to retrieve process information again if there are indications that the
data is corrupt. By default the probe re-tries once; this setting can be changed in the Raw Configure GUI to any value between 0 and 10.
The probe generated false alarms in alarm console for a profile having multiple processes with different names. For example, you create
a profile called nimbus* and select the Track Processes by Process Identifier checkbox in the General Setup section of the probe.
Now, when you deactivate any one of the nimbus processes, you get false alarms. Thus, you don't know which process went down and
which came up.
The workaround for this issue is to create a separate profile for each process.
qos_processor Release Notes

The qos_processor probe listens for QOS_MESSAGE subjects on the UIM bus, evaluates and potentially modifies some non-key attributes of the
record corresponding to the monitor. baseline_engine depends on qos_processor to save the QOS_BASELINE messages in the UIM database.
Both the qos_processor and baseline_engine probes are automatically deployed to the primary hub by the CA UIM Server installer.
Revision History
Version
Description
State
Date
1.25
What's New:
Minor software modifications.
GA
August 2015
1.24
Minor software modifications.
GA
December 2014
1.23
Minor documentation changes.
GA
September 2014
1.22
Defect fixes.
GA
June 2014
1.20
Fixed a defect where qos_processor failed to enrich some qos data due to database deadlocks in MySQL
GA
Mar 2013
GA
May 2012
Added alarm - QoS correlation and maintenance of baseline data.
1.10
Initial implementation.

Under normal operation, the maximum insert rate on a system where qos_processor and data_engine run together is 15,000 inserts per second.
The actual rate depends on performance of the hub hardware and is largely independent of the database type.
The qos_processor memory footprint directly correlates with the size of the S_QOS_DATA table in the database. The number of QoS objects
determines the maximum Java heap size:
Less than 500,000 2 GB
500,000 to 999,999 3 GB
1,000,000 or more 4 GB
Note: Use the Raw Configure utility to set the Java heap size. To determine current memory usage, run the get_statistics callback th
rough the probe utility and check the jvm_start_current_memory value

The qos_processor v1.25 probe requires:
Java Virtual Machine 1.7 or later
CA Unified Infrastructure Management v8.31 or later
CA Unified Management Portal (UMP) v8.31 or later
The qos_processor v1.24, v1.23, v1.22 probes require:
Robot 5.7 or later
Java Virtual Machine 1.6 or later
CA Unified Infrastructure Management v8.1 or v8.2
CA Unified Management Portal (UMP) v8.0 or later
Supported Platforms
The qos_processor probe is supported on the same operating systems as CA Unified Infrastructure Management.
reboot Release Notes

The reboot probe is a "timed" probe that reboots the computer according to the probe configuration. When activated the probe performs a reboot
of the computer at the specified point in time.
On initial installation the probe is not active. The default configuration sets the reboot time to five minutes past midnight every Monday morning.
You should modify the default configuration parameters according to your requirements before activating the probe.
Revision History
This section provides the history of revisions for the reboot probe.
Version
Description
State
Date
1.41
What's New:
GA
November
2015
Added support for IPv6.

1.40

Added support for Web-based Service Oriented Configuration (SOC)
1.30
Improved logging
December
2010
June 2010
Added 'or' keyword to activate_when syntax

Added NIS(TNT2) support
1.21
Fix for every weekday

Fix for the nth weekday of the month
September
2009
Previously working Example:

1. Reboot when at least one day has passed and it is Sunday evening after 10 p.m.: 'activate_when' = Sunday after 22:00
2. Reboot when at least 2 weeks and 1 day has passed and it is Sunday evening after 10 p.m.: 'activate_when' = 3rd
Sunday after 22:00
Current working Example:
1. Reboot when it is Sunday evening after 10 p.m.: 'activate_when' = Sunday after 22:00
2. Reboot when at least 2 weeks has passed and it is Sunday evening after 10 p.m.: 'activate_when' = 3rd Sunday after
22:00
1.20
1.13
Added support for Windows Itanium 2 systems (IA64)

Rebuild following NimBUS library fixes
Fix for nth week of month/year issue
1.11
Rebuild with new NimBUS libraries

June 2009
December
2008
September
2008
Note: For version 1.1 and higher of this probe NimBUS Robot version 3.00 (or higher) is a prerequisite. Carefully review the
"Upgrading the NimBUS Robot" document before installing/upgrading
1.05
Modified reboot flags

Added command line parsing help
December
2006
Alarm message, level and subsystem are configurable

1.04
Fixed parsing error - confusion between week-of-month and week-of-year
April 2003
rsp (Remote System Probe) Release Notes

The Remote System Probe (rsp) allows you to monitor system metrics. The probe collects performance data in an agentless manner without
installing proprietary software on the system.
Note: The rsp probe supports only password-based and key based authentication. Keyboard-Interactive and authentication less
method are not supported. If the UNIX-based remote server is not password-based or key-based authentication enabled, the rsp probe
is not able to discover the remote host.
Contents
Revision History
Monitoring Support
Supported Hosts
Windows Operating System
SSH Monitoring to UNIX Like Operating System
UNIX System Utilities for Data Collecting
Known Issues
Revision History
This section describes the history of revisions for this probe.
Version
Description
State
Date
5.11
Fixed Defects:
GA
October
2015
GA
June 2015
GA
March
2015
The time stamp in the probe configuration file did not match with the time of the last event that was generated on the
monitored host. So the probe sent duplicate alarms for the event. Salesforce case 00160027
If a process restarted with different command line parameter, the probe displayed the process in down state. Salesforce
case 00162366
On Linux platform, the probe displayed incorrect value for the Total CPU monitor. Salesforce case 00167398
5.10
What's New:
Fixed Defects:
The probe displayed wrong subsystem ID for alarms. Salesforce case 00166698
The probe accepted only 512 bytes in the event description and was storing the first 512 bytes in the database. Salesfor
ce case 00161142
5.01
What's New:
The probe generates priority alarms for all the metrics.
Fixed Defects:
Fixed a defect where if a process doesn't exist on the monitored remote system, alarms other than the process down
alarm do not expand the variables in the alarm message.
5.00
What's New:
Beta
March
2015
Updated the probe Infrastructure Manager GUI and Admin Console GUI for specifying the character encoding in
different locales.
corrupt the probe configuration file.
Fixed Defects:
Fixed a defect where the probe was not discovering the hosts on the SuSE r11 OS. Salesforce cases:
00132878, 00145831
4.03
Fixed Defects:
October
2014
Fixed a defect where the probe was collecting, and storing data of all the processes, ntevents, and services of all the
hosts. Salesforce case 00130220
Fixed a defect where the configuration details of a section, instance, or monitor was not displayed in the Profile
Templates node in the Advanced Configuration section of the monitor. (Salesforce Case: 00139452)
Fixed a defect in which the probe makes three consecutive attempts to discover and establish a WMI connection with
the host. Salesforce case 00143692
4.01
Added support for monitoring remote systems over Internet Protocol version 6 (IPv6).
March
2014
4.00
What's New:
December
2013
Implemented probe restart feature. RSP does not reload full configuration on adding/deleting/modifying a profile. Now
the probe restarts the configuration without closing the probe window.
Implemented Custom WMI feature. This enables user to monitor any WMI classes and objects.
Fixed Defects:
Defect fixed related to probe crash where the probe crashed on specific non-English locale process/service names.
Defect fixed related to mismatch in reported time of event on different OS. Event tab now shows local time irrespective
of Operating System.
Defect fixed where the probe was not alerting Critical event on Japanese Locales.
Defect fixed where the probe used to show large number of process bulbs when process was down.
Defect fixed: for the upgrade scenario of the probe from version 2.92, where probe is missing two key values. This
defect was affecting those users who have created custom groups in 2.92 and were upgrading to 3.0 onwards.
3.07
Fixed: RSP Service Monitors Change Slash (/) to Pound.
3.06
Implemented regular expression for processes.

Fixed a SOC issue where probe could not discover host outside subnet.
3.05
Fixed an issue where _rsp.log was not getting created intermittently.

Fixed an issue where probe did not leave port when it is disabled.
October
2013
September
2013
September
2013
Fixed a SOC issue where probe used to crash when cycle is left blank.
Fixed an issue where probe did not discover Solaris system where prtconf command returns error.
3.04
On windows QoS values for CPU system, wait, idle and user would be sent as NULL.
Optimized discovery callback to improve time for discovering hosts.
August
2013
3.02
Adding functionality to include monitoring of system wait and idle CPU time for windows
July 2013
Fixed a defect where swap memory was not getting reported on windows.
Fixed a defect where processes were not properly monitored if command line of any process contains a single quote().
Fixed a defect where probe was not alerting when swap memory is not present.
Fixed a broken functionality of passwordless ssh using passphrase.
Fixed a broken functionality of cpu monitoring on AIX.
Fixed a crash defect in expand_ipv6 callback when input parameters are not specified.
Fixed a crash issue when command line of a process is very long
Fixed issues related to incorrect number of instances shown on GUI.
Fixed an issue where folders having # in their names were not monitored.
Fixed an issue where probe shows process name instead of command line when profile is created as name +
commandline.
3.01
Reduced virtual memory footprint on linux OS.
June 2013
Fixed a defect where process selected as process + Commandline option from GUI does not appear.
Fixed a defect where rsp used to crash on windows after 1 day.
3.00
Improved scalability in RSP to support 6000 monitors(CPU, Disk and Memory).
June 2013
Report Viewer functionality is discontinued from GUI.(However, user can use UMP).
LUA load and clear alarms at startup has been removed.
Interval is now supported at host level instead of monitor level and all monitors are now governed by cycle. For example
a profile with interval 5 min and disk as 3 will have disk run after every 15 mins.
2.93
2.92

Fixed an issue of database growth.
Supported Japanese language in Probe GUI.
February
2013
January
2013
Supported Japanese reg-ex for the ntevents.

Fixed an issue of crash for solaris.
2.91
Fixed an issue related to "#" in service name.

Fixed an issue where sometimes rsp.cfg disappears.
2.90
Added support for $profile & $host for alarm messages.

Added support to consider entitled capacity for CPU utilization calculation.
October
2012
September
2012
Updated discover_host callback to add architecture and address_width values to CPU entries.
Fixed false positive alerts for monitored processes in LINUX.
Added support for password-less ssh (RSA/DSA).
2.81
Added support for IPv6 address range expansion for discovery feature.
March
2012
2.80
Fixed issue related to incorrect QOS and alarms for process instances. The discovery feature of address range for IPv6 is not
supported in this version.
December
2011
2.72
Fixed process monitoring on Linux with name+command option.

Fixed process CPU percentage reporting 0% for all processes on the VM ware environment.
November
2011
Added support for fetching machine name via SSH and WMI.
Updated libraries.
2.71
Fixed process monitoring on Linux with name+command option.

Fixed process CPU percentage reporting 0% for all processes on the VM ware environment.
October
2011
Added support for fetching machine name via SSH and WMI.
2.68
Fixed CPU discovery LUA script.

Localization fixes.
March
2011
2.66
January
2011
2.65
Stepped up version for Nimsoft Server 5.0 release.
December
2010
2.61
Fixed memory leak.

Fixed disk discovery LUA script.
2.60
Optimized the read buffers for event log to improve performance.

Optimized code to improve performance while reading large amount of wmi data.
December
2010
October
2010
Fixed possible probe restart situation in case of NTevent profile deletion.

Support for reading alarm tokens from cfg.
Initial support for internationalization of probe alarms.
Support for web-based Service Oriented Configuration (SOC).
2.52
Optimized code to improve the performance while reading a large amount of WMI data.
Fixed a crash in case of NTevent profile deletion.
September
2010
2.51
Optimized the read buffers for event log to improve performance.
July 2010
2.50
Added support for Solaris platform
June 2010
2.40
Added support for ntevent monitoring across multiple timezones.
June 2010
Note: Profiles which are monitoring event logs from machines that are not in the RSP probe's timezone need to be
reconfigured by deleting the section from the affected profiles.
2.31
2.30
Added fix to reduce CPU usage in case of monitoring events.

Fixed the issue of host_list returns garbage and removed special characters from description field.
Fixed repeated WMI errors for process monitoring on windows 2000 machine.
March
2010
February
2010
Fixed the NT Services configuration issue.

Added support for using sudo instead of root.
Included Group name in alarm message.
Some minor user interface fixes.
Fixed the issue of service failure in case of '/' in the display name. Note for '/': User will have to manually delete the
existing configured service (with '/' in the display name) and reconfigure the service to enable monitoring.
2.23
Removed the feature of sending checkpoint clear alarms on probe start/restarts.

Deletion of discovery data in case an instance of disk and cpu is removed from monitoring.
February
2010
Added a fix for the rarely occurring database locking issue.

Fixed memory leak which was introduced in version 2.20.
2.21
Fixed the issue of probe sending clear alarms on system restarts.

Fixed the issue of devices not being listed in the main UI in case of data collection failure.
2.20
2.17

Added support for data collection failure alarms.
Note: In RSP v2.17 and above in case of data collection failure, individual alarms for all discovered cpus/disks will not
be raised. A single data collection failure alarm with NULL QoS are sent instead. In case there is no data collection
failure and single instance of cpu/disk is missing then cpu/disk missing alarm for each missing instance will be sent with
NULL QoS for the missing instance.
December
2009
December
2009
December
2009
In case of data collection failure the checkpoint icon in GUI changes to data not available icon.
Fixed nimlog messages.
NTEvents_helper included in db cleanup.
Fixed the issue of incorrect NTEvent QoS count.
2.16
Fixed the bug in CPU.lua which wrongly reported 100% CPU utilization on some Linux machines.
December
2009
2.15
Added support for deleting the monitored CPU and Disk devices from the main user interface.
December
2009
2.14
Changed the RSP services QoS definition to match the QoS definitions of NTServices probe.
Added new key to hide irrelevant UI controls in case of default and inst_default template specifically in processes,
windows services and windows events template settings
December
2009
2.13
Minor GUI bug fixes.
July 2009
Fixed delay issue in Linux data collection.

Fixed issue for solaris processes data collection.
Windows Events Refresh button is causing regeneration of alarms for those events also for which alarms are already
raised.
Some minor GUI fixes.
Added alarm on missing wmi classes.
Added alarm in probe in case, event monitoring is enabled on windows 2000 machine.
Added a yes/no box in GUI in case, event monitoring is being enabled on windows 2000 machine.
Alarms and QoS are now sent only in the data of the current interval.
Fixed some minor GUI issues.
2.11
Minor bug fixes.
March
2009
2.10
Added mass configuration support for NTEvents, Services and Processes.
March
2009
2.02
Added functionality similar to Processes, NTEvents and NTH probe to existing RSP probe functionality.
Parsing of the data is now done using the Lua scripts instead of the C code.
December
2008
Added job queue to fix the problem DB locking issue in case of multiple threads inserting simultaneously in DB.
Modified DB to support Lua scripting.
Upgrade from 1.18 to 2.02
1.18
1.17
Fixed problem with deleted profiles being listed in host_info callback.

Interactive discovery will warn if a NimBUS Robot is running on a discovered host and not automatically create a
monitoring profile for it.
May 2008
March
2008
'Close' of the authentications window now works even when no authentication profiles exist.
1.16
1.15
Fixed problem with CPU data collection against HP-UX 11 systems.

Modified rediscover function in configurator to update the profile parameters.
The Windows disk label was changed from C: to C:\ to be compatible with CDM. This version adds upgrade code for the
configuration and database to reflect this change.
January
2008
November
2007
Add callback for use by the discovery process.

Discovery callbacks use the timeout specified in the calling application, rather than the global timeout value in the config
file.
1.12
Fix problem monitoring CPU usage on Linux systems.

Fixes in GUI.
September
2007
Ported to Linux systems running glibc 2.3 or higher.

Added database integrity test for discovery data.
Clear data for removed systems, so they no longer show up in reports.
Added option to bypass name lookups during discovery and use ip address as the host.
Added option to monitor paging in kb/s.
Fixed various data collection issues.
Added extra information about the operating system on each host to enable the Group Server to display dynamic
dashboards for monitored hosts.
1.03
Modified advanced setup configuration tree so that opened tree branches do not close on open of others.
February
2007
1.02
December
2006
The rsp probe gathers the following statistics on the CPU utilization, disk, memory usage, and load:
CPU usage (%) with multi-CPU support
The high severity (error) and low severity (warning) alarms for the total CPU usage.
The high severity (error) alarms for the individual CPU usage in multi-CPU systems.
Disk
Automatic local disk discovery
Disk Usage (MB or %)
Information retrieval on the local disk (Total disk space, Free disk space, and Used (%) disk space).
Memory
Total memory usage (%)
Physical memory usage (%)
The page file usage (%)
Swapping or the paging activity page/s
Load
Load at a specific moment
Processes
Alarms for the invalid process owner
Alarms for the invalid CPU usage
Alarms for invalid process size
Alarms for the invalid thread count
Alarms for the wrong number of process instances
Alarms on process up/down
Services (Windows Specific)
Alarm on the state of a service
NTEvents (Windows Specific)
Alarms on specified NTevents
Custom WMI (Windows Specific)
Alarm specific to an object of WMI class
The rsp probe monitors thresholds for all the data points it gathers and allows you to also gather the QoS data. The QoS names match those
used by the CDM probe since the gathered data is the same. To gather remote data, the probe uses WMI on Windows systems and native
commands on UNIX/Linux systems, either through SSH or telnet.
Note: These commands are run as the root user on UNIX or Linux systems. Therefore, it is strongly recommended that you use SSH to
avoid the root password being transferred without encryption over the network.
The rsp probe is multithreaded and allows simultaneous data gathering from several servers. You can monitor up to 50 servers simultaneously.
This number depends on several factors, which are as follows:
Monitoring of the Window computers is less time consuming as compared to UNIX computers
Using SSH is faster than using telnet
The capacity and speed of the network
The capacity of the computer hosting the probe
The capacity of the computers being monitored
Monitoring Support
The rsp probe runs on Windows and Unix or Linux operating systems as specified in the Support Matrix for CA UIM Probes. You cannot monitor
Windows machines from an instance of rsp running on a UNIX or Linux robot.
The host and the corresponding monitored platforms that are supported for the rsp probe are:
Windows->Windows
Windows->Unix
Windows->Linux
Unix->Linux
Linux->Unix
Linux-> Linux
Unix->Unix
Important! The rsp probe cannot be deployed on AIX systems but can monitor remote AIX systems running on only versions 4, 5, or 6.
Supported Hosts
From rsp version 5.0 and later, the probe supports hosts with the following encodings:
UTF-8: Unicode (UTF-8)
UTF-16BE: UnicodeBigUnmarked
UTF-16LE: UnicodeLittleUnmarked
UTF-32BE: Unicode (UTF-32 Big endian)
UTF-32LE: Unicode (UTF-32 Little endian)
Shift_JIS: Japanese (Shift-JIS)
ISO-2022-JP: Japanese (JIS)
ISO-2022-CN: Chinese(ISO)
ISO-2022-KR: Korean (ISO)
GB18030: Chinese Simplified (GB18030)
GB2312: Chinese Simplified (GB2312)
Big5: Chinese Traditional (Big5)
EUC-JP: Japanese (EUC)
EUC-KR: Korean (EUC)
ISO-8859-1: Western European (ISO)
ISO-8859-2: Central European (ISO)
windows-1250: Central European (Windows)
windows-1252: Western European (Windows)
Important!
Use a text editor like Notepad++ on Windows system and gedit on Linux system to edit your configuration file directly. If you
use Notepad as an editor, it appends BOM (Byte Order Mark) for an UTF-8 encoding file and the probe does not start with a
BOM included configuration file.
Do not use Raw Configuration GUI when the probe is deployed in a non-English locale.

2.01 and later with CA UIM 8.31 or later. Refer the threshold_migrator probe document for information on how to migrate a probe.
Probe specific alarm configurations in the probe monitors will be replaced by Static Alarm, Time To Threshold, and Time Over Threshold
configurations.
Probe template configurations will be displayed on the Admin Console GUI.
The Send Average Value in QoS and Send Qos per Process Instance fields on the rsp node will get enabled, if disabled. These two
fields must be enabled for Standard Static Thresholds to work.
The Publish Alarms checkbox will be applicable only for the static alarms.
The alarms for WMI objects will keep coming, even though the WMI objects are not configurable from the Admin Console GUI.
The threshold_migrator probe will only migrate the thresholds for CPU, Disk, Memory, and Processes of the rsp probe.
After migration of disk alarms, the threshold values and the configured alarm messages will change.
Note: For more information, refer Disk metrics in the rsp Metrics article.
The QOS_PROCESS_STATE that monitors the state of the process will not be migrated.
The higher threshold will be migrated for any monitor having same severity for both high and low threshold.
Any profile created with a group does not display on the Admin Console GUI under Templates drop-down.
If the monitors selected from the Admin Console GUI are not part of group, the QoS and alarms will not come for them.

The rsp probe must be installed on systems with the following minimum resources:
Memory: 2-4 GB of RAM. Probe's OOB configuration requires 256 MB of RAM

The rsp probe requires the following software environment:
Robot 7.6 or later (recommended).
Probe Provisioning Manager (ppm) probe version 2.38 or later (required for Admin Console).
Java JRE version 6 or later (required for Admin Console).
The rsp probe requires the following software environment to migrate with threshold_migrator probe:
The installation considerations for different operating systems are mentioned in the following sections.
Windows Operating System

Monitoring event logs may severely affect the performance of the monitored Windows 2000 systems.
Load, paging and process monitoring are not available over WMI for Windows NT / 2000.
To get service information from remote machine, credential must have the SC_MANAGER_CONNECT privilege enabled.
Unlike Windows XP/Server 2003, the results in Windows Vista and Windows 2008 are returned in order oldest to newest. This causes the
oldest records to be listed first. We need to find a work around for this or wait for vista/2008 SP2.
Processes, Services, Ntevents monitors requires huge processing and number of hosts/monitors need to be reduced suitably.
SSH Monitoring to UNIX Like Operating System

SSHD running on remote machines have limitations in form of number of concurrent sessions that could be make to the SSHD. If there are other
SSH sessions open to the remote server, then probe would not be able to connect to remote server. Number of concurrent SSH connections to
the sshd could be increased by increase the number of MaxSessions & MaxStartsup in the file /etc/ssh/sshd_config. These parameters are only
configurable in openssh SSHD version 5.2 and above.
UNIX System Utilities for Data Collecting

Each UNIX system requires utilities to be installed in order for data collection to work appropriately.
Solaris
/bin/uname
/usr/bin/mpstat
/usr/sbin/df
/usr/sbin/prtconf
/bin/vmstat
/usr/sbin/swap
/usr/bin/uptime
/bin/vmstat
ps -efo
Linux
/bin/uname
/bin/cat /proc/stat
/bin/df
/bin/cat /proc/vmstat
/usr/bin/getconf
/usr/bin/uptime
/bin/ps -eLo
AIX
/bin/uname
/usr/bin/pagesize
/usr/bin/hostname
/usr/sbin/sar
/usr/bin/df
/usr/sbin/bootinfo
/usr/bin/vmstat
/usr/bin/uptime
/usr/bin/vmstat
/usr/sbin/swap (AIX 5.x)
ps -efo
HP-UX
/bin/uname
/usr/bin/sar
/usr/bin/df
/etc/dmesg
/usr/bin/vmstat
/usr/sbin/swapinfo
/usr/bin/uptime
/usr/bin/vmstat
ps -efl
Tru64 (OSF1)
/bin/uname
/usr/sbin/collect
/usr/bin/df
/bin/vmstat
/usr/sbin/swapon
/usr/bin/uptime
/bin/vmstat
ps -efo
Known Issues
The rsp probe expects the data to be returned by the hosts being monitored. In case of failure to collect the data from hosts, the probe
raises an alarm and sends NULL QoS. In some cases, where max values in QoS are dynamic, the QoS data is discarded by data engine
as the data is not available from the hosts.
At startup, the rsp probe looks up the host name and sends data integrity alarms for each host. If these alarms are generating slowly
(delay of 4-5 sec between each alarm) instead of a burst then there might be some problem in DNS setting of the server where the probe
is running.
The probe does not support monitoring of forwarded events.
You may see inconsistency in cycles shown in GUI and template.
The probe cannot monitor remote Windows server if the probe is deployed on a linux or solaris system.
The probe does not support host name and user credentials with non ASCII characters.
The Admin Console GUI of the probe has the following additional limitations:
Profiles created from the Admin Console GUI are not available on the IM GUI.
The probe does not provide creation of custom WMI profiles.
The probe does not provide monitoring through template.
Note: If the probe is migrated using threshold_migrator 2.01, the template configurations are also available on the Admin
Console GUI.
The probe does not provide discovering range of IPs.
salesforce (Salesforce Monitoring) Release Notes
Salesforce is a cloud-computing platform that provides physical computing infrastructure and a common application platform that runs on the
infrastructure. The salesforce cloud infrastructure consists of a set of datacenters (referred to as salesforce instances). The datacenters can be
located anywhere in the world.
The salesforce probe monitors the following parameters on the Salesforce cloud using the page http://trust.salesforce.com/trust/status/:
Average transaction speed in milliseconds: The transaction speed is calculated as the difference between the entry and exit time-stamps
of a user from the Salesforce application server. The transaction speed is an average of all transactions across all salesforce instances.
The average is calculated for a 24-hour period defined by UTC time.
Number of transactions: The total number of transactions executed within the cloud.
Instance Status: Each salesforce instance displays the current operating status. Typical values are: Instance Available (operating
normally), Performance Issues (instance performance degraded), Service Disruption (severe service degradation), Informational
Message and, Status not Available (offline).
The salesforce probe can monitor any number of organizations. For each organization, the probe can measure the following QoS parameters:
Web Login Logout timing: The time taken to log in and log out from the selected organization through the Web.
Data Storage Used: The amount of data currently stored for the organization. Organizations typically have contractual limits as to how
much data they are permitted to store.
File Storage Used: The number of files currently stored for the organization. Organizations are contractually limited as to how much file
storage they are allowed to use.
Number of API calls in the last 24 hours: The count of web service API calls made to the organization in the last 24 hours. Organizations
have a contractual limit as to how many API calls they are permitted in one day.
API Login Logout timing: The amount of time the system takes to log in and log out from the organization through a web service API call.
Query Execute Time: The amount of time the system takes to execute a query against an organization. The probe user can define any
number of custom queries to execute.
Number of Objects: The number of objects returned by the specified query.
Query Returned Value: The probe can extract a specific value from the result objects of a query and can use that value for generating
QoS.
Important! The salesforce probe from version 2.0 and later is accessible only through the Admin Console GUI and not through the
Infrastructure Manager GUI. Upgrade from any previous version of the probe to version 2.0 is not supported.
Contents
Revision History
Revision History
Version
Description
State
Date
2.0
GA
January
2015
The probe is now available only through the Admin Console (AC) GUI and not through the Infrastructure Manager (IM)
GUI.
Upgrade from previous versions to version 2.0 and later is not supported.
Note: Probe is supported from CA Unified Infrastructure Management 8.0 and later only.
This section contains the considerations for the salesforce probe.
The salesforce probe version 2.0 and later is available through Admin Console (AC) GUI only and not through the Infrastructure Manager
(IM) GUI.
Upgrade from previous versions to version 2.0 is not supported.
If you have been using a probe version prior to version 2.0 then you must manually transfer the existing configurations to the new
version.
You must remove all the versions of the salesforce probe that are older than version 2.0 as upgrade to version 2.0 is not supported.

The probe requires:
CA Unified Infrastructure Management8.0 or later
sdgtw (Service Desk Gateway) Release Notes

The sdgtw (Service Desk Gateway) probe acts as a gateway between CA Unified Infrastructure Management (CA UIM) and service desk
applications. Through CA Normalization Integration Management Service Management (CA NIM SM), the probe supports the connection from CA
Unified Infrastructure Management to multiple different service desk applications, and to multiple instances of the same service desk application.
Revision History
Prerequisites
System Requirements
Limitation
Troubleshooting
Revision History
Version
Description
State
Date
1.01
What's New:
Beta
Oct 2015
Beta
September
2015
Support for Salesforce (SFDC) Service Cloud

The Incident Status for Alarm Acknowledgement field added to the Incident to Alarm Sync Settings section
enables you to specify comma-separated values for an incident status (for example, Closed, Resolved). Based on the
specified values, the alarms corresponding to an incident are acknowledged.
1.00
Initial release
Prerequisites
The CA Unified Infrastructure Management Alarm Server (nas) probe must be installed and activated.
System Requirements
The probe should be installed on a system with the following minimum resources:
Memory: 2-4 GB of RAM
CPU: 3 GHz dual-core processor, 32-bit, or 64-bit
The probe requires CA Unified Infrastructure Management v8.1-8.3.
The probe is compatible with the following service desk applications:
Service Desk Application
Version
BMC Remedy
8.1
CA Cloud Service Management
Bamboo Release
CA Service Desk Manager
12.9
HP Service Manager
9.30
SAP Solution Manager
7.1 SP12
ServiceNow
Calgary, Dublin, Eureka, Fuji
Salesforce (SFDC) Service Cloud
Winter 2015
The probe supports the following operating systems:
Windows 2008 Server

Windows 2012 Server
Red Hat Enterprise Linux 6
Cent OS 6
Limitation
If the Launch in Context URL from a Service Desk contains single quotes, then the single quotes( ) are replaced with the HTML ASCII code
(&#39) and is displayed in the configured custom field of CA Unified Infrastructure Management.
For example, if the Launch in Context URL is as follows:
http://<host name>:<port>/arsys/servlet/ViewFormServlet?form=HPD:Help
Desk&server=<host name>&qual='1000000161' == "INC000000000658"
Then the URL is displayed in the following format in the custom field of CA Unified Infrastructure Management as follows:
http://<host name>:<port>/arsys/servlet/ViewFormServlet?form=HPD:Help
Desk&server=<host name>&qual=&#391000000161&#39 == "INC000000000658"
To access the URL from a browser, replace the HTML ASCII code (&#39) with single quotes ( ').
Troubleshooting
Symptom:
The probe fails to save the configuration details when the probe is deployed on a robot which is not present on a primary hub machine.
Solution:
Change the probe security settings as follows:
1. Open Admin Console.
2. Select Settings, Probe Security.
3. In the Probe Security page, change the Access level setting for "ppm" and "sdgtw" probes to "admin".
4. Restart ppm and sdgtw probes.
Symptom:
The probe generates an alarm in CA Unified Infrastructure Management because incident creation or updating failed in a service desk.
Solution:
Check the connection details of the Service Desk in the sdgtw.cfg file.
Symptom:
The probe generates an alarm in CA Unified Infrastructure Management because it failed to update the custom alarm fields in CA Unified
Infrastructure Management.
Solution:
Restart the probe.
Symptom:
The probe fails to create an incident.
Solution:
The probe can fail to create an incident because of a mismatch between the alarm field and the service desk field. Check if any of the service
desk fields require specific values to be entered in the alarm field that is mapped to them. For example, the impact field of a service desk accepts
only High, Medium and Low as values. Map the impact field to an alarm field that contains the same values of High, Medium and Low.
Symptom:
For SFDC Service Cloud, I configured the probe to change the status of incident to Resolved when an alarm is deleted in CA Unified
Infrastructure Management. But the incident resolution fails.
Solution:
For SFDC Service Cloud, for the Incident Resolved Status field, select Closed instead of Resolved. The incident in SFDC Service Cloud does not
have a Resolved status.
Symptom:
The probe fails to subscribe to a configured queue.
Solution:
Check the connection details and the status of the relevant service desk. The probe subscribes to a queue only when you configure a connection
to at least one service desk. If the probe cannot connect to a service desk, the probe does not subscribe to the queue.
Symptom:
The probe unsubscribes to a queue.
Solution:
If the probe fails to update a custom alarm field due to a problem in CA Unified Infrastructure Management, it is unable to subscribe to the
affected queue. Restart CA Unified Infrastructure Management. If that does not resolve the issue, contact your CA Unified Infrastructure
Management administrator.
Symptom:
For SAP Solution Manager (SAPSolManager), I changed the status of an incident to Closed. But the corresponding alarm in CA Unified
Infrastructure Management is not deleted.
Solution:
Synchronization of incidents to alarms is not possible for SAP Solution Manager. If an incident is closed in SAP Solution Manager, then the
corresponding alarm is not deleted in CA Unified Infrastructure Management.
service_host Release Notes

The Service Host (service_host) probe is released as a part of the core Unified Infrastructure Management Server release. For this reason,
release notes for the Service Host probe are included in the Unified Infrastructure Management Release Notes on the CA UIM Documentation
Space.
sharepoint (Microsoft SharePoint Server Monitoring) Release Notes

The sharepoint probe supports monitoring of Microsoft SharePoint servers:
Microsoft Office SharePoint Server
Microsoft SharePoint Services 3.0
Microsoft SharePoint 2013
Contents
Revision History
Revision History
Version
Description
State
Date
1.70
What's New:
GA
June 2015
GA
March 2013
Added a checkbox on the Infrastructure Manager GUI to enable and disable alarms for thresholds that have QoS
data.
1.60
Support for SharePoint Server 2013.

Fixed defect of showing ::1 instead of IP.
1.51
1.50
Fixed Issue: Sharepoint is sending hostname on source field instead of the IP address
Fixed Issue: SharePoint probe not working on SharePoint Server 3.0.
July 2012
April 2012
Fixed Issue: Displays wrong version. HELP file activated

1.42
1.40
Fixed SOC issues

Enhanced UI performance.
December
2011
June 2011
Added fix to make correct counter selection.

New performance counters added.
1.31
Profile name column stay expanded
June 2011
1.30
December
2010
1.21
Added fix to make default service profiles compatible with SharePoint 2010 setup.
November
2010
1.20
June 2010
Added code to remove whitespace.

Added fix to set QoS value properly.
Added fix for crash on probe restart..
1.10
Updated the latest Nimbus Dot Net API with SSL support.
June 2010
Added profile name to QoS target in all QoS to differentiate between profiles.
1.02
1.01
If controller is configured to use robot name for QoS, the probe will send configured name in the QoS source.
Otherwise the probe will send the host name in QoS source
Added fix in eventlog profile to minimize CPU usage.
September
2009
August 2009
Added fix for crash on probe restart. Updated bmake and package file for win64 support.
1.00
Initial release.
June 2009

2.0 and later with CA UIM 8.3 or later. Refer the threshold_migrator probe document for information on how to migrate a probe.
Note: The changes in the probe after migration are:

The Infrastructure Manager (IM) GUI of the probe will not be available and the probe will only be configured using Admin
Console (AC).
Probe specific alarm configurations in the probe monitors will be replaced by Static Alarm, Time To Threshold, and Time Over
Threshold configurations.

The sharepoint probe must be installed on systems with the following minimum resources:

The sharepoint probe requires the following software environment:
CA Unified Infrastructure Management7.5 to 7.6 or CA Unified Infrastructure Management 8.0 or later
Java JRE 6 or later
Microsoft .NET Framework 3.5 on the system where the Robot is installed.
The probe and manager machines require Microsoft .NET Framework 2.0 Runtime installed. On 64-bit Windows machines, the probe
requires 64-bit Microsoft .NET Framework 2.0 to run as 64-bit native application.
The sharepoint probe requires the following software environment to migrate with threshold_migrator probe:
sla_engine Release Notes

The primary task of the sla_engine probe is to compute Service Level Agreement (SLA) compliance based on the settings for the different SLAs
entered in the Service Level Manager (SLM).
Calculation jobs are automatically started and run on a schedule specified in the sla_engine user interface. Calculation jobs may also be started
manually from the Service Level Manager. The result of the calculation jobs are stored in the UIM database. Reports are formed on demand by
the CA Unified Management Portal (UMP) SLM and SLAReport portlets.
Note: In order to obtain proper time zone calculations the sla_engine must be deployed in the same time zone as the data_engine
probe.
Contents
Revision History

Scaling the Calculation of Compliance
Revision History
Version
Description
State
Date
3.72
Fixed Defects:
sla_engine calculates and reports data automatically without occasionally dropping SLA periods. Salesforce cases:
148390, 154959, and 159677
GA
August
2015
Controlled
Release
July
2015
3.71
3.7
Service Level Objectives (SLOs) can now use QoS metrics with names up to 255 characters. Previously, it was limited to 64
characters.
GA
Dec
2014
3.63
Minor defect fixes. No documentation changes.
GA
Sep
2014
3.62
Fixed issue in which sla_engine would calculate some SLAs incorrectly in Interval mode.
GA
Mar
2014
3.60
Fixed defects:
Fixed setting any arbitrary timepoint in the GUI as the starting point for an SLA interval.
GA
Jun
2013
Improved handling of missing data sample(s) in an interval period.

Fixed time zone issue where an SLA is calculated at less than 100% even though all samples are available and in
compliance.
Fixed time zone mappings.
3.59
Fixed the rounding error in doubles calculation.
Jan
2013
3.58
Fixed sla_engine restarts continuously in a cluster environment.
Oct
2012
3.57
Fixed getting the wrong timezone when there are multiple locales using the same timezone description.
Jul
2012
3.56
Fixed non-standard database ports for MYSQL, MSQL and Oracle

Fixed sla_engine asynchronous data calculations.
May
2012
Fixed Oracle cursor leaks.

3.55
Added the updated mysql_nis_base_create.sql script. This file updates the database to improve the startup performance of
the sla_engine.
Mar
2012
3.54
Added a check for the database version. If the database is up-to-date, the create database script is not run.
Feb 28
2012
3.53
This version corrects the time zone calculation for SLAs that are created for time zones other than the time zone the
sla_engine and data_engine are deployed in. Changed MySQL driver to version 5.1.18. Requires Robot version 5.51 or
better.
Feb 21
2012
3.49
Longer timeout in calculation, so calculations will complete with large amount of data.
Jun
2011
3.48
Fixed SLA Engine not updating operating period for SLA of more than one month.
Setting application in oracle database connection.
Mar
2011
Fixed both SLA engines becoming slave.

Fixed SLA calculation stops.
Fixed Median for QOS calculation.
SLA Engine now registers its address with data engine.
3.38
Minor fixes.
Dec
2010
3.34
Minor fixes.
Nov
2010
3.29
Added support for MYSQL and Oracle databases.
Oct
2010
3.03
New multi-expression plugin.

New engine for multiplatform support.
2.13
2.10
sla_engine no longer fails with errors in the log under certain period conditions.
Added a section for changing default alarm settings in the configuration file.
Added support for custom alarms per SLA/SLO, configuration of this is done in the SLM.
Jul
2010
Mar
2010
Aug
2009
Native 64-bit support for Windows (not IA64 however).

Support for the SLM 4 data model.
Changed algorithm for creating operating period SQL statement to support minutes.
1.57
The multi-series plugin can now treat missing data as down in the calculation.
Mar
2007

None.

The sla_engine probe requires the following software environment:
Robot 5.7 or later
CA Unified Management Portal (UMP) 8.0 or later
Plan to deploy the sla_engine probe in the same time zone as the data engine.
Deactivate the sla_engine probe before performing an upgrade of the probe.
Deploy the sla_engine probe from the archive in the normal manner.
Scaling the Calculation of Compliance

When multiple SLAs are defined, you can speed up the compliance calculation by installing another sla_engine probe on another robot controlled
by the SLM hub. The additional sla_engine is automatically defined as a slave to the master sla_engine and is assigned SLA calculations in a
cooperative manner.
Note: Once the sla_engine is set to run in either Master or Slave mode, this setting can only be changed in Raw Configure. For more
details, see the sla_engine probe article.
smsgtw (Short Message Service Gateway) Release Notes
The Short Message Service Gateway (smsgtw) probe provides a powerful tool to send alerts and messages over GSM digital cellular telephone
networks. Mission critical systems and applications alerts can be forwarded automatically to a mobile telephone. The bi-directional communication
enables the user to request "status" from the monitored systems.
Extensive high-availability features are built into version 2.x and above, such as Hot-Standby and Fail-Over. It is also possible to handle more two
adapters (E.g. SMSC and external GSM phone) on a single gateway. A smsgtw client is also available, enabling any PC to send SMS messages
from their desktop environment using the same gateway.
Contents
Revision History
Prerequisites
Revision History
Version
Description
State
Date
3.10
What's New:
GA
September
2014
Added support for Windows 2012 R2.

Fixed Defects:
Fixed a defect in which the time of alerts sent as an SMS would reset to the probe restart time. Salesforce case
00134930
3.03
Resolved wrong logging and proxy issue.
GA
October
2013
3.02
First Port Number issue fixed.
GA
April 2013
GA
December
2012
GA
June 2007
3.01
Complete java based solution.

Windows-32/64bit support.
Multiple token support.
Minor GUI change for static text of Message Length of Outgoing Messages.
2.14
Added reinit of devices at restart, default generic modem for usb connections, added com ports to 16, updated
documentation.
Added support for MultiTech modems, and for Cingular SMS services.
SMS gateway now does a cold start if its connected to secondary device for more than 5 minutes without switching
back to primary device.
Added support for DATEK SMSC version 2 messages
2.10
Added support for DATEK SMSC.
GA
February
2004
Prerequisites
A connection to the PC normally provided by the modem manufacturer, for example Multi-tech Modem Driver. This could be RS232
based or USB based.
One or more Robot.

The smsgtw probe must be installed on systems with the following minimum resources:
CPU: 3-GHz dual-core processor, 32 or 64 bit
GSM Modem with Supported Network Configuration

The smsgtw probe requires the following software environment:
Java JRE 6 or later
sngtw (Service Now Gateway) Release Notes
The ServiceNow Gateway probe is used to generate an incident in the Incident Management process of the ServiceNow platform from the NMS
Alarm. Generating an incident helps the service desk user to take corrective actions for resolving an issue. The incident is generated when an
alarm is assigned to the designated NMS user.
The Service Now Gateway probe is currently certified on calgary version of servicenow. The probe supports Basic authentication type to manage
connections to a ServiceNow instance through a proxy server.
Contents
Revision History
Revision History
This section describes the history of the revisions for sngtw probe.
Version
Description
State
Date
2.12
Fixed Defects:
GA
June 2014
The Custom2 field was storing the wrong Service Now URL for the created incident.
Alarms were being cleared automatically every hour by the Service Now account causing new incidents to be created.
Alarms were not cleared for incidents resolved or closed in Service Now.
2.01
Fixed Defects:
GA
April 2014
Fixed an issue for generating a dynamic URL to ServiceNow incident when the ServiceNow URL is based on IP
address.
Fixed the field mapping functionality to map the date time field of the NMS alarm to the String type field of the
ServiceNow incident.
Fixed the Time Arrival, Time Origin, and Time Received fields for supporting a user defined format through Raw
Configure.
2.00
Implemented feature to invoke SN instance from USM device View.

Implemented feature to invoke USM device view from SN Instance.
Implemented alarm update feature - If alarm get updated, respective incident will also be update at SN side.
Implemented alarm closure feature - If alarm get acknowledged OR Clear at NMS, respective incident will also be Resolved /
Closed at SN side.
Fixed performance issue while creating multiple ticket simultaneously.
Fixed issue which was causing error prone data into configuration against sd_alarm_ids for alarm update / close.
Provided Backward Compatibility while upgrading probe for already created incidents.
June 2013
1.21
Fixed issue to Close NMS alarm on both Resolve / Closed event at service now side.
User can configure Close / Resolve incident based Request XML using SngtwRequestXML.properties file.
User can configure service now field which contains NMS alarm ID for close incident query.
Fixed issue to disable retry functionality.
Fixed issues to support few string into Message text during incident creation (& / $)
April 2013
1.20
Service Now Gateway would now be able to retry for ticket creation on failure. Retries are configurable from probe
configuration.
User can configure how what alarm severities can trigger ticket creation.
Service Now Gateway now has capability to query resolved incidents in order to close alarms.
Fixed issue where the probe configuration window opened to the field mapping tab directly.
Fixed issues with the field mapping window where duplicate service desk field mapping was added if an existing mapping
was opened for editing and source alarm field was updated.
Corrected handling of last_incidentcheck_timestamp. Previously, if the probe could not find a ticket closed by the alarm it
skipped last_incidentcheck_timestamp update. Additionally if the last_incidentcheck_timestamp was present in the
configuration file it generated an unrealistic future date to fetch closed incidents.
September
2012
1.10
Changed the subsystem ID of Service-Now Gateway Probe to 2.17.1.

Fixed Issue related to Service-Now Gateway probe failing when "Test" Button is used to check service availability.
Service Now Gateway probe now defaults the last_incidentcheck_timestamp to Current Date - 24 hrs to ensure that we
process a limited set of incidents.
Alarm Severity Field Mapping to allow users to map the alarm severity with Incident ticket's Impact/Urgency/Priority.
June 2012
1.01
Added support for :

Two way synchronization of incidents/alarms.
Check Service-Now server disconnection.
Probe restart functionality after CASD server is detected up and running.
Offline management for alarms.
Assigning incident ID to custom fields after alarm is assigned.
Timezone handling for synchronization process.
Configurable Service-Now user to whom alarms will be assigned.
Field mapping for custom Field1Field5 and User Tag1, User Tag2.
Added support for Linux and Solaris.
Added support for custom fields for field mapping.
Issue fixed for origin for field mapping.
August
2011
The sngtw probe must be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. The OOB configuration of the probe requires 256 MB of RAM
The sngtw probe requires the following software environment:
Incident Management process of the ServiceNow platform
UMP 6.6.0 for assigning alarms and communication between the UMP and ServiceNow platform

The sngtw probe initially takes some time while upgrading it from a previous version (earlier than 2.0) to 2.0. CA recommends you to wait for at
least 1-2 minutes for each 1000 alarms, which are already assigned to the sngtw user.
snmpcollector (SNMP Data Monitoring) Release Notes

Simple Network Management Protocol (SNMP) is an internet-standard protocol for managing devices on IP networks and consists of a set of
standard for network management, including application layer protocol, database schema, and a set of data objects. Typical devices that support
SNMP are routers, switches, servers, workstations, and printers.
The SNMP Data Monitoring (snmpcollector) probe allows you to monitor network-attached devices for conditions that require administrative
attention.
Revision History
Version
Description
State
Date
2.26
What's new:
GA
October
2015
GA
August
2015
GA
July 2015
Streamlined rediscovery process when interface index shifts occur.

Streamlined rediscovery behavior during snmpcollector restart.
Enhanced verbose logging to log stack traces when exceptions occur.
Pollagent now restarts all delta calculations for a device when the device transitions from unreachable to reachable.
Previously, the probe would attempt to calculate a delta with the last value read before the device became
unreachable.
Created a pollagent self-health monitor to provide overall insight and increase the resiliency of pollagent. The Poller
SpecialDebug.log file continually logs thread counts that are greater than 100. The probe reads this file and restarts
if threads are unavailable for longer than 15 minutes. The log file is found in <Nimsoft>\probes\network\pollagent.
Pollagent now reads startup parameters in a pollagent.cfg file. This file allows the startup options to remain in place
during an upgrade. The file is found in <Nimsoft>\probes\network\pollagent.
The probe now performs license checks.
Simplified the probe configuration by removing the configuration for custom monitors.
Hardened concurrency guard to snmpcollector configuration and component files.
Hardened pollagent behavior during a timeout and the sysUptime query fails.
Re-architected TaskController to prevent race conditions during data read/write.
Throttled back aggressive discovery/rediscovery behavior to only process requested devices in the rediscovery
callback.
DevIDs no longer change to GUIDs.
Setting the discovery time to 0 no longer causes discovery to go into an infinite loop. A setting of 0 inactivates
discovery.
Corrected an issue with unpredictable component configuration file behavior for unreachable devices.
Corrected an issue where an index shift would cause the probe to stop publishing QoS data for the device.
Corrected an issue with device rediscovery where the probe would drop existing polled metrics when new
components, properties, or metrics are added to an existing device.
Corrected an issue where pollagent intermittently stops polling with no errors or obvious reason.
Updated metrics for:
Checkpoint Firewall memory reserved
InfoBlox DHCP metrics
Firewall VSX Chassis memory reserved
Bluecoat CPU utilization
Checkpoint traffic metrics
Checkpoint memory metrics
Juniper netscreen total connections
Bluecoat proxy cpu utilization
F5 connection metrics
Nexus 7k number or port channels active
RPF Poxy load average
McAfee CPU utilization
2.23
What's new:
The Component User-Defined Property field now persists with rediscovery.
IP addresses that were incorrectly appearing in hex now appear as IP addresses.
Corrected issues with metric families causing device discovery to poll too many OIDs
Corrected issues where changes to metric families were causing template upgrades to fail.
Corrected an issue where agent restarts would cause the probe to incorrectly calculate metrics with delta values.
2.21
What's new:
The custom properties on device profiles now appear correctly in the probe configuration GUI.
The default templates are now read-only and inactive. Activate these templates through the template editor to apply
the default metric settings to your devices.
2.2
What's new:
GA
June 2015
GA
April 2015
GA
March
2015
GA
December
2014
Added the ability for users to define their own custom properties on device profiles. Use these properties to further
refine the rules for applying a template filter.
Converted metrics from polled to nonpolled so they no longer appear incorrectly in monitoring templates.
ManagementRedundancyRole and LastRestartReason in the Server Statistics metric family
SourceIpPort, DestinationIpPort, IpProtocol, EtherType, and MediaRingType in the System Ip Policer metri
c family
PolId and PolPriority in the Acl Stats metric family
2.11
What's new:
Added the ability to set a fixed time for data collection within the polling interval. The RandomFixedSchedule config
uration option is in the pollagent fh.conf file (<Nimsoft>\probes\network\pollagent\conf). The default probe
behavior is to collect data at a random point within the interval. When RandomFixedSchedule=true, data collection
occurs at a fixed time.
The probe now publishes data in USM by host name. Previously, the default behavior was to publish data by IP
address. You can disable this behavior in the probe Raw Configure setup options.
The device Availability metric allows you to determine if the device was available within a polling interval. The metric
value is 100 percent if the device was operating the entire time since last polling cycle, or 0 percent if the device
stopped operating for some time since the last polling cycle. This fix corrects the known issue, "The Availability
metric value is either 100 or No Value (null)".
Corrected an issue with deprecated metric families that was causing template migrations from v2.0 to v2.1 to fail.
Updated metrics in the following metric families:
DNS metric family has the CacheHitRatio metric
System Session Information metric family has the SessionRate1Min metric
License Management metric family contains the TotalLicenses and UsedLicenses metrics
Updated memory and disk requirements for v2.1 snmpcollector and pollagent.
2.1
What's new:
Created a Self-Certification portlet in USM. The portlet is a wizard that allows you to add new device and MIB OID
support to the snmpcollector probe. Use this tool if existing device metrics are not sufficient, or you have an
unsupported SNMP enabled device. For more information, see SNMP Device Self-Certification.
Added support for multiple SNMP Credentials for CA SystemEDGE devices.
Reduced probe memory requirements.
Created a probe meta-package to install snmpcollector and its dependant packages.
Deprecated the Alternate Interface, Cisco UCS Switch Fan, Cisco UCS Switch Power Supply, and Environmental
Sensor Temperature Status metric families. The deprecated metric families contained metrics that were duplicated
in the Interface, Fan, Power Supply, and Temperature metric families.
Alarms are generated when thresholds are set within the Reachability metric family.
Corrected an issue where duplicate interfaces appear due to the grouping of devices in the probe inventory.
2.0
What's new:
Created the snmpcollector Device Support tool. This website allows you to view supported SNMP devices, object
identifiers (OID), vendors, vendor certifications, metric families, and associated metrics. For more information, see sn
mpcollector Device Support.
Added the ability to create monitoring configuration templates. These templates allow you to apply consistent
monitoring configurations across multiple devices by using filters.
Added options to modify the polling frequency on devices, interfaces, and other components with template filters.
Added a default monitoring configuration template that supports At a Glance Reports.
Added discovery filters to control the list of devices that are retrieved from the discovery server. Discovery filters
govern the available monitoring targets that appear under the Profiles node.
The following settings are available in the probe configuration GUI:
Configure the SNMP port number in a device profile.
Override interface network speed.
Configure the polling frequency on a device, network interface, or component.
Removed the Metric Families node from the probe configuration GUI.
View raw interface table attributes when you select the Interfaces category for a discovered device. Attributes
include ifIndex, ifName, ifDescr, ifPhysAddress, ifAlias, ifType, ifAdminStatus, ifOperStatus, and ifMtu.
In UIM, added the ability to view the QoS metrics by interface.
1.61
What's new:
GA
July 2014
GA
June 2014
GA
May 2014
GA
April 2014
GA
March
2014
GA
March
2014
GA
February
2014
GA
January
2014
Metrics with a RollupStrategy of sum are now calculated as a rate over time since the last polling cycle.
The probe now supports floating-point numbers on robots where decimal points are represented as commas.
Added more metric families.
Added support for dynamic indexes to the Response Path Test ICMP, Response Path with ICMP Jitter, and Resp
onse Path with Jitter metric families. The dynamic index MIBs are cisco-ipsla-ethernet, cisco-rttmon, and ciscorttmon-icmp. This change was added to support Cisco network device monitoring tests. In these tests, new rows
are periodically created to store data with a new timestamp in the index.
Fixed an issue where changes to a component threshold value resulted in the removal of all other threshold values
1.6
What's new:
Added a servlet to view the internal status of the pollagent probe. The URL to access the servlet is <robotSystem>:
9715/Dump/Help.
Added automatic device rediscovery with an index shift occurs.
Added functionality for monitoring probe self-health.
1.42
What's new:
Added the ability to override the default speed in and out settings for interface devices. For more information, see the
updated Known Issues and Workarounds section.
Fixed an issue with the calculation of metric counter values.
1.41
What's new:
Fixed an issue where large values for the QoS metrics were calculated incorrectly.
Fixed an issue with inventory corruption when loading USM devices.
Removed the obsolete metric family Generic System CA. Metrics were moved into specific device metric families.
1.4
What's new:
Support for SNMP AES-192 and AES-256 privacy protocols.
Support for polling 50,000 interfaces every 5 minutes.
Added full support for Juniper devices.
Improved handling of index shift for router interfaces.
Improvements in performance for Discovery Server and detection of device components.
Corrected issues with invalid or duplicate device names appearing after rediscovery.
Updated memory and disk requirements, software requirements, and supported platforms.
Unsupported metrics no longer appear for device components. Previously, unsupported metrics would appear as
configurable but never collect data.
1.33
What's new:
Updated for use with SnapCA Unified Infrastructure Management 7.5.
Fixed an issue with QOS_pctDiscardsOut not appearing in USM.
Fixed an issue where SNMP V3 devices with AES encryption would appear in USM without default monitors.
1.32
What's new:
Minor bug fixes and performance enhancements.
Name changes for System Management Info-Router\Director and Anti-Virus Info metric families.
1.3
What's new:
Support for SNMP V3 3-DES, and AES-128 privacy protocols.
Support for CPU and physical memory metric families on Juniper devices.
Added the NMS RULE AdminStatus Down rule to filter interfaces that are administratively down.
Updated memory and disk requirements, software requirements, and supported platforms.
1.2
What's new:
GA
December
2013
GA
September
2013
Support for more metric families.

Support for F5, Juniper devices, and system agents (Host Resources and CA Systems Performance for
Infrastructure Managers)
1.1
What's new:
Improvements in performance, especially discovery. Usability improvements to UI.
Added the ability to monitor Cisco devices, similar to the functionality of the cisco_monitor probe.
Added the ability to set rules for monitoring configurations. These rules allow you to set different thresholds that are
based on nonpolled configuration information (for example, based on ifType).
1.01
Improvements to memory management and discovery performance.
Controlled July 2013

Release
1.0
Initial version of the SNMP Data Monitoring probe

Release
More information:
Install snmpcollector
snmpcollector Known Issues and Workarounds
snmpcollector (SNMP Data Monitoring)
snmpcollector Hardware Requirements

This article contains the specific hardware requirements for various versions of the snmpcollector probe.
Contents
Version 2.x Hardware


Install snmpcollector on systems with the following minimum resources:
Memory: 8 GB (minimum) of RAM. This probes out of the box configuration requires 2.5 GB of RAM.
CPU: 4 3-GHz processors, 64-bit.

Install snmpcollector on systems with the following minimum resources:
Memory: 4 GB (minimum) of RAM. This probes out of the box configuration requires 2.5 GB of RAM.
CPU: 3-GHz dual-core processors, 64-bit.
snmpcollector Software Requirements

This article contains the specific software requirements required to enable all of the features in a version of the snmpcollector probe. For
information about installation options, see Install snmpcollector.
Contents
Version 2.26 Software


On the primary hub CA Unified Infrastructure Management server 8.2 or later
ci_defn_pack 1.1.5 or later (where nis_server is running)
mps_language_pack-8.3.6 or later (where service_host is running)
wasp_language_pack 8.3.6 or later on the UMP server where wasp is running
The following minimum probe packages in the local archive on a hub:
snmpcollector 2.26
pollagent 2.26
ppm 3.1 (automatically installs the required probes prediction_engine and baseline_engine)
discovery_agent (the same version as CA Unified Infrastructure Management server)
NAS 4.6 to install the alarm_enrichment package

On the primary hub CA Unified Infrastructure Management server 8.2 or later
ci_defn_pack 1.0.6 or later (where nis_server is running)
Mps_language_pack-8.3.0 or later (where service_host is running)
On the UMP server where wasp is running:
wasp_language_pack 8.3.0 or later
snmpcollector 2.23
pollagent 2.23
ppm 3.1 (automatically installs prediction_engine and baseline_engine)

On the primary hub:
ci_defn_pack 1.0.4 (where nis_server is running)
On the UMP server where wasp is running:
wasp_language_pack 8.2.1
snmpcollector 2.11
pollagent 2.11


CA Unified Infrastructure Management server 8.2 or later on the primary hub
snmpcollector 2.1
pollagent 2.1

The snmpcollector probe and the pollagent probe must be on a remote (secondary) hub.
The probe requires the following minimum software versions:
On the primary hub:
CA Unified Infrastructure Management server version 8.1
monitoring_services 2.02
On each hub with the snmpcollector probe:
ppm 3.0
pollagent 2.0
(optional) baseline_engine 2.4
(optional) alarm_enrichment 4.6
(optional) NAS 4.6
(optional) prediction_engine 1.1

CA Unified Infrastructure Management server version 7.6 or later with:
CA Unified Infrastructure Management discovery_server probe on the primary hub
CA Unified Infrastructure Management ppm probe on each hub with a robot running the snmpcollector probe
CA Unified Management Portal (UMP)
snmpcollector Memory and Disk Requirements

This article provides the memory and disk requirements for specific releases of the snmpcollector and pollagent probes. For instructions on how to
adjust the probe memory settings, see Install snmpcollector.
Note: The provided values are based on the probe collecting 400 metrics per device. If you collect using more devices for this number
of metrics, you need to allocate additional memory.
Contents
Versions 2.1 and 2.2 Memory and Disk

Version 2.0 Memory and Disk
Versions 1.3 and Earlier Memory and Disk

The following table shows the memory and disk requirements for the snmpcollector and pollagent probes.
Number of Metrics
Value
snmpcollector
pollagent
10,000
Xmx Memory
1.5 GB
1 GB
Disk
4 GB
6 GB
Xmx Memory
4 GB
3 GB
Disk
8 GB
12 GB
Xmx Memory
6 GB
4 GB
Disk
12 GB
24 GB
Xmx Memory
18 GB
16 GB
Disk
28 GB
40 GB
Xmx Memory
28 GB
24 GB
Disk
36 GB
56 GB
50,000
100,000
500,000
1,100,000
Version 2.0 Memory and Disk

Number of Components
Value
snmpcollector
pollagent
1000
Xmx Memory
2 GB
4 GB
Disk
4 GB
6 GB
Xmx Memory
4 GB
8 GB
Disk
8 GB
12 GB
Xmx Memory
6 GB
12 GB
Disk
12 GB
24 GB
Xmx Memory
8 GB
16 GB
Disk
18 GB
40 GB
Xmx Memory
20 GB
16 GB
Disk
26 GB
56 GB
5000
10,000
20,000
50,000

Value
snmpcollector
pollagent
1000
Xmx Memory
1 GB
2 GB
5,000
10,000
20,000
50,000
Disk
2 GB
3 GB
Xmx Memory
2 GB
4 GB
Disk
4 GB
6 GB
Xmx Memory
3 GB
6 GB
Disk
6 GB
12 GB
Xmx Memory
4 GB
8 GB
Disk
9 GB
20 GB
Xmx Memory
6 GB
13 GB
Disk
13 GB
28 GB
Versions 1.3 and Earlier Memory and Disk

Value
snmpcollector
pollagent
1000
Xmx Memory
1 GB
2 GB
Disk
2 GB
3 GB
Xmx Memory
2 GB
4 GB
Disk
8 GB
12 GB
Xmx Memory
3 GB
6 GB
Disk
12 GB
24 GB
Xmx Memory
4 GB
8 GB
Disk
20 GB
40 GB
5,000
10,000
20,000
snmpcollector General Considerations

This article contains general considerations for the probe.
Contents
Version 2.0 Localization

Versions 1.6 and Earlier Do Not Duplicate Priority for Rules
Version 1.2 Limitations for Juniper Devices
Data Storage
Some Metrics May Not Be Reported on Some Devices
Version 2.0 Localization

Many strings are not localized for non English locales in the probe GUI.
Versions 1.6 and Earlier Do Not Duplicate Priority for Rules
Do not assign the same priority to more than one rule. If you do so, the existing rule with that priority is overwritten (deleted).
Version 1.2 Limitations for Juniper Devices

Metrics for memory and CPU are not supported for Juniper devices.
Data Storage
Depending on your configuration, the snmpcollector probe can generate a large amount of data. For example, just one probe collecting 500,000
metrics every 5 minutes for a week can fill a hundred gigabytes of database space. Allocate and maintain a sufficient amount of memory in your
database.
Some Metrics May Not Be Reported on Some Devices

Not all metrics that are defined in a metric family are delivered for all devices. Some devices do not support some OID metrics. For example,
PctDiscards of packets on a virtual router might not be calculated if certain OID data is not available from the router.
To determine whether metrics are not being reported, view the pollagent log file. When the pollagent is given a new set of metrics to poll, it
attempts to collect all OID data. Any OIDs not supported by a device are logged when the metric is first added, and when it is re-added through a
probe restart.
In the following pollagent log message examples, you see the device IPaddress, the metric family name, and the OID name and value that is not
supported.
Dec 20 10:41:42 DASCH03-780.ca.com AGM: [Info.] (Tests:SnmpGetExpressio

n:p_172.19.255.12|NormalizedPortInfo|s86) [SnmpGetExpressionTest: 172.1
9.255.12_V2] - UNSUPPORTED_OID=1.3.6.1.2.1.31.1.1.1.6.86 ifHCInOctets
9.255.12_V2] - UNSUPPORTED_OID=1.3.6.1.2.1.31.1.1.1.8.86 ifHCInMulticas
tPkts
9.255.12_V2] - UNSUPPORTED_OID=1.3.6.1.2.1.31.1.1.1.10.18 ifHCOutOctets
9.255.12_V2] - UNSUPPORTED_OID=1.3.6.1.2.1.31.1.1.1.12.18 ifHCOutMultic
astPkts
9.255.12_V2] - UNSUPPORTED_OID=1.3.6.1.2.1.31.1.1.1.6.18 ifHCInOctets
9.255.12_V2] - UNSUPPORTED_OID=1.3.6.1.2.1.31.1.1.1.8.18 ifHCInMulticas
tPkts
This article contains recommendations and considerations for installing the snmpcollector probe software.
Contents
Performance and Scalability Considerations
Adjust Probe Memory Settings
pollagent Memory
snmpcollector Memory
Hub Configuration
Consider the following information before you install the probe:
The recommended way to install the snmpcollector probe for a production environment is with the meta-package. The meta-package
installs the snmpcollector probe with all software packages that are required to enable all the snmpcollector probe features.
Note: If required by your organization, you can still install each of the probe required software software components
individually. Download the probes from the internet archive into your local archive and then install the packages on the
appropriate hub. For more information about required software components, see snmpcollector Software Requirements.
The minimum software packages that are required to run snmpcollector to generate only QoS data are:
On the primary hub CA Unified Infrastructure Management server
You might require updates to ci_defn_pack, mps_language_pack and wasp_language_pack
snmpcollector
pollagent
ppm (automatically installs the required probes prediction_engine and baseline_engine)
If you want to enable alarms, install on a remote (not primary) hub:
prediction_engine
baseline_engine
NAS to install the alarm_enrichment package
Warning! These packages are required to enable alarm functionality in the snmpcollector probe. Do not uninstall
prediction_engine and baseline_engine once installation is complete.
The threshold alarm options only appear in the probe configuration GUI if you install these probes. We recommend that you do
install these probes. These probes provide useful features such as Time to Threshold and Time Over Threshold alarms.
On Linux/Unix systems, the /etc/hosts file should contain an entry with the FQDN for the installation system.
Performance and Scalability Considerations

The snmpcollector probe uses a large amount of memory and disk resources. For the best performance and scalability:
Install the snmpcollector probe on a remote (not primary) hub. The hub that you use for SNMP data monitoring can have a significant
impact on the performance and scalability of the probe.
Allocate sufficient memory and disk space to support your data collection requirements. The monitoring capabilities of the snmpcollector
probe are limited if you install the probe on a small scale system with a limited amount of resources. For more information about the mini
mum hardware requirements, see snmpcollector Hardware Requirements.
Only install snmpcollector with other monitoring probes if the other probes do not consume a large amount of system resources.
For example, you can install the cdm and ntservices probes if the hub has sufficient resources. We do not recommend installing
snmpcollector on a hub with other probes that can also consume a large amount of system resources. Some examples of these probes
are vmware, icmp, and ibmvm.
Use filters as much as possible rather than creating multiple templates. Filters let you control how the probe applies monitors based on
attributes of the target device. Every template that you create is read separately by the probe. The probe uses a large amount of system
resources to read each template.
Follow these steps:
1. Review the installation considerations and performance and scalability considerations. These sections contain important information
about where and how to deploy the snmpcollector probe and information about alternative installation options.
2. Verify that the local archive has the packages for all the minimum probe versions. For specific information about your snmpcollector
version, see snmpcollector Software Requirements.
3. Verify that you installed any required mps_language_packs, ci_defn_packs, or wasp_language packs.
4. Restart nis_server and wasp.
5. (Optional) Import the probe meta-package (snmpcollector_hub_metapackage.zip) into the local archive.
6. Choose one of the following options:
(Versions 2.1 and later) Deploy the probe meta-package on the appropriate hub. Use the meta-package to install the current version
for snmpcollector probe packages that exist in the local archive. The meta-package installs the snmpcollector probe with all the
software packages required to enable all the snmpcollector probe features. Do not use the meta-package to install individual software
components. The meta-package installation fails if all the packages are not present in the local archive.
Warning! We recommend that you use a remote (not primary) hub.
Install install the packages individually on the appropriate hub.

7. Configure the queues on any remote hubs to post data to the primary hub. The remote hub requires a queue for QOS_MESSAGE,
QOS_DEFINITION, QOS_BASELINE, and a queue for probe_discovery to export messages.
8. Configure the hub name service on the primary hub for any remote (not primary) hubs.
9. On a remote hub with snmpcollector and NAS, set NAS forwarding as "All alarm events in both directions". The destination is the primary
hub.
10. Verify that NAS and alarm_enrichment are running on the hub. If necessary, start NAS and alarm_enrichment.
Adjust Probe Memory Settings

The memory and disk requirements for the snmpcollector and pollagent probes can vary. The number of processors, devices, device
components, and metrics can affect your requirements. You might need to adjust the Xmx memory to improve performance. For more information,
see snmpcollector Memory and Disk Requirements.
pollagent Memory
Follow these steps:
1. In Infrastructure Manager, select and right-click on pollagent.
2. Select Edit from the menu.
3. In the Arguments box, change the number in -Xmx1536m. The number following Xmx is the maximum amount of memory in megabytes
consumed by the probe.
4. Click OK.
snmpcollector Memory
Follow these steps:
1. Enter the Raw Configure menu for the snmpcollector probe.
2. Select the startup node.
3.
3. Select options.
4. Change the number in -Xmx1024m. The number following Xmx is the maximum amount of memory in megabytes consumed by the
probe.
5. Click Apply.
Hub Configuration
You set up queues on the hub to transfer snmpcollector data as part of the CA Unified Infrastructure Management configuration process. The
snmpcollector probe can send a large amount of data through these queues.
If the size of a get or post queue never shrinks to zero or if it always has many messages, increase the Bulk Size on the queue. The bulk size
setting allows the hub to transfer multiple messages in one packet. For more information about hub configuration, see the appropriate guide for
your hub version.
(snmpcollector v2.x and later) If NAS is installed on a remote (not primary) hub:
Set up queues on the remote hub to post data to the primary hub. The remote hub requires a queue for QOS_MESSAGE,
QOS_DEFINITION, QOS_BASELINE, and a queue for probe_discovery to export messages.
Configure NAS forwarding as "All alarm events in both directions" on the remote hub. The destination is the primary hub.
Upgrade snmpcollector
This article provides information about upgrading snmpcollector.
Contents
Upgrades with Templates
Memory and Disk Settings
Performance Reports Designer Data
Migration from 1.x to 2.x
Version 2.x Migrating Deprecated Metric Family Configuration
Upgrade Environment
Upgrade the Probe
Review the following considerations before you upgrade the snmpcollector probe or pollagent.
Upgrades with Templates

The snmpcollector probe can take some additional time to activate after performing an upgrade with active templates.
Memory and Disk Settings

Upgrading or reinstalling pollagent can reset the memory settings in the fh.conf file. If you have modified your memory settings, verify that your
probe specific memory settings are correct. Reapply your probe specific memory settings if necessary. For more information, see snmpcollector
Memory and Disk Requirements.
Performance Reports Designer Data

Before version 2.11, data was published in USM by IP address. After an upgrade, Performance Reports Designer can show data for an IP
address and a host name. Data collection ends for the device IP address and continues under the device host name.
Note: You can disable the publishing of data by host name in the probe Raw Configure setup options.
Migration from 1.x to 2.x
There is no migration path built into v2.0. To upgrade from version of 1.x snmpcollector to version 2.x or later requires a reinstallation of the probe.
Existing data is lost during this process. Before you install v2.x, remove the current 1.x version and existing configuration.
Uninstall the current version of snmpcollector and pollagent.
Clear the associated probe directories:
<Nimsoft>/probes/network/snmpcollector
<Nimsoft>/probes/network/pollagent
Use Infrastructure Manager to upgrade the probe on the remote hub.
Version 2.x Migrating Deprecated Metric Family Configuration

The Alternate Interface, Cisco UCS Switch Fan, Cisco UCS Switch Power Supply, and Environmental Sensor Temperature Status metric
families in v2.0 were deprecated in v2.1. If you have monitors configured in the deprecated metric families, you must manually reapply your
configuration. The monitors can be configured through either the probe configuration GUI or templates.
The following table shows the new location of monitors in the metric families.
Deprecated Metric Families
Metric Family to Use
Alternate Interface
Interface
Cisco UCS Switch Fan
Fan
Cisco UCS Switch Power Supply
Power Supply
Environmental Sensor Temperature Status
Temperature
Use the following steps to view your previous configuration settings:

To view your GUI configuration files, go to <Nimsoft>\probes\network\snmpcollector\templates.
To view your backup template files (.bak), go to <Nimsoft>\probes\network\snmpcollector\bulk_config\templates.
Upgrade Environment
Deactivate snmpcollector and pollagent when you upgrade the probes. This will minimize possible issues related to the corruption of the probe
configuration.
Upgrade the Probe

Follow these steps:
1. Download the new version of the probe package to your archive
2. Drag and drop the probe package from the archive to the system you want to upgrade.
snmpcollector Known Issues and Workarounds

This article describes the known issues found in a particular release of snmpcollector.
Contents
Version 2.2x Issues

Version 2.1x Issues
Version 2.0x Issues
Version 1.6x Issues
Version 1.4x and Earlier Issues
General Probe Issues
Version 2.2x Issues

Issue:
Data might be lost in some instances where the password save feature included in most browsers automatically overwrites any passwords
added to a device profile. The remaining profile information is deleted. Profiles that have been impacted no longer display data when you
select the first profile node.
Workaround:
Do not use the password save feature included in most browsers to save the admin console password.
Version 2.1x Issues

Issue:
In version 2.11, the probe configuration GUI and templates show some metrics as numbers. The metric types for the CacheHitRatio,
SessionRate1Min, TotalLicenses, and UsedLicenses metrics as numbers.
Workaround:
11.157:5 = DNS.CacheHitRatio
11.55.27 = System Session Information.SessionRate1Min
11.396:1 = License Management.TotalLicenses
11.396:2 = License Management.UsedLicenses
Issue:
In version 2.1, the Availability metric value is either 100 or No Value (null).
Workaround:
Use the Reachability metric to provide an idea about whether a system is reachable or not. The Reachability metric always provides a value
of 100 when the device is reachable and No Value otherwise.
Issue:
In version 2.1, the Run Vendor Certification Test does not work correctly for the Availability metric. The Availability metric is a calculated
value for monitoring device up-time. The test returns "null" for v2.0 and "NA" for v2.1.
Workaround:
Use the Reachability metric instead of the Availability metric. The Reachability metric gives accurate information for monitoring connectivity
to monitored devices.
Issue:
In version 2.1, the speed for high speed interfaces (> 4 Gbits/sec) that appears on the interfaces tab in USM is incorrect.
Workaround:
Do not use the value for interface speed. This number is an approximate static maximum value.
Version 2.0x Issues

Issue:
The Run Vendor Certification Test does not work correctly for the Availability metric. The Availability metric is a calculated value for
monitoring device up-time. The test returns "null" for v2.0 and "NA" for v2.1.
Workaround:
Use the Reachability metric instead of the Availability metric. The Reachability metric gives accurate information for monitoring connectivity
to monitored devices.
Issue:
The speed for high speed interfaces (> 4 Gbits/sec) that appears on the interfaces tab in USM is incorrect.
Workaround:
Do not use the value for interface speed. This number is an approximate static maximum value.
Issue:
The various threshold settings for a metric are used to generate baseline data in USM. The scale of the monitoring environment has a
direct impact on the calculation of baseline data. In larger scale environments, it could take significantly longer for the data to appear in
USM.
Workaround:
Only enable the threshold settings that are necessary. No workaround exists at this time.
Issue:
The discovery query can take a long time to complete if there is a discovery filter with a subnet mask.
Workaround:
It can take some time for the devices to load if the discovery scope is for a large number of devices. Entering range scopes larger than
65,536 addresses (subnets greater than /16) impacts discovery performance. Wait for the discovery process to complete.
To verify the status of the device import, select the snmpcollector node, and view the Profile Import Status field.
To verify the status of subcomponent discovery, select snmpcollector > Profiles > profile name >device name, and view the Component
Discovery field.
Version 1.6x Issues

Issue:
Starting with version 1.61, counts have significantly dropped for metrics that measured network packets (bits, frames, octets).
Workaround:
The drop in counts is expected after an upgrade to version 1.61 or later. Pollagent now calculates metrics with a RollupStrategy of sum as a
rate over time in seconds since the last polling cycle.
Look in the appropriate metric family file in <install_path>\Nimsoft\probes\network\snmpcollector\MetricFamily to view the RollupStrategy for
a particular metric.
Issue:
The SNMP Data Monitoring probe shows fewer metrics after an upgrade to v1.6.
Workaround:
This behavior is not an issue. The metrics for SNMP response time and availability previously existed within each metric family. With v1.6,
these metrics were consolidated into their own metric families that are named Reachability and Availability.
Version 1.4x and Earlier Issues

Issue:
In versions earlier than1.2, all devices might not receive the updated thresholds when thresholds are changed in a monitoring template.
Workaround:
Avoid changing an existing monitoring template. Create a new template (uses the values in the default) and apply the new template to the
devices.
Issue:
In version 1.0, discovery can take longer than expected. The snmpcollector version 1.1 probe greatly improves performance of discovery.
Workaround:
To verify discovery progress:
Version 1.0
In the probe GUI, click the SNMP Collector Probe node in the tree and view the Discovery Status field.
Version 1.1 and later
In the probe GUI, click a device name in the tree and view the Component Discovery field.
General Probe Issues

Issue:
Changes to profile credentials are not saved if you add a profile and then edit an authentication credential.
Workaround:
Delete the profile and add it with the correct credentials.
Issue:
The configuration file can become corrupted if the probe is disconnected from the controller while executing a discovery or configuration
operation.
Workaround:
The snmpcollector probe creates a configuration backup file every time the probe starts successfully. You can use the
snmpcollector.cfg.BAK file that is located in Nimsoft/probes/networking/snmpcollector/ to assist with the recovery process. Make frequent
backups while making configuration changes.
Issue:
The interface speed for some virtual interfaces is not reported correctly. The device is not able to detect the true speed of connection for the
virtual interface. This issue is seen with WAN-related interfaces.
Workaround:
To calculate utilization on these interfaces, contact your system administrator to determine the maximum speed of the interface. Then set
the interface speed in the probe.
The interface speed settings are available with probe v1.42 or later. Set an override value in the Speed out Override and Speed in Override
fields in bits per second.
For example, to set an interface to a speed of 100 GB you would enter 100000000000.
Issue:
Where are the probe log files?
Workaround:
For Admin Console users: Click the triangle next to the probe name in the Admin Console and click View Log in the drop-down list.
Issue:
Some polled metric values larger than 8 million might be rounded. This behavior limits the precision available in polled metrics.
Workaround:
No workaround exists at this time.
Issue:
I see an I/O communication error in the snmpcollector.log file with the following message:
Exception in ThreadClient: (2) communication error, I/O error on nim session

(S)
com.nimsoft.nimbus.NimServerSession(/123.45.678.191:54827-/123.45.6.7:59412):
End of stream while trying to read header.
This message only appears when loglevel is 1 or greater when loading or reloading the configuration page.
Workaround:
No action is required. You can ignore this alarm.
Issue:
SNMP devices with nonstandard port numbers are not detected. The standard port number for an SNMP device is 161.
Workaround:
View the device in NMS and verify that a nonstandard device port is in use.
For v1.61 and earlier, reconfigure the device to use port 161.
For v2.0 and later, go to the probe configuration GUI and locate the device profile (snmpcollector > Profiles > profile name). Enter the
correct SNMP port for the device.
Issue:
I see an alarm with the following message:
An attach queue for the subject probe_discovery on the hub

/SNMPdom/SNMPhub/SNMProbot/hub has been successfully detected. Though not
determined here, either a get or post queue may also be needed to forward
discovery results if this is not the primary hub.
Workaround:
No action is required. You can ignore this alarm.
Issue:
Initial discovery of device subcomponents can take 30 minutes or more to complete the first time you query the discovery server. Screen
(GUI) timeouts might occur during this period.
Workaround:
Wait for subcomponent discovery to complete.
Issue:
Admin Console based Restart command does not work for snmpcollector or pollagent.
Workaround:
First Deactivate the probe and then Activate it.
Issue:
The SNMP Data Monitoring probe might be unresponsive under heavy load, during scheduled rediscovery, or immediately after applying a
monitoring template to multiple large devices.
Workaround:
If the probe is unresponsive, wait several minutes and try again.

Issue:
Your SNMP Data Monitoring probe does not start. If the process died or was killed while saving discovery or configuration changes, the
configuration file might be corrupt.
Workaround:
Use the most recent snmpcollector.cfg.BAK file to recover the probe configuration. The SNMP Data Monitoring probe creates a
configuration backup file every time the probe starts successfully.
Locate the snmpcollector.cfg and snmpcollector.cfg.BAK files in Nimsoft/probes/networking/snmpcollector/.
Copy and rename the current snmpcollector.cfg file. You can use this file for later analysis.
Copy and overwrite the snmpcollector.cfg file with the snmpcollector.cfg.BAK file.
Restart the probe.
The probe starts with the last successful configuration. Any configuration changes made since the last successful startup are lost.
Issue:
No QoS data is available.
Workaround:
Subcomponent discovery might not be completed. To verify discovery progress:
Version 1.0
In the probe GUI, click the snmpcollector node in the tree and view the Discovery Status field.
Versions 1.1 and later
In the probe GUI, click a device name in the tree and view the Component Discovery field. The device might not have a
monitoring configuration.
If no subcomponents are listed for the device, try the following actions:
Validate that the MIB is returning valid data for the SNMP MIB table of interest using a tool such as the snmpget probe.
Verify that the subcomponents are administratively up.
Validate the SNMP credentials for the device. If the credentials are not valid, you cannot expand the nodes to see the
components.
Subcomponents might be disabled on the device.
If they are disabled, follow the manufacturer's instructions to enable the subcomponents.
snmpget (SNMP Get) Release Notes

The SNMP Get (snmpget) probe sends SNMP GET queries to SNMP devices. The probe then changes the query result into configured alarm and
Quality of Service messages for Service Level Agreement (SLA). You can also browse remote SNMP agents for required monitoring information.
The probe supports SNMPv1, SNMPv2c, and SNMPv3.
Note: SNMPv3 requires that your network community strings are at least eight characters long.
Contents
Revision History
Compatibility
Revision History
Version
Description
State
Date
1.90
Fixed Defects:
GA
October
2015
GA
May 2015
For new hosts, the probe applied the last used timeout value instead of the default timeout value. Salesforce case
00164867
The probe sent alarms for individual samples even before the required number of samples were collected. Salesforce
case 00168336
Note: The samples are collected when a profile calculates the average value of the monitored metric.
The probe configuration interface displayed incorrect values when a numeric value was extracted from a string value. S
1.89
What's New:
Added feature to modify the host not found error message and the host found clear message from the Setup window.
1.88
Fixed Defects:
April 2015
The probe did not display metrics for some OIDs until all the MIB files were deleted from the MIBS directory. Salesforce
case 00142442
Device Id was not displayed for the Agent Not Responding alarm due to which Maintenance mode was unable to stop
SNMP failure. Salesforce case 00142524
1.87
Fixed Defects:
October
2014
Fixed a defect where the user was not able to specify any limit for log file size. Salesforce case 00144902
1.86
Fixed Defects:
July 2014
Implemented the regex support for comparing string values on IM probe GUI and displaying appropriate color of the
counter. This option works only with = and != operators. Salesforce case 00122120
1.85
Fixed Defects:
April 2014
When the Threshold was set as , the expected result for operator != must be . The probe was issuing alarm [ even
with the expected result.
While OID configuration for timetick, runtime error was being thrown if the Enable Monitoring check box was
unchecked after entering an invalid threshold value.
1.84
Fixed the issue of SNMP V3 authentication where you must restart the probe for applying the SNMP V3 authentication
credentials. Now, the updated SNMP V3 credentials take effect without restarting the probe.
January
2014
Fixed the issue of probe GUI where the probe was showing the duplicate OID. The probe was not able to validate a
static OID is already configured in the profile and same OID is configured again through a template. Now, the probe
shows an error message of duplicate OID.
1.83
Fixed issue related to incorrect value calculated from Octet Strings.
June 2013
Fixed a defect where value was wrong on GUI (value was always "0").
1.82
February
2013
1.81
Fixed issue of "Enable Monitor" for all OID Types.
June 2012
Fixed issue of appending "?" for wrong OIDs. Fixed Runtime error "424".
Fixed: Value for "regex to numeric value" enabled templates is coming 0.
Fixed incorrect timeticks value in QoS.
1.80
Added new callback to return all active profiles and their active children.
June 2012
Fixed the handling of non-numeric timeticks.

Added support to consider elapsed time in value calculation of counter types.
Added support to fetch numeric value from strings using regular expressions.
Added fix to display sampled value in alarm message.
Added fix to support hostname in case of IPv6.
Added support to set custom suppression key in profiles.
Added support to use regex in threshold for string OIDs.
Added description in profile setting.
Added support for minimum 8 characters password for SNMPv3.
Fixed: It allows user to enter 260 characters for host name but all the functionality is performed on first 259 characters. It
discards 260th character. Fixed Soc defects.
1.67
Revert back to Robot address as default qos source (as used pre-1.66).
September
2011
1.66
Provided option for selecting different QoS Source and Alarm Source.
August
2011
1.65
Rebuilt with latest versions of snmp libraries. (v1.63/v1.64 had problems with SNMPv3 (authNoPriv, authPriv) on 32 bit
Linux systems).
May 2011
1.64
Added Solaris Intel platforms.
March
2011
1.63
Fixed GUI load time.
February
2011
1.62
January
2011
Increased internal limit of OIDs per profile to 299 (from 199).

1.60

January
2011
Added support for web-based Service Oriented Configuration.

Fixed the GUI to read all Templates when language setting is set to German.
Fixed the Monitor Graph to prevent GUI crash on invalid values.
1.52
June 2010
1.51
Added support for dynamic index tracking.
May 2010
1.50
Added NIS (TNT2) support.
April 2010
1.41
Fixed "Variable has bad type" value displayed in GUI (and fetched by probe) when OID is actually missing.
January
2010
Fixed severity of missing OID alarm (when using default message).

Replaced GUI "Splitter" component (display "arrow" icon when mouse is over the separator between the left and right
window panes).
1.40
Added fix to copy all OID parameters while dragging from template to profiles.
October
2009
1.39
Fixed error while reading new QoS definition which contains has_max value.
September
2009
1.38
Fixed the crash in QoS loading in case of empty group key.
August
2009
Note: Previously the group was hardcoded to use QOS_SNMP_VARIABLE even if the group value was specified by user.
Now the group would use the group value specified by user in the GUI.
1.37
Fixed the default down alarm text in case of hardcoded alarm.

Fixed the crash in the $thr and $oid variables' expansion when the device is not responding.
Fixed the device not responding message.
July 2009
1.36
The OID available alarm clear is sent only when OID missing alarm is previously raised.
July 2009
Note: Upgrade from version 1.33, 1.34 and 1.35 to 1.36 will change the QoS target from "profile.oid" to "profile.oid name" OR
"oid" to "oid name".
1.35
Added fix to save encrypted community string if 'Encrypt community string' option is selected.
June 2009
1.34
Bug fixes in libraries.
June 2009
1.33
Implemented native support for sparc-64/Windows64/Linux64 bit platform.
June 2009
Added SNMP v3 support.

Official support for windows 2008.
Implemented average over x values graph.
Added support for $variable.
Profile settings will now override template settings applied to profile.
Changed the Qos target from OID.name to OID.
Removed the support for (Solaris 2.5, 2.6 and 7).
Some minor UI defects fixed.
1.23
Fixed QoS definition issue.
October
2007
1.22
August
2007
Fixed bulk-configurator (keep group setting).

Fixed QoS Group settings.
Fixed rounding issues when using ratio.
Fixed decimal separator issues in GUI.
Added "bulk-configurator".
Added "Display timeticks as numeric datatype" (Note: this is a general probe setting).
Added QoS Group to the "Add New QoS definition" dialogue.
Added "agentgroup" and "oidgroup" as $ variables in alarm messages.
Added "SNMP Retries" setting.
Added "Stop" button to the MIB Browser.
Added limited support for the IPAddress datatype (compare as strings).
Fixed problems regarding empty strings.
Fixed problems regarding send of duplicate QoS NULL values.
GUI will no longer allow QoS name longer than 255 characters. (QoS Group limited to 64 characters).
Better handling of delta-computations (when counters wrap).
Fixed erroneous GUI symbols when using "extended rule".
Fixes UNIX-problem with "between" operand when monitoring OID's.
1.14
Added support for timeout and delay in SNMP queries.

Fixed issues relating to buffer overflow leading to a crash situation during startup/restart.
1.12
Fixed issues regarding Run-time errors.

Disabled possibility to edit QoS definitions after they are created.
February
2007
December
2006
Fixed issue regarding "large" Counter32 values not being sent correctly to QoS db.
1.10
Fixed issue regarding dashboards (and Probe Utility) not working correctly when communicating with probe.
March
2006
1.09
Added possibility for changing of SNMP Port number.
December
2005
Added possibility to set a user defined message string when a CLEAR message is sent.
Added between and not between threshold operators.
Fixed issue related to incorrect status of device without oids.
Added possibility for changing of Subsystem ID.
Fixed issue related to QoS not being sent.
Fixed various UI.
1.07
Fixed issue with many concurrently executing profiles and source name-resolution.
November
2005
Fixed issue with OID template override. Fixed various minor UI problems.
Added variable monitor to UI to ease configuration and device troubleshooting.

The snmpget probe must be installed on systems with the following minimum resources:
CPU: 3-GHz dual-core processor (32-bit or 64-bit)

The snmpget probe requires the following software environment:
Compatibility
Probes that support SNMP on Linux (interface_traffic, snmptd, and snmpget) use an SNMP library. This library can cause newer Linux systems to
issue the following message in the Linux console log:
Process SNMPget is using obsolete setsockopt SO_BSDCOMPAT
The SNMP library supports older versions of glibc which require the SO_BSDCOMPAT flag for sockets to work correctly. The network section of
the glibc library sends this message. The message shows that an unsupported flag is being sent to the setsockopt function. The library ignores
the SO_BSDCOMPAT flag, so you can also ignore it.
snmpgtw (Simple Network Management Protocol Gateway) Release Notes

The Simple Network Management Protocol Gateway (snmpgtw) probe converts CA UIM Infrastructure alarms to SNMP-TRAP messages. The
messages are read by SNMP-based event managers such as HP OpenView, CA Unicenter TNG, and BMC CommandPost.
Most SNMP-based event managers can define filters based on the incoming object identifier (OID) and the trap information. The probe can map
the various severity levels to enterprise-specific trap types. This makes it possible to define a number of trap definitions on the event manager
side to recognize the various severity levels.
Revision History
Version
Description
State
Date
1.34
What's New:
GA
September
2015
1.33
What's New:
GA
April 2015
GA
February 2015
Support for pure IPv6.

Default profile for CA Spectrum.
1.32
Fixed Defects:
Fixed the issue of trailing .0 at the end of the Variable Binds in SNMP Traps generated by the probe. Salesforce case
00151851
1.31
Fixed Defects:
June 2014
Fixed a defect where the log file size is not user-configurable. Salesforce case 131654
1.30
Added Metric Id as a trap variable in the Setup tab.
May 2014
1.22
Fixed the issue showing incorrect source detail while receiving trap in third party Trap Receiver.
August 2012
1.21
Fixed a defect in reading user tags (if present) from the udata section of alarm messages.
December
2010
1.20
Upgraded the probe to use latest version of nimsnmp library

Added native support for Windows 64-bit and Linux 32-bit and 64-bit environments
September
2010
Added support for configuring snmp port for individual profile.

Prohibited use of whitespace in GUI configurator.
1.12
1.11
Fixed the issue of nas IP being sent as alarm source in case of repost messages.
Fixed the issue of probe not sending traps on clear severity alarms.
Fixed the issue of probe not working for post_message.
1.07
Initial release.
May 2010
December
2009
April 2005

The snmpgtw probe requires the following software environment:
Known Issues
The snmpgtw version 1.11 and later supports sending traps with trap_type 0. Hence, all the pre-configured profiles with traps mapped to
'0' start sending traps with trap_type 0. If traps with trap_type 0 are not required, modify the configured profiles manually. See the respecti
ve configuration article for details.
snmptd (Simple Network Management Protocol Trap Daemon Monitoring) Release Notes
The Simple Network Management Protocol Trap Daemon Monitoring (snmptd) probe enables you to receive SNMP trap messages from other
monitoring tools. Based on these messages, you can generate alarms using the probe.
The probe acts as a gateway from the SNMP environment to CA Unified Infrastructure Management (CA UIM). It also converts SNMP-TRAPs to
CA UIM alarm messages. Network devices, such as routers, switches, and bridges are SNMP driven. The devices report error conditions in the
form of SNMP-TRAP, which are sent to a directed UDP port (Default - 162) in the network. The SNMP-TRAPs can be sent to a management
station such as HP OpenView Network Node Manager. The probe listens to the specified port and converts the incoming traps according to the
defined profiles. The probe monitors the incoming trap messages from other monitoring tools and converts them to CA UIM messages.
Contents
Revision History
Revision History
This section describes the history of the revisions for the snmptd probe.
Version
Description
State
Date
3.18
Fixed Defects:
GA
October
2015
GA
August
2015
GA
May 2015
When creating a profile, the probe did not retrieve the specific trap number for a vmware trap. Salesforce case
70003379
The probe displayed only the default message text in profiles if multiple profiles were created simultaneously. This
situation occurs when the Enhanced MIB Parsing feature is enabled. Salesforce case 00170395
The probe assigned the default severity to new traps when the Enhanced MIB Parsing feature was enabled. Salesforc
e case 00166577
The probe GUI became unresponsive when performing any action such as saving the probe configuration. Salesforce
cases 00162781, 00156506
Updated Known Issues and Workarounds for an issue where active profiles are not displayed in the probe configuration
interface. Salesforce case 00125427
3.17
What's New:
Added ability to add PDU variables from traps to profiles automatically.
For more information, see the General Setup Window section in the v3.1 snmptd IM GUI Reference article.
Fixed Defect:
Multiple trap profiles cannot be created from the same MIB file with different enterprise identifiers. Salesforce cases:
00163170, 00161291, 00161615
For more information, see the Known Issues and Workarounds section.
3.16
What's New:
Added support for pure IPv6.
Fixed Defect:
If the alarm suppression key is too long, the probe restarts every time that a trap is captured. Salesforce case 00153961
3.15
Fixed Defects:
April 2015
Probe was unable to create more than one new profile for CISCO-BGP4 from the MIB Trap Browser. Salesforce case 0
0158238
The IF-MIB:linklUp was displayed under NS-ROOT-MIB in the probe when importing NS-ROOT-MIB.txt from the MIB
Setup Wizard. Salesforce case 00150607
Probe did not display the QoS on number of traps if the probe configuration was saved until a new trap is generated. Sal
Default alarm was not generated if alarm text in PDU is blank. Salesforce cases: 00155958, 00156323
Probe did not start if Enhance MIB Parsing was enabled. Salesforce cases: 00154624, 00156648
The SNMP v2 trap profiles in folders moved to the SNMP v2 Traps Unknown MIB folder if Enhance MIB Parsing was
enabled and probe was restarted. Salesforce case 00157560
3.14
Fixed Defects:
February
2015
sysUpTime and snmpTrapOID were included as numbered variables. Now they are visible as configurable variables for
v2 and v3 traps. Salesforce case 00127360
All the trap profiles with the same name but associated with different MIBs are not displayed. Salesforce case 00133041
MIB Trap Browser does not display modules or traps if Enhance MIB Parsing is selected or deselected in General Setup
and probe is restarted from within the snmptd interface. Salesforce cases: 00141428, 00151195
Alarms for traps have modified and garbled variable values when Remove Double Quotes is selected in General Setup
when deployed on the Community Enterprise Operating System (CentOS). Salesforce cases: 00138829, 00147481
Probe converts only the alphanumeric characters and not all ASCII values. Salesforce cases: 00148310, 00149058,
00149872
3.13
Fixed a defect where new trap profiles were displayed in different groups after saving the probe configuration and
restart. Salesforce case 00138814
October
2014
Fixed a defect where trap variables were displayed in hexadecimal. Salesforce case 00138835
Fixed a defect where probe GUI was not working while adding similar Engine ID with different case due to case
sensitivity. Salesforce case 00141346
3.12
Fixed Defects:
July 2014
Added default varbinds for SNMP V2 profiles, which are created from the MIB trap browser. Salesforce case 00127360
Fixed the issue of incorrect parsing of IP address when saving the IP address in a String type variable. Salesforce case
00130094
Fixed the issue of displaying the IP address of the system instead of hostname of the source. Salesforce case 0011619
7
3.11
Fixed an issue in the SNMP Trap Monitor dialog where alarms from the snmptd probe displayed IP address instead of
hostname for the Hostname field.
April 2014
For SNMP traps, the Rename functionality available on right-clicking of a profile is removed. In case, you must rename
a profile, use the Edit option.
3.10
What's New
January
2014
A customized way to read MIBs that enables auto-populating of the severity and message text for traps of supported
MIBs. By default, this feature is turned-off.
Fixed Defects
Defect fixed related to the import of trap descriptions by implementing the feature.
Defect fixed related to garbled text in alarms by adding the support for that.
3.03
Fixed: Default message scenarios for configured alarms
October
2013
3.02
Fixed: Run Time Error observed in a scenario.
September
2013
Fixed: Community string could not be typed in.

Fixed a defect where varbinds are not expanded properly.
3.01
Added probe defaults for the probe
June 2013
3.00
Added a feature to prepopulate the OIDs to be monitored for unidentified received traps while creating the profile.
May 2013
Added a feature to use the source address or the agent address to associate a trap to a device.
Merged the cim_traps profiles and dom_traps profiles with the snmptd probe.
Added a feature to substitute value codes with predefined value meanings i.e.evaluate the varbinds.
Added a feature to load / compile a trap MIB (and its MIB dependencies). Added the profile that is based on the trap
definition on the MIB.
Added a feature to interpret Compaq Insight Manager so that traps are interpreted correctly.
Added a variable $MIB_DESCR to provide the actual trap description that is defined in the MIB.
2.14
Fixed the SNMPv2/ SNMPv3 TRAP Details.
July 2012
Fixed memory leaks.

Fixed junk character issue that comes on NAS in trap variables.
Fixed an issue where MIBs were not uploading well.
2.11
Rebuilt with latest versions of snmp libraries. (v2.10 had problems with SNMPv3 (authNoPriv, authPriv) on 32-bit Linux
systems).
March
2011
2.00
Added support for the internationalization.
December
2010

Merged the SNMPv2 and V3 sections in GUI and config file. Refer to the "Installation Notes" section in this release note
if upgrading the probe from the 1.9x version.
Changed text 'NimBUS' to 'Nimsoft' in the probe GUI.
1.92
Fixed the crash issue due to variable 0 defined in variable rules of any profile.
Fixed the issue of MIB loading errors in the net-snmp library.
October
2010
Added fix to unlock the config file while unloading the configurator tool.
Added the fix in the PDU variable window to avoid zero in 'variable' field.
Added the fix in the trap details window to display all characters in the variable.
Added code to set a trap name as the profile name while creating a profile.
1.91
Added the missing "Remove double-quotes" functionality for string variables in alarm messages.
October
2010
1.90
Added support for SNMPv3 traps.
October
2010
Added fix to provide the option to remove double-quotes from variable values.
Added fix to support regular expressions in variable rules.
Added fix to send OID information in alarm messages.
Added support to log errors while parsing MIBs.
1.80
Added support for the generic profile (to trap all messages).
June 2010
Added minor fixes in the GUI.

1.71
Fixed MIB Trap Browser issue.
May 2010
1.70
Added NIS (TNT2) changes
May 2010
Fixed the memory leak that is found in version 1.65.

1.66
Fixed the MIB Trap browser issue (specific IDs).
May 2010
Increased the GUI timeout when opening MIB Trap Browser.

1.65
Fixed the suppression key in cases where a custom suppression key is specified and PDU variable matching is
performed with "process all rules" turned off. Probe no longer appends the variable number to the suppkey on a PDU
variable rule match. If "process all rules" is turned on, there is no change (variable number is appended to suppkey on
the match).
May 2010
To revert to pre-v1.65 suppression key behavior when using PDU Variables Rules with the custom suppression key,
create key /setup/pre165suppkeys = 1 using raw configure.
Fixed the suppression key when no variable rules are defined and no custom suppkey is specified. Previously the probe
sent NULL as the suppression key when using the described settings.
1.64
Fixed threshold checking of PDU variables (no translation of enums before processing).
May 2010
1.62
Changed handling of OctetString variables to support various display formats.
December
2009
1.61
Fixed the issues with the trap monitor on win64.

Added MIB Trap Browser for the easy configuration of new traps.
September
2009
Added the translation of PDU variables from integers to enumerated string values in Alarm messages. For example,
DiskStatus is defined in a MIB as 1=ok, 2=failed, 3=other". "Disk Status is 1" is now "Disk Status is ok".
Fixed logical grouping of SNMPv2 traps (groups SNMPv2 traps on the MIB module that defined the trap).
Allowed multiselect of the MIB files when adding MIBs using the MIB Setup Wizard.
Added support for Counter64 in the varbinds.
Fixed various minor issues in the GUI. Fixed $C (community) variable for use in the alarm messages.
1.55
Fixed memory and handle leak. Fixed closing of TCP sockets.

The empty PDU variable list always sends nimbus alarm on a trap match, independent of the 'Send default message on
no match' setting.
March
2009
1.53
Fixed trap source decoding. snmp_pdu transport_data_length changed after update of nimsnmp.
July 2008
1.52
Fixed possible crash situation caused by long traps.
June 2008
1.51
Fixes:
December
2007
The ip mask that is entered for host deny could be interpreted as numeric, caused a crash of configurator.
Fixed the configurator hang for specific traps when creating profile from the trap monitor.
Nimbus SNMP-TRAP only posted if the convert flag is set.
Deletion of the MIB files added.
The Default message always present. Added check box for not sending the default message if no match on pdu variable
rules.
Features added:
In the SNMP monitor, copy to clipboard of selected entries, by Ctrl+C, or from the right-click menu.
Ctrl+A selects all. QoS added.
Source is IP, and target is the trap name or oid and specific trap number if available. (enterprise specific with oid of
enterprise and specific trap type, version 2 with trap object identifier). A QoS is the number of times a specific trap has
been received during the interval. The interval is default 1 minute, and can be set in the general setup.
The snmptd probe listening on multiple ports.
Fixed an error on Linux, causing high cpu usage.
Fixed GUI display error of large values for the "Specific trap number" field in the SNMP Trap Monitor window.
Fixed GUI run-time error when specifying numeric community string.
1.43
Added the possibility to "Process all rules" in the PDU variables section. Added support for 20 PDU variables pr.
trap(previously 10).
Added right-click menu in the PDU variables section which allows the user to move the PDU variables up and down.
Added support for use of variables on the "Message" field in the PDU variable section.
Added support for use of variables in "Source" and "Suppression key" fields.

The snmptd probe must be installed on systems with the following minimum resources:
CPU: 3-GHz dual-core processor (32-bit or 64-bit)

The snmptd probe requires the following software environment:
December
2005
Consider the following point when installing the probe:
Ensure that ports used are free (UDP/162 is the default port). You can issue the netstat -an command to search and confirm the port
status. For example, if the UDP 0.0.0.0:162 port is present, then some other application, such as HP OpenView and Compaq Insight
Manager are using this port.
Consider the following point when upgrading the probe:
Upgrading the probe from version 1.9x to version 2.0x to 3.0x
The probe merges the SNMPv3 and SNMPv2 checkpoints on upgrade. If the checkpoints have same names in the SNMPv2 and
SNMPv3 sections, the SNMPv2 checkpoint configuration takes precedence. As a result, SNMPv2 settings override the SNMPv3 settings.

The snmptd probe has the following known issues:
The probe overwrites a previously created profile for a TRAP from an MIB file. The override occurs when a new profile that is created
from the same MIB file has a different Enterprise ID. The previous trap is displayed as an enterprise in the right pane if you select V1
Traps in the left pane and is non-configurable. The probe continues to generate alarms for thresholds that are already configured in the
profiles.
Profiles created from some MIBs such as TEK-TOOLS-TRAPS may not always appear in the probe configuration GUI even if they are
functional. You must restart the probe and use the Raw Configuration interface to configure these profiles.
The Enhanced MIB Parsing feature is not supported on Solaris 64-bit platforms.
In version 3.18 and later, the probe displays the correct message text in profiles if multiple new profiles are created simultaneously. This
occurs when the Enhanced MIB Parsing feature is enabled. However, existing profiles from earlier versions have to be recreated or
manually updated.
snmptoolkit (SNMP Toolkit) Release Notes

The snmptoolkit probe allows you to monitor SNMPv1, SNMPv2c, and SNMPv3 devices. The probe allows you to create 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 with both static and dynamic OIDs to selected SNMP devices.
The probe also allows the following actions:
The probe transforms the SNMP GET query results into alarms and Quality of Service metrics for performance, availability, and SLA
monitoring.
The probe also includes a DTA configuration file upload/download utility.
The probe checkpoint creation allows you to group checkpoints under a user-defined navigational node.
Example: All checkpoints corresponding to OIDs form the same SNMP table for a device.
You can group collection of nodes to be part of a higher-level node such as the top-level node.
Notes:
The node name must be unique in a given DTA file. Node names cannot repeat in various node branches of a probe
deployment (in a given DTA file), as it results in erroneous checkpoints values.
The checkpoint names under a node must be unique for each node. You can repeat same checkpoint names in different
nodes, such as "Status".
Contents
Revision History

Revision History
Version
Description
State
Date
1.39
Fixed Defects:
GA
October
2015
GA
April 2015
GA
October
2014
The probe was unable to display all the profiles for a group, if the group was renamed. Salesforce case 00167300
Note: See Upgrade Considerations section for more information.
The probe returned OID error if the OID value (string) had double quotes, even after setting the DTA file correctly. Salesf
orce case 00166165
Updated the Known Issues and Workarounds section in the Release Notes to state that the probe displays the same
ambient temperature of all instances with the same name. Salesforce case 00138234
1.38
Fixed Defects:
Fixed a defect in which incorrect status alarms were generated if a period (.) was not placed at the beginning of the OID.
Note: It is recommended to place a period (.) at the beginning of the OID.
Fixed a defect in which QoS returned null values if dynamic variable (X) was placed in the OID. Salesforce case 001520
53
Note: Dynamic Variable is only supported at the end of the OID.
Fixed a defect in which the probe crashed when loading pools data. Salesforce case 00155852
Fixed a defect in which the probe crashed on Windows Server 2008 r2. Salesforce case 00144480
1.37
Fixed Defects:
Fixed a defect in which the probe was restarting in loop when deployed on CentOS 5 and 6. Salesforce case 00127396
Fixed a defect in which the probe was adding multiple duplicate entries on adding new devices for monitoring. Salesforce
case 00120888
1.36
Fixed Defect:
January
2014
The probe was unable to fetch the interfaces (dynamic OIDs) at a port other than the default port (161).
1.32
1.31
The defect snmptoolkit config tools alarm state is incorrect for some types of checkpoints has been fixed.
Added a feature to specify wildcard or regex in profile_name value in callback.
Fixed a defect where probe was adding extraneous carriage returns to the DTA files uploaded by the probe.
January
2013
December
2012
Fixed a defect where host severity was not properly loaded in UI.
1.2
Removed the Custom Monitor section.
June
2012
1.04
December
2011
Prevent the overwrite of dta file on probe upgrade.

Added DTA upload/download utilities.
Added DTA settings utility.
Initial version.
The snmptoolkit probe should be installed on systems with the following minimum resources:

The snmptoolkit probe requires the following environment:
This section lists the upgrade considerations for the snmptoolkit probe.
In the probe version 1.38 and earlier, the probe was unable to display all the profiles for a group, if the group was renamed. When you
upgrade the probe from a previous version to version 1.39, you must delete the profiles (existing in the group that was renamed in the
earlier versions) from the raw configuration section and then create new profiles.

The probe displays the same ambient temperature of all instances with the same name. The displayed temperature is for the first
instance of the name encountered by the probe.
Already set static monitors take precedence over applying auto configuration. Delete the static monitors if you want to apply
auto-configuration to create auto-monitors. You can select delete existing monitors by dragging and dropping a template to the
auto-configuration node.
spooler Release Notes

The spooler is a core component of a CA UIM robot. The spooler relays messages to the hub from the probes that are connected to the robot. Th
e spooler is deployed with the controller and hdb probes during robot installation or update. The spooler version is always in sync with the
controller and
hdb.
See the controller Release Notes for release information about the robot.
Revision History
Version
State
Date
7.80
GA
June 2015
7.70
GA
March 2015
7.63
GA
December 2014
7.62
GA
November 2014
7.60
GA
June 2014
7.05
GA
March 2014
7.10
GA
December 2013
Fixed Defects
If ssl_mode=0 when spooler starts, the SSL server setup should not execute.
In version 7.70, if ssl_mode=0 when the spooler starts, the SSL server setup executes improperly.
In version 7.80, if ssl_mode=0 when the spooler starts, the SSL server setup fails to run. The behavior is consistent with the
behavior of the hub and controller.
sql_response (SQL Server Response Monitoring) Release Notes

The SQL Server Response Monitoring (sql_response) probe uses ADO or ODBC connections to execute SQL queries and monitor SQL server
databases. The probe then evaluates the result of the query (for example, response time, number of returned rows, and returned value) to
generate alarms and QoS.
Contents
Revision History
Known Issues
Revision History
This section describes the history of revisions for this probe.
Version
Description
State
Date
1.65
Fixed a defect where the probe did not accept passwords with semicolon (;) while creating an OLEDB connection. Salesforce
case 00159821
GA
December
2015
1.64
Fixed Defects
GA
January
2015
GA
December
2013
Fixed a defect where the probe did not process any NULL values. Salesforce case 00140172
Fixed a defect where the probe did not clear the alarms when the connection was configured as <server IP>,<port>. Sal
Fixed a defect where the user had to test the connection when editing any profile. Now, a user can now test a query
without testing the connection, after editing a profile. Salesforce case 00134063
1.63
Fixed Defects:
Defect fixed relating to met_id and dev_id of ODBC. The met_id and dev_id did not appear in the case of ODBC, which
was fixed in this defect.
Defect fixed relating to Windows Authentication. The probe did not work when the Windows Authentication check box is
selected, which is fixed in this defect.
1.62
Fixed Defect:
Defect fixed relating to trailing zeros by removing the extra zeros appearing in the alarm threshold.
GA
June 2013
1.60
This is now available in Admin Console GUI.
GA
March
2013
1.61
GA
February
2013
GA
August
2012
1.60
Added a callback function to fetch active profile using wild card or regex expressions in profile_name.
Fixed an issue where "datetime" type variables were not properly displayed in alarm messages.
1.53
Fixed SOC issues.
June 2012
1.52
Fixed SOC issues.
December
2011
1.51
Fixed an issue where row key column value was not getting expanded for alarm suppression key and message variable.
June 2011
TNT2 for custom QoS.

1.50

1.41
Fixed an issue where the probe was considering sql connection timeout as 0 irrespective of setting it to any value in
config file.
December
2010
September
30 2010
Fixed QoS issue where definition are not sent when configured in value section if no data is returned by query.
1.40
Added 64 bit native support.

Added fix for GUI crash.
September
13 2010
Added code to remove whitespace from config sections.

Added support for multiple alarms on single checkpoint.
1.30
Added NIS(TNT2) changes.
June 2010
1.28
Removed validations for the initial catalog field for database connections
December
30, 2009
1.27
Fixed security token leak by closing the security tokens when they are not required.
December
18, 2009
1.26
Changed the GUI to allow specifying the name for the QoS.
Fixed the issue of QoS definition not sent for all the QoS in the QoS list.
1.25
Error occurred on Test connection in case of OLEDb and ODBC with data source specified is fixed.
Problem with probe getting restart for both Apply and Ok actions fixed.
October
2009
August
2009
Auto-fill of the connection user interface in case of ODBC.

Added support for date and time comparison on the value tab.
1.24
Problem with message variable truncation fixed.

Problem with sending connection error alarm fixed.
March
2009
Problem with value checking columns format fixed.

Problem with some numeric values fixed.
Problem with currency values fixed.
Problem with date formating in message fixed.
1.22
Fixed the problem of profile not starting on schedule time.
October
2008
1.21
Problem with value checking columns format fixed.
August
2008
1.20
Problem with Alarm Threshold.
July 2008
No record alarm does not clear.

Fix for two similar alarms on Response time threshold breach.
Fix for windows authentication.
Fix for crash in cfg migration.
Fix for saving threshold changes in configuration file.
Fix for connecting to Lotus Notes database through ODBC.
Fix for displaying columns in case no rows are returned by test query.
Fix for clearing now row alarms.
Fix for profile deletion problem after updating QoS
1.18
Clear connection alarm for all profiles

Clear existing alarms after restart if within thresholds
December
2007
1.16
cfg migration to 1.15 format corrected

windows authentication
September
2007
support for "date" format

QoS on every column, every row
unknown value ins QoS on "no record"
"run now" for profile test
character comparison
regular expression comparison
set log file size
Alternative alarm source added
Memory leak problem fixed
Clear query-timeout/error alarm
1.08
Fixed rename profile error.
July 2006
Changed scheduling functionality to prevent the combination of 'run once' and 'exceptions'
For 'value' checking, all query results can be used in alarm messages, using column names as variables, preceded by $
(case sensitive!)
1.07
'Rename profile' error corrected
June 2006
'Run once' and 'exceptions' in scheduling not possible together

For 'value' checking, All query results can be used in alarm messages, using column names as variables, preceded by $
(case sensitive!)
1.05
New profile scheduling feature.
April 2006
Variable $description added to messages.

Thread handle initialize
Debug messages extended
Connection error message
No record message
Query timeout correction
1.02
Division by zero fixed.

The sql_response probe should be installed on systems with the following minimum resources:

The sql_response probe requires the following software environment:
MDAC 2.5 or higher + ADO provider for database to be connected
Known Issues
The probe has the following known issue:
Connection to ODBC is not successful if semicolon (; ) is used in the password.
September
2005
sqlserver (SQL Server Monitoring) Release Notes

SQL Server Monitoring (sqlserver) is a remote probe that continuously monitors the internal performance and space allocation of the SQL Server
database. The probe sends this monitoring information to the UIM availability manager for the appropriate alert notification, when required. The
monitoring information is based on the checkpoints that you can select and schedule according to your requirements.
Contents
Revision History
Supported Versions
Setting Permissions
Revision History
Version
Description
State
Date
4.94
Fixed Defects:
GA
January
2015
GA
October
2015
GA
July 2015
GA
December
2014
Probe was not generating QoS Messages at the specified poll interval. Support case number 246108
Probe was not displaying the value in Bytes when lock_memory, connection_memory, optimizer_memory,
sqlcache_memory, and total_memory checkpoints were executed. Support case number 246026
4.93
Fixed Defects:
Probe was reporting a connection timeout in a time less than that specified in the checkpoint interval. Salesforce case 0
0154897
Probe was displaying an error message while executing agent_job_failure checkpoint using Windows authentication. Sa
lesforce case 00155101
4.92
Fixed Defects:
Fixed a defect where the template checkpoint was overriding the static checkpoint. Salesforce case 00165905
Fixed a defect where the QOS was not always coming through Use FQDN As QoS Source. Salesforce case 00144129
Fixed a defect where the remote probe was reporting a connection timeout before the scheduled checkpoint interval. Sal
Added user setting information for SQL Server 2014. Salesforce case 00162883
4.91
Fixed Defects:
Fixed a defect where the Use Excludes check box is disabled when a new custom checkpoint is created. Salesforce
case 00151079
Fixed a defect where the user_cpu checkpoint returns the CPU usage value greater than 100%. Salesforce case
00147822
4.90
What's New:
Beta
December
2014
GA
January
2014
GA
March
2013
GA
March
2013
Added support for SQL Server 2014.

Fixed Defects:
Fixed a defect where the connection timeout value was always set to 2 seconds even after assigning a different value. S
Fixed a defect where the check_dbalive_2 default message is enclosed in quotes. Salesforce case 00151089
Fixed a defect where the probe did not start if the profile name length exceeded 60 characters. Salesforce case
00148591
4.84
Fixed Defects:
On creating a threshold for alarms from Status tab, the object name was not appearing as per expectations.
During unauthorized query changes for the custom checkpoints, the alarm was generated and was repeating the
message again and again. This defect has been fixed.
The alert message is generated once and the checkpoint is deactivated as expected.
4.81
4.80
Fixed: Garbled data coming in alarm message for user_waits checkpoint.

Added features in user_waits for blocking length and the include, exclude feature in exclude of user_waits.
Added checkpoint logfile_usage_with_avail_disk and category_name for jobs in checkpoint long_jobs.
Added feature in backup_status for ignoring databases for no of days, restoring databases and database snapshots.
Added feature for clear alarm for profile level alarms.
Added feature in long_jobs for active jobs, their name, job run time and name of category.
Fixed: Errors with respect to checkpoint logfile_usage and logfile_size.
Fixed: Multiple conf_sqlserver_4.40.exe are created while testing sqlserver probe.
Fixed: Changes getting applied on click cancle button also.
Fixed: Details of one custom checkpoint gets displayed on another custom checkpoint.
Fixed: Alarms related to float values.
Fixed: av_fragmentation checkpoint reporting NULL table values.
Fixed: Probe to show Fully Qualified Domain Name as QOS source.
4.72
Fixed a defect where checkpoint's check_interval was not working.
GA
January
2013
4.71
Added checkpoint logfile_usage_with_avail_disk and category_name for jobs in checkpoint long_jobs.
GA
January
2013
4.71
Updated the mirror state values in the hints section of mirror_state checkpoint.
GA
December
2012
GA
December
2012
4.70
Added a feature in custom checkpoints which will allow thresholds to be defined for multiple columns.
Added functionality to set up a schedule for each alarm in custom as well as built-in checkpoints.
Added functionality to set up key specific alarms in custom checkpoints.
Added new checkpoint(fg_freeSpace_with_avail_disk) which monitors free space in filegroups after considering the
available disk size.
Fixed check_dbalive checkpoint to send value "0" instead of "NULL" as QoS for connection failure.
Fixed an issue related to incorrect calculation for fg_free_space checkpoint.
Fixed an issue related to negative values for the checkpoints fg_free_space and free_space.
Fixed an issue in custom checkpoints where NULL QoS with invalid keys were generated in case of any databaserelated errors.
Fixed an SOC issue of CM Authentication Failure.
4.6
Fixed an issue where the "Windows Authentication" method lets you access the server with or without providing a valid
user account
GA
September
2012
GA
June 2012
GA
June 2012
GA
March
2012
GA
March
2012
Fixed an issue where the "Windows Authentication" method on local system is connecting using system account rather
than the domain account configure in the connection.
Added a feature "suppress all alarms" so that all the alarms are suppressed.
Added a feature so that a monitoring profile does not run concurrently and the delay alarm raised whenever the profile
run is delayed.
Fixed an issue where the profile shows template checkpoints even though the group is selected.
Fixed the issue with logfile_usage checkpoint which was reporting incorrect values.
Fixed an issue where the probe was crashing if "detect domain automatically" is selected on a machine which is not on
domain.
4.41
4.40
Fixed an issue with backup_status checkpoint was reporting wrong value.

Added a new checkpoint suspect_pages for reporting if suspect pages are logged for databases.
Added a new checkpoint agent_job_failure for reporting failed agent jobs within a defined interval.
Added new checkpoints ls_primary_status, ls_secondary_status, ls_primary_time_since_last_backup,
ls_secondary_time_since_last_copy, ls_secondary_time_since_last_restore and ls_secondary_last_restored_latency
checkpoints for monitoring Log Shipping in SQLServer 2005 and above.
Added a callback that able to specify wildcard or regex in profile_name value to fetch active profiles.
Fixed an issue where active_connection_ratio checkpoint was not working.
Fixed an issue where checkpoint schedule was running for an extra minute.
4.30
Fixed an issue where the probe was failing to pick up no. of samples(overridden) correctly for static checkpoints.
Fixed a logging issue where the probe was incorrectly logging sqlserver password in plain text.
Fixed an issue where in some cases the probe was failing to return any rows for custom checkpoint queries.
Fixed QOS V2 compatibility issue, earlier the probe was not able to send the QOS as per V2 QOS specification
Fixed an issue in manual signed stored procedure feature related to permissions.
Fixed an issue where the probe was incorrectly converting metric units(KB/MB/GB etc.) for some checkpoints
Fixed an issue where the probe was not able to return any rows in case of complex custom checkpoint queries.
Fixed an issue in logfile_size and logfile_usage checkpoints where the checkpoints were failing when any database is in
the middle of recovery. The probe now skips the databases which are being recovered until the recovery is complete
and database is online.
4.22
Fixed Misspelling in description of lock_requests checkpoint

Fixed Size reporting for large databases.
4.21
Fixed SOC Issues.
GA
December
2011
4.20
SOC Support Added. Added support for signed store procedure for standard and custom checkpoints queries. Probe can be
run in standard as well as in sign mode. Added new checkpoints mirror_state, mirror_witness_server and mirror_sqlinstance
for monitoring Database Mirroring state, status of witness server and status of sql server instance hosting mirroring database.
Fixed an issue where sqlusr_cpu store procedure are not deleted after executing queries in case of SQL Server 2000.
Modified qos_key value for user_cpu checkpoints for avoiding large amount of QoS. Fixed an issue related to subsystemid
field where subsystemid shows wrong value. Fixed an issue where long_jobs checkpoint do not send any alarms. Fixed an
issue where logic_fragment checkpoint gives Lock request time out error. Fixed Handle leak issue. Added support for
configuring unit as minutes, hours and days in backup_status, transaction_backup_status and differential_backup_status
checkpoints. Added a new error alarm message that will be send in case of checkpoint query execution failure.
GA
August
2011
GA
April 2011
GA
September
2010
4.11

4.01
Fixed division by zero errors for Logfile_Usage and Logfile_Size checkpoints.

Added interval_value variable in custom checkpoints, so QoS can be sent on interval_value.
Updated QoS definition of logfile_size i.e. removed qos_max.
4.00
Added a new checkpoint logfile_size for reporting database log file size in MB.
GA
September
2010
Initial implementation of sqlserver probe based on V4 database framework.

Fixed defects in probe and GUI
Implemented support for alarms.cfg .
Added a new checkpoint blocked_users for calculating blocked user connections
Added support for authentication on untrusted domain
Fixed an issue in backup_status checkpoint where it was incorrectly reporting logfile_usage QOS
Fixed a crash in GUI configurator related to editing message variables
Fixed the white space issue in GUI configurator
Added support for includes functionality in the probe. This feature works just the same as exclude feature
Fixed an issue in fg_free_space checkpoint where incorrect values are being reported by the probe
Added support for reporting QoS values for long_queries checkpoint
Added a new checkpoint active_connection_ratio for reporting active connection ratio
Added two new checkpoints transaction_backup_status and differential_backup_status for reporting transaction and
differential backup status
Fixed an issue in GUI configurator where the "Alarm Severity filter" field on the setup tab was editable, now the field is
made non-editable
Added support for creating custom checkpoints for reporting per-second metric values
Added support for configuring separate sql timeouts for checkpoints
Added 64-bit support
Updated cfx file for message variables in 'server_startup' checkpoint.
3.14
GA
August
2010
3.13
In case of custom checkpoints, the query password was not always saved properly. Fixed the query password encryption in
GUI.
Note: If any custom checkpoints are deactivated by the probe, those checkpoints will have to be deleted from the GUI and
will have to be added again in the probe.
GA
September
2009
3.11
SQL Native Client 2008 support.
GA
January
2009
GA
December
2008
GA
October
2008
3.07
Query for checkpoint free_connections corrected.

Threshold migration for check_dbalive corrected.
V2 QoS compatibility modus
3.05
Problem with crashes in multithreaded environment fixed.

Query database_size for SQL Server 2000 corrected.
Several other queries for SQL Server 2000 corrected.
Memory leak problem fixed.
3.03
Problem with empty password solved
GA
September
2008
3.02
Windows authorization support corrected.

queries logfile_usage and fg_free_space corrected
GA
August
2008
3.00
Multithreading - every profile runs in a separate thread.
GA
May 2008
GA
June 2007
GA
November
2006
GA
April 2006
GA
November
2005
Scheduling - every checkpoint can have its own schedule.

Multiple thresholds - every checkpoint can have more than one threshold.
Message pool - messages can be customized and reused among checkpoints.
Connection retry - for every connection there can be number of attempts defined, before the probe raise an alarm.
Resizable GUI windows - all windows with lists are resizable.
Multiple QoS per checkpoint
Exclude lists
# of samples for alarming
Auto-update (GUI)
Customer-created checkpoints
New checkpoints: long_queries, long_jobs, backup_status
Problem with occasional "probe may be hanging" message fixed
Problem with database names containing "-" or other special character solved
Support for case-sensitive database added
"No response" parameter added into GUI
2.14
problem with database names containing "-" or other special character solved
support for case-sensitive database added
"No response" parameter added into GUI
2.12
Added library to enable support for SQL Server 2005.

Integer overflow in free space calculation fixed.
Hardcoded "oracle.log" removed.
Long domain instance name possible.
2.10
New checkpoint database_status

Database name added to "locked_users" message
2.09
new checkpoint alloc_space

buf_cachehit_ratio corrected for SP3
domain user-id support for Windows security
Severity for "Database report generation time..." alarm changed (default "critical" now)
Supported Versions
The sqlserver probe supports the following SQL Server versions:
SQL Server 2005
SQL Server 2008
SQL Server 2008 R2
SQL Server 2012
SQL Server 2014
Notes:
The sqlserver v4.9 probe supports SQL Server 2014.
From April 2013 onward, Microsoft has discontinued the support for SQL Server 2000 version. Therefore, all enhancements
done for sqlserver probe v4.8 or later are not supported for SQL Server 2000.

The sqlserver probe must be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. The OOB configuration requires 256MB of RAM.


The sqlserver probe requires the following software environment:
MDAC 2.5 or higher, and ADO provider for database connection
You need to install probe on a robot to remotely monitor MS-SQL server or a PC installed with client software for SQL Server.
Setting Permissions
For SQL Server versions 2005, 2008, and 2012, 2014 set VIEW SERVER STATE permission on master database. Also, map the user for the
following databases:
master
model
msdb
ReportServer
ReportServerTempDB
tempdb
Usually, the default database roles are used to grant access to the users. However, you can edit and grant different roles and permissions to
different users. User mapping is done to GRANT, REVOKE, and DENY permissions for the user in the SQL Server.
Follow these steps:
1. Right-click on the table and go to Properties > Permissions Tab.
2. Select Add and browse for the user to grant permission.
3. Click OK.
4. Select the permission type under the Grant column.
User is mapped for the required permission. User mapping is required for the following tables:
master.sys.databases
master.dbo.sysperfinfo
msdb.dbo.sysjobsteps
msdb.dbo.sysjobs
msdb.dbo.syscategories
msdb.dbo.log_shipping_monitor_secondary
msdb.dbo.log_shipping_monitor_primary
msdb.dbo.sysjobhistory
.sys.database_files
.sys.partitions
.sys.allocation_units
.sys.internal_tables
.sys.filegroups
For Windows authentication, perform the following:
map the user to SQL Server for access.

provide access rights to Niscache folder of the file system on which the CA UIM robot is installed.

This section contains the known issues and workarounds for the probe.
The probe configuration for both the Infrastructure Manager (IM) GUI and Adapter Console (AC) GUI is separate. For example, any
profile that is created in the IM GUI is not available on the AC GUI and must be recreated.
If a custom QoS or a checkpoint is added to an existing monitoring profile, the Unified Management Portal (UMP) creates a separate
node in the Metric section (Custom in case of a custom QoS and dynamic in case of custom checkpoint). Further, it does not display the
user-defined description and unit.
The Admin Console version has the following additional limitations:
If a checkpoint has multiple QoS and you activate or deactivate one QoS, the other QoS of the checkpoint are also activated or
deactivated.
If a checkpoint has multiple alarms and you activate or deactivate one alarm, the other alarms of the checkpoint are also activated or
deactivated.
If you edit a message variable in custom checkpoints, it adds a new message variable in the Message Variable table. To edit a message
variable in custom checkpoint, delete and create a message variable.
Dynamic population of Alarm Message field is not supported in AC GUI.
When you define a threshold for a checkpoint, first select a message and then save it. The message text field is updated with the
corresponding message text after the probe reloads the page.
Known SQL Server 2000 Problem

Sometimes, SQL Server internal tables are not updated with the current size values. This can cause negative size values in the following
checkpoints:
database_size
free_size
fg_free_size
table_size
Use command DBCC UPDATEUSAGE to correct the values in SQL catalog. Running this command takes a long time on large databases.
Known SQL Server 2005 Problem with av_fragmentation

SQL Server 2005 changed SQL syntax for some commands with its SP2 maintenance. If you want to run the checkpoint av_fragmentation, you
must apply the SP2 maintenance pack otherwise the checkpoint returns the error 0x80040e14.
V2 QoS Compatibility Mode

In the V3, the has_max flag has been added to following checkpoints:
alloc_space
fg_free_space
free_connections
free_space
locks_used
logic_fragment
scan_density
server_cpu
server_io
user_cpu
workspace_memory
If you have created the QoS definition for any of these checkpoints under V2 sqlserver probe, you must enable the checkbox "QoS V2
compatibility" in the General section of the probe. This ensures that all data is inserted correctly into the QoS database. If you want to use the V3
format (with the has_max flag), delete the V2-generated QoS definitions for these checkpoints (all data for these checkpoints will be deleted).
Unable to Map User to File System Containing Niscache Folder

The probe cannot create .MET files in the Niscache folder. So, the QoS are not inserted in the database, and are not visible on the USM. This
issue is valid for Windows authentication. To enable the mapping, complete the following steps:
1. Open the Raw Configure interface of the sqlserver probe.
2. Set the value of the flag_reverttoself key as Yes.
sybase_rs (Sybase Replication Server Monitoring) Release Notes

The sybase_rs probe extracts vital information about your Sybase Replication Servers using SQL data from the Replication Server as well as from
member Sybase ASE databases. The information is presented to the database-administrator as alarms and/or as a report showing areas that
need attention. The following information is extracted and monitored:
Monitors connectivity to the Replication server
Monitors the thread status of the Replication server
Stable queue used in percent for the Replication server
Monitors the status of log shipping process for specified databases
Monitors replication latency for specified databases
Contents
Configure Sybase Library Path
Known Issues
Revision History
Version
Description
State
Date
1.42
Fixed Defects:
GA
October
2014
GA
September
2014
GA
September
2014
Fixed a defect in which the probe was creating core dump files on Solaris platform. Salesforce case 00144984
1.41
What's New:
1.40
What's New:
Added support for TNT2 compliance where Device Id and Metric Id are generated correctly.
Added support for encrypted authentication between the probe and the sybase replication database server for Linux and
Solaris OS.
1.32
Fixed Defects:
GA
January
2014
GA
March
2013
GA
March
2011
The order of keys that was written in cfg file was in a fixed sequence. Any deviation from this sequence caused the probe to
skip certain important keys resulting in improper configuration of the probe. This defect is fixed and now the keys can be
written in any sequence.
1.30
Enhanced stable_queues checkpoint for Sybase Rep Server v15.x

Added a new checkpoint large_transactions to monitor large transactions in SQT queues.
Added Probe defaults.
1.20

1.11
Added support for alarm cfg.
GA
September
2010
1.10
Added support for extended NIS database (TNT2) information.
GA
July 2010
Updated GUI for config locking.
1.03
Fixed the issue of crash on Linux.
GA
December
2009
1.01
Linux and Solaris package
GA
October
2009
1.00
Initial version of the probe
GA
May 2008
Software: Sybase OCS client 15.x, Sybase Replication Server 15.x, and Sybase ASE Server 15.x
Sybase Replication Server: Sybase Replication Server 15.x/Sybase ASE Server 15.x (only on Solaris sparc v9 and Linux 64-bit systems).
Libraries and Variables: Sybase libraries and environment variables must be set in the system PATH. For more information, refer the Configure
Sybase Library Path section.
Adaptive Server Enterprise 15.7: The property net password encrypt must be changed and set to a value "2" to enable the encrypted
communication between the probe and the Sybase database server.

The Sybase library path is required to specify the location of the shared libraries. You must set the LD_LIBRARY_PATH and the environment
variables to specify the location of the shared libraries.
Note: Ensure that the Sybase server is running and is accessible from the terminal.
Follow these steps:

1. Open the terminal and check the environment variable path using EXPORT command.
2. Copy the following environment variables values to the controller probe.
LD_LIBRARY_PATH: /opt/sybase/ASE-15_0/lib:/opt/sybase/DataAccess64/ODBC/lib:/opt/sybase/DataAccess/ODBC/lib:/opt/sybase/
OCS-15_0/lib:/opt/sybase/OCS-15_0/lib3p64:/opt/sybase/OCS-15_0/lib3p:/opt/sybase/ASE-15_0/lib:/opt/sybase/DataAccess64/ODB
C/lib:/opt/sybase/DataAccess/ODBC/lib:/opt/sybase/OCS-15_0/lib:/opt/sybase/OCS-15_0/lib3p64:/opt/sybase/OCS-15_0/lib3p
SYBASE: /opt/Sybase
SYBASE_ASE: ASE-15_0
SYBASE_JRE_RTDS: /opt/sybase/shared/SAPJRE-7_1_011_64BIT
SYBASE_OCS: OCS-15_0
SYBASE_WS: WS-15_0
SYBROOT: /opt/sybase
Sybase library path variables are configured.
The probe must be installed on a Linux/Solaris Robot with the Sybase server. For monitoring replication latency, the probe creates tables in both
primary and secondary database. Remove the table RSProbeLatency manually if you are uninstalling the probe.
1. Get the package sybase_rs.zip from Internet Updates.
2. Get a valid license from http://www.nimsoft.no.
3. Install sybase_rs.zip on the system running Sybase Client (use drag-and-drop from the CA Unified Infrastructure Management
Probes Infrastructure Manager Archive).
4. Double-click the sybase_rs probe for the probe configuration.
5. Go to the Connection tab and setup ASE Server and Replication Server connections.
6. Define and activate at least one monitoring profile.
Important! Delete the utility folder from the installation directory of the probe if you are only upgrading the probe. The utility folder
contains reference links from the previous version.

The sybase_rs probe should be installed on systems with the following minimum resources:

The sybase_rs probe requires the following software environment:
CA Unified Infrastructure Management Server 7.1 to 7.6 or CA Unified Infrastructure Management 8.0 or later.
Note: CA Unified Infrastructure Management 8.0 or later is required for Admin Console GUI.
CA Unified Infrastructure Management Robot 7.1 or later (recommended).

Java JRE 6 or later.
Probe Provisioning Manager (PPM) 2.38 or later.
Known Issues
The known issues of the sybase_rs probe are:
The sybase_rs probe must be configured on either the Infrastructure Manager (IM) GUI or the Admin Console (AC) GUI.
sybase (Sybase Monitoring) Release Notes

The sybase (Sybase Monitoring) probe allows you to monitor real-time events occurring in the Sybase server. The probe provides parameters to
measure the real-time database operations. The probe also allows you to create custom checkpoints as required to define monitoring profiles.
You can set up multiple monitoring profiles using these checkpoints to extract vital information about the database servers at specified intervals.
You can also configure these profiles to generate alarms and QoS when the specified threshold of an event is breached and identify performance
issues in servers. You can then diagnose and resolve these issues, and take preventive measures to ensure an optimal server run time.
Contents
Revision History
User ID Authorization
ASE Configuration
Revision History
Version
Description
State
Date
4.30
What's New:
GA
October
2015
GA
January
2015
GA
September
2014
GA
January 2
014
GA
November
2012
Added a feature to use alarm source as QoS source.

Added support to rename profile name and connection name from IM GUI.
Fixed Defects:
The probe generated QoS and alarms for excluded patterns defined in thresholds and monitors. Salesforce case
00161495
The probe displayed password in clear text in probe logs. Salesforce case 00169670
The probe displayed incorrect alarms and QoS when the backup server was used. Salesforce cases 246449, 246780
4.21
Fixed Defects:
Fixed a defect in which the default threshold values for some alarms were incorrect. Salesforce case 00145161
Fixed a defect in which the probe GUI was not displaying the correct custom checkpoint schedules. Salesforce case
00145051
4.20
What's New:
Added support for encrypted authentication between the probe and the sybase database server for Linux and Solaris
OS.
Added support for Windows 2012 R2.
Fixed Defects:
Fixed a defect where DevID and MetID are not generated for alarm and QoS.
4.14
Fixed Defects:
Defect fixed related to sybase probe not able to display configuration correctly. Schedules were not visible in custom
checkpoints on reopening the probe GUI.
4.11
Added probe defaults feature.

Fixed an issue where description of checkpoints buffer_memory, stp_memory, and total_memory were incorrect.
4.10
Fixed an issue with the database_size checkpoint where it was returning incorrect values when some DB has mixed
devices.
GA
September
2012
GA
May 2011
Fixed an issue where description of checkpoints buffer_memory, stp_memory and total_memory were incorrect.
Functionality to set up a schedule for each alarm in custom and built-in checkpoints added.
Functionality to set up key specific alarms in custom checkpoints added. Functionality to add custom checkpoints
added.
Functionality to generate QoS metrics from multiple columns that are returned by query in custom checkpoints added.
Thresholds on multiple columns can be created for custom checkpoints.
Support for AIX_5.3 64-bit added.
Support for Solaris 64-bit sparcv9 added.
3.53
Applied temporary workaround to memory leak issue by making the probe restart every midnight.
3.50
Added a checkpoint suspect_pages for reporting if suspect pages are logged for databases.
February
2011
Added a checkpoint agent_job_failure for reporting failed agent jobs within a defined interval.
Added new checkpoints ls_primary_status, ls_secondary_status, ls_primary_time_since_last_backup,
ls_secondary_time_since_last_copy, ls_secondary_time_since_last_restore and ls_secondary_last_restored_latency
checkpoints for monitoring Log Shipping in SQLServer 2005 and above.
Added a callback that able to specify wildcard or regex in profile_name value to fetch active profiles.
Fixed an issue where the active_connection_ratio checkpoint was not working.
Fixed an issue where the checkpoint schedule was running for an extra minute.
3.42
Fixed an issue where the probe was failing to pick up no. of samples(overridden) correctly for static checkpoints.
GA
September
2010
GA
September
2012
GA
August
2010
GA
August
2010
Fixed a logging issue where the probe was incorrectly logging sqlserver password in plain text.
Fixed an issue where sometimes the probe was failing to return any rows for custom checkpoint queries.
Fixed QOS V2 compatibility issue, earlier the probe was not able to send the QOS according to V2 QOS specification.
Fixed an issue in manual signed stored procedure feature that is related to permissions.
Fixed an issue where the probe was incorrectly converting metric units(such as KB, MB, or GB) for some checkpoints.
Fixed an issue where the probe was not able to return any rows in complex custom checkpoint queries.
Fixed an issue in logfile_size and logfile_usage checkpoints where the checkpoints were failing when any database is in
the middle of recovery. The probe now skips the databases which are being recovered until the recovery is complete
and database is online.
3.41
Fixed Misspelling in description of lock_requests checkpoint

Fixed Size reporting for large databases.
3.40
Fixed SOC Issues.
3.31
SOC Support Added. Added support for signed store procedure for standard and custom checkpoints queries. Probe
can be run in standard and in sign mode. Added new checkpoints mirror_state, mirror_witness_server and
mirror_sqlinstance for monitoring Database Mirroring state, status of witness server and status of sql server instance
hosting mirroring database. Fixed an issue where sqlusr_cpu store procedure is not deleted after executing queries in
SQL Server 2000. Modified qos_key value for user_cpu checkpoints for avoiding large amount of QoS. Fixed an issue
that is related to the subsystemid field where subsystemid shows wrong value. Fixed an issue where the long_jobs
checkpoint does not send any alarms. Fixed an issue where logic_fragment checkpoint gives Lock request time-out
error. Fixed Handle leak issue. Added support for configuring unit as minutes, hours and days in backup_status,
transaction_backup_status and differential_backup_status checkpoints. Added a error alarm message that is sent in
checkpoint query execution failure.
3.30
Added support for the internationalization.
March
2010

3.26
Fixed division by zero errors for Logfile_Usage and Logfile_Size checkpoints.

Added interval_value variable in custom checkpoints, so QoS can be sent on interval_value.
Updated QoS definition of logfile_size, for example: removed qos_max.
GA
November
2008
3.24
Added a checkpoint logfile_size for reporting database log file size in MB.
GA
Initial implementation of the sqlserver probe that is based on V4 database framework.
August
2008
Fixed defects in probe and GUI

Implemented support for alarms.cfg.
Added a checkpoint blocked_users for calculating blocked user connections
Added support for authentication on untrusted domain
Fixed an issue in backup_status checkpoint where it was incorrectly reporting logfile_usage QOS
Fixed a crash in GUI configurator related to editing message variables
Fixed the white-space issue in the GUI configurator
Added support for includes functionality in the probe. This feature works the same as the exclude feature
Fixed an issue in fg_free_space checkpoint where incorrect values are being reported by the probe
Added support for reporting QoS values for long_queries checkpoint
Added a checkpoint active_connection_ratio for reporting active connection ratio
Added two new checkpoints transaction_backup_status and differential_backup_status for reporting transaction and
differential backup status
Fixed an issue in GUI configurator where the "Alarm Severity filter" field on the setup tab was editable, now the field is
made non-editable
Added support for creating custom checkpoints for reporting per-second metric values
Added support for configuring separate sql timeouts for checkpoints
Added 64-bit support
Updated cfx file for message variables in 'server_startup' checkpoint.
3.23
3.22
In case of custom checkpoints, the query password was not always saved properly. Fixed the query password encryption in
GUI.
July 2008
GA
June 2008
Note: If any custom checkpoints are deactivated by the probe, those checkpoints must deleted from the GUI and added
again in the probe.
3.20
Fix for check_dbalive default threshold
GA
April 2008
3.12
Fix for check_dbalive default threshold.
GA
February
2008
3.11
Problem with test connection fixed.
GA
December
2007
GA
September
2007
Note: During the migration from sybase probe V2.xx it can happen, that the checkpoint "check_dbalive" threshold does not
get translated correctly into new value. In that case, the probe incorrectly report that the database server is not alive, even if it
is running.
Solution: the old threshold value "ONLINE" must be corected to the new value "1", using either the GUI or raw config.
3.10
New checkpoints: LOG_SIZE, DB_DEVICE_SIZE, TEMPDB_DEVICE_SIZE, DEVICE_SIZE

Problem with scheduling corrected
2.06
The probe is now built with the new Sybase ASE 15 libraries, in addition to the ASE 12 libraries. A post-install program
determines which version of Sybase is running to ensure the correct version of the probe is used.
GA
August
2006
2.05
cfg parameter "noResponse_severity" introduced to change "Report Generation Time exceeded..." alarm severity
GA
November
2005

The sybase probe must be installed on systems with the following minimum resources:
Memory: 2-4 GB RAM (OOB configuration of probe requires 256MB RAM)

The probe needs to be configured on the Sybase server that you want to monitor. The sybase probe requires the following software environment:
The probe must be configured on Windows, Linux or Solaris platforms.
The sybase probe has the following prerequisites for installation:
Libraries and Variables: The probe requires the following library configurations:
libstdc++ 5 library must be present on the robot platform.
Sybase libraries and environment variables must be set in the system path. For more information, refer the Configure Sybase Library
Path section.
Software: Sybase OCS client 15.x or ASE 15.x.
Advanced Monitoring: Sybase Monitoring Server or Monitoring Tables must be installed and enabled.
Sybase: Sybase Monitoring Server must be up and running.
Adaptive Server Enterprise 15.7: The property net password encrypt must be updated to a value 2 to enable the encrypted
communication between the probe and the Sybase database server.

You must set the LD_LIBRARY_PATH and the environment variables to specify the location of the shared libraries.
Note: Ensure that the Sybase server is running and is accessible from the Linux system.
Follow these steps:

1. Log in to the Linux system and verify the environment variable path using EXPORT command.
2. Copy the following values of the environment variables to the controller probe.
LD_LIBRARY_PATH: /opt/sybase/ASE-15_0/lib:/opt/sybase/DataAccess64/ODBC/lib:/opt/sybase/DataAccess/ODBC/lib:/opt/sybase/
OCS-15_0/lib:/opt/sybase/OCS-15_0/lib3p64:/opt/sybase/OCS-15_0/lib3p:/opt/sybase/ASE-15_0/lib:/opt/sybase/DataAccess64/ODB
C/lib:/opt/sybase/DataAccess/ODBC/lib:/opt/sybase/OCS-15_0/lib:/opt/sybase/OCS-15_0/lib3p64:/opt/sybase/OCS-15_0/lib3p
SYBASE: /opt/Sybase
SYBASE_ASE: ASE-15_0
SYBASE_JRE_RTDS: /opt/sybase/shared/SAPJRE-7_1_011_64BIT
SYBASE_OCS: OCS-15_0
SYBASE_WS: WS-15_0
SYBROOT: /opt/sybase
Sybase library path variables are configured.
User ID Authorization
The probe operates in basic and advanced modes. In the basic mode, the probe collects information from the sybase table accessible to the user.
In the advanced mode, the probe uses monitoring tables from the Sybase Adaptive Server Enterprise (ASE) to collect monitoring information of
the database from the ASE.
Basic Mode
Access to following tables is needed to run the probe in basic mode:
sysdatabases
spt_values
sysusgaes
sysprocesses
syscurconfigs
sysconfigures
Advanced Mode
Consider the following points to connect to the database in advanced mode:
User credentials to access Sybase server requires 'mon_role' authorization to connect to the database using Monitoring Tables.
Sybase System Administrator account such as 'sa' is used to run the probe using Monitoring Server API.
Note: For configuring the probe on Sybase server, Sybase Monitoring Server or Monitoring Tables must be installed and activated.
ASE Configuration
You must configure the following values in the ASE for monitoring the data collection of tables:
buf_cachehit_ratio
enable monitoring = 1
lock_requests, lock_requests_db, lock_requests_granted_db, lock_requests_waited_db
per object statistics = 1
object lockwait timing = 1
total_disk_io
stp_cachehit_ratio
locked_users (advanced, with sql text)
max SQL text monitored = 1024 or more
SQL batch capture = 1
sql text pipe active = 1
sql text pipe max messages = 256 or more (depends on interval length and server activity)
The probe has the following migration considerations:
Before upgrading the probe, delete the utility folder from the installation directory of the probe. The utility folder contains reference links
from the previous version.
If you migrate the probe from previous releases, only the old configuration file (sysbase_monitor.cfg) is migrated into a release 3
configuration file (sysbase_monitor_v3.cfg). Every instance from V2 is converted into one connection and one monitoring profile in V3.
Every profile starts one thread for SQL queries and one process as Monitor Server data collector.
From version 4.2 onward, the probe does not support advanced monitoring using Monitoring Server for Linux 64-bit systems. This is
because the Monitoring Server is not a part of the Adaptive Server Enterprise v15.7.

The known issues of the sybase probe are:
The probe must be configured using either the Infrastructure Manager (IM) GUI or the Admin Console (AC) GUI.
With Sybase OCS 15.0, the Sybase Monitoring Server API can end in a CPU loop if the probe agent does not close connection to the
Sybase server properly. This issue is solved by applying Sybase maintenance (15.0.2 or higher).
sysloggtw (System Log Gateway) Release Notes

The Syslog Gateway probe acts as a gateway from the Syslog environment into CA UIM. Most network devices, such as routers, switches, and
bridges, report events using SNMP as well as using the well-known syslog format. The Syslog Gateway probe listens to port 514/udp when
running in a receive mode. All incoming Syslog messages are acted upon using the defined receive mode:
Generate Alarm
Generate SYSLOG-IN (for post-processing) messages
Log to the file
The Syslog Gateway probe is also capable of receiving alarm messages. For example, you receive a message from the Alarm Server
auto-operator that is converted to a Syslog message and passed onto remote syslog daemons.
You may combine the sysyloggtw with logmon to post-process incoming syslog messages. Some devices like Cisco routers may add an index to
each message. Use logmon to reformat the text and severity levels instead of having sysloggtw determining the alarm level according to the
syslog priority.
Using logmon and sysloggtw, you can:
Create an "attach" queue collecting the subject SYSLOG-IN.
Add a profile that attaches to the named queue.
Add watchers according to your needs.
Contents
Revision History
Known Issues
Revision History
This section describes the history of the revisions for the sysloggtw probe.
Version
Description
State
Date
1.41
Fixed Defects:
GA
February
2015
GA
December
2012
GA
September
2010
Fixed an issue in which the dev ID was coming from local robot rather than actual device. Salesforce cases 00147258,
00147305, 00147258
Fixed an issue in which there was no alarm for backup file at the required interval, unless there was an Incoming log. S
Fixed an issue in which the probe was not using the configured path to delete the file. Salesforce case 00149998
1.40
What's New:
Added probe defaults for the probe.
Fixed Defects:
Fixed an issue in which log files were not getting deleted after the correct number of days set.
1.30
Added support for Windows 64, Linux 32/64 and Solaris platforms.
Fixed memory leak.
Added proper configuration file reading mechanism on probe restart.
Added proper thread termination and start functionality on probe restart and stop.
Added support to redirect messages in separate file and to provide variable names ($logsource and $date) in that
file-name.
Added support to store logs in separate log files as per the source (IP address) they are coming from.
Added support for probe logfile truncation.
Implemented file rotation algorithm (for message file). Added support for file rotation based on size or time along with
file cleanup after certain period.
1.21
GA
June 2010
1.20
GA
March
2010
1.12
Improved message delivery to spooler.
GA
November
2003

The sysloggtw probe should be installed on systems with the following minimum resources:

The sysloggtw probe requires the following software environment.
Robot 5.23 or later
Ensure that port 514/udp is free. You may do this by issuing the netstat -an command, and look for something like UDP 0.0.0.0:514. If it is
present, then something else, for example, a syslog daemon is using this port.
When upgrading from versions prior to 1.41 on Unix platforms, the log files must be manually cleared before upgrading.
Known Issues
Post-processing of SYSLOG-IN messages using the logmon probe is possible only when the matched pattern consists of ASCII characters.
sysloggtw probe cannot interpret incoming multi byte syslog messages from remote devices.
For example, consider four remote devices that send syslog messages to sysloggtw probe with four different encodes:
Device (A) - Shift_JIS encode
Device (B) - UTF-8 encode
Device (C) - EUC encode
Device (D) - ASCII encode
The logmon probe monitors SYSLOG-IN queue only for remote device D.
sysstat (iSeries System Statistics Monitoring) Release Notes

The IBM iSeries System Statistics Monitoring (sysstat) probe monitors the iSeries system statistics. You can create profiles to monitor system
statistic variables for:
Batch jobs
Users
System status
Storage pools
Alarm messages are generated when the specified threshold for the defined system statistic variable is breached.
Contents
Revision History
Revision History
This section describes the history of the revisions for the sysstat probe.
Version
Description
State
Date
1.14
What's New:
GA
September 2015

Fixed Defect:
The variable list did not appear after migration to UIM 8.2. Salesforce cases: 00169247, 00166416
1.13
Fixed Quality of Service send for 'MaxUnprotectedStorageUsed'.
GA
August 2012
1.11
GA
January 2011
1.10
Added new alarm and QoS metric functionality.

Added support for Internationalization.
Internal update: Modified to use nim library version 4.
1.08
New variables added.
1.07
July 2009
New base library used.
November 2007
Fixed list positioning on profile edit.

1.06
Fixed missing QoS problem introduced in version 1.05.
May 2007
1.05
QoS definition fix for pool statistics variables.
May 2007
1.04
Default QoS source when hostname is not found is set to the robot name.
February 2006
1.03
Added counters for memory pools.
March 2005

The sysstat probe should be installed on systems with the following minimum resources:

The sysstat probe works only on AS400 systems. It requires the following software environment:
Java JRE 6 or later
Probe Provisioning Manager (PPM) probe version 2.38, or later (required for Admin Console)
tcp_proxy (TCP/IP Proxy Service) Release Notes

The tcp_proxy probe sets up a proxy connection to a set of defined TCP services, either locally or through a tunnel.
Contents
Revision History
Requirements
Revision History
Version
Description
State
Date
1.10
Initial version of probe with GUI
GA
Jun 2010
Requirements
This section contains the requirements for the tcp_proxy probe.
None.
CA Unified Infrastructure Management Robot 3.00 or later.
threshold_migrator (Threshold Migrator) Release Notes

The threshold_migrator probe allows you to migrate the probe threshold configuration values to the standard static threshold configuration of the
baseline_engine. Migration also includes custom alarm messages. The advantages of standard static threshold configuration are:
Consistent threshold configuration options (for all probes that support it)
Ability to configure Time Over Threshold for static thresholds
Support for five different threshold levels (most probes support one or two levels)
Note: Migration is supported for the specified version or later of the probes using CA UIM 8.31 or later for threshold_migrator.
Contents
Revision History
Supported Probes
Revision History
This section describes the history of the revisions for the threshold_migrator probe.
Version
Description
State
Date
2.11
What's New:
GA
September 2015
GA
August 2015
Added support to migrate the exchange_monitor probe to standard static thresholds.

2.10
What's New:
Added support to migrate the net_connect probe to standard static thresholds.
Added support to migrate dynamic alarm variables in dirscan 3.13 or later.
2.01
What's New:
CR
June 2015
Beta
May 2015
GA
March 2015
Added support to migrate the following probes to standard static thresholds:

ad_server
iis
lync_monitor
rsp
sharepoint
Added support to migrate probes on all hubs in a domain.
Added support to view robot specific migration error details.
1.10
What's New:
Added support to migrate the url_response probe to standard static thresholds.
Added support for robot specific migration.
1.00
Supported Probes
The 1.00 and later versions of the probe migrate the threshold configuration for the following probes:
dirscan (File and Directory Scan) version 3.12 or later
logmon (Log Monitoring) version 3.49 or later
ntperf (Performance Collector) 1.90 or later
The 1.10 and later versions of the probe also migrate the threshold configuration for the following probes:
url_response (URL Endpoint Response Monitoring) 4.20 or later
The 2.01 and later versions of the probe also migrate the threshold configuration for the following probes:
ad_server (Active Directory Server Monitoring) 1.80 or later
iis (IIS Server Monitoring) 1.71 or later
lync_monitor (Microsoft Lync Server Monitoring) 2.20 or later
rsp (Remote System Probe) 5.10 or later
sharepoint (Microsoft SharePoint Server Monitoring) 1.70 or later
The 2.10 and later versions of the probe also migrate the threshold configuration for the following probe:
net_connect (Network Connectivity Monitoring) 3.11 or later
The 2.11 and later versions of the probe also migrate the threshold configuration for the following probe:
exchange_monitor ((Microsoft Exchange Monitoring) version 5.20 or later

After migration, the baseline_engine probe sends the alarms for these probes. The alarm thresholds can only be configured from the Admin
Console. Refer Configuring Alarm Thresholds for information about how to configure the static thresholds after migration. Also, the Admin
Console GUI of the probe displays the static alarms and time over threshold configurations. You cannot configure the probe-specific alarm
configurations to generate alarms.
After migration, the following elements of the migrated probe are not available:
Infrastructure Manager GUI
Opening the IM GUI displays a message that the probe can only be configured using the Admin Console. You are then redirected to the
Release Notes for the probe.
Automated rollback
The probe does not support rollback. A backup of the config file for each instance of the probe is created in the threshold _migrator
installation directory for reference.
Some changes to alarms after migration are as follows:
Alarm messages that are sent by the baseline_engine do not yet support internationalization. The alarm messages are not automatically
translated or displayed in non english languages. However it is possible to use non english characters to customize alarm messages.
The $ variables that are used in probe alarm messages are migrated.
The variable syntax changes from $<variableName> to ${<variableName>}.
Static message variables are also migrated and replaced with standard variables such as $value and $threshold.
When you create new profiles for monitoring, customize the alarm messages in the profile, as needed. If no alarm message is configured,
baseline_engine uses a default alarm message string. The default string can be different from the probe alarm messages in other
profiles.
For more information about probe-specific changes, see the threshold_migrator Supported Probe Considerations article .
Important! The IM GUI of a migrated probe is not available after the probe is migrated using threshold_migrator. The migrated probe
can only be configured using the Admin Console GUI.
Refer Known Issues in the ppm probe documentation for the migrated probes to view the limitations of using Admin Console.

The threshold_migrator probe must be installed on systems with the following minimum resources:

The threshold_migrator and its supported probes have the following software requirements:
Note: Robot 7.70 is required to migrate the url_response probe.

PPM (Probe Provisioning Manager) probe version 3.22 or later
udm_manager Release Notes

The UDM Manager (udm_manager) probe is released as a part of the core Unified Infrastructure Management Server release. For this reason,
release notes for the UDM Manager are included in the Unified Infrastructure Management Release Notes.
CA Unified Infrastructure Management - 8.2 Release Notes
CA Unified Infrastructure Management - 8.1 Release Notes
url_response (URL Endpoint Response Monitoring) Release Notes

The URL Endpoint Response Monitoring (url_response) probe monitors time duration for downloading a web page. The probe can also perform
comparison checks on the page contents. The probe supports proxies and user authentication for accessing the requested web URL. In addition,
the probe generates quality of service (QoS) messages for analyzing the URL performance.
Contents
Revision History
Limitations
Known Issues
Revision History
This section describes the history of the revisions for url_response probe.
Version
Description
State
Date
4.23
What's New:
GA
December
2015
GA
September
2015
GA
May 2015
Added support to disable alarms when a string is specified in Look for substring in page content field.
Fixed Defects:
Invalid time was retrieved while checking the SSL certificate of URL. Support case number 00246519
Probe was crashing due to memory corruption. Support case number 00164669
Error was generated in log file when number of samples for calculating the average was specified as zero. Support case
number 70005470
4.22
What's New:
Added support for the following authentication types in Windows platform:
NTLM
DIGEST
GSSNEGOTIATE
ANYSAFE
Fixed Defects:
Defaults were overwritten in message section in the cfx file. Salesforce case 00164613
The probe crashed as it had reached the maximum restarts. Salesforce case 00164669
Variables specified in the Source Override field in the Advanced tab did not expand to their actual values. Salesforce
case 00165815
4.21
What's New:
Added support of dynamic variables (code, description, and timer) in static and dynamic threshold messages. This is
applicable on CA Unified Infrastructure Management 8.3 or later.
Fixed Defects:
Updated alarm priority logic information in probe document. Salesforce case 00160102
Fixed a defect where url_response 4.18 did not report days to certificate expiry for SSL connections. Salesforce case 00
159461
4.20
What's New:
April 2015
The probe can be migrated to standard static thresholds using the threshold_migrator probe.
The device ID key (useHostNameForDeviceIdentification) can be set through Raw Configure. Default value of key is
no. Set this key to yes to generate device ID based on hostname instead of IP address.
Separate source override text boxes added for Alarm and QOS in Advanced tab.
Fixed Defects:
The authentication did not work for profiles and user was getting 401 error code. Salesforce case 00135591
The user was unable to monitor a URL and was getting 500 error code. Salesforce case 00153888
The user was unable to connect to https websites. Salesforce cases: 00146412, 00148664, 00146769
4.18
Fixed Defects:
March
2014
A new profile was not being created in case the URL was an IP address.
For some URLs, the substring match (with or without regex) was unsuccessful.
4.17
Fixed Defects:
January
2014
The probe always displayed Clear Pending Alarm message for any alarm being cleared, irrespective of the clear
message configured for that alarm.
Fixed a defect to prevent creating profile with blank URL.
4.16
Fixed issue related to url_response probe fails to alarm after profile is setup to not alarm on first sample. Probe default
updation. Fixed issue related to url_response probe fails to populate variables properly in UMP when internationalization is
ON in nas.
October
2013
4.15
June 2013
4.14
Fixed: File dump content is partially visible on screen. Fixed: Website with windows authentication no longer works.
April 2013
4.13
Added Support For Ubuntu/Debian/CentOS- 64Bit Debain& Ubuntu-32 Bit

Fixed: Issue of memory leak.
4.12
Fixed issues related to SSL Certification Fixed Certification error related to severity Fixed Issue related to File Dump
Fixed Issue related to 35SSL Connect error Fixed issue related to form authentication.
November
2012
September
2012
Added Support for Debian/Ubuntu for Peer1 for libc.so.6

4.11
4.10
Added fix to Cant get source field for QoS messages.

Added support for IPv6. Added fix to send clear alarm on each interval if "sendAlarmOnEveryInterval" is set to "yes" in
the CFG and no threshold is breached.
January
2012
December
2011
Fixed minor bugs in the GUI

4.00
Added support for SSL and client certificates.

Added a tab for configuring SSL Certificates in the GUI.
August
2011
Added support for monitoring of certificates.

Added support for Linux PPC64.
Added support to modify the "Delayed" message for a specific set of profiles.
Fixed an issue with clearing of alarms when using alarm source override.
Fixed an issue to correctly display the sampled value for Time to First Byte in the alarm message.
Fixed the issue in which the suppression key for clear and other alarms was not matching.
Fixed issue where was probe was sending QOS when no QOS was selected.
Fixed issue where the probe was sending alarms with incorrect subsys on restart.
Fixed issue where the alarms were being acknowledged when applying updates.
Fixed issue where the Profile Name field was not allowing text like http://www.google.com.
3.92
Issue with QoS Data when upgraded from 3.63 to 3.91 is fixed.
Fixed SOC defects
3.91
March
2011
January
2011
3.90

December
2010
Fixed an issue where the probe used to wait for URL timeouts even when restart or stop is called.
3.82

Fixed an issue where the probe sent hard-coded clear alarm string instead of the string configured in the message pool
for clear alarm.
October
2010
Fixed an issue in content comparison. Earlier, the probe failed to compare the content when the search criteria started
with the first character, even if the string match was ok.
3.81
Added support to send alarms after collecting all samples.
July 2010
Added fix to content matching in page when Windows authentication is enabled.

Added fix to handle the lookup failures when a monitored URL has port numbers.
3.80
Added support for Solaris platform.
July 2010
Added fix to allow variables in "Alarm source override" field.

Added fix to properly rename the profile names.
Added fix for NIS defect.
3.71
3.70

Changed the probe installation folder from Network to Application. (Please refer to the Installation notes section)
June 2010
May 2010
Added support to prohibit use of white space in the probe configurator.

Fixed the issue of look for substring in content failure.
Fixed issue of QoS column in profile view does not work.
Fixed issue of profile not getting created through wizard.
Added support for virtual host name.
3.64
Added support for mapping the custom delayed messages to profiles.
May 2010
3.63
Changed the response time to total time provided by curl instead of nimbus timer.
September
2009
3.62
Added sampling for:

1. DNS resolution time
September
2009
2. Time to first byte

3. Time to last byte
4. Download time
5. Redirect Time
6. TCP Connect Time
Added alarm and QoS for:
1. DNS resolution time
2. Time to first byte
3. Time to last byte
4. Download time
5. Redirect Time
6. TCP Connect Time
Added bug fixes in GUI.
Added new profile form in GUI.
Added QoS for string found.
3.60
Added support for SSL handling in case of windows and curl.

Added retry support before sending String found/not found alarms in case of forwarded urls.
August
2009
Support for overwriting of the subsystem ID.

Enhancements and Bug fixes in GUI.
"No thread available" alarms are now not sent if it is the first run of the profile.
Proper termination of the retry while loop in case of restarts and probe shutdown.
Added feature to ignore connection time in url response QoS and alarms.
3.53
3.52
Fixed problem running on Linux without dynamic libraries present. (This was a problem in new installations of version 3.5x.
Upgrades worked OK).
Fixed issue of missing SubsystemID in default clear alarm.

Added the error code for invalid certificate.
August
2009
January
2009
Fixed the issue with https and nt-authentication.

Fixed the issue of "NimBUS" as user agent in case of windows authentication even if overriden by user.
Fixed problem with test function and passwords.
Corrected handling of https when used in conjunction with Windows NT authentication.
Fixed handling of url options when using Windows NT authentication.
Added schedule for profiles
Grouping support for profile list.
Added Support for windows 2008, linux 64 and windows 64 bit.
User defined clear message.
Added alarm on fetched bytes threshold.
Added alarm on load time below threshold.
Moved critical section initialization to after configuration file read, as the critical section may not be used depending on
configuration parameters.
3.42
3.41
Linux: removed references to IPWorks library.

Resolved Configuration tool crash on Alarm Message Overrides occurring when undefined messages were defined.
July 2008
July 2008
Implemented timeout in use of new underlaying library introduced in version 3.40.

Modified thread handling on restart and stop to allow unfinished threads to complete.
Added alarm message for delayed execution of profiles. This situation can occur when a profile is still running or when
no thread is available for profile execution.
3.40
Changed underlaying library to be able to resolve issues on LINUX.
June 2008
Modified configuration tool to disallow specifying an empty string as a profile name as this resulted in removal of all
non-modified profiles.
Added option to set user agent string.
3.31
Modified configuration tool to disallow specifying an empty string as a profile name as this resulted in removal of all
non-modified profiles.
April 2008
Known issues: This version and previous versions running on Linux have a bug in a library which can cause the probe
to hog cpu and hang or crash. A new version solving this problem will be made available as soon as old functionality
has been ported and verified using the new library.
3.29
LINUX package requires Robot 2.65 or higher to avoid installation problems.

Hanging thread problem on Linux systems fixed.
3.27
3.26
Updated underlaying library to resolve problem with ok return code on LINUX when the web server was actually not available.
Fixed occasional program failure on probe restart.
Fixed alarm message handling for the 'config_error' alarm situation.
3.25
All platforms: Fixed serious memory leak when called from logmon.
LINUX: Explicit dependency on Robot >= 2.60 added to the package to ensure that a suitable glibc is available on
installation.
February
2008
November
2007
September
2007
September
2007
3.23
Fixed problem with NTLM authentication against proxy server.

Added option to set alarm source for each profile.
February
2007
Added support for saving page to disk if status indicates that fetch was unsuccessful.
Added support for encrypted passwords when fetching pages on behalf of another probe or GUI (test_url callback).
Linux version added. Note: Glibc v2.3 required to run this probe! Test_url callback threaded to allow pages to be fetched
on behalf of other probes.
3.20
Fixed expansion of variables again. Now all available variables are expanded for all message types.
November
2006
3.19
Additional flags set when using Windows Authentication to fix issue with redirection from a non-SSL to an SSL connection.
August
2006
3.18
Additional flags set when using Windows Authentication without username/password.
July 2006
Fixed issue regarding alarms not being updated/cleared

(Probe hung because RECEIVE timeout was not set when 'Windows NT Authentication' was used ).
3.16
New version of IP*Works for better support of Windows 2003 Server.

Implemented language option for HTTP Get.
March
2006
General error corrections.

3.15
Fixed expansion of variable $url

Fixed minor bugs in Configurator
November
2005
It is now possible to insert regular expressions when looking for substrings in page content.
3.13
Additional QoS value: Fetch time in bytes per second.
July 2004
Added 'Accept' headers

The url_response probe should be installed on systems with the following minimum resources:

The url_response probe requires the following software environment:
Notes:
For SOC functionality, NM Server 5.6 or later and UMP 2.5.2 or later is required.
For the url_response probe to work on the Linux platform, the libstdc++.so.5 library file should be present in the system
environment.

With version 4.20 and later, threshold configurations of the probe can be migrated to standard static alarm thresholds using the
threshold_migrator probe 1.10 and later. The probe requires the following software for migration using threshold_migrator:
CA UIM 8.2 or later

Note: If you want to migrate the probe to standard static thresholds using the threshold_migrator probe, set the device ID key useHo
stNameForDeviceIdentification to yes in the probe Raw Configuration.

Probe specific alarm configurations in the probe monitors will be replaced by Static alarm, Time To Threshold, and Time Over
Threshold configurations. Refer url_response Metrics for details.
If all the metrics supported for migration are configured, then nine different alarms will be generated after migration. Currently, the probe
generates only one alarm at a time based on metric priority.
The url_response probe can be deployed on a local system to monitor a website URL. The probe requires the following installation
considerations:
The default installation directory for url_response probe has changed to /probe/application from /probe/network. This is applicable for
versions 3.7x and above. If you downgrade to probe version lower than 3.71, the configuration files will not merge.
Some web servers require user authentication. The url_response probe transmits user information as specified in the HTTP / HTTPS
protocols. This works with webpages, where on interactive use, the browser prompts for logon information.
When the web pages implement a logon screen, you will normally have to use the E2E Application Response Monitoring.
In Microsoft environment, authentication with web servers and proxy servers is of the 'Basic' type. if 'Windows Integrated Authentication'
is required, the 'Windows NT Authentication' check box in the profile must be selected. Proxy settings will then be retrieved from the
registry, as saved by Internet Explorer.
Because of limitations in the libraries used, problems can occur on multi-processor computers. In such cases, the probe can be run in
synchronous mode (fetching one URL at a time) by setting the force_synchronous flag in the setup section of the configuration file.
Note that this will limit the number of profiles handled by the probe.
In the case of fast networks, if the ignore connection time option is selected, then the response time of the URL may sometimes be below
1 millisecond. This will be reported as 0 in the probe.
Limitations
By default, the probe is configured to limit the number of concurrent profiles to 100. That is, more profiles can be defined, but the probe checks for
the profiles sequentially. This may potentially lead to profiles not being executed at the scheduled time. The probe raises an alarm in this situation.
You can modify this limit by editing the max_threads setting in the configuration file.
Important! You must check the resource usage of the probe when updating the max_threads setting in the configuration file. This avoi
ds running into machine-dependent limitations for memory, threads or connections.
The probe initially allocates 'min_threads' threads for profile execution. If there are more profiles defined, the probe may gradually increase the
number of threads. Profiles that are not immediately allocated a thread are rescheduled 20 seconds later.
If Windows authentication option is selected, then the alarms and QoS will not be available for the following:
Time to first byte
Time to last byte
TCP connect time

DNS resolution time
Download time
Re-direct time
Known Issues
The Admin Console GUI of the probe has the following known issues:
The probe does not provide schedulers to the profiles.
The probe does not allow test profiles in proxy environment in Unix.
usage_metering Release Notes

The usage_metering probe collects data on UIM usage and provides that data to the billing probe. The billing probe then analyzes the data, maps
it to UIM subscriptions, calculates the billable items, and creates a billing report with summary and detail information.
Contents
Revision History
Revision History
Version
State
Date
8.00
Expanded configuration parsing capabilities to include more remote probes.
GA
September
2014
2.11
Addressed a SQL Constraint Violation that could occur during report generation if scans do not complete before the start
of the next day.
GA
June 2013
GA
March 2013
2.10
Added support for multiple instances of usage_metering.

Fixed defects in the configuration GUI.
Improved device extraction.
2.00
Scans monitored systems for UIM component usage and stores the data. The billing report uses the data to generate
billing reports.
GA
November
2012
1.30
Added ability to:
GA
November
2011
Store the last cycle details.

Copy the exported zip and xml files on the local system if the robot is on different system.
Export the license info.
Page through the QOS Usage, Device Usage and Device Fault tabs.
Set Date and time for first cycle.
The billing probe is typically deployed to the primary hub. An instance of usage_metering must reside on the same robot as the billing probe, and
must be configured as the primary instance of usage_metering. See usage_metering for information on primary and secondary instance types.
vmware (VMware Monitoring) Release Notes

This section contains the release notes for the VMware Monitoring (vmware) probe.
Contents
Revision History
Probe Specific Application Requirements
Upgrading from v6.41 to v6.50
Upgrading from earlier versions to v6.41 or later
Unified Dashboards or Summary Views in UMP
Migration
Considerations for the VMware Web Services API
Considerations for Viewing Information in USM
Best Practices
Performance
Optimizing Memory for the Probe
Hardware Monitoring
SOC Support for Hosts and VMs
Raw Configure In Place of IM
Windows 2008 Socket Exception
Inconsistent Data for Memory Shared Metric
Passive Robot
IPv6 Support
Trappable Stack Trace in Log File
Appearance of VMs in USM
Errors with Polling Intervals under 20 Seconds
Collection Times are Extremely Slow
Probe Values Don't Match the vSphere Client
For Event Monitors, All Events are Coming Across as Part of a Single Alarm
Limited Multibyte Character Support
QoS Data Fails to be Submitted into the SLM DB
State of ESXi host services out of date
Known Issues and Workarounds for Infrastructure Manager Users Only
No Value is Listed for a Monitor
Out of Memory Errors
Error When Closing the Configuration GUI
UI Fails to Load Auto/All Monitors Nodes
UI Slowly Loads Nodes Within the Inventory Tree
Revision History
Version
Description
State
Date
6.60
What's New:
Added support for VCenter and ESX 6.0.
Target strings are changed for host metrics of type HOST_SYSTEM. Target strings for HOST_SYSTEM are found
under the System node on hosts and are named "host/system/kernel." For example, the old target string was:
"Resource CPU Usage in Mhz (% of Mhz*NumCpuCores)". The new target string is "host/system/kernel/Resource CPU
Usage in Mhz (% of Mhz*NumCpuCores)."
Fixed Defects:
Fixed an issue in which, if a message pool identification name included an underscore, the high and low threshold
status display order was reversed. Salesforce case 00168994
Fixed an issue in which, if a metric was disabled in Infrastructure Manager, it was not disabled in Admin Console. Sales
force case 00169165
Fixed an issue in which the probe was inconsistent in which name it used to identify the source for a QoS message. Sal
Fixed an issue in which, for certain alarms, the device ID incorrectly displayed as the default connector. Salesforce
00170025
Fixed an issue in which, for users with CA UIM v8.0-8.1, the Unified Dashboards for VMware were missing QoS that
were collected by the probe. Salesforce case 00154590
Fixed an issue in which the probe did not send device ID in alerts through the CA UIM Connector for CA SOI. Salesforc
e case 00170025
Fixed an issue in which the template editor in Admin Console offered a superfluous option to apply a log level filter.
Fixed an issue in which the probe stopped generating QoS messages after running continuously for one day.
Fixed an issue in which a MissingTargetException occurred.
Fixed an issue in which, when running on a Windows 2008 server with a socket leak, the probe displayed the following
error message: "Java.net.SocketException: No buffer space available."
Fixed an issue in which, when the user was using Japanese characters, the QoS source and target were garbled when
they were stored in the database.
GA
October
2015
6.53
What's New:
Added support to configure and apply all monitoring, manually or with templates, in Admin Console
Added documentation about how to format IPv6 addresses when used for a Uniform Resource Identifier (URI); use the
Java convention of enclosing an IPv6 address in square brackets.
For more information, see the v6.5 vmware AC Configuration and v6.5 vmware IM Configuration guides.
Added new monitors to the datastore resource:
number read averaged
number write averaged
number read rate
number write rate
Added the ability to monitor a datastore disk, including the following monitors:
number read rate
number write rate
Added the ability to monitor a datastore under a host, including the following monitors:
number read rate
number write rate
total read latency
total write latency
Added the ability to monitor a datastore under a vm, including the following monitors:
number read rate
number write rate
total read latency
total write latency
For more information about these metrics, see vmware Metrics.
Fixed Defects:
Fixed an issue in which QoS monitoring configurations were lost when the user password changed. Salesforce case
00162857
Fixed an issue in which delta values were incorrectly calculated.
Fixed an issue in which the numeric sensor monitor was not updating the power supply status. Salesforce case 001556
26
Fixed an issue in which automonitors using the value average*n did not work. Salesforce case 00160619
GA
August
2015
6.41
What's New:
GA
March
2015
Added Admin Console GUI element: the Detached Configuration folder in the left-hand navigation tree for the probe
displays resources that have been deleted in the VMware vSphere and which still have configuration in the probe.
Added monitoring of Distributed Virtual Port Groups and Switch.
Added support for monitoring the same VCenter with multiple credentials.
Added support for using non-English characters in the following fields: template name, template description, message
name, message error text, message OK text, and alarm thresholds.
Enabled the probe to indicate to baseline_engine (or other probes performing a similar computational function) to
compute baselines, publish QoS data to the message bus, and publish alarms when configured alarm threshold criteria
is met.
Improved discovery time and HEAP memory usage.
Fixed Defects:
Fixed an issue in which, when using two user profiles with different permissions on the same ESXi host, incorrect
credentials were set on both resources and both resources monitored the same set of objects from the vCenter. Salesfo
rce case 00152061
Fixed an issue in which, when monitoring numeric sensors on ESXi hosts, the profile did not work and the tooltip
displayed an "unable to connect" error message.
Fixed an issue in which, when monitoring QoS metric for host service availability, the service description was missing
from the CI naming.
Fixed an issue in which internationalization (translation from English) caused the QoS source/target text to be garbled
when it was stored in the database.
6.30
Corrected an issue with value updates for HOST_SERVICE metrics.

Improved the loading time of All Monitors and Auto Monitors content in Infrastructure Manager GUI.
Improved monitor processing logic to reduce polling intervals.
Performance metrics are now visible in the GUI whether or not monitoring is enabled.
Reduced memory footprint by modifying internal representation of objects.
Reduced polling interval time by creating thread calls to collect vCenter performance metrics.
GA
December
2014
6.12
Added support for migration to current release from 4.01 and forward.
All group names are localized in Probe Configuration.
Corrected an issue where non-clustered VMware server instances are falsely reported as a vCenter.
Fixed default messages that reported "memory" instead of "network."
GA
July 2014
Fixed incorrect QoS target name format for Guest Disks: QOS_DISK_FREE //Free (in % of Capacity) is correct;
QOS_DISK_FREE GuestDisk///Free (in % of Capacity) was incorrect.
6.10
Added requirements for VMware VirtualCenter 5.5 and VMware ESX/ESXi 5.5
Described appearance of VMs in USM.
Support for IPv6 environments.
Restored VMwareApiAvailable metric
GA
March
2014
6.01
Fixed: Monitoring alarms on multiple vCenters could cause a collection failure.
GA
December
2013
6.00
Performance enhancements
Support for VMware 5.5
Fixed: Provisioning VMs could cause spurious duplicate UUID alarms
Fixed: Expiration of the probes session with vCenter triggers spurious duplicate UUID alarms.
Beta
December
2013
5.10
Probe fails to detect new VMs on 5.1 update 1

Provisioning VMs trigger false duplicate UUID alarms
Monitors of 'average of last n' do not display values in 'All Monitors'
GA
October
2013
5.03
Reintroduce source_is_ip support

Use a new method of event collection that works for all ESXi hosts.
Fix API response time calculation
Improve displayed error message when communication with the controller fails.
GA
June 2013
5.02
Mouse-over tool-tips on resource nodes to provide additional context

Fixed creation of devices visible to USM
GA
May 2013
5.01
Rewritten backend and GUI

Alarm forwarding support
Storage Pod and Virtual App monitoring
Cluster VMotion monitoring
March
2013
4.20
Probe help button now accessing online Help Resource site

Performance metric auto-monitors are no longer created for entities missing the performance metric
Memory and CPU performance metrics added to Resource Pools
Corrections around the creation of Remote Device details for SOC niscache content
Host Virtual Switch ports and available ports metrics added to Hosts entity
Added (optional) support for including DataStore containing folders in the QoS Target
Active Template highlighting during drag-n-drop fixed
Template copy operation is now supported
June 2012
4.11
Corrected Resource Pool QoS target strings for uniqueness

Corrected Auto-Monitor wildcard instance QoS target strings
Corrected QoS target string for Auto to Static Monitor conversions
March
2012
4.03
Polling interval alarms are now cleared when the collection cycle takes less time than the configured interval.
Target string corrected for DS, Cluster, and Network auto-monitors created from static monitors.
Target string corrected to contain topology path for Resource Pools and Networks.
Corrected the robot dependencies setting in the VMware probe package.
Restored missing VM Memory usage metric in the inventory tree.
Corrected reported FM snapshot size.
Added supported for tracking VMs by instanceUUIDs for environment with duplicated UUIDs (e.g., Lab Manager & vCloud)
January
2012
4.02
Updated the UMP Metrics template to match the latest Dashboard content
December
2011
4.01
Augment QoS source to optionally include origin for multi-tenant setups.

Fixed missing scenarios around converting auto monitor to static monitors.
Any static monitor now takes precedence over auto monitors.
November
2011
4.00
Added support for SOC management of Hosts, and VMs with VMTools installed.
Corrected target naming for Datastores contained within folders.
Fixed enabling of static monitors for the Top Level API monitors
October
2011
3.53
Fixing failures around calculation process for missing Network Metrics
June 2011
3.52
Adjusting QoS entries in support OOB Dashboards.
June 2011
3.51
Fixed millisecond to percentage calculations for CPU performance metrics
June 2011
3.42
Fixed auto-monitor behavior around wildcarded monitors (e.g., Services, CPUs, CpuStatusInfo, Disks, etc.).
StorageStatusInfo, CpuStatusInfo, MemoryStatusInfo and NumericSensorInfo monitors how support wildcarding in
auto-monitors and templates.
Probe allows for ESX Hosts vnic property to not be set.
May 2011
3.41
Status monitor supported for Network Switches.

Summary level monitors are supported for Clusters.
Top level disk latency is now reported as an average.
Booleans are converted to integers to enable QoS submittal.
Correcting CPU performance metrics to report in terms of per CPU Average
May 2011
3.40
Maintenance release that includes additional message types and QoS entries.
March
2011
3.31
Corrected target resolution process for submitted QoS and Alarm messages
March
2011
3.30
Probe startup process has been migrated to the standard controller mechanism.
resource alarms are now sent for unavailable resources.
Additional CPU and Memory metrics.
Configuration UI and probe performance improvements.
Corrected the source for Resource Pool AutoMonitors.
Updated the UMP metrics template monitor Memory Grants.
Deleting all monitors via Applying Templates is no longer supported. Please use the "all Monitors" section to select and
delete all monitors (e.g., select the first monitor, then use the CTL+SHIFT+END shortcut to select all, then finally use the
context menu's delete to perform the delete).
Warning level Alarm is now emitted when the data collection time for a resource is greater than the polling interval.
The probe now substitutes calculated values for Network Metrics missing/unavailable on some ESX servers (e.g., latest EXSi
4.1 Servers). When substitute values are used, the probe logs a warning message in the log file.
Correct Source As IP behavior with Template deployed monitors.
March
2011
3.29
Fixed Event Monitors.

Updated the defaults for the VM Guest Memory Monitor.
Updated the UMP Metrics template monitors around Datastores and Guest Memory.
February
2011
3.28
Added support for pulling PowerState metric from Hosts.

Incorporated best match processing for handling name changes occurring with StorageStatusInfo, CpuStatusInfo,
MemoryStatusInfo and NumericSensorInfo monitors. In cases where the probe has to perform a best match, the probe logs a
warning message in the log file.
February
2011
3.27
Fixed enabling Datastore Monitors from Config UI's List View.

Templates can be used with Datastores with both Auto-Monitors and Monitors.
Enabled Drag and Drop of Templates to Datastores directly.
VMware API Auto-Monitors at the Resource level now work
Corrected error recovery / handling around VMware session timeouts
Config UI's browse hierarchy properly reflects the state of performance based Auto-Monitors.
NumericSensorInfo reporting is now disabled by default
Fixes were made to Memory percent based metrics
Metrics added for reporting VM Template state and tallying the count of Non-Template VMs
December
2010
3.26
Corrected behavior around disabled monitors.
November
2010
3.25
Corrected behavior around sending clear alarms for monitors.

Fixed target for datastore auto monitors.
Fixed checkbox for host monitors.
November
2010
3.24
Handle error when some hosts have a null datastore
October
2010
3.23
Fix metrics that don't display properly in the GUI when a host name is not resolvable.
October
2010
3.22
Fix auto configuration matching defect that caused auto monitors to match non-running VMs
Fix session timeout defect that caused null data when long intervals were used
Retry queryAvailablePerfMetrics since it sometimes fails
September
2010
3.21
Allow IP address as source for auto monitors

Fix string threshold editing defect
September
2010
3.20
Added VMware API availability and response time metrics

Added SnapshotCount and SnapshotSize metrics for VMs
Added default auto configurations for new resources
Performance improvements
August
2010
3.10
Scale improvements
NIS2 enabled
April 2010
3.02
Removed limitation on number of resources

Added login-only check for resources without monitors
Use language-independent exception handling
Fixed NullPointerException when the array of objects returned by the server (by one of the getArrayOf methods) is null
November
2009
3.01
Fixed problems with VMWARE subject detection and reconnection after connection to server is lost.
September
2009
3.00
Added support for additional measurement points for vSphere 4

Added support $ip tag in messages
Added support for automatic upgrade to vSphere 4 (if possible) using Ctrl-U
June 2009
2.73
Fixed CPU key in default template
February
2009
2.71
Corrected error when connecting to VC/ESX
February
2009
2.70
Added support for CPU, Disk and Network instance performance monitoring.
Added the possibility to average a monitor point over the 2-5 last measurements.
Optimized start-up time for configurations with many active resources.
Added sortable column of alarm severities.
Fixed deployment of templates in clustered environments.
Fixed potential GUI issues when probe is about to restart.
December
2008
2.55
Added support for resource alarms to queue.
October
2008
2.54
Added fixed connect timeout
October
2008
2.53
Removed possible performance collection error after a monitored VM is removed.
October
2008
2.52
Removed sending alarms when only QoS active
October
2008
2.51
Removed hang when a resource was unavailable
October
2008
2.50
Added support for two alarm levels.

Added support for auto configuration.
September
2008
2.20
Added the possibility to route alarms to logmon queue.

Added the possibility to add the DNS name (if available) to an alarm ($dns tag).
Added possibility to define Datastore, GuestDisk and Service checkpoints in Templates.
Added possibility to delete all existing checkpoints when a template is deployed.
Added "Add to template..." menu option.
Added "Deploying templates" status window.
Java 1.6 is supported.
June 2008
2.10
A number of new measurement points are added.

Improved GUI performance.
Automatic refresh of GUI may be turned off (use F5 for manual refresh).
A number of icons are changed.
The VM icons reflect the run-state and configuration-state of the VM.
A template may be dropped at any level (supports VM, Host and Resource Pool checkpoints).
Removed "Create Template" / "Apply Template" menu options on VM's.
Added support for Events in templates.
Removed list of checkpoints in template creation process (only drag and drop is supported).
Java 1.5 is supported.
Technical upgrade.
April 2008
2.08
Upgrade libraries
October
2007
2.07
Fixed login
August
2007
2.06
Changed handling of monitor IDs
August
2007
2.05
Fixed templates
June 2007
2.01
Fixed QoS target and source
April 2007
2.00
Added support for infrastructure 3 (VirtualCenter 2.x and ESX 3.x)

Added template support
Changed GUI icons
March
2007
1.16
Changed startup script to support Solaris
December
2006
1.15
Improved certificate handling
November
2006
1.00
Initial version
September
2006
Probe Specific Application Requirements

The probe requires user account access to the following applications:
User access to the VMware vCenter or ESX server.
Successful distribution of the probe package relies on the Java package installed with the CA Unified Infrastructure Management server.

The probe supports monitoring for the following vSphere environments:
v6.6 and later:
VMware VirtualCenter 5.1 update 2 or newer, 5.5, and 6.0
VMware ESX/ESXi 5.1 update 2 or newer, 5.5, and 6.0
v6.1 and later:
VMware VirtualCenter 5.1 update 2 or newer, and 5.5
VMware ESX/ESXi 5.1 update 2 or newer, and 5.5
v6.0 and earlier:
VMware VirtualCenter 4.1 update 1 or newer, 5.0, 5.1, and 5.5
VMware ESX/ESXi 4.1 update 1 or newer, 5.0, 5.1, and 5.5
Important! The probe requires targeted vSphere environments to use unique UUIDs. This means that when cloning virtual machines
(VMs), each clone must have a distinct UUID in order for proper monitoring to occur. If each VM does not have a unique UUID,
incorrect data will be reported for the VMs.

Memory: 2-4 GB of RAM. The probe as shipped requires 512 MB of RAM.

To use all of the features available for v6.41 and later, including configuration of the probe in the Unified Management Portal (UMP) and the
Admin Console (AC) portlet,
CA Unified Infrastructure Management v8.2 or later is recommended.
The probe requires the following minimum software environment:
Note: It is recommended that the CA Unified Infrastructure Management server and CA Unified Management Portal (UMP) are the
same version. To check the version number for Unified Management Portal (UMP), enter html/version.txt in your browser address
bar, after the UMP IP/ or hostname/. For example:http://<UMP_Server_name_or_IP_adress>:/html/version.txt. When you do this, a
page displays the Version, Build Label, Build Date, and Build Number.
CA Unified Infrastructure ManagementRobot version 5.23 or later.
Java Virtual Machine
vmware versions 6.53 and later: Java Virtual Machine version 1.7 package or later (deployed as part of the probe package).
vmware versions up to 6.51: Java Virtual Machine version 1.6 package or later (deployed as part of the probe package).
Note: CA Unified Infrastructure Management server 7.0 or later version is required to use the Unified Service Management (USM)
portlet, which most customers use. If you do not want to use USM, data collection and dashboards function with CA Unified
Infrastructure Management5.1.1 or later.
Microsoft .NET framework 3.5 on the system running the probe.
Note: Microsoft .NET framework 4.0 or later is not supported. To determine your version, go to the Microsoft documentation and search
for "How to: Determine Which .NET Framework Versions Are Installed."
For Infrastructure Manager users:

Infrastructure Manager 4.08 or later.
Microsoft .NET framework 3.5 on the system running the probe.
Note: Microsoft .NET framework 4.0 or later is not supported. To determine your version, go to the Microsoft documentation
and search for "How to: Determine Which .NET Framework Versions Are Installed."
The probe requires the following type of account access to the VMware environment:
Read access on all monitored entities
The following sections apply to users accessing the probe configuration GUI using CA Unified Infrastructure Management Infrastructure Manager
or Admin Console.
Upgrading from v6.41 to v6.50

Versions 6.41 and later include support for configuring and applying monitoring with templates in Admin Console.
When you apply monitoring with templates in v6.41 and then upgrade the probe to v6.50, any Admin Console templates (and their filters, rules,
and monitors) that you have configured are saved and included in the upgraded probe.
Any monitors that are new in v6.50 are added to all relevant Admin Console templates, including templates that were configured in v6.41. The
new monitors are available but turned off by default.
Note: Active default templates are upgraded automatically when you upgrade the probe. Any new or deprecated filters, rules, and
monitors, in the latest version of the active default template are applied automatically as part of the upgrade process. If you want to
save the monitoring configuration of your current active default template and to prevent them from being overwritten when you upgrade
the probe, copy the active default template, rename it, and apply this renamed copy before you upgrade the probe.
Upgrading from earlier versions to v6.41 or later

Configuring and applying monitoring with templates in Admin Console is possible for only v6.41 and later.
If you upgrade to v6.41 or v6.50 from an earlier version of the probe, and want to apply monitoring with templates, you must first delete any
previous configuration. You can then enable bulk configuration, which enables configuration only through Admin Console and disables
Infrastructure Manager. Because of this, we recommend that you delete probe versions earlier than 6.41 and deploy a new v6.41 or later probe.
If you want to configure the probe using only Infrastructure Manager, you can upgrade from an earlier version to v6.41 or later without deleting
any previous configuration. However, not all features of v6.41 and later are supported in Infrastructure Manager.
Note: If you are upgrading from v4.23 and want to retain your configured monitors, we recommend upgrading to v6.50 because of its
improved upgrading performance.
Unified Dashboards or Summary Views in UMP

The probe version 5.01 and later requires you to update to the default preconfigured VMware List Views provided under Unified Dashboards or
Summary Views in UMP. Any existing VMware list views may show blank data in some list views.
See the following steps to resolve the dashboard or List Views issues:
Apply the UMP Template provided with the probe (or manually update your monitors to reflect the content in the UMP Template), and
Use the List Views provided with the latest version of UMP. Alternatively, you can go to the support site and obtain the updated List
Views that are compatible with version 5.01 of the probe. Please refer to the forums for information on obtaining this content.
Migration
Migration from 4.2x versions of the probe is supported, but with important caveats. Please read carefully if you intend to perform migration.
CPU Extra (% of available) and CPU Guaranteed (% of available) were both removed from the VMware API after ESX 3.5. They have
been removed from the probe.
VMwareApiAvailable has been removed as a monitorable metric in versions 5.01 to 6.01. A self-monitoring alarm has replaced it.
This functionality was restored in version 6.10 and may be used in addition to the self-monitoring alarm.
Reservation (vm) was a duplicate of the monitor CPUReservation. To avoid confusion, reservation has been removed.
Host metrics VMNonTemplateCount, VMNamesActive, and VMNames were all intended for an abandoned feature. They have been
removed.
ToolsStatus (deprecated) was deprecated for a release and is now removed.
TemplateState has been removed in favor of having fully distinct type for VMs and templates. Static monitors that were created against
entities reclassified from VM to template will need to be recreated.
Attempting to migrate any of these monitors will result in alarms for each during every polling cycle.
The original configuration file is automatically backed up in the probe installation directory.
Any of CpuStatusInfo, MemoryStatusInfo, or NumericSensorInfo that were manually enabled in the old probe will need to be enabled in
the new probe by editing the 'mondef.cfg' file.
The 5.x versions of the probe use more memory. If you were close to the memory limit on the previous version of the probe, it is very
likely you will need to increase the available memory.
Considerations for the VMware Web Services API

The probe relies on the VMware Web Services API for data collection. All data is collected using exclusively read-only operations (the probe
never makes update or write requests to the environment).
Considerations for Viewing Information in USM

Additional steps are required to view VMware consumption metrics and information in USM. Note that the VMware-specific information displayed
in USM varies depending on the VMware system--vCenter, host, or virtual machine.
For CA Unified Infrastructure Management
1. In Infrastructure Manager, apply the UMP Metrics template to the system.
Note: This step enables the majority of the monitors required for viewing VMware information in USM. However, to view all of
the VMware specific information available, you must also perform the next step.
2. Select the Publish Data check box for the following monitors:
Lists for Hosts and vCenters
Top 5 Resource Pools - CPU
CPUOverallUsage
Top 5 Resource Pools - Memory
MemoryOverallUsage
Top 5 Data Stores - Capacity
Capacity
Top 5 VMs - Memory
GuestMemoryUsage
vCenter Properties
Storage vMotions
Num Storage VMotions
VM vMotions
Num VMotions
Total Memory
TotalMemory
Total CPU
TotalCPU
Lists for vCenters

Top 5 Hosts - CPU
TotalCPU
Top 5 Hosts - Memory
OverallMemoryUsage
Best Practices
This section contains general best practices for using the probe. See the documentation for your version and configuration interface for further
best practices specific to your situation.
Performance
The default settings should be sufficient performance for most environments. The following items can affect performance:
The number of resources targeted

The API response time of the targeted environments
The number of monitors
Polling frequency
If the probe is not able to keep up, it will send an alarm indicating that the collection process is taking longer than the polling interval. In general
CA recommends keeping the polling interval at 10 minutes or longer. If you are still seeing problems even with a higher polling interval, consider
doing one or both of the following:
Increase the polling interval. If the probe is not experiencing memory issues, change the polling interval to allow for the fetching and
processing of data from the targeted VMware environment.
Increase the amount of maximum memory. Do this only if you see evidence that the probe has insufficient memory (verify using either a
JVM monitoring tool or through the info call-back).
Also be aware that on start up or as part of configuring against a new resource, the start up of the probe may take several minutes (depending on
number of VMs in the Virtual Center).
Optimizing Memory for the Probe

On large installations with many checkpoints, you may need to adjust the memory settings in the probe configuration to optimize probe
performance. There are two good indicators you can examine:
See if the log file contains out-of-memory errors; if present, you should consider making an adjustment.
Check the process size; if it is reaching the configured Java Virtual Machine memory limit, you should consider making an adjustment.
Use the Raw Configure tool to adjust the memory available to the probe. A good rule is to use 1000 Mbytes of memory for each 1,000 VMs that
you are monitoring. For example, to set the startup heap size to 1000 Mbytes, proceed as follows:
1. In Infrastructure Manager, press SHIFT, then right-click the probe.
2. Select Raw Configure from the context menu.
3. Add or change the following entry in the startup section:
Key: options
Value: -Xms32m -Xmx1000m
Note that the entry is case sensitive.
IMPORTANT! The Raw Configure tool has no error checking. Take care that any changes you make are valid before you
continue.
Hardware Monitoring
Note: This topic applies to users accessing the monitoring configuration GUI using CA Unified Infrastructure Management Infrastructure
Manager or Admin Console.
The probe provides numerous virtualization monitoring metrics and alerts for performance and availability of the VMware environment through the
VCenter and ESXi web services APIs. The VMware APIs also provide metrics for the underlying server hardware that runs the ESXi hypervisor.
The probe collects most of these server hardware monitoring metrics. The metrics available are limited by the data provided by the VMware APIs.
The metrics also differ in coverage and accuracy depending on the server hardware.
Therefore, we recommend using other CA Unified Infrastructure Management probes for server hardware monitoring, especially SNMP-based
probes such as snmptd. As a best practice, use the snmptd probe to catch traps due to fault or damaging events from the underlying server
hardware device that runs the ESXi hypervisor. Follow the instructions provided by VMware or the server hardware vendor to enable SNMP on
the server hardware device. To configure the CA CA Unified Infrastructure Management snmptd probe, see the probe documentation or contact
support for assistance.
Alternatively, the probe can forward alarms from the vCenter. Configure appropriate hardware alarms in the vCenter, and turn on alarm monitors
for the related devices in the probe to forward any triggered alarms.
SOC Support for Hosts and VMs
Note: This topic applies to users accessing the probe monitoring configuration GUI using Infrastructure Manager or Admin Console.
Starting with v4.0, the probe supports configuration through Service-Oriented Configuration (SOC). Please be aware of the following behaviors
when using the probe with SOC:
Configuring a connection to a vSphere resource is performed through the Probe UI.
Template Groups for VMs or Hosts can be formed by using the dedicated setting. For VMs, the field is VirtualMachine; for hosts, its
HostSystem.
The probe will do an initial discovery of manageable Hosts and VMs and populate this content to the local robots niscache for Discovery
Server processing.
When using SOC, the probe will monitor its configuration file for changes. When a change has been noticed, the probe waits for a 5
minute quiet period before restarting.
Configuration of the probe must be done through the Probe UI or SOC exclusively. Attempting to manage a probe through both
mechanisms at the same time will result in collisions within the configuration.
Only Virtual Machines with VMtools installed can be managed by SOC. All Hosts can be managed by SOC.
Upgrading and conversion to SOC of an existing probe setup may disrupt expected data collection as a side effect of the SOC
configuration over writing pre-existing configuration.

Raw Configure In Place of IM
Symptom:
I launch the IM GUI, but get the Raw Configure dialog instead.
Solution:
Install .NET 3.5 on the system. If you install .NET 3.5 after launching the GUI, you may also need to restart the robot.
Windows 2008 Socket Exception

Symptom:
I deployed the probe on a Windows 2008 server. And I see the following exception in the log file: " java.net.SocketException: No buffer space
available (maximum connections reached?): connect".
Solution:
Apply the hot fix for a socket leak on the Windows 2008 server.

Symptom:
Solution:
Inconsistent Data for Memory Shared Metric

Symptom:
Probe returns inconsistent data for the Memory Shared (% of MemorySize) metric.
Solution:
v6.21 and 6.30:
1. Go to the vmware.cfg file.
2. In the vmware.cfg file, search for:
Memory Shared (% of Memory Size).
3. Replace every instance of Memory Shared (% of Memory Size) with:
Memory Shared (% of Memory)
IMPORTANT: The Raw Configure tool has no error checking. Take care that any changes you make are valid before you
continue.
Note: If you have any templates configured to monitor Memory Shared (% of Memory Size), you must also change the metric
within the template to read Memory Shared (% of Memory).
v6.4 and later:

In the probe configuration GUI, delete any auto and static monitors for Memory Shared (% of Memory Size). Recreate the monitors.
Passive Robot
Symptom:
When configuring a probe deployed on a passive robot, you see an error message:
Configuration was unable to be retrieved.
Message: Request Error: Probe vmware on robot...passivehub is busy.
Resolution: Please wait and retry loading configuration later.
Error Code: PPM-023
Solution:
You can ignore the message. The hub will retrieve configuration information from a probe deployed on a passive robot the next time that the
hub_update_interval has elapsed.
Or, if you want to decrease the time it takes for a hub to retrieve configuration information from a probe deployed on a passive robot, decrease the
hub_update_interval from the the default value (900). For more information about how to configure a hub with a passive robot, see the hub guide
on the CA Unified Infrastructure Management wiki.
IPv6 Support
Symptom:
Solution:
Symptom:
When using probe v6.10 or later, IPv6 addresses are not shown in USM for CA Unified Infrastructure Management 7.0 or 7.1.
Solution:
Upgrade to CA Unified Infrastructure Management 7.5.
Symptom:
Infrastructure Manager UI fails for IPv6 only robot host
Solution:
The Infrastructure Manager user interface for the probe will fail to display when the robot hosting the monitor is hosted on an IPv6 only network.
The workaround is to provide IPv4 access to the robot host.
Trappable Stack Trace in Log File

Symptom:
When I turn on the VMWare API Available monitor, I get a null pointer exception and a stack trace in the log.
Mar 27 17:28:51:807 [pool-3-thread-1, vmware] Failed to build collectio

n request for monitor "ESC:RESOURCE:138.42.229.17"."VMwareApiAvailable"
Mar 27 17:28:51:807 [pool-3-thread-1, vmware] java.lang.NullPointerExce
ption
Solution:
Ignore this error, data is still collected correctly.
Appearance of VMs in USM

Symptom:
This issue applies to probes prior to v6.0. Machines with VMtools installed will appear as independent VMs in USM. Machines without VMtools
installed will appear as children of the containing hypervisor.
Solution:
Either install or uninstall VMtools as needed from your machines to control your view of VMs in USM.
Errors with Polling Intervals under 20 Seconds

The probe configuration GUI allows polling intervals of less than twenty seconds to be requested. However, the VMware software only makes
metrics available with a resolution of twenty seconds. Attempting to poll more frequently than twenty seconds will result in errors.
Collection Times are Extremely Slow

Symptom:
In any size environment, the total collection time is high, particularly the time to Execute request for perf metrics (visible in the log file). The time
to collect may drop noticeably overnight, or during times of light load on the vCenter.
Solution:
This is generally due to a bottleneck accessing the vCenter database. You should investigate the source of the congestion, which could be
memory, CPU, disk or database access, or another resource that is insufficient at peak load.
Users accessing the probe monitoring configuration UI via Infrastructure Manager can also disable collection of metrics that rely heavily on
database operations. To do this, use Raw Configure to set the 'include_summary_perf_metrics' key to 'no'.
IMPORTANT: The Raw Configure tool has no error checking. Take care that any changes you make are valid before you continue.
Probe Values Don't Match the vSphere Client

Symptom:
Comparing values in the database or probe configuration GUI displays different values than appear in the vSphere Client.
Solution:
Numerous data bugs in the API were fixed in the 4.1 updates. Therefore, if you're running ESXi 4.1 pre-update 1, update your ESXi version.
Otherwise, investigate the VMware 'managed object browser'. It will allow you to view many of the values as VMware exposes them via its API.
Additionally, we aggregate many values over the configured collection period, so displayed values may not match the most recent value displayed
in vSphere.
For Event Monitors, All Events are Coming Across as Part of a Single Alarm
This behavior is as designed.
Limited Multibyte Character Support

Inventory items with multibyte names can be displayed, but static monitors cannot be created for these entities. Additionally, user input fields do
not support multibyte characters.
QoS Data Fails to be Submitted into the SLM DB

Symptom:
The system is successfully submitting QoS messages (for example, observed via Dr Nimbus), but the data is not persisted in the SLM
database. In addition, the data_engine log entries indicate that the message was rejected due to a conflict in the QoS definition (log level 3).
Solution:
This occurs when there are discrepancies in how QoS definitions are defined. The probe has unique QoS definitions available for every metric.
Select the appropriate unique QoS to avoid the conflict.
State of ESXi host services out of date

Symptom:
If I use the ESXi hypervisor console to manually shut down services instead of using the vSphere Client, VMware does not update the ESXi
server status reported to the probe.
Solution:
Do the following:
1. Make sure you have administrator privileges and a 6.12 or later release of the probe.
2. Click Raw Configure on the context menu.
The probe Raw Configure window opens.
3. Click the setup section.
The Keys and Values for the setup section are displayed in the right pane.
4.
4. Select Add key.

The Add key dialog opens.
5. Enter "force_services_refresh" and click Add.
6. Click in the Value column for the "force_services_refresh" Key, enter "true" for the Value, and press Enter.
7. Click Apply.
Known Issues and Workarounds for Infrastructure Manager Users Only

This section describes some known issues and workarounds that apply only to users of the Infrastructure Manager interface for configuring the
probe.
No Value is Listed for a Monitor

Symptom:
When I click on a Resource component in the navigation pane, some monitors have no value listed in the Value column in the content pane.
Solution:
This is expected behavior. Some monitors for the probe take a while to collect. For these monitors, the current value is not displayed unless the
monitor is activated (the check box is selected). To see the current value for a monitor, select the check box. The value is collected during the
next polling cycle, even if QoS and alarming are not enabled.

Symptom:
Out of memory or garbage collection errors in the log file.
Solution:
If you have more than several thousand monitors (or entities) in the probe, you may need to increase the heap space for the probe. Heap space is
allocated during probe startup. By default the heap space for the probe is 512 MB.
You can increase the heap space setting for the probe in the Raw Configure window for the probe.
Follow these steps:
1. Shift + right-click on the probe in Infrastructure Manager.
2. Choose Raw Configure from the menu.
3. Click startup in the left pane.
4. Select the options key and open it for editing.
5. Enter a value similar to the following:
-Xms256m - Xmx<nnnn>m
where <nnnn> is heap space up to 2048 MB or greater. For example,
to increase the heap space to 1024 MB, enter the following:
-Xms256m - Xmx1024m
Ensure the machine where the robot and probe are deployed has enough RAM.
6. Click OK and Apply.
Error When Closing the Configuration GUI

Symptom:
I get a Windows error dialog when I attempt to close the configuration GUI.
Solution:
If the configuration GUI has been open for an extended period of time, the probe will not automatically release its lock on the configuration file (if
configuration file locking is enabled). This will only occur if the GUI is left open for periods longer than controller-configured session expiration time
and the 'Cancel' button or 'X' button are used to close the GUI.
The error is harmless and can safely be ignored.
UI Fails to Load Auto/All Monitors Nodes

Symptom:
In environments with many active monitors, the UI may fail to load the list of monitors into either the Auto Monitors or All Monitors nodes. The
issue begins occurring when the monitor count is greater than 40,000 and the UI begins to exhaust memory.
Solution:
There are no workarounds for this problem. Avoid accessing these node in such environments. If you need to see and manage a particular set of
monitors - you can temporarily disable other static and auto-monitors to reduce the monitor count, and then work from there.
UI Slowly Loads Nodes Within the Inventory Tree

Note: This topic applies to users accessing the configuration GUI using CA Unified Infrastructure Management Infrastructure Manager.
It does not apply to Admin Console users.
Symptom:
In environments with a large inventory, the UI may take several minutes to load content within the Inventory Tree. For example, for a vCenter with
10,000 VMs - loading the VMs will take several minutes.
Solution:
Where possible, avoid navigating to such nodes. In the example of the VMs node, try finding the VMs under the hosting HyperVisor as opposed
to relying on the VMs node.
vplex (EMC VPLEX Monitoring) Release Notes

EMC VPLEX provides local or distributed federation within a single data center, or between two clusters within synchronous or asynchronous
distances.
The EMC VPLEX Monitoring (vplex) probe remotely monitors the performance, throughput and response time of VPLEX systems. The probe
enables you to connect to the VPLEX server and discover VPLEX components to be monitored. You can define alarms that are generated when
the specified thresholds are breached. For example, you can check the latency of front end and back end ports in a single VPLEX engine. Based
on the configured parameters, the probe generates Quality of Service (QoS) metrics. Refer to vplex Metrics to understand the monitoring
capabilities of the probe.
The probe uses the following two methods to connect to the VPLEX system and monitor entities:
Using Representational State Transfer (REST)ful web services API.
Downloading perpetual logs from the VPLEX server to the local robot where the probe is deployed.
The vplex probe can monitor the following VPLEX components:
Clusters
Local Devices
Ports
Engines
Directors
Back End Ports
Cache Memory
CPU
Fibre channel (FC) COM Port
Front End Ports
IP
Memory
Storage volume
Virtual volume
Note: You can configure the probe through Admin Console only.
The probe includes the standard static alarm threshold parameters using CA Unified Infrastructure Management 8.2 or later.
Revision History
EMC VPLEX Supported Versions
Revision History
Version
Description
State
Date
1.00
What's New:
GA
December
2015

The probe configuration is available ONLY through Admin Console GUI and NOT through the Infrastructure
Manager (IM) GUI.
EMC VPLEX Supported Versions

The probe is certified on EMC VPLEX version 5.4 Local and Metro modes.

The vplex probe must be installed on systems with the following minimum resources:
CPU: 3-GHz dual-core processor 32, or 64 bit.

The vplex probe requires the following software environment:
Unified Dashboards version 2.96 or later
Install and deploy the ci_defn_pack version 1.16 probe on the primary hub robot (with the nis_server probe) to view the metrics on the
USM portal. You must restart the nis_server after you deploy the ci_defn_pack.
Install the mps_language_pack probe version 8.38 and later to view the metric type on the Admin Console. You must restart the service
_host probe after you deploy the mps_language_pack.
webgtw (Web Gateway) Release notes
The web gateway (webgtw) probe automatically transfers customer billing reports to CA Technologies. This helps customers fulfill their probe
usage reporting obligations by eliminated the need to manually email the reports.
Revision History
Version
State
Date
8.00
Initial release of webgtw.
GA
September 2014
weblogic (Weblogic Monitoring) Release Notes

The Weblogic Monitoring (weblogic) probe collects and stores data and information from the monitored WebLogic server at customizable
intervals. You can define alarms to be raised and propagated to CA Unified Infrastructure Management when the specified thresholds are
breached.
Notes:
For WebLogic 9 and 10, the IIOP needs to be enabled on the WebLogic server. For more details, please refer to the section "Enable IIOP
on the WebLogic Server" in the probe help document.
Older versions of the probe cannot be upgraded to version 1.3x.
Contents
Revision History
Revision History
This section describes the history of the revisions for the weblogic probe.
Version
Description
State
Date
1.41
What's New:
GA
June 2014
GA
March 2014
Added support for monitoring the WebLogic server using Secure Socket Layer (SSL).
1.35
What's New:
Added support for jre 1.7x.
Fixed Defects:
Fixed an issue of generating duplicate QoS for the same monitor.
1.34
Fixed Defects:
GA
January 2014
Fixed an issue in which the probe disconnected every time the server restarted.
Fixed an issue in which the metrics were appearing without a value.
1.33
Added support for WebLogic version 12c.

Fixed: Duplicate profile generation in resources.
GA
January 2013
1.32
Enabled SSL communication between NMS components
GA
December 2011
1.31
Added extra arguments for probe startup in package file.

Added support for weblogic version 11g.
Added new mechanism of Mbean handling.
Added i18n and TNT2 support.
GA
June 2011
1.21
Fixed the manual scanning issue.

Fixed the probe upgradation issue.
Truncated the monitor names.
Added product info in the release notes.
Changed the start-up mechanism to start up Java.
Added support for automatic scanning of newly added servers.
Changed the Cfg structure. Monitors are now part of profile section.
GA
December 2010
1.10

Fixed alarm message for janitor memory check.
GA
June 2010
1.03
Added support for AIX.

Fixed alarm subsystem IDs, which are overridden by this release.
GA
February 2010
1.02
Fixed a defect with tree node-name collisions that caused missing nodes and data.
Also changed cluster presentation.
GA
December 2009
1.01
Upgraded libraries
GA
November 2007
1.00
Initial version
Beta
September 2007

The weblogic probe should be installed on systems with the following minimum resources:

The weblogic probe requires the following software environment:
Java JRE 6 or later
WebLogic 9.x, 10.x, 11g, and 12c
Follow these steps:
2. To ensure a successful installation of the probe package (drag-and-drop), it is required that a java.exe (version not critical) exists in the
PATH. If no Java runtime is present, install Java JRE 6 or higher.
4. Double-click the probe for initial configuration. On first-time probe configuration, initiated by double-clicking the probe in CA UIM, the
installation wizard automatically will be launched. The wizard will prompt you for the path to the java.exe of the version required by the
probe.

Some Operating systems (for example, RedHat Linux) bundle a version of Java which is not fully compatible with the Oracle Java runtime,
cauisng the probe to malfunction. This often manifests as connection problems. It is recommended that Oracle Java runtime is installed on the
robot to ensure that the probe functions properly.
Note: There is no problem running multiple Java versions on a robot but it is important that the probe is set up to reference the correct
Java runtime.
webservicemon (Webservice URL Monitoring) Release Notes

This probe monitors web services for following parameters: response time from webservice, return status code, state of SSL certificate expiration
and validity, and the content of the response received from webservice after executing a pre-configured webservice method in a profile.
The webservicemon probe monitors the following systems:
SOAP based web services running on specified web servers. It monitors the SOAP response based on the monitored values, the probe
calculates the turn-around time, collects QoS metrics, and raises alarms.
Contents
Revision History
Supported Platforms
Known Issues
Revision History
Version
Description
State
Date
1.25
What's New:
GA
December
2014
GA
January
2014
GA
November
2012
GA
November
2012
GA
June
2012
First release of the Admin Console GUI of the probe.

Fixed Defects:
Fixed an issue with the edit functionality of the probe. Salesforce case 00145897
1.24
Fixed Defects:
Fixed an issue in which, after a network connection went down and came back up, the probe sent a clear message only after
it was restarted.
1.21
1.20
Fix done to render enumerated values while capturing data for SOAP Request from GUI, at step 3 of 6.
Added Group functionality through which you can create groups and further create profile(s) in groups.
Fix done to generate SOAP Request for RPC style based webservices.
Fix done to get customized alarm messages on UMP alarm console.
Fix done to get proxy settings work properly.
Fix for basic URL authentication should work properly with valid credential at Step 1of 6.
Fix to handle HTTPS based web services which do not require any certificate.
1.11
Fix for Source and Hostname name in QoS.

Fix done for profile name does not accept special characters.
Fix issue to communicate with the web service with client certificate.
Fix issue for DEFAULT QOS.
1.10
Added Custom Header, WSDL Input through File System, and UI validation.
GA
May 2012
Added feature to auto-populate SOAP Action based on method selection.

Added feature to cut and paste predefined SOAP Request Added feature to generate dynamic UI and capture
parameter's values (Header / Body along with attributes) from User.
Modified UI to capture multiple values for a parameter from User and added UI validation.
Added feature to display SOAP Request along with captured user input and make it editable for user.
Modified Response Status Alarm functionality as per status code. Along with, Fixed various existing defects related to
Qos / Alarms / Response Time / RegEx.
1.01
Fixed an issue in which default time unit set to ms in response time QOS and alarm. Salesforce case 71296
GA
December
2011
1.00
Initial release
Beta
November
2011
Supported Platforms

The webservicemon probe should be installed on systems with the following minimum resources:
CPU: 3GHz dual-core processor, 32-bit or 64-bit.

The webservicemon probe requires the following software environment:
CA Unified Infrastructure Management Server 7.1 to 7.6 or CA Unified Infrastructure Management 8.0. Install the ci_defn_pack version
1.01 probe. You must restart the nis_server when you deploy the ci_defn_pack.
or CA Unified Infrastructure Management 8.1 or later (ci_defn_pack is not required)

Probe Provisioning Manger (PPM) probe version 3.00 or later (for Admin Console GUI only)
Java Virtual Machine version 1.6 or later
Known Issues
New group creation functionality is not supported through the Admin Console GUI.
RegEx Edit functionality is not supported through the Admin Console GUI.
In USM view, the heading of Response Time Alarm is displayed incorrectly.
When you create more than one regular expression and configure alarms and QoS for all of them, the default Metric Id for all the regular
expressions is same. As per RegEx, the Metric Id must be different for all the regular expressions.
websphere_mq (WebSphere MQ Monitoring) Release Notes

The WebSphere MQ Monitoring (websphere_mq) probe allows you to monitor the following components of the IBM WebSphere MQ application:
Queue Managers
Queues
Channels
Topics
Subscriptions
The probe only supports 64-bit operating systems and is deployed locally on the system with the IBM WebSphere MQ.
Note: The probe is only available for Admin Console.
Contents
Revision History
Supported Products
Subsystem ID Considerations
Override the Subsystem ID
Update NAS Subsystem ID
Revision History
Version
Description
State
Date
2.12
What's New:
CR
January
2016
GA
January
2015
Added support for WebSphere MQ 8.0.x. For more information, see Supported Products.
Added Client Mode support for connecting to WebSphere MQ. For more information about configuring Queue Managers
with Client Mode, see Set Up Client Connection Mode.
Ability to create monitoring configuration templates. The templates allow you to apply consistent monitoring
Added factory template for monitors available on the Websphere MQ Unified Dashboard.
2.02
What's New:
Added support for AIX 6.x OS for WebSphere MQ 7.5.x.
2.01
What's New:
Added support for monitoring Topics and Subscriptions.
Added new metrics for monitoring in doubt status of the channels.
Added support for monitoring Remote, Alias, Model, and Cluster queues.
Added support for monitoring inhibit put and inhibit get status of the queue.
Added support for Multi-Instance queue manager monitoring.
Added support for monitoring WebSphere MQ on Solaris 11 and Windows Server 2012 R2 operating systems.
September
2014
1.01
First release of the probe with Admin Console GUI.
June 2014
The probe configuration is available ONLY through Admin Console GUI and NOT through IM probe GUI.
The probe runs with NMS 7.6 or later versions and PPM 2.34 or later versions.
Permissions for setmq_auth.sh file changes to default when the probe is upgraded to new version. Change the permission, as required,
after upgrading the probe to a new version.
If you are upgrading the probe from 2.02 to a later version, consider the following points:
The existing Queue Managers in binding state remain as is in the upgraded probe. The new discovered Queue Managers are in the
client mode.
A separate node called Queue Manager is created under Queue Manager where all metrics for a queue manager are listed.
If you are upgrading the probe to 2.01 or later, consider the following points:
To view the new metrics that are introduced in the websphere_mq probe version 2.01 or later on the Unified Service Management
(USM), you can perform any one of the following actions:
Upgrade NMS 7.6 to CA UIM 8.0 or later
Install the ci_defn_pack probe version 1.00 or later and restart the nis_server probe.
The Queue metrics that are previously generated by the probe are displayed at the LocalQueue level on the USM in versions 2.01 or
later. However, the existing metrics already displaying at Queue level remain as is on the USM.
The Queue monitors, which are activated on the probe prior to version 2.01, move to the Detached Configuration node after
upgrade. You can activate the monitors for each queue again from the Local Queue node.
The probe version 2.01 or earlier used the IP address of the system as QoS and alarm source while the versions 2.01 or later use the
hostname as the default source. After migration, you can update the Source Override field value at websphere_mq node to IP
address else two views are displayed on the USM for the same metric.
The QMs and their corresponding components, which are the part of a cluster, are now displayed under Cluster Queue Manager nod
e and their activated monitors are moved to the Detached Configuration node. Before version 2.01 of the probe, all QMs are
displayed under the Queue Manager node.

The websphere_mq probe must be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM. The OOB configuration of the probe requires 256 MB of RAM.
CPU: 3GHz dual-core processor, 32-bit, or 64-bit

The websphere_mq probe requires the following software environment:
jre_aix probe (only for NMS 7.6 or CA UIM 8.2 and earlier versions on AIX platform)
(for probe version 1.01) Probe Provisioning Manager (PPM) probe version 2.34 or later
(for probe version 2.01 or later) Probe Provisioning Manager (PPM) probe version 2.38 or later
Java JRE version 6 (64-bit) for websphere_mq probe version 2.02 and earlier
Supported Products
The probe can monitor the following WebSphere MQ products:
IBM WebSphere MQ version 8.0.X (tested on IBM WebSphere MQ versions 8.0.0.4 for 64-bit versions of RHEL 6, AIX 6, and Windows
2012)
IBM WebSphere MQ versions 7.5.X or 7.0.X (tested on IBM WebSphere MQ versions 7.5.0.3 and 7.0.1.10) for all supported OS (64-bit)
IBM WebSphere MQ version 7.5.x for AIX 6.x (64-bit) OS using robot 7.80. For more information, see Set Up Environment for AIX
Monitoring.
Subsystem ID Considerations
Alarms are classified by their subsystem ID, identifying which part of the system the alarm relates to. You can perform the following operations in
probe versions 2.01 and earlier:

The PPM probe maintains a table of subsystem IDs that are mapped to the probes. In probe version 2.01, the subsystem IDs for the probe default
to 1.1.19. If you are using either dynamic or static alarm thresholds, you can change the default entry to the appropriate subsystem ID. These
changes enable displaying the name corresponding to the subsystem ID in the USM.
Follow these steps:
1. Open the websphere_mq probe.
3. Change the Static and Dynamic Subsystem (override) fields to 2.3.7.1..

Alarms are classified by their subsystem ID, identifying which part of the system the alarm relates to. These subsystem IDs are kept in a table that
is maintained by the NAS probe. These subsystem IDs already exist in NAS if you are using CA UIM 8.0 or later. Add these subsystem IDs
manually, in the NAS Raw Configuration, if you are using NMS 7.6.
Important! This step is not required if you are using CA UIM 8.0 or later.
Key Name
Value
2.3.7.
WebSphere_MQ
2.3.7.1
Resource
2.3.7.2.
QueueManager
2.3.7.3.
Queue
2.3.7.4.
Channel
2.3.7.5.
Subscription
2.3.7.6.
Topic
1. In the Admin Console, open the NAS probe configuration interface.
2. Click the Subsystems folder.
3. Click the New Key Menu item.
4. Enter the Key Name in the Add key window and click Add.
6. Repeat this process for all the required subsystem IDs for your probe.
7.
7. Click Apply.
1. In Infrastructure Manager, right-click on the NAS probe, and select Raw Configure.
3. Click the New Key... button.
4. Enter the Key Name and Value and click OK.
6. Click Apply.
websphere (WebSphere Monitoring) Release Notes
Businesses that are based on web depend on a high degree of quality and availability. Therefore, the security, availability, and performance of the
IBM WebSphere Application Servers (WAS) must be as high as possible. Monitoring and managing the servers, components, and services are
essential to ensure optimal performance of WAS.
The WebSphere Monitoring (websphere) probe handles all the common monitoring and data collection tasks on the WAS. The probe collects and
stores data and information from the monitored system at customizable intervals. The probe generates alarms when the specified thresholds are
breached. The websphere probe monitors the WAS version 7.0 or later.
Contents
Revision History
Install Java JRE
On UNIX
On Windows
PMI
WAS Versions
Known Issues
Revision History
This section describes the history of the revisions for the websphere probe.
Version
Description
State
Date
1.73
Fixed Defects:
GA
June 2015
Fixed a defect where the log size kept on increasing even after setting the log size key value. Salesforce case 00164635
1.72
Fixed Defects:
GA
April 2015
Probe did not handle a period (.) in the deployed application name and did not generate metrics for the application. Sale
The probe kept restarting and eventually crashed if different credentials were provided to connect to the same server
and same port. Salesforce case 00157088
The probe took time to load checkpoints for J2EE applications. Salesforce case 00157088
The probe was not generating alerts with the Advanced Alarming feature. Salesforce case 00158147
In probe version 1.70, a new resource could not be added to the probe configuration. Salesforce cases: 00145653,
00149026, 00148816
The probe did not display metrics under automonitor node when applied through auto-configuration. Salesforce case
00149110
The user credentials are no longer stored in the probe logs. Salesforce case 00151834
1.71
Provided an option on the probe GUI to configure IBM WebSphere 8.5
GA
November
2014
1.70
GA
June 2014
GA
April 2014
GA
March
2014
1.65
Fixed the defect where the probe displays an error in the Portuguese environment while adding resource information or
fails to launch the probe GUI if a resource is already added.
Fixed the defect where the probe is generating two device id for one resource.
Fixed the defect where the TNT2 data does not match with the Metric Definition table data.
1.64

Fixed an issue where No Entities Found error was being thrown while creating a profile for a valid resource with
incorrect details.
1.63
Fixed server name change on auto scan of profiles Fixed GUI error in multiple groups Fixed template functionality for
template from different profiles.
GA
October
2013
1.62
Added Probe Defaults template.
GA
November
2012
GA
September
2012
GA
August
2012
GA
December
2010
GA
June 2010
GA
April 2009
GA
December
2007
GA
September
2007
1.61
Dragging issue for wild-card scenario and template to auto-configuration.

Fixed issues of Monitor: Browse, Activation/Deactivation, Updating no. of monitors after deletion, Disappearing of
monitors after editing profile.
Default group is no longer visible if no resource is kept under it.
Fixed the Issue of QoS Definition issue in automonitor.
1.60
Added support for WAS version 8.0 & 8.5.

Added features for Auto Configurations, Auto Monitors, and Templates.
Added monitoring capability for application up/down status.
Added Low threshold for monitors in GUI.
Added Memory Threshold tab in General Setup dialog.
1.51
Added support for automatic scanning of newly added servers.

Fixed the issues that are related to Scanning.
Changed the probe startup mechanism to start up java.
Changed the cfg structure. Monitors are now part of the profile section.
1.40
1.31

Added support for WebSphere Application Server version 7.0.
Added an option to turn off the usage of SSL.
Changed message subsystem to 2.3.4.x (only new installations).
1.25
Upgrade libraries.
Added security file.
1.23
Better handling of clusters.

Fixed GUI issues.
1.21
Changed start-up script on Solaris.
GA
December
2006
1.20
Fixed data collection in websphere cluster.
GA
November
2006
1.18
Optimized data collection
GA
October
2006
GA
September
2006
GA
July 2006
GA
May 2006
1.17
Fixed deprecated messages in SystemOut.log (WAS 6.0).

Optimized data-collection.
1.16
Fixed issues on UNIX platform.

Added support for "First probe port number".
Minor GUI changes.
1.15
Fixed missing alarms.

Minor GUI Changes.
Fixed error in config file write when section contained '/'.
Java SDK changed - now sends probe name with alarms Fixed fetching of keys from WAS.
Initial version.

The websphere probe should be installed on systems with the following minimum resources:
Memory: 2-4GB of RAM.
Probe's OOB configuration requires 256MB of RAM
CPU: 3-GHz dual-core processor, 32-bit, or 64-bit

The websphere probe requires the following software environment:
Note: For SOC functionality, CA Unified Infrastructure Management 7.6 or 8.0 or later and UMP 2.5.2 or later is required.
Java JRE 6 or later. By default Java comes with WAS 7 and above. Use the same path for java_home.
PMI: Performance Monitoring Infrastructure (PMI) must be enabled on the WebSphere Application Server for the probe to gather
performance data.
WebSphere Application Server version 7.0 or higher.
Note: WebSphere Community Edition (CE) is not supported.
Product Info: Some checkpoints of older version of probe cannot be upgraded with this version of probe.
The websphere probe can be installed on either a server running WebSphere or on a remote computer.
If installed on a server running WebSphere, install the relevant environment files on the server.
If installed on a remote computer, install the relevant environment files on that computer.
Note: Install WAS files/AppServer directory on the machine where the probe is deployed for all WAS version.
For WebSphere version 7.0, 8.0, and 8.5 copy the runtimes and plugins folders from the WebSphere directory of the WebSphere server.
Notes:
Copy the etc and lib folders from the WebSphere server to the remote computer, if the OS on the remote computer (running
websphere probe) and server (running WebSphere software) are different.
If the websphere probe is running on Windows OS, use the AppServer directory for Windows. Similarly, if the probe is running
on Linux or Solaris, use the AppServer directory from the respective environment.
Follow these steps:

2. Ensure that java path is correctly configured for the successful installation of the probe package.
4. Double-click the probe for initial configuration.
At first-time probe configuration, the installation wizard is automatically launched. The wizard prompts you for the path to the correct
version of IBM JVM and other environmental files that are required by the probe.
Install Java JRE

Install Java JRE version 6 or higher from IBM on the computer running the WebSphere probe. The probe path has to contain the java executable.
You can also copy the Java folder from the server WebSphere directory to the remote Windows computer on which probe is installed.
Note: Java JRE 6 and above is available with WAS 7.0 and above and you can use the same path for java_home.
On UNIX
You can configure the JVM and Java Home settings for installing the websphere probe on a computer running the UNIX OS.
Follow these steps:
1. Set the JAVA_HOME environment variable to the directory in which IBM JVM is installed and export JAVA_HOME. For example,
export JAVA_HOME=/usr/lib/jvm/ibm-java2-i386-50/jre/bin
2. Make sure that the PATH variable includes $JAVA_HOME. For example,
export PATH=$JAVA_HOME:$PATH
3. Open a shell as user root and use the command java - version.
The output shows the IBM java version installed.
On Windows
You can configure the JVM and Java Home settings for installing the websphere probe on a computer running the UNIX OS.
Follow these steps:
1. To set the Java path, right-click My Computer and select Properties.
2. In the Advanced tab, click Environment variables.

3. Alter the Path variable so that it also contains the path to the IBM Java executable.
4. Open a DOS window and use the command java - version.
The output shows that IBM java version is installed.
PMI
Enable Performance Monitoring Infrastructure (PMI) on the WebSphere Application Server so that the probe can gather performance data.
Read more about PMI:
http://www-01.ibm.com/support/knowledgecenter/SSTVLU_8.6.0/com.ibm.websphere.extremescale.doc/txsenablepmi.html?lang=en
WAS Versions
Certain WebSphere Application Server (WAS) versions prevent external PMI clients like the websphere probe from obtaining correct PMI values
from the server. The internal error is fixed in the following WAS versions:
For both WAS 5 and 6, the error is corrected.
For WAS 5, the error is fixed in version 5.1.1.10.
For WAS 6, the error is fixed in version 6.0.2.9, older versions like 6.0.2.5 and 6.0.2.7 contain the error.
Known Issues
This section describes the known issues of the probe.
The probe stops functioning if you save the probe configuration with an invalid Java Home path or Libraries path.
The Admin Console GUI of the probe has the following additional limitations.
The probe stops functioning if you do not refresh the web page after adding new resource.
The probe does not provide the ability to create Templates, Auto Monitor, and Auto Configuration.
The probe does not support any other QoS except Default.
The probe does not support the Rescan host option, which allows the user to scan the profiles in the host server after a pre-configured
interval (15 minutes) and loads any profiles available in the host server under the respective Resources nodes in the probe GUI.
wins_response (Windows Internet Name Service Response Monitoring) Release Notes

This article contains the Release Notes for all versions of the wins_response monitoring probe.
Contents
Revision History
Requirements
The WINS Server Response monitoring probe can monitor the WINS response for one or more Windows Internet Name Service (WINS) servers,
based on individual monitoring profiles for the different WINS Servers. The probe can send Quality of Service messages on response time and
alarms if the service is unavailable or the lookup failed.
Revision History
Version
Description
State
Date
1.20
GA
Dec 2010
GA
Oct 2006
GA
Aug 2003

1.03
Added message pool functionality.
1.02
Added more probe logging.

Corrected typos.
Corrected alarm subsystem.
Requirements
This section contains the requirements for this probe.
There are no additional hardware requirements for this probe.
A WINS server is required.
xenapp (XenApp Monitoring) Release Notes

This article contains the release notes for the XenApp Monitoring (xenapp) probe.
Contents
Revision History
Requirements
Prerequisites
Considerations
Known Issues
Known Issues with Workarounds
Increasing Probe Heap Space for Large Implementations
Probe Not Collecting Data
Probe Delays in Fetching XenApp Data
Probe Delays in Fetching Farm Data
Probe Not Fetching Performance Metrics for Some Servers in Farm
Probe Not Fetching Performance Metrics even when WinRM Enabled
Probe Not Fetching ICA Latency Metrics
Troubleshooting Connection Issues
Verify the WinRM Connection
Verify PowerShell Access
Set Up Multi-Hop Authentication
Revision History
This table describes the revision history for the probe.
Version
Description
State
Date
1.12
Minor release
GA
Sept
2015
What's New:
When the probe is configured for localhost monitoring (that is, when the probe is deployed on a robot present in a Citrix XenApp
Server machine), the probe functions when you also enter localhost in the Hostname field while creating a resource.
1.10
Minor Release
GA
July
2014
1.00
Initial Release
Beta
June
2014
Requirements
Prerequisites
The probe requires these prerequisites:
CA Unified Infrastructure Management version 5.1.1 or later environment.
Windows PowerShell command line interface on the XenApp server. The latest version of PowerShell that comes with Windows Server
2008R2 or later is required. For information on configuring PowerShell for use with the XenApp Monitoring probe, see the Citrix XenApp
Guide.
Windows Remote Management (WinRM) enabled on the xenapp server. For instructions on enabling WinRM, see the xenapp Guide.
Citrix XenApp v 6.5.
Java Virtual Machine 1.6 or later (typically installed with CA Nimsoft Monitor server 5.0 and later)
Infrastructure Manager 4.02 or later
Microsoft .NET Framework 3.5 on the system where the Infrastructure Manager application is running
Important!: On 64-bit Linux systems, the Java jre included in the XenApp Monitoring probe package does not install successfully when
you deploy the XenApp Monitoring probe on a robot.
Considerations
This section describes important information to know about the probe.
Installation follows the standard probe distribution process.
No general use considerations exist at this time.
Known Issues
This section describes known issues. These issues apply to the latest version of the probe unless otherwise noted.
Applies to all versions.
1. In locales where the system settings are in languages other than English, the probe may not be able to fetch data for metrics with decimal
points.
2. Authentication failure can happen intermittently when the SSL option is enabled while configuring a domain user for a resource
Known Issues with Workarounds

This section describes known issues with possible workarounds. These issues and workarounds apply to the latest version of the probe unless
otherwise noted.

If you have many applications on a xenapp server (represented as a resource in the XenApp Monitoring probe), you may need to increase the
heap space for the probe. Heap space is allocated during probe startup. By default the heap space for the XenApp Monitoring probe is 256 MB.
You can increase the heap space setting for the XenApp Monitoring probe in the Raw Configure window for the probe.
Follow these steps:
1. Shift + right-click on the XenApp Monitoring probe in Infrastructure Manager.
The Raw Configure dialog opens.
where <nnnn> is heap space up to 2048 MB or greater. For example, to increase the heap space to 1024 MB, enter the following:
-Xms256m - Xmx1024m
Ensure the machine where the CA Nimsoft Monitor robot and probe are deployed has enough RAM.
Probe Not Collecting Data

Applies to all versions:
Symptom:
The probe is not collecting data.
Solution 1:
The probe may not be able to connect to the XenApp environment. There are several issues that can cause this. See the Connecting to the
XenApp Environment section of this document, including the subsection on Troubleshooting Connection Issues.
Solution 2:
You may need to allocate more memory for the probe to execute PowerShell commands on the XenApp server. We recommend setting this to
1024 MB during initial configuration for the XenApp Monitoring probe. However, in some cases this may need to be increased.
Check the xenapp.log file for the following message:
Process is terminated due to StackOverflowException
If you see this message, enter the following command on the XenApp server:
winrm set winrm/config/winrs @{MaxMemoryPerShellMB="nnnn"}
where nnnn is a number greater than 1024.
Solution 3:
Note: This solution is only valid when Kerberos Authentication is enabled.
You might get the Kerberos error, "Clock Skew too great while getting initial ticket".
This error occurs when there is a time difference between the XenApp server and the probe machine. Verify that both the XenApp server and
probe machines are in the same time zone, and the time difference between the machines is not more than 5 minutes.

Symptom:
Out of memory errors.
Solution:
If you have many applications on a XenApp server (represented as a resource in the XenApp Monitoring probe), you may need to increase the
heap space for the probe. For instructions, see Increasing the Heap Space for the Probe.
Probe Delays in Fetching XenApp Data

Symptom:
The Add-PSSnapin cmdlet sometimes takes more time, around 60 to 90 seconds. This happens sometimes when the XenApp Server is not
connected to internet, while loading the XenApp SDK Snapin in PowerShell, system tries to verify the Authenticode signature and hence takes
more time.
Solution:
To resolve this issue, you can either provide the computer with internet access so it can verify the Authenticode signature, or disable the
Authenticode signature checking feature for Microsoft Management Console as described below.
1. On the XenApp server added under Resources, open Internet Options in the Control Panel or Internet Explorer.
2. Click the Advanced tab.
3. Scroll down to Security.
4. Uncheck Check for publisher's certificate revocation.
5. Uncheck Check for server certificate revocation.
6. Click OK.
Probe Delays in Fetching Farm Data

Symptom:
The Add-PSSnapin cmdlet sometimes takes more time, around 60 to 90 seconds. This happens sometimes when the XenApp Server is not
connected to internet, while loading the XenApp SDK Snapin in PowerShell, system tries to verify the Authenticode signature and hence takes
more time.
Solution:
Authenticode signature checking feature for Microsoft Management Console as described below.
1. On the XenApp server added under Resources, open Internet Options in the Control Panel or Internet Explorer.
4. Uncheck Check for publisher's certificate revocation.
5. Uncheck Check for server certificate revocation.
6. Click OK.
Probe Not Fetching Performance Metrics for Some Servers in Farm

Applies only to probe version 1.1.
Problem:
Resources are configured to fetch performance metrics from specific servers by placing the file "serversForMetrics_<ResourceName>.txt " in
XenApp probe directory on the probe machine; as a result, the servers from which metrics are not fetched might not be listed in the file.
Note: This is an optional configuration, and absence of this file would fetch metrics from all the servers in the farm. More information:
Server List Configuration.
Solution:
Go the probe installed location and check if the file serversForMetrics_<ResourceName>.txt is present. If the file is present, open the file and
check if the server name (from which metrics are not coming) is present in the list.If the name is not present, then append the name to the list,
save the file and close it.
Problem:
WinRM configuration is not enabled on the server from which metrics are not fetched. WinRM configuration must be enabled in all servers in the
farm from which metrics have to be collected.
Solution:
Enable Winrm configuration on the server from which metrics are not fetched. More information: Configure WinRM and PowerShelll.
Probe Not Fetching Performance Metrics even when WinRM Enabled

Problem:
The probe will not fetch metrics if WinRM is not configured properly.
Solution:
1. Run the below command on windows prompt in the server from which metrics are not coming: winrm get winrm/config/service.
2. In the command result, check that the property - AllowUnencrypted = true.
3. If the above property value is 'false', then run the below command:
winrm set winrm/config/service @{AllowUnencrypted="true"}
4. Verify again that the property is set to true by repeating step 1.
Probe Not Fetching ICA Latency Metrics

Problem:
Probe fetching all performance metrics except those related to Citrix ICA Latency.
Solution:
1. On Windows servers, open Windows Registry Editor (go to Start->Run, and type "regedit" and Enter).
2. In the Registry Editor, traverse to the path mentioned below:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Citr
ixICA\Performance
3. Check if the value of the registry Disable Peformance Counters is 1.

4. If the value of the registry is 0, then open the registry Disable Performance Counters and change the value of the registry from 1 to 0.
5. Save the registry value.
6. In the next polling interval, verify that the probe fetches the ICA Latency metrics.
Troubleshooting Connection Issues

This section contains troubleshooting steps you can take if the XenApp Monitoring probe is unable to connect to the XenApp server and no data is
collected.
Verify the WinRM Connection

If no data is displayed in the XenApp Monitoring probe GUI, you must verify that the WinRM service is connecting to the XenApp server.
Follow these steps:
1. Verify that the WinRM service is running on the XenApp server.
2. Review the WinRM configuration details for any problems by entering the following command at the Command Prompt on the xenapp
server:
winrm get winrm/config
3. Verify that the correct port is assigned to Win RM on the XenApp server.
The port number is listed under Default Ports in the output for the previous step. The default is 5985.
Verify PowerShell Access

If the XenApp Monitoring probe cannot connect to the XenApp server, it may be because remote access to PowerShell on the XenApp server is
restricted. Verify that the correct access is set for PowerShell on the XenApp server.
Follow these steps:
1. Open a PowerShell window on the XenApp server and enter the following command:
Get-ExecutionPolicy
2. If the response says Restricted, you must change the setting to Unrestricted or RemoteSigned. For example, to set it to RemoteSigne
d:
a. Enter the following command:
Set-ExecutionPolicy RemoteSigned
b. Enter Y to accept the policy.
c. Enter the Get-ExecutionPolicy command again to verify the setting.
Set Up Multi-Hop Authentication

If the XenApp Monitoring probe cannot connect to the XenApp server, it may be because credentials must be delegated across multiple remote
computers in your environment. In this case, you must configure WinRM to use Credential Security Service Provider (CredSSP) to provide
multi-hop support for authentication. Kerberos delegation is not supported by the XenApp Monitoring probe.
Follow these steps:
Note: If any of the following commands having single quotations fail, then try to run the command without the quotation marks.
1. Enable CredSSP on the WinRM client system, either by setting it manually or through a Group Policy setting.
To set it manually enter the following command:
winrm set winrm/config/client/auth '@{CredSSP="true"}'
To set it through a Group Policy, follow these steps:
a. Enter the following command in a Command Prompt window to open the Group Policy dialog:
gpedit.msc
b. Navigate to Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management
(WinRM)\WinRM Client.
c. Double-click on the Allow CredSSP authentication policy in the right pane to open its configuration dialog.
d. Edit the policy as necessary.
2. Enable CredSSP on the WinRM service, either by setting it manually or through a Group Policy setting.
To set it manually enter the following command:
winrm set winrm/config/service/auth '@{CredSSP="true"}'
To set it through a Group Policy, follow these steps:
a. Enter the following command in a Command Prompt window to open the Group Policy dialog:
gpedit.msc
b. Navigate to Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management
(WinRM)\WinRM Service.
c. Double-click on the Allow CredSSP authentication policy in the right pane to open its configuration dialog.
d. Edit the policy as necessary.
xendesktop (XenDesktop Monitoring) Release Notes

This section contains the release notes for the XenDesktop Monitoring (xendesktop) probe.
Contents
Revision History
Requirements
Prerequisites
Considerations
Auto-Discovery Time for Large Implementations
Deploying the Probe on a 64-bit Linux Machine
xendesktop Probe is Not Collecting Data
xendesktop Probe Delays in Fetching Site Data
xendesktop Probe Not Fetching HealthInfo Metrics even when WinRM Enabled
xendesktop Probe Out of Memory Errors
xendesktop Probe Known Issues
Revision History
Version
Description
State
Date
3.03
What's New:
Beta
May 2015
Added support for metrics from v1 ODATA APIs for Citrix Xendesktop 7.6.
3.02
Fixed Defects:
Beta
April 2015
Beta
March
2015
Fixed an error related to FileNotFoundException for pom.xml

Fixed an error in which Dr. NimBUS displayed the message "Failed to update/fix details for static monitor" for the alarms
raised for application metrics
3.00
What's New:
Version 3.0 of the probe supports monitoring of both Citrix XenApp v7.5 and Citrix XenDesktop v7.5 and is compatible with
only v8.0 and v8.1 of CA Unified Infrastructure Management.
Added the ability to look up the localhost for automated deployments.
Added monitoring capability for the following components:
Applications
Load Indexes
Added new metrics (collected through ODATA APIs) to the following resources:
Administrator
Broker Session
Catalog
Desktop
Desktop Group
Load Index
Machine
Hypervisor
Added the ability to query metrics for:
one specified Citrix server (controller) OR a list of specified controllers
one or more specified site metric groups for one or more controllers
Removed ICA session metrics that were available in prior releases.
For more information about specific metrics, see the Metrics page.
2.10
Support for optional Kerberos Authentication
GA
July 2014
2.00
General release of version 2.0
GA
June 2014
2.00
Support for monitoring of clustered XenDesktop DDC environments.
Beta
September
2013
Beta
December
2012
Supports monitoring of Citrix XenDesktop 7.

Supports monitoring of additional objects:
XenDesktop Sites
Broker User Sessions
Controllers
Health Information for each DDC server
License Server
Individual Virtual Desktops (basic health parameters) - optional
Administrators
1.00
Requirements
This section describes the requirements for the probe.
Prerequisites
This section describes the prerequisites for the probe:
Kerberos Authentication
XenDesktop version 7.5.
Windows PowerShell command-line-interface on the XenDesktop Delivery Controller (DDC) server. The latest version of PowerShell that
comes with Windows Server 2008R2 or later is required. For information about configuring PowerShell for use with the XenDesktop
Monitoring probe, see the XenDesktop Monitoring Guide.
Windows Remote Management (WinRM) enabled on the DDC server. For instructions on enabling WinRM, see the xendesktop Guide.
v3.0 requires CA Unified Infrastructure Management v8.0 or v8.1
Earlier versions require:
Java Virtual Machine 1.6 or later (typically installed with UIM server 5.0 and later)
Infrastructure Manager 4.02 or later
Microsoft .NET Framework 3.5 on the system where the Infrastructure Manager application is running
Important! On 64-bit Linux systems, the Java jre included in the probe package does not install successfully when you deploy the
probe on a robot. You must manually install the glibc.i686 library or compatible 32-bit libraries on 64-bit Linux systems where you
deploy the probe.
Considerations
This section describes important information to know about the probe.
Installation follows the standard probe distribution process.

None.

This section describes known issues and possible workarounds for this probe. These issues and workarounds apply to the latest version of the
probe unless otherwise noted.
Auto-Discovery Time for Large Implementations

In large Citrix XenDesktop VDI implementations, it may take some time for discovery to occur when you open the probe configuration GUI,
especially the first time you open the GUI. You may see a delay while the resource tree is populated in the navigation pane of the GUI.
Deploying the Probe on a 64-bit Linux Machine

Important! On 64-bit Linux systems, the Java jre included in the probe package does not install successfully when you deploy the
probe on a CA Nimsoft robot. You must manually install the glibc.i686 library or compatible 32-bit libraries on 64-bit Linux systems
where you deploy the probe.

If you have more than 3000 virtual desktops for a DDC server (represented as a resource in the probe), you may need to increase the heap space
for the probe. Heap space is allocated during probe startup. By default the heap space for the probe is 256 MB.
You can increase the heap space setting for the probe in the Raw Configure window.
Follow these steps:
1. Shift + right-click on the probe in Infrastructure Manager.
The Raw Configure dialog opens.
where <nnnn> is heap space up to 2048 MB or greater. For example, to increase the heap space to 1024 MB, enter the following:
-Xms256m - Xmx1024m
Ensure the machine where the robot and probe are deployed has enough RAM.
xendesktop Probe is Not Collecting Data

Symptom:
The probe is not collecting data.
Solution 1:
The probe may not be able to connect to the XenDesktop environment. There are several issues that can cause this. See the Set Up and
Configure Connections section of the probe guide, including the subsection on Troubleshooting Connection Issues.
Solution 2:
You may need to allocate more memory for the probe to execute PowerShell commands on the DDC server. We recommend setting this to 1024
MB during initial configuration for the xendesktop probe. However, in some cases this may need to be increased.
Check the xendesktop.log file for the following message:
Process is terminated due to StackOverflowException
If you see the StackOverflowException message, on the DDC server added as a resource or alternate resource, open a command prompt and
enter the following command :
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="nnnn"}'
where nnnn is a number greater than 1024.
Solution 3:
Note: This solution is only valid when Kerberos Authentication is used in the probe. Kerberos Authentication is required for v3.0 and
optional for earlier versions.
Note: In the probe log, if you get the Kerberos error, "Clock Skew too great while getting initial ticket," there is a time difference between
the XenDesktop server and the probe machine. Verify that both the XenDesktop server and probe machines are in the same time zone,
and the time difference between the machines is not more than 5 minutes.
xendesktop Probe Delays in Fetching Site Data

Symptom:
In some environments, the Add-PSSnapin cmdlet might take approximately 60 to 90 seconds to add XenDesktop PowerShell SDK related snapin.
This delay happens when the XenDesktop Server is not connected to the internet. This delay can also happen when the XenDesktop SDK Snapin
is added in a PowerShell session, because the system tries to verify the Authenticode signature and this takes more time.
Solution:
Authenticode signature checking feature for Microsoft Management Console as mentioned below.
1. Open Internet Options in the Control Panel or Internet Explorer.
4. Uncheck "Check for publisher's certificate revocation."
5. Uncheck "Check for server certificate revocation."
6. Click OK.
xendesktop Probe Not Fetching HealthInfo Metrics even when WinRM Enabled
Problem:
The probe will not fetch HealthInfo metrics even though WinRM is enabled.
Solution:
1. On the server from which you want the probe to fetch the HealthInfo metrics, in the Windows prompt, run the command :
winrm get winrm/config/service
2. In the command result, check that the property - AllowUnencrypted = true.

3. If the above property value is false, then run the command:
winrm set winrm/config/service @{AllowUnencrypted="true"}
4. Verify again that the property is set to true by repeating step 1.
xendesktop Probe Out of Memory Errors

Symptom:
Out of memory errors.
Solution:
If you have more than 3000 virtual desktops for a DDC server (represented as a resource in the probe), you may need to increase the heap space
for the probe. For instructions, see Increasing the Heap Space for the Probe.
xendesktop Probe Known Issues

In locales where the system settings are in languages other than English, the probe may not be able to fetch data for metrics with decimal points.
xenserver (Citrix XenServer Monitoring) Release Notes

This section contains the release notes for all version of xenserver (XenServer Monitoring) monitoring probe.
Contents
Revision History
Requirements
Prerequisites
Considerations
Guest Disk Usage Metrics Are Static
QoS Collisions
The xenserver (XenServer Monitoring) monitoring probe performs all common monitoring and data collection tasks for Citrix XenServer systems.
The CA Unified Infrastructure Management XenServer Monitoring (xenserver) monitoring probe handles all common monitoring and data
collection tasks for Citrix XenServer systems. The probe collects and stores data and information from the monitored systems at customizable
intervals. You can easily define alarms to be raised and propagated to the CA Unified Infrastructure Management Alarm Console when specified
thresholds are breached.
Contents
Revision History
Requirements
Prerequisites
Considerations
QoS Collisions
Revision History
Version
Description
State
Date
What's New:
GA
November
2015
2.30
Added support for Admin Console.
Added support for multiple resources to the same host
Enhanced metric processing performance
Added a metric for the HOST_CPU_GROUP: Host CPU Average Utilization. Salesforce case 00037522
Added the ability to send QoS values for the Virtual Machine State. Salesforce case 00071197
Fixed Defects:
Fixed a defect in which the probe puts a host prefix on the source field for hypervisors. Salesforce case 00071197
Fixed a defect in which the probe created monitors for devices that were not configured to have them. Salesforce case
70003268
Fixed a defect in which session connections were not closed at the end of a session. Salesforce case 0000131675
Fixed a defect in which the Unified Dashboards for the probe were not correctly populating with data.
Note: After you upgrade to v2.30, reapply the UMP templates for the Unified Dashboards to populate correctly.
Fixed a defect in which the Virtual Machine State metric for the VM and Host Template had a QOS value of "Default."
The correct possible values are: -1 (Unknown), 0 (Unrecognized), 1 (Halted), 2 (Paused), 3 (Running), 4 (Suspended).
2.03
Added ability to configure the probe using the Admin Console or Snap UI.
GA
December
2013
2.01
Fixed the master failover issue. Improved CPU metric collection. Improved performance. Added metrics.
GA
August
2013
1.22
Fixes for Pool behavior
GA
January
2013
1.21
Fixed robot config locking behavior
GA
September
12 2012
1.10
Commercial Release
GA
September
30 2012
Requirements
This section contains the requirements for the probe.
Prerequisites
The probe requires:
An account with access to the XenServer pool master (if monitoring a pool) or host
A collection of metrics that are enabled on each XenServer host
Typically metrics are enabled by default. However, metrics are not enabled on some versions of XenServer. See the Citrix XenServer
documentation for information about your version. Most metrics are obtained using the Citrix XenServer RRD, and the rest are obtained
using the xenapi. Some versions of XenServer do not collect CPU utilization metrics by default. If this data is not being collected, enable
the collection of CPU utilization metrics (and the related probe checkpoints). Then restart the system. To enable the collection of CPU
utilization metrics, run the following command on the XenServer system or a remote xe client:
xe host-param-set uuid=<HOST_UUID> other-config:rrd_update_interval

=1
Substitute your host uuid for <HOST_UUID>. The xe host-list command can be used to find the uuid of the host.
Installation of XenServer tools on each VM:
We recommend creating XenCenter templates that have the XenServer tools. The probe collects some metrics without the XenServer
tools on each VM. However, some metrics, such as guest memory usage, can only be obtained with the XenServer tools.
Deploy the probe only on robots with the following minimum resources:
Note: We recommend that you deploy storage and virtualization probes on robots, not on primary hubs.

The memory requirements depend on the size of the monitored environment, the number of collected metrics, and the frequency of
updates (the check interval). The probe, as shipped, requires a minimum of 256 MB of RAM.
CPU: 3-GHz dual-core processor, 32-bit, or 64-bit
XenServer versions up to v6.5, service pack 1
CA Unified Infrastructure Management v8.2 or later
CA Unified Infrastructure Management Monitor Server 5.1.1 or later
Java Virtual Machine 1.71 or later (typically installed with CA Unified Infrastructure Management server 5.0 and later)
Microsoft .NET Framework 3.5.x on the host where Infrastructure Manager is running
Considerations
This section lists important information about the probe.

VM Guest disk usage metrics coming from XenServer represent initial static guest usage only. XenServer does not provide real-time updated VM
guest disk usage through xenapi or RRD.
Install the package into your local archive.
Drop the package from your local archive onto the targeted robot.
As part of the distribution to the target robot, the CA Unified Infrastructure Management JRE package is included for the probe to use.
The master failover issue is fixed in this release of the probe. However, when you configure the resource pool for the first time, verify that you
connect to the correct master.
The first time that you apply a configuration with a new resource, the probe can take several minutes to start.

QoS Collisions
Symptom:
I installed the xenserver probe on my CA UIM system on which I had the vmware probe already installed. Now, I observe: 1) data missing for my
memory monitoring 2) the data_engine log has errors for QOS_MEMORY_PERC_USAGE.
Solution:
If you install the xenserver probe on a CA UIM installation, on which the vmware probe is installed, QoS collisions occur. Collisions can occur
because both probes have a QOS_MEMORY_PERC_USAGE monitor but the vmware probe has more fields for the monitor. To fix the problem,
add these extra fields to the xenserver monitor configuration.
Follow these steps:

1. In Admin Console, select the xenserver probe.
2. Click Raw Configure.
3. Click QOS_MEMORY_PERC_USAGE.
4. Click Add key and add the key/value for each of the following pairs:
Key
Value
asynch
no
hasmax
100
isbool
no
unit
percent
5. Click Apply.
You added the missing fields.
Symptom:
I installed the vmware probe on my CA UIM system on which I had the xenserver probe already installed. Now, I observe: 1) data missing for my
memory monitoring 2) the data_engine log has errors for QOS_MEMORY_PERC_USAGE.
Solution:
If you install the vmware probe on a CA UIM installation, on which the xenserver probe is installed, QoS collisions occur. Collisions can
occur because both probes have a QOS_MEMORY_PERC_USAGE monitor but the vmware probe has extra fields for the monitor. To fix the
problem, delete these extra fields from the vmware monitor configuration.
Follow these steps:
1. In Admin Console, select the vmware probe.
2. Click Raw Configure.
3. Click QOS_MEMORY_PERC_USAGE.
4. Click Remove key and remove each of the following key/value pairs:
Key
Value
asynch
no
hasmax
100
isbool
no
unit
percent
5. Click Apply.
You removed the extra fields.
xmlparser Release Notes

The xmlparser probe enables the user to process any valid input XML against specified sets of rules and generates output as configured in a
specific profile. In addition, the probe can also raise alarms and generate QoS, if configured to do so.
Contents

Requirements

Version
1.22
Description
Modified the code for output field, field names.
State
Date
GA
Dec 2010
GA
Nov 2010
GA
Sep 2010
GA
Jun 2010
Added a compatibility check for the old cfg file.

1.20
Modified the Alarm/QoS generation implementation.

Added a dialog to add Alarm/QoS details.
Added support for internationalization in alarm strings.
1.11
Probe restart functionality added on profile deletion.

TNT2 support Ci path and metric id no longer appended.
Output data is now displayed according to the modified output expression
1.0
Initial Version
Requirements
The xmlparser probe has no additional software or hardware requirements.
zdataservice (Data Service Probe) Release Notes

The zdataservice (Data Service) probe monitors the operational functionalities of the CA Unified Infrastructure Management for z Systems.
Revision History
Known Issues
Fixed Issues
Revision History
This section describes the history of the revisions for the zdataservice probe.
Version
Description
State
Version
1.11
This version fixes an issue that was recently detected. For more information, see Fixed Issues.
GA
December
2015
1.10
Updated Probe Specific Software Requirements for the z/VM Data Collector in the zdataservice (Data Service Probe)
Release Notes.
The z/VM Data Collector now includes support for the following operating systems:
GA
October 2015
GA
August 2015
Red Hat Enterprise Linux 7.0

SUSE Linux Enterprise Server 12
1.00
Initial version
To implement the probe, verify that your system meets the following minimum system requirements:
z/VM Data Collector
Required privilege classes: G
Memory:
Red Hat: 256 MB for Red Hat
SUSE: 1.5 GB
Free disk space: 220 MB (70 MB for installation, 150 MB of free disk space for logging)
Supported Operating Systems
Red Hat Enterprise Linux 6.5, 6.6, or 7.0
SUSE Linux Enterprise Server 11 SP3 or 12
IBM Java Runtime Environment:
Java SE Version 7 SR1 FP1, or,
Java SE Version 8 SR1
CIM Data Collector
z/OS 1.13 with CIM version 2.11.2
z/OS 2.1 with CIM version 2.12.1
Supported Operating Systems for the Data Service Probe
Windows Server 2012 (Memory: 800 MB)
Windows Server 2008 R2 SP1 (Memory: 800 MB)
Red Hat Enterprise Linux 6.6
CA Unified Infrastructure Management Server
CA Unified Infrastructure Management server version 8.2 or later
The following considerations affect the zops (zMonitoring) Probe, the zstorage (zStorage Monitoring) Probe, and the zvm (zvm Monitoring) Probe.
Verify that the following tasks are complete before you install any of the aforementioned probes.
The CIM server is configured.
The zdataservice (Data Service) probe is deployed and connected to CIM Server.
The following packs are installed:
ci_defn_pack is installed on the robot hosting the nis_server infrastructure probe.
mps_language_pack is installed on the robot hosting service_host.
wasp_language_pack is installed on the robot hosting WASP.
For more information, see the following articles:
zops (zops Monitoring) Release Notes
zstorage (zstorage Monitoring) Release Notes
zvm (zvm Monitoring) Release Notes
Known Issues
The following issues are known to exist in this release of the probe:
Under various conditions, CIM Server reports the file system size for network and hierarchical file systems incorrectly. This behavior
causes the Percentage Utilized metric to equal 100% when the Available Space metric is greater than zero.
IBM recently released an APAR to address this problem. To correct this behavior, apply the APAR listed below that
corresponds with your z/OS operating system to your environment:

z/OS 1.13: UA79059
z/OS 2.1: UA79122
z/OS 2.2: UA79047
Under various conditions, CIM Server reports empty Names for Address Spaces and the incorrect type of the address space.
If the probe queries the CIM server when it is in the process of starting, the CIM server can shut down unexpectedly. As a best practice,
we recommend that you start the CIM server before you configure the probe to collect data.
When you add and then immediately delete the added row/rows in the CIM Server Connections or z/VM Server Data Collector
Connections table on the zdataservice Probe Configuration window, and then save the configuration, deleted rows may not be deleted or
some of the existing rows may be replicated. To avoid this situation, always reopen the configuration window, delete the row/rows and
then click Save.
Fixed Issues
The following issue was fixed in version 1.11 of the probe:
Excessive, unclosed TCP/IP connections to the z/VM data collector host, the LPAR where CIM server is running, or both may cause the
Data Service server to stop responding. This behavior can prevent other products from connecting to the TCP/IP service on z/VM and
z/OS systems. To correct this behavior, download and upgrade to the 1.11 version of the Data Service Probe.
zones (Solaris Zones Monitoring) Release Notes

This probe monitors the health and performance of Solaris Zones virtualization enabled systems. The probe collects and stores data and
information from the monitored host system at customizable intervals. You can easily define alarms to be raised and propagated to USM when
specified thresholds are breached.
Contents
Revision History
Revision History
Version
Description
State
Date
1.31
Fixed Defects:
GA
February
2015
GA
December
2012
GA
May 2012
Corrected an issue where the probe version was incorrectly displayed. The update version message is now correct. Salesfo
rce case 00104805
1.30
What's New:
It is no longer necessary to use SSH to connect to zones host
Added default templates
1.23
Probe can now use public/private key-pair authentication for SSH login to Zones host Enhanced Help documentation.
1.20
Added Java implementation, including:
GA
April 2010
Added scalability and performance improvements

Reduced impact on host and zones (minimized the number of commands that the probe will run)
Added support for configuration items and metrics (NIS2)
Please note that Java 1.5 (or newer) is now required.
1.11
Fixed intermittent CPU utilization failure.
GA
April 2010
1.10
Commercial Release
GA
September
2009
Added the choice to gather information from non-global zones using a direct SSH connection or using zlogin from the
global zone.
Replaced run queue length with vmstat pages scanned.
QoS for Resource Controls not enabled by default.
CA Unified Infrastructure Management Robot 3.02 or newer
Java 1.5 or newer
Sun Solaris 10 (release level - Intel x86: 08/07 & Sparc: 11/06) with zones pre-configured.
One of the following:
SSH access to the Solaris Global zone
SSH access to the individual zones
A robot installed on the Solaris Global zone
zops (zops Monitoring) Release Notes

CA zops probe monitors the operational functionalities of z Systems.
Revision History
Known Issues
Revision History
This section describes the history of the revisions for the zops probe.
Version
Description
State
Date
1.00
Initial version
GA
August 2015

To implement zops v1.0, verify that your primary hub meets the following minimum requirements.
Operating System
Windows Server 2008 R2 SP1 or Windows Server 2012 R2
Or
Red Hat Enterprise Linux 6.6 (RHEL 6.6) on 64-bit x86 systems
UIM Server
Ensure the following before you install the zops probe.
The CIM Server is configured.
Note: For details about CIM Server configuration and Data Service deployment, refer to zdataservice (Data Service) Probe.

Note: To know more about installing packs, refer to Install zops.
Known Issues
The following issue exists in version v1.0 of the probe:
When working with the tree view in the USM portlet, some alarms related to the resource inventory may not appear. You can, however,
display all alarms in the Integrated Alarm view when you click the Alarm View icon in USM.
Note: See zdataservice (Data Service Probe) Release Notes for a complete list of the issues that affect the Data Service Probe.
zstorage (zstorage Monitoring) Release Notes

CA storage probe monitors the storage functionalities of z Systems.
Revision History
Known Issues
Revision History
This section describes the history of the revisions for the zstorage probe.
Version
Description
State
Date
1.00
Initial version
GA
August 2015
To implement zstorage v1.0, verify that your primary hub meets the following minimum requirements.
Operating System
Or
UIM Server
CA Unified Infrastructure Management server version 8.2 or later.
Verify the following requirements before you install the zstorage probe.
The CIM Server is configured.
Note: For details about CIM Server configuration and Data Service deployment, refer to zdataservice (Data Service) Probe.

Note: To know more about installing packs, refer to Install zstorage.
Known Issues
The following issue exists in this release of the probe:
When working with the tree view in the USM portlet, some alarms related to the resource inventory may not appear. You can, however,
display all alarms in the Integrated Alarm view when you click the Alarm View icon in USM.
Note: See the zdataservice (Data Service Probe) Release Notes for a complete list of the issues that affect the Data Service Probe.
zvm (zvm Monitoring) Release Notes

The zvm Monitoring probe feeds metrics data from the mainframe z/VM hypervisor into CA Unified Infrastructure Management, such as System
CPU, Guest CPU, page volume, spool volume, and wait states. It also provides metrics data related to guests running on z/VM such as total CPU,
Resident Memory, Working Set, Page Read and Page Writes.
Revision History
Known Issues
Revision History
This section describes the history of the revisions for the zvm probe.
Version
Description
State
Date
1.10
Revised the default Port on the Add New Profile dialog. The default is now 7161, which corresponds to the default port for the
zdataservice (Data Service) probe.
GA
October
2015
GA
August
2015
Added the ability to monitor the following single CPU metrics:

Guest CPU Usage/percent
System CPU Usage/percent
Total CPU Usage/percent
Added the ability to monitor the following spool metrics:
Aggregate Spool Volume Reads/Sec
Aggregate Spool Volume Writes/Sec
Spool Volume Reads/Sec
Spool Volume Writes/Sec
Added a new resource for the following Virtual Switch monitors:
Active Trace ID Count
Linux Guest in Sniffer Mode Count
Received Bytes/sec
Received Discarded Packets/sec
Received Error Packets/sec
Received Packets/sec
Transmitted Bytes/sec
Transmitted Discarded Packets/sec
Transmitted Error Packets/sec
Transmitted Packets/sec
Added a new resource for the following Network monitors, listed under the Guest component:
Aggregate Received Bytes/sec
Aggregate Received Discarded
Aggregate Received Error Packets/sec
Aggregate Received Packets/sec
Aggregate Transmitted Bytes/sec
Aggregate Transmitted Discarded Packets/sec
Aggregate Transmitted Error Packets/sec
Aggregate Transmitted Packets/sec
1.00
Initial version

The zvm probe requires the following software on the primary hub:
Operating System
Or
CA Unified Infrastructure Management Server
Ensure the following before you install the zvm probe.

The z/VM Data Collector is installed and configured.
The zdataservice (Data Service) probe is deployed and connected to the z/VM Data Collector.
Note: For details about z/VM Data Collector configuration and Data Service deployment, refer to zdataservice (Data Service)
Probe.

Note: For more information, see Install the Language and Configuration Packs.
Note: The installation prerequisites and software requirements are described in the main article for zvm Monitoring.
Known Issues
The following issue exists in this release of the zvm probe:
When working with the tree view in the USM portlet, some alarms related to the resource inventory may not display. You can display all
alarms in the Integrated Alarm view when you click the Alarm View icon in USM.
Note: See the zdataservice (Data Service Probe) Release Notes for a complete list of the issues that affect the Data Service Probe.
Alphabetical Probe Articles

This section contains all of the articles pertaining to CA UIM probes, listed in alphabetical order.
A probe is small piece of software that performs a dedicated task. CA Unified Infrastructure Management has two types of probes:
Monitoring probes gather availability and performance data. Some 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 called infrastructure or utility probes) provide product utility functions.
Probes can be easily configured 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.
ace (Automatic Configuration Engine)

ace v8.3
The Automatic Configuration Engine (ace) probe allows you to apply monitor configurations to Monitored Elements (MEs) within your CA UIM
system. This probe is used behind the scenes to store a probes configured setting in the UIM database.
ace v3.5 and earlier

The Automatic Configuration Engine (ace) probe allows you to apply monitor configurations to Monitored Elements (MEs) within your CA UIM
system. This probe is used behind the scenes within Unified Service Manager. Using Unified Service Manager and Service Oriented
Configuration to configure your individual probes, you can create monitoring templates for your CA UIM system.
Configure ace
This probe has no configuration GUI and requires little to no user interaction, so there are no user instructions for this probe.
ad_response (Active Directory Response Monitoring)

An Active Directory (AD) is a directory service, which is integrated in most of the Windows Server operating systems. The Active Directory stores
information about network components and enables clients to find objects within its namespace.
The Active Directory Response (ad_response) probe monitors the availability of the Active Directory. The probe can monitor and report:
Object and number of objects found.
More information:
ad_response (Active Directory Response Monitoring) Release Notes
v1.6 ad_response AC Configuration

The following diagram outlines the process to configure the probe to monitor:
Objects.
Everything that AD server tracks is considered as an object.
Contents
Verify Prerequisites
Configure Replication Objects Monitoring
Configure Response Time Monitoring
Configure Object Monitoring

Alarm Thresholds
Verify that required hardware, and software is available before you configure the probe. For more information, see ad_response (Active Directory
Response Monitoring) Release Notes.

This section describes the minimum required settings for the probe to connect to the AD server and monitor replication objects.
Follow these steps:
1. Open the ad_response probe configuration interface.
2. Navigate to ad_response > Active Directory > Replication.
3. Click Options (icon) > Add Profile.
4. Specify the following profile information and click Submit.
The name of the profile.
The AD server address or domain name.
The credentials to connect to the AD server.
A profile is added to the Replication folder.
5. Navigate to the new <profile name> node created in the Replication folder.
6. Specify the time interval in seconds in Sample Data Every (in seconds) during which the profile collects QoS data.
Reduce this interval to generate alarms faster, as the next interval takes lesser time but it can increase the system load. You can also
increase this interval to generate alarms later and reduce the system load.
7. Select Enabled(runs at specified interval) to start sampling the data at the specified time interval.
8. In the Connection section, define the connection properties for the profile as follows:
Connection Type: Select a connection type that the profile uses to connect to the AD server.
Select Use Secure Connection to ensure encrypted communication with the AD server.
Select Bind to Specific Server to bind the connection to the AD server that is specified in the Server address field. If the defined
AD server is unavailable, the connection fails.
On deselecting the Bind to specific server option, the Domain name field replaces the Server address field. The connection is
successful if at least one domain-controller (LDAP) or Global Catalog is available on the specified domain.
9. Click Actions > Test Connection to test whether the connection defined in this profile is working or not. The confirmation message
displays the connection status. The message also displays the time that is taken to test the connection to the AD server.
10. Define the values in the following fields in the Object section.
The container where the profile searches for the specified object and attribute.
The object that the profile searches.
Example: a user in the AD server such as an administrator.
The attribute that the profile monitors.
Example: the department of an administrator user.
11. Select the required options for the following fields:
Write mode option to enable the profile to write to the selected attribute.
Actions > Test Read to verify if the object and attribute exists.
The profile checks and displays a message whether the object and attribute exist. The message also displays the age of the attribute
since the last modification.
Actions > Test Write to add current time to the selected attribute of the object.
Note: The Test Write option is enabled only if you select the Write mode option.
12. In the Counter Name section, specify the following values to generate alarms and thresholds for a counter.
Enable to publish alarms for the counter.
12.
Enable or disable the defined threshold for the counter.
Define the threshold value and severity for the selected counter, and click Save.

This section describes the minimum required settings for the probe to monitor the connection response time from the AD server.
Follow these steps:
2. Navigate to ad_response > Active Directory > Response.
The credentials to connect to the server.
A profile is added to the Response folder.
5. Navigate to the new <profile name> node created in the Response folder.
6. Navigate to the General, Connection, and Counter Name sections.
7. Define the field values as described in the Configure Replication Objects Monitoring section.

This section describes the minimum required settings for the probe to monitor the searched objects.
Follow these steps:
2. Navigate to ad_response > Active Directory > Search.
The server address or domain name.
The credentials to connect to the server.
A profile is added to the Search folder.
5. Navigate to the new <profile name> node created in the Search folder.
6. Navigate to the General, Connection, and Counter Name sections.
8. Specify the following values in the Query section:
The objects to search in the Search Root Container.
Enable searching the subcontainers within the root container.
The filter query for the search.
Example: Last name starting with "a" and first name starting with "b": (&(sn=a*)(givenName=b*))
9. Click Actions > Test Query.
The probe displays the response time and number of records that are found when the query is successful.
Alarm Thresholds
The alarm threshold options that are available can vary depending on the probe versions installed at the hub level. The alarm threshold settings to
allow the probe to:
Send alarms when threshold criteria is met

Indicate to baseline_engine to compute baselines
See Configuring Alarm Thresholds for details.
v1.6 ad_response AC GUI Reference

This article describes the fields and features of the ad_response probe.
Contents
ad_response Node
Active Directory Node
Replication
<Profile Name> Node
<Server Name>_<Profile Name> Node
<Profile Name> Node
Response
<Profile Name> Node
<Profile Name> Node
Search
<Profile Name> Node
<Profile Name> Node
ad_response Node
This node lets you view the probe information and configure the log level information of the probe.
Navigation: ad_response
ad_response > Probe Information
This section provides information about the probe name, probe version, start time of the probe, and the probe vendor.
ad_response > Log Level Configuration
This section lets you configure the log level of the probe.
Log level: Specifies the detail level of the log file. Log as little as possible during normal operation to minimize disk consumption, and
increase the amount of detail when debugging.
Default: 0-Normal
ad_response > Message Properties
This section is read-only and displays a list of alarm messages available in the probe.
Message: Indicates the variables that are used in the message.
SubSystem: Indicates the alarm subsystem. All profiles using the same connection use this ID as their alarm subsystem.
Active Directory Node

This node does not have any sections or fields and contains the following sub-nodes accessed from the navigation pane.
Navigation: ad_response > Active Directory
Replication: Lets you create a profile, which monitors replication of modified objects between servers, sites, and domains.
Response: Lets you create a profile, which monitors the response time or connect time of the server.
Search: Lets you create a profile, which calculates the search time and number of objects found.
Replication
This node lets you add a profile to the Replication node. The added profile monitors replication of modified objects between servers, sites, and
domains.
Navigation: ad_response > Active Directory > Replication
Replication > Options (icon) > Add Profile
This section lets you add a profile in the Replication node.
Profile Name: Defines the name of the profile to be added in the Replication node.
Server Address / Domain Name: Defines the AD server address or the domain name that the profile monitors.
User: Defines the user name that the profile uses to connect to the AD server.
Password: Defines the password of the user name to connect to the AD server.
Domain: Defines the domain name with which the user connects to the AD server.
<Profile Name> Node

This node is read only and displays the profile name details.
Navigation: ad_response > Active Directory > Replication > Profile Name

Navigation: ad_response > Active Directory > Replication > Profile Name > Server Name_Profile Name
The Server Name_Profile Name node is used to identify the AD server that the probe connects to, and does not contain any field or section.
<Profile Name> Node

The profile name node lets you:
Configure the general properties of the profile.
Configure the connection details of the AD server.
Define the objects the profile monitors.
List the counters available for the object.
Navigation: ad_response > Active Directory > Replication > Profile Name > Server Name_Profile Name > Profile Name
profile name > General
This section lets you configure the general properties of the profile.
Name: Defines the name of the profile.
Description: Defines additional information to identify what objects are monitored by the profile.
Sample Data Every(in seconds): Samples the data at the specified poll interval.
Default: 60
Enabled(runs at specified interval): Enables or disables the profile.
Default: Deselected
profile name > Connection
This section lets you configure the connection properties for the profile.
Connection Type: Specifies the connection type used by the profile to connect to the AD server.
Default: LDAP
Use Secure Connection: Lets you use a secure connection ensuring that all communications are encrypted when connecting to the AD
server.
Default: Deselected
Bind to Specific Server: Binds the connection to the server specified in the Server Address / Domain Name field. If the defined server
is unavailable, the connection fails.
Default: Deselected
Server Address / Domain Name: Defines the AD server address or the domain name that the profile monitors. Specify the AD server
address of the profile if the Bind to Specific Server option is selected. Otherwise, specify the fully qualified domain name of the profile.
User: Defines the user name that the profile uses to connect to the AD server.
Password: Defines the password of the user name to connect to the AD server.
Domain: Defines the domain name with which the profile connects to the AD server.
Actions > Test Connection: Tests the connection and displays the response time of connecting to the server.
profile name > Object
This section lets you define the object the profile monitors and is available only for the Replication profiles.
Container: Specifies the container in which the profile looks for the specified object and attribute.
Object: Defines the object, which the profile searches.
Attribute: Defines the attribute the profile monitors.
Write Mode: Provides the write access to the selected object and attribute.
Actions > Test Read: Checks the existence of the specified object and attribute. The function also checks for the the age of the attribute
Actions > Test Write: Writes the current time to the selected attribute of the object.
Note: Test Write enables only if you select the Write Mode check box.
profile name > Counter Name

This section lists the counters available for the object the profile monitors.
Publish Alarms: Select to publish alarms for the counter.
Enable/Disable: Select to enable or disable the defined threshold for the counter.
Operator: Specifies the comparison operator for verifying the number of rows returned against the threshold value.
Value: Specifies the alarm value of the profile response time.
Severity: Specifies the alarm severity when the profile response time exceeds the threshold value.
Message: Defines the alarm message issued when the profile response time exceeds the threshold value.
profile name > Options (icon) > Delete
Deletes the profile from the probe.
Response
This node lets you add a profile to the Response node to calculate and monitor the response time and the connect time of the server.
Navigation: ad_response > Active Directory > Response
Response > Options (icon) > Add Profile
This section lets you add a profile in the Response node.
Note: The field descriptions are same as described in the Add Profile section in the Replication node.
<Profile Name> Node

Navigation: ad_response > Active Directory > Response > Profile Name

Navigation: ad_response > Active Directory > Response > Profile Name > Server Name_Profile Name
The Server Name Profile Name node is used to identify the server that the probe monitors, and does not contain any field or section.
<Profile Name> Node

Navigation: ad_response > Active Directory > Response > Profile Name > Server Name_Profile Name > Profile Name
This section lets you configure the connection details for the profile to connect to the AD server.
Note: The field descriptions for General, Connection and Counter Name sections are same as described in the <Profile Name>
Node section in the Replication node.

Search
This node lets you create a profile, which calculates the search time and number of objects found.
Navigation: ad_response > Active Directory > Search
Response > Options (icon) > Add Profile
This section lets you add a profile in the Search node.
Note: The field descriptions are same as described in the Add Profile section in the Replication node.
<Profile Name> Node

Navigation: ad_response > Active Directory > Search > Profile Name

Navigation: ad_response > Active Directory > Search > Profile Name > Server Name_Profile Name
The Server Name Profile Name node is used to identify the server that the probe monitors, and does not contain any field or section.
<Profile Name> Node

Define the query that the profile monitors.
Navigation: ad_response > Active Directory > Search > Profile Name > Server Name_Profile Name > Profile Name
This section lets you configure the connection details for the profile to connect to the AD server.
profile name > Query
This section lets you define the search query, which the profile executes for monitoring and is available only for Search profiles.
Search Root Container: Specifies the objects to search in this field.
Include Subcontainers: Executes the query in the subcontainers under the root container.
Filter: Defines an LDAP query for the search.
Examples:
User id starting with "e": (sAMAccountName=e*)
User id NOT starting with "e": (!sAMAccountName=e*)
Last name starting with "a" and first name starting with "b": (&(sn=a*)(givenName=b*))
Last name starting with "a" or "b": (|(sn=a*)(sn=b*))
Actions > Test Query: Tests the query by performing a search in the root container. If the objects are found, the response time and
number of records are displayed.
Note: The field descriptions for General, Connection and Counter Name sections are same as described in the <Profile Name>
Node section in the Replication node.

v1.6 ad_response IM Configuration

The following diagram outlines the process to configure the probe to monitor:
Objects.
Contents
Verify that required hardware and software is available before you configure the probe. For more information, see ad_response (Active Directory
Response Monitoring) Release Notes.

This section describes the minimum required settings for the probe to connect to the AD server and monitor replication objects.
Follow these steps:
2. Select the Replication group under Active Directory.
3. Right-click in the right pane and select New to add a profile to the Replication group.
The Properties dialog appears with four tabs: General, Connection, Object and Counters that enable you to configure the profile
4. Click the General tab, specify the following profile information and click OK.
Additional description for the profile.
The time interval in minutes during which the profile collects QoS data.
5. Click the Connection tab to define the connection properties for the profile as follows:
Options:
Type: Select a connection type that the profile uses to connect to the AD server.
successful if at least one domain-controller (LDAP) or Global Catalog is available on the specified domain.
The fully qualified server address or domain name of the AD server.
6. Click Test Connection to test whether the connection defined in this profile is working or not. The confirmation message displays the
connection status. The message also displays the time that is taken to test the connection to the AD server.
7. Click the Counters tab that lists the counters available for the object being monitored by the profile.
Select a counter in the list and click Add.
The Response time threshold dialog appears.
Define the threshold value and severity for the selected counter, and click OK.
8. Define the following field values in the Object tab.
Write mode option to enable the profile to write to the selected attribute.
Test Read to verify if the object and attribute exists.
since the last modification. The age
Test Write to add current time to the selected attribute of the object.
10. Click OK.

12. A profile is added to the Replication folder.
13. Navigate to the new <profile name> node created in the Replication folder.
14. Specify the time interval in seconds in Sample Data Every (in seconds) during which the profile collects QoS data.
Reduce this interval to generate alarms faster, as the next interval takes lesser time but it can increase the system load. You can also
15. Select Enabled(runs at specified interval) to start sampling the data at the specified time interval.
16. In the Connection section, define the connection properties for the profile as follows:
Connection Type: Select a connection type that the profile uses to connect to the AD server.
successful if minimum one domain-controller (LDAP) or Global Catalog is available on the specified domain.
17. Click Actions > Test Connection to test whether the connection defined in this profile is working or not. The confirmation message
displays the connection status. The message also displays the time that is taken to test the connection to the AD server.
18. Define the values in the following fields in the Object section.
Write mode option to enable the profile to write to the selected object and attribute.
Actions > Test Read to verify if the object and attribute exists.
Actions > Test Write to add current time to the selected attribute of the object.
A new profile is created to monitor the replication object.

This section describes the minimum required settings for the probe to monitor the connection response time from the AD server.
Follow these steps:
2. Select the Response group under Active Directory.
3. Right-click in the right pane and select New to add a profile to the Response group.
The Properties dialog appears with three tabs: General, Connection and Counters that enable you to configure the profile
4. Navigate to the General, Connection, and Counter tabs.
A new profile is created to monitor the response time.

This section describes the minimum required settings for the probe to monitor the searched objects.
Follow these steps:
2. Select the Search group under Active Directory.
3. Right-click in the right pane and select New to add a profile to the Search group.
The Properties dialog appears with four tabs: General, Connection, Query and Counters that enable you to configure the profile
4. Navigate to the General, Connection, and Counter tabs.
6. Click the Query tab to query and filter the object for monitoring.
7. Specify the following field values.
The objects to search in the Search root container.
Enable searching the subcontainers within the root container.
The filter query for the search.
Example: Last name starting with "a" and first name starting with "b": (&(sn=a*)(givenName=b*))
8. Click Test Query.
9. The probe displays the response time and number of records that are found when the query is successful.
10. Click OK.
A new profile is created to monitor the search object.
v1.6 ad_response IM GUI Reference

The ad_response probe is configured by double-clicking the line representing the probe in the Infrastructure Manager. This brings up the
configuration tool for the probe, containing two window panes, a menu bar and a status bar. This article describes the fields and features of the
ad_response probe.
Contents
Probe GUI
Profile Properties
General tab
Connection Tab
Object Tab
Counters Tab
Query Tab
Probe GUI
Menu bar
The menu bar provides options to activate, deactivate, restart and exit the probe. You can also click Probe > Options to define the Log level.
Log level
Specifies the detail level of the log file. Log as little as possible during normal operation to minimize disk consumption, and increase the
amount of detail when debugging.
Default: Normal (0)
The probe also lets you manage the alarm messages available in the probe. Click Tools > Message pool manager to display Message Pool
Editor. The Editor allows you to create a new message, edit or delete an existing message.
Name: Indicates the message name, which is specified when you define thresholds in the probe.
Text: Indicates the variables that are used in the message.
Subsystem: Indicates the alarm subsystem. All profiles using the same connection use this ID as their alarm subsystem.
Left pane
The left pane contains a node called Active Directory, which further contains three groups. These groups are used to place functional profiles
together.
Replication
Response
Search
Right pane
The contents on the right pane depend on your selection in the left pane. The pane lists all the profiles of the group selected in the left pane. The
following information display about a profile:
The name of the profile
The server address (the fully qualified domain name)
If the profile is enabled or not
The poll interval (how often the profile collects data)
A short description of the profile
If you select the the Active Directory in the left pane, all the profiles are listed.
Icons
The icon next to the profile name in the list indicates the profile status. When you restart the probe, no icon is visible during the short initialization
period. After a few seconds, the following icons appear:
indicates an active profile, but no data is yet sampled. The sample period is defined in the profile properties.
indicates an inactive profile.
After the first sample period, one of the following icons should appear. Apart from green, other colors indicate the severity level of the threshold
breach.
Green means OK (Clear)
Information
Warning
Minor
Major
Critical
Profile Properties
Select one of the folders in the left pane, right-click in the right pane and select New to open the Properties dialog for a new profile. The
Properties dialog lets you specify the profile parameters.
General tab
The General tab lets you define the general properties of the profile.
The fields in the tab are explained as follows:
Name
A descriptive name of the profile.
Description
A short description of the profile to identify what you are monitoring.
Sample data every
Specifies how often the profile collects data. You can specify the interval in seconds, minutes, hours or days.
Default: 1 minutes
Enabled (runs at specified interval)
Select the check box to activate the profile. If activated, the profile samples the data at the specified poll interval.
Default: Deselected
Connection Tab
The Connection tab lets you define the connection properties for the profile.
Options
Type:
Specifies the connection type used by the profile to connect to the AD server. The available options are: LDAP and Global Catalog.
Default: LDAP
Use secure connection
Lets you use a secure connection ensuring that all communications are encrypted when connecting to the AD server.
Default: Selected
Bind to specific server
Binds the connection to the AD server specified in the Server address field. If the defined server is unavailable, the connection fails. On
deselecting the Bind to specific server option, the Domain name field replaces the Server address field. The connection is successful
if at least one domain-controller (LDAP) or Global Catalog is available on the specified domain.
Default: Selected
Server address: (Fully qualified domain name)
Defines the AD server address or the fully qualified domain name that the profile connects to for monitoring objects.
Authentication
User:
Defines the user name that the profile uses to connect to the AD server.
Password:
Defines the password of the user name to connect to the AD server.
Domain:
Defines the domain name with which the user connects to the AD server.
Test Connection
Tests the connection and displays the response time of connecting to the server.
Object Tab
The Object tab lets you define the object and attribute that the profile monitors. This tab is only applicable for the Replication profiles.
Container
Specifies the container in which the profile looks for the object and attribute.
Object
Defines the object, which the profile searches.
Attribute
Defines the attribute that the profile monitors.
Write mode
Provides the write access to the selected object and attribute.
Default: Deselected
Test Write
Writes the current time to the selected attribute of the object.
Test Read
Checks the existence of the specified object and attribute. The function also checks for the the age of the attribute since the last
modification.
Note: The Test Write field enables only if you enable Write mode option.
Counters Tab
The Counters tab lists the counters available for the object that the profile monitors.
Counters
Lists the counters available for the object.
Thresholds
Define one or more thresholds for the selected counter.
Select a counter in the list and click the Add button to set or modify the threshold value and severity for the selected counter.
Add
Lets you define a threshold value and associated severity level for the selected counter. You can define several thresholds and
also define the alarm messages.
Remove
Removes the selected threshold. This button enables only when you select a threshold in the list.
Send QoS
Sends QoS data on the counters defined in the profile.
Query Tab
The Query tab lets you define the search query, which the profile executes for monitoring and is available only for Search profiles.
Search root container:
Specifies the objects to be searched for in this field.
Include subcontainers
Executes a query in the subcontainers under the root container.
Default: Deselected
Filter:
Defines an LDAP query for the search.
Examples:
User id starting with "e": (sAMAccountName=e*)
User id NOT starting with "e": (!sAMAccountName=e*)
Last name starting with "a" and first name starting with "b": (&(sn=a*)(givenName=b*))
Last name starting with "a" or "b": (|(sn=a*)(sn=b*))
Test Query
Tests the query by performing a search in the root container. If the objects are found, the response time and number of records are
displayed.
ad_response Metrics
The following table describes the checkpoint metrics that can be configured using the ad_response probe.
Monitor Name
Units
Description
Version
QOS_AD_CONNECT_RESPONSE
Milliseconds
Measures the response time of connecting to the Active Directory (AD) server.
1.0
QOS_AD_REPLICATION_AGE
Seconds
Measures the time since the last replication of the AD server.
1.0
QOS_AD_SEARCH_OBJECTS
Count
Measures the number of the objects found by the search query.
1.0
QOS_AD_SEARCH_RESPONSE
Milliseconds
Measures the response time of the search query performed on the Active Directory (AD)
server.
1.0
ad_server (Active Directory Server Monitoring)

Active Directory is the directory service included with the Windows servers to manage the identities and relationships for managing network
environments.
The active directory server probe monitors the selected counters on Active Directory (AD). These counters measure the availability and response
time of the active directory server and perform health checks to prevent outage and degradation conditions.
The probe uses monitoring profiles, which are classified in the following eight predefined groups:
Event Logs: monitors the event logs for specific event IDs contents. For example, messages.
Filesystems: monitors the file systems for specific patterns.
Files: monitors for specific files.
Performance Counters: monitors the performance counters for a wide range of system objects. For example, disk, CPU performance,
and memory print queues.
Processes: monitors the wide range of counters for the different processes running on the system.
Services: monitors the services outside the AD that are essential to the proper operation of AD.
Windows Management Instrumentation (WMI): checks authentication failures and the inability to access resources.
Note: The probe does not support the WMI of Datatype Reference.
Health Monitor: monitors status and response time for all the objects. For example, monitor the operations master schema, fetch
number of lost and found objects, and fetch AD replication partner synchronization status.
Each of these groups can have more than one monitoring profile. The active directory server probe is delivered with a default configuration of a
selected set of profiles to be monitored. You can also define your own profiles containing more than one counter.
More information:
ad_server (Active Directory Server Monitoring) Release Notes
v1.8 ad_server AC Configuration

The Active Directory Server probe is configured to monitor health and performance of the Active Directory (AD) server by configuring the
threshold parameters for counters. This probe is delivered with a default configuration of a selected set of monitoring counters.
Note: The active directory server probe is a local probe, which monitors the AD server of the host system only.
The following diagram outlines the process to configure the probe to monitor Active Directory servers.
Contents
Create Monitoring Profile(s)
Add Monitoring Object Details
Add Monitor(s)
Alarm Thresholds
Precedence for Threshold Alarms
Verify that required hardware and software is available before you configure the probe. For more information, see ad_server (Active Directory
Server Monitoring) Release Notes.

Create a monitoring profile to monitor health and performance of the AD server.
Follow these steps:
1. Select a monitoring category in the left pane.
2. Click the Options (icon) and select Add Profile.
3. Enter a Name for the profile.
Note: You cannot enter slash(/) or comma in the profile name.
4. Enter a Description for the profile.

5. Define the time interval to execute the profile and collect data.
6. Specify the unit of the time interval.
7. Define a time delay to collect data from the AD server after the profile is activated.
8. Specify the unit of time delay.
9. Select Enabled (runs at specified interval) to activate the profile after it is created.
10. Click Submit button to create a profile.
Notes: Select an existing profile and edit the details in the General Configuration section.
Add Monitoring Object Details

You must specify additional details of the object to be monitored in the category section on the <profile name> node.
Eventlog
Enter the details of the Eventlog to be monitored.
Follow these steps:
1. Specify the log file to fetch the events for monitoring.
2. Enter the computer name where the event has occurred.
3. Define the source or the publisher of the event.
4. Specify the severity of the event.
5. Enter the Windows user account with the event is generated.
6. Define the event category.
7. Define the unique identification number of the event.
8. Specify the event message text.
File
Enter the details of the File to be monitored.
Follow these steps:
1. Define the path of the file to be monitored.
File System
Enter the details of the File System to be monitored.
Follow these steps:
1. Define the directory path or file system to be monitored.
2. Enter the regular expression specific pattern to search within the file system.
3. Select Include Subdirectories to search and include sub directories of the file system.
Health Monitors
Enter the details of the Health Monitor (s) to be monitored.

Follow these steps:
1. Enter the Search Root Criteria to fetch Response Time, Objects Found, and status counters value.
Performance Counters
Enter the details of the Performance Counter to be monitored.
Follow these steps:
1. Specify the performance object of the host to monitor.
2. Select the performance object instance to fetch data.
Process
Enter the details of the Process to be monitored.
Follow these steps:
1. Select the process to be monitored.
Service
Enter the details of the Service to be monitored.
Follow these steps:
1. Select the service to be monitored.
WMI
Enter the details of the WMI to be monitored.
Follow these steps:
1. Select the WMI namespace to be monitored.
2. Specify a class of the selected namespace to be monitored.
3. Enter the instance of the selected class to be monitored (when more than one instance is found).
Add Monitor(s)
A counter defines the area monitored by the profile. There is a list of predefined counters for each type of profile. You can add more than one
counter to a profile.
Important! The probe does not support counters, which return a datetime value.The probe GUI displays unexpected results when such
a counter is added to the profile.
Follow these steps:

1. Click the Options (icon) next to the Monitors node in the navigation pane.
2. Click the Add Monitor.
3. Select the counter from the Name drop-down list and click Submit.
Notes:
You can add counters for every predefined group or category. The option to add a counter for a profile appears only when
certain selection criteria are met, depending on which group is selected.
You can configure only two thresholds in probe version 1.71 or later. However, if more than two thresholds were configured in
the previous version(s), they are also available in the later versions..
Monitors can only be created for Performance Counter and WMI categories.
Alarm Thresholds
allow the probe to:
Precedence for Threshold Alarms

The precedence of alarm generation and string monitors follows an order rather than the defined severity of the threshold. For example: If an
existing threshold condition is ">=0' set at any severity, and a new threshold condition is set as "!=4000" of same or any other severity, an alarm
will be generated for ">=0".
The precedence for alarm generation is as follows:
1. >=
2. >
3. =
4. <=
5. <
6. !=
The precedence for string monitors is as follows:
1. contains
2. ends with
3. starts with
4. not equal
5. equal
v1.8 ad_server AC GUI Reference

The Active Directory Server probe is configured to monitor health and performance of the AD server by configuring the threshold parameters for
counters. This probe is delivered with a default configuration of a selected set of monitoring counters.
Note: The ad_server probe is a local probe, which monitors the Active Directory (AD) server of the host system only.
Important! If the probe is migrated using threshold_migrator, it displays the standard static threshold block instead of the probe-specific
alarm thresholds.
Contents
ad_server Node
Event Logs Node
<Profile Name> Node
File Node
<Profile Name> Node
File System Node
<Profile Name> Node
Health Monitor Node
<Profile Name> Node
Performance Counter Node
<Profile Name> Node
Process Node
<Profile Name> Node
Service Node
<Profile Name> Node
WMI Node
<Profile Name> Node
ad_server Node
The ad_server node lets you view the probe information and configure log level of the probe.
Navigation: ad_server
Set or modify the following values if needed:
ad_server > Probe Information
ad_server > General Configuration
This section is used to configure log level of the probe.
Log Level: specifies the detail level of the log file.
Default: 0 - Fatal
Event Logs Node

The Event Logs node is used to create and configure profiles for monitoring event logs of the host system. Each monitoring profile is displayed
under the Event Logs node.
<Profile Name> Node

The profile name is used to configure properties for monitoring the event logs of the host system.
Navigation: ad_server > Event Logs > profile name
Set or modify the following values as required:
This section lets you edit the properties which are defined at time of creating a profile.
Sample Data Every: defines the time interval for executing the profile and collecting data.
Sample Data Every (Unit): specifies a time interval unit.
Default: 0
Startup Delay: defines a time delay for collecting data from the AD server after activating the profile.
Startup Delay (Unit): specifies a unit of time delay.
Default: 0
<profile name> Node > Options (icon) > Delete Profile
The option allows you to delete a profile.
profile name > Event Log
This section defines the criteria for monitoring the Windows event logs.
Log: specifies the log file for fetching the events for monitoring.
Computer: defines the computer name where the event has occurred.
Source/Publisher: defines the source or the publisher of the event.
Severity: specifies the event severity.

User: defines the Windows user account for whom the event is generated.
Category: defines the event category.
Event ID: defines the unique identification number of the event.
Message: defines the event message text. Use the regular expressions for identifying the message string.
Note: Specify only those fields, which are required for filtering the event logs and keep all other fields blank. Do not use
asterisk (*) in any other field because the regex is unsupported for filtering event logs.
File Node
The File node is used for monitoring host system files. Each monitoring profile is displayed under the File node.
<Profile Name> Node

This node lets you define the files, which the profile monitors.
Navigation: ad_server > Files > profile name
profile name > File
This section lets you define the complete path of the file to be monitored.
Note: The fields of the General and the Monitors sections are same as described in the profile name node under the Event
Logs node.
File System Node

The File System node defines the file system, for example, C: and C:\program Files, for monitoring. The ad_server probe checks the directory
existence, file existence, size of the directory, oldest file age and newest file age.
<Profile Name> Node

The profile name node lets you configure the file system, which the profile monitors.
Navigation: ad_server > File System > profile name
profile name > File System
This section lets you define the directory path for monitoring.
Directory: defines the directory path or file system for monitoring.
Pattern: defines the pattern (for example, the name of a file) to search within the file system.
Include Subdirectories: lets you search and include sub directories of the file system.
Logs node.
Health Monitor Node

The Health Monitor node lets you configure counters for monitoring the AD Server health. These counters help you understand that current
activities of the AD Server are within normal and healthy parameters. The Health Monitor node contains the following counters:
Response Time: calculates the connection (bind) time for getting a response from the object. For example, use this counter for fetching
the last bind time of the following objects:
Operations Master Infrastructure
Operations Master Domain naming

Operations Master Primary Domain Controller (PDC)
Operations Master Relative Identifier (RID)
Operations Master Schema
Important! The Response Time counter is not applicable for replication profiles and returns a NULL value.
Object Found: calculates the number of objects in the target root folder of the server. For example, use this counter for fetching the AD
lost objects and number of domain controller replication partners.
Status: monitors the object availability. For example, use this counter for fetching status of the lost and found object container and AD
replication partners' synchronization status.
Note: The probe contains a default set of health monitoring profiles for demonstrating counters usage. All monitoring profiles
are deactivated, by default; you can activate them manually.

The option allows you to delete a profile.
<Profile Name> Node

The profile name node lets you configure the health monitoring profile properties.
Navigation: ad_server > Health Monitor > profile name
profile name > Health Monitor
This section lets you configure the search root criteria for identifying a monitoring object of the AD server.
Search Root Criteria: specifies the search root criteria to fetch Response Time, Objects Found, and status counters value. Mention
replication for a replication profile and for the PDC profile leave it blank. Enter search criteria for a normal profile in the DC=demodo
main,DC=local format.
Logs node.

The Performance Counter node lets you fetch performance data from the performance counters. The performance data provides health
information about Operating System, Network, Applications, Services, and so on.
<Profile Name> Node

The profile name node configures a monitoring profile for consuming data from the performance counters. This data is used for comparing actual
values with the threshold values and generate alarms and QoS.
Navigation: ad_server > Performance Counter > profile name
profile name > Performance Counter
This section lets you define performance object and instance for monitoring.
Object: specifies the performance object of the host for monitoring.
Instance: specifies the performance object instance for fetching data.
profile name > Monitors
This section lets you select the appropriate counters from the list and configure counter thresholds. The probe lets you configure two
thresholds for each counter.
Notes:
The fields of the General and the Monitors sections are same as described in the profile name node under the Event Logs
node.
Use the Add Monitor option on the profile name node for adding any monitor to the list.
Severity: specifies the alarm message severity.
Operator: specifies the threshold operator for comparing the actual and threshold value.
Value: defines the counter threshold value for generating alarms.
Message: specifies the alarm message when the threshold value breaches.
Similarly, you can configure the second threshold for the counter in the corresponding Severity 2, Operator, Value,
and Message fields.
<monitor name> Node > Options (icon) > Delete Monitor

The option allows you to delete a monitor.
Process Node
The Process node lets you monitor the running processes of the host system (for example, notepad.exe).
<Profile Name> Node

The profile name node lets you configure the monitoring parameters of the process, which the probe is monitoring.
Navigation: ad_server > Process > profile name
profile name > Process
This section lets you specify the process for monitoring.
Logs node.
Service Node
The Service node lets you monitor running services of the host system (for example, DNScache).
<Profile Name> Node

The profile name node lets you configure parameters of the service, which the probe is monitoring.
Navigation: ad_server > Service > profile name
profile name > Service
This section lets you specify the service for monitoring.
Note: The fields of the General and the Counter: Counter Name sections are same as described in the profile name node
WMI Node
The WMI node is used for creating a monitoring profile for fetching WMI-related data from the host system. The WMI data is used for
consolidating the management of devices and applications in a network from the Windows environment.
<Profile Name> Node

The profile name node lets you configure the WMI parameters for getting status of the local and remote systems.
Navigation: ad_server > WMI > profile name
profile name > WMI
This section lets you specify the process that the profile is monitoring.
Namespace: specifies the WMI namespace for monitoring. For example, CIMV2.
Class: specifies a class of the selected namespace for monitoring. For example, Win32_process.
Instance: specifies the instance of the selected class for monitoring, when more than one instance is found. For example, notepad.ex
e.
Logs node.

This section lets you select the appropriate counters from the list and configure counter thresholds. The probe lets you configure two
thresholds for each counter.
Note: Use the Add Monitor option on the profile name node for adding any monitor to the list.
and Message fields.
<monitor name> Node > Options (icon) > Delete Monitor

The option allows you to delete a monitor.
v1.8 ad_server IM Configuration

The Active Directory Server probe is configured to monitor health and performance of the Active Directory Server (AD) server by configuring the
threshold parameters for counters. This probe is delivered with a default configuration of a selected set of monitoring counters.
Content
Create Monitoring Profile
Adding Counters
Verify that required hardware and software is available before you configure the probe. For more information, see ad server (Active Directory
Server) Release Notes.
Create Monitoring Profile

Follow these steps:
2. Right click on the right pane and click New.
3. Specify the name and description for the profile.
4. Specify the poll interval for profile.
5. Define a time delay before a profile starts polling.
6. Select Enabled (runs at specified interval) to sample the data at the poll interval specified.
Notes:
When you rename a profile, save the configuration and restart the probe to activate it.
You cannot enter slash (/) or comma (,) in the profile name.
General and Counters tabs are common profiles, while the third tab is specific to the selected monitoring category.
The Counters list will only be generated, after the name and description has been entered for the profile.
The Description does not support multi-line text.
You cannot copy content into Name and Description fields.
7. Click OK to create the profile.
Note: Select an existing profile to edit as needed.
Adding Counters
This tab lists the counters available for the category being monitored by the profile. This tab is valid for all types of profiles.
Follow these steps:
1. Select a Counter from the list.
2. Select Send QoS data to enable QoS.
3. Select Send Alarm to send alarms on the counters defined in the profile.
4. Click Add to specify a threshold value and associated severity level for the selected counter.
5. Select the Value of the counter.
6. Select the Severity of the counter.
7. Select the Message for the counter.
Note: The Message Text and the Subsystem is displayed automatically according to the message selected.
8. Click OK to create a counter.

The counter for the profile is created.
Notes:
You can edit the Counters for existing profiles with the mentioned steps.
You can select a threshold in the Counters tab and click Remove to delete the threshold associated to the required counter.
the previous version(s), they are still available in this version.
v1.8 ad_server IM GUI Reference

This article describes the fields and features of the Active Directory Server probe. This probe monitors selected checkpoints on Active Directory,
through profiles which are grouped into pre-defined groups or categories.
Probe GUI
The Application Window
General Tab
Variable Tab
Probe GUI
The probe is configured by double-clicking the probe in the Infrastructure Manager, which brings up the GUI (configuration tool).
The window consists of two panes, a menu bar at the top and a status bar at the bottom.
Notes:
Select Help > Show help from the menu bar or from the Help button at the bottom right for online help documentation.
Alternatively, you can press the F1 key for quick access.
Click the Apply button to activate any configuration modifications done.
The left pane

The left-pane contains a node, active directory server. Under this node, there are seven logical groups for different profiles:
Eventlogs
Files
Filesystems
Health Monitor
Performance counters
Processes
Services
WMI
If you select active directory server node, all default profiles are displayed in the right pane. You can also define new profile(s).
Each profile can contain several counters.
The right pane
This pane lists the profiles. Select the Active Directory Server node in the left pane to open profiles in the right pane.
Select the active directory server node in the left pane to open categorized profiles under groups. The following information can be found in the
list:
The name of the profile
If the profile is enabled or not
The last status message of the profile
The group name for each profile is shown in the list.
Profile Status
The icons indicate the profile status.
Note: The profile status icon appears after a short initialization period.
indicates an active profile, but data is not sampled yet. The sample period is defined in the profile property dialog.
After the first sample period, one of the following icons appears.
Green means OK (Clear).
Other colors indicate the severity level for breaching the threshold value of profile:
Information
Warning
Minor
Major
Critical
The Menu bar
The option in the menu bar helps in managing the probe.
File
This menu entry contains two options:

Save
Saves configuration modifications.
Note: You can also save configuration modifications by simultaneously pressing Ctrl+S on your keyboard.
Exit
Quits the configuration tool. If you have modified your configuration, save the changes before exiting.
Probe
This menu entry contains four options:
Activate
Starts the probe again and the status Started is displayed in the Status bar.
This option is enabled only when the probe is stopped/deactivated.
Deactivate
Stops the probe and the status Stopped is displayed in the Status bar.
This option is enabled only when the probe is activated.
Restart
Stops and then starts the probe.
Options
Sets the log level details of the probe. Maintain log as less as possible, to minimize the disk consumption. Increase the log level
temporarily for debugging purposes.
Help
This Help menu contains two options:
Show help
Displays the probe documentation.
You can also press F1 key or click the Help button at the bottom right.
About
Displays the version of the probe.
General Tab
You can define the general properties for the profile.
This tab is valid for all types of profiles.
The fields in the dialog are explained below:
Name
Defines the name of the profile.
Notes:
Do not enter characters like slash (/) or comma (,) in the profile name.
Sve the configuration and restart the probe to activate the profile, if you rename a profile.
Description
Provides a short description of the profile.
This description is not displayed in the list of profiles in the right pane.
Sample data every
Specifies the profile poll interval in seconds, minutes, hours or days.
Startup delay
Defines a delay in seconds, minutes, hours or days, before a profile starts polling.
Enables the profile to sample the data at the poll interval specified.
Variable Tab
The variable tab is the 3rd tab in the New Profile window. The name of this tab(s) is dependent on the selected monitoring category.
The Eventlog tab
The log file to be monitored by the profile, is defined in this tab.

This tab is valid for Eventlog profiles only.
The fields in the dialog are explained here:
Log
Specifies the log file that the profile will monitor.
Computer
Defines the name of a computer to be searched for in entries in the log file.(Optional)
Source
Defines the name of a source to be searched for entries in the log file.(Optional)
Severity
(Optional) Specifies the severity to be searched for in entries in the log file.
User
(Optional) Defines the name of a user to be searched for in entries in the log file.
Category
(Optional) Defines the category to be searched for in entries in the log file.
Event ID
(Optional) Defines an event ID to be searched for in entries in the log file.
Message
(Optional) Defines a message to be searched for in entries in the log file.
Note: Specify only those fields, which are required for filtering the event logs and keep all other fields blank. Do not use an asterisk (*)
in any other field because the regex is unsupported for filtering event logs.
The Files tab

This tab lets you define the performance object that the profile will monitor.
This tab is valid for File profiles only.
The field in this dialog is explained below:
File
Defines a specific file to monitor. The probe checks if the file is created or changed.
The Filesystem tab
This tab lets you define the Filesystem that the profile will monitor.
This tab is valid for Filesystem profiles only.
Directory
Defines the filesystem to be monitored for a specific pattern.
The probe checks the size of the directory, the file and age of the oldest and newest file.
Pattern
Defines the pattern (For Example, the name of a file) to be searched for within the specified filesystem
Include subdirectories
Selects the subdirectories for the defined directory.
The Performance counters tab
This tab lets you define the performance object that the profile will monitor.
This tab is valid for Performance counter profiles only.
The fields in this dialog are explained below:
Object
Specifies the performance object available on the host to be monitored.
Description
Indicates a read-only field containing a description of the selected performance object.
Instance
Specifies the instance of an object available on the system.
The field is disabled, if the the instance is not available.
The Process tab
This tab lets you define the process the profile will monitor.
This tab is valid for Processes profiles only.
The fields in this dialog are explained below:
Process name
Specifies the process that the profile will monitor.
The Service tab
This tab lets you define the service that the profile will monitor.
This tab is valid for Service profiles only.
Service
Specifies the service to that the profile will monitor.
Display name
Identifies the name of the service.
Description
Indicates a brief description of the selected service.
The WMI tab
This tab lets you define the WMI to that the profile will monitor.
This tab is valid for WMI profiles only.
Namespace
Specifies the namespace of the WMI to be monitored.
Class
Specifies the class to be monitored.
Instance
Specifies the instance, where more than one is found.
The Health Monitor tab
This tab lets you monitor the health of the ad_server.
Search Root Criteria
Defines the search root criteria to fetch Response Time, Objects Found, and Status counters value. Mention replication for a
replication profile and for the PDC profile leave it blank. Enter search criteria for a normal profile in the DC=demodomain,DC=local form
at.
The fields of the Counters Tab are explained as follows:
Note: The probe does support counters, which return a date time value. The probe displays an error when you try adding a threshold
for an unsupported counter.
Thresholds
The counters available depends on category:

EventLog
EventFound (true/false)
NumberOfEventsFound
Files
Changed: seconds since file was changed
Created : seconds since file was created
NotFound (true / false)
Filesystems
Directories: Number of directories in the directory specified.
NotFound (true / false). This is set to true is critical for default Filesystem profiles.
FileAgeNewest: Age in seconds of the newest file in the directory.
FileAgeOldest: Age in seconds of the oldest file in the directory.
Files: Number of files in the directory specified.
TotalSize: Size of all the files in the directory specified, in bytes.
The ad_server configuration: (pre-configured)
C:\ , TotalSize > 50000000000.
And C:\Windows\NTDS\ ntds.dit , TotalSize > 50000000000.
Will vary with the type of counter.
As given for the ad_server configuration.
LSASS: % Processor time, default threshold value: = 50 is warning.
IO Read bytes per sec: > 100000 is major.
IO Write bytes per sec: > 100000 is major.
Page faults/sec: > 1000 is major.
NTFRS: the same as for LSASS.
Processes
As given for the ad_server configuration: none pre-configured.
Services
Default monitored services:
Lan Manager, File replication service, DNS client, Security accounts manager, Intersite messaging, Kerberos key distribution center,
net logon.
Threshold for all Services: State != Running is minor.
Health Monitor
The Health Monitor tab lets you configure counters for monitoring the AD Server health. These counters help you understand that
current activities of the AD Server are within normal and healthy parameters. The Health Monitor tab contains the following counters:
Response Time: calculates the connection (bind) time for getting a response from the object. For example, use this counter for
fetching the last bind time of the Operations Master Infrastructure, Operations Master Domain naming, Operations Master
Primary Domain Controller (PDC), Operations Master Relative Identifier (RID), and Operations Master Schema objects.
Note: The probe contains a default set of health monitoring profiles for demonstrating counters usage. All monitoring
profiles are deactivated, by default; you can activate them manually.
WMI
Default monitores wmi counters:
Microsoft_DomainTrustStatus (exist only on windows 2003 server), TrustIsOK, false is critical.
MSAD_ReplNeighbor(exist only on windows 2003 server), ModifiedNumConsecutiveSyncFailures, > 0 is critical, and
NumConsecutiveSyncFailures, > 0 is critical.
Select a message to be issued if the threshold specified is breached. The Text and Subsystem fields are read-only.
Send QoS data
The probe sends QoS data on the counters defined in this profile.
Send Alarm
The probe sends alarms on the counters defined in this profile.
Add
Allows you to define a threshold value and associated severity level for the selected counter (see above).
You can define several thresholds.
Remove
Removes the selected threshold. This button is enabled only when a threshold is selected in the threshold list.
v1.7 ad_server AC Configuration

Note: The Active Directory Server probe is a local probe, which monitors the AD server of the host system only
How to Monitor an AD Sever

Adding Counters
Alarm Thresholds
Delete Profile
How to Monitor an AD Sever

This section describes the minimum configuration settings required to configure the ad_server probe.
Follow these steps:
1. Click the Options icon next to the monitoring category in the navigation pane.
2. Click the Add Profile option.
Refer Create Monitoring Profile.
3. Enter profile details in the General dialog and click Submit.
The profile is displayed under the selected node with all applicable counters.
4. Enter the details in the applicable Counter section(s).
Refer Adding Counters.
5. Click Save.
The profile is added under the appropriate group node and all configured monitors list is displayed in the Monitors section of the profile
name node.
Note: You can also edit an existing profile.

2. Click the Options (...) tab and select Add Profile.
3. Update the required fields in the General dialogue.
4.
4. Specify the sampling and delay intervals for the profile.

6. Click Submit button to create a profile.
7. Configure the properties of the applicable Counters.
8. Click Save button.
Note: The Counters for each profile are specific to monitoring category.
Adding Counters
A counter defines the area, which the profile monitors. For each type of profile, there is a list of predefined counters. You can add more than one
counter to the profile.
Important! The probe does not support those counters, which returns a datetime value. The probe GUI shows unexpected results
when any such counter is added to the probe.
Follow these steps:

1. Click the Options icon next to the profile name node in the navigation pane.
2. Click the Add Counter option.
3. Select the counter from the Name drop-down list and click Submit.
The new counter is added in the list of Monitors section of the profile name node.
Notes:
You can add counters for every predefined group or category. The option to add a counter for a profile appears only when
certain selection criteria are met, depending on which group is selected.
the previous version(s), they will be available in this version also.
Alarm Thresholds
allow the probe to:
Delete Profile
You can delete a monitoring profile when you no longer want the probe to monitor it.
Follow these steps:
1. Click the Options icon next to the profile name node that you want to delete.
2. Click the Delete Profile option.
3. Click Save.
The profile is deleted.
v1.7 ad_server AC GUI Reference

The active directory server probe is configured to monitor health and performance of the AD server by configuring the threshold parameters for
Content
ad_server Node
Event Logs Node
<Profile Name> Node
File Node
<Profile Name> Node
File System Node
<Profile Name> Node
<Profile Name> Node
Process Node
<Profile Name> Node
Service Node
<Profile Name> Node
WMI Node
<Profile Name> Node
Health Monitor Node
<Profile Name> Node
ad_server Node
The ad_server node lets you view the probe information and configure log level of the probe.
Navigation: ad_server
ad_server > Probe Information
ad_server > General Config
Default: 0 - Fatal
Event Logs Node

The Event Logs node is used to create and configure profiles for monitoring event logs of the host system. Each monitoring profile is displayed
<Profile Name> Node

The profile name is used to configure properties for monitoring the event logs of the host system.
Notes:
This node is user-configurable and is named as the profile name node.
You cannot enter characters like slash (/) or comma (,) in the profile name.
Navigation: ad_server > Event Logs > profile name

This section lets you edit the properties which are defined at time of creating a profile.
Sample Data Every: defines the time interval for executing the profile and collecting data.
Sample Data Every (Unit): specifies a time interval unit.
Startup Delay: defines a time delay for collecting data from the AD server after activating the profile.
Startup Delay (Unit): specifies a unit of time delay.
profile name > Event Log
This section defines the criteria for monitoring the Windows event logs.
Log: specifies the log file for fetching the events for monitoring.
Computer: defines the computer name where the event has occurred.
Source: defines the source or the publisher of the event.
Severity: specifies the event severity.
User: defines the Windows user account for whom the event is generated.
Message: defines the event message text. Use the regular expressions for identifying the message string.
Note: Specify only those fields, which are required for filtering the event logs and keep all other fields blank. Do not use
asterisk (*) in any other field because the regex is unsupported for filtering event logs.
File Node
The File node is used for monitoring host system files. Each monitoring profile is displayed under the File node.
<Profile Name> Node

This node lets you define the files, which the profile monitors.
Navigation: ad_server > Files > profile name
profile name > File
This section lets you define the complete path of the file to be monitored.
Logs node.
File System Node

The File System node defines the file system, for example, C: and C:\program Files, for monitoring. The Active Directory Server probe checks
the directory existence, file existence, size of the directory, oldest file age and newest file age.
<Profile Name> Node

The profile name node lets you configure the file system, which the profile monitors.
Navigation: ad_server > File System > profile name
profile name > File System
This section lets you define the directory path for monitoring.
Directory: defines the directory path or file system for monitoring.
Pattern: defines the pattern (for example, the name of a file) to search within the file system.
Include Subdirectories: lets you search and include sub directories of the file system.
Logs node.
Note: Use the Add Monitor option on the profile name node for adding any monitor to the list.
and Message fields.

The Performance Counter node lets you fetch performance data from the performance counters. The performance data provides health
information about Operating System, Network, Applications, Services, and so on.
<Profile Name> Node

The profile name node configures a monitoring profile for consuming data from the performance counters. This data is used for comparing actual
values with the threshold values and generate alarms and QoS.
Navigation: ad_server > Performance Counter > profile name
profile name > Performance Counter
This section lets you define performance object and instance for monitoring.
Object: specifies the performance object of the host for monitoring.
Instance: specifies the performance object instance for fetching data.
Logs node.
Process Node
The Process node lets you monitor the running processes of the host system (for example, notepad.exe).
<Profile Name> Node

The profile name node lets you configure the monitoring parameters of the process, which the probe is monitoring.
Navigation: ad_server > Process > profile name
profile name > Process
This section lets you specify the process for monitoring.
Logs node.
Service Node
The Service node lets you monitor running services of the host system (for example, Dnscache).
<Profile Name> Node

The profile name node lets you configure parameters of the service, which the probe is monitoring.
Navigation: ad_server > Service > profile name
profile name > Service
This section lets you specify the service for monitoring.
Note: The fields of the General and the Counter: Counter Name sections are same as described in the profile name node
WMI Node
The WMI node is used for creating a monitoring profile for getting WMI-related data from the host system. The WMI data is used for consolidating
the management of devices and applications in a network from the Windows environment.
<Profile Name> Node

The profile name node lets you configure the WMI parameters for getting status of the local and remote systems.
Navigation: ad_server > WMI > profile name
profile name > WMI
This section lets you specify the process that the profile is monitoring.
Namespace: specifies the WMI namespace for monitoring. For example, CIMV2.
Class: specifies a class of the selected namespace for monitoring. For example, Win32_process.
Instance: specifies the instance of the selected class for monitoring, when more than one instance is found. For example, notepad.ex
e.
Logs node
Health Monitor Node

The Health Monitor node lets you configure counters for monitoring the AD Server health. These counters help you understand that current
activities of the AD Server are within normal and healthy parameters. The Health Monitor node contains the following counters:
Response Time: calculates the connection (bind) time for getting a response from the object. For example, use this counter for fetching
the last bind time of the following objects:
Operations Master Infrastructure
Operations Master Domain naming
Operations Master Primary Domain Controller (PDC)
Operations Master Relative Identifier (RID)
Operations Master Schema
Object Found: calculates the number of objects in the target root folder of the server. For example, use this counter for fetching the AD
lost objects and number of domain controller replication partners.
Status: monitors the object availability. For example, use this counter for fetching status of the lost and found object container and AD
replication partners' synchronization status.
Note: The probe contains a default set of health monitoring profiles for demonstrating counters usage. All monitoring profiles
are deactivated, by default; you can activate them manually.\
<Profile Name> Node

The profile name node lets you configure the health monitoring profile properties.
Navigation: ad_server > Health Monitor > profile name
profile name > Health Monitor
This section lets you configure the search root criteria for identifying a monitoring object of the AD server.
Search Root Criteria: specifies the search root criteria to fetch Response Time, Objects Found, and status counters value. Mention
replication for a replication profile and for the PDC profile leave it blank. Enter search criteria for a normal profile in the DC=demodo
main,DC=local format.
Logs node.
v1.7 ad_server IM Configuration

Note: The Active Directory Server probe is a local probe, which monitors the AD server of the host system only.
How to Monitor an AD Server

Adding Counters to a Profile
Editing Monitoring Profile
How to Monitor an AD Server

This section describes the minimum configuration settings required to configure the ad_server probe.
Follow these steps:
1. Open the ad_server probe configuration interface.
2. Select a monitoring category on the left pane.
3. Create a new monitoring profile. You can also use the existing default profiles.
Refer Creating Monitoring Profile(s).
Note: You can also edit an existing profile. Refer Editing Monitoring Profile for more information.
4. Create a Counter for the new monitoring profile. You can also edit the counters for existing profiles.
Refer to Adding Counters to a Profile.
5. Save the configuration to start monitoring.

Follow these steps:
2. Right click on the right pane and click New.
3. Specify the name and description for the profile in the General tab.
4. Specify the sampling and delay intervals for the profile.
6. Specify the details of the applicable category.
Notes:
General and Counters tab(s) is common for all types of profiles, while the third tab is specific to the monitoring category.
The Counters tab will only be enabled, after a profile has been created.
Adding Counters to a Profile

This tab lists the counters available for the catagory being monitored by the profile. This tab is valid for all types of profiles.
Follow these steps:
1. Select a Counter from the list.
2. Specify the threshold, severity, and alarm message for the counter.
3. Select Send QoS data to enable QoS alarms.
4. Click on Add button to add thresholds for the alarms.
5.
5. Select Send Alarms to enable alarms.

6. Click OK to create a counter.
The counter for the profile is created.
Notes:
You can edit the Counters for existing profiles with the above steps.
You can select a threshold in the Counters tab and click Remove to delete the threshold associated to the required counter.
the previous version(s), they will be available in this version also.
Editing Monitoring Profile

You can edit and use an existing profile from the default profiles that are available with the probe.
Follow these steps:
1. Double-click the profile.
You can also right-click and select Properties.
Note: Right-click and select Delete to delete the profile.
2. Edit the parameters of the profile in all the 3 tabs.

3. Click OK to update the profile.
An existing profile is now updated.
v1.7 ad_server IM GUI Reference

This article describes the configuration concepts and procedures for setting up the ad_server probe. This probe is configured to monitor the
selected checkpoints on Active Directory, through profiles which are grouped into pre-defined groups or categories.
Probe GUI
The General Tab
The <variable> Tab
Probe GUI
The active directory server probe is configured by double-clicking the probe in the Infrastructure Manager, which brings up the GUI
(configuration tool).
The application window
The window consists of two panes, a menu bar at the top and a status bar at the bottom.
Notes:
Select Help > Show help from the menu bar or from the Help button at the bottom right for online help documentation.
Alternatively, you can press the F1 key for quick access.
Click the Apply button to activate any configuration modifications done.
The left pane

The left-pane contains a node, active directory server. Under this node, there are seven logical groups for different profiles:
Eventlogs
Files
Filesystems
Processes
Services
WMI
Health Monitor
If you select active directory server node, all default profiles are displayed in the right pane.You can also define new profile(s).
Each profile can contain several counters.
The right pane
This pane lists the profiles. Select the active directory server node in the left pane to open profiles in the right pane.
Select the active directory server node in the left pane to open categorized profiles under groups. The following information can be found in the
list:
If the profile is enabled or not.
The last status message of the profile.
The group name for each profile is shown in the list.
Profile Status
The below mentioned icons indicate the profile status.
The profile status icon only occur after a short initialization period.
indicates an active profile, but data is not sampled yet. The sample period is defined in the profile property dialog.
After the first sample period, one of the following icons appears.
Green means OK (Clear).
Other colors indicate the severity level for breaching the threshold value of profile:
Information
Warning
Minor
Major
Critical
The Menu bar
The option in the menu bar helps in managing the probe.
File
This menu entry contains two options:

Save
Saves configuration modifications.
Note: You can also save configuration modifications by simultaneously pressing the Ctrl+S keys on your keyboard.
Exit
Quits the configuration tool. If you have modified your configuration, save the changes before exiting.
Probe
This menu entry contains four options:
Activate
Starts the probe again and the status Started is displayed in the Status bar.
This option is enabled only when the probe is stopped/deactivated.
Deactivate
Stops the probe and the status Stopped is displayed in the Status bar.
This option is enabled only when the probe is activated.
Restart
Stops and then starts the probe.
Options
Sets the log level details of the probe. Maintain log as less as possible, to minimize disk consumption. Increase the log level
temporarily for debugging purposes.
Help
This Help menu contains two options:
Show help
Displays the probe documentation.
You can also press F1 key or click the Help button at the bottom right.
About
Displays the version of the probe.
The General Tab

You can define the general properties for the profile.
This tab is valid for all types of profiles.
The fields in the above dialog are explained below:
Name
Defines the name of the profile.
Notes:
You must not enter characters like slash (/) or comma (,) in the profile name.
If you rename any profile, you must save the configuration and restart the probe to activate the profile.
Description
Provides a short description of the profile.
This description will not be displayed in the list of profiles in the right pane.
Sample data every
Specifies the profiles poll interval in seconds, minutes, hours or days.
Startup delay
Defines a delay in seconds, minutes, hours or days, before a profile starts polling.
Enables the profile to sample the data at the poll interval specified.
The <variable> Tab

The variable tab is the 3rd tab in the New Profile window. The name of this tab(s) is dependent on the selected monitoring category.
All these tabs are explained below in detail.
The Eventlog tab

This tab lets you define the log file to be monitored by the profile.
This tab is valid for Eventlog profiles only.
Log
Specifies the log file to be monitored by this profile.
Computer
Defines the name of a computer to be searched for in entries in the log file.(Optional)
Source
Defines the name of a source to be searched for entries in the log file.(Optional)
Severity
Specifies the severity to be searched for in entries in the log file. (Optional)
User
Defines the name of a user to be searched for in entries in the log file. (Optional)
Category
Defines the category to be searched for in entries in the log file.(Optional)
Event ID
Defines an event ID to be searched for in entries in the log file. (Optional)
Message
Defines a message to be searched for in entries in the log file. (Optional)
Note: Specify only those fields, which are required for filtering the event logs and keep all other fields blank. Do not use asterisk (*) in
any other field because the regex is unsupported for filtering event logs.
The Files tab

This tab lets you define the performance object to be monitored by the profile.
This tab is valid for File profiles only.
The field in the above dialog is explained below:
File
Defines a specific file to monitor. The probe checks if the file is created or changed.
The Filesystem tab
This tab lets you define the Filesystem to be monitored by the profile.
This tab is valid for Filesystem profiles only.
Directory
Defines the filesystem to be monitored for a specific pattern. The probe checks the directory, the size of the directory, the file and age of
the oldest and newest file.
Pattern
Defines the pattern (e.g. the name of a file) to be searched for within the filesystem specified.
Include subdirectories
Selects the subdirectories for the defined directory.
The Performance counters tab
This tab lets you define the performance object to be monitored by the profile.
This tab is valid for Performance counter profiles only.
Object
Specifies the performance object available on the host to be monitored.
Description
Indicates a read-only field containing a description of the selected performance object.
Instance
Specifies the instance of an object if available on the system. Otherwise, the field is grayed out.
The Process tab
This tab lets you define the process to be monitored by the profile.
This tab is valid for Processes profiles only.
Process name
Specifies the process to be monitored by this profile.
The Service tab
This tab lets you define the service to be monitored by the profile.
This tab is valid for Service profiles only.
Service
Specifies the service to be monitored by the profile.
Display name
Identifies the name of the service.
Description
Indicates a brief description of the selected service.
The WMI tab
This tab lets you define the WMI to be monitored by the profile.
This tab is valid for WMI profiles only.
Namespace
Specifies the namespace of the WMI to be monitored.
Class
Specifies the class to be monitored.
Instance
Specifies the instance, if more than one is found.
The Health Monitor tab
This tab lets you monitor the health of the ad_server.
Search Root Criteria
Defines the search root criteria to fetch Response Time, Objects Found, and status counters value. Mention replication for a
replication profile and for the PDC profile leave it blank. Enter search criteria for a normal profile in the DC=demodomain,DC=local form
at.
The fields of the Counters Tab are explained as follows:
Note: The probe does support counters, which return a date time value. The probe displays an error when you try adding a threshold
for an unsupported counter.
Thresholds
The counters available depends on category:
EventLog
EventFound (true/false)
NumberOfEventsFound
Files
Changed: seconds since file was changed
Created : seconds since file was created
NotFound (true / false)
Filesystems
Directories: Number of directories in the directory specified.
NotFound (true / false). This is set to true is critical for default Filesystem profiles.
FileAgeNewest: Age in seconds of the newest file in the directory.
FileAgeOldest: Age in seconds of the oldest file in the directory.
Files: Number of files in the directory specified.
TotalSize: Size of all the files in the directory specified, in bytes.
The ad_server configuration: (pre-configured)
C:\ , TotalSize > 50000000000.
And C:\Windows\NTDS\ ntds.dit , TotalSize > 50000000000.
Will vary with the type of counter.
LSASS: % Processor time, default threshold value: = 50 is warning.
IO Read bytes per sec: > 100000 is major.
IO Write bytes per sec: > 100000 is major.
Page faults/sec: > 1000 is major.
NTFRS: the same as for LSASS.
Processes
As given for the ad_server configuration: none pre-configured.
Services
Default monitored services:
Lan Manager, File replication service, DNS client, Security accounts manager, Intersite messaging, Kerberos key distribution center,
net logon.
Threshold for all Services: State != Running is minor.
Health Monitor
The Health Monitor tab lets you configure counters for monitoring the AD Server health. These counters help you understand that
current activities of the AD Server are within normal and healthy parameters. The Health Monitor tab contains the following counters:
Response Time: calculates the connection (bind) time for getting a response from the object. For example, use this counter for
fetching the last bind time of the Operations Master Infrastructure, Operations Master Domain naming, Operations Master
Primary Domain Controller (PDC), Operations Master Relative Identifier (RID), and Operations Master Schema objects.
Note: The probe contains a default set of health monitoring profiles for demonstrating counters usage. All monitoring
profiles are deactivated, by default; you can activate them manually.
WMI
Default monitores wmi counters:
Microsoft_DomainTrustStatus (exist only on windows 2003 server), TrustIsOK, false is critical.
MSAD_ReplNeighbor(exist only on windows 2003 server), ModifiedNumConsecutiveSyncFailures, > 0 is critical, and
NumConsecutiveSyncFailures, > 0 is critical.
Select a message to be issued if the threshold specified is breached. The Text and Subsystem fields are read-only.
Send QoS data
The probe sends QoS data on the counters defined in this profile.
Send Alarm
The probe sends alarms on the counters defined in this profile.
Add
Allows you to define a threshold value and associated severity level for the selected counter (see above).
You can define several thresholds.
Remove
Removes the selected threshold. This button is enabled only when a threshold is selected in the threshold list.
ad_server Metrics
The following section describes the metrics that can be configured with the Active Directory Server Monitoring (ad_server) probe.
Contents
QoS Metrics
Alert Metrics Default Settings
QoS Metrics
The following table describes the QoS metrics that can be configured using the ad_server probe.
Resource
Monitor Name
Units
Description
Version
Eventlogs
QOS_NUMBEROFEVENTSFOUND
Number of events found.
v1.1
Eventlogs
QOS_CHANGED
When was the file

changed?
v1.1
Eventlogs
QOS_CREATED
When was the file created?
v1.1
Filesystems
QOS_DIRECTORIES
Total number of directories.
v1.1
Filesystems
QOS_FILEAGENEWEST
Age of the newest file.
v1.1
Filesystems
QOS_FILEAGEOLDEST
Age of the oldest file.
v1.1
Filesystems
QOS_FILES
Number of files.
v1.1
Filesystems
QOS_TOTALSIZE
Total size of all files.
v1.1
Performance
Counters
QOS_SQLCLIENT:_CURRENT_#_CONNECTION_POOLS
Sql Client: Current number

of connection pools.
v1.1
Performance
Counters
QOS_SQLCLIENT:_CURRENT_#_POOLED_AND_NONPOOLED_CONNECTIONS

of pooled and non-pooled
connections.
v1.1
Performance
Counters
QOS_SQLCLIENT:_CURRENT_#_POOLED_CONNECTIONS

of pooled connections.
v1.1
Performance
Counters
QOS_SQLCLIENT:_PEAK_#_POOLED_CONNECTIONS
Sql Client: Peak number of

pooled connections.
v1.1
Performance
Counters
QOS_SQLCLIENT:_TOTAL_#_FAILED_COMMANDS
Sql Client: Total number of

failed commands.
v1.1
Performance
Counters
QOS_SQLCLIENT:_TOTAL_#_FAILED_CONNECTS
Sql Client: Total number of

failed connects.
v1.1
Performance
Counters
QOS_WORKFLOWS_ABORTED
Workflows aborted.
v1.1
Performance
Counters
QOS_WORKFLOWS_ABORTED/SEC
Workflows aborted per

second.
v1.1
Performance
Counters
QOS_WORKFLOWS_COMPLETED
Workflows completed.
v1.1
Performance
Counters
QOS_WORKFLOWS_COMPLETED/SEC
Workflows completed per

second.
v1.1
Performance
Counters
QOS_WORKFLOWS_CREATED
Workflows created.
v1.1
Performance
Counters
QOS_WORKFLOWS_CREATED/SEC
Workflows created per

second.
v1.1
Performance
Counters
QOS_WORKFLOWS_EXECUTING
Workflows executing.
v1.1
Performance
Counters
QOS_WORKFLOWS_IDLE/SEC
Workflows idle per second.
v1.1
Performance
Counters
QOS_WORKFLOWS_IN_MEMORY
Workflows in memory.
v1.1
Performance
Counters
QOS_WORKFLOWS_LOADED
Workflows loaded.
v1.1
Performance
Counters
QOS_WORKFLOWS_LOADED/SEC
Workflows loaded per

second.
v1.1
Performance
Counters
QOS_WORKFLOWS_PENDING
Workflows pending.
v1.1
Performance
Counters
QOS_WORKFLOWS_PERSISTED
Workflows persisted.
v1.1
Performance
Counters
QOS_WORKFLOWS_PERSISTED/SEC
Workflows persisted per

second.
v1.1
Performance
Counters
QOS_WORKFLOWS_RUNNABLE
Workflows runnable.
v1.1
Performance
Counters
QOS_WORKFLOWS_SUSPENDED
Workflows suspended.
v1.1
Performance
Counters
QOS_WORKFLOWS_SUSPENDED/SEC
Workflows suspended per

second.
v1.1
Performance
Counters
QOS_WORKFLOWS_TERMINATED
Workflows terminated.
v1.1
Performance
Counters
QOS_WORKFLOWS_TERMINATED/SEC
Workflows terminated per

second.
v1.1
Performance
Counters
QOS_WORKFLOWS_UNLOADED
Workflows unloaded.
v1.1
Performance
Counters
QOS_WORKFLOWS_UNLOADED/SEC
Workflows unloaded per

second.
v1.1
Performance
Counters
QOS_FRAGMENTATION_FAILURES
Fragmentation failures.
v1.1
Processes
QOS_EXECUTIONSTATE
Execution state.
v1.1
Processes
QOS_HANDLECOUNT
Handle count.
v1.1
Processes
QOS_KERNELMODETIME
100ns
Kernel mode time.
v1.1
Processes
QOS_MAXIMUMWORKINGSETSIZE
Kilobytes
Maximum working set size.
v1.1
Processes
QOS_MINIMUMWORKINGSETSIZE
Kilobytes
Minimum working set size.
v1.1
Processes
QOS_OTHEROPERATIONCOUNT
Other operation count.
v1.1
Processes
QOS_OTHERTRANSFERCOUNT
Bytes
Other transfer count.
v1.1
Processes
QOS_PAGEFAULTS
Page faults.
v1.1
Processes
QOS_PAGEFILEUSAGE
Kilobytes
Page file usage.
v1.1
Processes
QOS_PARENTPROCESSID
Parent process Id.
v1.1
Processes
QOS_PEAKPAGEFILEUSAGE
Kilobytes
Peak page file usage.
v1.1
Processes
QOS_PEAKVIRTUALSIZE
Bytes
Peak virtual size.
v1.1
Processes
QOS_PEAKWORKINGSETSIZE
Kilobytes
Peak working set size.
v1.1
Processes
QOS_PRIORITY
Process priority.
v1.1
Processes
QOS_PRIVATEPAGECOUNT
Private page count.
v1.1
Processes
QOS_PROCESSID
Process Id.
v1.1
Processes
QOS_QUOTANONPAGEDPOOLUSAGE
Quota non-paged pool

usage.
v1.1
Processes
QOS_QUOTAPAGEDPOOLUSAGE
Quota paged pool usage.
v1.1
Processes
QOS_QUOTAPEAKNONPAGEDPOOLUSAGE
Quota peak non-paged pool

usage.
v1.1
Processes
QOS_QUOTAPEAKPAGEDPOOLUSAGE
Quota peak paged pool

usage.
v1.1
Processes
QOS_READOPERATIONCOUNT
Read operation count.
v1.1
Processes
QOS_READTRANSFERCOUNT
Bytes
Read transfer count.
v1.1
Processes
QOS_SESSIONID
Session Id.
v1.1
Processes
QOS_THREADCOUNT
Thread count.
v1.1
Processes
QOS_USERMODETIME
100ns
User mode time.
v1.1
Processes
QOS_VIRTUALSIZE
Bytes
Virtual size.
v1.1
Processes
QOS_WORKINGSETSIZE
Working set size.
v1.1
Processes
QOS_WORKINGOPERATIONCOUNT
Write operation count.
v1.1
Processes
QOS_WRITETRANSFERCOUNT
Write transfer count.
v1.1
WMI
QOS_COUNTERVALUE
Counter value.
v1.1
Health Monitor
QOS_RESPONSETIME
milliseconds
Total time for connecting to

object.
v1.1
Health Monitor
QOS_OBJECTFOUND
count
(number)
Number of objects found

after connection.
v1.1
Health Monitor
QOS_STATUS
count
(number)
Status of connection (4
indicates failure and 0
indicates success).
v1.1

This section contains the alert metric default settings for the ad_server probe.
Resource
Alert Metric
Warning
Threshold
Warning
Severity
Error
Error
Description
Threshold Severity
Version
Eventlogs
Event Found
TRUE
Critical
Event matched
v1.1
Eventlogs
Number of Events Found
Critical
Event matched
v1.1
Files
Not Found
TRUE
Critical
File failure
v1.1
Files
Changed
Critical
File failure
v1.1
Files
Created
Critical
File failure
v1.1
Filesystems
Directories
Critical
File system failure
v1.1
Filesystems
File Age Newest
Critical
File system failure
v1.1
Filesystems
File Age Oldest
Critical
File system failure
v1.1
Filesystems
Files
Critical
File system failure
v1.1
Filesystems
Total Size
Critical
File system failure
v1.1
Filesystems
Not Found
True
Critical
File system failure
v1.1
Performance
Counters
Sql Client: Current # of connection

pools
Critical
Performance failure
v1.1
Performance
Counters
Sql Client: Current # of pooled and

nonpooled connections
Critical
Performance failure
v1.1
Performance
Counters
Sql Client: Current # of pooled

connections
Critical
Performance failure
v1.1
Performance
Counters
Sql Client: Peak # of pooled

connections
Critical
Performance failure
v1.1
Performance
Counters
Sql Client: Total # of failed

commands
Critical
Performance failure
v1.1
Performance
Counters
Sql client: Total # of failed

connects
Critical
Performance failure
v1.1
Performance
Counters
% Processor Time
50
Warning
Performance failure
v1.1
Performance
Counters
IO Read Bytes per second
100000
Major
Performance failure
v1.1
Performance
Counters
IO Write Bytes per second
100000
Major
Performance failure
v1.1
Performance
Counters
Page Faults per second
1000
Major
Performance failure
v1.1
Performance
Counters
Fragmentation failures
Critical
Performance failure
v1.1
Performance
Counters
Active Lines
Critical
Performance failure
v1.1
Performance
Counters
Active Telephones
Critical
Performance failure
v1.1
Performance
Counters
Client Apps
Critical
Performance failure
v1.1
Performance
Counters
Current Incoming Calls
Critical
Performance failure
v1.1
Performance
Counters
Current Outgoing Calls
Critical
Performance failure
v1.1
Performance
Counters
Incoming Calls per second
Critical
Performance failure
v1.1
Performance
Counters
Lines
Critical
Performance failure
v1.1
Performance
Counters
Outgoing Calls per second
Critical
Performance failure
v1.1
Performance
Counters
Telephone Devices
Critical
Performance failure
v1.1
Performance
Counters
Active Sessions
Critical
Performance failure
v1.1
Performance
Counters
Inactive Sessions
Critical
Performance failure
v1.1
Performance
Counters
Total Sessions
Critical
Performance failure
v1.1
Performance
Counters
Datagrams No Port per second
Critical
Performance failure
v1.1
Performance
Counters
Datagrams Received Errors
Critical
Performance failure
v1.1
Performance
Counters
Datagrams Received per second
Critical
Performance failure
v1.1
Performance
Counters
Datagrams Sent per second
Critical
Performance failure
v1.1
Performance
Counters
Datagrams per second
Critical
Performance failure
v1.1
Performance
Counters
Workflows Aborted
Critical
Performance failure
v1.1
Performance
Counters
Workflows Aborted per second
Critical
Performance failure
v1.1
Performance
Counters
Workflows Completed
Critical
Performance failure
v1.1
Performance
Counters
Workflows Completed per second
Critical
Performance failure
v1.1
Performance
Counters
Workflows Created
Critical
Performance failure
v1.1
Performance
Counters
Workflows Created per second
Critical
Performance failure
v1.1
Performance
Counters
Workflows Executing
Critical
Performance failure
v1.1
Performance
Counters
Workflows Idle per second
Critical
Performance failure
v1.1
Performance
Counters
Workflows in Memory
Critical
Performance failure
v1.1
Performance
Counters
Workflows Loaded
Critical
Performance failure
v1.1
Performance
Counters
Workflows Loaded per second
Critical
Performance failure
v1.1
Performance
Counters
Workflows Pending
Critical
Performance failure
v1.1
Performance
Counters
Workflows Persisted
Critical
Performance failure
v1.1
Performance
Counters
Workflows Persisted per second
Critical
Performance failure
v1.1
Performance
Counters
Workflows runnable
Critical
Performance failure
v1.1
Performance
Counters
Workflows suspended
Critical
Performance failure
v1.1
Performance
Counters
Workflows suspended per second
Critical
Performance failure
v1.1
Performance
Counters
Workflows Terminated
Critical
Performance failure
v1.1
Performance
Counters
Workflows Terminated per second
Critical
Performance failure
v1.1
Performance
Counters
Workflows Unloaded
Critical
Performance failure
v1.1
Performance
Counters
Workflows Unloaded per second
Critical
Performance failure
v1.1
Performance
Counters
HiPerf Classes
Critical
Performance failure
v1.1
Performance
Counters
HiPerf Validity
Critical
Performance failure
v1.1
Processes
Caption
Critical
Process failed
v1.1
Processes
Command line
Critical
Process failed
v1.1
Processes
Creation Class Name
Critical
Process failed
v1.1
Processes
CS Creation Class Name
Critical
Process failed
v1.1
Processes
CS Name
Critical
Process failed
v1.1
Processes
Description
Critical
Process failed
v1.1
Processes
Executable Path
Critical
Process failed
v1.1
Processes
Execution State
Critical
Process failed
v1.1
Processes
Handle Count
Critical
Process failed
v1.1
Processes
Kernel Mode Time
Critical
Process failed
v1.1
Processes
Maximum Working Set Size
Critical
Process failed
v1.1
Processes
Minimum Working Set Size
Critical
Process failed
v1.1
Processes
Name
Critical
Process failed
v1.1
Processes
OS Creation Class Name
Critical
Process failed
v1.1
Processes
OS Name
Critical
Process failed
v1.1
Processes
Other Operation Count
Critical
Process failed
v1.1
Processes
Other Transfer Count
Critical
Process failed
v1.1
Processes
Page Faults
Critical
Process failed
v1.1
Processes
Page File Usage
Critical
Process failed
v1.1
Processes
Parent Process ID
Critical
Process failed
v1.1
Processes
Peak Page File Usage
Critical
Process failed
v1.1
Processes
Peak Virtual Size
Critical
Process failed
v1.1
Processes
Peak Working Set Size
Critical
Process failed
v1.1
Processes
Priority
Critical
Process failed
v1.1
Processes
Private Page Count
Critical
Process failed
v1.1
Processes
Process ID
Critical
Process failed
v1.1
Processes
Quota Nonpaged Pool Usage
Critical
Process failed
v1.1
Processes
Quota Paged Pool Usage
Critical
Process failed
v1.1
Processes
Quota Peak Nonpaged Pool Usage -
Critical
Process failed
v1.1
Processes
Quota Peak Paged Pool Usage
Critical
Process failed
v1.1
Processes
Read Operation Count
Critical
Process failed
v1.1
Processes
Read Transfer Count
Critical
Process failed
v1.1
Processes
Session ID
Critical
Process failed
v1.1
Processes
Status
Degraded
Critical
Process failed
v1.1
Processes
Thread Count
Critical
Process failed
v1.1
Processes
User Mode Time
Critical
Process failed
v1.1
Processes
Virtual Size
Critical
Process failed
v1.1
Processes
Windows Version
Critical
Process failed
v1.1
Processes
Working Set Size
Critical
Process failed
v1.1
Processes
Write Operation Count
Critical
Process failed
v1.1
Processes
Write Transfer Count
Critical
Process failed
v1.1
Services
State
Continue
Pending
Critical
Service is Continue Pending/Pause

Pending/Paused/Running/Start Pending/Stop
Pending/Stopped/Unknown
v1.1
WMI
Counter Value
Critical
WMI failure
v1.1
Health
Monitor
ResponseTime
15000
Major
30000
Critical
Total time to connect
v1.1
Health
Monitor
ObjectFound
10
Warning
100
Major
Total number of object found (thresholds are mentioned only for

"Lost and Found" profiles)
v1.1
Health
Monitor
status
Warning
Connection status
v1.1
adevl (Active Directory Events Monitoring)

The Active Directory Events (adevl) probe generates alerts based on messages from the NT event logs associated with Active Directory. The
probe monitors the event logs of Directory Service, Application, DNS Server, and File Replication Service for new messages and generates alarm
messages according to your setup. You can set up the probe to trigger an alarm when a log event occurs in Windows, which activates it
immediately every time a new message is put into the event log. Alternatively, you can check the event log for new messages at fixed time
intervals, which reduces the system load of the probe.
The probe supports the following non-English locales:
B-Portuguese
French
German
Italian
Japanese
Korean
Spanish
More information:
adevl (Active Directory Events Monitoring) Release Notes
v2.0 adevl AC Configuration

The Active Directory Events probe is configured by defining one or more profiles identifying a set of criteria for event log messages and how they
are configured. This probe allows you to define actions on different event log messages. This probe is configured to generate alerts based on
messages from the NT event logs associated with Active Directory.
The following diagram shows the tasks that you must complete to configure the adevl probe for monitoring event logs of Directory Service,
Application, DNS Server, and File Replication Service.
Contents
Prerequisites
Configure General Properties
Select Event Log File
Add Profiles
(Optional) Add Exclude Profile
Alarm Thresholds
Prerequisites
Verify that required hardware, software, and information is available before you configure the probe. For more information, see adevl (Active
Directory Events Monitoring) Release Notes.

You can configure the properties of the probe as desired to apply the settings on all the monitoring profiles.
Follow these steps:
1. Open the adevl probe configuration interface.
2. Configure the properties like Run Type, log file size, alarm list size, maximum events to fetch, WMI query details in the Properties sectio
n at adevl node.
3. Select the log files that you want to monitor from the Available list to Selected list in the Log Files Configuration section.
4. Click the New button to define a new alarm subsystem ID for each monitored log file in the Subsystems Configuration section.
Important! Do not delete or modify any of the default subsystem IDs.
5. Configure the various non-English event severity strings with appropriate severities in English in the Language String Configuration sec
tion.
Note: The Language String Configuration is applicable when the probe is deployed on Windows Vista or Windows Server
5.
2008 R2 or a later version.

6. Select the desired event in the Event Log Status section.
7. Save the general configuration of the probe to apply on all profiles.
Select Event Log File

The probe lets you view the event log properties on the probe GUI. The probe helps you in the following ways:
Identify the events that require monitoring.
Identify the event properties for monitoring all related events.
Provide an option for creating a monitoring profile where the selected event details are already filled.
Follow these steps:
1. Click the Options (icon) next to the adevl node.
2. Select the Add Event Log option.
3. Select the appropriate event log file from the Event Log drop-down list.
Note: The Event Log drop-down displays only those log files that are selected in the adevl > Log Files Configuration section
.
4. Click Submit.
The logs of selected event log files are displayed in the Event Log Status section.
5. Select the appropriate event in the Event Log Status list and the event details are displayed below the list.
6. Select the New Profile option from the Actions drop-down list.
7. Define the New Profile Name and click Submit.
The new profile appears under the Profile node. You can select the profile name node and can verify in the Event Selection section that
event details are already filled.
Similarly, select the Exclude Profile option from the Actions drop-down list for creating an exclude profile for the event. Select Clear
Log to delete the log from the list.
Add Profiles
You can add a monitoring profile which is displayed as a child node under the Profiles node.
Follow these steps:
1. Click the Options (icon) beside the Profiles node.
2. Click the Add New Profile option.
3. Add the field information, activate the profile, and click Submit.
The profile is saved and you can configure the profile properties to monitor the event log status.
Important! Do not use slash (/) in the profile name; else the probe trims the profile name from the slash (/) character and
discards the profile properties. For example, if the profile name is My/Profile then the probe only saves My as the profile name.
4. Add criteria for event selection in the Event Selection Criteria section.
5. Select QoS properties and alarm messages in QoS and Alarm sections, as applicable.
6. Click the New button to define variables with a set of conditions for each profile in the Variables section.
Note: The name for two variables cannot be the same.
(Optional) Add Exclude Profile

You can create a profile for excluding the events from monitoring by the probe, which is displayed as a child node under the Exclude node.
Follow these steps:
1. Click the Options (icon) beside the Exclude node.
2. Click the Add Exclude Profile option.
3. Enter the profile name, activate the profile, and click Submit.
4. Define the selection criteria for events like Log name, severity in the Event Selection Criteria section.
5. Click the Save button to save the profile.
Alarm Thresholds
allow the probe to:
v2.0 adevl AC GUI Reference

This article describes the fields in the probe GUI.
Contents
adevl Node
<Host Name> Node
Exclude Node
<Exclude Profile> Node
Profiles Node
<Profile Name> Node
adevl Node
The adevl node is used to configure the general settings of the probe. These settings are applicable to all monitoring profiles of the probe.
Navigation: adevl
adevl > Probe Information
This section provides information about the probe name, probe version, start time of the probe, and the vendor who created the probe.
adevl > Properties
This section lets you configure the general properties of the Active Directory Events probe.
Description Delimiter: defines an ASCII character to replace the existing character as delimiter. Recommendation is to use a special
character as delimiter.
Remove Recurring Delimiter: removes the repetition of delimiter.
Default: Not selected
Generate New Metric Id: displays different metric ID when adevl and ntevl probes are deployed on the same robot.
Run Type: specifies the condition when the probe is triggered for updating the events list. You can select one of the following options:
Poll: lets you configure the time interval (in the Poll interval (Seconds) field) for fetching the details of new events.
Default: 30
Alarm Timeout (Seconds): lets you configure field for generating an alarm, when the probe is unable to fetch new event details
within the specified time limit.
Default: 10
Event: updates the event list when the new event is logged in the event log file. Configure the Alarm Timeout (Seconds) field for
generating an alarm, when the probe is unable to fetch new event details within the specified time limit.
Default: 10
Default post subject: defines the default subject of the alarm messages, which the probe generates. This default post subject can be
overridden while creating a monitoring profile.
Default: adevl
A subject, which is used internally in CA UIM for alarm messages, cannot be used in this field:
alarm
alarm_new
alarm_update
alarm_close
alarm_assign
alarm_stats
QOS_MESSAGE
QOS_DEFINITION
In case, any of the given subject is used then the probe uses the evl_ as the message subject. If the field is left blank, probe uses adevl as the
default post message subject.
Note: This field only defines the default post message subject, select the Post Message option in the Alarm section of the profile name
node for sending the message. You can even override the message subject there.
Column Prefix: defines a text for appending after each column name of the alarm message.
Default: evl_
Log File: defines the log file where the probe logs information about its internal activity.
Default: adevl.log
Log File Size (KB): sets the size of the log file.
Default: 100
Log Level: defines how much information is written to the log file.
Default: 0-fatal
Maximum Events to fetch: defines the maximum number of latest events that the probe fetches from each event log file and displays in
the Event Log section. If the field is left blank, the probe displays all the events.
Default: 1000
Important! Do not configure the field value to more than 1000 else the probe can stop responding. Refer the Known Issues section of
adevl (Active Directory Events Monitoring) Release Notes for more detail.
Output Encoding: specifies the character encoding for generating alarms and QoS messages when the probe is deployed in a
non-English locale.
Default: blank
System Encoding: specifies the system and output encoding where the probe is installed.
Default: blank
Note: The probe auto-detects the system and output encoding when these field values are blank. However, the recommendation is to
specify the appropriate encoding in the fields. You can use UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE, Shift_JIS,
ISO-2022-JP, ISO-2022-CN, ISO-2022-KR, GB18030, GB2312, Big5, EUC-JP, EUC-KR, ISO-8859-1, ISO-8859-2, windows-1250, and
windows-1252 encodings.
Alarm List Size: defines the buffer size for storing the event details that match the monitoring profile criteria. This field is useful when a
profile generates an alarm when a certain number of events are found. For example, a monitoring profile generates an alarm when the
matching events count reaches 50. Since the event count is up to 49; probe keeps the events detail in the buffer.
Default: 1000
WMI Query Timeout: defines the time-out interval of WMI query for fetching the monitoring data. The probe uses WMI queries when
hosted on operating systems earlier than Windows Server 2008.
Default: 1
Note: The WMI service must be enabled on the host system for this option to work.
WMI Timeout Interval: specifies the unit of WMI query time-out interval.
Default: Seconds
adevl > Log Files Configuration
This section lets you select the log files, which the probe monitors. Select a log file from the Available list and add it to the Selected list.
adevl > Subsystems Configuration
This section lets you define a different alarm subsystem ID for each monitored log file. Use the New button and define the new subsystem ID by
configuring the following fields:
Subsystem Key: defines a subsystem key for the appropriate log file. This key must be identical to the corresponding log file name,
contain only small characters, and the slash (/) character is replaced with $$. For example, the key is microsoft-iis-configuration$$adm
inistrative for the Microsoft-IIS-Configuration/Administrative log file.
Subsystem Value: defines a different alarm subsystem ID for each monitored log file. The recommendation is to use the default
subsystem ID pattern (1.1.11.1.X) for other log files too. This pattern is mandatory to view the metric details under the Event Log node of
the Unified Management Portal (UMP).
You can also define an appropriate name of newly defined subsystem value in the nas probe, else subsystem value is displayed as is on
UMP.
The default configuration of the probe monitors dns, filerep, and directory log files with subsystem ID 2.1.2.
adevl > Language String Configuration

This section lets you configure the various non-English event severity strings with appropriate severities in English. If not configured, the probe
displays the event severity as Information on the probe GUI. The reason is that Windows returns event severity string in specific locales and the
probe cannot compare these values with equivalent English string. For example, if your Windows is in the French locale, then define Erreur in the
Error field.
Note: The Language String Configuration is applicable when the probe is deployed on Windows Vista or Windows Server 2008 R2 or a
later version.
adevl > Event Log Status

This section displays a list of events in a grid for one of the selected log files. Select a grid row and the corresponding event details with XML view
are displayed on the screen.
Note: Use the Options icon of the adevl node and specify the log file for displaying the events list in this Event Log Status grid.
The Actions drop-down list provides you the following options:

Clear Log: deletes the log from the list.
New Profile: creates a monitoring profile for the selected event log. Refer the profile name node for the field descriptions and other
related information.
Exclude Profile: creates an exclude profile for the selected event log. Refer the exclude profile name node for the field descriptions and
other related information.
adevl > Options (icon) > + Select Event Log
This option allows you to select an event log that you want to the probe to monitor.
<Host Name> Node
The host name node is used to identify the host of the system on which the probe is deployed. This node does not contain any field or section and
is used for classifying the exclude and monitoring profiles.
Exclude Node
The Exclude node is used to create a profile for excluding the events from monitoring by the probe. This node does not contain any field or
section, but contains only child nodes where each child node is a different exclude profile.
Navigation: adevl > Exclude
Set the following values if needed:
Exclude > Options (icon) > + Exclude Profile
This option allows you to create and activate an exclude profile using the Options icon.
<Exclude Profile> Node
The exclude profile node is used to define the event selection criteria. The Active Directory Events excludes the matching events from monitoring.
Note: This node is referred to as exclude profile in this document and is user-configurable.
Navigation: adevl > Exclude > exclude profile

exclude profile > Event Selection Criteria
This section allows you to configure the properties of the event selection criteria of the exclude profile.
Active: activates the exclude profile.
Default: Not Selected
Log: specifies the log file from which the probe excludes the events from monitoring. The event log files, which are selected in the adevl
node are displayed here.
Default: blank
Computer: defines the computer name on which the event has occurred.
Default: *
Source: defines the source from where the event has logged.
Default: *
Severity: specifies the severity of the event.
Default: *
User: defines the Windows user account for whom the event was generated.
Default: *
Default: *
Default: *
Message String: defines the message text of the event. You can use the regular expressions for matching the message string.
Default: *
The events matching the given criteria are excluded from the monitoring profile of the probe.
exclude profile > Options (icon) > Delete Exclude Profile
This option allows you to delete an Exclude Profile.
Profiles Node
The Profiles node is used to create a monitoring profile for generating alarms and QoS for the events that match the monitoring criteria. The
monitoring profile caters to the monitoring requirements and alerts the user when something unexpected happens. This node does not contain
any field or section, but it contains only child nodes where each child node is a different monitoring profile.
Navigation: adevl > Profiles
Profiles > Options (icon) > Add New Profile
This option allows you to create and activate a monitoring profile by clicking the Options icon.
<Profile Name> Node
This node allows you to configure the event selection criteria of the profiles. You can also configure the QoS settings of the Active Directory
Events probe.
Note: This node is referred to as profile name and is user-configurable.
Navigation: adevl > Profiles > profile name

profile name > Event Selection Criteria
This section allows you to configure the properties of the event selection criteria of the profile.
Active: activates the profile.
Default: Selected
No propagation of events: excludes an event that matches the selection criteria of one monitoring profile for all other profiles.
Log: specifies the log file from which the probe monitors the event. The event log files, which are selected in the adevl node are displayed
here.
Default: blank
Computer: defines the computer name on which the event has occurred.
Default: *
Source/Publisher: defines the source or the publisher from where the event is logged.
Default: *
Severity: specifies the severity of the event.
Default: *
Note: The audit success and audit failure severity options are applicable only for Windows earlier than Vista and 2007. Microsoft has
moved these options to the keyword field from Windows Vista and 2007 onwards. The severity level of these events is shown as Infor
mational in the event viewer. The current implementation of the probe does not support monitoring on basis of the keyword field.
User: defines the Windows user account for whom the event was generated.
Default: *
Category: defines the filter for the event when this field matches category in the event log.
Default: *
Event ID: defines the filter for the event when this field matches event ID in the event log.
Default: *
Message String: defines the filter for the event when this field matches message string in the event log.
Default: *
Run command on match: enables the Command Executable and the Command Arguments fields.
Command executable: defines the executable command when the matching event is found. You can also use the browse option and
attach a batch file.
Command arguments: defines the command arguments for executing the command.
Separator: defines a field separator character for the event message text. This field is useful for segregating the event message text in
multiple columns and then uses those column numbers in the Variables section. For example, if your event message text is
ABCD:EFGH:IJKL:MNOP and the separator is : (colon) then probe segregates the message text in four different columns (0 through 3).
You can use these column numbers for fetching the appropriate text to the variable.
Note: The non-English characters are not supported as a separator.
profile name > QoS

This section allows you to configure the QoS properties of the Active Directory Events probe.
Publish Data: enables profile to generate the QoS.
Time interval (in seconds): defines the time interval for monitoring the events and generating alarms and QoS.
profile name > Alarm
This section allows you to configure the alarm messages for the monitoring profile of the Active Directory Events probe.
Publish Alarms: enables the profile to geneaste the alarm message.
Alarm Message: defines the alarm message to be generated when the event matches the monitoring criteria. You can use following
variables in the message text:
$profile: Name of the profile for which alarm is generated.
$description: User-defined description.
$variable: User-defined variable.
$source: The source from where the event is logged. For example, [Service Control Manager].
$event_id: The ID of the particular event.
$category: Category name of the particular event. For example, [Management] and [Disk].
$log: The event log name. For example, [System] and [Application].
$severity: The event Severity level of the event.
$severity_str: The severity code name. For example, [error] and [information].
$user: Username of the event.
$computer: Host name of the system on which the event is generated.
$time_stamp: Date timestamp when the event is generated.
$message: Message description available in the event logger.
$record_id: The record number which is assigned to the event when the event is logged.
$evlData: The data associated with the event. If no data is present, None is added to the message.
Level: specifies the severity of the alarms. Select the From Eventlog option to use the same severity as the event log message.
Note: The critical level is only supported on the Windows Server 2008.
Subsystem: defines a custom subsystem ID for overriding the default subsystem ID. For example, you can give the profile name for
identifying each alarm source. You can also use variables in this field, which are explained for the Alarm Message field.
Set Suppression Key: activates the message suppression feature to avoid multiple instances of the same alarm event.
Optional Key: defines a suppression key for the alarm messages, which overrides the default key.
Time Frame(Value): specifies the time interval for the monitoring of the events.
Time Frame(Unit): specifies the unit of the time frame value.
Event Count: defined the number of events and generates alarms when this number breaches the threshold limit.
Post message: posts the event log message as the alarm.
Post Message Subject: defines the subject of the alarm. This value overrides the default message subject, which is defined in the adevl n
ode.
profile name > Variables
This section allows you to define variables with a set of conditions for each profile. These conditions populate the variable value on real time from
the selected event log message. These variables are then used for generating the alarm messages.
Note: The name for two variables cannot be the same.
profile name > Options (icon) > Delete Profile

This option allows you to delete an existing profile.
v2.0 adevl IM Configuration

This article describes the configuration concepts and procedures for setting up the adevl probe. This probe is configured to monitor the event logs
Directory Service, DNS Server, and File Replication Service for new messages and generating alarm messages as per your setup.
At the time of deploying a probe for the first time on robot, some default configuration gets deployed automatically. These probe defaults could be
Alarms, QoS, Profiles, and so on which save time to configure the default settings. These probe defaults are seen on a fresh installation where no
instance of the probe is already available on that robot in activated or deactivated state.
The adevl probe is configured by defining one or more profiles, identifying a set of criteria for event log messages and how they should be treated.
You can define actions on different event log messages.
Contents
How to Monitor Active Directory Event Logs

Select Log File
Add Profile
How to Define Variable
Add Exclude Profile
Probe Defaults
How to Monitor Active Directory Event Logs

This section describes the minimum configuration settings that are required to configure the adevl probe for monitoring event logs of Directory
Service, Application, DNS Server, and File Replication Service.

You can configure the properties of the probe if required to apply the settings on all the monitoring profiles.
Follow these steps:
1. Click Setup > Properties tab.
2. Define Poll or Event details in the Run Type section.
3. Specify log name, size, and log level in the Logging section.
4. Specify maximum events to fetch in the Fetch Event Setup section.
5. Add the WMI query details and alarm list size.
6. Click Apply button to save the general configuration of the probe to apply on all profiles.
Select Log File

You can select a log file from the available list and can monitor it by creating a profile.
Follow these steps:
1. Click Setup > Properties.
2. Select any of the log files from Available Log Files drop-down and click the >> arrow to start monitoring.
Notes:
This option is available for Vista and later version of Windows OS only.
The log files DNS Server, Directory Service, and File Replication Service are added by default.
3. Click the Apply button to save the changes.
Add Profile
You can define a monitoring profile for the selected log file.
Follow these steps:
1. Click Setup > Profiles.
2. Right-click the left pane and click New.
3. Add a profile name in the New Profile Name dialog and click OK.
The new profile is listed in the left pane.
Note: Two default profiles that appear in the left pane are:
allevents: Monitors all events of the log file, which are selected for monitoring.
allerrors: Monitors all events where the event severity is error.
4. Select the check-box to the left of the profile to enable it for monitoring.
5. Enter a description of the profile in the Description field.
6. Configure the event properties for filtering the Windows events and Active Directory events that the profile monitors. Select the Log that
you want to monitor from the drop-down options using the Event Selection tab.
Note: The event log files, which are selected in the Properties tab are displayed here.
7. Configure the alarms and QoS messages as desired using the Alarm/Post and QoS tabs, respectively.
8. Define the variables with a set of conditions for each profile using the Variables tab.
Refer How to Set Variable for more details.
How to Define Variable

You can define multiple variables for each profile to set conditions for event log messages to trigger alarms. Each variable name is unique. The
conditions populate the variable value on real time from the selected event log message. These variables are then used for generating the alarm
messages.
Follow these steps:
1. Select the Profile check box on the left-hand pane to activate it.
2. In the Variables tab, right-click in the grid and select New from the context menu.
The Variable settings dialog opens.
3. Enter the name and source line of the variable.
4. Select the desired Source FROM Position and Source To Position specifying the start and end points of threshold search.
5. Select comparison Operator from the drop-down options and set the Threshold value of the variable.
6. Click OK.
The newly created variable is displayed in the Variables grid.
You can edit and delete a variable by right-clicking on the variable and selecting the desired option from the context menu.
Add Exclude Profile

You can specify the profiles that should be excluded from monitoring by the adevl probe.
Follow these steps:
1. Click Setup > Exclude.

2. Right-click in the left pane and select New from the context menu.
The Exclude entry name dialog opens.
3. Enter a name for the entry and click OK.
The entry gets added to the left pane. Also, the fields in the right-hand pane are enabled.
4. Enter details in the Event selection criteria. Specify regular expressions identifying the event log messages that you are looking for. An
asterisk (*) in one of these fields means all log messages regardless of the contents in the field.
Note: You can use both ranges and commas in the same entry, such as, 1-5, 9-20.
Events matching all the criteria in an exclude profile are excluded from monitoring by the defined profiles.
The Event ID field does not support regular expressions.
Use format as shown in the following examples:
*
114
1, 5,10
1, 10-12
115-12
Probe Defaults
Alarms, QoS, Profiles, and so on, which save time to configure the default settings. These probe defaults are seen on a fresh install, that is no
instance of that probe is already available on that robot in activated or deactivated state.
The Active Directory Events probe has following default properties:
Setup > Properties
Poll Interval: 30 Seconds
Alarm Timeout: 10 Seconds
Log File: adevl.log
Log File Size: 100 KB
Maximum Events to Fetch: 1000
Fetch Alarms on Configurator Startup: Selected
WMI Query Timeout: 1
WMI Timeout Interval Unit: Seconds
Alarm List Size: 1000
Log Files to Be Monitored: Directory Service, DNS Server, File Replication Service
Setup > Profiles
v2.0 adevl IM GUI Reference

This article describes the fields and features of the adevl probe.
Contents
Setup Tab
Properties Tab
Profiles Tab
Event Selection Tab
Alarm / Post Tab
QoS Tab
Variables Tab
Exclude Tab
Language String Configuration Tab
Subsystems Configuration Tab

Status Tab
Parameters in a Posted Message
Setup Tab
When you double-click on the probe name in Infrastructure Manager, the GUI for the adevl probe is displayed with Setup tab (Profiles sub tab)
opened by default.
This tab contains the following tabs:
Properties
Profiles
Exclude
Language String Configuration
Subsystem Configuration
Properties Tab
The Properties tab lets you configure all initial and basic configuration of the probe, which is applicable for all monitoring profiles. The tab
contains the following fields:
Probe Active
Activates the probe if checked. Clear the check box to deactivate the probe.
Default: Selected
Description Delimiter
Adds any ASCII character including special characters to replace with new line character of the event log message.
Remove Recurring Delimiter
Removes repetition of delimiter, if selected.
Run type
Select Event to trigger the probe every time Windows NT puts a new message into the event log. Select Poll and specify a Poll Interval
and Alarm Timeout to check at regular intervals.
Default Poll Interval: 30 seconds
Default Alarm Timeout: 10 seconds
Logging
Specifies the file (Log File) to which the probe logs information about its internal activity and the level of details that are written to the log
file (Log Level). Log as little as possible during normal operation (to minimize disk consumption), and increase the amount of detail when
debugging. Sets the size of the log file (Log File Size). Large log files can cause performance issues, therefore use caution when
changing this size.
Default: 100 KB
Post Event Log Message Setup
When event log messages are posted, the default message subject is specified here (Default Post Subject). Do not use the following
subjects as they are used internally in CA UIM for alarm messages:
alarm
alarm_new
alarm_update
alarm_close
alarm_assign
alarm_stats
QOS_MESSAGE
QOS_DEFINITION
In case, any of the given subjects are used then the probe uses the evl_ as the message subject. If the field is left blank, the probe uses
adevl as the default post message text. The subject can be overridden in a profile.
Note: This field only defines the default post message subject, select the Post Message option in the Profiles > Alarm / Post
tab to send the message. You can even override the message subject at profile level
Column Prefix
Defines the text, which is added with each field name of the event log when the probe posts a message. This prefix and field name are
set for identifying the field in the posted message.
Fetch Event Setup
Maximum Events to Fetch
Specifies the maximum number of events that are fetched from the event log in the Status tab.
Default: 1000
The limit is defined to avoid timeout situations when fetching events from the probe.
Fetch Alarms on Configurator Startup
Fetches all alarms at configuration start-up (select the Status tab to see the alarm list).
If the option is not checked, this list is empty at configurator startup. Click the Refresh button of the Status tab to fetch the alarms.
Default: Selected
Output Encoding
Specifies the character encoding for generating alarms and QoS messages when the probe is deployed in a non-English locale. The
recommendation is to use same encoding as the monitored system, unless necessary.
System Encoding
Specifies the system encoding where the probe is installed.
Note: The probe auto-detects the system and output encoding when these field values are blank. However, the
recommendation is to specify the appropriate encoding in the fields. You can use UTF-8, UTF-16BE, UTF-16LE, UTF-32BE,
UTF-32LE, Shift_JIS, ISO-2022-JP, ISO-2022-CN, ISO-2022-KR, GB18030, GB2312, Big5, EUC-JP, EUC-KR, ISO-8859-1,
ISO-8859-2, windows-1250, and windows-1252 encodings.
WMI Query Timeout
Defines the time-out interval of WMI query for fetching the monitoring data. The probe uses WMI queries when hosted on earlier than
Windows Server 2008 operating systems.
Default: 1
WMI Timeout Interval Unit
Specifies the unit of WMI query time-out interval.
Default: Seconds
Alarm List Size
Defines the buffer size for storing the event details that match the monitoring profile criteria. This field is useful when a profile generates
an alarm when some events are found. For example, a monitor profile generates an alarm when the matching events count reaches 50.
Since the event count is up to 49, probe keeps the events detail in the buffer.
Default: 1000
Generate New Metric ID
Displays different metric ID when adevl and ntevl probes are deployed on the same robot.
Default: Selected
Available Log Files
Provides a list of available Log files, which you can select to be monitored. Select any of the log files and click the >> button to start
monitoring. This option is available for Vista and later version of Windows OS only.
Log Files to be Monitored
Displays a list of log files that the probe monitors. The log files DNS Server, Directory Service, and File Replication Service are added by
default. However, you can add/remove other log files from the Available Log Files list view. This option is available for Vista and later
version of Windows operating systems only.
Profiles Tab
When you select the Profiles tab, the GUI is displayed which contains the list of profiles in the left pane and some sub tabs in the right pane.
These sub tabs are used to configure the selected profile.
The Profiles tab contains the following fields:
<List>
Displays all the defined setup profiles. The check box to the left of the profile name must be checked to enable the profile. Select a profile
to display/ modify its parameters.
The first profile in the list is processed first and then the next one. Right-clicking in the list allows you to move a profile up or down.
Description
Defines a text string identifying the watcher.
There are four sub tabs in the Profiles tab:
Event Selection
Alarm / Post
QoS
Variables
Event Selection Tab
The Event Selection tab lets you configure the event properties for filtering the Windows events that the profile monitors. The tab contains the
following fields:
Event Selection Criteria
Defines the event selection criteria for filtering the event list and identifying the event for monitoring. An asterisk (*) in one of these fields
means that the profile processes all log messages regardless of the contents in the field.
No Propagation of Events
Excludes an event matching the selection criteria of one of the monitoring profiles, which is made unavailable for the other profiles.
Note: You can change the order of the profiles and the corresponding processing order.
Log
Specifies the log file from where the probe monitors the event. The event log files, which are selected in the Properties tab are
displayed here.
Computer
Defines the computer name on which the event has occurred.
Note: You can use local host in the Computer field to get only local messages. You can also use both ranges and commas
in the same entry, such as 1-5 and 9-20.
Source/Publisher Name
Defines the source or the publisher from where the event has logged.
Severity
Specifies the event severity.
Note: The audit success and audit failure severity options are applicable only for Windows earlier than Vista and 2007.
Microsoft has moved these options to the keyword field from Windows Vista and 2007 onwards. The severity level of these
events is shown as Informational in the event viewer. The current implementation of the adevl probe does not support
monitoring on basis of the keyword field.
User
Defines the Windows user account for which the event is generated.
Category
Defines the event category, for example, Service State Event.
Event ID
Defines the event ID you are monitoring. Use * for monitoring all event of the select log file.
Note: The Event ID field does not support regular expressions.
Message String
Defines the alarm message text when the event selection criteria matches an event.
Run Command on Match
Allows you to run the command when an event matches the selected criteria.
Command Executable
Specifies the command to execute when an event matches the profile. You can use the Browse button to configure a batch file path.
For example, you can execute a script for sending an email to the support executive for resolving the issue.
Command Arguments
Defines the parameters which are required for executing the command or the batch file. For example, define the email ID of the
support executive for sending an email. This field is optional.
Alarm / Post Tab
The Alarm / Post tab contains the following fields:

Send Alarm
If checked, sends an alarm message on recognition of an event log message.
Default: Selected
Alarm Message
Creates or edits an alarm message for the selected profile, and you are allowed to use variables in the messages:
$profile: Name of the profile for which alarm/QoS is generated
$description: User-defined description
$variable: User-defined variable
$source: The source from where the event is logged, for example, [Service Control Manager]
$event_id: The ID of the particular event
$category: Category name of the particular event, for example, [Management]; [Disk]
$log: The event log name, for example, [DNS Server]; [DFS Replication]
$severity: The event severity level
$severity_str: The severity code name, for example, [error] [information]
$user: Username
$computer: Computer name
$time_stamp: Date Timestamp
$message: Message description fetched from the event logger
$evlData: The variable $evlData can be used to get the data associated with the event. If no data is present, "None" is added to the
message
Level
Specifies the severity level of the generated alarms. You can use from eventlog to use the same severity level as the eventlog
message.
Note: The critical level is supported by Windows Server 2008 only. The probe generates a Minor severity alarm for an error type
event.
Subsystem
Defines a custom subsystem ID for overriding the default subsystem ID. For example, you can give the profile name for identifying
each alarm source. You can also use variables in the field.
Set Suppression Key, Optional Key
Activates the message suppression features to avoid multiple instances of the same alarm-event (variables may be used). By default,
the alarm description is used for suppressing alarms. The probe sends only one alarm with the same description in one interval. You
can also define the custom suppression key for suppressing the alarms.
If you want to receive separate alarms, clear this check box.
Time Frame
Interval Defines the time interval during which the probe monitors the events and keeps the matching events in buffer. This field is
different from Poll Interval which is configured in the Properties tab.
Event Count
Defines the operator for thresholding the event count, which matches the profile during a given time frame.
Event count text box
Defines the event count for comparing with the actual event count in buffer and generate alarm when the threshold breaches.
For example, the Time Frame is 5 min, Event Count is > (greater than) and Event Count is 4. The probe scans the event log
messages in a slot of 5 minutes. Whenever the matching events count is more than 4, the probe generates an alarm.
Post Message
Select this option if you want the event log message data to be posted as an alarm with the given subject.
Post Subject
Defines the custom Message Subject for the selected profile. This subject overrides the default subject, which is adevl or as defined in
the Default Post Subject field of the Properties tab.
You are allowed to use variables in the messages.
$variable: User-defined variable
QoS Tab
The QoS tab contains the following fields:

Number of Events Found in Time Interval
Sends QoS messages on the number of events that are detected within the specified time interval.
Default: Selected
Time Interval
Specifies the time interval (in seconds) for event detection that is used by the QoS option.
Default: 3600 seconds
Variables Tab
The Variables tab is used for defining the variables with a set of conditions for each profile. These conditions populate the variable value on real
time from the selected event log message. These variables are then used for generating the alarm messages.
The Variables tab contains the following fields:
<Variable List>
Lets you view the existing variables list and select any variable for editing the variable definition.
Field Separator
Defines a field separator character for the event message text. This field is useful for segregating the event message text in multiple
columns and then use those column numbers in the Variable settings dialog. For example, if your event message text is
ABCD:EFGH:IJKL:MNOP and the separator is : (colon) then probe segregates the message text in four different columns (1-4). You can
use these column numbers for fetching the appropriate text to the variable.
Note: The non-English characters are not supported as a field separator.
Activate a Profile, Right-click in the grid, and select New from the context menu in the Variables tab to create new variable settings.
The fields in the Variable settings dialog are:
Name
Defines the name for the variable. Duplicate variable names are not allowed.
Default: var
Source Line
The source line of the variable where the threshold alarm needs to be defined. Select the FROM and TO positions.
Source FROM position
The probe must start searching the threshold from this position in the event description.
Column
Select this option to define the column number from where the probe must start searching for the specified threshold in the event
description.
Default: 1
Character position
Select this option to define the character position from where the probe must start searching for the specified threshold in the event
description.
Default: 1
Match expression
Select this check box to define the regular expression that the probe must search in the event description.
Note: The regular expression should match the event description.
Source TO position
The probe must stop searching the event description at this position.
Ignore 'To'
Select this option to allow the probe to search the event description until the end.
To Column
Select this option to define the column number until where the probe must search the specified threshold in the event description.
To End of Line
Select this option to allow the probe to search the event description until the end of defined Source Line.
Threshold Alarm Definition
Operator
Select a comparison operator from the drop-down menu. You can also choose the re option if you want to use regular expressions.
Note: The >, <, >=, and <= operators support only integer and float type values. These operators do not work with string
values. Only the = operator works with string values.
Threshold
Set the threshold value for the variable.
Example: If you set the threshold value for column 0 equal to 10, then an alarm is generated every time the value in column 0 equa
ls 10.
Exclude Tab
The Exclude tab enables you to specify the profiles that you want to exclude from monitoring by the probe.
Right-click in the left-hand section and select New from the context menu to create a new Exclude profile. The entry appears in the left-hand
pane. Also, the fields in the right-hand pane are enabled.
<List>
Displays all the defined exclude profiles. Select a profile to display/modify its parameters.
Event selection criteria
Specify regular expressions identifying the event log messages that you are looking for. An asterisk (*) in one of these fields means all
log messages regardless of the contents in the field.
Note: You can also use both ranges and commas in the same entry, such as 1-5, 9-20.
Events matching all the criteria in an exclude profile are excluded from monitoring by the defined profiles.
The Event ID field does not support regular expressions.
Use format as shown in the following examples:
*
114
1, 5,10
1, 10-12
115-12
Language String Configuration Tab
The Active Directory Events probe displays all event severity as Information, when deployed in a non-English locale. When the probe is installed
on Windows Vista, Windows Server 2008 R2, or a later version, Windows returns event severity string in their specific locales and the probe is not
able to compare these values with an equivalent English string.
The Language String Configuration tab lets you configure the locale-specific severity strings when the probe is deployed in a non-English
locale. This tab contains the following fields:
Critical
Defines an appropriate string for identifying the event severity as Critical. For example, define critique for the French locale.
Information
Defines an appropriate string for identifying the event severity as Information. For example, define informations for the French locale.
Warning
Defines an appropriate string for identifying the event severity as Warning. For example, define avertissement for the French locale.
Verbose
Defines an appropriate string for identifying the event severity as Verbose. For example, define verbeux for the French locale.
Error
Defines an appropriate string for identifying the event severity as Error. For example, define erreur for the French locale.
Audit Success
Defines an appropriate string for identifying the event severity as Audit Success. For example, define chec de l'audit for the French
locale.
Audit Failure
Defines an appropriate string for identifying the event severity as Audit Failure. For example, define Succs de l'audit for the French
locale.
Subsystems Configuration Tab
The Subsystems Configuration tab lists the existing alarm subsystem ID for each monitored log file. You can also define a new subsystem ID for
any custom log file, which is selected for monitoring. The default configuration of the probe monitors Directory Service, DNS Server, and File
Replication Service log files, with the following subsystem IDs:
2.1.2
2.1.2
2.1.2
You can right-click the subsystem ID list and select New for adding a subsystem ID.
Subsystem Key
Defines a subsystem key for the appropriate log file. This key must be identical to the corresponding log file name, contains only small
characters, and the slash (/) character is replaced with $$. For example, the key is microsoft-iis-configuration$$administrative for the
Microsoft-IIS-Configuration/Administrative log file.
Subsystem Value
Defines a different alarm subsystem ID for each monitored log file. The recommendation is to use the default subsystem ID pattern
(2.1.2.X) for other log files too. This pattern is mandatory to view the metric details under the Event Log node of the Unified Management
Portal (UMP).
Note: You can also define an appropriate name of newly defined subsystem value in the nas probe, else subsystem value is
displayed as is on UMP.
Status Tab
The Status tab lets you view the events of the log files which are selected for monitoring in the Setup > Properties tab. This tab displays latest
event logs when the total event count is greater than the Maximum Events to Fetch field value. In case, the alarm list remains empty at start-up,
click the Refresh button and fetch the event list. You can control the default behavior for fetching event by configuring the Fetch Alarms on
Configurator Startup option in the Setup > Properties tab.
Important! The probe throws the Failed to get events error while fetching the event list when the event count is higher, for example,
3000 or more. The actual event count varies due to your system configuration and performance. In such case, reduce the value of Maxi
mum Events to Fetch field in the Properties tab.
The following right-click menu selections are available by right-clicking in the window:
Refresh - Fetches the event log messages again.
New profile - Creates a monitoring profile using values from the current event.
Exclude from monitoring - Creates an exclude profile using values from the current event.
Clear log - Removes all event messages from the current event log.
Parameters in a Posted Message

The messages are posted to a table called EventLogMessages containing the following fields:
Parameter
Type
Value
column prefixwatcher
Text
The name of the profile finding the event log message.
column prefixlog
Text
The event log containing the event.
column prefixseverity
Text
The event type.
column prefixseverity_str
Text
Event severity.
column prefixsource
Text
Identification of the application generating the event.
column prefixcategory
Text
The event category.
column prefixevent_id
Number
A numeric event identifier.
column prefixuser
Text
The user running the application that generated the event.
column prefixcomputer
Text
The computer name on which the event was generated.
column prefixdescription
Text
Expanded event description.
column prefixdata
Text
None
column prefixtime_stamp_epoc
Number
The time the event was generated.
column prefixtime_stamp
Date/Time
The time the event was generated.
Note: Depending on the number of variables created in the profile the parameters gets displayed.
v2.0 adevl IM Operation and Use

This article describes how to monitor up and down status for multiple computers, using two profiles. For this, you need to create two profiles - UP
status and DOWN status and then configure both the profiles.
Follow these steps to configure the UP and DOWN status profiles:
1. Right-click in the left pane of the profile list and then select the New option. Enter the profile name as UP status and click OK.
The profile name gets added in the list. Similarly, create another profile as DOWN status.
2. Add short descriptions of both the profile in the Description box and select the Activate box for both profiles.
3. Select the Event selection tab and specify the Event ID for the UP status as 50002.
4. Select the Alarm / Post tab. Create an Alarm Message (e.g. $computer up) and select severity level as clear. Also, set a suppression
key as $computer to avoid multiple instances of the same alarm message.
5. Now, configure the DOWN status profile. For this, select the Event selection tab and specify the Event ID for the DOWN status as 5000
1.
6. Select the Alarm / Post tab. Create an Alarm Message (e.g. $computer DOWN) and select severity level as warning. Also, set a
suppression key (e.g. $computer) to avoid multiple instances of the same alarm message.
7. Click Apply to activate the new profiles and then the OK button to exit the adevl configuration tool.
adevl Metrics
The following table describes the QoS metrics that can be configured using the Active Directory Events (adevl) probe.
Monitor Name
Units
Description
Version
QOS_EVL_COUNT
Count
Returns the number of matching events found by the monitoring profile.
v1.1
adevl Regular Expressions

Constructing regular expression and pattern matching requires meta characters. The probe supports Perl Compatible Regular Expression (PCRE)
which are enclosed in forward slash (/). For example, the expression /[0-9A-C]/ matches any character in the range 0 to 9 in the target string.
You can also use simple text with wild card operators for matching the target string. For example, the *test* expression matches the text test in
target string.
The following table lists various rules and constructs for creating regex and pattern matching:
S.
No.
Meta
Character
Description
Sample Log
File Text
Result Using "/"
Result Using "*"
Examples without regex

(Enclosed without "/")
1.
[ ] Square
Brackets
Match anything inside the square brackets for

only one character position
Sample 1:
Nimsoft12 IM
is a CA
product
Sample 2:
Nimsoft
IM0123456 is a
CA product
2.
3.
4.
- Dash
^
Circumflex
or Caret
$ Dollar
Defines range for the target string when used

within square brackets. For example, [012345
6789] can be written as [0-9].
Sample:
Nimsoft12 IM
is a CA
product
Matches any string beginning with the

expression.
Sample:
Negates the expression when used

within square brackets.
Nimsoft12 IM
is a CA
product
Matches the target string only at the end.
Sample 1:
Nimsoft12 IM
is a CA
product
Sample 2:
Nimsoft12 IM
is a product of
CA
5.
. Period
Matches any character(s) following the

expression, except the new line character.
Sample 1: The expression /[1 Expression *[12]* returns

2]/ returns 1 because [12] ma the whole string for both
tches the target to 1 and if
Sample 1 and Sample 2.
that does not match, then it m
atches the target to 2.
Not recommended to use this

meta character without / as it
can result in unexpected
match results.
Sample 2: The expression /[0

123456789]/ returns 2 becau
se [0123456789] means
match with any character in
the range 0 to 9.
[0-9A-C]: matches for 0 to 9

and A to C (but not a to c) in
the target string.
[0-9A-C]: matches the enti

re string [0-9A-C] with the
target string.

meta character without /, as
it can result in unexpected
match results.
Expression /^Nim/ returns Ni

m because ^Nim matches
any string that begins with Ni
m (in this case Nimsoft).
Expression *^Nim* returns

the whole string.

meta character without /as
such patterns are by default
appended with another^ at the
beginning and $ at the end;
hence internally handled as ^^
nim$

meta character without / as
Sample 1: uct because uct$ Sample 1: returns the who by default such patterns are
appended with another $ at
matches the text Product sinc le string.
the beginning and $ at the
e it appears at the end of the
end; and hence internally
string.
Sample 2: returns No
handled as $$uct$
Match.
Expression /uct$/ returns:
Expression *uct$* returns:
Sample 2: NO match becaus

e uct does not appear at the
end of the target string.
Expression *N.msoft* retur

ns No Match, because
with *, the probe takes the
dot (.) as a literal character
instead of an operator.

match results.
Expression *Ni?msoft* ret

urns No Match for Sample
1 and Sample 2 because
Nimsoft IM is a
CA product
Sample 1: Nimsoft because probe treats the ? operator
as the dot (.) operator and
it finds i is found 1 time.
expects one between Ni a
Sample 2:
Sample 2: Nmsoft because it nd m.
Nmsoft IM is a finds i is found 0 time.
Returns Niimsoft for Sam
CA product
Sample 3: NO match becaus ple 3 because probe treats
the ? operator as the dot
e it finds i is found 2 times.
Sample 3:
(.) operator and it found i b
etween Ni and m.
Niimsoft IM is
a CA product

match results.
Sample:
Expression /N.msoft/ returns:
Nimsoft12 IM
is a CA
product
Nimsoft because N.msoft ca

n match Nomsoft, Nkmsoft,
and so on.
6.
? Question
Matches the target string when the preceding

character occurs zero times or once.
Sample 1:
Expression /Ni?msoft/ return

s for:
7.
* Asterisk

character occurs for zero times or more.
Sample 1:
Expression /Nim*/ returns for:
Nimmsoft IM
is a CA
product
Sample 2:
Nisoft IM is a
CA product
Sample 3:
Nimsoft IM is
a CA product
Expression *Nim** returns
tre* in the Match

Expression matches only
Sample 1: matches Nimm be No Match for Sample 2 as those lines which contains
only one word and starting
it matches at least 1
cause m is found 2 times.
occurrence of m (character with tre.(for example, tree
and tread)
Sample 2: matches Ni becau preceding *).
se m is found 0 times.
Returns whole string in Sa
Sample 3: matches Nim bec mple 1 and Sample 3 whe
re occurrence of m is at
ause m is found 1 time.
least 1
8.
+ Plus or
Addition

character occurs for once or more.
Sample 1:
Nimmsoft IM
is a CA
product

tre+: matches the entire
string with the target string. meta character without /, as
Sample 1: matches Nimm be
cause
Expression *Nim+* returns match results.
whole string for Sample 1
and Sample 2
Nim+ finds m 2 times.
Expression /Nim+/ returns:
Sample 2:
Nimsoft IM is
a CA product
Sample 2: matches Nim bec

ause
NO Match for Sample 3.
Nim+ finds m 1 time.

Sample 3:
Nisoft IM is a
CA product
9.
{n}

character occurs n times exactly.
10.
{n,m}
Matches the target string when the preceding Sample 1:

character occurs at least n times but not more
than m times.
Nimsoft IM is a
fannntastic
product of CA
Sample 3: NO match becaus

e Nim+ finds m 0 times.
Sample:
Expression /[0-9]{3}[0-9]{4}/ r Expression */[0-9]{3}[0-9]{

eturns 1234567 because
4}* returns whole string.
Nimsoft IM is a sample contains 123 which is
CA product and between 0 to 9 ([0-9]) and
are three digits ({3}), similarly
its Support
[0-9]{4} matches 4567 text of
Contact
the string.
Number is
1234567
Expression /fan{1,3}t/ returns

:
Sample 1: A match (fannnt)
because Count of n in fannnt
astic is between 1 and 3.
Sample 2:

match results.
Expression *fan{1,3}t* retu Not recommended to use this

rns:
match results.
Sample 1: A Match
(whole string)
Sample 2: No Match
Expression /fan{4,6}t/ returns

Nimsoft IM is a :
fannnntastic
product of CA Sample 2: A No Match as
the count of n in fannnntastic
is not between 1 and 3..
Expression *fan{4,6}t* retu

rns:
Sample 1: No Match
Sample 2: A Match
(whole string).
11.
12.
{n, }
\\ Escape
Sequence

character occurs at least n times.
Matches meta characters with literal.
Sample 1:
Expression /fan{2,}t/ returns:
Expression *fan{2,}t* retur

ns:
Nimsoft IM is a Sample 1: A match because

fannntastic
Count of n is greater than
product of CA equal to 2
Sample 1: A Match
(whole string)
Sample 2:
Sample 2:
Sample 2:
Nimsoft IM is a A No Match because count

fantastic
of n is 1 which is less than 2.
product of CA
A No Match because
count of n is 1 which is
less than 2.
Sample 1:
\\nimsoft: matches the

entire string with the target
string.
Expression /\\\\Technologies
/ returns:
Nimsoft IM is a
CA
Sample 1: A match because
\\Technologies \\Technologies matches in
product
the target string
Sample 2:
Expression /\\\Technologies/
returns:
Nimsoft IM is a
CA
Sample 2: A match because
\Technologies
\Technologies matches in
product
the target string
Expression *\\\\Technolog
ies * matches with Sample
1.
Expression *\\\Technologi
es* matches with Sample
2.

match results.

match results.
13.
14.
\ Back
Slash
"(" or ")"
Matches the subsequent character with literal. Sample:
Expression /help?/ returns:
Used to escape a special character. In some

cases, you might need to use one of the
characters reserved as operators (any
character on this list) within your regular text.
In these cases, the backslash is used to
escape the operator and uses the next
character literally
Nimsoft IM is a
CA
Technologies
product but is
its support
always happy
to help?
Sample: A match, but fails t

o include ? in its search, and
matches help instead of help
?
Matches meta characters with literal.
Sample:
Expression /(good){3}/ return

s for:
Expression /help\?/ returns h

elp? for Sample.
Expression *help?* returns Not recommended to use this

:
Sample: A match, but fail match results.
s to include ? in its search,
and matches help instead
of help?
Expression *help\?* return
s a Match help?.
Expression *(good){3}* ret

urns:
Nimsoft IM is a
CA
Sample: A Match because g Sample: A No Match as
Technologies
ood is repeated 3 times in the (good){3} is not expanded
product and
to goodgoodgood
target string.
indeed its
support is
goodgoodgood

meta character without /,as it
will always result in no match
with the target string.
Notes on Regexp Constructs

All the patterns that are not used with / are internally enclosed within ^ and $. For example, nimsoft is converted to ^nimsoft$ and
further regular expression processing is done considering rules for both ^ and $. However, using * (e.g. *nim.soft*) provides another
way to the end users to use regular expressions. Some of the existing PCRE rules might change as explained for * and ? meta
characters above (examples 6 and 7); however, these patterns, unlike other pattern, return the whole event text (for ntvel) and line
containing the match upto 1004 characters length (for logmon), as shown below:
Event text: Nimmsoft IM is a CA product
Watcher Rule: *Nim*soft*
Result: Match containing complete string Nimmsoft IM is a CA product
Event text: Nimmsoft IM is a CA product
Watcher Rule: /Nim*soft/
Result: Match containing only the part of the string: Nimm
General:
[^<]*
Anything (or nothing) not a '>'. Useful for getting the rest of a tag without knowing what it is!
\"([^\"]*?)\"
Capture anything (or nothing) inside quotes. The data inside the parentheses is available for use in variables on the logmon probe. Use these
variables in alarm messages, validate values, and send QoS messages with the contents.
Note: The quotes are also required here and the quote must be escaped with the backslash \ character.
<A[^>]*?>
Matches and anchor tag up until the end of the tag. This tag generalizes for other tags as required.
<\/A[^<]*?
Matches an end anchor tag and anything up until the start of the next tag.
Note: A slash / must be escaped with a backslash because it is a reserved character in regular expressions.
If the monitoring target is URL:

Avoid using the * because the regex tries to match anything. The page is stripped of newlines when we get it, so everything is on one long line,
and '.*' matches more than you probably expect it to. Be restrictive and try to limit yourself to what is either inside or outside the tag. Avoid using
combinations unless you are aware about the log file text, which you are monitoring.
Carriage Return (\r) and Newline (\n) characters are stripped out and replaced by spaces in the file when we get it. Replacing these characters
means that you have to be ready to deal with spaces in places, which you do not expect. Either add \s* (zero or more spaces) to your regex or
handle anything up to the next start or end of a tag.
Note: For adding space, you can use \s on Solaris but it does not work on the Linux and Windows systems.
If the monitoring target is File:

For case sensitive search use (?-i) and (?i) for case insensitive search. For example, you can search for case insensitive match that contains
icon and end with the .png extension with /(?i)^.*icon.*.png$/ expression.
Notes on Building Regexp

Break what you are looking for down into manageable component parts. The following example is a table entry in an html file.
1. Start small - figure out where what you are looking for starts. In this example, start on a table row (<TR bgcolor=#efeee9>).
2. Figure out a regex to find a table row in the file and add it to your configuration.
3. Generate a dummy alarm for every match and count number of alarms you received. If it matches the number you are expecting, then
move on to the next part of the regex.
4. Add fields one at a time. As long as you take it one step at a time you can easily see which regex is causing you to get unexpected data.
5. Open an editor for tracking the regex component parts. Add the notes and judge complexity of the regex. Also track the different
parentheses groupings, so that you know which regex you can use in the variable list.
6. When you match everything you are looking for, you can start adding variable definitions. Do not add thresholds yet - ensure that you are
matching everything that you are looking for first. Print them in the alarms and validate that you are getting the expected values.
7. Add threshold values so that matching entries that are within acceptable limits are not generating alarms.
Notes:
The threshold is an expected value. So, if the value is 1, the operator is < and the threshold is 5 then an alarm is NOT
generated (1<5 = true). In case, the value is 7 then an alarm is sent (7<5 = false). The numeric operators (<, <=, >, and >=)
require a numeric value. Checking strings can be done with the =, ! =, and re operators. The re operator requires a regex,
which starts and ends with a slash (/regexp/).
The probe does not support /s for adding space in a regular expression.
adogtw (ADO Gateway)

The ActiveX Data Objects (ADO) Gateway is a database gateway probe between CA Unified Infrastructure Management and a database. The
probe reads data from database tables using user-defined SQL statements for monitoring database performance. The probe uses SQL Queries to
monitor the database performance parameters like, the response time and number of rows returned. Based on the database performance, the
probe posts Quality of Service (QoS) messages to CA Unified Infrastructure Management.
More information:
adogtw (ADO Gateway) Release Notes
v2.7 adogtw AC Configuration
Configure a Node
Add Connection
Manage Profiles
Delete Connection
Delete Profile
The ADO Database Gateway probe is configured to establish an ADO connection between the probe and the database. You can create a
connection using different types of database providers. You can also create profiles for monitoring database transactions.
Configure a Node
This procedure provides the information to configure a section within a node.
Each section within the node lets you configure properties of the probe for connecting to the database.
Follow these steps:
1. Navigate to the section within a node that you want to configure.
2. Update the field information and click Save.
The specified section of the probe is configured.
Add Connection
You can create an ADO connection of the ADO Database Gateway probe for monitoring a database.
Follow these steps:
1. Click the Options icon next to the adogtw node in the navigation pane.
2. Select Add New Connection.
3. Update the field information and click Submit.
The new ADO connection is available for database monitoring and is visible under the adogtw node in the navigation pane.
Manage Profiles
You can add a profile of the ADO connection in the ADO Database Gateway probe for database monitoring.
Follow these steps:
1. Click Options next to the connection name node in the navigation pane.
2. Select Add New Profile.
The new monitoring profile is visible under the Metric or Publish node in the navigation pane.
Delete Connection
You can delete an ADO connection to stop database monitoring.
Follow these steps:
1. Click the Options icon next to the Connection-connection name node that you want to delete.
2. Select Delete Connection.
3. Click Save.
The ADO connection is deleted.
Delete Profile
You can delete a Metric or Publish profile of the connection to stop database monitoring.
Follow these steps:
2. Select the Delete Profile.
3. Click Save.
The monitoring profile is deleted from the resource.
v2.7 adogtw AC GUI Reference

<Connection Name> Node
This node lets you configure the connection setup. Refer to the Add New Connection section of the adogtw node for field description.
Note: This node is referred to as connection name node in the document and is user-configurable.
Navigation: adogtw > Connection-connection name > connection name
connection name > Add New Profile

This section lets you create a profile for accessing and monitoring the database.
Name: defines the profile name.
Select Profile: specifies if the profile is a Metric type profile or a Publish type profile.
Metric Node
This node represents the Metric type profile for ADO Database Gateway probe. All custom Metric type profiles are displayed under this node.
This node does not contain any fields or sections. The Metric type profile generates the following QoS messages:
Query Response QoS
Row Count QoS
Value QoS
Navigation: adogtw > Connection-connection name > connection name > Metric
<Metric Profile Name> Node

This node lets you view and configure the Metric type profile properties. You can set the QoS and alarm values for monitoring the database
transaction execution.
Note: This node is referred to as metric profile name node and is user-configurable.
Navigation: adogtw > Connection-connection name > connection name > Metric > metric profile name
metric profile name > General Setup
This section lets you configure the profile properties and set the timeout values.
Active: activates the monitoring profile.
Profile Name: identifies the profile name.
Connection Name: identifies the provider name.
Query Timeout: specifies the time limit for fetching the SQL query output.
Run Interval: specifies the time interval between two successive SQL Query executions.
Default: 10 minutes
Interval Unit: specifies the measurement unit of Run Interval.

metric profile name > SQL Query
This section lets you define the Simple Query for accessing database tables and reads data from them. The Test option under Actions l
ets you execute the defined query.
Note: The Test option lets you verify if the SQL query runs successfully without displaying any database items or number of
rows returned.
metric profile name > Query Response QoS
This section lets you configure the threshold properties for generating QoS messages and alarms for the SQL query response time.
Severity: specifies the alarm severity.
Default: information
Message: defines the alarm message text.
Subsystem: specifies the alarm subsystem ID that defines the alarm source.
Default: 1.1.13-Database
Threshold: specifies the alarm threshold operator.
Threshold Value (ms): specifies the time interval for fetching SQL query output, exceeding which alarms are issued.
Note: Similarly, you can configure the Row Count QoS and Value QoS.
<Publish Profile Name> Node

This node lets you view and configure the Publish profile properties. You can set the variable value and name of unmapped messages.
Note: This node is referred to as publish profile name node and is user-configurable.
Navigation: adogtw > Connection-connection name > connection name > Publish > publish profile name
publish profile name > General Setup
This section lets you configure the profile properties and set the timeout values. Refer to the General Setup section of the metric profile
name node for field description.
publish profile name > SQL Query Setup
publish profile name > Publish Message Subject
This section lets you configure the Subject field. This field defines the message content.
publish profile name > Publish Message Setup
This section lets you create a variable to map with the message.
Variable Name: defines a unique name in the message.
Variable Mapping: defines the variable value. If no mapping is given, then the column name is used as variable to map with the
message.
Publish Node
This node represents the Publish type profile for ADO Database Gateway probe. All custom Publish type profiles are displayed under this node.
This node does not contain sections or fields.
Navigation: adogtw > Connection-connection name > connection name > Publish
adogtw Node
This node lets you view the probe information and configure log properties of the probe. You can also add an ADO connection to access a
database.
Navigation: adogtw

adogtw > Probe Information
adogtw > General Configuration Setup
This section lets you configure the log properties.
Log File: defines the log file name.
Default: 0-fatal
Severity: specifies the severity level of connection error alarm.
adogtw > Add New Connection
This section lets you add an ADO connection to access the database.
Connection Name: defines the ADO connection name.
Connection Type: specifies if the ADO connection type is Object Linking and Embedding Database (OLEDB) connectivity or Open
Database Connectivity (ODBC).
Default: OLEDB
Provider: specifies the database provider that is used for establishing ADO connection.
Note: If you select ODBC as the connection type, then instead of Provider, you can select the Data Source Name (DSN).
DSN is a data structure that contains information about a database.
Initial Catalog: defines the database name.
Data Source: defines the database server.
User ID: defines the database user login ID.
Parameters: defines the additional parameters for establishing an ADO connection.
v2.7 adogtw IM Configuration

Probe Configuration Interface Installation for adogtw
Probe Configuration
The Setup Tab
The Connections Tab
Add New Connection
Define an ODBC Connection
Set up an ADO connection
The Profiles Tab
The General Tab
The SQL Query Tab
The variablename Tab
The Publish Message Tab
The Quality of Service Definition Tab
The Subscribe Tab
The Alarm Definition Tab
adogtw QoS Metrics
Set Up Network Transaction Logging
The adogtw probe is configured by double-clicking the line representing the probe in the Infrastructure Manager. This brings up the configuration
tool for the probe. This probe is configured to read data from database tables using user defined SQL statements and generate messages and
alarms. It also monitors the database performance by running SQL Queries and post quality of service (QoS) messages with response time
and/or number of rows returned by the query.
Probe Configuration Interface Installation for adogtw

The probe configuration interface is automatically downloaded and installed by the Nimsoft Infrastructure Manager when the probe is deployed on
a robot.
Probe Configuration
This section describes how to configure the adogtw probe. The adogtw probe contains three tabs:
Setup
Connections
Profiles
The Setup Tab

The controls under the Setup tab configure various elements of the ADO Gateway.

Logging
Log file
Defines the file where the probe logs information about its internal activity.
Log level
Sets the level of details written to the log file. Log as little as possible during normal operation to minimize disk consumption and
Connection Error
Allows you to specify the severity level for the alarms issued when communication errors occur.
The Connections Tab

The Connections tab contains a pool of database connections that can be used by all the profiles. Right-clicking in the pane provides you three
options - New, Edit, and Delete.
Add New Connection

Follow these steps:
1. Right click in the Connections tab and select New from the shortcut menu.
The Add New Profile dialog opens.
2. Enter profile name in the Name box and click OK.

The New Connection dialog opens. Enter the required fields.

Provider / DSN
Select either OLEDB or ODBC. If OLEDB is selected, field name is Provider where you need to select the database provider. If
ODBC is selected, field name is DSN. For DSN, see Define an ODBC Connection.
Initial Catalog
Defines the database name that is to be monitored.
Data Source
Defines the database server or TNS dependent of the provider.
User ID
Defines the User Id of the database user.
Password
Defines the password of the database user.
Parameters
Used to add additional parameters for the ADO connection. This is for advanced use only. Leave the field blank unless you have
detailed knowledge about how to use these parameters.
Test button
Tests the defined connection.

3. Click OK.
The new connection is created.

To be able to select a DSN from the drop-down menu when defining a new connection, ODBC connections should be created.
Follow these steps:
1. Open the Control Panel in your system and select Administrative Tools.
2. Select Data Sources (ODBC).
The ODBC Data Source Administrator dialog appears.
3. Select the System DSN tab and click Add.
A Create New Data Source wizard is launched.

4. Select the driver you want to use (e.g. SQL server) and click Next.
5. Follow the steps through the wizard to finish the definition.
When finished, the new definition will appear in the drop-down menu on the adogtw probe when you define a new ADO connection,
selecting ODBC.
Set up an ADO connection

Follow these steps:
1. Select the Oracle provider you want to use.
2. Leave the Initial Catalog field blank.
3. Put the TNS you want to connect to in the Data Source field.
4. Enter the User ID and Password for database connection.
5. Leave the Parameters field blank unless you have detailed knowledge and know how to use these parameters.
6. Click OK.
The new connection gets added.
The Profiles Tab

A profile is a definition of one specific ADO Gateway task. The tasks can be one of the following types:
Send alarms
Publish messages
Publish QoS messages
Subscribe to messages
Right-clicking in the list displays three options - New, Edit, and Delete.
Follow these steps to create a new profile:

1. Right-click in the Profiles pane and select the New option.
The Create New Profile dialog appears.
You can create four types of profiles - Alarm, Publish, QoS, and Subscribe.
2. Enter the name of the new profile in the Name box, select the profile type as Alarm, and click OK.
The New Alarm [profile name] dialog appears.
2.
Now, there are three tabs as listed below:

General
SQL Query
[variablename]
The first two tabs of the Profiles dialog - General and SQL Query are common for most of the profile types, while the third tab depends on the
profile type selected in the Create New Profile dialog as stated below:
If Alarm is selected, the tab name is Alarm Definition.
If Publish is selected, the tab name is Publish Message.
If QoS is selected, the tab name is Quality of Service Definition.
If Subscribe is selected, the SQL Query tab is not displayed and the new tab name is Subscribe.
The General Tab

Active
If selected, the profile gets activated.
Description
Defines the description of the profile.
Connection
Defines the connections from the connection pool.
Run Interval
Defines how often the SQL query and tests should run.
Query Timeout
Defines the time the ADO Gateway should wait for the query to finish.
The SQL Query Tab

Simple Query
Select this option for simple one line queries.
From File
Stores the multi line queries in a file. This way a query can be shared between different profiles. It also makes it possible to create
queries with other tools. The files are stored in the same directory that the adogtw is installed. You can select either Simply Query or Fro
m File option.
Read File
Allows you to read the query from the file.
Test
Tests the query written in either the Simple Query box or in the file mentioned in the From File field.
The variablename Tab

The third tab of the Profiles dialog depends on the profile type selected in the Create New Profile dialog. The different tab names, due to
selection of different profile types, are listed below:
Alarm Definition
Publish Message
Quality of Service Definition
Subscribe
The Publish Message Tab

Messages without any mapping will post a message using all the values in the row and the column names as variable names. Right-clicking in the
Variable Mapping list displays the options as shown below:
The field in the above dialog is explained below:

Subject
Defines the subject for publishing.
Follow these steps to create a new variable:
1. Right-click in the Variable Mapping frame and select New from the shortcut menu.
The New Variable Mapping dialog opens.

Variable Name
Defines the variable name in the message. Must be unique for the message.
Value Mapping
Defines the variables value. Supports variable expansion.
2. Click OK.
The new variable gets created in the list.
Notes:
Select the variable in the list and click Delete to delete the created record. Similarly, select Edit to perform the required modifications.
Select the record and then click Remove Mapping to delete the selected record.
The Quality of Service Definition Tab
There are three different QoS types supported by the adogtw probe.
Query Response: Specifies how long (in milliseconds) it took to run the SQL query.
Row Count: Specifies how many rows the SQL query returned.
Value QoS: Sends the value of selected column (must be a numeric value) returned by the SQL query.
You can send a QoS message and/or send an alarm if the threshold is breached.
Send QoS Message on query response time
Enables or disables quality of service messages.
Send Alarm
Enables or disables alarm.
Severity
Specifies the severity of the alarm message.
Message
Specifies the alarm message text.
Subsystem
Specifies the alarm subsystem.
Threshold
Specifies the alarm condition and threshold value.
Note: All the fields in the remaining tabs - Row Count QoS and Value QoS are same as above but the QoS generation criteria are different.
The Subscribe Tab

A subscribe profile makes it possible to subscribe to a subject and insert the data into a specific table. You must create the target table before you
configure a new Subscribe profile. Make sure that the columns are named corresponding to the message that you want to subscribe to and that
they are of the correct data type. This will make it much easier to create the profile.

Subject
Defines the subject you want to subscribe to.
Table properties
Table
Defines the table you want to insert data into.
Column Properties
Defines the column name, column type, and format of the values that you want to insert. $variable represents the name of the keys in
the message you subscribes to.
You have to select a connection before the Table drop-down is populated. When you create the profile, a queue will be created on the hub as
well. This queue will be enabled or disabled corresponding to the profile and it will be deleted when you delete the profile.
The Alarm Definition Tab

Severity
Defines the severity of the alarm. The alarm severity levels are currently not user-configurable in adogtw probe and you can only select
an alarm severity from the pre-defined list shown in the drop-down.
Subsystem
Defines the subsystem of the alarm.
Message
Defines the alarm message text. Supports variable expansion.
Advanced
Suppression key
Creates a logical checkpoint that is used for suppression of alarms.
Source of Sender
Used to impersonate another source that the machine that runs the ADO Gateway.
Alarm Condition
Column
Specifies what column the condition should be checked against.
adogtw QoS Metrics

The following table describes the checkpoint metrics that can be configured using the adogtw probe.
Monitor Name
Units
Description
QOS_SQL_RESPONSE
Milliseconds
SQL query response time
QOS_SQL_ROWS
Rows
SQL query rows
QOS_SQL_VALUE
Value
SQL query value
Set Up Network Transaction Logging

This example describes how to set up the adogtw log network transactions to a table in a database. In this example, we assume that the table Ala
1. Add a connection to the database.
2. Add a new profile and select Subscribe.
3. Click the General tab and select the connection that you created.
4. Click the Subscribe tab and select Subject as nas_transaction and Table as AlarmTransactionLog.
5. Activate the profile, save it, and watch the table gets filled.
adogtw Troubleshooting
adogtw Tips
The query
There are some rules that you should follow when you create a query:
1. Use column names in the query. For example, SELECT a, b FROM table1.
This makes it easier to determine the variables available in the profile. In this case $a and $b.
2. Try to limit the number of rows that are returned by the query. Receiving 12432 alarms every 5 minutes is excessive.
For example: SELECT a, b FROM table1 WHERE somedate < DATEADD(n,-10,GETDATE())
3. Use queries that return one row if you can. For example, SELECT count(*) as rows FROM table1.
Remember that each row returned by a query results in one alarm or on message.
Using column variables
It is possible to use variables in most fields in Alarm and Publish profiles. The number of variables available depends on the select statement
used in the query. Always use column names in the query. For example, SELECT a, b FROM table1. This makes it easier to determine the
variables available in the profile. In this case $a and $b.
The example above could in an Alarm profile result in a Message definition like this: $a contains $b. Each variable will be replaced with the
corresponding value from the select.
Using message variables
This applies to the Subscribe profile only. When you create a table that you are going to use to insert Nimsoft messages try to use the same name
on the columns as the variables used in the message (PDS). You can use a sniffer tool (the hub) to find out what the message contains.
Some data types are treated specially:
1. Numbers that look like this: 1022649974 is most likely an EPOC value. This number corresponds to the date Wednesday, May 29, 2002
05:26:14. EPOC is a system date used by computers and starts on Thursday, January 01, 1970 00:00:00 with the value 0. This value can
be inserted into the database as a datetime value.
2. Formats for number and decimal types must contain only one variable and that value must contain numbers only.
3. The string can contain anything, including multiple variables.
adogtw Metrics
The following table describes the checkpoint metrics that can be configured using the ADO Gateway Monitoring (adogtw) probe.
Monitor Name
Units
Description
Version
QOS_SQL_RESPONSE
Milliseconds
SQL query response time
v2.5
QOS_SQL_ROWS
Rows
SQL query rows
v2.5
QOS_SQL_VALUE
Value
SQL query value
v2.5
aggregate_alarm
The aggregate_alarm probe lets you build an expression that includes one or more QoS metrics published by any CA UIM probe and a threshold
point for each QoS in the expression. When aggregate_alarm evaluates the expression, if it is true, it generates an alarm of the configured alarm
severity and alarm text.
More Information:
aggregate_alarm Release Notes
v1.0 aggregate_alarm AC Configuration

The aggregate_alarm probe lets you alarm on QoS metrics for a single QoS message or multiple QoS messages that are published by any CA
UIM probe. You can combine QoS metrics in an expression to generate a single aggregate alarm that is based on combined alarm threshold
conditions. In addition to receiving individual alarms for various alarm thresholds, you can also receive an aggregate alarm.
Note: An aggregate alarm's expression can have QoS metrics from a single or multiple sources. Therefore, an aggregate alarm is not
associated with a specific source.
About the aggregate_alarm Probe
The purpose of the aggregate_alarm probe is to allow you to generate a single event alarm based on multiple alarm conditions. Using this probe
lets you customize alarms based on your environment.
You can create an aggregate alarm with one or more QoS metrics that are generated by any CA UIM probe. Select the Publish Data option in a
probe's GUI for all QoS metrics included in an aggregate alarm expression. When this option is selected, the probe puts QoS messages on the
UIM message bus. The aggregate_alarm probe listens on the UIM message bus and gathers all QoS messages identified in all the aggregate
alarm conditions expressions. Probes must be publishing QoS messages for the conditions expression to be evaluated properly.
The following diagram shows how QoS messages from probes are used to generate an aggregate alarm that is based on multiple alarm
conditions.
When you configure an aggregate alarm, the following actions occur:

The aggregate_alarm probe listens on the UIM message bus for all QoS messages.The aggregate_alarm collects all QoS messages
from the UIM message bus that match the QoS name, source, and target data specified in all QoS Conditions tables for all configured
aggregate alarm profiles.
When aggregate_alarm has QoS messages that match QoS data in the QoS Conditions tables, it evaluates the values from the most
recent QoS messages.
If an aggregate alarm condition expression is true, aggregate_alarm generates an alarm of the configured severity with the specified
Origin (if applicable) and configured alarm message and places it on the UIM message bus.
Configuration Overview
The following diagram shows the process of creating an aggregate alarm.
Sample Configuration
As an example, to generate an aggregate alarm of minor severity (level 3) when Disk Usage for a specified QoS source and target exceeds 85
percent AND CPU Usage for a specified QoS source and target exceeds 50 percent, here are the actions to perform:
1. Using the Admin Console, access the desired probe configuration settings.
a. Access the cdm probe. For Disk Usage > Disk Usage (%), select the Publish Data check box.
b. For cdm probe Processor > Total CPU > Total CPU Usage, select the Publish Data check box.
2. In Admin Console, access the aggregate_alarm GUI and create a new aggregate alarm profile.
a. By default, the new aggregate alarm is Enabled. You can clear this check box and can enable it at a later time.
b. Select the Query UIM database check box (cleared is the default setting) to indicate that you want the QoS Name, Source, Target,
and Origin drop-down lists populated at the next Refresh Interval.
3. In the QoS Conditions table, click New and enter the QoS data for each QoS to be included in the aggregate alarm conditions
expression.
Each condition requires:
a unique identifier
the QoS name
the source host name or IP address included in the emitted QoS message
a target which can be a host name, IP address, or valid identifier (such as a drive identified C:\)
a threshold operator
the alarm threshold the aggregate_alarm uses to evaluate in the condition expression.
The following are example QoS conditions:
id1
id2
QOS_DISK_USAGE_PERC
QOS_CPU_USAGE
QA-Test-VM
QA-Test-VM
10.1.1.1
10.1.1.1
>
>
85
50
4. Enter the QoS condition expression the aggregate_alarm evaluates to determine if it needs to generate an alarm. Based on the QoS
conditions that are shown in the previous step, here's a sample expression that evaluates true when QOS_DISK_USAGE_PERC for the
entered source and target goes above 85 percent AND QOS_CPU_USAGE for the entered source and target goes above 50 percent.
id1&&id2
5. Select the alarm severity level for the aggregate alarm and enter the alarm text. Following the sample configuration, a minor alarm
(severity level 3) with the configured alarm text appears in Unified Service Manager when the QoS condition expression evaluates to true.
Alarm Severity: Minor Level 3

Alarm Text: This is a test alarm.
6. (Optional) Select an Origin from the drop-down list.

8. Access CA UMP and open Unified Service Manager. Click
to display all alarms.
The aggregate alarm is now defined and will be active if the Enabled option is selected in the aggregate_alarm probe GUI.
Probes generate QoS messages at different intervals. For example, one probe might generate a QoS message every 15 minutes while another
probe generates a QoS message every hour. aggregate_alarm collects QoS messages from the UIM message bus for all QoS metrics added in
all QoS conditions tables and stores the data. When there is at least one collected QoS message for each QoS included in a conditions
expression, aggregate_alarm can start the expression evaluation process.
The aggregate_alarm evaluates the QoS messages included in each conditions expression to determine if the expression is true. When the
conditions expression is true, the aggregate_alarm sends an alarm of the configured severity with the configured alarm text. The generated alarm
and configured alarm text display in Infrastructure Manager and Unified Service Manager.
Configuring an Aggregate Alarm

When you create or copy an aggregate alarm, you must give it a unique name. As part of the alarm's configuration, you add one or more QoS
conditions, each with a unique identifier, and build an expression using the configured identifiers for the QoS conditions. Finally, you configure the
severity level and the displayed text message for the aggregate alarm to be generated when the expression evaluates to true.
Add a New Aggregate Alarm Profile
Configure an Aggregate Alarm
Copy an Aggregate Alarm
Modify a QoS Condition
Delete a QoS Condition
Delete an Aggregate Alarm
Deactivate an Aggregate Alarm
Adjust the Refresh Settings
Modify the Log Level
Add a New Aggregate Alarm Profile

The first time you access the aggregate_alarm configuration, create a new aggregate alarm.
Follow these steps:
1. In the Admin Console navigation pane, click the robot.

2. Click the down arrow next to the aggregate_alarm probe, and select Configure.
3. Click Aggregate Alarm in the navigation tree.
4. Click Options (...) > Create New Aggregate Alarm.
5. Enter a unique alarm profile name.
6. Click Submit.
Configure an Aggregate Alarm

Follow these steps:
1. In the QoS Conditions table header, click New.
2. Below the table, enter a unique Identifier.
An identifier must begin with a letter (a-z or A-Z) and can have any number of characters. Valid characters include letters (a through z,
uppercase or lowercase), numbers (zero through nine), and underscore (_). For example, alarm_id_1 is a valid identifier.
Note: An identifier may not begin with the character sequence QOS_, as this sequence is reserved for use with identify Qos
values published on the UIM message bus.
3. Select or enter a QoS name, source, and target.

a. Select a value from the drop-down list.
b. Click Add Item (+ sign) and type a valid QoS name, source, or target to manually enter a value.
4. Select an operator.
5. Enter an alarm threshold value appropriate for the QoS. The units used for the QoS are automatically applied for the entered threshold.
6. Enter a Condition Expression. aggregate_alarm evaluates this expression to determine if an aggregate alarm should be generated.
Valid expressions are:
&& - and
|| - or
! - not
Note: You can use parenthesis to indicate order of processing. For example, you can enter "id1 || (id2 || (id3&&id4))". This
expression evaluates true when id3 AND id4 OR id2 QoS conditions breach a configured threshold, or id1 QoS condition
breaches a threshold.
7. Select an Alarm Severity for the aggregate alarm.

8. Enter Alarm Text for the QoS message that is generated for an aggregate alarm.
9. (Optional) Select or enter an Origin.
a. Select a value from the drop-down list.
b. Click Add Item (+ sign) and type an Origin to manually enter a value.
Copy an Aggregate Alarm

After you have one or more configured aggregate alarms, you can create a new alarm by copying an existing alarm and modifying the configured
settings.
Follow these steps:
1. Click an existing alarm name in the navigation tree.
2. Click Options (...) > Copy.
3. Enter a unique alarm name.
4.
4. Click Submit.
Modify a QoS Condition

Follow these steps:
1. Access an existing alarm profile.
2. In the QoS Conditions table click to highlight a condition. The condition fields appear below the table.
3. To change the identifier, highlight and type a different identifier.
4. To change one or more of the QoS metrics:
a. Select No Selection from the QoS Name, Source, and Target drop-down list to refresh the QoS metrics data.
b. Select the desired QoS Name, Source, and Target from the drop-down list.
5. Modify the Operator or Threshold, if needed.
6. If you changed an identifier included in the Condition Expression, update the expression. Otherwise, saving your changes will result in an
error message.
7. Modify the Alarm Severity and Alarm Text, if needed.
8. To change the Origin, select a different Origin from the drop-down list or use the Add Item (+ sign) and manually enter a new Origin.
Delete a QoS Condition

Follow these steps:
1. Access an existing alarm profile.
2. In the QoS Conditions table click to highlight a condition.
3. Click Delete in the table header.
Delete an Aggregate Alarm

Follow these steps:
1. Click an alarm profile in the navigation tree.
2. Click Options (...) > Delete.
3. Click OK to confirm.
Deactivate an Aggregate Alarm

An aggregate alarm is enabled by default. To turn off an aggregate alarm, clear the Enabled check box on the Aggregate Alarm Configuration
page.
Adjust the Refresh Settings

You can control whether or not the QoS Name, Source, Target, and Origin drop-down lists are populated with data from the UIM database, and
how often the data is collected from the UIM database.
Follow these steps:
1. In the navigation pane, click Aggregate Alarm.
2. Select the Query UIM Database check box if you want the QoS Name, Source, and Target, and Origin drop-down lists populated with
data from the UIM database.
Default: This option is not selected.
Note: Depending on the size of your infrastructure, it may take several minutes for the drop-down lists to be populated with
data. While the data is populating, you can use Add Item (+ icon) to manually type a QoS Name, a Source, a Target, or an
Origin for a QoS. These fields are case-sensitive. Therefore, you must enter the string correctly to generate an aggregate
alarm. For example, "QoS CPU Usage" is incorrect, but "QOS_CPU_USAGE" is correct.
3. Change the Refresh Interval, if desired.
3.
If the Query UIM Database option is selected, this interval indicates how often the data in the drop-down lists is updated.
Default: 60 minutes
4. Click Save.
Note: Deactivate and then Activate the probe to immediately start the process of populating the QoS Name, Source, Target,
and Origin drop-down lists. Otherwise, the process of populating the drop-down lists will occur at the next Refresh Interval.
Modify the Log Level

Select the alarm severity level of messages to be stored in the aggregate_alarm log file.
The log file is stored in Program Files (x86)\Nimsoft\probes\slm\aggregate_alarm.
Follow these steps:
1. At the top of the navigation tree, click aggregate_alarm.
2. Modify the Log Level alarm severity setting.
More Information:
v1.0 aggregate_alarm AC GUI Reference
v1.0 aggregate_alarm AC GUI Reference

This article explains the configuration information and options available through the Admin Console aggregate_alarm configuration GUI. The
sections to configure include:
Probe Interface
aggregate_alarm Probe Setup
Probe Information
Probe Setup
Aggregate Alarm General Settings
Aggregate Alarm Profile
QoS Conditions
Condition Expression
Alarm Configuration
Probe Interface
The probe interface is divided into a navigation pane and a details pane. The left navigation pane contains a hierarchical representation of the
existing aggregate alarm profiles. The right details pane shows how aggregate alarms are configured.
aggregate_alarm Probe Setup

Navigation: aggregate_alarm
This section lets you view probe information and modify log file settings, if required.
Probe Information
This section provides the basic probe information and is read-only.
Probe Setup
Modify the log setting in this section, if required.

Log Level
Specifies the amount of log information you want to collect for this probe.
Default: 3 (info)
Aggregate Alarm General Settings

Navigation: aggregate_alarm > Aggregate Alarm
You can determine whether or not the drop-down lists are automatically updated at the configured QoS Metric Refresh Interval. These settings
apply to all aggregate alarm profiles. Modify the settings in this section, if required.
Query UIM Database
Select this check box if you want the QoS Name, Source, Target, and Origin drop-down lists populated with data stored in the UIM
database. The drop-down lists are populated at the configured Refresh Interval, but as a background task. This enables you to configure
QoS conditions and the Origin without having to wait for the update process to complete.
Use the Add Item (+ sign) to manually add a new QoS Name, Source, Target, or Origin that does not appear in the drop-down lists.
When you manually add a QoS name, it must match the name displayed in the probe's GUI. When you manually enter a
source, target, or origin, it must match the information emitted in a QoS message. Otherwise, an aggregate alarm will not be
generated because the aggregate_alarm probe will be listening for QoS messages that don't exist.
Default: Check box is not selected
Note: In environments with a large number of probes, it might take several minutes to populate drop-down lists. However,
selecting this option and then selecting values from the populated drop-down lists ensures that the QoS Name, Source, Target,
or Origin is correct.
Refresh Interval (mins)

By default, the UIM database is queried every hour to collect data for the drop-down lists for all QoS messages being emitted by CA UIM
monitoring probes. aggregate_alarm stores this data and uses it to evaluate the QoS condition expression.
Default: 60 minutes
Aggregate Alarm Profile

Navigation: aggregate_alarm > Aggregate Alarm > alarm name
Create an aggregate alarm profile for each aggregate alarm. This profile contains configuration settings used to generate an aggregate alarm.
Name
An alarm identifier. This name must be unique among the aggregate alarms. You can modify this name at any time.
Enabled
Select this check box to make the aggregate alarm active. When active, the aggregate_alarm probe emits alarms when the conditions
expression evaluates to true.
Default: Selected
QoS Conditions
Use the QoS Conditions table to define all the QoS metrics to be included in the aggregate alarm condition expression.
Identifier
A unique name to identify a condition, which includes a QoS name, a source, a target, an operator, and a threshold.
QoS Name
The exact name of a QoS. The name must match the name displayed in the probe's configuration pages. For example,
QOS_DISK_AVAILABLE is correct, but QoS_disk_Available is incorrect.
Source
The source host name or IP address emitted in a probe's QoS message.
If you manually enter a source using the Add Item (+ sign), the source data must match the source a probe emits in its QoS message.
The source is case sensitive. To determine a QoS source, you must look at a generated QoS message.
Default: No Selection
Target
The target emitted in a probe's QoS message.
If you manually enter a target using the Add Item (+ sign), the target data must match the target a probe emits in its QoS message. The
target is case sensitive. To determine a QoS target, you must look at a generated QoS message.
Default: No Selection
Note: The QoS name, source, and target must match what is an emitted in a QoS message. Otherwise, the aggregate_alarm probe will
fail to generate an aggregate alarm. Incorrect QoS name, source, and target data results in the aggregate_alarm probe listening for the
wrong QoS messages.
Operator
Choose an operator for the alarm threshold.
< An alarm occurs when the metric is less than the set threshold.
< = An alarm occurs when the metric is less than or equal to the set threshold.
Threshold
The user-defined threshold for the alarm. The number entered for this threshold should correspond to the units used for the QoS.
Condition Expression
The Expression field indicates the desired condition for generating an alarm.
Valid operators include:
&& - Evaluates true when both of the relational expressions on either side of the operator evaluate true.
|| - Evaluates true when either one or both of the relational expressions on either side of the operator evaluate true.
! - Inverts the result of the relational expression to the operator's right. For example, "! (id1 || id2)" inverts the result of the composite
expression contained within the parentheses, but "! id1 || id2" inverts only the expression to be "id1".
Parentheses
Use parentheses to indicate the order in which the expression is evaluated.
For example, the expression "((id1 && id2) || id3))" indicates the condition is true (meaning an alarm is generated) when the thresholds
set for both id1 and id2 are reached OR the threshold set for id3 is reached.
Alarm Configuration
Alarm Severity
The level of alarm generated for the aggregate alarm event.
Critical Level 5
Major Level 4
Minor Level 3
Warning Level 2
Information Level 1
Alarm Text
The alarm message on an emitted alarm.
Origin
A system-generated alarm origin or another origin you enter.
Create Aggregate Alarms from the Command Line

The article explains how to create an aggregate alarm command and run it from <aggregate_alarm_dir> instead of using the probe's GUI. You
can store the expressions file anywhere you have read access on the file system. If you specify a relative path to the expressions file, the probe
resolves the path beginning in its installation directory. Or you can specify an absolute path.
An aggregate alarm command uses the following format:
$ALARM Alarm_Name1:4, "Alarm text message.", "originhubname"

identifier1:QOS_DISK_TOTAL_THROUGHPUT,"hubsource3","hubtarget3"
identifier2:QOS_DISK_SIZE,"hubsource2",c:\
identifier1 < 1000 || identifier2 > 4
$ALARM
A reserved keyword that Introduces an alarm definition you intend to emit when the expressions following the alarm definition evaluate
true.
Syntax: Reserved keywords are all uppercase and start with $. $ALARM is the only defined keyword.
alarm name (Alarm_Name1)
Tha name of the alarm.
Syntax: An upper or lower case letter followed by any combination of zero or more upper and lower case letters (a-z or A-Z), digits (0-9)
or underscores (_).
alarm level (4)
The alarm severity level.
Syntax: An integer between 1 and 5 inclusive.
1 = information level
2 = warning level
3 = minor level
4 = major level
5 = critical level
"alarm text" ("Alarm text message.")
The alarm message as it will appear in the alarm console. Beginning and ending quotes are required in the command but are removed
before sending the alarm.
"origin" ("originhubname")
The system-generated alarm origin or another origin you enter. To display the system-generated origin, leave the origin field blank by
setting the origin to a blank string (""). To display an origin you enter, enclose the origin string in quotes ("hub_name"). Beginning and
ending quotes are required for the origin string but are removed before sending the alarm.
identifier
A unique name that identifies a unique combination of the QoS triple values (QoS name, source, and target). Identifiers are
case-sensitive, meaning Id3 is different than id3. Windows drive identifiers entered as a target are also case sensitive (C:\ is different than
c:\). Windows drive identifiers for a target are not quoted (id3 : QOS_DISK_USAGE, "82dsmMhub5", C:\ is a valid expression).
Syntax: An upper or lower case letter followed by any combination of zero or more upper and lower case letters (a-z or A-Z), digits (0-9)
or underscores (_).
Note: Do not use the string QOS_ as the initial characters in an identifier. However, identifiers such as Qos_1, qos_1, or
QoS_1 are valid.
QoS name
The exact QoS name as it appears in a Qos message in UIM.
Syntax: The string QOS_ followed by any combination of at least one upper or lower case letters, digits, or underscores.
source ("hubsource3")
The host name, IP address, or valid identifier (such as a drive identified C:\) of a source included in a QoS message.
target ("hubtarget3")
The host name, IP address, or valid identifier (such as a drive identified C:\) of a target included in a QoS message.
operator
Operators used to compare QoS values to threshold constants or other QoS values.
Valid operators are:
== Operands are exactly equal.
!= Operands are not equal.
> Left operand is greater than the right operand.

>= Left operand is greater than or equal to the right operand.
< Left operand is less than the right operand.
<= Left operand is less than or equal to the right operand.
aggregate alarm threshold (1000)
Alarm threshold for the related identifier.
Syntax: A numeric value.
Logical operators
Allows you to combine any number of QoS conditions to be evaluated. If the evaluation is true, an aggregate alarm is generated.
Valid logical operators are:
&& Evaluates true when both of the relational expressions on either side of the operator evaluate true.
|| Evaluates true when either one or both of the relational expressions on either side of the operator evaluate true.
! inverts the result of the relational expression to the operator's right. Logical negation is only valid when the expression to the
operator's right is a relational expression. For example, "! id31" is not a valid expression, but the following examples are valid
expressions:
! (id31 >= 0.0 || id32 <= 0.0) // inverts the result of the composite
expression contained within the parentheses
! id31 >= 0.0 && id32 <= 0.0
// inverts only the result of the expression
"id31 >= 0.0"
Comments
The character sequence // begins a single-line comment. For example:
! (id31 >= 0.0 || id32 <= 0.0) // Text from here to the end of this line is
discarded
// QOS_CPU_USAGE,"82dsmMhub5", d:\ >= 0
The character sequence /* begins a multi-line comment, and the character sequence */ ends a multi-line comment. Both the beginning
and ending multi-line sequences may be on the same line. For example:
/*
All of the text in this block is discarded during expression evaluation.
$ALARM Alarm1:1, "This is an alarm \"with quoted text\"", ""
id31:QOS_CPU_USAGE,"82dsmMhub3","82dsmMhub3"
id33:QOS_CPU_USAGE,"82dsmMhub5", c:\
Qos_1:QOS_CPU_USAGE,"82dsmMhub5", d:\
id31 >= -1.0 || id32 < 3.14 || id33 != 0.0
*/
! id31 >= 0.0 && id32 <= 0.0
/* This is a multi-line comment on one line */
Alarms are cleared when the conditions that originally caused an alarm to be published no longer exist.
Format for Expressions

Each QoS condition expression should use one of the following formats:
IDENTIFIER:QOS_IDENTIFIER,
QUOTED_TEXT, QUOTED_TEXT
QUOTED_TEXT, DRIVE_IDENTIFIER
DRIVE_IDENTIFIER, QUOTED_TEXT
DRIVE_IDENTIFIER, DRIVE_IDENTIFIER
Expression Evaluation
When the probe parses an expressions file, any referenced QOS values register themselves to be processed as they are transmitted across the
UIM message bus. Expressions are evaluated at the rate of the slowest occurring QOS. For example, say that QOS_1 is published at 5-minute
intervals, and QOS_2 is published at 1-hour intervals. An expression referencing only QOS_1 would evaluate each time QOS_1 is published as
soon as the probe sees QOS_1 on the UIM message bus. An expression referencing both QOS_1 and QOS_2 would evaluate each time QOS_1
and QOS_2 are published, so the expression would evaluate at QOS_2's publication rate. In addition, the expression evaluates using the latest
values of each referenced QOS. In this example, QOS_1 would be published 12 times for each time QOS_2 is published. The expression would
evaluate using the twelfth QOS_1 value and the first QOS_2 value. After successful evaluation, the referenced QOS values are cleared, so
subsequent evaluations would follow the same schedule as the first evaluation.
Examples
For the examples in this section, the aggregate_alarm probe collects the QoS messages included in each identifier string (for example,
id31:QOS_CPU_USAGE,"82dsmMhub3","82dsmMhub3","") from the UIM message bus. When the probe has collected the QoS messages
needed to evaluate an expression, it executes the evaluation. When the expression evaluates as true, the probe emits a single alarm of the
configured severity level and with the configured alarm text (for example, "This is an alarm.").
After expression evaluation, the aggregate_alarm probe clears any data values used in the evaluation instance, then resumes processing QoS
messages.
Aggregate Alarm With a Single Alarm Threshold
The aggregate_alarm probe collects the QoS messages with QOS_CPU_USAGE, "82dsmMhub3", "82dsmMhub3" from the UIM message bus.
All QOS_CPU_USAGE messages are evaluated against the conditions expression (id31>=-1.0). When the QoS message contains a value
greater than or equal to -1.0, the expression for Alarm1 expression would evaluate true, and the probe would emit a level 1 alarm with the text
"This is an alarm".
$ALARM Alarm1:1,"This is an alarm","" id31:QOS_CPU_USAGE,"82dsmMhub3","82dsmMhub3"

id31>=-1.0
Using the AND Condition
The aggregate_alarm probe collects the QoS messages with QOS_CPU_USAGE, "82dsmMhub3", "82dsmMhub3" and QOS_CPU_USAGE,
"82dsmMhub4", "82dsmMhub4" from the UIM message bus. When aggregate_alarm evaluates the QoS messages and conditions id31 >= -1.0
and id32 < 3.14 for Alarm1 are true, the probe emits a single level 1 alarm with the text "This is an alarm".
$ALARM Alarm1:1,"This is an alarm","origin_hub_1"

id31 >= -1.0 && id32 < 3.14
Using the OR Condition
The aggregate_alarm probe collects the QoS messages with QOS_CPU_USAGE, "82dsmMhub3", "82dsmMhub3" and QOS_CPU_USAGE,
"82dsmMhub4", "82dsmMhub4" from the UIM message bus. When aggregate_alarm evaluates the QoS messages, and either condition id31 >=
-1.0 or id32 < 3.14 for Alarm1 are true, the probe emits a single level 1 alarm with the text "This is an alarm". Both expressions are evaluated,
even though it is not strictly necessary to evaluate id32 < 3.14 after id31 >= -1.0 has already evaluated true.
$ALARM Alarm1:1,"This is an alarm","origin_hub_2"

id31 >= -1.0 || id32 < 3.14
Using Parenthesis in a Conditional Expression
For this expression, parenthesis are used in the conditions expression to specify an evaluation order. In the expression shown below the
expression within the parenthesis (id32 < 3.14 || id33 != 0.0) is evaluated first. The order of expression evaluation without parentheses would be
left to right.
The aggregate_alarm probe collects the QoS messages specified for id31, id32, and id33 from the UIM message bus. When aggregate_alarm
evaluates the QoS messages, and condition id32 < 3.14 or id33 !=0.0 or id31 >= -1 for Alarm1 is true, the probe emits a single level 1 alarm with
the text "This is an alarm".
$ALARM Alarm1:1,"This is an alarm",""

id33: OS_CPU_USAGE,"82dsmMhub5","82dsmMhub5"
id31 >= -1.0 || (id32 < 3.14 || id33 != 0.0)
More Information:
v1.0 aggregate_alarm AC Configuration
alarm_enrichment
The alarm_enrichment probe is a pre-processor probe for the nas probe. Alarm_enrichment attaches itself to a permanent queue and receives
alarm messages distributed by the Hub.
This probe is documented along with the nas probe.
apache (Apache HTTP Server Monitoring)

The Apache HTTP Server Monitoring (apache) probe monitors all the Apache-based HTTP servers of an organization to detect any performance
issues. It performs HTTP GET queries to the specified Apache web servers and transforms the query result into alarms and Quality of Service for
Service Level Agreements (SLA).
The probe also performs the following functions:
Provides central, agent-less, monitoring of multiple Apache HTTP servers.
Monitors server level measures and response time for individual Apache HTTP servers.
Supports monitoring of individual requested resources.
Provides Quality of Service data for trend analysis.
Detects Apache server problems and degradations.
Identifies bottlenecks and point of failure.
Alerts a proactive response for problems impacting the service
Minimizes service downtime.
Monitors server HTTP response times.
Monitors server-status parameters.

Monitors extended server-status including requests running in separate worker threads.
Supports scoreboard data for instance number of requests waiting for connection.
More information:
apache (Apache HTTP Server Monitoring) Release Notes
apache AC Configuration
Configure the Apache HTTP Server Monitoring (apache) probe to monitor the status and performance of the Apache web server. You can add the
target Apache web server to the probe and can configure the required checkpoints.
The following diagram outlines the process to configure the probe to monitor Apache web server.
Create a Profile
Activate the Checkpoints
Alarm Thresholds
Verify that required hardware and software is available before you configure the probe. For more information, see apache (Apache HTTP Server
Monitoring) Release Notes.
Create a Profile
Add Apache web server to this probe to connect and request necessary information from that server. The probe can connect and request
necessary information from the apache server, after the host is added.
Follow these steps:
1. Click the Options (icon) next to the apache node.
2. Select Add New Host option.
The General Profile Configuration dialog appears.
3. Set or modify the following values, as required:
3.
Hostname or IP address: Specify the IP address or the hostname of the Apache web server system in the Hostname field
Active: Select Active to activate the profile and start monitoring the Apache server, on profile creation.
Alarm Message: Select the alarm message to be generated, when the Apache web server host does not respond.
Override Default Suppression ID: Select this checkbox to override the default suppression ID with the specified suppression ID.
Suppression ID: (If Override Default Suppression ID checkbox is selected) Define the new suppression ID for filtering alarm
messages.
Server Address for HTTP Response and Server Status: Define the apache web server address in the <server
address>/server-status?auto. For Example: www.apache.org/server-status?auto
Data Collection Interval: Specify the time interval for collecting data from the Apache web server.
Default: 5 minutes
Note: Reduce this interval to generate alarms frequently. A shorter interval can also increase the system load.
Extended Status: Select this checkbox to collect detailed information on the status (for example, detailed connection and request
information) from the Apache web server. The extended status information is displayed in the right pane, when selecting the Apache
Connection sub-node for the Apache server.
Note: Enabling the Extended Status option can result in increased server load.
Use SSL: Select this checkbox to allow the probe to use HTTPS to connect with the Apache web server.
Peer Verification: (If Use SSL checkbox is selected) Select this check box to enable peer verification. Peer is the certification
authority which issues the SSL certificates.
Certification Authority Bundle Path: (If Use SSL checkbox is selected) Specifies the certification bundle path for the SSL
verification.
Note: The bundle contains certificates of all the issuing authorities. For the verification of SSL certificates, the certification
bundle path is necessary.
Host Verification: Select this check box to enable the host verification. This option verifies whether the hostname matches the names
that are stored in the Apache web server certificate.
Note: Localhost (host) is added, by default, to the probe.
Host Verification Level: Select one of the following levels for verifying a host:
Loose: The host name is not verified against the CN (Common Name) attribute appearing in the SSL certificate. The host
verification checks if the IP address or host name points to the same Apache web server
Strict: The host name is verified against the CN (Common Name) attribute appearing in the SSL certificate. If the host name
does not match the CN field, the session request gets rejected.
Note: Host Verification Level is enabled only when Host Verification is selected.
4. Click Submit button.

The profile is created successfully
Activate the required checkpoints to fetch monitoring data, after you create a profile. The checkpoints allow you to generate alarms when the
specified thresholds are breached and also generates QoS data at specified intervals.
Follow these steps:

1. Navigate to the Monitors node under the profile name node.
2. Select the required monitor from the Monitors section.
3. Select the Publish Alarms option and configure the alarm fields: Threshold Operator, Threshold Value, and Alarm Message.
Note: The probe does not generate alarms even if Publish Alarms is selected.
4. Select the Publish Data option, if available, for generating QoS data for the monitor.
5. Click Save to apply these changes.
Alarm Thresholds
allow the probe to:
apache AC GUI Reference

This article describes the fields in the Admin Console interface for Apache HTTP Server Monitoring (apache) probe.
Contents
apache Node
Profile-Host Name
Apache Server Node
Connection Node
apache Node
You can configure the general properties of the probe. These properties apply to all the monitoring checkpoints of an Apache web server.
Navigation: apache
apache > Probe Information
This section provides information about the probe name, version, start time, and the probe vendor
apache > General Configuration
This section allows you to configure the log properties and timeout settings for the Apache HTTP Server Monitoring probe.
Log level: specifies the level of details that are written to the log file.
Default: 0 - Fatal
Note: Log as little as possible during normal operation to minimize disk consumption, and increase the amount of detail when
debugging.
Total Operation Timeout (Seconds): defines the time in seconds the probe waits to get a response from the server.
Default: 300
Connect Timeout (Seconds): defines the time limit for establishing a connection between the Apache web server and the probe.
Default: 10
apache > Message Pool: displays default alarm messages that are generated at the different error conditions.
Profile-Host Name
The Profile-host name node is used to configure the host name or the IP address of the system, where the Apache web server is deployed. This
node is displayed as a child node under the group name node.
Navigation: apache > Profile-host name
Profile-host name > Apache Host Information
This section is used to update the host name or IP address of the Apache HTTP server.
Navigation: apache> Options (icon)> Add New Host
The Add New Host option configures the properties of the monitored host. Each Apache host is displayed as a child node under the host name no
de.
Navigation: apache > Profile-host name > host name > Application Server
Application Server > Host Configuration
This section configures the basic properties, required for the probe to connect and start a communication with the Apache host.
Hostname or IP address: defines the host name or IP address of the system where the Apache web server is deployed.
Alarm Message: specifies the alarm message to be generated when the Apache web server host does not respond.
Override Default Suppression ID: allows you to override the default suppression ID with the specified suppression ID.
Suppression ID: defines the new suppression ID to filter certain alarm messages. The defined suppression ID will override the default
suppression ID.
Server Address for HTTP Response and Server Status: defines the Apache web server address in the <server
address>/server-status?auto format.
Data Collection Interval: specifies the time interval for collecting data from the Apache web server.
Default: 5 minutes
Extended Status: enables you to collect detailed information on the status (for example, detailed connection and request information)
from the Apache web server. This option works only if the Apache server configuration file is configured for providing the necessary
details.
Use SSL: allows the probe to use HTTPS to connect to the Apache web server securely.
Peer Verification: enables or disables the peer verification. Peer is the certification authority who issues the SSL certificates.
Certification Authority Bundle Path: specifies the certification bundle path for the SSL verification. The server path contains
certificates of all the issuing authorities. For the verification of SSL certificates, the certification bundle path is required.
Host Verification: enables or disables the host verification. This option verifies whether the hostname matches the names that are
stored in the server certificate.
Host Verification Level: specifies one of the following levels for verifying a host:
Loose: The host name is not verified against the CN (Common Name) attribute appearing in the SSL certificate. The verification
checks if the IP address or host name points to the same server
Strict: The host name is verified against the CN (Common Name) attribute appearing in the SSL certificate. If the host name does
not match the CN field, the session request gets rejected.

Apache Server Node
The Apache Server node (default for each host) configures the checkpoints for the hosts being monitored. These checkpoints are classified
under the following nodes:
Connection
Connection Mode
ScoreBoard
ScoreBoard %
Server
Navigation: apache> Profile-localhost> localhost> Application Server> Apache Server
Notes:
Each category checkpoint is available under the specific category.
For more information on checkpoints, refer to the apache Metrics.
Connection Node
The Connection node is used to configure the following checkpoints:

Navigation: apache > Profile-host name > host name > Application Server > Apache Server > Connection
Connection > Child Avg Mbytes
This section is used to configure the Child Avg Mbytes checkpoint.
Active: activates the monitoring of the checkpoint.
Name: identifies the checkpoint name.
Class: identifies the class under which the checkpoint is classified.
Group: identifies the group name of the checkpoint. The group can either be Connection or Server.
Monitoring Object: identifies the Apache object (connection or the server), which is monitored by the checkpoint. This object is
preconfigured against each checkpoint in the probe.
Description: gives a description of the monitoring object.
Compute Average: allows you to calculate average of the values that are measured during the selected time interval and then
compare it with the threshold value. Select one of the predefined intervals from the drop-down list.
Operator: specifies the threshold operator.
Threshold Value: defines the alarm threshold value. In case, this value is breached (see the Value and Operator fields) alarm is
generated.
Message Token: specifies the alarm message that is generated when the specified threshold value is breached. These messages
are kept in the Message Pool.
Override Default Suppression ID: allows you to override the default suppression id with the specified suppression id.
Suppression ID: defines the suppression id (overriding the default suppression ID) used to filter out certain alarm messages.
Note: You can configure the other checkpoints same as the Child Avg Mbytes checkpoint.
apache IM Configuration
The following diagram outlines the process to configure the probe.
Contents
Create a Profile
Activate the Required checkpoints
Create Alarm Messages
Create a Profile
Add Apache web server to this probe to connect and request necessary information from that server.
Follow these steps:
1. Select an existing group. You can also create a new group for the host.
2. Click New Host button.
Suppression ID: Define the new Suppression ID for filtering alarm messages.
Notes:
If Override Default Suppression ID option is selected, it is mandatory to enter the Suppression ID,
The Suppression ID textbox is enabled, only if Override Default Suppression ID option is selected.
Default: 5 minutes
Notes:
Reduce this interval to generate alarms frequently. A shorter interval can also increase the system load.
This specified time interval overrules the Common minimum data collection interval that is defined on the Setup dialog.
Note: Enabling the Extended Status option can result in increased server load
authority which issues SSL certificates.
verification.
Information: The certification bundle path is required for the verification of SSL certificates. The bundle contains certificates
of all the issuing authorities.
Host Verification: Select this checkbox to enable the host verification. This option verifies whether the hostname matches the names
Note: A Host Verification Level is enabled only when Host Verification is selected.
4.
4. Click the Test button to verify the connection between the host and the probe.
5. If the credentials are correct, a connection is established
6. Click OK.
The profile is created successfully.

specified thresholds are breached and QoS data at the specified intervals.
Follow these steps:
1. Navigate to the Apache Server node under the profile name node.
2. Select the checkbox next to the required monitor to enable the alarms.
3. Double-click the required monitor to enable the alarm configuration and QoS. You can also right-click and select edit to enable the
alarms.
The Edit Monitor screen is displayed.
Click OK button to save the checkpoints.

The alarm messages for each alarm situation are stored in the Message Pool. You can edit the existing alarm messages or can create a new
alarm message with the Message Pool Manager.
Follow these steps:
1. Click the Message Pool Manager button in the tool bar.
2. Click the Add button to create an alarm message.
3. Enter the Name of the alarm message.
4. Select a pre-defined alarm message from the Token dropdown.
5. Enter the Alarm Message text that is generated when the defined threshold is breached.
6. Enter the Clear Alarm message text.
7. Define the Subsystem_ID of the alarms generated. A string or an ID managed by the nas.
8. Select the Severity Level of the alarm.
9. Click OK to create the alarm.
apache IM GUI Reference

This article describes the fields in the Infrastructure Manager interface of the Apache HTTP Server Monitoring (apache) probe.
Contents
The Tool Bar

General Setup
Create a New Host
The Left Pane
The Right Pane
Viewing the Apache Summary Report
Show Summary Database Status
The Checkpoint Monitoring Properties
Message Pool Manager
The Tool Bar

The toolbar contains the following tool buttons:
General Setup: allows you to set or modify the general probe parameters.
Show Summary Database Status: displays the database status of the monitored hosts in the right pane.
The graph displays the backlog and summary data, only of the first and the last date which are recorded in the database.
Create a New Group Folder: enables you to create a folder in the left window pane. Use the folder to group the monitored hosts
logically.
Create a New Host Profile: enables you to create a host to be monitored in the folder selected from the left pane..
Message Pool Manager: enables you to modify the alarm text. You can also create your own messages.
View Apache Summary: displays the Apache Summary Report for the selected host. The graph displays the HTTP response time and
the cache hits and misses per day.
Show/Hide checkpoints that are not available: enables you to hide or show the checkpoints or monitors that are not available for the
selected host.
General Setup
Click the General Setup button to open the Setup dialog. General Setub tab has three sections - General, Advanced, and Timeout.
General tab
This section allows you to configure the log level for the probe.
Log-level - specifies the level of details that are written to a log file.
debugging.
Advanced Tab
Autorefresh GUI: Select this checkbox to automatically update the GUI to display the most recent measured values.
Maximum Summary Storage (used for local monitoring - will not affect QoS data): enables you to select the maximum data storage
time from the drop-down list. The monitored values in the selected time range are used to calculate the average value. The average is
used when setting the alarm threshold. For example, 24 hours means that only the values that are stored within the last 24 hours are
used.
Maximum concurrent threads: specifies the maximum number of profiles that the probe runs simultaneously. The valid range is 0 - 100.
Timeout Tab
Total operation timeout: defines the time (in seconds) the probe waits to get a response from the server.
Connect timeout: specifies the timeout (in seconds) the probe takes to connect with the server.
Create a New Host

Host Name or IP address: defines the host name or IP address of the system where the Apache web server is deployed.
Suppression ID: defines the new suppression id overriding the default suppression ID to filter certain alarm messages.
Default: 5 minutes
Extended Status: allows you to collect extended status (including detailed connection and request information) from the Apache web
server. This option works only if the Apache server configuration file is configured for providing the necessary details.

Use SSL: allows the probe to use HTTPS to connect to the Apache web server.
Certification Authority Bundle Path: specifies the certification bundle path for the SSL verification. The path contains certificates of all
the issuing authorities. For the verification of SSL certificates, the certification path is required.
Host Verification: enables or disables the host verification, which verifies the hostname with the names that are stored in the server
certificate.
Strict: The host name is verified against the CN (Common Name) attribute appearing in the SSL certificate. If the host name does not
match the CN field, the session request gets rejected.
The Left Pane

The left pane displays the various groups and hosts that belong to a group. Each host has two sub-nodes, which are displayed in the left pane:
Apache Server
Displays all checkpoints, that include the measured values displayed on the server status.
Apache Connection
Displays the extended status information (includes the detailed connection and request information) from the server.
The Apache Connection node also displays the connection status for the host as follows:
Indicates that the host responds.
Indicates that the host does not respond.
Initializing, waiting for measured values from the profile.
Indicates that the host responds, but has no monitored interfaces.
Activate the monitors that you want to monitor. Click Show/Hide checkpoints that are not available checkbox.
Right-click in the pane to open a context menu to display the following options:
New Host: allows you to create a host for monitoring
Available only when a group is selected.
New Group: Enables you to create a folder in the left pane. Use the folder to group the monitored hosts logically.
Edit: allows you to modify the host properties.
Available only when a host is selected.
Delete: allows you to delete the selected host or group.
Rename: enables you to rename the selected group or host.
Refresh: displays the current values of the objects that are listed in the right pane.
Note: If you attempt to refresh a host that does not respond, the checkpoint description in the right pane appears in red.
Activate All: activates all monitors on the selected host.

Deactivate All: deactivates all monitors on the selected host.
The Right Pane

The right pane of the probe displays the following options, depending on the selection in the navigation pane:
Hosts: displays the host in a group that is selected in the left-pane.
All checkpoints: displays the checkpoint or monitors of a host that is selected in the left-pane.
The following icons appear in the right pane, indicating the status of the checkpoint:
Green: the monitor is active.
Red: indicates an error situation.
Black: the monitor is not active.
Yellow: the last measurement failed.
Right-clicking in the pane allows you to perform the following functions,
Edit: enables you to modify the properties of the selected monitor.
Activate: activates the enabled monitors monitored by the probe. You can also select the required monitors.
Deactivate: deactivates the selected monitor.
Monitor: displays the values that are recorded because the probe was started.
Note: The horizontal red line in the graph indicates the alarm threshold (in this case 90 percent) defined for the checkpoint.
If you click inside the graph, a red vertical line appears. Continue to hold the line to read the exact value at different points in the graph.
The value is displayed in the upper part of the graph in the format: <Day> <Time> <Value>
The status bar displays the following information:

The number of samples monitored by the probe, since the probe was started.
The minimum value of the response time measured by the probe.
The average value of the response time measured by the probe. measured.
The maximum value of the response time measured by the probe. measured.
The backlog.
Note: Right-click in the monitor window to select the backlog or the time range. The horizontal blue line in the graph
represents the average sample value. The time range in the graph cannot be greater than the defined Maximum Data
storage time in the Setup dialog.

The apache summary report displays the HTTP response time for the selected period. You can select a graph from the drop-down that displays
the following values for the selected time period.
Per hour: displays the values of one hour for the period that is selected using the From and To fields.
Per day: displays the values of one day for the period that is selected using the From and To fields.
Last day: displays the values of one hour of the last day.
Last month: displays the values of one hour of the last month.

The Show Summary Database Status button displays a summarized view of the database status of the monitored hosts. The list displays the
first and the last day summary data that are recorded in the database.The data also displays the number of records in the period.
Delete Summary Data: allows you to delete the database of the selected or complete time period.

The Checkpoint Monitor Properties dialog for a checkpoint or monitor, enables you to modify the monitoring properties for the monitor.
Description: provides additional information of the checkpoint.
Monitoring Object: defines the name of the monitoring object.
Enable Monitoring: activates the monitoring of the checkpoint.
Value
Last/Current Sample
Uses the last measured value to compare with the specified threshold value.
Compute Average
Computes the average of the measure values in the selected time interval. Select one of the predefined intervals from the drop-down
list. You can type your own value in the field.
Operator: specifies operator to use when defining the alarm threshold.
Examples:
= 90 means generate an alarm if the measured value is 90.
=> 90 means generate an alarm if the measured value is equal to or above 90.
Threshold Value: specifies the alarm threshold value.
Unit: specifies the unit of the monitored value. For example, %, Mbytes.
Message Token: allows you to select the alarm message to be generated if the specified threshold value is breached.
Publish Quality of Service (QoS): allows you to generate a QoS data.

The Message Pool Manager displays the list of alarm messages that are available in the probe. You can also create or edit new messages.
Identification Name: defines the name of the alarm message.
Token: identifies the predefined alarms.
Error Alarm Text: allows you to specify the alarm message text, which is generated if the defined threshold is breached.
Clear Alarm Text: allows you to specify the clear alarm message text.
Severity: specifies the alarm messages severity level.
Subsystem: identifies the alarm subsystem ID that defines the alarm source.
apache Server Configuration

The apache probe is configured to enable organizations to centrally monitor all their Apache based HTTP servers, thus ensuring that any
irregularities in performance and availability are detected at the earliest possible stage. The Quality of Service data provided by the Apache probe
makes it possible to detect performance trends enabling the organization to take precautionary actions before the users notice any degradations
of the service.
Contents
Retrieving Performance from the Apache HTTP server

Preparing the Apache Servers to Deliver Extended Status
Retrieving Performance from the Apache HTTP server

The probe retrieves performance data from the Apache HTTP server using HTTP to access the server-status URL of the server to be monitored.
The Apache HTTP server provides a module for reporting performance data over HTTP. The URL that directs to this page is "<server
name>/server-status". You can view the sample output from the Web server of Apache.org, the organization behind the HTTP server.
Note: The server-status module must have been installed and configured on the Apache HTTP server to be monitored. The server-stat
us module allows the computer hosting the monitoring probe to access the server-page.
Access the URL http://www.apache.org/server-status and it returns the verbose version of the status page. You can add the "?auto" at the end of
the URL and access the less verbose version of the page; for example, http://www.apache.org/server-status?auto. The less verbose version is
more suitable for programmatic use.
Note: The less verbose version does not return connection level details. Therefore, it is not possible to monitor individual resources
using this option.
You can restrict access to authorized users or computers (the IP addresses), while configuring the server-status page. You can avoid the
availability of the information to the intruders by restricting the access.
The Extended Status module must be installed on the Apache HTTP server for retrieving detailed worker thread information. A worker thread is
used for handling individual requested resources. However, this option is not required to achieve the server level monitoring.
Note: All official documentation for the Apache HTTP server is available online and can be found here: http://httpd.apache.org/docs.
Preparing the Apache Servers to Deliver Extended Status

Add a section in the configuration file on each of the Apache servers for reading the extended status information of the server.
Follow these steps:
1. Open the httpd.conf file.
This file is available at the following location:
Windows Hosts: C:\Program Files\Apache Software Foundation\Apache2.2\conf
Linux Hosts: %PATH% /APACHE 2 / conf
2. Activate the LoadModule status_module modules/mod_status.so in the file by removing the #-sign.
3. Add the following code snippet at the end of the file:
ExtendedStatus On
<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .nimsoft.no
</Location>
Note: Replace .nimsoft.no in the preceding example with your domain (or part of it). The ExtendedStatus On in the preceding
example is optional and it is included only if you want to receive extended status. The extended status includes the detailed
connection and request information of the server.
4. Restart the server after updating the configuration file for activating the new configuration settings.
Use the command din/apachectl - k restart or use the apache service monitor for restarting the server.
Note: Select the ExtendedStatus on the probe GUI for each of the Apache servers.
apache Metrics
This article describes the metrics that can be configured for the Apache HTTP Server Monitoring (apache) probe.
Contents
QoS Metrics
QoS Metrics
The following table describes the QoS metrics that can be configured using the Apache HTTP Server Monitoring probe.
Metric Name
Units
Description
Version
QOS_APACHE_BUSYWORKERS
Count
The number of busy threads on the server.
1.5
QOS_APACHE_BYTESPERREQ
Bytes/Seconds
The average number of bytes transferred per request.
1.5
QOS_APACHE_CHILDAVEMBYTES
MBytes
The average megabytes transferred by the child in all connections.
1.5
QOS_APACHE_CHILDMAXMBYTES
MBytes
The maximum megabytes transferred by the child in any current

connection.
1.5
QOS_APACHE_CLOSINGCONNECTION
Count
The number of workers closing a connection.
1.5
QOS_APACHE_CLOSINGCONNECTIONPCT
Percent
The percentage of number of workers closing a connection.
1.5
QOS_APACHE_CONNAVEKBYTES
KBytes
The average number of kilobytes transferred in all connections.
1.5
QOS_APACHE_CONNMAXKBYTES
KBytes
The maximum number of kilobytes transferred in any current

connection.
1.5
QOS_APACHE_CPULOAD
Percent
The current CPU Load on the server.
1.5
QOS_APACHE_DNSLOOKUP
Count
The number of workers currently requesting the DNS lookup.
1.5
QOS_APACHE_DNSLOOKUPPCT
Percent
The percentage of number of workers currently requesting the DNS

lookup.
1.5
QOS_APACHE_GRACEFULLYFINISHING
Count
The number of workers currently gracefully finishing connections.
1.5
QOS_APACHE_GRACEFULLYFINISHINGPCT
Percent
The percentage of number of workers currently gracefully finishing

connections.
1.5
QOS_APACHE_HTTPRESTIME
Milliseconds
The time taken by the apache server to handle server-page request.
1.5
QOS_APACHE_HTTPRESVALUE
State
The value of server response.
1.5
QOS_APACHE_IDLECLEANUPOFWORKER
Count
The number of workers, which are currently performing idle cleanup

procedure.
1.5
QOS_APACHE_IDLECLEANUPOFWORKERPCT
Percent
The percentage of number of workers, which are currently

performing idle cleanup procedure.
1.5
QOS_APACHE_IDLEWORKERS
Count
The number of idle threads on the server.
1.5
QOS_APACHE_KEEPALIVE
Count
The number of workers currently sending keepalive messages.
1.5
QOS_APACHE_KEEPALIVEPCT
Percent
The percentage of number of workers currently sending keepalive

messages.
1.5
QOS_APACHE_LOGGING
Count
The number of workers currently busy updating log files.
1.5
QOS_APACHE_LOGGINGPCT
Percent
The percentage of number of workers currently busy updating log

files.
1.5
QOS_APACHE_OPENSLOTNOCURRENTREQUEST
Count
The number of workers currently not busy with any process.
1.5
QOS_APACHE_OPENSLOTNOCURRENTREQUESTPCT
Percent
The percentage of number of workers currently not busy with any

process.
1.5
QOS_APACHE_READINGREQUEST
Count
The number of workers currently reading incoming requests.
1.5
QOS_APACHE_READINGREQUESTPCT
Percent
The percentage of number of workers currently reading incoming

requests.
1.5
QOS_APACHE_REQAVETIME
Millisecond
The average time required to process most recent request from all
current connections.
1.5
QOS_APACHE_REQMAXTIME
Millisecond
The maximum time required to process most recent request from

any current connection.
1.5
QOS_APACHE_REQPERSEC
Count/Second
The number of requests received per second in the apache server.
1.5
QOS_APACHE_SENDINGREPLY
Count
The number of workers currently sending a reply.
1.5
QOS_APACHE_SENDINGREPLYPCT
Percent
The percentage of number of workers currently sending a reply.
1.5
QOS_APACHE_SLOTAVEMBYTES
MBytes
The average value of the total megabytes transferred in this slot from
all current connections.
1.5
QOS_APACHE_SLOTMAXMBYTES
MBytes
The maximum value of the total megabytes transferred in this slot

from any current connection.
1.5
QOS_APACHE_STARTINGUP
Count
The number of workers currently starting up a connection.
1.5
QOS_APACHE_STARTINGUPPCT
Percent
The percentage of number of workers currently starting up a

connection.
1.5
QOS_APACHE_SSAVETIME
Seconds
The average time since the beginning of request in seconds.
1.5
QOS_APACHE_SSMAXTIME
Seconds
The maximum time since the beginning of request in seconds.
1.5
QOS_APACHE_STATECSSAVETIME
Seconds
Current average of all SS, where mode is C.
1.5
C = The closing connection.
QOS_APACHE_STATECSSMAXTIME
Seconds
Maximum occurrence of SS, where mode is C.
1.5
QOS_APACHE_STATEDSSAVETIME
Seconds
Current average of all SS, where Mode is D.
1.5
D = The DNS Lookup
QOS_APACHE_STATEDSSMAXTIME
Seconds
Maximum occurrence of SS, where mode is D.
1.5
QOS_APACHE_STATEKSSAVETIME
Seconds
Current average of all SS, where mode is K.
1.5
K = Keepalive (read)
QOS_APACHE_STATEKSSMAXTIME
Seconds
Maximum occurrence of SS, where mode is K.
1.5
QOS_APACHE_STATELSSAVETIME
Seconds
Current average of all SS, where mode is L.
1.5
L = Logging
QOS_APACHE_STATELSSMAXTIME
Seconds
Maximum occurrence of SS, where mode is L.
1.5
QOS_APACHE_STATERSSAVETIME
Seconds
Current average of all SS, where mode is R.
1.5
R = Reading Request
QOS_APACHE_STATERSSMAXTIME
Seconds
Maximum occurrence of SS, where mode is R.
1.5
QOS_APACHE_STATEWSSAVETIME
Seconds
Current average of all SS, where mode is W.
1.5
W = Sending Reply
QOS_APACHE_STATEWSSMAXTIME
Seconds
Maximum occurrence of SS, where mode is W.
1.5
QOS_APACHE_WAITINGFORCONNECTION
Count
The number of workers currently waiting for a connection.
1.5
QOS_APACHE_WAITINGFORCONNECTIONPCT
Percent
The percentage of number of workers currently waiting for a

connection.
1.5

This table contains the alert metrics default settings for the Apache HTTP Server Monitoring probe.
QoS Metric
Warning
Threshold
Warning
Severity
Error
Threshold
Error
Severity
Description
MsgAgentError -
Critical
If the server is not running on $host, MsgAgentError is generated. The default value of the
MsgAgentError is defined in the Message Properties dialog.
MsgWarning
Warning
If the checkpoint breaches threshold, MsgWarning is generated. The default value of the
MsgWarning is defined in the Message Properties dialog.
MsgError
Critical
If the checkpoint breaches threshold, MsgError is generated. The default value of the
MsgError is defined in the Message Properties dialog.
apache Version 1.6

This section contains documentation for version 1.61 of the apache probe:
v1.6 apache AC Configuration
v1.6 apache IM Configuration
v1.6 apache AC Configuration

The following diagram outlines the process to configure the probe to monitor Apache web server.
Create a Profile
Alarm Thresholds
Create a Profile
Add Apache web server to this probe to connect and request necessary information from that server. The probe can connect and request
necessary information from the apache server, after the host is added.
Follow these steps:
1. Click the Options (icon) next to the apache node.
2. Select Add New Host option.
Suppression ID: (If Override Default Suppression ID checkbox is selected) Define the new suppression ID for filtering alarm
messages.
Default: 5 minutes
Note: Enabling the Extended Status option can result in increased server load.
authority which issues the SSL certificates.
verification.
Note: The bundle contains certificates of all the issuing authorities. For the verification of SSL certificates, the certification
bundle path is necessary.
Host Verification: Select this check box to enable the host verification. This option verifies whether the hostname matches the names
Strict: The host name is verified against the CN (Common Name) attribute appearing in the SSL certificate. If the host name
does not match the CN field, the session request gets rejected.
Note: Host Verification Level is enabled only when Host Verification is selected.
4. Click Submit button.

The profile is created successfully

specified thresholds are breached and also generates QoS data at specified intervals.
Follow these steps:

2. Select the required monitor from the Monitors section.
Note: The probe does not generate alarms even if Publish Alarms is selected.
5.
Alarm Thresholds
allow the probe to:
v1.6 apache AC GUI Reference

This article describes the fields in the Admin Console interface for Apache HTTP Server Monitoring (apache) probe.
Contents
apache Node
Profile-Host Name
Apache Server Node
Connection Node
apache Node
You can configure the general properties of the probe. These properties apply to all the monitoring checkpoints of an Apache web server.
Navigation: apache
apache > Probe Information
This section provides information about the probe name, version, start time, and the probe vendor
apache > General Configuration
This section allows you to configure the log properties and timeout settings for the Apache HTTP Server Monitoring probe.
Default: 0 - Fatal
debugging.
Total Operation Timeout (Seconds): defines the time in seconds the probe waits to get a response from the server.
Default: 300
Connect Timeout (Seconds): defines the time limit for establishing a connection between the Apache web server and the probe.
Default: 10
apache > Message Pool: displays default alarm messages that are generated at the different error conditions.
Profile-Host Name
The Profile-host name node is used to configure the host name or the IP address of the system, where the Apache web server is deployed. This
node is displayed as a child node under the group name node.
Navigation: apache > Profile-host name
Profile-host name > Apache Host Information
This section is used to update the host name or IP address of the Apache HTTP server.
Navigation: apache> Options (icon)> Add New Host
The Add New Host option configures the properties of the monitored host. Each Apache host is displayed as a child node under the host name no
de.
Navigation: apache > Profile-host name > host name > Application Server
Application Server > Host Configuration
This section configures the basic properties, required for the probe to connect and start a communication with the Apache host.
Hostname or IP address: defines the host name or IP address of the system where the Apache web server is deployed.
Override Default Suppression ID: allows you to override the default suppression ID with the specified suppression ID.
Suppression ID: defines the new suppression ID to filter certain alarm messages. The defined suppression ID will override the default
suppression ID.
Default: 5 minutes
Extended Status: enables you to collect detailed information on the status (for example, detailed connection and request information)
from the Apache web server. This option works only if the Apache server configuration file is configured for providing the necessary
details.
Use SSL: allows the probe to use HTTPS to connect to the Apache web server securely.
Certification Authority Bundle Path: specifies the certification bundle path for the SSL verification. The server path contains
certificates of all the issuing authorities. For the verification of SSL certificates, the certification bundle path is required.
Host Verification: enables or disables the host verification. This option verifies whether the hostname matches the names that are
stored in the server certificate.
Apache Server Node
The Apache Server node (default for each host) configures the checkpoints for the hosts being monitored. These checkpoints are classified
under the following nodes:
Connection
Connection Mode
ScoreBoard
ScoreBoard %
Server
Navigation: apache> Profile-localhost> localhost> Application Server> Apache Server
Notes:
Each category checkpoint is available under the specific category.
For more information on checkpoints, refer to the apache Metrics.
Connection Node
The Connection node is used to configure the following checkpoints:

Navigation: apache > Profile-host name > host name > Application Server > Apache Server > Connection
Connection > Child Avg Mbytes
This section is used to configure the Child Avg Mbytes checkpoint.
Active: activates the monitoring of the checkpoint.
Name: identifies the checkpoint name.
Class: identifies the class under which the checkpoint is classified.
Group: identifies the group name of the checkpoint. The group can either be Connection or Server.
Monitoring Object: identifies the Apache object (connection or the server), which is monitored by the checkpoint. This object is
preconfigured against each checkpoint in the probe.
Description: gives a description of the monitoring object.
Compute Average: allows you to calculate average of the values that are measured during the selected time interval and then
compare it with the threshold value. Select one of the predefined intervals from the drop-down list.
Operator: specifies the threshold operator.
Threshold Value: defines the alarm threshold value. In case, this value is breached (see the Value and Operator fields) alarm is
generated.
Message Token: specifies the alarm message that is generated when the specified threshold value is breached. These messages
are kept in the Message Pool.
Suppression ID: defines the suppression id (overriding the default suppression ID) used to filter out certain alarm messages.
Note: You can configure the other checkpoints same as the Child Avg Mbytes checkpoint.
v1.6 apache IM Configuration

Contents
Create a Profile
Monitoring) Release Notes
Create a Profile
Add Apache web server to this probe to connect and request necessary information from that server.
Follow these steps:
1. Select an existing group. You can also create a new group for the host.
2. Click New Host button.
Suppression ID: Define the new Suppression ID for filtering alarm messages.
Notes:
If Override Default Suppression ID option is selected, it is mandatory to enter the Suppression ID,
The Suppression ID textbox is enabled, only if Override Default Suppression ID option is selected.
Default: 5 minutes
Notes:
Reduce this interval to generate alarms frequently. A shorter interval can also increase the system load.
This specified time interval overrules the Common minimum data collection interval that is defined on the Setup dialog.
Note: Enabling the Extended Status option can result in increased server load
authority which issues SSL certificates.
verification.
Information: The certification bundle path is required for the verification of SSL certificates. The bundle contains certificates
of all the issuing authorities.
Host Verification: Select this checkbox to enable the host verification. This option verifies whether the hostname matches the names
Note: A Host Verification Level is enabled only when Host Verification is selected.
4. Click the Test button to verify the connection between the host and the probe.
5. If the credentials are correct, a connection is established
6. Click OK.
The profile is created successfully.

specified thresholds are breached and QoS data at the specified intervals.
Follow these steps:
1. Navigate to the Apache Server node under the profile name node.
2. Select the checkbox next to the required monitor to enable the alarms.
3. Double-click the required monitor to enable the alarm configuration and QoS. You can also right-click and select edit to enable the
alarms.
The Edit Monitor screen is displayed.
Click OK button to save the checkpoints.

The alarm messages for each alarm situation are stored in the Message Pool. You can edit the existing alarm messages or can create a new
alarm message with the Message Pool Manager.
Follow these steps:
1. Click the Message Pool Manager button in the tool bar.
2. Click the Add button to create an alarm message.
3. Enter the Name of the alarm message.
4. Select a pre-defined alarm message from the Token dropdown.
5. Enter the Alarm Message text that is generated when the defined threshold is breached.
6. Enter the Clear Alarm message text.
7. Define the Subsystem_ID of the alarms generated. A string or an ID managed by the nas.
8. Select the Severity Level of the alarm.
9. Click OK to create the alarm.
v1.6 apache IM GUI Reference

This article describes the fields in the Infrastructure Manager interface of the Apache HTTP Server Monitoring (apache) probe.
Contents
The Tool Bar

General Setup
Create a New Host
The Left Pane
The Right Pane
The Tool Bar
The toolbar contains the following tool buttons:

General Setup: allows you to set or modify the general probe parameters.
Show Summary Database Status: displays the database status of the monitored hosts in the right pane.
The graph displays the backlog and summary data, only of the first and the last date which are recorded in the database.
Create a New Group Folder: enables you to create a folder in the left window pane. Use the folder to group the monitored hosts
logically.
Create a New Host Profile: enables you to create a host to be monitored in the folder selected from the left pane..
Message Pool Manager: enables you to modify the alarm text. You can also create your own messages.
View Apache Summary: displays the Apache Summary Report for the selected host. The graph displays the HTTP response time and
the cache hits and misses per day.
Show/Hide checkpoints that are not available: enables you to hide or show the checkpoints or monitors that are not available for the
selected host.
General Setup
Click the General Setup button to open the Setup dialog. General Setub tab has three sections - General, Advanced, and Timeout.
General tab
This section allows you to configure the log level for the probe.
Log-level - specifies the level of details that are written to a log file.
debugging.
Advanced Tab
Autorefresh GUI: Select this checkbox to automatically update the GUI to display the most recent measured values.
Maximum Summary Storage (used for local monitoring - will not affect QoS data): enables you to select the maximum data storage
time from the drop-down list. The monitored values in the selected time range are used to calculate the average value. The average is
used when setting the alarm threshold. For example, 24 hours means that only the values that are stored within the last 24 hours are
used.
Maximum concurrent threads: specifies the maximum number of profiles that the probe runs simultaneously. The valid range is 0 - 100.
Timeout Tab
Total operation timeout: defines the time (in seconds) the probe waits to get a response from the server.
Connect timeout: specifies the timeout (in seconds) the probe takes to connect with the server.
Create a New Host
Host Name or IP address: defines the host name or IP address of the system where the Apache web server is deployed.
Suppression ID: defines the new suppression id overriding the default suppression ID to filter certain alarm messages.
Default: 5 minutes
Extended Status: allows you to collect extended status (including detailed connection and request information) from the Apache web
server. This option works only if the Apache server configuration file is configured for providing the necessary details.
Use SSL: allows the probe to use HTTPS to connect to the Apache web server.
Certification Authority Bundle Path: specifies the certification bundle path for the SSL verification. The path contains certificates of all
the issuing authorities. For the verification of SSL certificates, the certification path is required.
Host Verification: enables or disables the host verification, which verifies the hostname with the names that are stored in the server
certificate.
Strict: The host name is verified against the CN (Common Name) attribute appearing in the SSL certificate. If the host name does not
match the CN field, the session request gets rejected.
The Left Pane
The left pane displays the various groups and hosts that belong to a group. Each host has two sub-nodes, which are displayed in the left pane:
Apache Server
Displays all checkpoints, that include the measured values displayed on the server status.
Apache Connection
Displays the extended status information (includes the detailed connection and request information) from the server.
The Apache Connection node also displays the connection status for the host as follows:
Indicates that the host responds, but has no monitored interfaces.
Activate the monitors that you want to monitor. Click Show/Hide checkpoints that are not available checkbox.
Right-click in the pane to open a context menu to display the following options:
New Host: allows you to create a host for monitoring
New Group: Enables you to create a folder in the left pane. Use the folder to group the monitored hosts logically.
Edit: allows you to modify the host properties.
Delete: allows you to delete the selected host or group.
Rename: enables you to rename the selected group or host.
Refresh: displays the current values of the objects that are listed in the right pane.
Note: If you attempt to refresh a host that does not respond, the checkpoint description in the right pane appears in red.
Activate All: activates all monitors on the selected host.

Deactivate All: deactivates all monitors on the selected host.
The Right Pane
The right pane of the probe displays the following options, depending on the selection in the navigation pane:
Hosts: displays the host in a group that is selected in the left-pane.
All checkpoints: displays the checkpoint or monitors of a host that is selected in the left-pane.
The following icons appear in the right pane, indicating the status of the checkpoint:
Green: the monitor is active.
Red: indicates an error situation.
Black: the monitor is not active.
Yellow: the last measurement failed.
Right-clicking in the pane allows you to perform the following functions,
Edit: enables you to modify the properties of the selected monitor.

Activate: activates the enabled monitors monitored by the probe. You can also select the required monitors.
Deactivate: deactivates the selected monitor.
Monitor: displays the values that are recorded because the probe was started.
Note: The horizontal red line in the graph indicates the alarm threshold (in this case 90 percent) defined for the checkpoint.
If you click inside the graph, a red vertical line appears. Continue to hold the line to read the exact value at different points in the graph.
The value is displayed in the upper part of the graph in the format: <Day> <Time> <Value>
The status bar displays the following information:

The number of samples monitored by the probe, since the probe was started.
The minimum value of the response time measured by the probe.
The average value of the response time measured by the probe. measured.
The maximum value of the response time measured by the probe. measured.
The backlog.
Note: Right-click in the monitor window to select the backlog or the time range. The horizontal blue line in the graph
represents the average sample value. The time range in the graph cannot be greater than the defined Maximum Data
storage time in the Setup dialog.
The apache summary report displays the HTTP response time for the selected period. You can select a graph from the drop-down that displays
the following values for the selected time period.
Per hour: displays the values of one hour for the period that is selected using the From and To fields.
Per day: displays the values of one day for the period that is selected using the From and To fields.
Last day: displays the values of one hour of the last day.
Last month: displays the values of one hour of the last month.
The Show Summary Database Status button displays a summarized view of the database status of the monitored hosts. The list displays the
first and the last day summary data that are recorded in the database.The data also displays the number of records in the period.
Delete Summary Data: allows you to delete the database of the selected or complete time period.
The Checkpoint Monitor Properties dialog for a checkpoint or monitor, enables you to modify the monitoring properties for the monitor.
Description: provides additional information of the checkpoint.
Monitoring Object: defines the name of the monitoring object.
Enable Monitoring: activates the monitoring of the checkpoint.
Value
Last/Current Sample
Uses the last measured value to compare with the specified threshold value.
Compute Average
Computes the average of the measure values in the selected time interval. Select one of the predefined intervals from the drop-down
list. You can type your own value in the field.
Operator: specifies operator to use when defining the alarm threshold.
Examples:
= 90 means generate an alarm if the measured value is 90.
=> 90 means generate an alarm if the measured value is equal to or above 90.
Threshold Value: specifies the alarm threshold value.
Unit: specifies the unit of the monitored value. For example, %, Mbytes.
Message Token: allows you to select the alarm message to be generated if the specified threshold value is breached.
Publish Quality of Service (QoS): allows you to generate a QoS data.
The Message Pool Manager displays the list of alarm messages that are available in the probe. You can also create or edit new messages.
Identification Name: defines the name of the alarm message.
Error Alarm Text: allows you to specify the alarm message text, which is generated if the defined threshold is breached.
Clear Alarm Text: allows you to specify the clear alarm message text.
Subsystem: identifies the alarm subsystem ID that defines the alarm source.
apmgtw (CA APM Gateway)

The CA Unified Infrastructure Management CA APM Gateway Probe (apmgtw) probe sends QoS messages from CA Unified Infrastructure
Management probes to your CA Application Performance Management (APM) database.
You configure the apmgtw probe to send QoS messages and alarms from those CA Unified Infrastructure Management probes that you define.
And for each probe that you configure apmgtw to report on, you can also define the specific QoS metrics that apmgtw sends to the CA APM
database.
You configure CA APM to use this data in dashboards.
Related topics:
apmgtw (CA APM Gateway) Release Notes
v2.0 apmgtw AC Configuration

This section describes the configuration of the CA APM Gateway (apmgtw) probe in CA Unified Infrastructure Management.
Contents
Overview
Set Up the apmgtw Probe
Define the Probes and Corresponding QoS Measurements for Reporting
Verify apmgtw Probe Function in CA APM
View Reports in CA APM
Supported CA Unified Infrastructure Management Probes
Overview
1. Install the probe only on a robot on a primary hub.
2. Configure the probe in the Admin Console UI.
Note: The probe is only configurable in the Admin Console UI.
Set Up the apmgtw Probe

1. In Admin Console, select the apmgtw probe> Configure.
2. In the details pane, in the Probe Configuration section, keep, or modify the following settings:
CA APM Enterprise Manager Server
Set the Server Host Name or IP Address of the CA APM Enterprise Manager (EM) server.
CA APM Enterprise Manager Server Port
Set the port number of the CA APM Enterprise Manager server. The default is 5001.
Probe log level
The default value is 3. The minimum value is 1 and the maximum value is 5. The maximum value yields the most detail. We
recommend using levels 4 and 5 only for troubleshooting. Return to log level 3 or lower after troubleshooting to minimize log file size.
Included Origins
An origin identifies a hub within a CA Unified Infrastructure Management domain. You can define the included origins for which the
apmgtw probe fetches metrics. If you define included origins, the probe fetches metrics from only those origins.
Included Hosts
You can specify the included hosts, the specific resources, for which the apmgtw probe reports QoS messages to CA APM. Enter the
host names, not the IP addresses.
Expiration
You can set the expiration for publishing data. The expiration is the maximum number of minutes, after the last value received from
any probe, that apmgtw continues sending QoS messages to CA APM. The default is 30 minutes.
Display Origin
You can display or hide the origin. If you display the origin, enter one or more origin (hub) names separated by a comma. The default
is true.
Prefetch Hosts
By default, the value for this field is set to false. As a result, the probe fetches host information while it processes the first QoS
message from a host. If you want the probe to prefetch host data when the probe starts up, set the value to true.

The probe sends QoS messages from select CA Unified Infrastructure Management probes to the CA APM database. You configure the apmgtw
probe to send QoS messages from those probes that you select.
Follow these steps:
1. In Admin Console, select the apmgtw probe> Configure.
In the navigation pane, each probe for which you can configure the QoS messages is listed as a separate node.
2. Select the node that corresponds to the probe for which you want to configure the QoS messages.
3. Check or clear the box next to the Enable QoS publishing field to enable or disable QoS message publishing for the probe.
4. In the detail pane below the Enable QoS publishing field for each probe, select which QoS messages you want to enable for the probe
by checking the appropriate boxes.
5. Repeat the previous steps until all the probes and their QoS messages are configured.
6. Click Save.
7. Deactivate and activate the probe for the changes to take effect.
You configured the apmgtw probe to send QoS messages from the desired probes
Verify apmgtw Probe Function in CA APM

To verify that the apmgtw probe is functioning in CA APM, look for the probe resources in CA APM Workstation.
Follow these steps:
1. In CA APM, navigate to Workstation>Investigator>Metric Browser.
2. In the navigation tree in the left pane, click> the machine name that you supplied CA APM with for the <Nimsoft Monitor Server>
Nimsoft> NimsoftAgent>Nimsoft QoS>Nimsoft Hub> <ProbeName> > <ResourceName> > <QoSMessage>.
3. Underneath the probes in the tree hierarchy, are the Resources and QoS reported to CA APM from the apmgtw probe.
If no Resources or QoS are displayed in <APM> Workstation, then the probe is not configured properly or there are no QoS messages
available to send to CA APM.
Check configurations or call support.
View Reports in CA APM

For more information about working with reports in CA APM, go to the CA Application Performance Management wiki. Look for the CA APM
Workstation User Guide section.

The apmgtw probe is certified to monitor the QoS data of the following CA Unified Infrastructure Management probes:
Active Directory Response (ad_response)
CPU, Disk, Memory Monitoring (cdm)
DB2 (db2)
DNS Response Monitoring (dns_response)
E2E Application Response Monitoring (e2e_appmon)
Citrix Client Response Monitoring (ica_response)
LDAP Server Response Monitoring (ldap_response)
MySQL Server Monitoring (mysql)
Network Connectivity Monitoring (net_connect)
Windows NT Services Monitoring (ntservices)
Oracle Database Monitoring (oracle)
Process Monitoring (processes)
Remote System Probe (rsp)
SQL Server Response Monitoring (sql_response)
SQL Server Monitoring (sqlserver)
URL Endpoint Response Monitoring (url_response)

VMware Monitoring (vmware)
XenDesktop Monitoring (xendesktop)
XenApp Monitoring (xenapp)
v1.1 apmgtw IM Configuration
Contents
Overview
Specify the CA APM Enterprise Manager Server
Specify the Port Number of the CA APM Enterprise Manager Server
Set the Probe Log Level
Define Included Origins for the Probe
Specify Included Hosts for the Probe
Display or Hide Probe Origin
Set Expiration for Publishing Data
Set Prefetch Hosts Value
PrimaryHub Host
Manage QoS Messages
Overview
1. In Infrastructure Manager, double-click or right-click the apmgtw probe> Configure.
2. The configuration window opens.
In the configuration window, the following Probe Configurations can be set:

Set the Server Host Name or IP Address of the CA APM Enterprise Manager server.

Set the port number of the CA APM Enterprise Manager server. The default, port number is 5001.

You can set the level of detail written to the probe log file.
Follow these steps:
1. In Infrastructure Manager, double click or right click the apmgtw probe.
2. In the configuration window Log Level field, enter the desired value.
Note: The default value is 3; the minimum value is 1 and the maximum value is 5. The maximum value yields the most detail.
You set the log level.

An origin identifies a hub within a CA Unified Infrastructure Management domain. You can define the included origins for which the apmgtw probe
fetches metrics.
Follow these steps:
2. In the configuration window Included Origins field, enter the desired origins separated by a comma.
Note: If you define included origins, the probe fetches metrics from only those origins.
You specified the included origins.

You can specify the included hosts, the specific resources, for which the apmgtw probe reports QoS messages to CA APM.
Follow these steps:
2. In the configuration window Included Hosts field, enter the desired hosts, separated by a comma.
Note: Enter the host names, not the IP addresses.
You specified the included hosts.
Note: If you specify included hosts, then the apmgtw probe sends QoS messages from only those hosts.

You can choose to display or hide the origin.
Follow these steps:
2. In the configuration window Display Origin field, select either true or false.
Note: The default is true.
3. (Optional) If you select true, enter one or more origin (hub) names separated by a comma.
You set the visibility of the origin.

The expiration is the maximum number of minutes, after the last value received from any UIM probe under monitor, that the apmgtw probe
continues to send QoS messages to APM.
You can set the expiration for publishing data.
Follow these steps:
2.
2. In the configuration window Expiration field, enter the desired value in minutes.
Note: The default is 30 minutes.
You set the expiration for publishing data.
Note: The expiration applies to all QoS messages that the apmgtw probe is configured to send. The probe stops sending QoS
messages to APM after this expiration time is met. However, if a UIM probe under monitor starts sending a QoS message again after
this, the apmgtw probe automatically resumes sending that data to CA APM.

By default, the value for this field is set to false. As a result, the probe fetches host information while it processes the first QoS message from a
host.
If you want the probe to prefetch host data when the probe starts up, set the value to true .
Follow these steps:
2. In the configuration window Prefetch Hosts field, select the desired value: either true or false.
You set the prefetch hosts value.
PrimaryHub Host
You can specify the Primary Hub host name of the CA Unified Infrastructure Management Infrastructure Manager. This is optional when the
apmgtw probe is deployed on a robot present in Primary Hub. This is mandatory field, when apmgtw probe is deployed on a robot present in a
Secondary Hub.
You can specify the primary hub host value.
Follow these steps:
2. In the configuration window, in the PrimaryHub Host field, enter the name or IP Address of the primary hub.
Manage QoS Messages

The apmgtw probe sends the QoS messages of all the probes which are being monitored to CA APM, when QoS Enabled field is set to True. If
this field value is set to false, then QoS messages will not be sent to CA APM. By default, this value will be True.
You can choose QoS Enabled.
Follow these steps:
2. In the configuration window, in the QoS Enabled field, select the desired value.

probe to send QoS messages from those CA Unified Infrastructure Management probes that you select in the apmgtw probe configuration in the
ShowQoS window.
Follow these steps:
2. In the configuration window, click Config QoS.
2.
Note: Every time you click Config QoS, the probes and QoS present in Nimbus at that instance are fetched and shown in the
ShowQoS window.
3. In the resultant ShowQoS window, each probe is shown as a tab in the window. All the QoS available in Nimbus for each probe are listed
under each of the tabs.
4. Select the probe which apmgtw probe wants to monitor by clicking on the appropriate tab.
5. Under the selected tab, select the first checkbox item in the list, which is Enable QoS publishing for <Probe Name> probe.
6. Select the QoS for this probe by selecting the checkboxes of the QoS messages.
8. Click Save button in the ShowQoS window.
9. Click Save button in Config UI.
10. Click Yes when the probe asks for restart.

The apmgtw probe v1.1 is certified to monitor the QoS data of the following CA Unified Infrastructure Management probes:
DB2 (db2)
v1.1 apmgtw Advanced Configuration

This article describes optional advanced configuration tasks to optimize the CA APM Gateway (apmgtw) probe settings for your environment.
Contents
Set the Java Paths

Edit the console.bat File to Set the Java Path
Edit the qosutil.bat File to Set the Java Path
Configure a Metric to Include a Target
Configure a Metric to Include a Defined Target or Source
Set the Java Paths

Follow these steps:

1. In the Tools folder, find the console.bat file.
2. Right click on the file and from the pulldown menu, choose Edit with Notepad.
3. Edit the Java path.
4. Example:
set JAVA_HOME=C:\Program Files (x86)\Java\jre7
5. Save and update.

You set the Java path in the console.bat file.
Next, edit the qosutil.bat file to set the Java path.
Follow these steps:

1. In the Tools folder, find the qosutil.bat file.
4. Example:
5. Save and update.

You set the Java path in the qosutil.bat file.

You can format a metric so that it includes a target that the apmgtw probe matches on.
Follow these steps:
1. In the qos.properties file, go to the QoS Metric Format section.
2. Define or locate the desired metric.
3. Add the desired target to the end of the metric.
For Example:
You can include a target that contains a certain string, such as 'MemoryOverallUsage:'
format.vmware.QOS_MEMORY_PERC_USAGE.MemoryOverallUsage\ (%\ of\ MemoryM

axUsage)={host}|VMware|Resources:{target:/:last}
The apmgtw probe then reports on any metric that matches the format, and includes the target.
In this case, the probe reports on any QOS_MEMORY_USAGE metric from the vmware probe that has a target containing the string
'MemoryOverallUsage':
You configured a metric so that it includes a target.

You can format a metric so that it includes a defined target, source, or both.
Follow these steps:
3. Add the desired target or source information to the end of the metric.
a. Delimit the metric outputs token 1 of the target by a '/'.
b. Delimit the metric outputs token 0 of the source by a '-'.
Examples:
format.cdm.QOS_CPU_USAGE={host}|CPU Usage:{target:/:1}
format.cdm.QOS_CPU_USAGE={host}|CPU Usage:{source:-:0}
You configured a metric to include a defined target, source, or both.
v1.1 Verify apmgtw Probe Function CA APM

To verify that the apmgtw probe is functioning in CA APM, look for the probe's resources in CA APM Workstation.
Follow these steps:
If no Resources and QoS are displayed in <APM> Workstation, then the apmgtw probe is not configured properly or there are no QoS
messages available in CA Unified Infrastructure Management to send to CA APM.
v1.1 Verify apmgtw Probe Function in CA UIM

To verify that the CA APM Gateway (apmgtw) probe is functioning in CA Unified Infrastructure Management, run the console.bat utility and look
for the metrics that the probe fetches from the message bus.
Note: Set the probe to inactive before you run the console.bat utility.
Follow these steps:

1. In CA Unified Infrastructure Management, navigate to the apmgtw files >Tools>console.bat.
2. Run console.bat.
In the command prompt window, console.bat displays the probe metrics that the probe fetches from the message bus.
If no probe metrics are displayed, the apmgtw probe is not functioning in CA Unified Infrastructure Management.
v1.1 View apmgtw Reports in CA APM

For more information about viewing and working with reports in CA APM, go to the CA Application Performance Management wiki and look for the
CA APM Workstation User Guide section.
v1.0 apmgtw IM Configuration
Contents
Overview
PrimaryHub Host
Manage QoS Messages
Overview
1. In Infrastructure Manager, double-click or right-click the apmgtw probe> Configure.
2. The configuration window opens.
In the configuration window, the following Probe Configurations can be set:

Set the Server Host Name or IP Address of the CA APM Enterprise Manager server.

Set the port number of the CA APM Enterprise Manager server. The default, port number is 5001.

You can set the level of detail written to the probe log file.
Follow these steps:
2. In the configuration window Log Level field, enter the desired value.
Note: The default value is 3; the minimum value is 1 and the maximum value is 5. The maximum value yields the most detail.
You set the log level.

An origin identifies a hub within a CA Unified Infrastructure Management domain. You can define the included origins for which the apmgtw probe
fetches metrics.
Follow these steps:
2. In the configuration window Included Origins field, enter the desired origins separated by a comma.
Note: If you define included origins, the probe fetches metrics from only those origins.
You specified the included origins.

You can specify the included hosts, the specific resources, for which the apmgtw probe reports QoS messages to CA APM.
Follow these steps:
2. In the configuration window Included Hosts field, enter the desired hosts, separated by a comma.
Note: Enter the host names, not the IP addresses.
You specified the included hosts.
Note: If you specify included hosts, then the apmgtw probe sends QoS messages from only those hosts.

You can choose to display or hide the origin.
Follow these steps:
2. In the configuration window Display Origin field, select either true or false.
Note: The default is true.
3. (Optional) If you select true, enter one or more origin (hub) names separated by a comma.
You set the visibility of the origin.

The expiration is the maximum number of minutes, after the last value received from any UIM probe under monitor, that the apmgtw probe
continues to send QoS messages to APM.
You can set the expiration for publishing data.
Follow these steps:
1.

2. In the configuration window Expiration field, enter the desired value in minutes.
Note: The default is 30 minutes.
You set the expiration for publishing data.
Note: The expiration applies to all QoS messages that the apmgtw probe is configured to send. The probe stops sending QoS
messages to APM after this expiration time is met. However, if a UIM probe under monitor starts sending a QoS message again after
this, the apmgtw probe automatically resumes sending that data to CA APM.

By default, the value for this field is set to false. As a result, the probe fetches host information while it processes the first QoS message from a
host.
If you want the probe to prefetch host data when the probe starts up, set the value to true .
Follow these steps:
2. In the configuration window Prefetch Hosts field, select the desired value: either true or false.
You set the prefetch hosts value.
PrimaryHub Host
You can specify the Primary Hub host name of the CA Unified Infrastructure Management Infrastructure Manager. This is optional when the
apmgtw probe is deployed on a robot present in Primary Hub. This is mandatory field, when apmgtw probe is deployed on a robot present in a
Secondary Hub.
You can specify the primary hub host value.
Follow these steps:
2. In the configuration window, in the PrimaryHub Host field, enter the name or IP Address of the primary hub.
Manage QoS Messages

The apmgtw probe sends the QoS messages of all the probes which are being monitored to CA APM, when QoS Enabled field is set to True. If
this field value is set to false, then QoS messages will not be sent to CA APM. By default, this value will be True.
You can choose QoS Enabled.
Follow these steps:
2. In the configuration window, in the QoS Enabled field, select the desired value.

probe to send QoS messages from those CA Unified Infrastructure Management probes that you select in the apmgtw probe configuration in the
ShowQoS window.
Follow these steps:
2. In the configuration window, click Config QoS.
2.
Note: Every time you click Config QoS, the probes and QoS present in Nimbus at that instance are fetched and shown in the
ShowQoS window.
3. In the resultant ShowQoS window, each probe is shown as a tab in the window. All the QoS available in Nimbus for each probe are listed
under each of the tabs.
4. Select the probe which apmgtw probe wants to monitor by clicking on the appropriate tab.
5. Under the selected tab, select the first checkbox item in the list, which is Enable QoS publishing for <Probe Name> probe.
6. Select the QoS for this probe by selecting the checkboxes of the QoS messages.
8. Click Save button in the ShowQoS window.
9. Click Save button in Config UI.
10. Click Yes when the probe asks for restart.

The apmgtw probe v1.0 is certified to monitor the QoS data of the following CA Unified Infrastructure Management probes:
DB2 (db2)
v1.0 apmgtw Advanced Configuration

This article describes optional advanced configuration tasks to optimize the CA APM Gateway (apmgtw) probe settings for your environment.
Contents
Set the Java Paths

Set the Java Paths
Follow these steps:

1. In the Tools folder, find the console.bat file.
4. Example:
5. Save and update.

You set the Java path in the console.bat file.
Next, edit the qosutil.bat file to set the Java path.
Follow these steps:

1. In the Tools folder, find the qosutil.bat file.
4. Example:
5. Save and update.

You set the Java path in the qosutil.bat file.

You can format a metric so that it includes a target that the apmgtw probe matches on.
Follow these steps:
3. Add the desired target to the end of the metric.
For Example:
You can include a target that contains a certain string, such as 'MemoryOverallUsage:'
format.vmware.QOS_MEMORY_PERC_USAGE.MemoryOverallUsage\ (%\ of\ M

emoryMaxUsage)={host}|VMware|Resources:{target:/:last}
The apmgtw probe then reports on any metric that matches the format, and includes the target.
In this case, the probe reports on any QOS_MEMORY_USAGE metric from the vmware probe that has a target containing the string
'MemoryOverallUsage':
You configured a metric so that it includes a target.

You can format a metric so that it includes a defined target, source, or both.
Follow these steps:

3. Add the desired target or source information to the end of the metric.
Examples:
format.cdm.QOS_CPU_USAGE={host}|CPU Usage:{target:/:1}
The metric outputs token 1 of the target delimited by a '/'.
format.cdm.QOS_CPU_USAGE={host}|CPU Usage:{source:-:0}
The metric outputs token 0 of the source delimited by a '-'.

You configured a metric to include a defined target, source, or both.
v1.0 Verify apmgtw Probe Function in CA APM

To verify that the apmgtw probe is functioning in CA APM, look for the probe's resources in CA APM Workstation.
Follow these steps:
If no Resources and QoS are displayed in <APM> Workstation, then the apmgtw probe is not configured properly or there are no QoS
messages available in CA Unified Infrastructure Management to send to CA APM.
v1.0 Verify apmgtw Probe Function in CA UIM

To verify that the CA APM Gateway (apmgtw) probe is functioning in CA Unified Infrastructure Management, run the console.bat utility and look
for the metrics that the probe fetches from the message bus.
Note: Set the probe to inactive before you run the console.bat utility.
Follow these steps:

1. In CA Unified Infrastructure Management, navigate to the apmgtw files >Tools>console.bat.
2. Run console.bat.
In the command prompt window, console.bat displays the probe metrics that the probe fetches from the message bus.
If no probe metrics are displayed, the apmgtw probe is not functioning in CA Unified Infrastructure Management.
v1.0 View apmgtw Reports in CA APM

For more information about viewing and working with reports in CA APM, go to the CA Application Performance Management wiki and look for the
CA APM Workstation User Guide section.
apmgtw Metrics
The CA APM Gateway (apmgtw) probe is a gateway probe that does not generate any QoS. Therefore, there are no probe checkpoint metrics to
be configured for this probe.
assetmgmt (Asset Management) - no longer supported

The asset management probe primarily performs the task of inventory collection of probes. The inventory is collected only for the probes which
are active and running.
When the probe is deployed for the first time, it fetches all data_engine probes in the current domain and makes the first data_engine found as
default data source for data collection. In addition to this the probe sets the default inventory collection time to 4 weeks by default. The probe
collects information about all the categories of probes.
v1.2 assetmgmt IM GUI Reference

Setup
Email configuration
Database configuration
Report
Setup
The Setup tab enables you to specify the depth (level) to which the messages should be logged as well as the interval at which the report will be
generated.
Field
Description
Log Level
Sets the level of messages written to the log file. By default, the slider is set to minimum log level.
Report Interval
Choose the time interval at which the report is to be generated. By default, this is set to 4 minutes.
Email configuration
The Email Configuration tab allows you to connect to an email server.
Field
Description
Primary
Mail
Server
Specify the address of the SMTP server
Ignore
TLS
Allows you to specify that TLS (Transport Layer Security) negotiation should NOT be attempted even if the server announces that
the capability exists. This because some servers will announce TLS capability even if is not there, usually due to a missing
certificate. By default, this checkbox is unselected.
Username
Password
Enter the username and password for SMTP server authentication
You can verify the settings by clicking the Test button.
Database configuration
The Database Configuration tab allows you to specify the database configuration to the data_engine probe.
On selecting the Choose Date Engine option, the drop-down menu is populated with all the data engines available in the domain. By default, the
first data engine is displayed.
You can also manually specify the database details by choosing the Set Database Configuration option. Provide the necessary details such as
name of the database, initial catalog, data source, user ID and password in the respective fields. A default string is preconfigured in the Parameter
s field.
You can verify the settings by clicking the Test Connection button.
Report
The Report tab displays the cumulative count of server probes for all the domains found, and the server probe count for individual robots.
assetmgmt Metrics
The Asset Management (assetmgmt) probe does not generate any QoS. Therefore, there are no metrics to be configured for this probe.
audit
The audit probe maintains data structures for UIM Server monitoring. When deployed, the audit probe performs the following tasks:
Creates AUDIT tables in the UIM database.
Adds an audit queue to the hub and stores audit messages in the database.
Monitors changes to your UIM environment and sends audit messages to the Primary Hub.
Audit messages, or events, are generated from the following actions:
User Commands - User activities such as activating probes.
Probe Commands - Probe activities such as distsrv probe package distributions.
On initial probe startup, the audit probe does the following:
1. Checks if an audit queue is available on the hub. If there is no audit queue, the queue is created.
Important! If the audit probe cannot create a permanent hub queue, it subscribes to audit messages and a temporary queue is
created. This can lead to a loss of audit messages if the audit probe is stopped.
2. Retrieves the UIM database connection string from the data_engine probe.
3. Creates the tables for the audit messages in the UIM database.
The audit probe can collect audit messages from robots on one hub or from robots on all of the hubs in a UIM Domain.
More information:
audit Release Notes
v1.2 audit IM Configuration

This article describes how to configure the audit probe.
Tip: If you need descriptions of the fields in the audit probe GUI, see the article v1.2 audit GUI Reference
The following diagram shows the tasks you should complete to configure the audit probe.
Deploy the audit Probe
(Optional) Change the Database Connection
Apply Auditing to the UIM Robots
(Optional) Add Filters
(Optional) Change any Advanced Settings

Change the Log File Parameters
Change the Data Retention Period and Occurrence Time
Change the Database Connection Settings
Change the Auditing Settings in the Robot Configuration File (robot.cfg)
The audit probe requires the appropriate version of the compat-libstdc++ runtime library to be installed on your system. This is required for C++
runtime compatibility. The copy of distribution specific compat-libstdc++ runtime library can be obtained from one of the following links:
http://rpm.pbone.net
http://rpmfind.net
Deploy the audit Probe

After installing CA UIM, the audit probe is available for deployment in the local archive. Before you can begin changing configuration settings, you
must deploy and activate the audit probe.
(Optional) Change the Database Connection

By default, the audit probe searches for the data_engine probe in your environment and uses its connection string to add items to the UIM
database. If you not want UIM administrators to have write access to the audit tables, you can create a separate database and modify the audit
connection settings.
Follow these steps:
1. In the audit probe configuration GUI, click Setup (
).
2. In the Database connection section, click Specify database connection information:

3. Select your database vendor and enter the appropriate connection information. For more information about each field, see the article v1.2
audit GUI Reference.
Apply Auditing to the UIM Robots

Note: Prior to applying auditing to your robots, you might see events originating from the hub probe. These events are inserted by the
hub probe and are related to hub login. You can disable these messages by adding the audit = off key to the <hub> section of the hub
configuration file (hub.cfg).
Follow these steps:
1. In the audit probe configuration GUI, click Administer (
). The Audit administration dialog opens.
2. Click Find robots, configure your robot search settings, and click OK. A list of available robots appears in the Audit administration
window. The status of each robot is denoted by the icon next to it:
- The robot does not support auditing.
- The audit probe cannot communicate with the robot. This can occur if the system the robot is deployed to is turned off.
- The robot is being audited.
- The robot is not being audited.
3. Select the robots you want to audit and click Enable audit.
Tip: The Audit administration window supports multi-select using <shift> or <ctrl>.
(Optional) Add Filters

The audit probe comes with a set of standard filters that you can use for your auditing data. If necessary, you can also create your own filters.
Follow these steps:
1. In the audit probe configuration GUI, do one of the following:
Click New Filter (
).
In the list of filters, right-click and select New Filter.

In the main window, right-click on an event that you want to filter on and select Create filter. This method populates the filter field with
the information from the selected event.
2. Choose the fields that you want to use as filter criteria. Note the following:
Filter fields in the same filter use AND criteria.
Clicking the small button next to a filter field activates NOT criteria for that field. When NOT criteria is being used, the small button
next turns red.
For more information about each field, see the article v1.2 audit GUI Reference.
3. Click Save as, enter a filter name and group, then click OK. If you enter a filter group that does not already exist, a new group folder is
created.
The new filter is now available in the left filter pane.
(Optional) Change any Advanced Settings

Advanced configuration options are available in the following locations:
The audit probe Infrastructure Manager GUI
The audit probe Raw Configure menu in either Admin Console or Infrastructure Manager.
The configuration files for each robot (robot.cfg)
Change the Log File Parameters

You can change both the audit log file size and the level of the alerts that are documented. The default location of the audit log file is <UIM
Install>\probes\service\audit.
Follow these steps:
).
2. In the Log Setup section, change the Level field desired logging level. The log levels that you can specify are:
Level 0 - Fatal - Logs severe messages
Level 1 - Error - Logs errors
Level 2 - Warn - Logs warnings
Level 3 - Info - Logs informational messages
Level 4 - Debug - Logs debugging messages
Level 5 - Trace - Logs tracing/low-level debugging messages
3. Change the Size(KB) field to the desired log size in KB.
Change the Data Retention Period and Occurrence Time

By default, the data in the audit tables is stored for 30 days. You can change the retention settings so that your auditing data is kept for a different
length of time. You can also change the administration time and interval. During administration time, data in the auditing tables is checked against
the set retention period and removed if necessary.
Follow these steps:
).
2. In the Data administration section, change the Drop data after: field to your desired retention period in days. You can select one of the
defined values or enter your own.
3. Change the Administration time to the desired time of day and interval length. For example, if you enter 03:00:00 interval 24:00:00,
data administration takes place every day at 3AM.
Change the Database Connection Settings

You can specify the following database connection information for the audit probe:
the number of simultaneous database connections.
the length of time that the database connections are kept open.
Follow these steps:
1. Open the Raw Configure menu for the audit probe.
2. Change the following values:
pool_keep_alive - The length of time the database connection stays open in seconds.
threads_query_pool - The number of simultaneous connections allowed for the audit probe. Note that new connections are only
established when existing connections are in use. For example, if threads_query_pool is set to 5, a 6th request results in an out of
resources error.
Change the Auditing Settings in the Robot Configuration File (robot.cfg)

When the audit probe is deployed, an audit configuration key is added to the robot configuration file (robot.cfg). Advanced users can alter the
values in this field to fine-tune their auditing settings.
Supported Values
The supported values for the audit key are as follows:

5 - Enable auditing and send messages to the message bus using the subject AUDIT.
6 - Enable auditing and save the messages to a file called audit.txt in the Nimsoft\Robot directory.
7 - A combination of both 5 and 6. Enable auditing, send the messages to the message bus, and save the messages to a file.
8 - Enable auditing for robots deployed to hubs with audit=robot in their hub configuration files (hub.cfg).
With the exception of the 8, these values are determined by combining several base options that control auditing behavior:
1 - Audit message are sent to a file called audit.txt in the Nimsoft\Robot directory.
2 - Audit messages are sent to the message bus with subject AUDIT.
4 - Audit messages are enabled.
For example, the 6 value indicates that base options 4 and 2 are activated.
Note: You cannot set the value of the audit key to 1,2, or 4. The write settings value (1 or 2) must be combined with the enable auditing
base value (4).
The 8 value does not follow this formula, it is a unique value that defers to the hub settings for auditing.
v1.2 audit Event Reference

The tables in this article list possible auditing events that you can encounter. Note that events can:
be associated with a user command, probe, or both.
contain no message information.
Contents
Controller Events
Hub Events
Infrastructure Manager Events
Note: The file size limit for configuration file comparison is set by in the controller configuration file using the audit_max_config_size
key. The default is 0 (unlimited).
Controller Events
Probe
Message
controller
Audit - full reset (index file not accessible)
controller
Audit - full reset (index file checksum error)
controller
Audit - full reset (Unable to open index file)
User Command
controller
_stop
controller
_shutdown
controller
To <address> (<ip>) from <address> (<ip>)
sethub
controller
Hub contact established / Hub contacted
hubcall_robotup
controller
Robot stop
controller
Hub contact established
controller
Hub contacted
controller
Leave maintenance mode
<probe name>
Probe removed
<probe name>
Probe audit re-initiated
<probe name>
Probe audit initiated
<probe name>
Audit initiated
<probe name>
Probe audit re-initiated
<probe name>
File change detected, but file is too large for change details comparison
<probe name>
File changes detected
<probe name>
probe_register
<probe name>
<varies according to parameters and changes>
probe_config_set
<probe name>
<varies according to parameters and changes>
remote_config_set
<probe name>
Package <pkg name>, section <section name>
inst_execute
<probe name>
probe_verify
<probe name>
probe_unregister
<probe name>
probe_activate
<probe name>
probe_deactivate
<probe name>
lock / unlock / force lock
probe_config_lock
<probe name>
probe_config_set
<probe name>
probe_start
<probe name>
probe_stop
<probe name>
<parameter>=<value>
probe_change_par
<probe name>
inst_pkg_remove
<package name>
inst_request
controller
Maintenance mode until
maint_until
controller
Turn on audit / Change audit
_audit_type
<probe name>
Restored from checkpoint
_audit_restore
<as specified>
_audit_send
Hub Events
Probe
Message
hub
hub suspended for ... Seconds
hub
Deleted user: ...
hub
Deleted ACL: ...
hub
New user: ...
hub
New ACL: ...
hub
Password changed for user: ...
Infrastructure Manager Events

Message
User Command
Account/Contact Management initiated by user: ...
_audit_send
Deleting Account with ID index: ...
_audit_send
Deleting Contact with ID index: ...
_audit_send
Creating new Account with ID: ...
_audit_send
Updating Contact with ID: ...
_audit_send
v1.2 audit GUI Reference

This topic describes the options in the audit probe configuration GUI.
Contents
The audit Application Window

Setup
Log Setup Fields
Data Administration Fields
Database Connection Fields
MySQL
Oracle
The Audit Administration Dialog
The Main Window Pane
The Navigation Pane
The Filter Dialog
Raw Configure Keys
The audit Application Window
The GUI consists of:
A tool bar with four tool buttons:

Setup: General probe parameters such as logging details and data administration.
Administer: Configuration settings for robot monitoring (the monitoring scope).
Filter: Additional event filtering for the audit probe.
Refresh: Refreshes the window.
The Main window pane, which is horizontally split into two parts:
The upper part lists the events for the filter selected in the navigation pane.
The lower part lists details for the selected event.
A Navigation pane that determines which events are shown in the main window pane.
A Status information field that indicates the probe version and the time the probe last was started.
Setup
Clicking the Setup button opens the Setup dialog. The Setup dialog contains general probe parameters such as the log levels and data
administration settings.
Log Setup Fields
Level - Sets the level of detail written to the log file. We recommend logging as little as possible during normal operation in order to
minimize disk consumption.
Size (KB) - Sets the size of the probes log file. The default size is 100 KB. When this size is reached, the contents of the file are cleared.
Data Administration Fields
Drop data after - Specifies the number of days the data is kept in the audit tables before they are deleted. You can select one of the
defined values or enter your own value.
Administration time specification - Specifies the time and interval for data administration using the format 03:00:00 interval 24:00:00.
During data administration, old data is deleted from the audit tables in the database.
Database Connection Fields
Search for data_engine - The audit probe searches for the data_engine probe in your environment and uses its connection string.
Specify data_engine - If the search for data_engine option does not work in your environment, you can specify the data_engine
address.
Specify database connection information - Use this option if you want to store the audit data in a separate database. You should use
this option if you do not want UIM administrators to have modify or delete access for the audit tables.
All other fields are dependent on the database software that you are using:
Provider - The database provider name (SQLOLEDB)

Server - The database server name or IP address
Database - The database name
User - The database user name
Password - The database password for the user
Parameters - The connection parameters for the database
MySQL
Server Host - The database server name or IP address

Schema - The database schema name
Username - The database user name
Port - The connection port for the database
Oracle
Hostname - The Oracle database server hostname

Username - The database user name
Service name - The Oracle service name. The service name is located in the SERVICE_NAMES parameter in the Oracle initialization
parameter file.
Port - The connection port for the database.
The Audit Administration Dialog

Clicking the Administer button open the Audit administration dialog.
You can use the Find robots button to search for the available robots in either of the following locations:
Under a selected hub

Under all of the hubs in the UIM domain.
All located robots are displayed in the Audit administration dialog. Note the different icons for the robots found:
- The robot does not support the audit feature.
- Unable to communicate with the robot. This can occur if the system the robot is deployed to is turned off.
- The robot is enabled for audit.
- The robot is disabled for audit.
You can select the entries in the list by left-clicking them. Multi-select is also possible by using the <shift> or <ctrl> keys on the keyboard.
When one or more entries in the list are selected, you can invert the selection by clicking the Invert selection button at the bottom of the dialog.
Then the selected entries will be deselected, and the others will be selected.
Clicking the Filter button opens the filter dialog, enabling you to create your own filters.
The probe is shipped with a set of standard filters, but you can easily create your own filters. These filters can be used to find and list events
meeting the criteria specified in the filter.
The Main Window Pane
The the upper part of the window lists the events collected by the filter selected in the Navigation pane. The columns in the window can be sorted
ascending or descending by clicking the column header, and the columns can also be moved, using drag and drop.
Right-clicking in the list, a small menu opens, allowing you to:
Create a filter.
Select all entries in the list
Copy the selected entries to the clipboard.
The entries in the list are tagged with an icon, depending on type of event:
The icon for events.
The icon for user commands.
This icon for probe commands. For example, probe package distribution executed by the distsrv probe.
The list has the following columns:
Event type: Describes the type of event; event, user command or probe command.
Event time: The time the event occurred.

Event description: A textual short description of the event.
Origin: Normally the name of the hub from which the event origins (if the origin name has not been overruled on the controller probe).
Domain: The name of the domain from which the event origins.
Hub: The name of the hub from which the event origins.
Robot: The name of the robot from which the event origins.
Probe:
For Events: The name of the probe that issued the event (the controller probe).
For User commands: The name of the probe to which the command was issued
For Probe commands: The name of the probe that issued the command.
User name: The name of the user or probe that issued the command. Note that user name only applies to user commands and probe
commands.
User command: The command that triggered the event.
User IP address: The IP address of the computer from which the command triggering the event was issued. The status
Indicates the status of the event (0 or 1).
0 means status is not issued to the IP address.
1 means status is issued to the IP address.
Has config changes: True or False. Indicates if configuration file for the probe involved has changed as a result of the event
Checkpoint ID: Custom id assigned to each checkpoint for unique identification.
Event ID: A unique identification number assigned to each event.
The the lower part of the window lists the configuration modifications for a selected event.
Note: Events only appear in the lower window if the event caused a configuration change (the column Has config change is set to True)
.
There are three different types of configuration operations:
- A key was added to the configuration file.

- The value for a key was added in the configuration file.
- A key was deleted from the configuration file.
The list has the following columns:
Operation - Describes the type of configuration change (if a value was added, modified or deleted).
Section - Shows the section of the configuration file where the change occurred.
Variable - A description of the event
Old value - If a probe configuration file was changed, the value of the configuration item prior to the change.
New value - If a probe configuration file was changed, the value of the configuration item after the change.
The Navigation Pane
The Navigation pane lists the filters for determining which events are shown in the Main window pane. The probe is delivered with a set of
standard filters, but you can also define your own filters.
Right-clicking in the list lets you add, edit or delete filters.
The Filter Dialog

Clicking the Filter button in the tool bar opens the Filter dialog.
Note: The small button next to the input fields let you invert the selection (NOT expression). The buttons will turn red when selected.
The following filter fields are available:

Field
Description
Event type
Select one of the three valid types of events:

Events.
User commands (commands issued by users, such as activating a probe).
Probe commands, such as probe package distribution executed by the distsrv probe.
Event
description
This is a description of the event, and filtering is done on events messages containing the description specified If the Event type
field is empty, all valid descriptions for all even types are listed. If one of the three valid event types is selected, the
corresponding descriptions will be available.
Origin
Normally the name of the hub from which the event occurs (if the origin name has not been overruled on the controller probe).
Domain
The name of the domain to which the hub belongs to.
Hub
The name of the hub from which the event origins.
Robot
The name of the robot from which the event origins.
Probe
For Events: The name of the probe that issued the event (the controller probe).
For User commands: The name of the probe to which the command was issued.
For Probe commands: The name of the probe that issued the command.
User name
Applies for user commands and probe commands only.

The command that was issued by the user or probe.
User
command
The command that triggered the event.
User IP
The IP address of the computer from which the command triggering the event was issued.
Status
Indicates the status of the event (0 or 1).

0 means status is not issued to the IP address.
1 means status is issued to the IP address.
Configuration
changes
True or False. Match for events where the configuration file for the probe involved has changed as a result of the event.
Checkpoint
ID
It is the custom id assigned to each checkpoint for unique identification.
Time
limitations
Select the time limitations for the filter, i.e. the time limitations for the entries shown in the Main window pane when the filter is
selected in the Navigation pane.
Valid entries are:
Last hour
Last day
Last week
Last month
Specify range
If specify range is selected, the From time and To time must be specified on the format.
<day><month><year> <hour><minute><second>.
Calendar functionality is available when selecting from the list. Select the preferred day and optionally edit the time specification
as required.
Raw Configure Keys
You can modify the following values using the audit probe Raw Configure menu.
pool_keep_alive - Specify a time-interval in seconds, for which a database connection will be kept open. For example, a value of 10
indicates that the connection(s) will be kept open for 10 seconds.
threads_query_pool - Specify the number of simultaneous connections allowed for the audit probe. For example, a value of 5 indicates
that a pool of 5 database connections can be maintained at the same time.
The automated_deployment_engine probe provides powerful functions to deploy robots using XML distribution, as well as behind-the-scenes
functionality for probe and package distribution in Admin Console.
Note: Admin Console distribution was handled by the distsrv probe prior to UIM Server 8.0. Distsrv continues to provide distribution in
Infrastructure Manager.
The automated_deployment_engine configuration GUI lets you:

View probe information, including name, start time, version, and vendor.
View the archive location on the local file system.
Adjust the log level. Under General Configuration, choose a new level, then click Save.
For more information, see the articles regarding robot deployment on the CA UIM Documentation Space.
aws (Amazon Web Services Monitoring)

The Amazon Web Services (AWS) Monitoring probe remotely monitors the health and performance counters of various AWS services over a
cloud network. The probe lets you create profiles that monitor your AWS user account and fetches all the service data from the AWS CloudWatch.
The probe lets you configure various monitoring parameters on each service. Based on the configured parameters, the probe generates Quality of
Service (QoS) data and issues status alarms.
Note: The probe from version 2.01 and later is configured only through the Admin Console GUI.
Amazon Web Service (AWS): The AWS provides a decentralized IT infrastructure to multiple organizations. You can create an account
on the AWS cloud and can use its services as per your IT infrastructure requirements. The various capabilities of AWS include storage,
web-scale computing, database access, and messaging.
The AWS Monitoring probe provides monitoring of the following AWS services:
Health: The probe monitors the overall health status of the AWS services for all geographical locations. Alarms are generated based on
the status of all the AWS services.
Amazon Simple Storage Service (S3): This AWS service provides an interface for storing and fetching data at any time instance. The
AWS Monitoring probe generates QoS data based on the time consumed in storing and retrieving files.
Amazon Elastic Compute Cloud (EC2): This AWS service provides a flexible web-scale computing interface. The AWS Monitoring probe
generates QoS data and alarms that are based on the performance of various EC2 instances.
Amazon Elastic Block Storage (EBS): This AWS service provides a scalable storage volume facility for the EC2 instances. The AWS
Monitoring probe generates QoS data and alarms that are based on the operations that are performed on the storage volumes.
Amazon Relational Database Service (RDS): This AWS service manages relational databases that are stored in a cloud network.
AWS-RDS handles many database administration tasks and lets you perform other operations like setting up and scaling the database.
The AWS Monitoring probe generates QoS data and alarms that are based on the system metrics and database operations.
Amazon ElastiCache: This AWS service provides the AWS instances with an option of storing temporary data in a scalable cache
memory, and thus, increasing the processing speed. The AWS Monitoring probe generates QoS data based on the time consumed in
accessing the cache service and other parameters like amount of data stored and time taken to fetch the data.
AWS Custom Metrics: AWS provides some default metrics for all its services. Another feature of AWS is that you can create and
configure your own customized metrics, and store these metrics in the AWS CloudWatch for viewing, or monitoring purpose. These
metrics, which AWS does not generate, are called custom metrics. The AWS Monitoring probe lets you configure the custom metrics for
QoS generation.
AWS Simple Queue Service (SQS): This AWS service lets you transmit data to other services using message queues. The AWS
Monitoring probe lets you configure the message queue properties for QoS generation.
AWS Simple Notification Service (SNS): This AWS service lets you manages the notification messages that a publisher sends and a
subscriber receives through a communication channel. The AWS Monitoring probe monitors the communication channel and generates
QoS data based on the status of the notifications.
AWS Elastic Load Balancing (ELB): This AWS service lets you route the traffic that comes from various applications across multiple
available EC2 instances. The AWS Monitoring probe monitors the ELB layer at group level and generates QoS data based on the status
of the ELB layer.
AWS Auto Scaling: This AWS service lets you accumulate different EC2 instances in a group. You can create an auto scaling group
according to the usage of the EC2 instances in various applications.The AWS Monitoring probe monitors the instance status at group
level.
Important! Amazon charges the AWS account which the probe uses to monitor the AWS services. You must consider this fact while
configuring the probe for monitoring various AWS services.
More information:
AWS Monitoring (aws) Release Notes
v4.0 aws AC Configuration
The AWS Monitoring (aws) probe is configured to create monitoring profiles for accessing AWS resources and fetching data from AWS
CloudWatch. You can also configure health monitors to generate alarms on the basis of the availability of services in various geographical
regions.
The probe also lets you configure the Auto Discovery functionality. If any service instance is added or deleted in the AWS resource, then the Aut
o Discovery functionality updates the list of instances in the probe.
The probe fetches data of instances, or services and provides you with various monitors for generating QoS. You can also fetch the list of custom
metrics, created for a specific service in the AWS CloudWatch.
The following diagram outlines the process to configure the aws probe.
Contents
Prerequisites
Create a Profile
Verify the Credentials
Activate a Service
Create a Template
Create Filter Rules
Copy Templates to Another Robot
Using Regular Expressions
Alarm Thresholds
Prerequisites
Verify that required hardware and software is available before you configure the probe. For more information, see aws (Amazon Web Services
Create a Profile
Each profile represents one AWS resource. There can be multiple instances of an AWS resource. The following procedure enables you to add a
profile for monitoring the AWS services.
Follow these steps:
1. Click Options (icon) next to the AWS node in the navigation pane.
2. Click Add New Profile.
3. Define a profile name.
4. Activate the profile.
5. Specify the time interval (in seconds) after which the probe collects the data from the AWS cloud for the profile.
6. Select the Alarm Message to be generated when the connection to AWS services fails.
7. Enter the Access Key.
8. Enter Secret Access key.
Note: Valid user-credentials, such as Access Key and Secret Access Key are mandatory for creating a profile.
9. Click Submit and Save the profile.

The new monitoring profile is visible under the AWS node in the navigation pane.
The Auto Discovery functionality automatically loads a list of all the available instances.
Verify the Credentials

Click Actions > Verify Credentials in the <Profile Name> node.
The credentials of the profile are verified.
Activate a Service
You can activate the service you want to monitor on the resource group.
Follow these steps:
1. Click the required <Service>
2. Select Active in the <Service Name> node.
You can activate any of the following services:
AutoScaling
Custom Metrics
ElastiCache
ELB Node
ELB-<Region Name>
RDS
S3
SNS
SQS
The selected service is activated.
Create a Template
You can create and use templates in the probe to configure multiple profiles and services with the same monitor configuration.
Follow these steps:
1. Open the probe configuration interface.
2. Click Template Editor.
The Template Editor - <probeName> <Version> page is displayed.
3. Click the Options (icon) next to the aws probe node.
4. Click Create Template.
5. Specify a name, description for the template.
6. Specify the precedence for the template.
6.
Notes:
A numeric value is set as precedence.
The default value is 0 (highest precedence).
The precedence of a template decreases as the value increases.
Example: 1 has higher precedence than 2 and so on.
The precedence is applied on multiple templates. The scenarios are describes as follows:
When the precedence is different for the templates: The precedence works from the lower to higher hierarchy.
Example: If the precedence is set at 0 for one template, and 1 for another template, the template with 0 precedence has
higher priority.
When precedence is same for all templates: The precedence works in alphabetical order of template name.
When filters are applied on templates: The precedence works according to the applied filters. If no filter is applied, the
precedence is applied on available templates.
7. Click Submit to create the template.

The <templateName> node is displayed followed by all the Services of the profile.
8. Click a node to view the related monitors to configure and include them in the template.
9. Click the Options (icon) next to nodes representing multiple possible values (such as Profile or CPU Metrics) to create filters.
You can also configure the default Auto Filters.
Note: The same precedence rules apply to Auto Filters as well.
10. Create rules for filters, as needed.
Note: You can skip steps 8 and 9 if you do not want to configure the applicable monitors in those nodes.
11. Select Include in Template to include the monitor or section in the template.
12. The monitor or section is available for editing.
13. Configure the required monitor or section, as needed.
14. Select the <templateName>node.
15. Select Active to activate the template.
Select Save.
The template is created and applied to the probe.
Note: The section of the profile(s) configured using templates are not available for individual configuration. Clear the Active checkbox
to deactivate the template on the profile to unlock it. You can also exclude the profile using filter rules.
Important! The templates are available only for profiles excluding the Custom Metrics and Health Services.
Create Filter Rules

You can create filter rules for nodes that represent multiple possible values (such as Profile or CPU Metrics). A filter allows you to control profiles
or services associated with a particular template. You can specify additional service criteria by using rules. Filters usually contain one or more
rules to define the types of services for the template. You can add rules to a profile filter, to create divisions or reduce the set of services that are
monitored by the probe.
Follow these steps:
1.
1. Click the filter node to be configured.

2. Click New in the Rules section of a filter.
3. Specify the condition that the probe matches against the label.
4. Specify the value against which the probe matches the label.
5. Click Save to save the rule for the filter.
The filter becomes applicable to all instances that match the created rule.
Copy Templates to Another Robot

After you configure a template, you can use the existing templates on other instances of the probe. This allows you to apply consistent monitoring
across probe instances.
Templates are stored on the robot system in the <CA UIM Installation Directory>\probes\<categoryName>\<probeName>\bulk_config\raw_t
emplates directory. The templates are stored with hexadecimal names and gzip extension. For example, fd1660f2-f7f1-4f95-92be-4c09b0674587
.gzip.
Follow these steps:
1. On the robot with the probe template, navigate to the raw_templates directory.
2. Copy the .gzip files from the source directory to the corresponding raw_templates directory of the target robot.
3. Repeat Step 2 for each instance of target probe.
4. Restart the target probes.
The templates are now available for application on the required probe instances.
Note: Copy all the gzip files from the directory. You can apply the required template from the template editor interface of the target
probe instance.

A regular expression (regex for short) is a special text string for describing a search pattern. Constructing regular expression and pattern matching
requires meta characters. The probe supports Perl Compatible Regular Expression (PCRE) which are enclosed within forward slash (/). For
example, the expression /[0-9A-C]/ matches any character in the range 0 to 9 in the target string.
You can also use simple text with some wild card operators for matching the target string. For example, *test* expression matches the text test in
target string.
The following table describes some examples of regex and pattern matching for the aws probe.
[A-Z]
Standard (PCRE)
Matches any uppercase alpha character.
[A-Z:\\]
Custom
Matches with the Uppercase character type of the local disk available on the respective box
Standard (PCRE)
Matches against any character
[*.\\]
Custom
Matches for all the drives which ends with \\
Standard (PCRE)
Matches against zero or more occurrences of the previous character or expression
\d*
Custom
Matches for the name which starts from letter d
Alarm Thresholds
allow the probe to:

maintained by the NAS probe. If you are working with NMS 7.6 or earlier, you must add the following subsystem IDs manually using the NAS Raw
Configuration menu. However, if you have upgraded to CA UIM 8.0 then you do not have to manually add the following subsystem IDs:
Key Name
Value
2.19.
Amazon
2.19.1.
AWS
2.19.1.1.
Resource
2.19.1.2.
ServiceStatus
2.19.1.3.
EC2
2.19.1.4.
S3
2.19.1.5.
EBS
2.19.1.6.
RDS
2.19.1.9
ElastiCache
2.19.1.8
SNS
2.19.1.7
SQS
2.19.1.11
ELB
2.19.1.12
Auto Scaling
1. In the Admin Console, click the black arrow next to the NAS probe, select Raw Configure.
3. Click the New Key Menu item.
7. Click Apply.
1. In Infrastructure Manager, right click the NAS probe, select Raw Configure.
3. Click the New Key (...) button.
4. Enter the Key Name and Value.
5. Click OK.
7.
7. Click Apply.
v4.0 aws AC GUI Reference

This article describes the fields and features of the probe.
Contents
aws Node
<profile name> Node
EC2 Node
ElastiCache Node
<Instance Name> node
SQS Node
SQS <Region Name> node
AutoScaling Node
Auto Scale-<Region Name> node
<Auto Scale Group Name> node
ELB Node
ELB-<Region Name> node
<ELB Layer Name> node
RDS Node
<Database Name> node
SNS Node
SNS-<Region Name> node
Custom Metrics
<AWS-Service Name> node
S3 Node
Template Editor
<templateName> Node
Auto Filter or <filterName> Node
Include in Template
aws Node
This node lets you view the probe information and configure the logging properties. You can also set the polling interval for Auto Discovery functi
onality and configure the proxy settings.
Note: The aws services nodes are visible in the navigation pane only after you create a monitoring profile. Initially, only the AWS node
and the AWS Service Health node are visible.
Navigation: aws
aws > Probe Information
aws > Probe Setup
This section lets you configure the detail level of the log file. The default value is 3-info.
aws > Auto Discovery
This section lets you set the value of Discovery Interval (minutes). If any instance is added or deleted in the AWS resource, then the Auto
Discovery functionality updates the list of instances in the probe. The Discovery Interval (minutes) specifies the time between each interval the
probe runs the auto discovery functionality.
aws > Proxy Settings
This section enables you to connect to the AWS cloud through a proxy server on the network. You need proxy server settings when your network
is not an open network.
Enable Proxy: lets you use a proxy server for connecting to the AWS cloud.
IP: defines the IP address of the proxy server.
Port: specifies the port on the proxy server through which the connection is established.
Username: defines the user name for accessing the proxy server.
Note: The AWS probe is certified for use in Squid proxy environment.
aws > Add New Profile

This section lets you add a profile for monitoring the AWS services data. QoS data is generated according to the performance of these services.
Profile Name: defines a unique name for the monitoring profile. This field was identified as Name in the previous versions of the probe.
You can specify the AWS account name as the value for this field.
Active: activates the profile for service monitoring.
Interval (seconds): specifies the time interval (in seconds) after which the probe collects the data from the AWS cloud for the specific
profile.
Default: 600
Note: Interval value must be above 300 seconds.
Alarm Message: specifies the alarm to be generated when the connection to AWS services fails.
Default: ResourceCritical
Access Key: defines the login credential of the AWS user-account for accessing the AWS resource.
Secret Access Key: specifies the additional login credential of the AWS user-account.
Note: The probe uses the combination of the Access Key and Secret Access Key for accessing the AWS resource.
<profile name> Node
This node represents the profile which is created to monitor the health and performance of AWS services. Each profile is mapped with an AWS
account. You can check the connection between the probe and the AWS resource through the Verify Credentials button under the Actions drop
down.
Note: This node is referred to as profile name node in the document and is user-configurable.
Navigation: AWS > profile name

Refer to the Add New Profile section of the AWS node topic for field descriptions.
Deletes the selected profile from the probe.
EC2 Node
The AWS EC2 service of a specific region stores the instance data in AWS CloudWatch. For a specific profile, the probe fetches the data from
AWS CloudWatch.
This node lets you configure the probe for interacting with the EC2 service and collect data about the instances of the AWS resource. The probe
generates QoS based on the instance data that is collected from AWS CloudWatch.
Navigation: AWS > profile name > EC2
EC2 > EC2 Configurations
This node lets you configure EC2 service properties.
Active: activates the addition of instances of the AWS resource.
Time Duration: specifies the time duration (in minutes) for collecting sample values from the AWS CloudWatch. The probe starts
collecting the values that were calculated during the time period which is specified here.
Statistics: defines one of the following operations to be performed on the sample values that the probe fetches:
Calculate minimum value.
Calculate maximum value.
Calculate the sum of all the values.
Calculate the average of all the values.
Default: Average
Note: When you change the Statistics value, the QoS graphs on the UMP portal are changed.
Period (minutes): specifies a time interval which is used to divide the collected values into groups.
For example, if the Time Duration is specified as 10 minutes and the Period is specified as 2 minutes, then the values are retrieved for 5
minutes time interval.

This node represents an instance of the AWS resource. An EC2 instance is a virtual machine (VM). If any region subscribes to the EC2 service,
then an instance of EC2 VM is created for that region.
The probe monitors the performance counters of the EC2 instances of the AWS resource. All EC2 instances are visible under the EC2 node.
Note: This node is referred to as instance name node in the document and each instance has a unique ID.
This node does not contain any fields or sections.

<Monitor Name> node
This node lets you configure the performance counters of the EC2 instances. The probe generates QoS data of the EC2 service of a specific
region according to the values fetched from the AWS CloudWatch.
The performance counters are divided into following categories:
CPU
Disk
Network
Each category is represented as a node under the instance name node.
Note: This node is referred to as EC2-monitor name node in the document and it represents various EC2 performance counters.
Navigation: AWS > profile name > EC2 > instance name > EC2-monitor name
monitor name > Monitors
This section lets you configure the performance counters for generating QoS.
Note: The performance counters of an EC2 instance are visible in a tabular form. You can select any one counter in the table and can
configure its properties.
Similarly, you can configure the other performance counters that are visible under the CPU, Disk, and Network nodes.
<EBS Volume> node
This node represents the Elastic Block Storage (EBS) which is linked to a specific EC2 instance. The EBS node is visible in the navigation panel
only if you have added a storage block with the EC2 instances, or when you have assigned a storage block to the instances.
Note: This node is referred to as EBS Volume node in the document and it represents an EBS storage volume.
Navigation: AWS > profile name > EC2 > instance name > EBS
EBS > Monitors
Note: The performance counters of an EBS volume are visible in a tabular form. You can select any one counter in the table and can
ElastiCache Node
The AWS ElastiCache service provides a scalable cache for storing temporary data. The probe generates QoS based on the instance data which
is collected from CloudWatch.
This node lets you configure the probe to fetch ElastiCache instance information.
Navigation: AWS > profile name > ElastiCache
ElastiCache > ElastiCache Configurations
This node lets you configure the ElastiCache service properties. For field descriptions, refer to the EC2 node section.
This node represents an AWS instance that uses the ElastiCache service. The ElastiCache service supports two types of cache engines:
Remote Dictionary Server or Redis (Currently, ElastiCache supports a single-node Redis cache cluster)
Memcached (Currently, ElastiCache supports a maximum of 20 nodes in a cache cluster)
The instances are displayed in the navigation pane according to the type of cache engine.
Note: This node is known as instance name node in the document and each instance has a unique ID.

<Node Name> node
This node lets you configure the performance counters of the ElastiCache instances. The probe generates QoS data of the ElastiCache service
according to the values fetched from CloudWatch.
Note: This node is referred to as node name node in the document and it represents a node of a Memcached or Redis ElastiCache
instance.
Navigation: AWS > profile name > Elasti Cache> instance name > node name
Note: The performance counters of an ElastiCache instance are visible in a tabular form. You can select any one counter in the
table and can configure its properties.
<ElastiCache-Monitor Name> node
This node lets you configure the performance counters of an ElastiCache instance node.
CPU
Memory
Each category is represented as a node under the node name node.
Note: This node is referred to as ElastiCache-monitor name node in the document and it represents various ElastiCache instance
performance counters.
Navigation: AWS > profile name > ElastiCache > instance name > node name > ElastiCache-monitor name
ElastiCache-monitor name > Monitors
Note: The performance counters of an ElastiCache instance node are visible in a tabular form. You can select any one counter
in the table and can configure its properties.
Similarly, you can configure the other performance counters that are visible under the Memory node.
SQS Node
The AWS SQS service lets you send data from an AWS service to any other AWS service. The probe monitors the properties of a queue based
on the data collected from the AWS CloudWatch in a specific region.
Navigation: AWS > profile name > SQS
SQS > SQS Configurations
This node lets you configure the SQS service properties.
Active: activates the monitoring of SQS queue.
This node represents the location of the SQS message queue. This node does not contain sections, and fields. You can configure the SQS QoS
metrics through the following available regions:
Asia Pacific (Singapore) Region
Asia Pacific (Sydney) Region
Asia Pacific (Tokyo) Region
EU (Frankfurt) Region
EU (Ireland) Region
South America (Sao Paulo) Region
US East (Northern Virginia) Region
US West (Northern California) Region
US West (Oregon) Region
<Queue Name> node
This node lets you configure the QoS metrics of SQS message queues. The probe generates QoS data of the SQS service according to the
values retrieved from AWS CloudWatch.

By default, the probe uses the following statistics on the collected values for each SQS metric:
Number of Messages Sent: Sum
Sent Message Size: Average
Number of Messages Received: Sum
Number of Empty Receives: Sum
Number of Messages Deleted: Sum
Approximate Number of Messages Delayed: Average
Approximate Number of Messages Visible: Average
Approximate Number of Messages Not Visible: Average
Notes:
You cannot change the value of the statistics.
This node is referred to as queue name node in the document and it represents various SQS metrics.
Navigation: AWS > profile name > SQS > SQS-region name > queue name
queue name > Monitors
This section lets you configure the SQS queue performance counters of a specific region for generating QoS data.
Note: The performance counters of a message queue are visible in a tabular form. You can select any one counter in the table and can
AutoScaling Node
This node lets you configure the probe for monitoring the QoS of the autoscaling groups. Auto-scaling groups are configured in the AWS
Management Console. Configure this node to view these groups, devices, and metrics in USM.
Note: You can create auto-scaling groups in USM by using the advanced filter attribute AWSAutoScalingGroup. For more information,
see Create and Manage Groups in USM.
Navigation: AWS > profile name > AutoScaling

AutoScaling > AutoScaling Configurations
This node lets you configure the AutoScaling service properties.
Active: activates the monitoring of the AutoScaling group.
Period (minutes): specifies a time interval, used to divide the collected values into groups.
Note: Auto Scale Service features are available on the USM.
Auto Scale-<Region Name> node
This node represents the location of the AutoScaling group. This node does not contain sections, and fields. Refer to the SQS-region name secti
on for the list of available regions.
<Auto Scale Group Name> node
This node lets you configure the metrics of the AutoScaling group. The AWS probe generates QoS data of the AutoScaling service according to
the values fetched from AWS CloudWatch.
By default, the probe uses a fixed operation the collected values for only the following AutoScaling metrics:
StatusCheckFailed: Average
StatusCheckFailed_Instance: Average
StatusCheckFailed_System: Average
Note: You can configure the statistics value for all the AutoScaling metrics, except for the above mentioned metrics.
This node is referred to as AutoScaling Group name node in the document and it represents various AutoScaling metrics.
Navigation: AWS > profile name > AutoScaling > AutoScaling-region name > AutoScaling Group name
AutoScaling name > Monitors
This section lets you configure the AutoScaling metrics of a specific region for generating QoS data.
Note: All AutoScaling monitors are visible in a tabular form. You can select any one monitor in the table and can configure its
properties.
Refer the queue name topic in SQS node topic for field descriptions.
This node represents the EC2 instances that are included in the AutoScaling group. For more details about the EC2 instances, refer to instance
name in the EC2 node section.
<Monitor Name> node
This node lets you configure the performance counters of the EC2 instances. For more details, refer to monitor name in the EC2 node section.
Note: If you configure the EC2 metrics for generating QoS data through monitor name node, then make sure that the EC2 service is
activated for your AWS account.
ELB Node
The probe monitors the ELB layer that distributes the incoming application data between multiple EC2 instances. In this node, you can view and
configure the metrics of those EC2 instances that are registered with ELB layer that you are currently monitoring. The probe generates QoS data
based on the inputs recived from the EC2 instances at group level.
Navigation: AWS > profile name > ELB
ELB > Elastic Load Balancing
This node lets you configure the ELB service properties.
Active: activates the monitoring of the ELB layer.
This node represents the location of the ELB layer. This node does not contain sections, and fields. Refer to the SQS-region name section for the
list of available regions.
This node lets you configure the metrics of the ELB layer. The probe generates QoS data of the ELB service according to the values fetched from
AWS CloudWatch.
By default, the probe uses the following statistics on the collected values for each ELB metric:
Healthy Host Count: Average
Unhealthy Host Count: Average
Request Count: Sum
Latency: Average
HTTPCode_ELB_4XX: Sum
HTTPCode_Backend_2XX: Sum
Backend Connection Errors: Sum
Surge Queue Length: Maximum
Spillover Count: Sum
Note: You cannot change the value of the statistics.
The following node is referred to as ELB Layer name node and it represents various ELB metrics.
Navigation: AWS > profile name > ELB > ELB-region name > ELB Layer name
ELB Layer name > Monitors
This section lets you configure the ELB metrics of a specific region for generating QoS data.
Note: All ELB monitors are visible in a tabular form. You can select any one monitor in the table and can configure its properties.

This node represents the EC2 instances that are registered with the ELB layer that the probe monitors. You can also view these EC2 instances in
the instance name node under the EC2 node. For more details about the EC2 instances, refer the instance name in the EC2 node section.
<Monitor Name> node
This node lets you configure the performance counters of the EC2 instances. For more details, refer the monitor name in the EC2 node section.
Note: If you configure the EC2 metrics for generating QoS data through monitor name node, then ensure that the EC2 service is
RDS Node
The AWS RDS service manages relational databases that are stored on AWS CloudWatch. The probe fetches the data from the CloudWatch and
generates QoS related to an RDS instance.
Navigation: AWS > profile name > RDS
RDS > RDS Configurations
This node lets you configure the RDS service properties.
Active: activates the addition of database instances of the AWS resource. For field descriptions, refer to the EC2 node section.
Note: This node is known as database name node in the document.
Navigation: AWS > profile name > RDS > database name
database name > Monitors
This section lets you configure the performance counters of a relational database instance for generating QoS data.
Note: The performance counters of an RDS database instance are visible in a tabular form. You can select any one counter in
the table and can configure its properties.
<RDS Monitor Name> node

This node lets you configure the performance counters of RDS instances. The probe generates QoS data of the RDS service according to the
values fetched from AWS CloudWatch.
CPU
Disk
Memory
Network
Each category is represented as a node under the database name node.
Note: This node is referred to as RDS monitor name node in the document and it represents various RDS performance counters.
Navigation: AWS > profile name > RDS > database name > RDS monitor name
RDS monitor name > Monitors
This section lets you configure the RDS performance counters of a specific instance for generating QoS data.
Note: The performance counters of a relational database are visible in a tabular form. You can select any one counter in the
Similarly, you can configure the other performance counters that are visible under the CPU, Disk, Memory, and Network nodes.
SNS Node
The probe monitors the SNS topic through which the publisher sends notifications to the subscriber. The probe also generates QoS data based
on the status of the notifications.
Navigation: AWS > profile name > SNS
SNS > SNS Configurations
This node lets you configure the SNS service properties.
Active: activates the monitoring of SNS topic.
Note: By default, for an active topic, the AWS CloudWatch receives metrics after every 5 minutes. Default monitoring, and
monitoring per minute is not available for AWS SNS.
This node represents the location of the SNS topic. This node does not contain sections, and fields. Refer to the SQS-region name section for
the list of available regions.
<Topic Name> node
This node lets you configure the performance counters of the publisher notifications. The probe generates QoS data of the SNS service according
to the values fetched from AWS CloudWatch.
By default, the probe uses the following statistics on the collected values for each SNS performance counter:
Number Of Messages Published: Sum
Publish Size: Average
Number Of Notifications Delivered: Sum
Number Of Notifications Failed: Sum
This node is referred to as queue name node in the document and it represents various SNS metrics.
Navigation: AWS > profile name > SNS > SNS-region name > topic name
topic name > Monitors
This section lets you configure the SNS topic performance counters of a specific region for generating QoS data.
Note: The performance counters of an SNS topic are visible in a tabular form. You can select any one counter in the table and
can configure its properties.
Refer the queue name section for field descriptions.

Custom Metrics
In AWS, metrics are segregated into different Namespaces. A Dimension is a variable that categorizes a metric according to its statistics. When
you create custom metrics through the script and store the metrics in AWS CloudWatch, the probe fetches that data from CloudWatch.
This node lets you select a custom metric that is available in an AWS Namespace and then define custom QoS for it. The custom metrics for
different AWS Namespace are visible in the Navigation Pane.
You can configure any of the discovered metrics that are available in an AWS Namespace through the Custom Metrics node except RDS, EC2,
EBS, ElastiCache, SQS, SNS, ELB, and AutoScaling.
Navigation: AWS > profile name > Custom Metric
Custom Metric > Custom Configurations
This section lets you configure the probe to fetch the list of custom metrics from the AWS CloudWatch and select custom metrics for a
specific Namespace.
Available Service Metrics: specifies the list of available AWS Namespaces that the probe fetches from CloudWatch. Each Namespace
contains various custom metrics. You can move specific service Namespace from the Available List to the Selected List. The
selected service metrics are visible as nodes in the Navigation Pane.
Note:
You must include Namespace and Dimensions in a custom metric script for the probe to collect the metrics.
For other field descriptions, refer to the EC2 node section.
This node lets you view and configure the custom metrics for all AWS services. You can define a custom QoS name, unit, and can let the probe
generate QoS data for the custom metric. This node contains a table that lists the AWS dimensions against each service metric.
Note: This node is referred to as AWS-service name node in the document and is user-configurable.
Navigation: AWS > profile name > Custom Metric > AWS-service name
AWS-service name > Collected Metrics
This section lets you define custom QoS name for different service metrics that are listed in a tabular form. You can also configure the
probe to generate QoS data for selected metrics.
Note: If you have created the custom metrics in a custom Namespace then only custom metrics are visible in the table.
However, if you have created the custom metrics in an existing Namespace then all the metrics are visible in the table.
S3 Node
The data which is stored in the cloud using the AWS S3 service is segregated into groups that are known as buckets. The probe monitors the time
which is consumed in storing and retrieving files to and from the bucket, respectively.
This node lets you configure the performance counters for S3 service. The AWS probe generates QoS data related to the time that is consumed
in storing and retrieving files to and from the S3 buckets.
Note:
Set the polling interval (Interval field in the Add New Profile section in aws node) according to the size of the file that you
want to store or retrieve. If the polling interval is too less, then the probe starts fetching data again from the bucket before
completing a previous file process. For example, if you want to upload a file of size 1 MB then you can set the polling interval
as 5 minutes.
S3 services are not supported on Factory Template.
Navigation: AWS > profile name > S3

S3 > S3 Configurations
This section lets you provide details about the file bucket so that the probe can monitor the time that is consumed in accessing the file
bucket.
Active: enables the monitoring of file bucket access time.
Bucket Name: specifies the name of the file bucket for which the probe monitors the storing and retrieving time.
File Name: defines the name of the file which is stored or retrieved from the bucket.
Note: The file, for which you want to generate the QoS data, must be present in the AWS probe base folder (/probes/appli
cations/aws).
S3 > Monitors
Note: The performance counters of the S3 service are visible in a tabular form. You can select any one counter in the table and can
Template Editor
The Template Editor interface is used to create, modify, or delete templates that can be applied to the probe. The editor allows you to define
templates that can be applicable across multiple profiles.
The node structure of the template editor resembles the node structure of the probe with the following differences:
<templateName> Node
The <templateName> node is used to activate or deactivate a template.

Auto Filter or <filterName> Node
The Auto Filter or the <filterName> node allows you to control which profiles or devices are associated with a particular template. You can
specify additional device criteria by using rules. Filters usually contain one or more rules to define the types of devices for the template. You can
add rules to a device filter to create divisions within a group of systems or reduce the set of devices that are monitored by the probe. For
example, you can add a rule to apply a monitoring configuration to all devices with the IPV4 address that contains 1.1.1.1.
Rules
You can specify rules to match specific criteria while applying a template on the probe. The fields in a rule are:
Label: indicates that the filter will be applicable to the name of the node or section.
Condition: selects the condition to match the value with the probe. The conditions are described as follows:
Contains: indicates that the label contains the specified value.
DoesnotContain: indicates that the label does not contain the specified value.
EndsWith: indicates that the label ends with the specified value.
Equals: indicates that the label is exactly the same as the specified value. This is the default selection.
NotEquals: indicates that the label is not the specified value.
Regex: indicates that the label will match the specified regular expression.
Refer Using Regular Expressions.
Starts With: indicates that the label ends with the specified value.
Value: specifies the value that is to be matched with the probe according to the specified condition.
Include in Template
The Include in Template checkbox is used to include and enable configuration of a monitor or section in the template. This checkbox is available
for static nodes and within filters for dynamic nodes.
v4.0 aws Service Health

This node represents the health monitoring service of aws probe. The probe monitors AWS service availability for a specific region. The probe
generates alarms in case any service for a specific region is unavailable. The following alarms are generated after the probe monitors the health
of the AWS services:
Disruption in the service.
Performance issues.
Service is operating normally.
Other information.
Navigation: AWS > AWS Service Health
Set or modify the following values as needed.
AWS Service Health > Health Configuration

This section enables you to configure the Health Monitoring functionality of the probe. The Health Interval (mins) field lets you set the time
interval, in minutes, during which the probe fetches the health status of the AWS services.
<AWS Region> Node
This node lets you view the list of AWS services that are available for a specific region. You can configure the AWS probe for generating alarms
for specific AWS services in a region.
Note: This node is known as AWS region in the document as this node represents all the geographical locations where AWS provides
services.
Navigation: AWS > AWS Service Health > AWS region

Set or modify the following values as needed:
AWS Region > AWS Service Status
This section lets you view the various AWS services that are available for a specific region. You can configure the service properties for
generating the alarms in case the service is not available.
Note: The AWS services for the selected region are visible in a tabular form. You can select any one service in the table and can
Description: indicates the description of the selected service.

Unit: indicates the unit of the selected service status.
Metric Type ID: identifies a unique ID for alarm generation.
Publish Alarms: enables the probe to check the status of the selected service and generate alarms.
Note: When you select the Publish Alarms check box, the value of the Alarm column in the table changes from Off to On.
Service: indicates the name of the selected service.

Similarly, you can configure the services of the other geographical locations.
v3.5 aws AC Configuration
The AWS Monitoring probe is configured to create monitoring profiles for accessing AWS resources and fetching data from AWS CloudWatch.
You can also configure health monitors to generate alarms on the basis of the availability of services in various geographical regions.
The probe also lets you configure the Auto Discovery functionality. If any service instance is added or deleted in the AWS resource, then the Aut
o Discovery functionality updates the list of instances in the probe.
The probe fetches data of instances, or services and provides you with various monitors for generating QoS. You can also configure the probe to
fetch the list of custom metrics that are created for a specific service in the AWS CloudWatch.
Contents
How to Configure Alarm Thresholds
Managing Profiles
Create a Profile
Delete a profile
This section contains the preconfiguration requirements for the CA UIM AWS Monitoring probe.
An AWS user-account with valid user-credentials, such as, Access Key and Secret Access Key.
EC2 Administrative Rights so that the AWS Monitoring probe can access the AWS resource.

This section provides information about the upgrade and migration scenarios for the AWS Monitoring probe.
When you install the probe version 2.01 then manually move the existing configurations, in case you are using the probe of version
earlier than version 2.01.
Delete all the versions of the AWS Monitoring probe that are earlier than version 2.01 as upgrade from a previous version to version 2.01
is not supported.
The probe from version 2.01 and later is accessible only through the Admin Console GUI.
For viewing the new metrics that are introduced in the AWS probe version 3.0, on the USM portal, you can perform any one of the
following actions:
Upgrade NMS 7.6 (or earlier) to CA UIM 8.0
Install the ci_defn_pack version 1.01 probe. you are required to restart the nis_server when you deploy the ci_defn_pack.

maintained by the NAS probe. If you are working with NMS 7.6 or earlier, you will have to add the following subsystem IDs manually using the
NAS Raw Configuration menu. However, if you have upgraded to CA UIM 8.0 then you do not have to manually add the following subsystem IDs:
Key Name
Value
2.19.
Amazon
2.19.1.
AWS
2.19.1.1.
Resource
2.19.1.2.
ServiceStatus
2.19.1.3.
EC2
2.19.1.4.
S3
2.19.1.5.
EBS
2.19.1.6.
RDS
2.19.1.9
ElastiCache
2.19.1.8
SNS
2.19.1.7
SQS
2.19.1.11
ELB
2.19.1.12
Auto Scaling
7. Click Apply.
4. Enter the Key Name and Value, Click OK.
6. Click Apply.

Some Quality of Service measurement probes allow you to set different types of alarm thresholds. These threshold options allow you to more
broadly control when alarm messages are sent for each QoS probe.
For more information about the different alarm thresholds and their configuration requirements, refer to the General Probe Configuration section of
the Admin Console Help.
Managing Profiles
This procedure provides the information to configure a particular section of a profile. Each section within the profile configures the monitoring
properties of the probe.
Follow these steps:
1. Navigate to the section within a profile that you want to configure.
The specified section of the probe is configured. The probe is now ready to monitor the log files, web pages, messages from queues, and
output from commands.
Create a Profile
The following procedure enables you to add a profile for monitoring the AWS services. Each profile represents one AWS resource. There can be
multiple instances of an AWS resource.
Follow these steps:
1. Click Options next to the AWS node in the navigation pane.
The new monitoring profile is visible under the AWS node in the navigation pane.
The Auto Discovery functionality automatically loads a list of all the available instances.
Delete a profile
You can delete a profile if you do not want the probe to monitor the performance of a specific AWS resource.
Follow these steps:
2. Select Delete Profile.
3. Click Save.
v3.5 AWS AC GUI Reference
This article describes the fields and features of the AWS Monitoring probe.
Contents
aws Node
<profile name> Node
EC2 Node
<Monitor Name> node
<EBS Volume> node
ElastiCache Node
<Node Name> node
SQS Node
<Queue Name> node
Autoscaling Node
Auto Scaling-<Region Name> node
<Auto Scaling Group Name> node
<Monitor Name> node
ELB Node
<Monitor Name> node
RDS Node
SNS Node
<Topic Name> node
Custom Metrics
S3 Node
aws Node
This node lets you view the probe information and configure the logging properties. You can also set the polling interval for Auto Discovery functi
onality and configure the proxy settings.
Note: The AWS services nodes are visible in the Navigation Pane only after you create a monitoring profile. Initially, only the AWS nod
e and the AWS Service Health node are visible.
Navigation: aws
aws > Probe Information
aws > Probe Setup
aws > Auto Discovery
This section lets you set the value of Discovery Interval (minutes). If any instance is added or deleted in the AWS resource, then the A
uto Discovery functionality updates the list of instances in the probe. The Discovery Interval (minutes) specifies the time interval
between each time the probe runs the Auto Discovery functionality.
aws > Proxy Settings
This section enables you to connect to the AWS cloud through a proxy server on the network. You need proxy server settings when your
network is not an open network.
Enable Proxy: lets you use a proxy server for connecting to the AWS cloud.
Note: The AWS probe is certified for use in Squid proxy environment.
aws > Add New Profile

This section lets you add a profile for monitoring the AWS services data. QoS data is generated according to the performance of these
services.
Profile Name: defines a unique name for the monitoring profile. This field was identified as Name in the previous versions of the
probe. You can specify the AWS account name as the value for this field.
Interval (seconds): specifies the time interval (in seconds) after which the probe collects the data from the AWS cloud for the specific
profile.
Default: 600
Note: Interval value must be above 300 seconds.
Alarm Message: specifies the alarm to be generated when the connection to AWS services fails.
Access Key: defines the login credential of the AWS user-account for accessing the AWS resource.
Secret Access Key: specifies the additional login credential of the AWS user-account.
Note: The probe uses the combination of the Access Key and Secret Access Key for accessing the AWS resource.
<profile name> Node
This node represents the profile which is created to monitor the health and performance of AWS services. Each profile is mapped with an AWS
account. You can check the connection between the probe and the AWS resource through the Verify Credentials button under the Actions drop
down.
Note: This node is referred to as profile name node in the document and is user-configurable.
Navigation: AWS > profile name

Refer to the Add New Profile section of the AWS node topic for field descriptions.
EC2 Node
The AWS EC2 service of a specific region stores the instance data in AWS CloudWatch. For a specific profile, the AWS Monitoring probe fetches
the data from AWS CloudWatch.
This node lets you configure the probe for interacting with the EC2 service and collect data about the instances of the AWS resource. The probe
generates QoS based on the instance data which is collected from AWS CloudWatch.
Navigation: AWS > profile name > EC2
EC2 > EC2 Configurations
This node lets you configure EC2 service properties.
Active: activates the addition of instances of the AWS resource.
Statistics: defines one of the following operations to be performed on the sample values that the probe fetches:
Calculate minimum value.
Calculate maximum value.
Calculate the sum of all the values.
Calculate the average of all the values.

Default: Average
Note: When you change the Statistics value, the QoS graphs on the UMP portal are changed.
For example, if the Time Duration is specified as 10 minutes and the Period is specified as 2 minutes, then the values are fetched for 5
minutes time interval.
This node represents an instance of the AWS resource. An EC2 instance is a virtual machine (VM). If any region subscribes to the EC2 service,
then an instance of EC2 VM is created for that region.
The AWS Monitoring probe monitors the performance counters of the EC2 instances of the AWS resource. All EC2 instances are visible under the
EC2 node.
Note: This node is referred to as instance name node in the document and each instance has a unique ID.

<Monitor Name> node
This node lets you configure the performance counters of the EC2 instances. The AWS Monitoring probe generates QoS data of the EC2 service
of a specific region according to the values fetched from the AWS CloudWatch.
CPU
Disk
Network
Each category is represented as a node under the instance name node.
Note: This node is referred to as EC2-monitor name node in the document and it represents various EC2 performance counters.
Navigation: AWS > profile name > EC2 > instance name > EC2-monitor name
Note: The performance counters of an EC2 instance are visible in a tabular form. You can select any one counter in the table
and can configure its properties.
Similarly, you can configure the other performance counters that are visible under the CPU, Disk, and Network nodes.
<EBS Volume> node
This node represents the Elastic Block Storage (EBS) which is linked to a specific EC2 instance. The EBS node is visible in the navigation panel
only if you have added a storage block with the EC2 instances, or when you have assigned a storage block to the instances.
Note: This node is referred to as EBS Volume node in the document and it represents an EBS storage volume.
Navigation: AWS > profile name > EC2 > instance name > EBS

EBS > Monitors
Note: The performance counters of an EBS volume are visible in a tabular form. You can select any one counter in the table and can
ElastiCache Node
The AWS ElastiCache service provides a scalable cache for storing temporary data. The AWS Monitoring probe generates QoS based on the
instance data which is collected from CloudWatch.
This node lets you configure the probe to fetch ElastiCache instance information.
Navigation: AWS > profile name > ElastiCache
ElastiCache > ElastiCache Configurations
This node lets you configure the ElastiCache service properties. For field descriptions, refer to the EC2 node section.
This node represents an AWS instance that uses the ElastiCache service. The ElastiCache service supports two types of cache engines:
Remote Dictionary Server or Redis (Currently, ElastiCache supports a single-node Redis cache cluster)
Memcached (Currently, ElastiCache supports a maximum of 20 nodes in a cache cluster)
The instances are displayed in the navigation pane according to the type of cache engine.
Note: This node is known as instance name node in the document and each instance has a unique ID.

<Node Name> node
This node lets you configure the performance counters of the ElastiCache instances. The AWS probe generates QoS data of the ElastiCache
service according to the values fetched from CloudWatch.
Note: This node is referred to as node name node in the document and it represents a node of a Memcached or Redis ElastiCache
instance.
Navigation: AWS > profile name > Elasti Cache> instance name > node name
Note: The performance counters of an ElastiCache instance are visible in a tabular form. You can select any one counter in the
This node lets you configure the performance counters of an ElastiCache instance node.
CPU
Memory
Each category is represented as a node under the node name node.
Note: This node is referred to as ElastiCache-monitor name node in the document and it represents various ElastiCache instance
performance counters.
Navigation: AWS > profile name > ElastiCache > instance name > node name > ElastiCache-monitor name
ElastiCache-monitor name > Monitors
Note: The performance counters of an ElastiCache instance node are visible in a tabular form. You can select any one counter
in the table and can configure its properties.
Similarly, you can configure the other performance counters that are visible under the Memory node.
SQS Node
The AWS SQS service lets you send data from an AWS service to any other AWS service. The AWS Monitoring probe monitors the properties of
a queue based on the data collected from the AWS CloudWatch in a specific region.
Navigation: AWS > profile name > SQS
SQS > SQS Configurations
This node lets you configure the SQS service properties.
Active: activates the monitoring of SQS queue.
This node represents the location of the SQS message queue. This node does not contain sections, and fields. You can configure the SQS QoS
metrics through the following available regions:
Asia Pacific (Singapore) Region
Asia Pacific (Sydney) Region
Asia Pacific (Tokyo) Region
EU (Ireland) Region
South America (Sao Paulo) Region
US East (Northern Virginia) Region
US West (Northern California) Region
US West (Oregon) Region
<Queue Name> node
This node lets you configure the QoS metrics of SQS message queues. The AWS probe generates QoS data of the SQS service according to the
values fetched from AWS CloudWatch.
By default, the AWS Monitoring probe uses the following statistics on the collected values for each SQS metric:
Number of Messages Sent: Sum
Sent Message Size: Average

Number of Messages Received: Sum
Number of Empty Receives: Sum
Number of Messages Deleted: Sum
Approximate Number of Messages Delayed: Average
Approximate Number of Messages Visible: Average
Approximate Number of Messages Not Visible: Average
Notes:
This node is referred to as queue name node in the document and it represents various SQS metrics.
Navigation: AWS > profile name > SQS > SQS-region name > queue name
queue name > Monitors
This section lets you configure the SQS queue performance counters of a specific region for generating QoS data.
Note: The performance counters of a message queue are visible in a tabular form. You can select any one counter in the table and can
Autoscaling Node
This node lets you configure the probe for monitoring the status of the auto scaling groups.
Navigation: AWS > profile name > Auto Scaling
Auto Scaling > Auto Scaling Configurations
This node lets you configure the Auto Scaling service properties.
Active: activates the monitoring of the auto scaling group.
Auto Scaling-<Region Name> node
This node represents the location of the auto scaling group. This node does not contain sections, and fields. Refer to the SQS-region name secti
on for the list of available regions.
<Auto Scaling Group Name> node
This node lets you configure the metrics of the auto scaling group. The AWS probe generates QoS data of the auto scaling service according to
By default, the AWS Monitoring probe uses a fixed operation the collected values for only the following auto scaling metrics:
StatusCheckFailed: Average
StatusCheckFailed_Instance: Average
StatusCheckFailed_System: Average
Note: You can configure the statistics value for all the auto scaling metrics, except for the above mentioned metrics.
This node is referred to as Auto Scaling Group name node in the document and it represents various Auto Scaling metrics.
Navigation: AWS > profile name > Auto Scaling > Auto Scaling-region name > Auto Scaling Group name
Auto Scaling name > Monitors
This section lets you configure the Auto Scaling metrics of a specific region for generating QoS data.
Note: All Auto Scaling monitors are visible in a tabular form. You can select any one monitor in the table and can configure its
properties.
Refer the queue name topic in SQS node topic for field descriptions.
This node represents the EC2 instances that are included in the Auto Scaling group. For more details about the EC2 instances, refer to instance
name in the EC2 node section.
<Monitor Name> node
This node lets you configure the performance counters of the EC2 instances. For more details, refer to monitor name in the EC2 node section.
ELB Node
The AWS Monitoring probe monitors the ELB layer that distributes the incoming application data between multiple EC2 instances. In this node,
you can view and configure the metrics of those EC2 instances that are registered with ELB layer that you are currently monitoring. The probe
generates QoS data based on the inputs recived from the EC2 instances at group level.
Navigation: AWS > profile name > ELB
ELB > Elastic Load Balancing
This node lets you configure the ELB service properties.
Active: activates the monitoring of the ELB layer.
This node represents the location of the ELB layer. This node does not contain sections, and fields. Refer to the SQS-region name section for the
list of available regions.
This node lets you configure the metrics of the ELB layer. The AWS probe generates QoS data of the ELB service according to the values fetched
from AWS CloudWatch.
By default, the AWS Monitoring probe uses the following statistics on the collected values for each ELB metric:
Healthy Host Count: Average
Unhealthy Host Count: Average
Request Count: Sum
Latency: Average
Backend Connection Errors: Sum
Surge Queue Length: Maximum
Spillover Count: Sum
Note: You cannot change the value of the statistics.
The following node is referred to as ELB Layer name node and it represents various ELB metrics.
Navigation: AWS > profile name > ELB > ELB-region name > ELB Layer name
ELB Layer name > Monitors
This section lets you configure the ELB metrics of a specific region for generating QoS data.
Note: All ELB monitors are visible in a tabular form. You can select any one monitor in the table and can configure its properties.
Refer the queue name article for field descriptions.

This node represents the EC2 instances that are registered with the ELB layer that the probe monitors. You can also view these EC2 instances in
the instance name node under the EC2 node. For more details about the EC2 instances, refer to instance name in the EC2 node section.
<Monitor Name> node
This node lets you configure the performance counters of the EC2 instances. For more details, refer to the monitor name in the EC2 node section
.
RDS Node
The AWS RDS service manages relational databases that are stored on AWS CloudWatch. The AWS Monitoring probe fetches the data from the
CloudWatch and generates QoS related to an RDS instance.
Navigation: AWS > profile name > RDS
RDS > RDS Configurations
This node lets you configure the RDS service properties.
Active: activates the addition of database instances of the AWS resource. For field descriptions, refer to the EC2 node section.
Note: This node is known as database name node in the document.
Navigation: AWS > profile name > RDS > database name
database name > Monitors
This section lets you configure the performance counters of a relational database instance for generating QoS data.
Note: The performance counters of an RDS database instance are visible in a tabular form. You can select any one counter in
the table and can configure its properties.
This node lets you configure the performance counters of RDS instances. The AWS probe generates QoS data of the RDS service according to
CPU
Disk
Memory
Network
Each category is represented as a node under the database name node.
Note: This node is referred to as RDS monitor name node in the document and it represents various RDS performance counters.
Navigation: AWS > profile name > RDS > database name > RDS monitor name
RDS monitor name > Monitors
This section lets you configure the RDS performance counters of a specific instance for generating QoS data.
Note: The performance counters of a relational database are visible in a tabular form. You can select any one counter in the
Similarly, you can configure the other performance counters that are visible under the CPU, Disk, Memory, and Network nodes.
SNS Node
The AWS Monitoring probe monitors the SNS topic through which the publisher sends notifications to the subscriber. The probe also generates
QoS data based on the status of the notifications.
Navigation: AWS > profile name > SNS
SNS > SNS Configurations
This node lets you configure the SNS service properties.
Active: activates the monitoring of SNS topic.
Note: By default, for an active topic, the AWS CloudWatch receives metrics after every 5 minutes. Default monitoring, and
monitoring per minute is not available for AWS SNS.
This node represents the location of the SNS topic. This node does not contain sections, and fields. Refer to the SQS-region name section for
the list of available regions.
<Topic Name> node
This node lets you configure the performance counters of the publisher notifications. The AWS probe generates QoS data of the SNS service
according to the values fetched from AWS CloudWatch.
By default, the AWS Monitoring probe uses the following statistics on the collected values for each SNS performance counter:
Number Of Messages Published: Sum
Publish Size: Average
Number Of Notifications Delivered: Sum
Number Of Notifications Failed: Sum
This node is referred to as queue name node in the document and it represents various SNS metrics.
Navigation: AWS > profile name > SNS > SNS-region name > topic name
topic name > Monitors
This section lets you configure the SNS topic performance counters of a specific region for generating QoS data.
Note: The performance counters of an SNS topic are visible in a tabular form. You can select any one counter in the table and
can configure its properties.
Refer the queue name section for field descriptions.

Custom Metrics
In AWS, metrics are segregated into different Namespaces. A Dimension is a variable that categorizes a metric according to its statistics. When
you create custom metrics through the script and store the metrics in AWS CloudWatch, the AWS probe fetches that data from CloudWatch.
This node lets you select a custom metric that is available in an AWS Namespace and then define custom QoS for it. The custom metrics for
different AWS Namespace are visible in the Navigation Pane.
You can configure any of the discovered metrics that are available in an AWS Namespace through the Custom Metrics node except RDS, EC2,
EBS, ElastiCache, SQS, SNS, ELB, and Auto Scaling.
Navigation: AWS > profile name > Custom Metric
Custom Metric > Custom Configurations
This section lets you configure the probe to fetch the list of custom metrics from the AWS CloudWatch and select custom metrics for a
specific Namespace.
Available Service Metrics: specifies the list of available AWS Namespaces that the probe fetches from CloudWatch. Each Namespace
contains various custom metrics. You can move specific service Namespace from the Available List to the Selected List. The
selected service metrics are visible as nodes in the Navigation Pane.
Note: For other field descriptions, refer to the EC2 node section.
This node lets you view and configure the custom metrics for all AWS services. You can define a custom QoS name, unit, and can let the probe
generate QoS data for the custom metric. This node contains a table that lists the AWS dimensions against each service metric.
Note: This node is referred to as AWS-service name node in the document and is user-configurable.
Navigation: AWS > profile name > Custom Metric > AWS-service name
AWS-service name > Collected Metrics

This section lets you define custom QoS name for different service metrics that are listed in a tabular form. You can also configure the
probe to generate QoS data for selected metrics.
Note: If you have created the custom metrics in a custom Namespace then only custom metrics are visible in the table.
However, if you have created the custom metrics in an existing Namespace then all the metrics are visible in the table.
S3 Node
The data which is stored in the cloud using the AWS S3 service is segregated into groups that are known as buckets. The AWS probe monitors
the time which is consumed in storing and retrieving files to and from the bucket, respectively.
This node lets you configure the performance counters for S3 service. The AWS probe generates QoS data related to the time that is consumed
in storing and retrieving files to and from the S3 buckets.
Note: Set the polling interval (Interval field in the Add New Profile section in aws node) according to the size of the file that you want
to store or retrieve. If the polling interval is too less, then the probe starts fetching data again from the bucket before completing a
previous file process. For example, if you want to upload a file of size 1 MB then you can set the polling interval as 5 minutes.
Navigation: AWS > profile name > S3

S3 > S3 Configurations
This section lets you provide details about the file bucket so that the probe can monitor the time that is consumed in accessing the file
bucket.
Active: enables the monitoring of file bucket access time.
Bucket Name: specifies the name of the file bucket for which the probe monitors the storing and retrieving time.
File Name: defines the name of the file which is stored or retrieved from the bucket.
Note: The file, for which you want to generate the QoS data, must be present in the AWS probe base folder (/probes/appli
cations/aws).
S3 > Monitors
Note: The performance counters of the S3 service are visible in a tabular form. You can select any one counter in the table and can
v3.5 AWS Service Health

This node represents the health monitoring service of AWS probe. The probe monitors AWS service availability for a specific region. The probe
generates alarms in case any service for a specific region is unavailable. The following alarms are generated after the probe monitors the health
of the AWS services:
Disruption in the service.
Performance issues.
Service is operating normally.
Other information.
Navigation: AWS > AWS Service Health
AWS Service Health > Health Configuration
This section enables you to configure the Health Monitoring functionality of the AWS probe. The Health Interval (mins) field lets you set
the time interval, in minutes, during which the probe fetches the health status of the AWS services.
<AWS Region> Node
This node lets you view the list of AWS services that are available for a specific region. You can configure the AWS probe for generating alarms
for specific AWS services in a region.
Note: This node is known as AWS region in the document as this node represents all the geographical locations where AWS provides
services.
Navigation: AWS > AWS Service Health > AWS region

AWS Region > AWS Service Status
This section lets you view the various AWS services that are available for a specific region. You can configure the service properties for
generating the alarms in case the service is not available.
Note: The AWS services for the selected region are visible in a tabular form. You can select any one service in the table and can
Description: indicates the description of the selected service.

Unit: indicates the unit of the selected service status.
Metric Type ID: identifies a unique ID for alarm generation.
Publish Alarms: enables the probe to check the status of the selected service and generate alarms.
Note: When you select the Publish Alarms check box, the value of the Alarm column in the table changes from Off to On.
Service: indicates the name of the selected service.

aws Metrics
The section describes the metrics that can be configured using the Amazon Web Services Monitoring (aws) probe.
Contents
QoS data for the AWS S3 service

QoS data for the AWS EC2 service
QoS data for the AWS EBS service
QoS data for the AWS RDS service
QoS data is for the AWS ElastiCache service
Host Level Metrics
Memcached Metrics
Redis Metrics
QoS data for the AWS SQS service
QoS data for the AWS SNS service
QoS data for the AWS ELB service
QoS data for the AWS Auto Scaling service
QoS data for the AWS S3 service

QoS Name
Metric Name
Units
Description
Version
QOS_AWS_FILEREADTIME
File Read Time
Seconds
Time taken to fetch a file from the file bucket.
2.0
QOS_AWS_FILEWRITETIME
File Write Time
Seconds
Time taken to store a file in the file bucket.
2.0
QoS data for the AWS EC2 service

QoS Name
Metric
Name
Units
Description
Version
QOS_AWS_CPU_UTILIZATION
CPU
Usage
Percent
The percentage of allocated EC2 compute units that are currently in use on the instance.
This metric identifies the processing power required to run an application upon a
selected instance.
2.0
QOS_AWS_DISK_WRITE_BYTES
Data
Written
Bytes
This metric is used to determine the volume of the data the application writes onto the
hard disk of the instance. This can be used to determine the speed of the application.
2.0
QOS_AWS_DISK_READ_BYTES
Data
Read
Bytes
This metric is used to determine the volume of the data the application reads from the
hard disk of the instance. This can be used to determine the speed of the application.
2.0
QOS_AWS_DISK_READ_OPS
Reads
Count
Completed read operations from all ephemeral disks available to the instance. This
metric identifies the rate at which an application reads a disk. This can be used to
determine the speed in which an application reads data from a hard disk.
2.0
QOS_AWS_DISK_WRITE_OPS
Writes
Count
Completed write operations to all ephemeral disks available to the instance. This metric
identifies the rate at which an application writes to a hard disk. This can be used to
determine the speed in which an application saves data to a hard disk.
2.0
QOS_AWS_NETWORK_IN
Total
Bytes
Received
Bytes
The number of bytes received on all network interfaces by the instance. This metric
identifies the volume of incoming network traffic to an application on a single instance.
2.0
QOS_AWS_NETWORK_OUT
Total
Bytes
Sent
Bytes
The number of bytes sent out on all network interfaces by the instance. This metric
identifies the volume of outgoing network traffic to an application on a single instance.
2.0
QoS data for the AWS EBS service

QoS Name
Metric
Name
Units
Description
Version
QOS_AWS_VOLUME_READ_BYTES
Total Read
Bytes
The number of bytes read in the time period specified in

the Start Time field.
3.0
QOS_AWS_VOLUME_WRITE_BYTES
Total
Written
Bytes
The number of bytes written in the time period specified in

the Start Time field..
3.0
QOS_AWS_VOLUME_READ_OPS
Total Read
Operations
Count
The number of Read operations in the time period

specified in the Start Time field.
3.0
QOS_AWS_VOLUME_WRITE_OPS
Total Write
Operations
Count
The number of Write operations in the time period

specified in the Start Time field.
3.0
QOS_AWS_VOLUME_TOTAL_READ_TIME
Total Read
Time
Seconds
The number of seconds spent by all read operations that

completed in a specified period of time. If multiple requests
are submitted at the same time, this total could be greater
than the length of the period.
3.0
QOS_AWS_VOLUME_TOTAL_WRITE_TIME
Total Write
Time
Seconds
The number of seconds spent by all write operations that

completed in a specified period of time. If multiple requests
are submitted at the same time, this total could be greater
than the length of the period.
3.0
QOS_AWS_VOLUME_IDLE_TIME
Total Idle
Time
Seconds
The number of seconds in the time period specified in the

Start Time field when no read or write operations were
submitted.
3.0
QOS_AWS_VOLUME_QUEUE_LENGTH
Queue
Length
Count
The number of read and write operation requests waiting to

be completed in the time period specified in the Start Time
field.
3.0
QOS_AWS_VOLUME_THROUGHPUT_PERCENTAGE
Throughput Percentage
Percentage
The percentage of I/O operations per second (IOPS)

delivered of the total IOPS provisioned for an Amazon EBS
volume. Used with Provisioned IOPS (SSD) volumes only.
3.0
QOS_AWS_VOLUME_CONSUMED_READ_WRITE_OPS
Consumed
Read Write
Operations
Count
The total amount of read and write operations (normalized

to 16K capacity units) consumed in the time period
specified in the Start Time field. Used with Provisioned
IOPS (SSD) volumes only.
3.0
QoS data for the AWS RDS service

QoS Name
Metric
Name
Units
Description
Version
QOS_AWS_RDS_BIN_LOG_DISK_USAGE
Binary Log
Size On
Disk
Bytes
The amount of disk space occupied by binary logs on

the master. Applies to MySQL read replicas only.
3.0
QOS_AWS_RDS_CPU_UTILIZATION
CPU
Utilization
Percent
The percentage of CPU utilization by the relational

database.
3.0
QOS_AWS_RDS_DATABASE_CONNECTIONS
Database
Connections
Count
The number of database connections in use.
3.0
QOS_AWS_RDS_DISK_QUEUE_DEPTH
Outstanding
IOs in
queue
Count
The number of outstanding IOs (read/write requests)

waiting to access the disk.
3.0
QOS_AWS_RDS_FREEABLE_MEMORY
Available
Memory
Bytes
The amount of available Random Access Memory.
3.0
QOS_AWS_RDS_FREE_STORAGE_SPACE
Available
Storage
Space
Bytes
The amount of available storage space.
3.0
QOS_AWS_RDS_REPLICA_LAG
Read
Replica Lag
Time
Seconds
The time for which a Read Replica DB instance lags

behind the Source DB instance. Replica lag occurs
due to slow execution of data manipulation queries
and is seen in MySQL database only.
3.0
QOS_AWS_RDS_SWAP_USAGE
Used Swap
Space
Bytes
The amount of swap space used on the DB Instance.
3.0
QOS_AWS_RDS_READ_IOPS
Read
Operations
Per Second
Count/Second
The average number of disk I/O operations per

second.
3.0
QOS_AWS_RDS_WRITE_IOPS
Write
Operations
Per Second
Count/Second
The average number of disk I/O operations per

second.
3.0
QOS_AWS_RDS_READ_LATENCY
Read
Latency
Seconds
The average amount of time taken per disk I/O

operation.
3.0
QOS_AWS_RDS_WRITE_LATENCY
Write
Latency
Seconds
The average amount of time taken per disk I/O

operation.
3.0
QOS_AWS_RDS_READ_THROUGHPUT
Read
Throughput
Bytes/Second
The average number of bytes read from disk per

second.
3.0
QOS_AWS_RDS_WRITE_THROUGHPUT
Write
Throughput
Bytes/Second
The average number of bytes written to disk per

second.
3.0
QOS_AWS_RDS_NETWORK_RECEIVE_THROUGHPUT
Network
Receive
Throughput
Bytes
The incoming (Receive) network traffic on the DB

instance, including both customer database traffic
and Amazon RDS traffic used for monitoring and
replication.
3.0
QOS_AWS_RDS_NETOWRK_TRANSMIT_THROUGHPUT
Network
Transmit
Throughput
Bytes
The outgoing (Transmit) network traffic on the DB

instance, including both customer database traffic
and Amazon RDS traffic used for monitoring and
replication.
3.0
QoS data is for the AWS ElastiCache service

Host Level Metrics
QoS Name
Metric Name
Units
Description
Version
QOS_AWS_ELASTICACHE_CPU_UTILIZATION
CPU Utilization
Percent
The percentage of CPU utilization.
3.0
QOS_AWS_ELASTICACHE_FREEABLE_MEMORY
Available Free Memory
Bytes
The amount of free memory available on the host.
3.0
Memcached Metrics
QoS Name
Metric
Name
Units
Description
Version
QOS_AWS_ELASTICACHE_MEMCACHED_UNUSED_MEMORY
Unused
Memory For
Cache
Bytes
The amount of unused memory the

cache can use to store items. This is
derived from the memcached
statistics limit_maxbytes and bytes
by subtracting bytes from
limit_maxbytes.
3.0
QOS_AWS_ELASTICACHE_MEMCACHED_CURRENT_ITEMS
Number of
Items
Count
A count of the number of items

currently stored in the cache.
3.0
QOS_AWS_ELASTICACHE_MEMCACHED_EVICTIONS
Total
Count
Non-Expired
Evicted
Items
The number of non-expired items the

cache evicted to allow space for new
writes.
3.0
QOS_AWS_ELASTICACHE_MEMCACHED_RECLAIMED
Total
Expired
Items
Evicted
Count
The number of expired items the

cache evicted to allow space for new
writes
3.0
QOS_AWS_ELASTICACHE_MEMCACHED_GET_HITS
Total Cache
Hits
Requests
Count
The number of get requests the

cache has received where the key
requested was found.
3.0
QOS_AWS_ELASTICACHE_MEMCACHED_GET_MISSES
Total Cache
Miss
Requests
Count
The number of get requests the

cache has received where the key
requested was not found
3.0
QOS_AWS_ELASTICACHE_MEMCACHED_BYTES_USED_FOR_CACHE_ITEMS
Total Bytes
Used for
Cache
Items
Bytes
The number of bytes used to store

cache items.
3.0
Redis Metrics
QoS Name
Metric Name
Units
Description
Version
QOS_AWS_ELASTICACHE_REDIS_CURRENT_CONNECTIONS
Total Bytes
Allocated for Cache
Count
The number of client connections, excluding

connections from read replicas.
3.0
QOS_AWS_ELASTICCACHE_REDIS_BYTES_USED_FOR_CACHE
Number of
Connections
Bytes
The number of bytes allocated by Redis.
3.0
QoS data for the AWS SQS service

QoS Name
Metric
Name
Units
Description
Version
QOS_AWS_SQS_APPROXIMATE_NUMBER_OF_MESSAGES_DELAYED
Number Of
Messages
Delayed
Count
The number of messages in the queue

that are delayed and not available for
reading immediately..
3.5
QOS_AWS_SQS_APPROXIMATE_NUMBER_OF_MESSAGES_NOT_VISIBLE
Number Of
Messages
Not Visible
Count
The number of messages that have been

sent to a client but have not yet been
deleted or have not yet reached the end of
their visibility window.
3.5
QOS_AWS_SQS_APPROXIMATE_NUMBER_OF_MESSAGES_VISIBLE
Number Of
Messages
Visible
Count
The number of messages available for

retrieval from the queue.
3.5
QOS_AWS_SQS_NUMBER_OF_EMPTY_RECEIVES
Number
OF Empty
Receives
Count
The number of ReceiveMessage API calls

that did not return a message.
3.5
QOS_AWS_SQS_NUMBER_OF_MESSAGES_DELETED
Number Of
Messages
Deleted
Count
The number of messages deleted from

the queue.
3.5
QOS_AWS_SQS_NUMBER_OF_MESSAGES_RECEIVED
Number Of
Messages
Received
Count
The number of messages returned by

calls to the ReceiveMessage API action.
3.5
QOS_AWS_SQS_NUMBER_OF_MESSAGES_SENT
Number Of
Messages
Sent
Count
The number of messages added to a

queue.
3.5
QOS_AWS_SQS_SENT_MESSAGE_SIZE
Sent
Message
Size
Bytes
The size of messages added to a queue.
3.5
QoS data for the AWS SNS service

QoS Name
Metric Name
Units
Description
Version
QOS_AWS_SNS_NUMBER_OF_MESSAGES_PUBLISHED
Number Of Messages
Published
Count
The number of messages published.
3.5
QOS_AWS_SNS_PUBLISH_SIZE
Publish Message Size
Bytes
The size of messages published
3.5
QOS_AWS_SNS_NUMBER_OF_NOTIFICATIONS_DELIVERED
Number Of Notifications
Delivered
Count
The number of messages successfully

delivered.
3.5
QOS_AWS_SNS_NUMBER_OF_NOTIFICATIONS_FAILED
Number Of Notifications
Failed
Count
The number of messages that SNS topic

failed to deliver.
3.5
QoS data for the AWS ELB service

QoS Name
Metric
Name
Units
Description
Version
QOS_AWS_ELB_HEALTHY_HOST_COUNT
Healthy
Host Count
Count
The number of healthy instances in each Availability Zone. Hosts

are declared healthy if they meet the threshold for the number of
consecutive health checks that are successful. Hosts that have
failed more health checks than the value of the unhealthy
threshold are considered unhealthy.
3.5
QOS_AWS_ELB_UNHEALTHY_HOST_COUNT
Unhealthy
Host Count
Count
The number of unhealthy instances in each Availability Zone.

Hosts that have failed more health checks than the value of the
unhealthy threshold are considered unhealthy.
3.5
QOS_AWS_ELB_REQUEST_COUNT
Request
Count
Count
The number of completed requests that were received and routed

to the back-end instances.
3.5
QOS_AWS_ELB_LATENCY
Latency
Seconds
The time elapsed after the request leaves the load balancer until
the response is received.
3.5
QOS_AWS_ELB_HTTP_CODE_ELB_4XX
Http Code
ELB 4XX
Count
The number of HTTP 4XX client error codes generated by the

load balancer when the listener is configured to use HTTP or
HTTPS protocols.
3.5
QOS_AWS_ELB_HTTP_CODE_ELB_5XX
Http Code
ELB 5XX
Count
The number of HTTP 5XX server error codes generated by the

load balancer when the listener is configured to use HTTP or
HTTPS protocols. This metric does not include any responses
generated by back-end instances.
3.5
QOS_AWS_ELB_HTTP_CODE_BACKEND_2XX
Http Code
Backend
2XX,
Count
The number of HTTP response codes generated by back-end

instances. This metric does not include any response codes
generated by the load balancer.
3.5
Http Code
Backend
3XX,
Http Code
Backend
4XX,
Http Code
Backend
5XX
QOS_AWS_ELB_BACKEND_CONNECTION_ERROR
Backend
Connection
Error
Count
The number of connections that were not successfully

established between the load balancer and the registered
instances.
3.5
QOS_AWS_ELB_SURGE_QUEUE_LENGTH
Surge
Queue
Length
Count
The number of requests that are pending submission to a

registered instance.
3.5
QOS_AWS_ELB_SPILLOVER_COUNT
Spillover
Count
Count
The number of requests that were rejected due to the queue

being full.
3.5
QoS data for the AWS Auto Scaling service

QoS Name
Metric
Name
Units
Description
Version
QOS_AWS_AUTO_SCALING_CPU_UTILIZATION
CPU
Usage
Percentage
The percentage of allocated EC2 compute units that are

currently in use on the instance.
3.5
QOS_AWS_AUTO_SCALING_DISK_READ_OPS
Reads
Count
Completed read operations from all ephemeral disks

available to the instance in a specified period of time.
3.5
QOS_AWS_AUTO_SCALING_DISK_WRITE_OPS
Writes
Count
Completed write operations to all ephemeral disks

available to the instance in a specified period of time.
3.5
QOS_AWS_AUTO_SCALING_DISK_READ_BYTES
Data
Read
Bytes
Bytes read from all ephemeral disks available to the

instance.
3.5
QOS_AWS_AUTO_SCALING_DISK_WRITE_BYTES
Data
Written
Bytes
Bytes written to all ephemeral disks available to the

instance.
3.5
QOS_AWS_AUTO_SCALING_NETWORK_IN
Total
Bytes
Received
Bytes
The number of bytes received on all network interfaces by

the instance.
3.5
QOS_AWS_AUTO_SCALING_NETWORK_OUT
Total
Bytes
Sent
Bytes
The number of bytes sent out on all network interfaces by

the instance.
3.5
QOS_AWS_AUTO_SCALING_STATUSCHECK
Status
Check
Count
Values for this metric are either 0 (zero) or 1 (one.) A zero

indicates that the status check passed. A one indicates a
status check failure.
3.5
QOS_AWS_AUTO_SCALING_STATUSCHECK_INSTANCE
Instance
Status
Check
Count
Reports whether the instance has passed the EC2

instance status check in the last minute. Values for this
metric are either 0 (zero) or 1 (one.) A zero indicates that
the status check passed. A one indicates a status check
failure.
3.5
QOS_AWS_AUTO_SCALING_STATUSCHECK_SYSTEM
System
Status
Check
Count
Reports whether the instance has passed the EC2 system

status check in the last minute. Values for this metric are
either 0 (zero) or 1 (one.) A zero indicates that the status
check passed. A one indicates a status check failure.
3.5
azure (Microsoft Azure Monitoring)

Microsoft Azure is a cloud computing platform and infrastructure, created by Microsoft that provides on-demand computing and storage to host,
scale and manage Web applications and services through a global network of Microsoft-managed datacenters.
The Microsoft Azure Monitoring probe remotely monitors the health and performance of Azure infrastructure and services. The probe enables you
to connect to Microsoft Azure using certificates and discover Azure resources to be monitored. The probe fetches all the service data from
different geographical locations and lets you create profiles that monitor your cloud services including virtual machines (VMs), websites and
storage. The probe lets you configure various monitoring parameters for each of these services. For example, you can check the health status of
data services and VMs, number of requests made to the storage service, CPU utilization, and so on. Based on the configured parameters, the
probe generates Quality of Service (QoS) metrics. Refer to azure Metrics to understand the monitoring capabilities of the probe.
You can also configure dynamic and static threshold values for the QoS metrics to receive alarms.
To use the azure probe, you must have:
Azure Subscription: To manage your Azure services, you must purchase one or more Azure subscriptions. A subscription defines how
many cloud resources (hosted services and storage accounts) you are entitled to create or use and how these resources are billed.
These subscriptions are created at the Azure Account Center. Each cloud service belongs to a subscription.
Note: An Azure account can have multiple subscriptions.
Management Certificate: Whenever you deploy a website, create a new storage account or manage any other service, these operations
pass through the Windows Azure Management API. The Azure Management Portal calls the Management API to perform that action for
you. These operation requests must be signed by a x509 certificate to ensure that only authorized operations are performed. These
certificates are called Management Certificates and are used to permit access to resources in your Azure subscription. The Management
certificate is saved as a .cer file.
One certificate can be linked to one or more subscriptions. A subscription can have multiple certificates and a certificate can even be
shared across multiple subscriptions regardless of who owns the subscription.
Note: To use the azure probe, you must upload a Management certificate to your Azure account in the Management portal and
associate Subscription Ids from your Azure account to this certificate.
More Information
azure (Microsoft Azure Monitoring) Release Notes
v2.1 azure AC Configuration

The azure probe is configured to create monitoring profiles to access Azure services and fetch data from Azure datacenters. You can also
configure health monitors to generate alarms on the basis of the availability of services in various geographical regions.
The following diagram outlines the process to configure the probe to collect QoS data for Microsoft Azure systems.
Contents
Prerequisites
Create a Profile
Apply Monitoring through Templates
Alarm Thresholds
Stop Receiving Alarms for Deleted Components
Prerequisites
Verify that required hardware and software is available before you configure the probe. For more information, see azure (Microsoft Azure
The following are the prerequisites for the Microsoft Azure Monitoring probe.
Before using the azure probe, you must :
1. Have an Azure user-account with valid user-credentials
2. Have a valid Azure subscription
3. Create a JKS Key Store File. A keystore is a database of cryptographic keys, X.509 certificate chains, and trusted certificates.
4. Create an Azure Management Certificate from that Key Store File.
5. Upload the Azure Management Certificate to your account in the Azure Management Portal. This certificate is used for Azure
Management API authentication.
6. Upload the Key Store File to the azure probe.
Create a JKS Key Store File and a Certificate

Ensure that you have the keytool.exe file in the bin folder and JDK 1.6 or JDK 1.7 installed on your system that is required to create the
certificate. The bin folder is located at Program Files -> Java -> JDK version -> bin
1. Run the following command from the bin folder. For example, run the command from C:\Program Files (x86)\Java\jdk1.6.0_21\bin
keytool -genkeypair -alias mydomain -keyalg RSA -keystore

WindowsAzureKeyStore.jks
-keysize 2048 -storepass "India@123"
Running this command creates a key store called WindowsAzureKeyStore.jks and sets the password to access this as India@123.
2. Run the following command to export a certificate from this key store.
keytool -v -export -file D:\WindowsAzure.cer -keystore

WindowsAzureKeyStore.jks
-alias mydomain
Running this command creates the WindowsAzure.cer file in the D: of your system.
Upload the Azure Management Certificate to your Azure Account in the Azure Portal
Follow these steps:
1. Open the Microsoft Azure home page in your web browser.
2. Log in with your Microsoft Azure account credentials.
3. Navigate to Settings from the left navigation pane.
4. Click the Management Certificates tab.
5. Click Upload.
6. Browse and select your certificate file.
7. Click OK.
The certificate file is uploaded and appears in the Microsoft Azure Management Portal.
Upload the Key Store File to the azure Probe

You must upload the Key Store file to the probe, while creating an azure profile. Refer Create a Profile section for details.
Create a Profile
The following procedure enables you to add a profile for monitoring the Azure services. Each profile represents one Azure subscription.
Follow these steps:
1. Click the Options (icon) next to the Azure node in the navigation pane.
3. Set or modify the following values.
Account Name: defines a unique name for the monitoring profile.
Key Store File Path: enables you to locate your key store file by clicking Browse.
Key Store File Password: specifies the key store file password.
Key Store Type: enables you to upload the selected the Key Store type. The available options are:
JKS: The Java Key Store (JKS) can contain private keys and certificates, but it cannot be used to store secret keys. Since it's a
Java specific keystore, so it cannot be used in other programming languages.
PKCS12: It is a standard keystore type which can be used in Java and other languages. It usually has an extension of p12 or pfx.
You can store private keys, secret keys and certificates on this type.
Subscription Id: specifies the Azure Subscription Id.
You can check the authenticity of the Subscription Id by clicking the Verify Selection button under the Actions drop down.
Active: activates the profile for service monitoring. By default, the profile is active.
Interval (seconds): specifies the time interval (in seconds) after which the probe collects the data from the Azure cloud for the specific
profile.
Alarm Message: specifies the alarm to be generated when the profile is not responding.
4. Click Submit.
The new monitoring profile is displayed as a node below the Azure Data Services Health node in the navigation pane.
5. Navigate to the Profile Name node.
6. Click the Verify Selection option under the Actions drop down to verify the Subscription Id.
7. Click Save to save the profile.
The profile is saved and the VM's, storages and websites are automatically discovered for the profile.
Note: The profile goes into pending state to fetch the data for that particular Azure subscription. Reload or reopen the page to see the
tree structure of the Azure VM's, storages and websites for that subscription.
Apply Monitoring through Templates

The azure probe allows you to create configuration templates. The templates allow you to apply consistent monitoring configurations across
multiple profiles using filters. For more information, see v2.1 Azure Apply Monitoring with Templates.
Alarm Thresholds
allow the probe to:

maintained by the NAS probe. If you are working with CA UIM 8.0 or earlier, you will have to add the following subsystem IDs manually using the
NAS Raw Configuration menu. However, if you have upgraded to CA UIM 8.1 or later, then you do not have to manually add the following
subsystem IDs:
Key Name
Value
2.1.6.
Azure
2.1.6.1.
Data Service Health
2.1.6.2.
VM Role
2.1.6.4.
Website
2.1.6.5.
Storage
In the Admin Console, click the icon next to the NAS probe, select Raw Configure.
Click on the Subsystems folder.
Click on the New Key Menu item.

Enter the Key Name in the Add key window, click Add.
Click in the Value column for the newly created key and enter the key value.
Repeat this process for all of the required subsystem IDs for your probe.
Click Apply.
In Infrastructure Manager, right click on the NAS probe, select Raw Configure.
Click on the Subsystems folder.
Click on the New Key... button.
Enter the Key Name and Value
Click OK.
Repeat this process for all of the required subsystem IDs for your probe.
Click Apply.

Use this procedure to stop receiving alerts for any Azure virtual machine, website, or storage that you delete from your Azure subscription.
For example, a monitored subscription for a virtual machine is deleted from Microsoft Azure before its monitoring is deactivated. The probe does
not fetch the VM details and generates false alerts because the VM is deleted from your Azure subscription. The probe keeps sending false
alarms for the VM because the probe is not able fetch the VM details. Since the VM is deleted from the Azure subscription, the probe does not
display the VM in the navigation pane of the probe GUI.
Modify the detached configuration parameter of the probe to stop receiving false alerts.
Follow these steps:
1. Open the Raw Configure GUI of the probe.
2. Add the show_detached_configuration key under the setup section and set the key value to Yes.
3. Click Apply to close the Raw Configure GUI for restarting the probe and applying changes.
The navigation pane of the probe GUI shows a new node Detached Configuration. This node contains the components which are
deleted from the Azure subscription but still selected for monitoring in the probe.
4. Click the Options (icon) next to the component name you want to stop receiving alerts and select Delete.
5. Click Save.
The probe stops sending false alerts for the deleted components after you complete the above mentioned steps.
v2.1 Azure Apply Monitoring with Templates

Contents
Apply a Default Template

Create Template
Create Template Filter Rules
Activate a Template Monitor
Using Regular Expressions in Templates
The Template Editor interface allows you to create and apply monitoring templates. Templates reduce the time that you need for manual monitor
configuration and provide consistent monitoring across the devices in your network. You can configure monitoring on many targets with a
well-defined template.
You can customize any template by configuring:
Precedence
Precedence controls the order of template application. The probe applies a template with a precedence of one after a template with a
precedence of two. If there are any overlapping configurations between the two templates, then the settings in the template with a
precedence of one overrides the settings in the other template. If the precedence numbers are equal, then the templates are applied
in alphabetical order.
Filters
Filters let you control how the probe applies monitors based on attributes of the target device.
Rules
Rules apply to a device filter to create divisions within a group of systems or reduce the set of devices that the probe monitors.
Monitors
Monitors collect quality of service (QoS), event, and alarm data.
This article describes how to apply monitoring with templates for the Microsoft Azure Monitoring (Azure) probe.

The default templates contain settings for a recommended monitor configuration. You can use, or modify these default configurations to quickly
start collecting data for your environment. Both, existing and new profiles can be configured using templates. The default template has the
monitors that are configured for the default USM view.
Follow these steps to apply a default template:
The Template Editor - <probeName> <Version> page is displayed
3. Click the Options (icon) next to the Azure Default Template node. The Copy dialog appears.
4. Enter the name of the template and a description.
5. Enter a precedence value for the template.
Following are the rules for setting the precedence:
A numeric value is set as precedence.
The precedence is applied on multiple templates. The scenarios are described as follows:
When the precedence is different for the templates:The precedence of a template decreases as the value increases.
Example: 1 has higher precedence than 2, and so on.
When filters are applied on templates: The precedence works according to the applied filters. If no filter is applied, the
precedence is applied on available templates
6. Select the Active checkbox to activate the template.

7. Click Submit and then click Save.
8. The probe applies the template with the default settings.
Create Template
You can create a new template to configure multiple existing profiles with the same monitor configuration.
Follow these steps:

3. The Template Editor - <probeName> <Version> page is displayed.
4. Click the Options (icon) next to the azure probe node.
6. Specify a name and description for the template.
7. Enter the precedence value if you want to modify the default precedence setting.
The <templateName> node is displayed followed by all the profile nodes of the probe.
9. Click the <templateName> node to view the monitors and configure and include them in the template.
10. Click the Options (icon) next to nodes representing multiple possible values (such as Profile or Storage State) to create filters.
Refer Creating Filter Rules for more information.
Note: You can skip Step 9 and Step 10 if you do not need to configure the applicable monitors in those nodes.

13. Select Save.
The template is created and applied to the probe at the next probe interval.
Note: The sections of the profiles configured using templates are not available for individual configuration. Clear the Active checkbox to
deactivate the template on the profile to unlock it. You can also exclude a profile using filter rules.
Create Template Filter Rules

Filters let you control how the probe applies monitors based on attributes of the target device. Filters also let you control which profiles or devices
are associated with a particular template. You can create filter rules for nodes that represent multiple possible values (such as Profile or Storage
State). You can add rules to a device filter to create divisions within a group of systems. Similarly, you can also reduce the set of devices that the
probe is to monitor. For example, you can add a rule to apply a monitoring configuration to all VMs for which the Power State is On.
Follow these steps:
3. Specify the condition that the probe uses to match against the label.
Default: Equals
All the conditions are described as follows:
Equals: indicates that the label is the same as the specified value.
Regex: indicates that the label matches the specified regular expression.
Refer to Using Regular Expressions for more information.
StartsWith: indicates that the label ends with the specified value.
5. Enter a precedence value for the filter.
Note: The rules for setting the precedence value for filters are same as setting precedence for templates.
5.

Note: You must activate the template for the probe to apply the monitor configuration. When you change the template state to active,
the probe immediately applies all template configuration, including filters, rules, and monitors.


You can also use simple text with some wildcard operators for matching the target string. For example, *test* expression matches the text test in
target string.
The following table describes some examples of regex and pattern matching for the azure probe.
Regular expression
Type of regular expression
Explanation
[A-Z]
Standard (PCRE)
Standard (PCRE)
Standard (PCRE)
\d*
Custom
v2.1 azure AC GUI Reference

Contents
Template Editor
Azure Node
Azure Data Services Health Node
<Region Name> Node
<Profile Name> Node
VM Node
Storage Node
Website Node
Template Editor
templates that can be applicable across multiple profiles. For more information, see v2.1 Azure Apply Monitoring with Templates.
Azure Node
This node lets you view the probe information and configure the logging properties.
Navigation: Azure
Set or modify the following values, as needed:
Azure > Probe Information
Azure > Probe Setup
This section lets you configure the detail level of the log file.
Default: 3-info.
Azure > Proxy Settings
This section enables you to connect to the Azure cloud through a proxy server on the network. You need proxy server settings when your network
Enable Proxy: lets you use a proxy server for connecting to the Azure cloud.
User: defines the user name for accessing the proxy server.
Note: The User field supports both the formats, that is, User Name and, Domain Name\User Name.
Azure > Add New Profile

This section lets you add a profile for monitoring the Azure services.
Note: Giving same name to the profile overrides the existing profile settings. So, you are recommended to provide a unique name for a
new profile.
Key Store Type: enables you to select the Key Store type. The available options are:
JKS: The Java Key Store (JKS) can contain private keys and certificates, but it cannot be used to store secret keys. Since it's a Java
specific keystore, so it cannot be used in other programming languages.
PKCS12: It is a standard keystore type which can be used in Java and other languages. It usually has an extension of p12 or pfx. You
can store private keys, secret keys and certificates on this type.
Default: PKCS12
Subscription Id: enables you to enter your Azure Subscription Id.
Notes:
On upgrading the probe from version 2.01 to 2.10 or later, only one Azure Subscription can be associated with a profile, which
is shown in encrypted format. If you have configured multiple subscriptions in one profile through the probe version 2.01, then,
on upgrading the probe to version 2.10 or later, the probe automatically creates separate profiles for each subscription. Thus,
you can manually configure the monitors for each subscription or apply monitoring templates to configure multiple profiles
simultaneously. For more information on using templates, refer v2.1 Azure Apply Monitoring with Templates.
From the probe version 2.10 or later, the Subscription Id is not added in the source or target and hence not visible on the USM
portal. Thus, you can see duplicate alarms on USM.

Default: Active
profile.
Default: 600
Note: You are recommended to keep the time interval as 600 seconds or above since the probe takes time to fetch the data from the
API.
Alarm Message: specifies the alarm to be generated when the profile is not responding. For example, the profile does not respond if there
is a connection failure or inventory update failure.

The azure probe scans the Azure cloud and fetches the global health status data of various services that are available in http://azure.microsoft.co
m/en-gb/status/. This node also enables you to set the polling interval for the Auto Discovery of new locations along with their services.
Navigation: Azure > Azure Data Services Health Node
Azure Data Services Health > Data Services Monitor
This section lets you set the polling interval after which the probe fetches the global health status data of various services.
Interval (minutes): enables you to set the polling interval.
Default: 5
<Region Name> Node

This node lets you view the list of Azure Data Services locations that are available when the Azure probe scans the Azure cloud. You can
configure the Azure probe to generate alarms for the selected location.
Note: This node is known as Region Name Node in the document as it represents all the geographical locations discovered by the
azure probe.
Navigation: Azure > Azure Data Services Health > Region Name
Region Name > Data Service Status
This section lets you view the current health status of a data service for the selected location. The value for the health status of a data
service can be 0 (Good), 1 (Warning), 2 (Error), and, 3 (Information). You can also configure the QoS for a specific data service for the
selected location.
Note: The data services for the selected location are visible in a tabular format. You can select any one service in the table and can
Description: indicates a description of the selected service.
Metric Type: identifies a unique ID for alarm and QoS.
Units: indicates the Metric unit of the selected service status.
Publish Data: enables the probe to check the status of the selected service and generate QoS and alarms.
Note: When you select the Publish Data checkbox, the value of the Data column in the table changes from Off to On.
Similarly, you can configure the services for other geographical locations.
<Profile Name> Node

This node represents the profile created to monitor an Azure account. After you configure your account/resource information including certificate
and subscription, the azure probe examines the current Azure subscription and imports all detected instances of VM's, websites, and storage into
a tree structure.
Note: This node is known as profile name node in the document and is user-configurable.
Navigation: azure > Profile Name

Profile Name > Resource Setup
Refer to the Add New Profile section of the azure node topic for field description.
VM Node
The azure probe enables you to discover all monitored resources such as VM's, websites and storage associated with the specified subscription.
This node represents all the Azure VM's associated with the specified subscription.
Navigation: azure > Profile Name > VM
<VM Name> Node
This node lets you configure the performance metrics for the VM's. The azure probe generates QoS data of that VM according to the values
fetched from the Azure Management Portal.
The performance metrics are divided into following categories:
CPU
Disk
Network
Each category is represented as a node under the VM Name node.
Note: This node is referred to as VM Name node in the document and it represents the VM state and various performance counters for
that VM.
Navigation: azure > Profile Name > VM > VM Name

VM Name > Time Duration Configuration
This section enables you to select the time duration according to which the VM data is retrieved.
Set or modify the following values, as needed.
Time Duration: enables you to select the time duration according to which the VM data is retrieved.
Default: 24 Hours
For details on how to set the time duration for a VM, refer the Time Duration Concept in Azure probe for Storage, VMs and Websites topic.
VM Name > Monitors
This section lets you configure the performance metrics for generating QoS for the Power State of the VM.
Note: The performance counters of a VM are visible in a tabular form. You can select any one counter in the table and can configure its
properties.
QoS Name: indicates the name of performance metrics.
Publish Data: generates the QoS data for the selected monitor.
Similarly, you can configure the other performance monitors that are visible under the CPU, Disk, and Network nodes.
Storage Node
This node represents all the Azure storage associated with the specified subscription.
Navigation: Azure > Profile Name > Storage

<Storage Name> Node
This node lets you configure the performance metrics for the Azure Storage. The azure probe generates QoS data for that Storage according to
the values fetched from the Azure Management Portal.
The performance metrics are divided into the following categories:
blob
queue
table
Each category is represented as a node under the Storage Name node.
Note: This node is referred to as Storage Name node in the document and it represents the storage state and various performance
counters for that storage.
Navigation: azure > Profile Name > Storage > Storage Name
For field descriptions, refer the VM Node topic.
For details on how to set the time duration for a storage, refer Time Duration Concept in Azure probe for Storage, VMs and Websites topic.
Website Node
This node represents all the Azure websites associated with the specified subscription.
Navigation: azure > Profile Name > Website
<Website Name> Node
This node lets you configure the performance metrics for the websites. The probe generates QoS data of that website according to the values
fetched from the Azure Management Portal.
Note: This node is referred to as Website Name node in the document and it represents the various performance metrics for that
Website.
Navigation: Azure > Profile Name > Website > Website Name
Set or modify the following values, if needed:
Website Name > Time Duration Configuration
This section enables you to select the time duration according to which the website data is retrieved.
Set or modify the following values, as needed.
Time Duration: enables you to select the time duration.
Default: 24 Hours
For details on how to set the time duration for a website, refer Time Duration Concept in Azure probe for Storage, VMs and Websites topic.
Website Name > Monitors
This section lets you configure the performance metrics for generating QoS.
Note: The performance metrics of a Website are visible in a tabular form. You can select any one metric in the table and can configure
its properties.
QoS Name: indicates the name of performance metric.
Publish Data: generates the QoS data for the selected metric.
Time Duration Concept in Azure probe for Storage, VMs, and Websites
The following table describes the time-duration concept in azure probe for storage, VMs and websites. You are required to set the time duration
while configuring the performance metrics for a storage, VM or website. For example, for a VM, if the time duration is set to 1 hour, it means that
you get response as an average of the data collected for every 5 minutes interval in the past 1 hour from Azure. Similarly, for the VM, if the time
duration is set to 7 days, it means that you get response as an average of the data collected for every 1 hour interval in the past 7 days from
Azure as described in the table below.
Time Duration
1 Hour
6 Hours
24 Hours
7 Days
Storage
1 Hour
1 Hour
1 Hour
VM
5 Minutes
5 Minutes
1 Hour
Websites
1 Minute
1 Hour
1 Hour
Note: The granularity of data (like 1 minute, 5 minutes) that is written in the table is based on the data provided by Microsoft Azure.
v2.0 azure AC Configuration

The Azure probe is configured to create monitoring profiles for accessing Azure services and fetching data from Azure datacenters. You can also
configure health monitors to generate alarms on the basis of the availability of services in various geographical regions.
Contents
Managing Profiles
How to create a profile
How to delete a profile
This section contains the prerequisites for the Microsoft Azure Monitoring probe.
An Azure user-account with valid user-credentials, a valid Azure subscription, Azure Management Certificate and a valid Key Store file. A
keystore is a database of cryptographic keys, X.509 certificate chains, and trusted certificates.
For using the Azure probe, you are required to upload your Azure Management Certificate to the Azure Management Portal which is used for
Azure Management API authentication. Then, you are required to upload the Key Store File to the Azure probe.
Note: Ensure that before you create or upload the certificate: JDK 1.6 or JDK 1.7 is installed on the computer to be used, and you have
the keytool.exe file in the bin folder to create the certificates. The bin folder is located at Program Files -> Java -> JDK version -> bin.
Follow these steps to create a JKS Key Store file:

1. Run the following command from the bin folder. For example, run the command from C:\Program Files (x86)\Java\jdk1.6.0_21\bin
keytool -genkeypair -alias mydomain -keyalg RSA -keystore

WindowsAzureSJKeyStore.jks
-keysize 2048 -storepass "Inda@123"
Running this command creates a key store called WindowsAzureSJKeyStore.jks and sets the password to access this as Inda@123.
2. Run the following command to export a certificate from this key store.
keytool -v -export -file D:\WindowsAzureSJ.cer -keystore

WindowsAzureSJKeyStore.jks
-alias mydomain -alias mydomain
Running this command creates the WindowsAzureSJ.cer file in the D: of my computer.

Follow these steps to upload the management certificate to your Azure account:
1. Open the Microsoft Azure home page in your web browser.
2. Log on with your Microsoft Azure account credentials.
3. Navigate to Settings from the left navigation pane.
4. Click the Management Certificates tab.
5. Click Upload.
6. Browse and select your certificate file.
7. Click OK.
The certificate file is uploaded and appears in the Microsoft Azure Management Portal.
For details on uploading the keystore file to the Azure probe, refer to the Add New Profile section under the Azure node.

Managing Profiles
This procedure provides the information to configure a particular section of a profile. Each section within the profile lets you configure the
properties of the probe for connecting to the Azure cloud and monitoring various Azure services.
Follow these steps:
1. Navigate to the section within a profile that you want to configure.
How to create a profile

The following procedure enables you to add a profile for monitoring the Azure services. Each profile represents one Azure account. There can be
multiple subscriptions for an Azure account.
Follow these steps:
1. Click Options next to the Azure node in the navigation pane.
The new monitoring profile is visible under the Azure node in the navigation pane.
How to delete a profile

You can delete a profile if you do not want the probe to monitor the performance of a specific Azure service.
Follow these steps:
3.
3. Click Save.
The monitoring profile is deleted.

maintained by the NAS probe. If you are working with CA UIM 8.0 or earlier, you will have to add the following subsystem IDs manually using the
NAS Raw Configuration menu. However, if you have upgraded to CA UIM 8.1 or later, then you do not have to manually add the following
subsystem IDs:
Key Name
Value
2.1.6.
Azure
2.1.6.1.
Data Service Health
2.1.6.2.
VM Role
2.1.6.4.
Website
2.1.6.5.
Storage
7. Click Apply.
6. Click Apply.
Note: Ensure that you enter the key names as-is including the period(.) in the end for correct mapping.

Use this procedure to stop receiving alerts for any Azure virtual machine, website or storage that you delete from your Azure subscription.
For example, you are monitoring a virtual machine, which is deleted from the Microsoft Azure subscription before deactivating its monitoring. The
probe is not able to fetch the VM details and generates false alerts because the VM is deleted from your Azure subscription. The probe keeps
sending false alarms for the VM because the probe is not able fetch the VM details. Since the VM is deleted from the Azure subscription, the
probe does not display the VM in the navigation pane of the probe GUI.
Modify the detach configuration parameter of the probe to stop receiving false alerts.
Follow these steps:
1. Open the Raw Configure GUI of the probe.
2. Add the show_detached_configuration key under the setup section and set the key value to Yes.
3. Click Apply to close the Raw Configure GUI for restarting the probe and applying changes.
The navigation pane of the probe GUI shows a new node Detached Configuration. This node contains the components which are
deleted from the Azure subscription but still selected for monitoring in the probe.
4. Click the Options icon next to the component name you want to stop receiving alerts and select Delete.
5. Click Save.
The probe stops sending false alerts for the deleted components after you complete the above mentioned steps.
v2.0 azure AC GUI Reference

Contents
Azure Node
<Region Name> Node
<Profile Name> Node
Subscriptions Node
<Subscription Id> Node
VM Node
Storage Node
Website Node
Time Duration Concept in Azure probe for storage, VMs and websites
Azure Node
Navigation: Azure
Azure > Probe Information
Azure > Probe Setup
Azure > Proxy Settings
This section enables you to connect to the Azure cloud through a proxy server on the network. You need proxy server settings when your network
Enable Proxy: lets you use a proxy server for connecting to the Azure cloud.
User: defines the user name for accessing the proxy server.
Note: The User field supports both the formats, that is, User Name and, Domain Name\User Name.
Azure > Add New Profile

This section lets you add a profile for monitoring the Azure VM's, storages and websites for the selected subscription. QoS data is generated
according to the metric values generated by these VM's, storages and websites.
Note: You are required to add the subscription Id to the profile for which monitoring is required.

Note: Giving same name to the profile overrides the existing profile settings. So, you are recommended to provide a unique name for
the new profile.
Key Store Type: enables you to select the Key Store type. The available options are:
JKS: The Java Key Store (JKS) can contain private keys and certificates, but it cannot be used to store secret keys. Since it's a Java
specific keystore, so it cannot be used in other programming languages.
PKCS12: It is a standard keystore type which can be used in Java and other languages. It usually has an extension of p12 or pfx. You
can store private keys, secret keys and certificates on this type.
Default: PKCS12
profile.
Default: 600
Note: You are recommended to keep the time interval as 600 seconds or above since the probe takes time to fetch the data from the
API.
The Azure probe scans the Azure cloud and fetches the global health status data of various services that are available in http://azure.microsoft.co
m/en-gb/status/. This node also enables you to set the polling interval for the Auto Discovery of new locations along with their services.
Navigation: Azure > Azure Data Services Health Node
Azure Data Services Health > Data Services Monitor
This section lets you set the polling interval after which the probe fetches the global health status data of various services.
Interval (minutes): enables you to set the polling interval.
Default: 5
<Region Name> Node
This node lets you view the list of Azure Data Services locations that are available when the Azure probe scans the Azure cloud. You can
configure the Azure probe for generating alarms for the selected location.
Note: This node is known as Region Name Node in the document as it represents all the geographical locations discovered by the
Azure probe.
Navigation: Azure > Azure Data Services Health > Region Name
Region Name > Data Service Status
This section lets you view the current health status of a data service for the selected location. The value for the health status of a data
service can be 0 (Good), 1 (Warning), 2 (Error), and, 3 (Information). You can also configure the QoS for a specific data service for the
selected location.
Note: The data services for the selected location are visible in a tabular format. You can select any one service in the table and can
Description: indicates a description of the selected service.
Metric Type: identifies a unique ID for alarm and QoS.
Units: indicates the Metric unit of the selected service status.
Publish Data: enables the probe to check the status of the selected service and generate QoS and alarms.
Note: When you select the Publish Data checkbox, the value of the Data column in the table changes from Off to On.
<Profile Name> Node
This node represents the profile created to monitor an Azure account. For each profile, you are required to add the subscription Id for which
monitoring is required. After you configure your account/resource information including certificates and subscriptions, the Azure probe examines
the current Azure subscription and imports all detected instances of VM's, websites and storage into a tree structure. In this way, the probe
creates a hierarchy of all the Azure subscriptions added by you in the profile.
Note: This node is known as profile name node in the document and is user-configurable.
Navigation: Azure > Profile Name

Profile Name > Resource Setup
Refer to the Add New Profile section of the azure node topic for field description.
Profile Name > Subscription Information
In this section, the Subscription IDs for the selected profile are visible in a tabular form. This section enables you to add/delete a
Subscription Id to/from your profile. Click New to add a Subscription Id and click Delete to delete an existing one.
Set or modify the following values as required.
Subscription IDs: specifies the selected Subscription Id. You can check the authenticity of the Subscription Id through the Verify
Subscription button under the Actions drop down.
Note: On adding a new Subscription Id and saving the configuration, the profile goes into pending state to fetch the data for that
particular subscription. On reloading the page or re-opening the GUI after sometime, you are able to see the tree structure of the VMs,
storage and websites.
Subscriptions Node
This node lets you view all the subscriptions for the selected profile.
Navigation: Azure > Profile Name > Subscriptions
This node has no sections, or fields.
<Subscription Id> Node
This node represents a subscription of the Azure account. The probe discovers all instances of VM's, database, storage and websites for each
subscription.
Navigation: Azure > Profile Name Node > Subscriptions > Subscription Id
This node has no sections, or fields.
VM Node
The Azure probe enables you to discover all monitored resources such as VM's, websites and storage associated with the specified subscription.
This node represents all the Azure VM's associated with the specified subscription.
Navigation: Azure > Profile Name > Subscriptions > Subscription Id > VM
<VM Name> Node
This node lets you configure the performance metrics for the VM's. The Microsoft Azure Monitoring probe generates QoS data of that VM
according to the values fetched from the Azure Management Portal.
The performance metrics are divided into following categories:
CPU
Disk
Network
Each category is represented as a node under the VM Name node.
Note: This node is referred to as VM Name node in the document and it represents the VM state and various performance counters for
that VM.
Navigation: Azure > Profile Name > Subscriptions > Subscription Id > VM > VM Name
VM Name > Time Duration Configuration
This section enables you to select the time duration according to which the VM data is retrieved.
Time Duration: enables you to select the time duration according to which the VM data is retrieved.
Default: 24 Hours
For details on how to set the time duration for a VM, refer to the Time Duration Concept in Azure probe for storage, VMs and websites topic.
VM Name > Monitors
This section lets you configure the performance metrics for generating QoS for the Power State for the VM.
Note: The performance counters of a VM are visible in a tabular form. You can select any one counter in the table and can configure its
properties.
QoS Name: indicates the name of performance metrics.
Publish Data: generates the QoS data for the selected monitor.
Similarly, you can configure the other performance monitors that are visible under the CPU, Disk, and Network nodes.
Storage Node
This node represents all the Azure storage associated with the specified subscription.
Navigation: Azure > Profile Name > Subscriptions > Subscription Id > Storage
<Storage Name> Node
This node lets you configure the performance metrics for the Azure Storage. The Microsoft Azure Monitoring probe generates QoS data for that
Storage according to the values fetched from the Azure Management Portal.
The performance metrics are divided into the following categories:
blob
queue
table
Each category is represented as a node under the Storage Name node.
Note: This node is referred to as Storage Name node in the document and it represents the Storage state and various performance
counters for that Storage.
Navigation: Azure > Profile Name > Subscriptions > Subscription Id > Storage > Storage Name
For field descriptions, refer to the VM Node topic.
For details on how to set the time duration for a storage, refer to the Time Duration Concept in Azure probe for storage, VMs and websites to
pic.
Website Node
This node represents all the Azure websites associated with the specified subscription.
Navigation: Azure > Profile Name > Subscriptions > Subscription Name > Website
<Website Name> Node
This node lets you configure the performance metrics for the websites. The Microsoft Azure Monitoring probe generates QoS data of that website
according to the values fetched from the Azure Management Portal.
Note: This node is referred to as Website Name node in the document and it represents the various performance metrics for that
Website.
Navigation: Azure > Profile Name > Subscriptions > Subscription Id> Website > Website Name
Website Name > Time Duration Configuration
This section enables you to select the time duration according to which the website data is retrieved.
Time Duration: enables you to select the time duration.
Default: 24 Hours
For details on how to set the time duration for a website, refer to the Time Duration Concept in Azure probe for storage, VMs and websites to
pic.
Website Name > Monitors
This section lets you configure the performance metrics for generating QoS.
Note: The performance metrics of a Website are visible in a tabular form. You can select any one metric in the table and can configure
its properties.
QoS Name: indicates the name of performance metric.
Publish Data: generates the QoS data for the selected metric.
Time Duration Concept in Azure probe for storage, VMs and websites
The following table describes the time-duration concept in Azure probe for storage, VMs and websites. You are required to set the time duration
while configuring the performance metrics for a storage, VM or website. For example, for a VM, if the time duration is set to 1 hour, it means that
you get response as an average of the data collected for every 5 minutes interval in the past 1 hour from Azure. Similarly, for the VM, if the time
duration is set to 7 days, it means that you get response as an average of the data collected for every 1 hour interval in the past 7 days from
Azure as described in the table below.
Time Duration
1 Hour
6 Hours
24 Hours
7 Days
Storage
1 Hour
1 Hour
1 Hour
VM
5 Minutes
5 Minutes
1 Hour
Websites
1 Minute
1 Hour
1 Hour
Note: The granularity of data (like 1 minute, 5 minutes) that is written in the table is based on the data provided by Microsoft Azure.
azure Metrics
The following table describes the checkpoint metrics that can be configured using the Microsoft Azure Monitoring (azure) probe.
Contents
QoS Metrics
QoS data for the Azure data services
QoS data for the Azure VM
QoS data for the Azure storage service
QoS data for the Azure website service
QoS Metrics
The following tables describes the checkpoint metrics that can be configured using the azure probe.
QoS data for the Azure data services

QoS Name
Metric
Name
Units
Description
Version
QOS_AZURE_DATASERVICE_STATUS
Status
State
The current availability and health status of the data services. The values are as
follows: 0-Good, 1-Warning, 2-Error, 3-Information
v2.0
QoS data for the Azure VM

QoS Name
Metric
Name
Units
Description
Version
QOS_AZURE_VM_STATE
VM Power
State
State
The current availability and health status of the VMs. The values are as
follows: 0-Started, 1-Starting, 2-Stopping, 3-Stopped, 4-Unknown
v2.0
QOS_AZURE_VM_CPU_UTILIZATION
CPU Usage
Percentage
The percentage of CPU utilization
v2.0
QOS_AZURE_VM_DISK_READ
Disk Read
Bytes/sec
Total disk read throughput.
v2.0
QOS_AZURE_VM_DISK_WRITE
Disk Write
Bytes/sec
Total disk write throughput
v2.0
QOS_AZURE_VM_NETWORK_IN
Total Bytes
Received
Bytes
The number of bytes received on all network interfaces by the VM. This
metric identifies the volume of incoming network traffic on a single VM.
v2.0
QOS_AZURE_VM_NETWORK_OUT
Total Bytes
Sent
Bytes
The number of bytes sent out on all network interfaces by the VM. This metric
identifies the volume of outgoing network traffic on a single VM.
v2.0
QoS data for the Azure storage service

QoS Name
Metric
Name
Units
Description
Version
QOS_AZURE_STORAGE_TOTAL_REQUESTS
Total
Requests
Count
The total number of requests made to the specified storage

service. This number includes both, successful and failed
requests.
v2.0
QOS_AZURE_STORAGE_SUCCESS_COUNT
Success
Count
Count
The number of successful storage requests.
v2.0
QOS_AZURE_STORAGE_SUCCESS_PERCENTAGE
Success
Percentage
Percentage The percentage of successful storage requests.
v2.0
QOS_AZURE_STORAGE_AVAILABILITY
Availability
Percentage The availability of the specified storage account name.
v2.0
QOS_AZURE_STORAGE_STATE
Storage
State
State
v2.0
The status of the storage account. The values are as follows:

0-Created, 1-Creating, 2-ResolvingDns, 3-Changing,
4-Deleting.
QoS data for the Azure website service

QoS Name
Metric
Name
Units
Description
Version
QOS_AZURE_WEBSITE_AVG_MEMORY_WORKING_SET
Average
Memory
Working
Set
Bytes
The average size of the Working Set of the running

process. The Working set includes the set of memory
pages touched recently by the threads in the process.
v2.0
QOS_AZURE_WEBSITE_AVG_RESPONSE_TIME
Average
Response
Time
Bytes
The average response time of the website.
v2.0
QOS_AZURE_WEBSITE_CPU_TIME
CPU Time
Microsecond
The CPU time of the website.
v2.0
QOS_AZURE_WEBSITE_DATA_IN
Bytes
Received
Bytes
Measures the data received by the website from clients.
v2.0
QOS_AZURE_WEBSITE_DATA_OUT
Bytes Sent
Bytes
Measures the data sent by the website to clients.
v2.0
QOS_AZURE_WEBSITE_HTTP_ERRORS
HTTP
Client
Errors
Count
The number of Http "401 Unauthorized", "403

Forbidden", "404 Not Found" and "406 Not Acceptable"
messages sent.
v2.0
QOS_AZURE_WEBSITE_HTTP_CLIENT_ERRORS
HTTP
Errors
Count
The number of Http "4xx Client Error" messages sent.
v2.0
QOS_AZURE_WEBSITE_HTTP_REDIRECTS
HTTP
Redirects
Count
The number of Http "3xx Redirection" messages sent.
v2.0
QOS_AZURE_WEBSITE_HTTP_SERVER_ERRORS
HTTP
Server
Errors
Count
The number of Http "5xx Server Error" messages sent.
v2.0
QOS_AZURE_WEBSITE_HTTP_SUCCESSES
HTTP
Successes
Count
The number of Http "2xx Success" messages sent.
v2.0
QOS_AZURE_WEBSITE_HTTP_STATE
Website
State
State
The state of the website. The values are as follows:

0-Running, 1-Stopped
v2.0
Note: The QoS of probe version 1.0 are not supported by the probe version 2.0.
baseline_engine
Baseline engine samples the Quality of Service (QoS) data on the message bus, and at the top of the hour calculates baseline data points for
monitoring probes. The qos_processor probe sends the resulting data points to the UIM database.
The first baseline approximation is available after the interval has concluded, and is improved with succeeding baseline data points from
corresponding intervals gathered over a four-week to 12-week period.
More Information:
Baseline Engine (baseline_engine) Release Notes
baseline_engine Deployment
The baseline_engine probe is designed to be deployed with minimal configuration. Once active, it provides baselines for all QoS metrics being
gathered across the domain.
ppm, baseline_engine, and prediction_engine must all be deployed and running on hub robots if you want to configure dynamic, static, or Time To
Threshold alarm and threshold settings for monitoring probes. Make sure the nas and alarm_enrichment probes are deployed to the hub robots
where ppm is running if you want to configure Time Over Threshold alarm and threshold settings for monitoring probes.
Note: When running ppm v2.38 or later, be sure to select the Compute Baseline check box on the probe GUI in Admin Console to
allow baseline_engine to provide baselines for QoS metrics.
Starting with CA UIM Server installer v8.0, the baseline_engine probe is included with the installer. It is automatically installed on the primary hub
as part of the installation process. Once active probes have the Compute Baseline option selected, baseline_engine provides baselines for all
QoS metrics gathered across the domain. Review the baseline_engine Release Notes for additional information about deploying baseline_engine
to secondary hubs.
Recommended Multiple Hub (tiered) Probe Deployment

The baseline_engine has been designed to be horizontally scalable. The recommended deployment approach is to install it on secondary or
sub-hub(s) to distribute the processing. You can distribute the probe using drag and drop with Admin Console or Infrastructure Manager.
Note: The qos_processor probe must be running on the primary Hub to store the QOS_BASELINE messages in the UIM database.
QOS_BASELINE messages (where subject ID is QOS_BASELINE) must be forwarded from the baseline_engine probe on the secondary hub(s)
to the qos_processor probe running on the primary hub. To enable this message forwarding, create a new hub queue or amend existing hub
queues to forward the new QOS_BASELINE messages to the primary hub--just as is done for QOS_MESSAGE and QOS_DEFINITION
messages.
To amend or augment existing hub queues, edit your existing post (or attach) queues and add the "QOS_BASELINE" subject. Alternatively,
create a new post (or attach) queue with just the "QOS_BASELINE" subject.
Verify QOS_BASELINE Messages are Detected After Installing ppm on a Secondary Hub
With CA UIM 8.2 and later, ppm must be deployed on every hub that directly, or through a subordinate robot, hosts a probe that will be configured
using Probe Provisioning. When you deploy ppm, baseline_engine, and prediction_engine are automatically deployed to the same subordinate
hub. baseline_engine, and prediction_engine must all be deployed and running if you want to configure dynamic or Time To Threshold alarm and
threshold settings for monitoring probes. Make sure the nas and alarm_enrichment probes are deployed to the same subordinate hub where ppm
is running if you want to configure Time Over Threshold alarm and threshold settings for monitoring probes.
With most UIM environments, secondary (or subordinate) hubs already have queues configured to pass QOS_MESSAGE and QOS_DEFINITION
messages to the data_engine probe on the primary hub. Verify that QOS_BASELINE messages were also added to the Subject field (on the Edit
Queue screen) so these messages are also passed to the data_engine probe on the primary hub. Otherwise, baseline data points for QoS
metrics are not generated.
Review the following example for instructions on adding QOS_BASELINE to the Subject field so these messages are passed to data_engine.
Example: Configure an Existing Queue
This example shows how to configure an existing hub queue in Infrastructure Manager.
Follow These Steps:
1. In Infrastructure Manager, double-click the hub probe to open its GUI.
2. In the Hub configuration GUI, under the Queues tab, select the queue that forwards messages with QOS_MESSAGE and
QOS_DEFINITION subjects:
3. Edit this queue by appending the additional subject ",QOS_BASELINE"
4. Click OK and then Yes when prompted to enable changes. The hub will refresh its configuration (perform a soft restart).
More Information:
See Configuring Queues and Tunnels for details about setting up queues.
See baseline_engine Release Notes for details about which versions of baseline_engine supports various versions of the ppm
probe.
v2.6 baseline_engine Configuration
This article explains the commands you use to set baselines or thresholds for probes, and the procedure to configure the amount of time, in
weeks, to retain the baseline data.
Create Baselines and Thresholds for Probes Without the Web-based GUI
Note: Both commands should be run from <baseline_engine_dir>.
Set up Baselines
java -cp ".;lib/*" com.nimsoft.threshold.cmd.BaselineSetter -user <user> -pwd

<password> -probe <path> -o <add | delete> [-f <file name>| -id <merticId>] [-native]
[-queue]
The options are:

user (required): The user name
pwd (required): The password
probe (required): The path to the baseline_engine probe, for example /domain/hub/robot/baseline_engine.
o (required): The operation add or delete.
f: The name of file containing the baseline definitions to load. This file should be in the same format as the baseline.cache file.
id (required): The metric ID of the QoS to baseline
native: Baseline the QoS using the probe's native sample frequency.
Set up Thresholds

The options are:

user (required): The user name
pwd (required): The password
probe (required): The path to the baseline_engine probe, for example /domain/hub/robot/baseline_engine.
threshType (required): The type of threshold, which is either static or dynamic.
type (required): The algorithm used to calculate the variance from the calculated baseline. Options are:
L: less than
G: greater than
EQ: is equal
NE: is not equal
operator1 <operator>: operator1 takes precedence over <operator>, information alarm threshold operator
operator2 <operator>: operator2 takes precedence over <operator>, warning alarm threshold operator
operator3 <operator>: operator3 takes precedence over <operator>, minor alarm threshold operator
operator4 <operator>: operator4 takes precedence over <operator>, major alarm threshold operator
operator5 <operator>: operator5 takes precedence over <operator>, critical alarm threshold operator

subsysId (required): The subsystem ID of the QoS for which the thresholds are being defined. Only one subsystem ID can be specified
using the subsysId option.
${operator} - The operator (>, , <, , =, or !=) for the critical level of the alarm.

Set up Thresholds Using a File

To set up thresholds for probes by using a file, use the following command:

<password> -probe <probepath> -file <filename> [-queue]
The options are:

user: The user name
pwd: The password
file: The name of file containing the threshold definitions to load. This file should be in the same format as the thresholds.cache file.
Change the Baseline Retention Period

The default baseline retention period is four weeks. You can adjust the number of weeks used in the retention period to better match the use
patterns for your environment.
Note: The baseline retention period can be set to a minimum of three weeks, or a maximum of twelve weeks. If you set the retention
period to an unsupported value, the baseline_engine probe will use the nearest supported value. For example, setting the retention
period to fifteen will result in an actual retention period of twelve weeks.
Follow these steps:

1. In the Raw Configure menu of baseline_engine, click on the Setup folder.
2. Select the retentionPeriod key and then click the Edit Key.
3. On the Edit Key menu, change the value to the desired number of weeks (3 through 12). The key is updated with the new value.
4. Click Apply.
v2.6 baseline_engine Raw Configuration

This article describes the configuration options available through the Raw Configuration menu. There is no stand-alone GUI configuration for the
baseline_engine probe. The navigation pane organizes configuration into three folders:
The Setup Folder

The Startup Folder
The Threshold Folder
The Setup Folder

Navigation: Setup
The setup folder contains the following configurable key-values:
logfile
Defines the log file name
loglevel
Sets the overall root log level (from 0 (minimum) to 5(maximum))
scriptloglevel
Sets the log level for messages tracking operation of the scripts that perform the baseline calculations
messagelimitlog
Sets the log level for messages that show if the maxmetrics limit is exceeded or not. This is essentially a binary setting, with level=1
denoting "off" and level=>2 equivalent to "on." If level=2, then an error message is logged to the main log when maxmetrics is exceeded.
To see the metrics that are not processed/baselined, view the skipped_message.log file.
performance
Switches a lightweight performance monitor process on (true) or off (false). The performance monitor checks every minute on the rate of
execution of queuing and calculation, etc. and logs this information to performance.log.
isNative
Provides the ability to override the default baseline calculation interval for individual probes. By default, isNative is set to false, meaning
baseline_engine computes a baseline for probes (that use a baseline) every hour. When isNative is set to True, instead of computing a
baseline every hour, a baseline is computed at the probe's native frequency.
projections
By default, this key-value is set to True and baselines are projected one week in the future to ensure that dynamic threshold alarms are
consistent with the baseline. When this setting is True, the baseline_engine adjusts the timestamps of the baselines to one week in the
future and sends duplicate baselines with unadjusted timestamps. This allows dynamic threshold configurations to be evaluated
immediately without having to wait one week. The duplicate baselines are only generated for one week. If you do not want to use this
projection behavior, change this setting to False before the baseline_engine calculates any baselines.
Important! If projectBaselines is set to True and you have already configured baselines, do not change this setting back to Fal
se. This causes the system to have two baselines for a period of one week in the future.
Important! Do not delete the projectionEnabled file stored in the root baseline_engine directory. Otherwise, your baseline
timestamps will be affected.
retentionPeriod
Sets the amount of time (in weeks) for the baseline to retain monitoring data. The range is between 3 and 12 weeks. The default is 4
weeks.
messagelimitlog
Sets the log level for the message limit sub-process.
The Startup Folder

Navigation: startup > opt
The opt folder contains the following key-values:
java_mem_init
Sets the initial Java heap size.
java_mem_max
Sets the maximum Java heap size.
java_opts
Used during JVM startup.

Navigation: threshold
The threshold folder contains the following configurable key-values:
useprevioushour
At startup, use the average for the previous hour.
alarmcheckers
Sets the amount of threads used to check alarms.


<password> -probe <path> -f <file name> [-queue]
The options are:

user: The user name
pwd: The password
f: The name of file containing the threshold definitions to load. This file should be in the same format as the thresholds.cache file.

The options are:

user: The user name
pwd: The password

type: The algorithm used to calculate the variance from the calculated baseline. Options are:
L: less than
G: greater than
EQ: is equal
NE: is not equal

subsysId option.
${operator} - The operator (>, , <, , ==, or !=) for the critical level of the alarm.


Follow these steps:

2. Select the retentionPeriod key and then click the Edit Key.
3. On the Edit Key menu, change the value to the desired number of weeks (3 through 12). The key is updated with the new value.
4. Click Apply.

baseline_engine probe. The navigation pane organizes configuration into three folders:
The Setup Folder

The Startup Folder
The Setup Folder

Navigation: Setup
logfile
loglevel
scriptloglevel
messagelimitlog
performance
isNative
Sets the ability to override the default baseline calculation interval for individual probes.
projections
retentionPeriod
weeks.
messagelimitlog
Sets the log level for the message limit sub-process.
The Startup Folder

java_mem_init
java_mem_max
java_opts

useprevioushour
alarmcheckers

Contents
java -cp ".;lib/*" com.nimsoft.threshold.cmd.BaselineSetter -user <user

> -pwd <password> -probe <path> -o <add | delete> [-f <file name> | -id
<metricId> ] [-queue]
The options are:

user: The user name
pwd: The password
java -cp ".;lib/*" com.nimsoft.threshold.cmd.ThresholdSetter -user <use

r> -pwd <password> -probe <path> -id <metric id> -threshType <static |
dynamic> -type <percent | scalar | stdev> -o <operator> [-level1 <value
> | -level2 <value> | -level3 <value> | -level4 <value> | -level5 <valu
e>] -subsysId <subsysId> [-queue]
The options are:

user: The user name
pwd: The password
L: less than
G: greater than

subsysId option.

Follow these steps:

2. Select the retentionPeriod key and click Edit Key.
3. On the Edit Key menu, change the value to the desired number of weeks (3 through 12).
The key is updated with the new value.
4. Click Apply.

baseline_engine probe. The navigation pane organizes configuration into three folders: Setup, Startup, and Threshold.
Contents
The Setup Folder

The Startup Folder
The Setup Folder

Navigation: Setup
logfile
loglevel
scriptloglevel
messagelimitlog
performance
isNative
projectBaselines
retentionPeriod
weeks.
messagestorelog
Sets the log level for the messagestore sub-process
demarshalpdslog
Sets the log level for the process that disassembles PDS messages from the bus
metricrunner
Sets the log level for the metricrunner process
metricfactory
Sets the log level for operation of the metricfactory (limited to whether or not the metricfactory successfully started)
metriccaluculator
Sets the logging level for the metric calculator, which executes scripts that perform the baseline calculations.
predictiveAlarmSubject
Sets the alarm subject for a Time To Threshold alarm. The baseline_engine probe uses this subject setting to assist in routing predictive
alarms. If this setting is alarm, the baseline_engine probe sends predictive alarms properly. If this parameter is set to a value other than
alarm, the baseline_engine will be unable to properly route predictive alarms to an administrator.
The Startup Folder

java_mem_init
java_mem_max
java_opts

useprevioushour
alarmcheckers

This article provides the commands you use to set baselines or thresholds for probes, and the procedure to configure the amount of time, in
Computing Baselines
java -cp ".;lib/*" com.nimsoft.threshold.cmd.BaselineSetter -user <user

> -pwd <password> -probe <path> -o <add | delete> [-f <file name> | -id
<metricId> ] [-queue]
The options are:

user: The user name
pwd: The password
java -cp ".;lib/*" com.nimsoft.threshold.cmd.ThresholdSetter -user <use

r> -pwd <password> -probe <path> -id <metric id> -threshType <static |
dynamic> -type <percent | scalar | stdev> -o <operator> [-level1 <value
> | -level2 <value> | -level3 <value> | -level4 <value> | -level5 <valu
e>] -subsysId <subsysId> [-queue]
The options are:

user: The user name
pwd: The password
Static: No alarms are sent until sufficient alarms meeting the time requirements have exceeded the threshold.
one of the following algorithms:
L: less than
G: greater than
subsysId option.

Follow these steps:

1. In the Raw Configure menu of baseline_engine, click on the setup folder.
2. Select the retentionPeriod key and click the Edit Key button.
3. The Edit Key menu opens.
4. Change the value to the desired number of weeks (3 through 12).
5. Click Apply.
A baseline will now be established using the new retention period.
Computing Baselines
Configuring baselines and thresholds for probes is a two-step process.
1. Configure baselines and thresholds for probes without the web-based GUI or you use Infrastructure Manager.
2. Indicate that you want a baseline computed for a QoS monitoring probe by selecting the Compute Baseline and Publish Data options in
the probe's GUI. See Set Thresholds for more information.

This article describes the configuration information and options available through the Raw Configuration menu. There is no stand-alone GUI
configuration for the baseline_engine probe. The navigation pane organizes configuration into three folders: Setup, Startup, and Threshold.
The Setup Folder

The Startup Folder
The Setup Folder
Navigation: Setup
logfile
loglevel
scriptloglevel
messagelimitlog
performance
isNative
projection
For new installations of the baseline_engine v2.3 probe, this key-value is set to True by default and baselines are projected one week in
the future to ensure that dynamic threshold alarms are consistent with the baseline. When this setting is True, the baseline_engine
adjusts the timestamps of the baselines to one week in the future and sends duplicate baselines with unadjusted timestamps. This allows
dynamic threshold configurations to be evaluated immediately without having to wait one week. The duplicate baselines are only
generated for one week. If you do not want to use this projection behavior, change this setting to False before the baseline_engine
calculates any baselines.
For baseline_engine v2.2 and earlier, the projection key is set to False by default.
Note: If you install baseline_engine v2.3 on a hub where a previous version of baseline_engine was running, this key value defaults to
False.
Important! If the projection key is set to True and you have already configured baselines, do not change this setting back to False.
This causes the system to have two baselines for a period of one week in the future.
Important! Do not delete the projectionEnabled file stored in the root baseline_engine directory. Otherwise, your baseline timestamps
will be affected.
retentionPeriod
weeks.
messagestorelog
Sets the log level for the messagestore sub-process
demarshalpdslog
Sets the log level for the process that disassembles PDS messages from the bus
metricrunner
Sets the log level for the metricrunner process
metricfactory
Sets the log level for operation of the metricfactory (limited to whether or not the metricfactory successfully started)
metriccaluculator
Sets the logging level for the metric calculator, which executes scripts that perform the baseline calculations.
predictiveAlarmSubject
Sets the alarm subject for a Time To Threshold alarm. The baseline_engine probe uses this subject setting to assist in routing predictive
alarms. If this setting is alarm, the baseline_engine probe sends predictive alarms properly. If this parameter is set to a value other than
alarm, the baseline_engine will be unable to properly route predictive alarms to an administrator.
The Startup Folder

java_mem_init
java_mem_max
java_opts

useprevioushour
alarmcheckers
baseline_engine Best Practices

The baseline_engine probe performs most tasks with little or no interaction from the administrator. However there are some configurations that
can improve performance.
Baseline_engine probe location
Deploy the baseline_engine probe to secondary or sub-hubs to distribute processing. For more information, see Recommended Multiple
(tiered) Probe Deployment.
Memory usage
The following memory allocation is recommended:
Number of Metrics to baseline
Memory Allocation
Disk Allocation
>10,000 metrics (default configuration)
1 GB
100 MB
10,000 to 50,000
1.5 GB
200 MB
50,000 to 100,000
2 GB
400 MB
You can estimate the current memory usage for the baseline_engine probe by checking the performance log. Find the entry JVM Memory
currently allocated: and add 40% to this figure. If required you can change the memory allocation using the jav_mem_max setting in The Startup
Folder.
billing
The billing probe collects usage data from all the usage_metering probes in the environment and performs the calculations required to generate a
billing report.
After a calculation completes, the probe creates a billable items report, which is stored locally and in the database. If the webgtw probe is
enabled, webgtw automatically transfers the report to CA Sales. You also can export a report that contains summary and detail information.
This article provides an introduction to:
Device-Based Usage Billing

Billing Subscriptions
Billing Reports
More information:
For information on the automated billing process, see the Set Up Automated Usage Metering and Billing article in the Mana
ging section of the CA Unified Infrastructure Management wiki space.
See billing Release Notes
Device-Based Usage Billing

In a network environment, a single device can be monitored by many probes simultaneously. In device-based metering, usage items are
measured on per device. A unique device reference is defined as the combination of a device's origin specification and a its fully qualified domain
name (fqdn) or IP.
For each usage_metering probe in the environment, the billing probe collects device usage item information, analyzes it, maps it for subscriptions
and performs the billing calculations resulting in billable items. A billable item consists of a device for which a specific billing pack is assigned. The
individual billable items from each usage_metering probe data calculation are aggregated to generate a final, comprehensive billing report
containing summary and detail information.
Billing Subscriptions
Prior to billing v8.0, each customer was assigned a billing subscription file that needed to reside with the billing probe. Once the subscription was
installed, a billing calculation could be performed to generate billing reports. With billing v.8.0 and later, subscription files are included with the
probe and do not need to be installed separately.
Billing Reports
After a calculation completes, a billable items report containing summary and detail information can be exported from the Calculations tab. The
report is exported in HTML format.
The generated HTML report can be loaded into Excel to review the resulting data in a spreadsheet. With the data loaded in Excel, advanced
features such as filtering and pivot tables can be used to view sections of the data in which one is particularly interested.
CA Sales Operations requires that customers generate and send their billing reports each month. Billing reports also can be generated on any
specific time interval for internal purposes.
billing Prerequisites
For the billing probe to work properly, the following prerequisites must be met:
All usage_metering probes in the environment must be the same release version as the billing probe.
An instance of usage_metering must reside on the same robot as the billing probe and must be configured as the Primary instance type.
See the usage_metering documentation for clarification on primary and secondary instances.
The probes must be deployed to a robot that is version 5.70 or higher and that has java v1.6.2 or higher installed on the system.
The subscription must been successfully configured in order for the billing probe to perform a calculation.
Deploy the Billing Probe

To deploy the billing probe from your local archive, follow these steps.
1. Drop the package from your local archive onto the targeted robot. Only one billing probe should reside in the UIM environment.
Note: The billing probe and the primary instance of usage_metering must be installed on the same robot, They are usually
deployed to the primary hub. For illustrations and additional information, see the section on deployment scenarios in the usage
1.
_metering probe documentation.
billing Versions 8.0 - 8.2

This section contains documentation for the following versions of the billing probe.
v8.2 billing IM Configuration

This article explains how to configure billing v8.2 in Infrastructure Manager.
See the billing Release Notes for for compatibility. When applicable, the usage_metering and billing probe installed to the environment
should be the same versions. If the same versions do not exist in the web archive, then the latest version of usage_metering should be
installed.
1. Open Infrastructure Manager and navigate to the billing probe.

2. Double-click the probe to open the probe configuration GUI. The GUI provides three tabs:
Settings allows you to set the log parameters for the billing probe.
Subscription allows you to configure your subscription.
Calculations shows the current list of calculations for the active subscriptions and allows you to export the calculations to a read-only
format for easy viewing.
3. Once the probe is configured, click Apply to restart the probe and apply the changes.
The following sections describe the configuration tasks.
Modify Logging Parameters

Configure a Subscription
Configure an Offline Subscription File
Check Billing Status
Export a Subscription File
Calculate Billing
Configure Additional Reporting Detail

The Settings tab allows you to modify the logging parameters for the probe:
Log level sets the level of logging (default is 2). CA recommends logging as little as possible during normal operation to minimize the
size of log file.
Log Size sets the size of the log file (default is 1000 KB).
The Subscription tab allows you to configure your subscription file.
This tab lets you perform the following actions.

Follow these steps:

1. In the Offline Billing section, click Configure Offline Subscription File.
2. Navigate to nms_offline_setup.subscription.
NOTE: If this file currently exists in a probes/service/billing/ directory, then copy it to another location (such as your desktop)
and select from this non-billing probe location. The configuration will not succeed if selecting the file from the billing probe
directory. Click the OK button.
3. Click Import. You know the import succeeded when:
A message states that the probe has been successfully configured.
The Subscription ID field is populated with an encrypted string of characters that uniquely identify a billing report for a specific
customer.
Check the Status section for the following:

Connected with Nimsoft displays the online status of the billing probe connection to Billing Server.
Subscription displays the number of subscriptions ready and active for use by the billing probe.
Subscription Status displays the details of the active subscriptions.
Click Export Subscription File to export the subscription to a read-only Excel file for viewing purposes. No changes can be made and stored
back into the billing probe.
Calculate Billing
To create and view billing calculations.
1.
1. Navigate to Calculations in the billing probe configuration GUI.

2. Under Billing Calculation, enter a four-digit year and numerical month (1 for January, 2 for February, etc.) for the billing report of
interest.
3. Click Run. The billing calculation is performed in the background. Progress can be viewed in the LogViewer, which lets you view billing.lo
g.
4. The Results section shows the first and last day of the report, as well as the active subscription. Press the Refresh to recalculate.
To export an HTML calculation report containing summary and detail information:
Click Export. This report must be submitted to CA Sales Operations on a monthly basis.

Additional reporting detail can be configured through Raw Configure. Additional columns (shown below highlighted in yellow) are added to the
report output. This data is useful when analyzing the report in a spreadsheet application such as Excel.
To add these additional columns, modify the billing probe's config file setup section. The setup section follows this format:
<setup>
...
http_timeout_in_millis = 15000
nimrequest_timeout_in_mins = 15
report_generate_full_details_flag = false
</setup>
To configure additional reporting detail through Raw Configure, follow these steps:
1. Shift + right-click the billing probe and select Raw Configure.
2. Navigate to the setup/report_generate_full_details_flag section.
3. Edit the following key-value pair:
setup/report_generate_full_details_flag=true
4. Save the changes.

This article explains how to configure billing v8.0 in Infrastructure Manager.
1. Open Infrastructure Manager and navigate to the billing probe.
2. Double-click the probe to open the probe configuration GUI. The GUI provides three tabs:
Settings allows you to set the log parameters for the billing probe.
Subscription allows you to configure your subscription.
Calculations shows the current list of calculations for the active subscriptions and allows you to export the calculations to a read-only
format for easy viewing.
3. Once the probe is configured, click Apply to restart the probe and apply the changes.
The following sections describe the configuration tasks.

Calculate Billing

The Settings tab allows you to modify the logging parameters for the probe:
Log level sets the level of logging (default is 2). CA recommends logging as little as possible during normal operation to minimize the
size of log file.
Log Size sets the size of the log file (default is 1000 KB).
The Subscription tab allows you to configure your subscription file.
This tab lets you perform the following actions.

Follow these steps:
1. In the Offline Billing section, click Configure Offline Subscription File.

2. Navigate to nms_offline_setup.subscription.
NOTE: If this file currently exists in a probes/service/billing/ directory, then copy it to another location (such as your desktop)
and select from this non-billing probe location. The configuration will not succeed if selecting the file from the billing probe
directory. Click the OK button.
3. Click Import. You know the import succeeded when:
A message states that the probe has been successfully configured.
The Subscription ID field is populated with an encrypted string of characters that uniquely identify a billing report for a specific
customer.
Check the Status section for the following:

Connected with Nimsoft displays the online status of the billing probe connection to Billing Server.
Subscription displays the number of subscriptions ready and active for use by the billing probe.
Subscription Status displays the details of the active subscriptions.
Click Export Subscription File to export the subscription to a read-only Excel file for viewing purposes. No changes can be made and stored
back into the billing probe.
Calculate Billing
To create and view billing calculations.
1. Navigate to Calculations in the billing probe configuration GUI.
2. Under Billing Calculation, enter a four-digit year and numerical month (1 for January, 2 for February, etc.) for the billing report of
interest.
3. Click Run. The billing calculation is performed in the background. Progress can be viewed in the LogViewer, which lets you view billing.l
og.
4. The Results section shows the first and last day of the report, as well as the active subscription. Press the Refresh to recalculate.
To export an HTML calculation report containing summary and detail information:
Click Export. This report must be submitted to CA Sales Operations on a monthly basis.

Additional reporting detail can be configured through Raw Configure. Additional columns (shown below highlighted in yellow) are added to the
report output. This data is useful when analyzing the report in a spreadsheet application such as Excel.
To add these additional columns, modify the billing probe's config file setup section. The setup section follows this format:
<setup>
...
http_timeout_in_millis = 15000
nimrequest_timeout_in_mins = 15
report_generate_full_details_flag = false
</setup>
To configure additional reporting detail through Raw Configure, follow these steps:
1. Shift + right-click the billing probe and select Raw Configure.
2. Navigate to the setup/report_generate_full_details_flag section.
3. Edit the following key-value pair:
setup/report_generate_full_details_flag=true
4. Save the changes.
capman_da (Capacity Management Data Adapter)

The capman_da probe is the interface between CA Capacity Command Center (CCC) and CA UIM. It pushes metric and configuration data
collected from the UIM probes to the Data Manager thrift service on an hourly schedule. The data is stored in the CA CCC database pre-staging
tables. To make this data available for capacity analysis, you configure the corresponding UIM data adapters in Data Manager, and schedule the
staging and migration.
The capman_da probe is deployed to the CA UIM primary hub, and requires with the nisapi_wasp package included in the CA UIM installation
(r8.1 and later).
capman_da AC Configuration
This article describes how to configure the capman_da probe.
Configure the capman_da Probe
(Optional) Collect Metrics
(Optional) vmax Probe QoS Mappings
(Optional) Configure the Queue List
Verify that the required hardware and software is available, and any installation consideration is met before you configure the probe. For more
information, see the capman_da Release Notes.
Configure the capman_da Probe

1. In Admin Console, open the capman_da probe in Raw Configure.
2. Expand the setup section to verify or make changes to the following parameters:
a. ccc_connection
i. hosts
The destination host IP or DNS address of the Data Manager that receives the data files. The probe supports data collection with
multiple Data Managers. Separate each value with a comma and no spaces.
ii. thriftports
The destination port number of the Data Manager. By default, the port is set to 8082.
iii. thrift_is_secure
Manages the SSL communication to the Data Manager. Set to true to enable secure communication.
If thrift_is_secure is set to true, the parameters thrift_truststores, thrift_truststore_passwords, and thrift_client_ti

meouts are required.
iv. thrift_truststores
The complete path to the trust store that contains the certificate used for SSL communication.
v. thrift_trustore_passwords
The encrypted password string for the trust store that contains the certificate used for SSL communication. You must use the CCC
EncryptPassword utility to generate the encrypted password string.
vi. thrift_client_timeouts
The timeout value, in milliseconds, for connecting to the thrift server over secure communication.
b. data_output_setup
i. cleanup_archive_interval_in_days
The number of days that an archived file is saved before it is deleted from the ARCHIVE folder. Only files with a date prior to the
number of days specified are deleted. The default interval is set at three days. A minimum of one day is required.
ii.
b.
ii. configuration_data_interval_time
The time when the resource configuration data is gathered from the source probes. The default time is set to 11:00 p.m.
iii. output_folder
A target folder, for example DM Data directory, that is automatically generated by the system, and comprises configuration and
metric data. This folder includes system-generated DATA and ARCHIVE sub-folders that contain probe-specific folders. Once the
data files are published successfully to the Data Manager, they are automatically moved to the ARCHIVE folder. The default folder
path is C:/CapMan_DA_Data/.
c. nis_api_connection
i. host
The host on which the nisapi_wasp package is deployed.
ii. port
The port for accessing the Web service. By default, the port is set to 8080.
3. Select the startup section. Verify or make changes to the options for JVM memory, language, and locale. The default is set at -Xms32m
-Xmx512m -Duser.language=en -Duser.country=US.
4. Expand the advanced_setup section to verify or make changes to the following parameters:
a. Select advanced_setup.
i. log_level
The log_level parameter maps to INFO, and the configurable range is 0 to 5.
ii. number_of_configuration_data_threads
Sets the size of the thread pool that processes the configuration data at the scheduled time. Set the size according to the number
of cores and processors. The acceptable range is 10 to 50. If you set the value to less than 10, the system uses 10. If you set the
value higher than 50, the system uses 50.
iii. inventory_data_collection
If set to true, inventory data is collected.
iv. performance_data_collection
If set to true, performance data is collected.
v. performance_data_multithreading
If set to true, multi-thread processing of performance data is enabled.
vi. maximum_csv_file_sie_in_mb
Sets the maximum CSV file size before it rolls over to the next file.
b. Select data_queue_configuration. The probe uses a data queue to temporarily store the relevant QoS messages before they can be
processed. The following properties are related to configuring this queue.
i. data_queue_batch_size
The number of records that are pulled from the data queue for bulk processing. The default batch size is 1,000 records. A
minimum of 100 records is required.
ii. data_queue_capacity
The maximum number of elements held in the queue before being dropped. The default queue size 1,000,000 elements. A
minimum of 10,000 elements is required.
c. Select process_sleep_configuration.
i. cleanup_archive_thread_sleep_time_in_minutes
The amount of time, in minutes, the cleanup thread waits between each time it checks for old archive files to be deleted. The
default time is set at 30 minutes. A minimum of one minute is required.
d. Select thrift_upload_configuration
i. enable_thrift_upload
If set to true, data is uploaded to the Data Manager.
ii. execution_interval_in_minutes
Sets when the probe restarts the upload after the previous upload completes. The minimum time that can be set is one minute.
iii. first_start_delay_in_minutes
Sets when the probe starts the upload process for the first time. The default is 60 minutes. The minimum time is one minute.
The following settings are recommended:
In large environments (over 8,000 QoS messages/second), configure 120 minutes.
In medium environments (4,000 to 8,000 QoS messages/second), configure 60 minutes.
In small environments (1,000 to 4,000 QoS messages/second), configure 30 minutes.
iv. maximum_number_of_threads
Sets the maximum number of threads for thrift data upload. The acceptable range is 1 to 50 threads.
In large environments (over 8,000 QoS messages/second), the recommended setting is 10 threads.
e. Select inventory_data_configuration.
i. dynamic_multi_threading
If set to true, dynamic thread pooling is used for inventory data processing.
ii. fixed_thread_pool_size
Sets the thread pool size to use if dynamic_multi_threading is disabled. Acceptable values are 1 to 50 threads.
iii.
iii. maximum_dynaic_thread_pool_size
Sets the maximum number of threads in a thread pool if dynamic_multi_threading is enabled.
In large environments (over 8,000 QoS messages/second), configure 50 threads.
In medium environments (4,000 to 8,000 QoS messages/second), configure 30 threads.
In small environments (1,000 to 4,000 QoS messages/second), leave the default value of 20 threads.
f. nis_api_configuration
i. enable_metric_api_call
If set to true, the system makes a call to the metric API endpoint of the nisapi_wasp web service.
ii. loss_of_data_at_threshold
Manages data when the threshold is reached. If set to true, data collection stops when the threshold is met to prevent the probe
from running out of memory.
iii. maximum_number_of_metrics_per_metric_api_call
Sets the maximum number of metrics used in a single call to the nisapi_wasp API endpoint. The acceptable range is 1 to 1000
metrics.
iv. maximum_number_of_metrics_per_metric_definition_call
Sets the maximum number of metrics used in a single call to the nisapi_wasp API definition. The acceptable range is 1 to 1000
metrics.
v. metric_api_data_queue_threshold_percentage
Sets the threshold of the data queue size for metric API data calls. The acceptable range is 10 to 100 percent.
vi. metric_api_maximum_thread_pool_size
Sets the maximum number of possible threads used for metric API endpoint calls. The acceptable range is 1 to 50 threads.
vii. metric_definition_api_maximum_thread_pool_size
Sets the maximum number of possible threads used for metric definition endpoint calls. The acceptable range is 1 to 50 threads.
In large environments (over 8,000 QoS messages/second), configure 50 threads.
In medium environments (4,000 to 8,000 QoS messages/second), configure 25 threads.
In small environments (1,000 to 4,000 QoS messages/second), leave the default value of 10 threads.
viii. nis_api_client_object_pool_size
Sets the number of nisapi_wasp clients created in an object pool. The acceptable range is 1 to 60 clients.
In large environments (over 8,000 QoS messages/second), configure 60 clients.
In medium environments (4,000 to 8,000 QoS messages/second), configure 35 clients.
In small environments (1,000 to 4,000 QoS messages/second), leave the default value of 20 clients.
ix. use_collection_xp_endpoint
If set to true, the collection XP endpoint is used instead of the collection endpoint.
5. Select the generic_metric_mapping section to list the default metrics mappings that are used by CA Data Manager to collect the
metrics.
(Optional) Collect Metrics

The vmax probe metric families and metrics include the option to enable or disable collecting metrics, using the collection_enabled key. By
default, this key is set to true to collect metrics. By default, the collection setting option for all other probes is available only at the probe level, and
the metric family and metric settings are set to true.
To add the collection option to metric families and metrics that are not included in the vmax probe, add the collection_enabled key.
Follow these steps:
1. Navigate to the metric family or metrics configuration window, and select Add key.
2. Enter collection_enabled. Use lower case.
3. Click Add. The new key appears in the configuration window.
4. Click Apply.
For all probes, if the probe-level collection setting is set to false, no metrics are collected.
(Optional) vmax Probe QoS Mappings
At the vmax metric level, the parameter matching_metric_type is set to 5:1. The additional_match key lists the out-of-box QoS mapping
parameters.
Since the matching_metric_type parameter is set to 5:1, you must enable the vmax probe monitors using the QoS mapping parameters.
(Optional) Configure the Queue List

You can configure a permanent queue for improved QoS messaging performance (CA UIM 8.2 and later). Only CA UIM nisapi_wasp 8.21
supports this permanent queue function. By default, if no queue exists when the capman_da probe is started, a temporary queue is used. After
you create a permanent queue, ensure that you restart the capman_da probe for the permanent queue to be used.
Follow these steps:
1. In Admin Console, select the icon next to the hub probe, and select Configure.
2. In the Probe Configuration navigation tree, select Queue List.
3. In the Queue List Configuration window, select New.
4. Configure the following parameters:
Queue Name: capman_da
Active: Click in the box to enable or disable the queue.
Type: Select attach from the drop-down list.
Subject: QOS_MESSAGE
Bulk Size: <default>
If you disable the capman_da probe, it is recommended that you disable the queue to avoid accumulating messages.
casdgtw (CA ServiceDesk Gateway)

The casdgtw probe is a gateway between the CA Unified Infrastructure Management (CA UIM) and the CA Service Desk. The probe generates an
incident ticket in the CA Service Desk that is based on the UIM alarm. Generating an incident helps the service desk user to take corrective
actions for resolving the issue. The incident is generated when an alarm is assigned to the designated CASD user. The probe uses this alarm as
a Service Desk Call Request and generates the ticket.
The probe supports the following functionality:
Tests the network access to the CA Service Desk (CASD) application.
Tests the login sessions on the CASD application.
Create an incident in the CASD application that is based on UIM alarms.
Updates incident activity logs in the CASD application that are based on the UIM alarm updates.
Close the incident when the corresponding alarm is acknowledged.
Acknowledge the alarm when the corresponding incident is closed in the CASD application.
More information:
casdgtw (CA ServiceDesk Gateway) Release Notes
v2.4 casdgtw AC GUI Reference
Contents
casdgtw Node
Field Mapping Node
Configure a Node
Add Field Mapping Details
Delete Field Mapping Details
Advanced Configuration Settings
Enable Offline Management
Configure HTTPS CA Service Desk URL
Configure the subscribe_alarm_closure Key
Configure the subscribe_alarm_updates Key
The CA ServiceDesk Gateway probe is configured by defining the URL of the CASD application with the user account details for generating
incidents by the probe. You can also specify the UIM user to whom the alarm is assigned for creating the incident. The configuration details
specify the field mapping details for storing relevant alarm information in the incident.
casdgtw Node
The casdgtw node contains sections for enabling the communication between the probe and the CASD application.
This section contains configuration details specific to the CA ServiceDesk Gateway probe.
Navigation: casdgtw
casdgtw > Probe Information
This section provides information about the probe name, probe version, start time, and the probe vendor.
casdgtw > Server Configuration
This section lets you configure the URL of the CASD application and user credentials for the authorization purpose.
Server URL: defines the WSDL URL of the CA Service Desk application for retrieving the description of the Web Service. This Web
Service exposes methods for performing necessary operations on the CA Service Desk application. For example, http://<IP/Instance
Name>/axis/services/USD_R11_Webservice?WSDL
Username: defines the user name for logging in to the CA Service Desk application.
Password: defines the password for logging in to the CA Service Desk application.
Note: Use the Test option from the Actions drop-down list for verifying the connectivity between the probe and the CASD
application.
casdgtw > General Configuration
This section lets you configure the compatibility and connection settings between the probe and the CASD application.
Log Level: sets the level of details to be included in the log file.
Default: 0 - Fatal
NAS Address: defines the address of the local Alarm Server (NAS) in the /<Domain>/<Hub>/<Robot>/nas format where the probe is
deployed. The address is case-sensitive.
Service Desk User: defines the username of the UIM user. Whenever you assign an alarm to the given user, the probe initiates the
request to generate a new incident.
Service Desk Version: specifies the version of the CA Service Desk application, which the probe is connecting.
Default: v12.1
Check Interval (Minutes): defines the time interval (in minutes) after which the probe checks for closed incidents in the CA Service
Desk application for clearing the corresponding alarms. The recommended value is 5 minutes.
Default: 30
Date Format: specifies the Date and Time format code for storing the time value. This field ensures that the probe and the CA Service
Desk application are using the same Date and Time format.
Default: MM/dd/yyyy HH:mm:ss
Timezone: specifies the time zone code for storing the time value. The time zone must be same as the time zone of the CA Service
Desk application. This field ensures that the probe and the CA Service Desk application are using the same time zone.
Default: Asia/Calcutta
Incident Id Custom Field: specifies the custom field of the alarm (custom_1 to custom_5) to save the incident id of the corresponding
incident.
Default: custom_1
Owning System: specifies the way of updating the incident and alarm status. Select one of the following options:
Nimsoft Monitor: closes the CASD incident, when the alarm is acknowledged.
Service Desk: acknowledges the alarm when the CASD incident is closed.
Both: performs the bidirectional updates.
Default: Service Desk
Closed Ticket Status: specifies the CASD incident status, which is set when the corresponding alarm is acknowledged.
Enable Incident Activity Logging: updates the activity log (creating, updating, and closing the incident) in the CASD incident that is
based on the corresponding alarm in UIM.
casdgtw > Configuration Item Status
The Configuration Item Status section lets you exclude the configuration items status from displaying in a CASD incident. This list of
configuration item status represents retired or blocked configuration items. If the CASD incident is having the selected status in the Confi
guration Item list, the respective status is not displayed in the incident.
Note: The list of available Configuration Item Status is populated only after configuring the server details.
casdgtw > Ticket Assignment

This section is used to configure the assignation of the incident to the respective CASD user, when the incident is generated and
updated.
Initial Assignment Group: defines the CASD group name to which the incident is assigned, when the incident is created. Provide the
group name and not the UUID of the group. If the given group name does not exist on CASD or the field is left blank, the incident is
assigned to the login user.
Enable Reassignment: lets you reassign the incident when the corresponding alarm updates the incident information.
Enable Severity: lets you reassign the incident when the alarm severity is updated.
Alarm Severity: specifies the alarm severity condition for reassigning the incident.
Reassignment Group: defines the CASD group name to which the incident is reassigned.
casdgtw > Edit Alarm Severity
This section is used for mapping the alarm severity with the Severity, Urgency, or Priority fields of the CASD incident. However, you
can map only one of these fields at a time. The Severity, Urgency, or Priority fields are also depends on the CASD application version.
Alarm Severity: specifies the incident field (Priority, Severity, or Urgency) for mapping with the alarm severity.
Note: The options available in this field depends on the Service Desk Version field of the General Configuration section.
Clear: specifies the Priority, Severity, or Urgency of the incident when the alarm severity is Clear.
Information: specifies the Priority, Severity, or Urgency of the incident when the alarm severity is Information.
Warning: specifies the Priority, Severity, or Urgency of the incident when the alarm severity is Warning.
Minor: specifies the Priority, Severity, or Urgency of the incident when the alarm severity is Minor.
Major: specifies the Priority, Severity, or Urgency of the incident when the alarm severity is Major.
Critical: specifies the Priority, Severity, or Urgency of the incident when the alarm severity is Critical.
Field Mapping Node

The Field Mapping node lets you map the CA Service Desk fields with one of the following values:
NMS Alarm Field: maps value of the corresponding field of the UIM alarm.
Custom Value: maps a custom Value, which is a combination of one or more variables representing the Alarm fields. For example, the De
scription field of the CASD is mapped with ${Message} because the current value ${value} is exceeding the threshold value
${threshold}.
Default Value: Maps a fixed value.
Navigation: casdgtw > Field Mapping
Set or modify the following values that are based on your requirement:
Field Mapping > Field Mapping
This section contains a Mapping table for displaying the list of the mapped fields and its associated value. The CA ServiceDesk Gateway
lets you map fields for three different scenarios:
On Alarm Create
On Alarm Update
On Alarm Close
Use the Delete button of the mapping table for removing the mapping details.
Note: Use the Options icon next to the Field Mapping node for adding the mapping details.
Configure a Node
This procedure provides the information to configure a particular section within a node.
Each section within the node lets you configure the properties of the probe. These properties are used for generating incident in the CASD
application that is based on the UIM alarm.
Follow these steps:
The probe is now ready for generating incidents in the CASD application.

The field mapping details are added for saving necessary information from the UIM alarm in the incident. This information helps the CA service
desk user for resolving the incident.
Follow these steps:
1. Click the Options icon next to the Field Mapping node.
2. Select Field Mapping.
3. Specify the Service Desk Field in the Field Mapping dialog.
Note: The service desk field list appears only if valid credentials are provided in the Server Configuration section of the casd
gtw node.
4. Specify Alarm Field or define a Default Value of the selected Service Desk Field for the following three scenarios:
Alarm Create
Alarm Update
Alarm Close
5. Click Submit.
The mapping details are saved and displayed in the Mapping table of the Field Mapping node.
Note: You can map a field (an Alarm field or a Service Desk field) again for updating the field mapping details.

The field mapping details are removed or deleted when there is no need of displaying certain information in the incident.
Follow these steps:
1. Click the Field Mapping node.
2. Select the appropriate row in the Mapping table of the Field Mapping section.
3.
3. Click the Delete button of the Mapping table.

4. Click Save.
The selected field mapping detail is removed.
Advanced Configuration Settings

The advanced configuration settings let you configure the probe using the Raw Configure option, which is not possible through standard probe
GUI.
Enable Offline Management

The Offline Management mode lets you save alarm details that are assigned to the UIM user while the CASD server is down. The CA Service
Desk Gateway probe pings the CASD server at regular intervals and receives an alert when the server is down. The probe restarts when the
CASD server is up again.
The Offline Management mode checks for the alarms that are assigned to the UIM user in NAS when the server is down. The probe then initiates
a request for generating incidents for those alarms.
Follow these steps:
1. Open the Raw Configure GUI of the probe and navigate to the Setup section.
2. Go to the disable_offline_management key.
3. Edit key value as described:
1: (Default) Set the key value to 1 to turn off the Offline Management mode.
0: Set the key value to 0 to turn on the Offline Management mode.
4. Click Apply to save the configuration.
5. Restart the probe for applying the changes.
The Offline Management mode is enabled.
Note: If the probe is handling more than 12500 alarms, update the value of the java_mem_max key under the Startup > Opt section.
Set the key value as -Xmx128m for 12500 alarms, -Xmx256m for 25000 alarms, and so on.
Configure HTTPS CA Service Desk URL

The CA Service Desk Gateway probe supports the HTTPS (server-client certificate or keystore) based authentication for connecting to the CASD
application. You can use the HTTPS-based URL in the Server Name field of the probe GUI. The probe requires either a client-side certificate or a
keystore in JKS format parsable by the keytool utility of the JDK.
Follow these steps:
1. Copy the client-side certificate to host system.
Note: Copy the client-side certificate in the probe installation directory.
2. Use the Raw Configure option and navigate to the Setup section.
3. Define the certificate path in the certificatePath key.
Note: The probe supports only absolute path including the certificate file name.

5. Restart the probe for applying the configuration changes.
The HTTPS CA Service Desk URL is configured.

The subscribe_alarm_closure key is configured to update the incident status to Resolved or Closed, when the corresponding alarm is
acknowledged.
Follow these steps:

1. Use the Raw Configure option and navigate to the Setup section
2. Go to the subscribe_alarm_closure key.
3. Edit key value as follows:
0: the probe does not update the incident status. 0 is the default value.
1: the probe updates the incident status.
4. Click Apply to save settings.
The subscribe_alarm_closure key is configured.

The subscribe_alarm_updates key is configured to receive alarm updates in the CASD server.
Follow these steps:
1. Use the Raw Configure option and navigate to the Setup section.
2. Go to the subscribe_alarm_updates key.
0: the probe does not receive alarm updates. 0 is the default value.
1: the probe updates the alarm.
4. Click Apply to save settings.
The subscribe_alarm_updates key is configured.
casdgtw Metrics
The CA ServiceDesk Gateway (casdgtw) probe does not generate any QoS. Therefore, there are no probe checkpoint metrics to be configured
for this probe.
cassandra_monitor (Cassandra Monitoring)

Apache Cassandra is a distributed database management system. Large amounts of data can be spread across a cluster of hundreds of nodes.
Each of these nodes can be located in different data centers and geographic regions. While this architecture provides highly available and
scalable service, maintenance can become an issue.
The Cassandra Monitoring (cassandra_monitor) probe constantly monitors the internal performance and resource usage throughout a node in a
Cassandra cluster. Each node in the Cassandra cluster should be installed with the Cassandra Monitoring (cassandra_monitor) probe for a
comprehensive monitoring experience. The probe uses operating system commands, Cassandra API calls, and the Cassandra supported JMX
layer. The information is presented to the cluster administrator as metrics, alarms, and reports in CA Unified Infrastructure Management. You can
select and schedule an extensive range of checkpoints to meet the needs of your specific monitoring requirements.
The quality of service (QoS) data that the probe extracts and monitors include:
Live node and dead node counts
Total disk space usage by Cassandra data (all column families) on the node
Total disk space usage by a particular column family on the node
Cassandra Key Cache hit rate
Number of false positives in the bloom filter
Number of range slice dropped messages
Number of read dropped messages
Number of read repairs dropped messages

Number of pending tasks regarding anti-entropy stage
Number of pending tasks regarding writes
Total memtable data size (roll up metric)
Average recent read latency (roll up metric)
Latency for the recent writes in a column family
Average recent write latency (roll up metric for all column families)
More Information:
cassandra_monitor (Cassandra Monitoring) Release Notes
cassandra_monitor AC Configuration
Each Cassandra Monitoring probe is a local standalone probe. Any configuration changes must be made on all instances of the probe where the
change is relevant.
The following figure provides an overview of the process you must follow to configure a working probe.
Verify that the required software is available before you configure the probe.
Follow these steps:
1. Review the cassandra_monitor (Cassandra Monitoring) Release Notes for dependencies, requirements, and deployment information.
2. Install the probe on each Cassandra node that you want to monitor.
Default Configuration Settings

The probe is active and immediately attempts to publish data after installation with the default configuration. The probe uses the following default
settings:
The default installation of Cassandra on the node is /opt/apache/cassandra.
The probe uses a logging level of 3 (INFO).
Metrics are collected and broadcast every 60 seconds.
(Optional) Change the Default Configuration

You can change the default configuration if the default settings do not meet your needs. You can configure the probe through raw configure, or
the probe configuration GUI. Some configuration items can only be set through raw config. Some configuration changes take effect as soon as the
probe polls or transmits data. Other configuration changes require a restart of the probe. In general, items that can only be configured through raw
config require the probe to be restarted.
Change the Cassandra Installation Path

If Cassandra is installed in a different location, the probe does not publish any metrics. The probe generates alarms such as Cassandra is not
running on this node. Use raw configure to change the Cassandra installation configuration.
Follow these steps:
1. In Admin Console, select the Raw Configure probe option.
2. Go to setup > cassandra.
3. Locate the keys that contain the path to the Cassandra installation and make the required changes.
4. Click Apply.
Change the Log Level Setting

You can view the probe log file by selecting the View Log probe option in Admin Console. You can change the amount of information the probe
records in this file.
Follow these steps:
1. In the probe configuration GUI, select the cassandra_monitor node in the navigation pane.
2. Locate the Log Level drop-down list and change the value. The log levels that you can select are:
0 - Logs only severe messages
1 - Logs errors
2 - Logs warnings
3 - Logs informational messages
4 - Logs debugging messages
5 - Logs tracing/low-level debugging messages
3. Click Save at the top of the page. A Success message appears when the configuration change is complete.
Change the Default Resource Setup
The probe configuration has a default resource that is defined with an identifier of CASSANDRA. You can change the default resource settings
according to your monitoring needs.
Follow these steps:
1. In the probe configuration GUI, select a resource node in the navigation pane. The resource settings appear in the details pane.
2. Make the appropriate changes.
The available settings are:
Identifier - The identifier of the Cassandra resource.
Active - Indicates if monitoring is on for the resource. The probe collects data at the specified interval when this option is active.
Interval (secs) - The frequency of data collection in seconds.
Alarm Message - The alarm message to be sent if the resource does not respond.
Collect System Metrics - Indicates if the probe collects system-level metrics. System metrics include metrics about the system, not
Cassandra processes. For example, system metrics collect QoS data on CPU usage and storage.
Publish to BDIM - Indicates if the probe sends data to Big Data Infrastructure Management.
3. Click Save at the top of the page. A Success message appears when the configuration change is complete.
Configure Monitoring
The CASSANDRA resource is associated with various subcomponents of the probe. You can add and configure monitors for these
subcomponents through the navigation pane. Click the node in the navigation pane to see the monitors that are associated with the probe. You
can configure the QoS measurements that you want to collect data for, and any alarms or events you want by modifying the appropriate fields.
Follow these steps:
1. Go to cassandra_monitor > host name > CASSANDRA in the navigation pane.
2. Click a node in the resource tree. If necessary, expand one or more nodes to view the monitors for the components included in the
resource.
The available monitors appear in a table on the details pane.
3. Select the monitor that you want to modify in the table.
4. Configure the monitor settings in the fields below the table.
5. Click Save at the top of the page.
A Success message appears when the configuration change is complete.
Alarm Thresholds
allow the probe to:
Export Configuration to Other Nodes

You can specify the desired probe configuration on one Cassandra node to be automatically exported to other Cassandra probes on other nodes
in the cluster. Supported configuration values are PublishToBDIM and CollectSystemMetrics. These values can be set in the configuration GUI for
the probe.
1. In Admin Console, click the icon next to the cassandra_monitor probe name. A pop-up menu displays.
2. Select Probe Utility.
3. Perform a setAgentNode request with the argument set to true. The configuration from this probe is exported to other Cassandra probes
in the cluster.
Note: The configuration screen of the peer probes will not immediately reflect the changes made on the agent node. The values can be
verified by viewing the "raw config" of the peer probes or by observing the change in probe functionality. Once the peer probes are
restarted, their configuration screens will reflect the changes made on the agent node.
cassandra_monitor AC GUI Reference

The Cassandra Monitoring probe GUI is divided into two panes. The left navigation pane contains a hierarchical representation of the probe
inventory. The probe inventory includes monitoring targets with logical or physical components. The right details pane contains information that is
based on your selection in the navigation pane.
Contents
Navigation Pane Hierarchy

cassandra_monitor Node
Hostname Node
Profile Node
Cluster Node
System Node

The components of the Cassandra node on which the Cassandra Monitoring probe is installed are displayed in the navigation pane. Click a node
in the navigation pane to see the alarms, events, or monitors available for component.
cassandra_monitor Node
Verify the probe setup after you install the probe.
Navigation: cassandra_monitor
Probe Information
This section displays read-only information about the probe.
Probe Setup
This section allows you to change the probe log level.
Hostname Node
The hostname node is a container for the probe inventory. This node is only a container, no configuration information is displayed in the details
pane for this node.
Navigation: cassandra_monitor > hostname
Profile Node
The profile node typically includes a cluster node and a system node. You can modify some of the resource settings and can verify the resource
information.
Navigation: cassandra_monitor > hostname > CASSANDRA
Resource Setup
Fields to know:
Identifier
The identifier for the Cassandra resource profile
Active
Indicates if monitoring is active for the resource.
Interval (secs)
The frequency of data collection in seconds.
Alarm Message
The alarm message to be sent if the resource does not respond.

Collect System Metrics
Indicates if the probe collects collect system-level metrics.
Publish to BDIM
Indicates if the probe sends data to Big Data Infrastructure Management.
Cluster Node
A Cassandra cluster is defined in the Cassandra YAML or some other Cassandra cluster configuration facility. This node contains a hierarchy of
the various Cassandra subcomponents that represent a cluster. Each cluster is identified by a hostname which contains a hierarchy of the various
Cassandra components that represent a cluster. All of the cluster components contain monitors that you can configure to collect QoS
measurements. The probe can monitor the following cluster components:
Binary - This node contains binary-related metrics. For example, the number of dropped messages for binary operation.
Gossip - This node contains gossip-related metrics. For example, the number of pending tasks for gossip operation.
Incremental Backup - This node does not contain any metrics.
Keyspaces - This node is a container for the keyspace components.
NodeMetrics - This node contains most of the Cassandra-specific metrics.
Thrift - This node contains thrift-related metrics. For example, the number of thrift clients.
Navigation: cassandra_monitor > hostname > profile name > cluster name
Click the cluster node to view the components in the cluster. Expand the cluster node and navigate through the hierarchy as needed. To
configure monitors, select each node that you want to monitor. In the details pane, select the monitors that you want to configure in the table and
modify the appropriate settings. Each monitor allows you to specify a QoS measurement, conditions to be associated with the monitor, and what
actions to take when the conditions are met, such as raising an Alarm.
Fields to know:
QoS Name
The name to be used on the QoS message issued. The field is read-only.
Description
A read-only field that describes the monitor.
Metric Type
Identifies a unique Id of the QoS.
Units
The unit of the monitored value (for example, % or Mbytes). The field is read-only.
Publish Data
Select this option if you want QoS messages to be issued on the monitor.
Publish Alarms
Select this option if you want to activate alarms.
Value Definition
Value to be used for alarming and QoS.
You have the following options:
Current Value -- The most current value that is measured is used.
Delta Value (Current - Previous) -- The delta value that is calculated from the current and the previous measured sample is used.
Delta Per Second -- The delta value that is calculated from the measured samples within a second are used.
Average Value Last n Samples -- The user specifies a count. The value is then averaged based on the last "count" items.
Number of Samples
The count of items for the Value Definition when set to Average Value Last n Samples.
Operator
The operator to be used when setting the high or low alarm threshold for the measured value. Select Publish Alarms to enable this
setting.
Example:
=> 90 means alarm condition if the measured value is above 90.
= 90 means alarm condition if the measured value is exact 90.
Threshold
The high or low alarm threshold value. An alarm message is sent if this threshold is exceeded.
Message Name
The alarm message to be issued if the specified high or low threshold value is breached. These messages are kept in the message pool.
Configure dynamic alarm thresholds following the instructions that are found in cassandra_monitor AC Configuration.
System Node
The system node and its subcomponents contain many monitors for system-level QoS measurements. The probe can monitor the following
system components and services:
CPU
Memory
Network - This node is a container all network interfaces on the system and TCP statistics. Network information is collected by searching
the system for all network interfaces. If the system contains multiple NICs for example, you might see values such as eth1 and eth2.
StorageVolumes - This node is a container for all mounted filesystems on the system. Storage volume information is collected by
searching for mount points. If a user has /etc mounted from a separate partition for example, you see /etc in the StorageVolumes
list. Even network drives can appear in the StorageVolumes container.
Navigation: cassandra_monitor > hostname > CASSANDRA > System
Click the system node to view the subcomponents. Expand the system node and navigate through the hierarchy as needed. To configure
monitors, select each node that you want to monitor. In the details pane, select the monitors that you want to configure in the table and modify
the appropriate settings. Each monitor allows you to specify a QoS measurement, conditions to be associated with the monitor, and what actions
to take when the conditions are met, such as raising an Alarm.
Fields to know:
QoS Name
Description
A read-only field that describes the monitor.
Metric Type
Units
The unit of the monitored value (For example, % or Mbytes). The field is read-only.
Publish Data
Publish Alarms
Value Definition
Current Value -- The most current value that is measured is used.
Delta Per Second -- The delta value that is calculated from the samples that are measured within a second are used.
Number of Samples
The count of items for the Value Definition when set to Average Value Last n Samples.
Operator
The operator to be used when setting the high or low alarm threshold for the measured value. Select Publish Alarms to enable this
setting.
Example:
Threshold
Message Name
Configure dynamic alarm thresholds following the instructions that are found in cassandra_monitor AC Configuration.
cassandra_monitor Metrics
The following tables list the metrics that you can collect with the probe. These metrics are configured in the probe configuration GUI.
Contents
Cluster Level Metrics

System Level Metrics
Cluster Level Metrics

The metrics in the following tables are collected for various components in the Cassandra cluster. The metrics can be configured by selecting the
respective nodes in the navigation pane.
Cluster Node
Monitor
Units
Description
Version Added
CassandraVersion
Number
Cassandra version in use
v1.0
LiveNodes
Count
Number of nodes that are currently active in the cluster
v1.0
DeadNodes
Count
Number of nodes that are currently not reachable in the cluster
v1.0
Cluster Resource Node

Monitor
Units
Description
Version Added
ProcessId
Float
Process ID of the Cassandra role running on this node
v1.0
NonJVMHeapMemoryUsed
Megabytes
Non-java virtual machine (JVM) heap memory that is used by the process
v1.0
NonJVMHeapMemoryCommitted
Megabytes
Non-JVM heap memory that is committed to the process
v1.0
JVMHeapMemoryUsed
Megabytes
JVM Heap memory that is used by the process
v1.0
JVMHeapMemoryCommitted
Megabytes
Heap memory that is committed by JVM
v1.0
JVMHeapMemoryUsedPercent
Percent
Percent of JVM heap memory used
v1.0
JVMHeapMemoryMax
Megabytes
Maximum memory that is allocated to JVM
v1.0
JVMThreadActiveCount
Count
Number of threads that are alive on the JVM
v1.0
JVMThreadPeakCount
Count
Peak number of threads on the JVM
v1.0
JVMThreadTotalStartedCount
Count
Number of threads that are started on the JVM
v1.0
JVMThreadDaemonCount
Count
Number of threads that are daemons
v1.0
JVMTotalGcCount
Count
Number of collections performed
v1.0
JVMTotalGcTime
Milliseconds
Total time taken for garbage collections
v1.0
MemoryMajorFaults
Count
Count of the page faults that caused disk I/O requests
v1.0
MemoryMinorFaults
Count
Count of the page faults that did not cause disk I/O requests
v1.0
ResidentMemory
Bytes
Total number of bytes the process actually has in memory
v1.0
MemoryUsage
Bytes
Total number of bytes the process detects in memory
v1.0
SharedMemory
Bytes
Total number of bytes the process has of shared memory
v1.0
MemoryPageFaults
Count
Total number of page faults for the process
v1.0
CpuUsage
Percent
Percentage of CPU usage by the process
v1.0
CpuKernelTime
Milliseconds
Process CPU kernel time
v1.0
CpuTotalTime
Milliseconds
Total CPU time (sum of user and system)
v1.0
CpuUserTime
Milliseconds
CPU user time
v1.0
CpuKernelTimePercent
Percent
CPU kernel time in percent
v1.0
CpuUserTimePercent
Percent
CPU user time in percent
v1.0
FileDescriptorsOpen
Count
Total number of file descriptors opened by the process
v1.0
Binary Node
Monitor
Units
Description
Version Added
BinaryDroppedMessages
Count
Number of binary dropped messages
v1.0
Gossip Node
Monitor
Units
Description
Version Added
GossipPendingTasks
Count
Number of pending tasks regarding gossip
v1.0
Keyspace Nodes
Monitor
Units
Description
Version Added
CFTotalDiskSpaceUsed
Bytes
Amount of space that is used for the column family
v1.0
CFMemTableDataSize
Bytes
Amount of space that is used for the memtable of the column family
v1.0
CFLiveStableCount
Count
Number of live sstables that are used for the column family
v1.0
CFBloomFilterDiskSpaceUsed
Bytes
Amount of space that is used for the bloom filter of the column family
v1.0
CFLIveDiskSpaceUsed
Bytes
Amount of live disk space that is used for the column family
v1.0
CFTotalWriteLatency
Microseconds
Total amount of latency for write in the column family
v1.0
CFRecentWriteLatency
Microseconds
Total amount of latency for the recent write in the column family
v1.0
CFRecentReadLatency
Microseconds
Total amount of latency for the recent read in the column family
v1.0
CFWriteCount
Count
Total number of writes to the column family
v1.0
CFReadCount
Count
Total number of reads to the column family
v1.0
CFPendingTasks
Count
Total number of pending tasks regarding the column family
v1.0
CFKeyspaceCacheHitRace
Number
Key cache hit rate
v1.0
CFBloomFilterFalsePositives
Count
Number of false positives in the bloom filter
v1.0
CFBloomFilterRecentFalseRatio
Number
False ratio of the bloom filter
v1.0
NodeMetrics Node
Monitor
Units
Description
Version
Added
NodeMsgQueueBinaryDroppedMessage
Count
Number of binary dropped messages
v1.0
NodeMsgQueueCounterMutationDroppedMessage
Count
Number of counter-mutation dropped messages
v1.0
NodeMsgQueueMutationDroppedMessage
Count
Number of mutation dropped messages
v1.0
NodeMsgQueuePageRangeDroppedMessage
Count
Number of page range dropped messages
v1.0
NodeMsgQueueRangeSliceDroppedMessage
Count
Number of range slice dropped messages
v1.0
NodeMsgQueueReadDroppedMessage
Count
Number of read dropped messages
v1.0
NodeMsgQueueReadRepairDroppedMessage
Count
Number of read repair dropped messages
v1.0
NodeMsgQueueRequestResponseDroppedMessage
Count
Number of request response dropped messages
v1.0
NodeMsgQueueTraceDroppedMessage
Count
Number of trace dropped messages
v1.0
NodePendingTasksHintedHandOff
Count
Number of pending tasks regarding the hinted hand-off
v1.0
NodePendingTasksPendingRangeCalculator
Count
Number of pending tasks regarding pending range calculator
v1.0
NodePendingTasksAntiEntropyStage
Count
Number of pending tasks regarding anti-entropy stage
v1.0
NodePendingTasksValidatorExecutor
Count
Number of pending tasks regarding validator executor
v1.0
NodePendingTasksCacheCleanup
Count
Number of pending tasks regarding cache clean-up
v1.0
NodePendingTasksReadRepairStage
Count
Number of pending tasks regarding read repair
v1.0
NodePendingTasksReadStage
Count
Number of pending tasks regarding read stage
v1.0
NodePendingTasksRequestResponseStage
Count
Number of pending tasks regarding request response stage
v1.0
NodePendingTasksMutationStage
Count
Number of pending tasks regarding mutation stage
v1.0
NodePendingTasksGossipStage
Count
Number of pending tasks regarding gossip stage
v1.0
NodePendingTasksMigrationStage
Count
Number of pending tasks regarding migration stage
v1.0
NodePendingTasksInternalResponseStage
Count
Number of pending tasks regarding internal response stage
v1.0
NodePendingTasksMiscStage
Count
Number of pending tasks regarding misc stage
v1.0
NodePendingTasksWrites
Count
Number of pending tasks regarding writes
v1.0
NodePendingTasksReads
Count
Number of pending tasks regarding reads
v1.0
NodePendingTasksCompactionExecutor
Count
Number of pending tasks regarding compaction executor
v1.0
NodeOpenFileDescriptorCount
Count
Number of open file descriptors
v1.0
NodeMaxFileDescriptorCount
Count
Number of the max file descriptor
v1.0
NodeSwapSpaceTotal
Bytes
Total swap size for the node
v1.0
NodeSwapSpaceFree
Bytes
Free swap size for the node
v1.0
NodePhysicalMemFree
Bytes
Free physical memory size for the node
v1.0
NodePhysicalMemTotal
Bytes
Total physical memory size for the node
v1.0
NodeVirtualMemCommitted
Bytes
Total committed virtual memory size
v1.0
NodeTotalDiskSpaceUsed
Bytes
Total disk space that is used by the column families on the

node
v1.0
NodeTotalMemTableSize
Bytes
Total memtable data size used by the column families on the

node
v1.0
NodeRecentReadLatencyAverage
Microseconds
Average recent read latency over the column families on the

node
v1.0
NodeRecentWriteLatencyAverage
Microseconds
Average recent write latency over the column families on the

node
v1.0
NodeTotalWriteCount
Count
Total number of write counts over the column families on the

node
v1.0
NodeTotalReadCount
Count
Total number of read counts over the column families on the

node
v1.0
RangeOperationCount
Count
Total number of range operations
v1.0
TotalReadLatencyMicros
Microseconds
Total amount of latency for a read operation
v1.0
TotalRangeLatencyMicros
Microseconds
Total amount of latency for a range operation
v1.0
NodeOperation
RoleOperationMode
Operation mode of the node:
v1.0
STARTING = 0
NORMAL = 1
CLIENT = 2
JOINING = 3
LEAVING = 4
DECOMMISSIONED = 5
MOVING = 6
DRAINING = 7
DRAINED = 8
RELOCATING = 9
UNKNOWN = 10
Thrift Node
Monitor
Units
Description
Version Added
ThriftClientCount
Count
Total number of thrift clients
v1.0
System Level Metrics

The metrics in the following tables are collected for a system that is a node in a Cassandra cluster. The metrics can be configured by selecting the
respective nodes in the navigation pane.
CPU Node
Monitor
Units
Description
Version Added
CPUIdleTime
Percent
Percentage of CPU idle time
v1.0
CPUIRQTime
Percent
Percentage of CPU handling interrupts
v1.0
CPUNicePriority
Percent
Percentage of CPU used in user level with nice priority
v1.0
CPUSoftIrq
Percent
Percentage of CPU handling softirqs
v1.0
CPUStolenTime
Percent
Percentage of CPU stolen by other virtualized environments
v1.0
CPUSystemLevel
Percent
Percentage of CPU used in system level
v1.0
CPUUserLevel
Percent
Percentage of CPU used in user level
v1.0
CPUIOWaitTime
Percent
Percentage of CPU idle time due to waiting for an I/O request
v1.0
Memory Node
Monitor
Units
Description
Version Added
SystemMemoryFree
Bytes
Total free system memory (For example, Linux plus cached)
v1.0
SystemMemoryUsed
Bytes
Total used system memory
v1.0
SystemMemoryUsedPercent
Percent
Percent total used system memory
v1.0
SystemSwapMemoryFree
Bytes
Total free system swap
v1.0
SystemSwapMemoryUsed
Bytes
Total used system swap
v1.0
TotalUsedSwapMemoryPercent
Percent
Percent total used system swap
v1.0
Network eth and Io Nodes

Monitor
Units
Description
Version Added
NetIntfRxPacketsDropped
Count
Number of received packets that were dropped due to error
v1.0
NetIntfRXPacketWithErrors
Count
Number of packets that are received with errors
v1.0
NetIntfRXPacketWithFrameErrors
Count
Number of packets that are received with frame errors
v1.0
NetIntfRXPacketsWithOverrunErrors
Count
Number of received packets that experienced data overrun errors
v1.0
NetIntfPacketsRecieved
Count
Number of packets received
v1.0
NetInterfaceSpeed
Bytes/Second
Network interface speed
v1.0
NetIntfBytesTransmitted
Bytes
Number of bytes transmitted
v1.0
NetIntfTXPacketsWithCarrierErrors
Count
Number of transmitted packets that experienced loss of carrier errors
v1.0
NetIntfTXPacketCollisions
Count
Number of transmitted packets that experienced collisions
v1.0
NetIntfTXPacketsDropped
Count
Number of transmitted packets that were dropped due to error
v1.0
NetIntfTXPacketsErrors
Count
Number of transmitted packets that experienced error
v1.0
NetIntfTXPackets
Count
Number of transmitted packets
v1.0
NetIntfBytesRecieved
Bytes
Number of bytes received
v1.0
NetIntfTXPacketsWithOverrunErrors
Count
Number of transmitted packets that experienced data overrun errors
v1.0
Network TCP Node

Monitor
Units
Description
Version Added
TCPPassiveOpens
Count
Number of new TCP connections to a server
v1.0
TCPFailedConnectionAttempts
Count
Number of failed TCP connection attempts
v1.0
TCPRetransmittedSegments
Count
Number of retransmitted TCP segments
v1.0
TCPActiveOpens
Count
Number of TCP connections that are initiated by the server
v1.0
TCPConnectionResets
Count
Number of TCP connections that were reset
v1.0
TCPCurentlyEstablishedConnections
Count
Number of currently established TCP connections
v1.0
TCPResetsSent
Count
Number of TCP resets that have been sent outbound
v1.0
TCPSegementsSent
Count
Number of TCP segments that have been sent
v1.0
TCPSegementsRecievedInErrors
Count
Count of how many incoming segments had errors
v1.0
TCPSegementsRecieved
Count
Number of TCP segments that have been received
v1.0
StorageVolumes Nodes
Monitor
Units
Description
Version Added
DiskServiceTime
Milliseconds
Average service time in milliseconds for I/O requests that were issued to the device
v1.0
DiskWrites
Bytes
Number of physical disk bytes written
v1.0
DiskReads
Bytes
Number of physical disk bytes read
v1.0
DiskUsage
Percent
Percent of disk used
v1.0
DiskWritesCount
Count
Number of physical disk writes
v1.0
DiskReadsCount
Count
Number of physical disk reads
v1.0
FileSystemUsage
Kilobytes
Total used kilobytes on the file system
v1.0
FileSystemFree
Kilobytes
Total free kilobytes on the file system
v1.0
FileSystemCapacity
Kilobytes
Total Capacity of the file system in kilobytes
v1.0
v1.0 cassandra_monitor Prerequisites

Verify that the required software is available before you configure the probe.
Follow these steps:
1. Review the Cassandra Monitoring (cassandra_monitor) probe release notes for dependencies, requirements, and deployment
information.
2. Install the probe on each Cassandra node that you want to monitor.
ccm_monitor (Cisco CallManager Monitor) - no longer supported

Cisco CallManager is the software-based call-processing component of the Cisco IP Telephony solution that manages IP telephony devices and
call services over the data network. The CallManager is a Cisco Windows 2000 system that runs on a Media Convergence Server (MCS). It
provides many functions, such as managing call setup, controlling devices, and collecting statistics on call quality. It can manage IP phones,
media processing devices, voice gateways, and multimedia applications.
The Cisco CallManager system extends enterprise telephony features and functions to packet telephony network devices such as:
IP phones
Media processing devices
Voice-over-IP (VoIP) gateways
Multimedia applications.
Additional data, voice, and video services interact through Cisco CallManager's open telephony application programming interface (API):
Unified messaging
Multimedia conferencing
Collaborative contact centers
Interactive multimedia response systems
The CA Unified Infrastructure Management ccm_monitor probe
The CA Unified Infrastructure Management ccm_monitor probe is a tool for managing the health and performance of your CallManager systems
and services.
This probe monitors a set of checkpoints on defined agents running the CCM software. The probe includes a set of predefined checkpoints
available on most hosts running the CCM software. These checkpoints are grouped in different classes, and you can choose to hide checkpoints
that are not available on the hosts.
The probe also includes a UI, which can be used to:
Configure the general properties of the probe.
Define the hosts to be monitored. Group folders can be created to place the hosts in logical groups.
Activate the checkpoints to be monitored and set the monitoring conditions for these checkpoints.
Monitor the different checkpoints. The measured values will be presented as a graph.
The probe is QoS enabled, supporting theCA Unified Infrastructure Management SLA system. It will send QoS data on profiles where it
has been enabled.
More information
ccm_monitor (Cisco CallManager Monitoring) Release Notes
v1.4 ccm_monitor IM Configuration

Contents

Viewing the CallManager Summary Report
Defining a Host to be Monitored
You configure the probe by double-clicking it in Infrastructure Manager. This brings up the configuration tool.

The window consists of a row of tool buttons and two panes.
The left pane
The left-pane shows the various groups and all hosts belonging to a group. Under each host, you will find a number of classes, a way of sorting
the different checkpoints.
Selecting a group, all hosts in that group will be listed in the right pane.
Selecting a host, all predefined checkpoints will be listed in the right pane.
Selecting a class, the predefined checkpoints belonging to that class will be listed in the right pane.
Note the symbols indicating if a monitored host responds or not:

Indicates that the host responds. Can access all checkpoints.
Indicates that the host does not respond (host stopped etc.).
Indicates that the host responds, but there are some authentication problems (wrong user name or password specified?).
This indicator will appear if you define a host that is NOT a CCM host. You will still be able to monitor some windows checkpoints.
Indicates that the profile is created and stored, but is not active.
Also note that the checkpoints initially are not activated. You must activate the ones you want to monitor. Note that the option Enable Monitoring
option on the checkpoints monitor properties dialog automatically will be ticked. You have also the possibility to hide/show the ones that are not
available on the host by clicking the rightmost tool button (Show/Hide checkpoints that are not available).
Right-clicking in the pane opens a pop-up menu, giving you the following possibilities:
New Host
Opens the profile dialog, enabling you to define a new host to be monitored.
New Group
Opens the profile dialog, enabling you to define a new group. Use the group folders to place the hosts in logical groups.
New
Opens the profile dialog, enabling you to define a new host to be monitored.
Edit
Opens the profile dialog for the selected host, enabling you to modify the properties for the host.
Rename
Lets you rename the selected group or host. Note that you are not allowed to rename the group Default.
Delete
Lets you delete the selected host or group. Note that you are not allowed to delete the group Default.
Refresh
Makes a refresh to reflect the current values of the objects listed in the right window pane.
Note: When attempting to refresh a host that does not respond, the checkpoints description fields in the right pane will appear
with red letters.
Reload
Retrieves updated configuration information from the selected agent.
Information
Opens an informational window, containing system and configuration information about the selected host.
Moving a host from one group to another:

You may easily move a host from one group to another by left-clicking the host, drag it and drop it in another group.
The right pane
The right-pane is multifunctional and shows:
Hosts when a group is selected in the left-pane.

All predefined checkpoints when a host is selected in the left-pane.
The checkpoints belonging to the selected class when a class is selected in the left-pane.
Note the meaning of the different icons in the window:
This indicator may be:
green (means OK)
red (indicates an error situation)
black (means the checkpoint is not active)
yellow (the last measurement failed)
blue (the alarm threshold is breached)
This indicator means that the probe is waiting for a value from the delta calculation.
This indicator means that the checkpoint is not available at the host.
The indicator will also preliminary appear for checkpoints that are available at the host if configuration changes have been made and the
probe has been restarted. The indicator will disappear when measured values are returned from the checkpoint.
Right-clicking in the pane gives you the following possibilities:
Edit
Opens the Monitor Properties dialog, enabling you to modify the monitoring properties for the selected checkpoint.
Activate
Activates the selected checkpoint to be monitored by the probe. Note that you may also activate it by clicking the check-box belonging to
the checkpoint.
Note that the Enable Monitoring option in the properties dialog (opened by right-clicking the checkpoint and selecting Edit) for
the checkpoint must be ticked before this option works.
Deactivate
Deactivates the selected checkpoint (if activated), and the probe will stop monitoring the checkpoint.
Monitor
Opens the monitor window for the selected checkpoint, showing the values recorded since the probe was started.
Note: The horizontal red line in the graph indicates the alarm threshold (in this case 90 %) defined for the checkpoint.
When clicking and holding the left mouse button inside the graph, a red vertical line appears. If you continue to hold the left mouse-button
down and move the cursor, you can read the exact value at different points in the graph. The value is displayed in the upper part of the
graph on the format: <Day> <Time> <Value>.
Right-clicking inside the monitor window lets you select the backlog (the time range shown in the monitor window). In addition, the
right-click menu lets you select the option Show Average. This adds a horizontal blue line in the graph, representing the average sample
value.
Note the status bar at the bottom of the monitor window. The following information can be found:
The number of samples since the probe was started.
The minimum value measured.
The average value measured.
The maximum value measured.
The backlog
This is the time range shown in the monitor window. The backlog can be selected to 6, 12, 24 or 48 hours by right-clicking inside the
graph. Note that the graph can not show a time range that is greater than the selected Sample Period setting in the Setup section of
the GUI.
View Summary
This option is enabled only when CallManager is selected in the left pane.
Opens the Call Manager Summary report window (see the section ) for the host.
The tool buttons
The configuration tool also contains a row of tool buttons:
General Setup button.

Clicking this button opens the Setup dialog for the probe, allowing you to modify the general probe parameters.
Show Database Status
If clicking this button, the database status for the monitored hosts will be displayed in the right pane.
The list shows the first and the last date QoS data has been recorded and written to the database, and also the number of records in the
period. See also Showing the database status (below).
Show User Specified Objects
Clicking this button, all user specified objects will be listed in the right pane.
Right-clicking in the right pane and selecting New, the User Object dialog appears, enabling you to define a new object.
See the description Showing the user specified objects (below).
Create a New Group Folder button
Creates a new group folder in the left window pane.. Use the group folders to place the hosts in logical groups.
Create a New Host Profile button
Creates a new host to be monitored in the selected folder in the left window pane.
Message Pool Manager button
This option lets you customize the alarm text, and you may also create your own messages.
Show Phone Table button
Opens the Phone Table window containing all telephony devices handled by the selected host. Note the Status column, indicating how
the CCM interprets the status of the different devices. Sorting on this column gives a good overview of the status of the different devices.
The status is also reflected in the status bar at the bottom of the window.
Show CTI Device Table button

Opens the CTI Device Table listing all CTI devices on the selected host. CTI (Computer-Telephony Integration) is the integration of
telephony services with computers, such as IVR (Interactive Voice Response) applications.
Sorting on this column gives a good overview of the status of the different devices. The status is also reflected in the status bar at the
bottom of the window.
View Call Summary button

Clicking this button opens the CallManager Summary Report for the selected host. The window contains a graph, showing all calls for the
period you select from the drop-down lists.
Show/Hide checkpoints that are not available button
Clicking this button hides checkpoints that are not available at the selected host from the list.
Clicking the button again will make the unavailable checkpoints appear in the list again.
General Setup
Clicking the General Setup button opens the General Setup dialog.
Field
Description
General
Log-level
Set the detail level for messages logged to the log-file.
SNMP
Community
String
Specify (add or delete) SNMP community strings to be used.
SNMP
request
timeout
Select the timeout value for the SNMP requests. Use the default value, or select another value (in seconds) using the slider.
Show
SNMP
Error
In the case of an SNMP error, a general error message appears on the screen.
If this option is checked, you will get a more detailed error message, describing the specific error that occurred.
Advanced
Check
Interval
Select the Check interval from the drop-down list. Valid choices are:
1 minute
5 minutes
15 minutes
30 minutes
1 hour
Check interval is the time gap between each time the probe collects the monitor data and writes to the database.
Sample
period
Select the Sample period from the drop-down list. Valid choices are:
6 hours
12 hours
24 hours
48 hours
Sample period is the time range within which the monitored values are picked when calculating the average value (used when
setting the alarm threshold). A Sample period of 24 hours means that the samples stored within the last 24 hours will be used.
Max
number of
threads
Specifies the maximum number of profiles the probe can run simultaneously. The valid range is 0 - 100.
Showing the database status
You may show the database status for the monitored hosts by clicking the Show Database Status tool button. The database status for the
monitored hosts will be displayed in the right pane.
The list shows the first and the last date QoS data has been recorded and written to the database, and also the number of records in the period.
Showing the user specified objects
The probe includes a set of predefined checkpoints available on most hosts running the CCM software, but you may also define your own objects
to be monitored. Clicking this button, previously user specified objects will be listed in the right pane.
Right-clicking in the right pane and selecting New, the User Object dialog appears, enabling you to define a new object. This enables you to
extend objects that are not a part of the Cisco Monitor standard objects, but are available from the windows performance system.
The User Object dialog appears, enabling you to define a new object.
When clicking the Apply button in the probe GUI, the new user object will be added to the list of user defined objects and also under the User
Objects sub-node under each host listed in the left pane. When restarting the probe, the probe has to wait for a couple of minutes before it can
show the measured values for the new user defined object.
Field
Description
Login Profile
Select one of the defined hosts from the drop-down list as a Login Profile.
Performance Object
Selector
Object Name
Select the name of the new object from the drop-down list. These are objects that are not a part of the Cisco
Monitor standard objects.
Counter Name
Select the counter name from the drop-down list (e.g. Disk Transfers/sec. if object LogicalDisk is selected).
Instance Name
Select the instance name from the drop-down list (e.g. disk drive D: if object LogicalDisk and counter Disk
Transfers/sec is selected).
Object Preferences
Description
Write an optional description of the object in this field.
Make Available as QoS
Check this option to make the measured value available as QoS.
Unit
Specify the unit of the QoS value, such as pages/sec, calls, connections, %.
Creating a new group folder
You may create a new group folder by clicking the New Group Folder tool button and giving the new folder a name.
Creating a new host profile
You may create a new host profile by selecting the group it should belong to and click the New Host Profile tool button.
A dialog-box will appear and prompt you for the hostname or IP-address to the CISCO device to monitor and some additional parameters. See
the section .
Launching the Message Pool Manager
The Message Pool Manager can be opened by clicking the Message Pool button in the Tool bar.
The alarm messages for each alarm situation are stored in the Message Pool. Using the Message Pool Manager, you can customize the alarm
text, and you may also create your own messages.
Note that variable expansion in the message text is supported. If typing a $ in the Alarm text field, a dialog pops up, offering a set of variables to
be chosen.
Showing the phone table
You can open the phone table for the selected host by clicking the Show Phone Table button in the Tool bar.
Opens the Phone Table window containing all telephony devices handled by the selected host.
Showing the CTI device table
You can open the CTI device table for the selected host by clicking the Show CTI Device Table button in the Tool bar.
This table lists all CTI devices found on the selected host. CTI (Computer-Telephony Integration) is the integration of telephony services with
computers, such as IVR (Interactive Voice Response) applications.
View Call Summary
You can open the CallManager Summary Report for a host by clicking the View Call Summary button in the Tool bar.
See details in the section .

Show/Hide checkpoints that are unavailable
You can select to show or hide the checkpoints that are not available at the selected host from the list in the right window pane by clicking the Sho
w/Hide checkpoints that are unavailable button in the Tool bar.
Clicking this button hides checkpoints that are not available at the selected host from the list.
Clicking the button again will make the unavailable checkpoints appear in the list again.
Viewing the CallManager Summary Report

You can open the CallManager Summary Report for a host by:
Clicking the View Call Summary button in the Tool bar.
or
Selecting the CallManager sub node under the host profile in the left pane and then right-click in the right pane and select View
Summary.
The CallManager Summary Report window opens The window contains a graph, showing all calls for the period you select from the drop-down
lists.
Calls completed appear in red, and calls attempted in blue. This information is fetched from the summary database.
When clicking and holding the left mouse-button down and move the cursor, you can read the exact value at different points in the graph. The
value is displayed in the upper part of the graph on the format: <Day> <Time> <Attempted> <Completed>.

Double-clicking a checkpoint in the right window pane opens the Monitor Properties dialog for the checkpoint, enabling you to modify the
monitoring properties for the checkpoint.
Field
Description
Description
This field allows you to create your own description of the monitoring object (checkpoint). If desired, replace the original
description text with a description of your own choice.
Monitoring object
This is the name of the monitoring object (checkpoint) and cannot be changed.
Value definition
Decides which value to be compared with the Threshold value defined below. The two options are:
Current value
Average value
Delta value (current-previous)
Current value
Uses the last measured value to be compared with the Threshold value defined below.
Average value
Computes the average of the values measured in the time interval selected from the drop-down list.
You may select one of the predefined intervals from the drop-down list or you may type your own value in the field.
Delta value
(current-previous)
The delta value (current - previous). This means that the delta value calculated from the current and the previous
measured sample will be used.
Enable
Monitoring
Ticking this option activates the monitoring of the checkpoint.

Note that the checkpoint will also be ticked in the list of checkpoints in the right window pane when this option is selected,
and that you can enable/disable monitoring of the checkpoint from that list.
Operator
Select from the drop-down list the operator to be used when setting the alarm threshold for the measured value.
Example:
=> 90 means alarm condition if the measured value (current sample or average value - see above) is above 90.
= 90 means alarm condition if the measured value (current sample or average value - see above) is exact 90.
Threshold Value
The alarm threshold value. If this value is exceeded (see value and operator above).
Note: For some checkpoints, the threshold is not a value, but a condition. Then the threshold must be selected as a fixed
condition/status from a drop-down list. The Unit field (see below) does then not apply and will be hidden.
Unit
Read only field, specifying the unit of the monitored value.

(for example %, Mbytes etc.).
Message Token
Select the alarm message to be issued if the specified threshold value is breached. These messages are kept in the
message pool. The messages can be modified in the Message Pool Manager.
Publish Quality of
Service (QoS)
Select this option if you want QoS messages to be issued on the checkpoint.
Defining a Host to be Monitored

You may create a new host profile by selecting the group it should belong to and press the New Host Profile icon in the menu-bar.
A dialog-box will appear and prompt you for the hostname or IP-address to the CISCO device to monitor and some additional parameters.
Field
Description
Hostname or IP
address
Specify the name or IP address of the host to be monitored.
Active
Use this option to activate or deactivate monitoring of the checkpoints on the host. Note that you may also
activate/deactivate monitoring of the various checkpoints individually.
Group
Select from the drop-down list which group folder you want to put the host. Use the group folders to place the hosts in
logical groups.
Alarm Message
The alarm message to be issued if the host doesnt respond. Using the Message pool, you can edit this message or add
other messages.
Description
A short optional description of the monitored host.
Windows
Authentication
User name and
password
The login properties (a valid user name and password with administrator privileges) on the monitored host.
Domain
If the monitored host is on another domain, use a domain user name and password (see above) and specify the domain
name here.
If the monitored host is on the same domain as the computer hosting the probe, you may use a local user name and
password on the monitored host and leave this field blank.
Test
Clicking this button checks if your windows authentication works.
SNMP
Authentication
Community
/password
Select the SNMP community string to be used from the drop-down list (these community strings must have been created
on the monitored device).
Test
Clicking this button checks if your SNMP authentication works.
cdm (CPU, Disk, and Memory Performance)

The CPU, Disk, and Memory Performance (cdm) probe monitors performance and load on critical system resources: CPU, disk and memory. The
probe provides two main benefits:
Generates alarms based on configured threshold values. This probe generates alarms that can trigger corrective actions immediately.
Generates trending data, quality of Service (QoS) data, that is measured and sent to the data_engine probe, which processes it and
stores it in the UIM database. This historical data facilitates capacity planning for monitored systems in the IT environment. For example,
you can see how disks are filling up over time, plan batch jobs according to the CPU utilization, and upgrade systems which consistently
operate near capacity.
More Information:
CPU, Disk, and Memory Performance (cdm) Release Notes
cdm AC Configuration
This article describes the configuration concepts and procedures to set up the cdm probe. You can configure the probe to monitor CPU, disk or
memory of the system on which the probe is deployed.
The following diagram outlines the process to configure the probe to monitor CPU, disks and memory.
Contents
Configure Disk Monitoring
Configure CPU Monitoring
Configure Memory Monitoring
Configure Network Disk State Monitoring on Windows
Configure Network Disk State Monitoring on Linux and Solaris
Alarm Thresholds
Edit the Configuration File Using Raw Configure
Verify that required hardware and software is available and any installation consideration is met before you configure the probe. For more
information, see cdm (CPU, Disk, Memory Performance Monitoring) Release Notes.

This section describes the minimum configuration settings required to configure the cdm probe for local disk monitoring. You can configure the
probe to monitor local disks as well as shared disks (cluster). When monitoring shared disks (such as NFS mounts) over low-performance or
over-utilized lines, you may experience slow response times.
Follow these steps:
1. Open the cdm probe configuration interface.
2. Expand the Disks node and select the diskname node that represents the disk you want to monitor. The Disks node contains all
available disks detected by the probe.
Note: If the monitored environment also includes cluster disks, these disks are also included in the diskname node with the
same alarms configurations as local disks. However, for such environments, a Cluster section is displayed in the cdm node
that enables you to view and modify alarm and QoS sources for the cluster resources.
3. Expand the Disk Usage node. Enable the alarms (options are MB or Percentage) and QoS metrics in the Alarm Thresholds and Disk
Usage sections.
4. Navigate to the Disk Configuration section under the Disks node. Specify the monitoring interval, in minutes, when the probe requests
the disk data.
5. Save the configuration.
The selected disk is now being monitored.

This section describes the minimum configuration settings required to configure the cdm probe for CPU usage monitoring.
Follow these steps:
2. Expand the Processor node and enable the alarms for processor queue length from the Processor Queue Length section and the
alarms for total CPU usage from the Total CPU Usage section. The QoS for Total CPU Usage and Processor Queue Length are
enabled by default.
3. Specify the time interval in minutes during which the probe requests for data from the Processor Configuration section under the Proce
ssor node.
The CPU performance is now being monitored.

This section describes the minimum configuration settings required to configure the cdm probe for memory monitoring.
Follow these steps:
2. Expand the Memory node and enable the alarms and QoS for Memory Metrics from the Alarm Thresholds section.
3. Specify the time interval in minutes during which the probe requests for data from the Memory Configuration section.
The system memory is now being monitored.
The cdm probe allows you to monitor the availability state and usage of network disks on Windows robots.
Follow these steps:
1. Click the Options icon next to the Disks node.
2. Click Add New Share to add a network disk.
The Add New Share window opens.
3. Specify the path of the network resource and access credentials.
4. Select the Enable Folder Availability Monitoring checkbox to enable alarms for the availability state of the network disk.
You can also skip this step and enable the alarms after you create the shared network disk in the probe.
5. Click Submit.
A success message is displayed if the probe is able to connect to the network disk using the specified credentials.
6. Click the shared disk name node of the network disk.
7. Select the Enable Space Monitoring checkbox to enable the alarms for the disk usage metrics of the selected network disk.
8. Save the configuration to start generating the alarms.

The cdm probe allows you to monitor the availability state and usage of network disks on Linux and Solaris robots. The probe automatically
fetches the network disks available on the host system.
Follow these steps:
1. Right click on the network disk that you want to monitor.
Alarm Thresholds
allow the probe to:

Click the cdm probe icon in Admin Console and select Raw Configure option to access the raw configuration options. The Raw Configuration
interface allows you to edit the configuration file.
For example, the following options can be configured from Raw Configuration:
ignore_device: ignores specified disks. Navigate to the <disk> section and edit this key as follows:
ignore_device = /<regular expression>/
ignore_filesystem: ignores specified file systems. Navigate to the <file> section and edit this key as follows:
ignore_filesystem = /<regular expression>/
The value must be a regular expression that matches all disks or file systems or both that probe must ignore. Here is an example to ignore
Auto-mounted disks that are recognized on each "disk interval":
ignore_device = /autofosmount.*|.*:V.*/
Note: Ensure that you add these two keys manually and then set up the respective configuration.
allow_remote_disk_info: makes the Device Id of shared drive and local drive identical. Navigate to the setup folder and set this key as No
to enable this feature.
Default: Yes
This feature is introduced because of the following two reasons:
When file system is mounted on Linux through cifs and the cdm probe is deployed fresh, the Device Id and Metric Id for QoS and
alarms for the respective mounted file system are missing.
On restarting, the probe is unable to mark cifs drives as network drive and hence generates wrong Device Id and Metric Id.
qos_disk_total_size: indicates the total size of the disk. Navigate to disk > fixed_default and set this key to yes to enable this feature.
Default: No
This key has been introduced in Fixed default section under disk for Windows, Linux and AIX platforms.
sliced_cpu_interval: avoids the delay caused by the probe while executing commands (such as SAR) that cause internal alarms.
Navigate to cpu folder and specify a value (in seconds).
sliced_memory_interval: avoids the delay caused by the probe for collecting data from commands (such as VMSTAT) that cause internal
alarms. Navigate to memory folder and specify a value (in seconds).
The following example explains the use of sliced_memory_interval key.
Configure the interval from Setup tab of Memory as 5 min. If you configure the value of sliced_memory_interval key as 10 seconds, then
the probe collects data through VMSTAT command for 290 seconds (that is, interval would be (5 min) 10 seconds). Thus, the probe does
not generate internal alarms and seamlessly generates QOS. If still the problem persists, you can increase the sliced_memory_interval few
more seconds.
The sliced_cpu_interval and sliced_memory_interval keys have been introduced for AIX platform in the Raw Configuration section.

The cdm probe uses regular expressions many times during probe configuration. For example, specifying the regular expression C:\\ in the Ignor
e filesystems field excludes the Disk C of the system from monitoring.
Note: On UNIX platforms, use the regular expression "/\" to exclude the root directory (/) from monitoring.
target string.
The following table describes some examples of regex and pattern matching for the cdm probe.
Regular
expression
Type of regular
expression
Explanation
[A-Z]
Standard (PCRE)
[A-Z:\\]
Custom
Matches with the Uppercase character type of the local disk available on the respective
box
Standard (PCRE)
[*.\\]
Custom
Standard (PCRE)
\d*
Custom
Matches for the filesystem name which starts from letter d
cdm AC GUI Reference

This article describes the fields and features of the cdm probe.
Contents
cdm node
<hostname> node
Disks node
<diskname> node
Disk Usage node
Disk Usage Change node
<diskname> Inode Usage node
<shareddiskname> node
Memory node
Memory Paging node
Physical Memory node
Swap Memory node
Network node
Processor node
Individual CPU node
Total CPU node
Iostat node (Linux, Solaris, and AIX)
Device Iostat node
cdm node
Navigation: cdm
This node lets you view the probe information, configure the logging properties and set data management values.
cdm > Probe Information
cdm > General Configuration
This section provides general configuration details.
Log Level: specifies the level of details that are written to the log file. Log as little as possible during normal operation to minimize disk
consumption, and increase the amount of detail when debugging.
Default: 0 - Fatal
Log size (KB): specifies the size of the log file to which the internal log messages of the probe are written, in kilobytes. When this size is
reached, new log file entries are added and the older entries are deleted.
Default: 100 KB
Send alarm on each sample: If selected, the probe generates an alarm on each sample where there is a threshold breach. If not
selected, the probe waits for the number of samples (specified in Samples in the cdm > Disk Configuration, cdm > Memory or cdm >
Processor configuration screens) before sending the alarm. The sample count is cleared on de-activation of the probe.
Send short name for QoS source: If selected, sends only the host name. If not selected, sends the full host name with domain.
Allow QoS source as target: A number of QoS messages, by default, use the host name as their target. If selected, the target name is
changed to be the same as the QoS source name.
Monitor iostat (Linux, AIX and Solaris only): Enables the iostat monitoring of the host system devices.
Count Buffer-Cache as Used Memory (Linux, Solaris, AIX and HP-UX only): Counts the buffer and cache memory as used memory
while monitoring the physical and system memory utilization. If not selected, the buffer and cache memory is counted as free memory.
Calculate Load Average Per Processor: For all Unix systems, the system load measures the computational work that the system is
performing. This means that if your system has a load of 4, four running processes are either using or waiting for the CPU. Load average
refers to the average of the computers load over several periods of time. This option enables you to calculate the load average per
processor and is available for Linux, Solaris, AIX and HP-UX platforms.
Default: Selected
cdm > Cluster
This section is only visible when monitoring clustered environments and displays the cluster resources associated to the monitored system.
The following fields are displayed for each resource:
Virtual Group: displays the resource group of the cluster where the host system of the robot is a node.
Cluster Name: displays the name of the cluster.
Cluster IP: displays the IP address of the cluster. This is used as the default source for alarm and QoS.
Alarm Source: defines the source of the alarms to be generated by the probe for cluster resources.
QoS Source: defines the source of the QoS to be monitored by the probe for cluster resources.
Note: The Alarm Source and QoS source fields can have the following values:
<cluster ip>
<cluster name>
<cluster name>.<group name>
The default value for both the fields is <cluster ip>
cdm > Messages

This section provides a listing of alarm messages issued by the cdm probe and is read-only. Selecting a row displays additional alarm message
attributes below the main list, including Message Token, Subsystem, and I18N Token.
<hostname> node
Navigation: cdm > host name
This section lets you configure computer uptime, QoS data and system reboot alarms.
Disks node
Navigation: cdm > Disks
The Disks node lets you configure the global monitoring metrics and default attribute values for each individual disk. The node also includes the
shared drives of the host system. For example, cifs is a shared Windows disk that is mounted on the Linux environment, and gfs which is a
shared disk of a clustered environment.
cdm > Disks > Disk Configuration
This section lets you configure the time interval and number of samples for fetching metric values from the system. These properties are
applicable for all the monitoring disks of the system.
Interval (minutes): specifies the time in minutes for how often the probe retrieves sample data.
Default: 15
Samples: specifies how many samples the probe is keeping in memory for calculating average and threshold values.
Default: 4
Note: In case, the Send alarm on each sample option is not selected, the probe waits for the number of samples then sends the
alarm. Even if you set the sample value as 0, the QoS for disk are generated based on the default sample value.
QoS Interval (Multiple of 'Interval'): specifies the time in minutes for how often the probe calculates QoS. For example, the interval is
set to 5 minutes and number of samples is set to 5, the disk utilization is the average for the last 25 minutes.
Default: 1
Ignore Filesystems: defines the file system to be excluded from monitoring. For example, specifying the regular expression C:\\ in this
field excludes the Disk C of the system from monitoring and also stops displaying the disk in navigation pane.
Timeout: specifies the time limit in seconds for the probe for collecting the disk-related data. This option is useful at time of disk fail/crash
in stale File system and avoid a hang situation for the probe. Default: 10
Filesystem Type Filter: specifies the type of the file system to be monitored as a regular expression. For example, specifying ext* in this
field enables monitoring of only file systems such as ext4 or ext5.
Note: The first three fields are common to Memory and Processor configuration sections.
cdm > Disks > Disk Missing Defaults

This section lets you configure alarms when a specific disk is missing (not mounted or available for monitoring).
cdm > Disks > Disk Usage Defaults
This section lets you configure default thresholds and alarm messages for disk usage in MB and percent.
Publishing Alarm Based on: specifies the usage measurement units. Select either percent or Mbytes.
Enable High Threshold: lets you define a threshold for generating a higher severity alarm.
Enable Low Threshold: lets you define a threshold for generating a lower severity alarm.
Threshold: defines the high threshold value.
Alarm Message: specifies the alarm message when the high threshold value breaches. Similarly, you can configure the low threshold
value where the alarm severity is lower.
Publishing Data in MB: measures the QoS for Disk Usage MBytes.
Publishing Data in Percent: measures the QoS for Disk Usage in percentage.
cdm > Disks > Inode Usage Defaults (UNIX only)
This section lets you configure default alarms and inode usage by number of files (count) and percent. You can also configure high and low
threshold values as in the Disk Usage Defaults section.
cdm > Disks > Disk Usage Change Defaults
This section lets you configure default thresholds and alarms for changes in disk usage. You can also configure high and low threshold values as
in the Disk Usage Defaults section.
Type of Change: specifies the type of change you want to monitor: increasing, decreasing, or both.
Change Calculation: specifies the way of calculating the disk change. Select one of the following values:
Summarized over all samples: calculates the difference between the first and last sample values. The number samples are specified in
the Disk Configuration section.
Between each sample: calculates the change in disk usage by comparing the values of two successive intervals.
cdm > Disks > Disk Read (B/S)
This section lets you activate the monitoring of disk read throughput and generate QoS at scheduled interval. You can also configure low and high
thresholds for generating alarms.
Note: The disk read throughput monitoring is supported only on the Windows, Linux and AIX platforms.
cdm > Disks > Disk Write (B/S)

This section lets you activate the monitoring of disk write throughput and generate QoS at scheduled interval. You can also configure low and high
Note: The disk write throughput monitoring is supported only on the Windows, Linux and AIX platforms.
cdm > Disks > Disk Read and Write (B/S)

This section lets you activate the monitoring of total throughput of the disk and generate QoS at scheduled interval. You can also configure low
and high thresholds for generating alarms.
Note: The disk total throughput monitoring is supported only on the Windows, Linux and AIX platforms.
cdm > Disks > Add New Share

This section allows you to add a network disk to be monitored. If you click this, the Add New Share window opens.
The fields in the window are described below:
Share: specifies the location or hostname of the network disk.
Default: //
User: specifies the username for the network disk.
Password: specifies the password corresponding to the username for the network disk.
Alarm Message: selects the alarm message to be generated if network disk is not available.
Enable Folder Availability Monitoring: enables the availability state monitoring of the network disk while creating the profile.
The shared network disk is displayed as the <shareddiskname> node.
Important! You can only add shared disks to be monitored in Windows robots.
<diskname> node
Navigation: cdm > host name > Disks > disk name
The disk name node lets you configure alarms and QoS for disk availability and size for an individual local or cluster disk.
Disk Missing: configure QoS disk availability status and generate alarm when the probe fails to connect with the disk.
Disk Size: configure QoS disk size and generate alarm when the probe fails to calculate the disk size.
Note: The configuration of disk size alarms and QoS are supported only on the Windows, Linux and AIX platforms.
The following attributes are common to many probe configuration fields in the cdm user interface. Here they pertain to disk usage, elsewhere they
pertain to memory or CPU usage, depending on context.
Enable High Threshold: enables the high threshold for disk usage change. This threshold is evaluated first and if it is not exceeded,
then the low threshold is evaluated.
Threshold: indicates the value in Mbytes of the free space on the disk. When disk free space gets below this value, an alarm message is
sent.
Alarm Message: sends the alarm message when the free space on the disk is below the high threshold.
Enable Low Threshold: enables the low threshold for disk usage change. This threshold is evaluated only if the high threshold has not
been breached.
sent.
Alarm Message: sends the alarm message when the free space on the disk is below the low threshold.
Disk Usage node

Navigation: cdm > host name > Disks > disk name > Disk Usage
This node lets you configure disk usage individually for each monitored disk (diskname1, diskname2, etc). You can set attributes for alarm
thresholds, disk usage (%) and disk usage (MB).
Note: The alarms are generated for free disk space and QoS are generated for disk usage.

Navigation: cdm > host name > Disks > disk name > Disk Usage Change
This node lets you configure thresholds and alarm messages sent with changes in disk usage for each monitored disk.
Change Calculation: indicates how you want to calculate the disk change. Select from the drop-down menu either of the following:
Summarized over all samples: The change in disk usage is the difference between the latest sample and the first sample in the
"samples window," which is configured at the Disk Configuration level.
Between each sample: The change in disk usage is calculated after each sample is collected.

Navigation: cdm > Disks > disk name > Inode Usage > Alarm Thresholds
You can individually configure inode usage for each monitored disk on a Unix host.
Inode Usage Alarm Based on Threshold for: indicates the usage measurement units. Select either percent or count.
Navigation: cdm > host name > Disks > shared disk name
A shared network disk is added under the Disks node in the navigation pane. You can select the shared disk and update user name, password,
and disk availability monitoring properties.
Enable Space Monitoring: This section allows you to enable network disk usage monitoring for the profile by selecting the Enable Space
Monitoring checkbox.
Network Connection: This section allows you to view or edit the user credentials for the shared network disk specified in the Add New Share wi
ndow while creating a network disk monitoring profile.
Shared Folder Availability: This section allows you to specify or edit the thresholds and alarms for the availability state of the network disk.
Note: The Disk Usage and the Disk Usage Change nodes for the <shareddiskname> node are the same as defined for the
<diskname> node.
Memory node
Navigation: cdm > Memory > Memory Configuration
At the Memory level, set or modify the following global memory attributes based on your requirements.
The fields are common to all three probe configuration sections (Disks, Memory, Processor).
Default: 5
Samples: specifies how many samples the probe should keep in memory to calculate average and threshold values. Default: 5 If you did
not select the Send alarm on each sample check box in the Probe Configuration details pane, the probe waits for the number of samples
(specified in this field) before sending the alarm. Do not specify 0 (Zero) in this field.
QoS Interval (Multiple of 'Interval'): specifies the time in minutes for how often the probe calculates QoS. For example, If the interval is
set to 5 minutes and number of samples is set to 5, the memory utilization reported will be the average for the last 25 minutes.
Default: 1
Set QoS Target as 'Memory': sets the QoS target to Memory.
Memory Paging node

Navigation: cdm > Memory > Memory Paging > Alarm Thresholds
You can individually configure alarm and memory paging thresholds for alarm sent with changes in memory paging for each monitored disk. See
Set Thresholds for more details about setting dynamic, static, Time Over Threshold, and Time To Threshold alarms.

Navigation: cdm > Memory > Physical Memory
The Physical Memory node lets you monitor the memory utilization of the system for generation QoS data and configure threshold for generating
alarms. The memory utilization is directly related to the system performance. In case, the memory utilization is high the system performance goes
down and the application response time increases. The increased response time of critical business applications can adversely impact the user
interaction. Monitoring the system memory lets you helps diagnosing the issue, for example, identifying the closing the unwanted applications.
You can also consider system upgrade when the memory utilization is consistently high.
This node lets you monitor the following memory metrics:
Physical Memory
System Memory
User Memory
Note: The system and user memory monitoring is supported only on the Windows, Linux and AIX platforms.
Swap Memory node

Navigation: cdm > Memory > Swap Memory > Swap Memory (%)
A swap memory is a reserved space on hard drive which is used by the system when the physical memory (RAM) is full. However, the swap
memory is not a replacement of the physical memory due to lower data access rate.
The CPU, Disk, and Memory Monitoring probe calculates the swap memory similar to the swap -l command of Solaris. However, the probe use
pages instead of blocks. You can compare the swap memory information of the probe and the swap -l command by using the following formula:
Swap Memory (calculated by probe) in MB = (Blocks returned by the swap -l command * 512)/ (1024*1024).
Network node
Navigation: cdm > Network
This node lets you monitor the outbound and inbound traffic of your system Network Interface Card (NIC). The NIC monitoring lets you analyze
the network bandwidth that is being utilized which can impact the overall network performance. For example, your NIC capacity is 100 MBPS and
aggregated traffic is more than 90 MBPS then it can slow down the data transfer rate. This monitoring helps you take preventive actions before
the network goes down. For example, upgrade your NIC or install more NICs and implement the load-balancing solution.
This node lets you monitor the following network metrics:
Inbound Traffic: Monitors the traffic coming from LAN or a public network to the monitored system in bytes per second.
Outbound Traffic: Monitors the traffic going from the monitored system to LAN or a public network in bytes per second.
Aggregated Traffic: Monitors both inbound and traffic in bytes per second.
Important! The probe monitors only physical NICs of system and sum up the metric values when multiple NICs are installed on the
monitored system.
Note: These network metrics are supported only on the Windows, Linux and AIX platforms.
Processor node
Navigation: cdm > Processor
The Processor node lets you configure processor-related metrics and their corresponding time interval for fetching the monitoring data. The probe
lets you configure the number of samples and returns the average of computed values. All calculations are based on the number of CPU ticks
returned, for example, the /proc/stat command returns in Linux. The probe adds the column values (user, nice, system, idle, and iowait) for
calculating the total CPU ticks. In a multi-CPU environment, the total for all CPU column values are added.
Similarly, the delta values are calculated by comparing the total CPU tick values of last and current interval. Then, the percentage values are
calculated for each column based on the total CPU ticks value. The QoS for total CPU value is the sum of CPU System, CPU User, and (if
configured) CPU Wait.
Configure the following fields:
Default: 5
Samples: specifies how many samples the probe should keep in memory to calculate average and threshold values.
Default: 5
Note: If you did not select the Send alarm on each sample checkbox, under the cdm node -> General Configuration section, the
probe waits for the number of samples (specified in this field) before sending the alarm. Do not specify 0 (Zero) in this field.
set to 5 minutes and number of samples is set to 5, the CPU utilization reported will be the average for the last 25 minutes.
Set QoS Target as 'Total': Select this checkbox if you want the QoS target to be set to Total.
Default: 5
Include CPU Wait in CPU Usage: includes the CPU Wait in the CPU Usage calculation.
Number of CPUs: displays the number of CPUs. This is a read-only field.
Maximum Queue Length: indicates the maximum number of items in the queue before an alarm is sent.
Alarm Message: sends the alarm message when the queue has been exceeded.
Top CPU consuming processes in alarm: defines the total number of top CPU consuming processes. Consider the following points
while using this option:
This alarm is generated when the defined total CPU usage is breached. The new alarms generate the process information in the
following format:
[processname[pid]-cpu%]; [processname[pid]-cpu%]
The actual CPU value in the alarm may not always match the total percentage of all the top CPU consuming processes shown in the
alarm message. It may vary as Total CPU Usage is calculated on the basis of samples. The Top CPU consuming processes fetch the
raw data at a given time will be displayed in the alarm.
For non-Windows platform, the probe uses ps command to retrieve the top CPU consuming processes.
Notes:
The CpuErrorProcesses and CpuWarningProcesses messages are available only on fresh installation of the probe version
5.6. If you upgrade the probe from previous versions, you need to select these messages from Alarm messages drop-down
list in Total CPU Usage section.
The variable '$processes' is added from probe version 5.6 and later.
Individual CPU node

Navigation: cdm > Processor > Individual CPU
The Individual CPU node lets you configure metrics for monitoring each CPU node of the host system. You can configure appropriate setting for
the following sections:
CPU Usage Difference - lets you monitor the difference in percent of CPU usage between two successive intervals.
Individual CPU Idle - lets you generate QoS data on the amount of time when CPU is not busy. In other words, CPU is running the
System Idle Process.
Individual CPU System - lets you generate QoS data on the amount of time during which CPU executed processes in kernel mode.
Individual CPU Usage - lets you generate QoS data for monitoring CPU usage in percent as compared to the CPU capacity.
Individual CPU User - lets you generate QoS data on the amount of time during which CPU executed processes in kernel mode.
Individual CPU Wait - lets you generate QoS data on the amount of time during which CPU is waiting for I/O process to complete.
Maximum CPU Usage - lets you generate alarm when the CPU usage percent breaches the maximum usage limit.
Total CPU node

Navigation: cdm > Processor > Total CPU > Total CPU Idle
This section lets you configure thresholds to send alarm messages when the CPU usage gets below the configured thresholds. Some of the
configuration fields are:
Enable High Threshold: sets the high threshold for CPU usage. This threshold is evaluated first and if it is not exceeded, then the low
Threshold: sends an alarm message when the CPU usage gets below this value. The value in percent of the CPU usage.
Alarm Message: sends the alarm message when the CPU usage on the disk is below the high threshold.
Enable Low Threshold: sets the low threshold for CPU usage. This threshold is evaluated only if the high threshold has not been
exceeded.

Navigation: cdm > host name > iostat
The iostat node lets you monitor the input and output statistics (iostat) on the respective devices.
This node appears only when the following two conditions are met:
The cdm probe is installed on the Linux, Solaris, and AIX environments.
The Monitor iostat option is selected in the General Configuration section of the cdm node.
Note: The Monitor iostat option is disabled, by default.
The probe executes the iostat command for fetching the iostat monitors value. The QoS values are obtained from the second sample value of the
devices.
Interval (minutes): defines the time interval for fetching the sample values from the device. Default: 5
Sample: defines the time interval in seconds, which is used with iostat command for fetching the iostat data for that time duration. This
value must be less than Interval (minutes) field value.
Default: 10
Ignore Iostat Devices: defines the iostat devices to be excluded from monitoring. For example, specifying the regular expression
sda|sdb in this field excludes the sda and sdb iostat devices from monitoring.
Device Iostat node

Navigation: cdm > iostat > device name
The device iostat node lets you configure the iostat monitors on the selected device. The list of iostat monitors differ for each operating system
(OS) as follows:
Operating System
Linux
Iostat Monitors
Iostat Average Queue Length
Iostat Average Request Size
Iostat Average Service Time (Linux)
Iostat Average Wait Time (active, by default)
Iostat Read Requests Merged Per Second
Iostat Reads Per Second
Iostat Sector Reads Per Second
Iostat Sector Writes Per Second
Iostat Utilization Percentage (active, by default)
Iostat Write Requests Merged Per Second
Iostat Writes Per Second
Solaris
Iostat Active Transactions

Iostat Average Service Time (Solaris)
Iostat Disk Reads Per Second
Iostat Disk Writes Per Second
Iostat Kilobytes Read Per Second
Iostat Kilobytes Written Per Second
Iostat Percentage Of Time Busy
Iostat Percentage Of Time Waiting For Service (active, by default)
Iostat Queue Length (active, by default)
AIX
Iostat Kilobytes Read

Iostat Kilobytes Transferred Per Second
Iostat Kilobytes Written
Iostat Percentage Of Time Active (active, by default)
Iostat Transfers Per Second
The probe detects the underlying OS and filters the list of monitors. This section lets you enable the iostat monitoring for the device. This option is
disabled, by default.
This section represents the actual monitor name of the device for configuration.
QoS Name: identifies the QoS name of the monitor.
Units: identifies a unit of the monitor. For example, % and Mbytes.
Publish Data: publishes the QoS data of the monitor.
Enable High Threshold: lets you configure the high threshold parameters. Default: Disabled
Threshold: defines the threshold value for comparing the actual value. Default: 90
Alarm Message: specifies the alarm message when the threshold value breaches. Default: IostatError
Enable Low Threshold: lets you configure the low threshold parameters. Typically, the low threshold generates a warning alarm and the
high threshold generates an error alarm. Default: Disabled
Alarm Message: specifies the alarm message when the threshold value breaches. Default: IostatWarning
Similarly, you can configure other monitors because each monitor contains the same set of fields.
cdm IM Configuration
Important! You must use cdm version 5.61 with cluster version 3.33 to view the cluster disks on the cdm Infrastructure Manager (IM).
Contents
Probe Defaults
How to Copy Probe Configuration Parameters

This article describes the minimum configuration settings required to configure the cdm probe for local disk monitoring. You can configure the
Follow these steps:
2. Click the Status tab. This tab is the default tab of the cdm probe GUI. From the Disk Usage section, select the disk you want to monitor
from the list of all available disks.
3. Navigate to the Disk Usage and thresholds tab and enable the QoS (options are MB or Percentage) and alarms.
4.
4. Click the Control Properties tab under the Setup tab. Specify the monitoring interval, in minutes, when the probe requests the disk data.
Note: You can add network disks to be monitored using Windows robots using the New Share option in the Disk Usage section of the
Status tab. You can monitor availability state and usage of network disks using any robot where the probe is deployed by clicking the E
nable Space Monitoring option in the Disk Usage section of the Status tab.

This article describes the minimum configuration settings required to configure the cdm probe for CPU usage monitoring.
Follow these steps:
2. Click the Advanced tab and enable the QoS by selecting the desired options.
3. Click the Status tab and enable the alarms by configuring the desired values in the CPU usage section.
4. Click the Control Properties tab under the Setup tab. Specify the monitoring interval, in minutes, when the probe requests the CPU
data.

This article describes the minimum configuration settings required to configure the cdm probe for memory monitoring.
Follow these steps:
3. Click the Status tab and enable the alarms by configuring the desired values in the Memory Usage section.
4. Click the Control Properties tab under the Setup tab. Specify the monitoring interval, in minutes, when the probe requests the Memory
data.
Probe Defaults
You can use the sample configuration file to configure a probe with default monitoring values.
Follow these steps:
1. Navigate to the Program Files\Nimsoft\Probes\System\<probe_name> folder.
2. Make the desired configuration in the <probe_name>.cfg file.
3. Run/restart the probe in Infrastructure Manager to initialize the configuration.
You can now use the newly added default monitoring values, such as templates, in the left pane as per requirement.

If you want to configure the cdm probe the same way on multiple robots, you can copy the probe configuration from one probe to another.
Note: When you perform this operation with the cdm probe, you must ensure that the disk partitions are the same on the source and
the target computers.
For example, If the source computer has a C: and a D: partition, and you copy the cdm probe configuration to a cdm probe on a computer with
only a C: partition, the cdm probe on this computer will try to monitor a D: partition (which is missing) and report an error.
Follow these steps:
1. Log on to the robot where your configured cdm probe resides.
2. Select the cdm probe to be copied from the probe list in the Infrastructure Manager and drag and drop the probe into the Archive.
3. Click Rename and enter a unique package name the copy of the cdm probe archive. For example, rename the package to cdm_master.
4. Select the Configuration Only check box.

5. Drag and drop this package on any other robot where the cdm probe is already running.
The distribution progress window appears and the configuration of the probe is completed after distribution process is finished.

To access the raw configuration pages hold the Shift key and right click the cdm probe in Infrastructure Manager. Then select the Raw Configure
option from the right-click menu. The raw configuration allows you to edit the configuration file or edit the data file.
Default: Yes

Default: No
more seconds.

target string.
Regular
expression
Type of regular
expression
Explanation
[A-Z]
Standard (PCRE)
[A-Z:\\]
Custom
box
Standard (PCRE)
[*.\\]
Custom
Standard (PCRE)
\d*
Custom
cdm IM GUI Reference

This article describes the fields and probe interface features.
The CPU, Disk and Memory Monitor (cdm) probe configuration interface displays a screen with tabs for configuring this probe. This probe can be
set up in three types of environments: single computer, multi-CPU and cluster.
Contents:
Setup Tab
General Tab
Control Properties Tab
Message Definitions Tab
Cluster Tab
Edit Alarm or QoS Source
Status Tab
Disk Usage
Disk Usage Modification
New Share Properties
UNIX platforms
Edit Disk Properties
Delete a Disk
Modify Default Disk Parameters
Enable Space Monitoring
The Multi CPU Tab
Advanced Tab
Custom Tab
New CPU Profile
New Disk Profile
New Memory Profile
Setup Tab
The Setup tab is used to configure general preferences for the probe. There are three tabs within this tab: General, Control Properties and Mes
sage Definitions. A fourth tab, the Cluster tab, appears if the probe is running within a clustered environment.
General Tab
Log level
Specifies the level of details that are written to the log file.
Log as little as possible during normal operation to minimize disk consumption, and increase the amount of detail when debugging.
Log size
Specifies the size of the probe's log file where probe-internal log messages are written. Upon reaching this size, the contents of the file
are cleared.
Default: 100 KB
Send alarm on each sample
If selected, the probe generates an alarm on each sample. If not selected, the probe waits for the number of samples (specified in the Sa
mples field of the Control properties tab) before sending the alarm. This check box is selected by default.
For example, if the value in the Interval field is set to 1 minute and the value in the Samples field is set to 2, under the Control
Properties tab, and if this:
Option is Unchecked: the first alarm will be generated in 2 minutes and the respective alarms will be generated in 1 minute time
interval each.
Option is Checked: the first alarm will be generated in 1 minute and the respective alarms will be generated in 1 minute time interval
each.
Note: The sample collected at the start of the probe is considered as the first sample. The sample count is cleared on de-activation of
the probe. For more details about the samples, see the Control Properties tab.
Send short name for QoS source

If selected, sends only the host name. If not selected, sends the full host name with domain.
Allow QoS source as target
Many QoS messages use the host name as their target, by default. If selected, the target name is changed to be the same as the QoS
source name.
Important! If the Set QoS source to robot name option is set in the controller you will get the robot name also as target.
Calculate Load Average per Processor

For all Unix based systems, the system load measures the computational work that the system is performing. This means that if your
system has a load of 4, four running processes are either using or waiting for the CPU. Load average refers to the average of the
computers load over several periods of time. This option enables you to calculate the load average per processor and is available for
Linux, Solaris, AIX and HP-UX platforms.
Default: Selected
The Control Properties tab defines the time limit after which the probe asks for data and the number of samples the probe should store to
calculate the values used to determine the threshold breaches.
The fields displayed in the above dialog are divided into the following three sections:
Disk properties
CPU properties
Memory & Paging properties
The field description of each section is given below:
Interval
Specify the time limit in minutes between probe requests for data. This field is common for all three sections.
Samples
Allows you to specify how many samples the probe should store for calculating values used to determine threshold breaches. This field is
common for all three sections.
Note: Even if you set the sample value as 0, the QoS for disk are generated based on the default sample value.
QoS Interval (Multiple of 'Interval')

Allows you to specify the time limit in minutes between sending of QoS data. For example, If the interval is set to 5 minutes and number
of samples is set to 5, the CPU utilization will be the average for the last 25 minutes. This field is common for all three sections.
Ignore Filesystems
Defines the filesystem to be excluded from monitoring. This field is specific to Disk Properties section only. For example, specifying the
regular expression C:\\ in this field excludes the Disk C of the system from monitoring. A red symbol is displayed next to the disk drive
which is excluded from monitoring in the Disk usage section of the Status tab.
Filesystem Type Filter

Specifies the type of the file system to be monitored as a regular expression. For example, specify ext* in this field to enable monitoring
of only file systems such as ext4 or ext5.
Timeout
Specifies the time limit for the probe to collect CPU, Disk and Memory related data. This option is useful at time of disk fail/crash in stale
File system to avoid hang situation for the probe. A default timeout of 5 seconds can be used to avoid hang situation to get disk statistics.
But when system is having high CPU load, 5 seconds timeout is not good enough in certain situations. Recommended timeout is 10
seconds and should be increased under situations like high CPU load. This option is available for nonwindows platforms only, like Linux.
Set QoS Target as 'Total' (CPU)
If selected, the QoS for Total (Individual as well as Average) will be changed to Total. The default is the hostname.
The following SQL scripts demonstrate how to update old data to confirm with when the QoS Target as Total is changed:
QOS_CPU_USAGE
To see the rows to be changed or updated rows:
SELECT * FROM dbo.s_qos_data WHERE probe LIKE 'cdm' AND qos LIKE 'qos_cpu_usage'
AND target NOT IN('user','system','wait','idle')
To update table for new target:
Declare @Target varchar(100) Declare @Source varchar(100)

SELECT @Target = 'Total' SELECT @Source = 'tsuse10-32' UPDATE dbo.s_qos_data SET
target=@Target WHERE source LIKE @Source AND probe LIKE 'cdm' AND qos LIKE
'qos_cpu_usage' AND target NOT IN('user','system','wait','idle')
Here, Target is the new QoS target to be set and Source is the QoS source for which target need to be changed. Both of these can be
configured by user.
QOS_CPU_MULTI_USAGE
SELECT * FROM dbo.s_qos_data WHERE probe LIKE 'cdm' AND qos LIKE
'qos_cpu_multi_usage' AND (target NOT LIKE 'User%' AND target NOT LIKE 'System%'
AND target NOT LIKE 'Wait%' AND target NOT LIKE 'Idle%')
Declare @Target varchar(100) Declare @Source varchar(100) SELECT @Target =

'Total' SELECT @Source = 'tsuse10-32' UPDATE dbo.s_qos_data SET
target=@Target+RIGHT(target,2) WHERE source LIKE @Source AND probe LIKE 'cdm'
AND qos IN ('qos_cpu_multi_usage') AND (target NOT LIKE 'User%' AND target NOT
LIKE 'System%' AND target NOT LIKE 'Wait%' AND target NOT LIKE 'Idle%')
Here, Target is the new QoS target to be set and Source is the QoS source for which target need to be changed. Both of these
can be configured by user.
Set QoS target as 'Memory'
If selected, QoS target for memory and paging is set as Memory.
The following SQL scripts demonstrate how to update old data in the database when the QoS Target as "Memory" is changed:
SELECT * FROM dbo.s_qos_data

WHERE probe LIKE 'cdm'
AND (qos LIKE'QOS_MEMORY_PERC_USAGE' or qos LIKE 'QOS_MEMORY_PAGING_PGPS' or qos
LIKE 'QOS_MEMORY_PAGING' or qos LIKE 'QOS_MEMORY_PHYSICAL' or qos LIKE
'QOS_MEMORY_PHYSICAL_PERC' or qos LIKE 'QOS_MEMORY_SWAP' or qos LIKE
'QOS_MEMORY_SWAP_PERC')
Declare @Target varchar(100)

SELECT @Target = 'Memory'
UPDATE dbo.s_qos_data
SET target=@Target
WHERE
probe LIKE 'cdm'
Note: Here, Target is the new QoS target to be set.
The Message Definitions tab enables you to customize the sent messages whenever a threshold is breached. A message is defined as a text
string with a severity level. Each message has a token that identifies the associated alarm condition.
The fields displayed in the above dialog are explained below:
Message Pool
This section lists all messages with their associated message ID. You can right-click in the message pool window to create a new
message and edit/delete an existing message.
Active Messages
This section contains tabs to allow you to associate messages with the thresholds. You can drag the alarm message from the message
pool and drop it into the threshold field. The available tabs are explained below:
CPU
High (error) and Low (warning) threshold for total CPU usage.
High (error) threshold for individual CPU usage (alarms are sent when one of the CPUs in multi-CPU systems breaches the
threshold).
CPU difference threshold (alarms are sent when the difference in CPU usage between different CPUs in multi-CPU systems breaches
the threshold).
Disk
To modify the thresholds for disks, double click the disk-entries under the Status tab.
Memory
Depends on what memory view is selected in the memory usage graph, where you may toggle among three views (see the Status
tab).
High (error) and Low (warning) threshold for pagefile usage and paging activity
Physical memory
Swap memory
Computer
Allows you to select the alarm message to be issued if the computer is rebooted.
Default: The time when the computer was rebooted.
Other
You can select the alarm message to be sent if the probe is not able to fetch data.
Default: Contains information about the error condition.
Cluster Tab
The Cluster tab is displayed only when the cdm probe is hosted in clustered environment and it is configured as a part of a cluster.
It displays a list of detected virtual groups belonging to the cluster. By editing the entries (refer Edit Alarm or QoS source section), you can set
the alarm source and QoS source to be used for disks belonging to that virtual group.
The available options for alarm source and QoS source are:
<cluster ip>
<cluster name>
You can edit the alarm source or QoS source.

Follow these steps:
1. Double-click a virtual group entry.
2. On the Group Sources dialog, select the Alarm source and QoS source.
3. Click OK.
Note: QoS messages can also be sent on Disk usage (both in % and MB), and availability for shared disks (also disk usage on NFS file
systems if the Enable space monitoring option is set for the file system as described in the section Setup > Cluster). These options can
be selected when defining the threshold values for these options under the Status tab.
Status Tab
The Status tab sets up high and low thresholds for the CPU, memory and paging activity for the selected file system. It is also the default tab of
the cdm probe GUI.

Graphs
The graphs display actual samples in purple, averages in blue, error threshold (if configured) in red, and warning threshold (if configured) in
yellow.
CPU usage: graph of the CPU usage.
Memory usage: three separate graphs (% of total available memory, physical, and virtual memory). Use the buttons M, S, and P on the
top right corner of the graph to toggle through the three graphs.
% of available memory: in % of total available memory
Physical memory: in % of available physical memory (RAM).
Swap memory: on UNIX systems, this value refers to the % of available swap space.
Note: Typing <Ctrl>+S on your keyboard will save the current view for this graph, and this view will be shown the next time you open
the probe GUI.
Paging activity: graph of the paging activity.

You can enter the Threshold values by clicking the up/down indicator for High and Low, or by typing the value into the text field. Please note that
the cdm probe uses average value as the reference value when it determines if a threshold is breached.
Disk Usage
The disk usage section displays the details of all disks installed on the system and the disk usage details such as file system type, amount of free
space and total disk usage. You can monitor each disk individually, with individual threshold values, messages and severity levels.
Note:
The probe uses the mount entries as in /proc/mounts file in Linux to display the file system type of devices that are remounted
to a different location.
When using NFS mounts in the cdm probe, be aware that the server where the mount point is pointing will appear in the
discovery in USM.
You can modify the monitoring properties of disk by right-clicking on a monitored disk in the list.
You have the following options, depending on the disk type:

New Share
Edit
Delete
Use the New Share option to modify the disk usage properties.
You can specify the network disk or folder to be monitored by the cdm probe.The network location is specified in the Share field using the format:
\\computer\share. In addition, specify the user name and password to be used when testing the availability of the share, and the Message ID to be
sent if a share is determined to be unavailable. You can use the domain user if the machine is a member of a domain.
Select the Folder Availability Quality of Service Message option to send QoS messages on availability of the shared folder.
Note: For UNIX platforms, this option is used to monitor NFS file systems.
To enable or disable space monitoring of the Windows share/mounted drive, right-click a monitored windows share/mounted drive in the list and
select the enable/disable space monitoring option.
Note: The shares are tested from the service context, and the cdm probe just checks that it is possible to mount the share.
UNIX platforms
To enable/disable space monitoring of the file system, right-click a monitored NFS file system in the list and select the enable/disable space
monitoring option. Enabling space monitoring of a NFS file system may cause problems for the cdm probe if the communication with the NFS
server is disrupted (e.g. stale NFS handles). By default, the NFS file systems are monitored for availability only.
Use the Edit option to modify the disk usage properties.
The disk usage configuration GUI displays tabs for each section of the disk configuration, which are explained below:
Disk usage and Thresholds tab
The page displays the amount of total, used, and free disk space for the file system.
You can configure the following threshold settings:
Monitor disk using either Mbytes or %.
High threshold for the disk. If you select this option, set the value (based on either Mbytes or %) and select the alarm message to be
sent. When the amount of free space gets below this value, the specified alarm message will be sent. This threshold is evaluated first and
if it is not exceeded, then the low threshold is evaluated.
Low threshold for the disk. If you select this option, set the value (based on either Mbytes or %) and select the alarm message to be sent.
When the amount of free space gets below this value, the specified alarm message will be sent. This threshold is evaluated only if the
high threshold has not been exceeded.
You can configure the Quality of Service message, which can have information about the disk usage in Mbytes, % or both depending on
your selections.
Inode Usage and Thresholds tab
This tab is only available for UNIX systems; otherwise it remains disabled. The tab indicates the amount of total, used, and free inodes on the file
system.
Monitor disk using either inodes or %.
High threshold for the disk. If you select this option, set the value (based on either inodes or %) and select the alarm message to be sent.
When the amount of free space gets below this value, the specified alarm message will be sent.
Low threshold for the disk. If you select this option, set the value (based on either inodes or %) and select the alarm message to be sent.
When the amount of free space gets below this value, the specified alarm message will be issued.
You can configure the Quality of Service message, which can have information about the disk usage in inodes, % or both depending on your
selections.
Disk Usage Change and Thresholds tab
This tab lets you specify the alarm conditions for alarms to be sent when changes in disk usage occur.
Disk usage change calculation
You can select one of the following:
Change summarized over all samples. The change in disk usage is the difference between the latest sample and the first sample in
the "samples window". The number of samples the cdm probe will keep in memory for threshold comparison is set as Samples on
the Setup > Control Properties tab.
Note: There may be some discrepancy between the values in QoS and values in alarms when the Change summarized over all
samples option is selected. This is because the QoS are generated on every interval and Alarms are generated based on the selection
of the option Change summarized over all samples.
Change between each sample. The change in disk usage will be calculated after each sample is collected.
Threshold settings
This section allows you to define the alarm conditions:
Type of change. You can select whether alarms should be issued on increase, decrease or both increase and decrease in disk usage.
High threshold for the disk. If you select this option, set the value in Mbytes and select the alarm message to be sent. When the
amount of free space gets below this value, the specified alarm message will be sent. The default value is 2 Mbytes.
Low threshold for the disk. If you select this option, set the value in Mbytes and select the alarm message to be sent. When the
amount of free space gets below this value, the specified alarm message will be issued. The default value is 2 Mbytes.
QoS
You can send QoS messages on disk usage change in Mbytes.
Delete a Disk
Use this option to delete the disk from being monitored by the cdm probe. When you use the Delete option a confirmation dialog appears. Click Y
es to delete the disk from the list.
Use the Modify Default Disk Parameters option to change fixed disk properties.
If you modify the default settings than every disk that you add from that point forward will have the new settings as the default disk properties.
The Enable space monitoring option appears only for the shared drive/folder (using the New Share... option) being monitored by the cdm probe.
To enable/disable space monitoring of the windows share/mounted drive/NFS file system, right-click a monitored windows share/mounted drive/
NFS file system in the list and select the enable/disable space monitoring option.
The Multi CPU Tab

Use the Multi CPU option to display the alarm threshold and the CPU usage for the different CPUs in a multi-CPU configuration. You can specify
the maximum threshold, CPU difference threshold and processors to display.
Note: This tab only visible when the cdm probe is running on a multi-CPU computer.
A multi-core processor (multi-CPU) is a single computing component with two or more independent actual processors (called "cores"), which are
the units that read and execute program instructions. A multi-core processor implements multiprocessing in a single physical package.
This tab contains a graph displaying the alarm threshold and the CPU usage for each processor in a multi-CPU configuration.
The thresholds and options available in the above dialog are explained below:
Maximum
High (error) threshold (in %) for individual CPU usage (alarms are sent when one of the CPUs in multi-CPU systems breaches the
threshold).
Difference
CPU difference threshold (in %). Alarms are sent when the difference in CPU usage among the CPUs in a multi-CPU system
breaches the threshold).
Select processors to view
Select the processor(s) to view in the graph. By default all available processor are shown.
Click Update to refresh the graph with the most current sample values.
Advanced Tab
The Advanced tab enables you to customize the QoS messages, for example an alarm on processor queue length, an alarm on detected reboot,
and paging measurements.

Quality of Service Messages
Select any of the following settings to send the QoS messages as per the time intervals defined under the Control properties tab.
Processor Queue Length (For Windows)/System Load (Processor Queue Length)(For AIX, SGI, Linux and Solaris)
Measures the number of queued processes, divided by the number of processors waiting for CPU time for the system.
Load Average 1 min
Specifies the average system load over the last one minute.
Load Average 5 min
Specifies the average system load over the last five minutes.
Load Average 15 min
Specifies the average system load over the last fifteen minutes.
Notes:
The values of the Load Average metrics are calculated per processor. These are dependent on the field Calculate Load
Average per Processor under the Setup -> General tab.
Sampling is not applicable for the three Load Average Metrics.
Memory Usage
Measures the amount of total available memory (physical + virtual memory) used in Mbytes.
Memory in %
Measures the amount of total available memory (physical + virtual memory) used in %.
Memory Paging in Kb/s
Measures the amount of memory that has been sent to or read from virtual memory in Kbytes/second.
Memory Paging in Pg/s
Measures the amount of memory that has been sent to or read from virtual memory in pages per second.
Note: If you have been running CDM version 3.70 or earlier, the QoS settings in the cdm probe GUI are different than CDM
version 3.72. However, if CDM version 3.70 or earlier already has created QoS entries in the database for kilobytes per second
(Kb/s) and/or pages per second (Pg/s), these entries will be kept and updated with QoS data from the newer CDM version (3.72
and higher).
Physical Memory Usage

Measures the amount of total available physical memory used in Kbytes.
Physical Memory in %
Measures the amount of total available physical memory used in %.
Swap Memory Usage
Measures the space on the disk used for the swap file in Kbytes.
Swap Memory in %
Measures the space on the disk used for the swap file in %.
Computer uptime (hourly)
Measures the computer uptime in seconds every hour.
CPU Usage
This section is divided into two tabs: Total CPU and Individual CPU. All measurements in these are in percentage.
Note: The Individual CPU tab remains disabled in a single CPU configuration.
CPU Usage (Total/Individual)

Measures how much time the CPU spends on user applications and high-level system functions. Even when the CPU usage is 0%,
the CPU is performing basic system tasks, such as responding to mouse movements and keyboard input. The QoS message includes
CPU User, CPU System and optionally CPU Wait information. The optional CPU Wait information requires you to select the CPU Wait
is included in CPU Usage (Total) option.
CPU User
Measures the time spent by the CPU on user tasks.
CPU System
Measures the time spent by the CPU on system tasks.
CPU Wait
Measures the time the CPU waits when accessing external memory or another device.
CPU Idle
Measures the time the CPU runs idle without processing anything.
Alarm on Processor Queue Length (For Windows)/Alarm on System Load (For AIX, SGI Linux and Solaris)
Select this alarm setting to check the processor queue length. The processor queue length measures the number of threads that are in
the server's processor queue waiting to be executed by the CPU. All servers, whether they have a single CPU, or multiple CPUs, have
only one processor queue. The processor queue length is a measurement of the last observed value, and it is not an average of any kind.
Alarm messages are generated according to the specified threshold value .
Default: 4.
Notes:
If running on a multi-CPU system, the queued processes will be shared on the number of processors. For example, if running
on a system with four processors and using the default Max Queue Length value (4), alarm messages will be generated if the
number of queued processes exceeds 16.
To enable the QoS metric QOS_PROC_QUEUE_LEN for per CPU, you are required to add a key system_load_per_cpu with
value as Yes under the CPU section through the raw configure option. The probe calculates the system load on Linux, Solaris
and AIX as Load/Number of CPU if this key is set to Yes.
Alarm on Load Average 1 min

Select this option if you want an alarm to be sent when the average system load over the last one minute exceeds the specified
threshold.
Max. Load Average
An alarm is sent when this threshold is breached.
Default: 0.9
Select this option if you want an alarm to be sent when the average system load over the last five minutes exceeds the specified
threshold.
Max. Load Average
Default: 0.9
Select this option if you want an alarm to be sent when the average system load over the last fifteen minutes exceeds the specified
threshold.
Max. Load Average
Default: 0.9
Alarm on Detected Reboot
Select this option if you want an alarm to be sent if this computer is rebooted.
CPU Usage options:
CPU Wait is included in CPU Usage (Total)
Select this option if you want the QoS message on CPU Total to include CPU User, CPU System and CPU Wait. Otherwise, the CPU
Total includes only CPU User and CPU System values.
CPU stats. against entitled capacity
Calculates CPU usage as per lpar on AIX system. This option is visible only on AIX system.
The formula to calculate CPU usage on AIX system is:
Lparstat i command
Total Capacity =( maxVirtualCPU/ maxCapacity)*100;
CPU User = CPU user *EntCap)/TotCapacity;
cpuStats->fSystem = (double)((cpuStats->fSystem *
cpuStats->fEntCap)/TotCapacity);
cpuStats->fWait = (double)((cpuStats->fWait *
cpuStats->fIdle = (double)((cpuStats->fIdle *
following format:
The actual CPU value in the alarm may not always match the total percentage of all the top CPU consuming processes shown in
the alarm message. It may vary as Total CPU Usage is calculated on the basis of samples. The Top CPU consuming processes
fetch the raw data at a given time will be displayed in the alarm.
Notes:
The CpuErrorProcesses and CpuWarningProcesses messages are available only on fresh installation of the probe
version 5.6. If you upgrade the probe from previous versions to 5.6, you must drag and drop these messages from
the Message Pool list under the Setup > Message definitions tab.
Paging measured in
Paging can be measured in Kilobytes per second or pages per second.
Paging is the amount of memory which has been sent to or read from virtual memory. This option lets you select the paging to be
measured in one of the following units:
Kilobytes per second (KB/s)
Pages per second (Pg/s). Note that the size of the pages may vary between different operating systems.
Note: When changing the paging selection, the header of the Paging graph on the Status tab immediately changes to show the
selected unit, but the values in the graph do not change until the next sample is measured.
QoS messages for NFS file systems

For NFS file systems, you can select QoS message on Disk availability to be sent. For this, right-click the filesystem on the Status tab and select
Edit. Select the Disk Available Quality of Service in the properties dialog and click OK. See Edit Disk Properties for more details.
Memory usage on Solaris systems
There seems to be some confusion about the memory usage the cdm probe reports on Solaris systems. Most often, the issue is that cdm
does not provide the same numbers that the popular TOP utility does. The main reason for this is that TOP and CDM gather swap
information differently.
CDM gathers swap information in a similar way as the Solaris utility swap-l does, but using pages instead of blocks. To compare the swap
information between CDM and the swap utility you take the blocks swap reports and run it through the formula: (blocks * 512) / (1024 *
1024) = total_swap Mb. This is the same number of MB the CDM probe uses in its calculations.
TOP on the other hand gathers information about anonymous pages in the VM, which is quicker and easier to gather but do not represent a
true picture of the amount of swap space available and used. The reason is that anonymous pages also take into account physical memory
that is potentially available for use as swap space. Thus, the TOP utility will report more total swap space since it is also factoring in
physical memory not in use at this time.
CDM and TOP gather physical memory information in similar ways, so the differences in available physical memory should be insignificant.
Since CDM does not differentiate between available swap and physical memory (after all, it is only when you run out of both the resources
that things stop working on the system), the accumulated numbers are used. The accumulated numbers for TOP will be off, since the free
portions of physical memory will be counted twice in many instances. While we could easily represent the data in the same format that TOP
does, we feel it does not give a correct picture of the memory/swap usage on the system.
Custom Tab
The Custom tab displays a list of all currently defined custom profiles. Custom profiles are used to get additional thresholds and alarms for
checkpoints that are available in the probe. All the alarm situations are available, except for those available for multi-CPU and cluster disks. A
custom profile allows you to fine-tune monitoring of resources for alarming purposes.
The alarms for each custom profile will be sent using suppression keys unique to the profile so that you can get multiple alarms for what is
basically the same alarm situation (for instance, the a breach of the memory usage threshold).
You can right-click inside the above dialog to create new custom profiles to monitor the CPU, disk or memory. Once a custom profile is created
you can select one or more custom profiles to edit, delete or activate/deactivate as and when required.
New CPU Profile
The fields are explained below:

Name: defines the CPU profile name.
Description: defines the CPU profile description.
Alarm On: specifies that the alarm threshold is considered as the average of defined threshold values, or the individual threshold values.
following format:
The actual CPU value in the alarm may not always match the total percentage of all the top CPU consuming processes shown in the
alarm message. It may vary as Total CPU Usage is calculated on the basis of samples. The Top CPU consuming processes fetch the
raw data at a given time will be displayed in the alarm.
Notes:
The CpuErrorProcesses and CpuWarningProcesses messages are available only on fresh installation of the probe
version 5.6. If you upgrade the probe from previous versions to 5.6, you must drag and drop these messages from the M
essage Pool list under the Setup > Message definitions tab.
High and Low: activates the alarm generation in case high, or low threshold values of selected checkpoint are breached.
New Disk Profile
You can create a custom profile for a local disk, shared disk, or for a disk available on a network.

Name: defines the disk profile name.
Description: defines the description of the disk profile.'
Regular Expression for Mount Point: defines a regular expression through which you can monitor your Custom Local Disk (for
Windows platform) and Custom Local and NFS (for Linux, Solaris and AIX platforms).
Note: on selecting this option, the drop-down menu Mount point and the field Remote Disk are disabled which means that
monitoring is enabled either through the regular expression or through the drop-down menu.
Active: activates the alarm generation if the disk is unavailable or not mounted.
Allow space monitoring: lets you configure three new checkpoints to monitor the disk, which are Disk free space, Inodes free, Space usage
change.
For more information on these checkpoints, refer to the Control Properties Tab section.
Note: You are required to enable NFS drives from the Status tab to see custom NFS inode alarms.
New Memory Profile

Name: defines the memory profile name.
Description: defines the memory profile description.
cdm Troubleshooting
This article contains the troubleshooting points for the cdm probe.
Contents
Guidelines for Sending Bug Reports

Memory Usage on Solaris Systems
AIX Calculations for AIX Logical Partition (LPAR)
Guidelines for Sending Bug Reports

The following is a list of files and commands that should be run on the affected system before a bug report is filed. The files and output from the
commands should be attached to the bug report if possible. Providing this information with the bug report saves time during the evaluation of the
issue.
Files for all platforms
Loglevel should be set to 3 and the error reproduced prior to sending these files. Since this will generate quite a lot of log information, you
can either increase the size of the log files in the cdm GUI or set the Loglevel to 13, which will not truncate the log file.
cdm.cfg
cdm.log
_cdm.log
Windows
The version of Windows and SP level should be provided. Individual patches applied are not necessary unless explicitly requested. A
screen shot of the Performance tab in the Task Manager would be helpful if the problem is CPU or Memory related. A screen shot of the
disks in Windows Explorer would be helpful for disk issues.
Unix (all platforms)
# uname -a
# mount
# df -k (on systems that support the -k option)
AIX
# /usr/bin/vmstat
# /usr/sbin/sar -P ALL
# /usr/bin/uptime
HP-UX
No commands need to be executed on this platform.
LINUX
#
#
#
#
cat
cat
cat
cat
/proc/stat
/proc/vmstat (if applicable)
/proc/meminfo
/proc/loadavg
Solaris
# /usr/bin/mpstat 60 (note: runs until stopped with Ctrl-C, get at least two
iterations)
# /usr/bin/uptime
Tru64
# /usr/sbin/collect -s c -t -i0 (note: runs until stopped with Ctrl-C, get at

least two iterations)
Memory Usage on Solaris Systems
The cdm probe reports the memory usage on Solaris systems in a different way from the popular TOP utility. The cdm probe does not provide the
same numbers that the TOP utility does. The main reason for this is that TOP and CDM gather swap information differently.
The cdm probe gathers swap information in a similar way as the Solaris utility swap-l does, but using pages instead of blocks. To compare the
swap information between CDM and the swap utility, you can take the blocks swap reports and run it through the formula: (blocks * 512) / (1024 *
TOP, on the other hand, gathers information about anonymous pages in the VM, which is quicker and easier to gather but do not represent a true
picture of the amount of swap space available and used. The reason is that anonymous pages also take into account physical memory that is
potentially available for use as swap space. Thus, the TOP utility reports more total swap space since it is also factoring in physical memory not in
use at this time.
The cdm probe and TOP gather physical memory information in similar ways, so the differences in available physical memory should be
insignificant.
Since the cdm probe does not differentiate between available swap and physical memory (after all, it is only when you run out of both the
resources that things stop working on the system), the accumulated numbers are used. The accumulated numbers for TOP will be off, since the
free portions of physical memory will be counted twice in many instances.
Thus, the cdm probe does not provide the data in the same format that TOP does, to give a clear picture of the memory/swap usage on the
system.
AIX Calculations for AIX Logical Partition (LPAR)

For AIX systems, using entitled capacity can lead to CPU usage above 100 percent. This happens because the option CPU stats. against
entitled capacity is selected under the Advanced tab.
The following calculations explain the reason for this high CPU utilization.
When you select the option CPU stats. against entitled capacity under the Advanced tab, and run the lparstat i command, you get the
following values for Maximum Virtual CPUs and Maximum Capacity in the output:
bash-3.2# lparstat -i
Maximum Virtual CPUs
: 4
Maximum Capacity
: 4.00
The following calculation is used to calculate the Total capacity.

Total Capacity = (Maximum Virtual CPUs / Maximum Capacity)/100
So (4/4.0)*100 = 100%
Run the sar command sar P ALL and observe the output like
bash-3.2# sar -P ALL 5 1

AIX aix7164 1 7 00F7874B4C00
03/08/13
System configuration: lcpu=4 ent=0.10 mode=Uncapped

07:45:14 cpu
07:45:19
%usr
%sys
%wio
%idle
physc
%entc
99
0.25
249.3
100
0.25
250.5
100
0.25
250.0
100
0.25
249.9
100
1.00
999.4
If you select the option Cpu Stats against entitled capacity, it is calculated as
Example 100 is %usr for cpu-1

Entitled capacity for usr -1 is calculated as follows:
(100x999.4)/100 = 999.4
(%usr
X %entc)/Total Capacity
Similarly, you can calculate entitled capacity for system and idle CPU utilization.
cdm Metrics
This article describes the metrics that can be configured using the CPU, Disk, and Memory Performance (cdm) probe.
QoS Metrics
CPU
Disk
Memory
Miscellaneous
Network
Iostat Monitors: Linux Platform
Iostat Monitors: Solaris Platform
Iostat Monitors: AIX Platform
Disk Usage and Thresholds (Disk Error)
Disk Usage Change and Thresholds (Delta Error)
Inode Usage and Thresholds
lostat
QoS Metrics
The following tables list all the QoS metrics generated by the cdm probe.
CPU
Monitor Name
QoS Name
Units
Description
Version
Individual CPU
Idle
QOS_CPU_MULTI_USAGE
Percent
The percentage of time when an individual CPU of the system was idle.
4.7
The percentage of time when an individual CPU of the system was executing
the kernel or operating system.
4.7
Individual CPU
Usage
The percentage of time for which an individual CPU of the system was used.
4.7
Individual CPU
User
The percentage of time for which an individual CPU of the system was execut
ing in user mode.
4.7
Individual CPU
Wait
The percentage of time for which an individual CPU of the system was waitin
g for I/O.
4.7
The percentage of time when all CPUs of the system were idle.
4.7
The sum of CPU time when all CPUs of the system were executing the kernel
or operating system.
4.7
Total CPU
Usage
The percentage of time for which all CPUs of the system were used.
4.7
Total CPU User
The percentage of time for which all CPUs of the system were executing in
user mode.
4.7
Total CPU Wait
The percentage of time for which all CPUs of the system were waiting for I/O.
4.7
Individual CPU
System
Total CPU Idle
Total CPU
System
(all of these metrics are calculated

from this monitor)
QOS_CPU_USAGE
(all of these metrics are calculated
from this monitor)
Percent
Disk
Monitor Name
QoS Name
Units
Description
Version
Disk Usage Change (MB)
QOS_DISK_DELTA
Megabytes
The disk usage change in megabytes
4.7
Disk Usage (MB)
QOS_DISK_USAGE
Megabytes
Aggregated disk usage in megabytes
4.7
Disk Usage (%)
QOS_DISK_USAGE_PERC
Percent
Aggregated disk usage in percentage
4.7
Disk Read (B/s)
QOS_DISK_READ_THROUGHPUT
Bytes/Second
Disk bytes read per second
5.1
Disk Write (B/s)
QOS_DISK_WRITE_THROUGHPUT
Bytes/Second
Disk bytes written per second
5.1
Disk Read and Write (B/s)
QOS_DISK_TOTAL_THROUGHPUT
Bytes/Second
Disk bytes read and written per second
5.1
Disk Size
QOS_DISK_TOTAL_SIZE
Gigabytes
Total size of the disk
5.1
Disk Available
QOS_DISK_AVAILABLE
Available
The availability of the disk
5.1
Inode Usage (Count)
QOS_INODE_USAGE
Inodes
Total number of free file nodes in file system
4.7
Inode Usage (%)
QOS_INODE_USAGE_PERC
Percent
Total number of free file nodes in file system in percentage.
4.7
Memory
Monitor
Name
QoS Name
Units
Description
Version
Memory
Usage (MB)
QOS_MEMORY_USAGE
Megabytes
Total memory usage in megabytes
4.7
Memory
Paging (KB/s)
QOS_MEMORY_PAGING
Kilobytes/Second
Memory paging in kilobytes per second
4.7
Memory
Paging (Pg/s)
QOS_MEMORY_PAGING_PGPS
Pages/Second
Memory paging in pages per second
4.7
Memory
Usage (%)
QOS_MEMORY_PERC_USAGE
Percent
Total memory usage in percentage
4.7
Physical
Memory (MB)
QOS_MEMORY_PHYSICAL
Megabytes
The size of the physical memory available in the system in megabytes.

Note: For this metric, the buffer cache will be subtracted from physical
memory value if the key mem_buffer_used is set as No. This support
is added for Linux, AIX, Solaris and HPUX platforms.
5.4
Physical
Memory (%)
QOS_MEMORY_PHYSICAL_PERC
Percent
The size of the physical memory available in the system in percentage
4.7
Swap Memory
(MB)
QOS_MEMORY_SWAP
Megabytes
Total Swap memory usage in megabytes
4.7
Swap Memory
(%)
QOS_MEMORY_SWAP_PERC
Percent
Total Swap memory usage in percent
4.7
System
Memory
Utilization (%)
QOS_MEMORY_SYS_UTIL
Percent
Total System memory utilization in percent. This metric is supported

only on the Windows, Linux and AIX platforms.
5.1
User Memory
Utilization (%)
QOS_MEMORY_USR_UTIL
Percent
Total User memory utilization in percent. This metric is supported only

on the Windows, Linux and AIX platforms.
5.1
Miscellaneous
Monitor Name
QoS Name
Units
Description
Version
Load Average 1 min
QOS_LOAD_AVERAGE_1MIN
Count
The average system load over the last one minute.
5.5
Note: This metric is supported only on the Linux, Solaris, AIX and HP-UX
platforms.
Load Average 5 min
Count
The average system load over the last five minutes.
5.5
platforms.
Load Average 15 min
Count
The average system load over the last fifteen minutes.
5.5
platforms.
System Load
QOS_PROC_QUEUE_LEN
Processes
The current calculated average load of the system.
4.7
Folder Available
QOS_SHARED_FOLDER
Available
Populates the data depending upon the disk availability.

The available options are: Missing, New and Ok.
4.7
Computer Uptime
Hourly
QOS_COMPUTER_UPTIME
Seconds
It contains information detailing how long the system has been on since its
last restart.
4.7
Network
Monitor Name
QoS Name
Units
Description
Version
Network Inbound Traffic
QOS_NETWORK_INBOUND_TRAFFIC
Bytes/Second
The total number of bytes per second received by the

server.
5.1
Network Outbound
Traffic
QOS_NETWORK_OUTBOUND_TRAFFIC
Bytes/Second
The total number of bytes per second sent by the server.
5.1
Network Aggregated
Traffic
QOS_NETWORK_AGGREGATED_TRAFFIC Bytes/Second
The total number of bytes per second sent and received

by the server.
5.1
Note: These metrics are supported only on the Windows, Linux and AIX platforms.
Iostat Monitors: Linux Platform

Monitor Name
QoS Name
Units
Description
Version
Iostat Read Requests

Merged Per Second
QOS_IOSTAT_RRQM_S
ReadReqMerged/Sec
Total Iostat read requests merged per second that were queued to
the device
5.1
Iostat Write Requests

Merged Per Second
QOS_IOSTAT_WRQM_S
WriteReqMerged/Sec
Total Iostat write requests merged per second that were queued to
the device
5.1
Iostat Reads Per

Second
QOS_IOSTAT_RS
Reads/Sec
The number of read requests that were issued to the device per
second
5.1
Iostat Writes Per

Second
QOS_IOSTAT_WS
Writes/Sec
The number of write requests that were issued to the device per
second
5.1
Iostat Sector Reads Per

Second
QOS_IOSTAT_SEC_RS
SectorReads/Sec
The number of sectors read from the device per second
5.1
Iostat Sector Writes Per

Second
QOS_IOSTAT_SEC_WS
SectorWrites/Sec
The number of sectors written to the device per second
5.1
Iostat Average Request

Size
QOS_IOSTAT_AR_SZ
Sectors
The average size (in sectors) of the requests that were issued to the
device
5.1
Iostat Average Queue

Length
QOS_IOSTAT_AQ_SZ
QueueLength
The average queue length of the requests that were issued to the
device
5.1
Iostat Average Wait

Time
QOS_IOSTAT_AWAIT
Milliseconds
The average time for I/O requests issued to the device. This
includes the time spent by the requests in queue and the time spent
servicing them.
5.1
Iostat Average Service

Time
QOS_IOSTAT_SVCT
Milliseconds
The average service time for I/O requests that were issued to the
device.
5.1
Iostat Utilization
Percentage
QOS_IOSTAT_PU
Percent
Percentage of CPU time during which I/O requests were issued to

the device.
5.1

Per Second
QOS_IOSTAT_KRS
Kilobytes/Sec
The amount of data read from the device.
5.2

Per Second
QOS_IOSTAT_KWS
Kilobytes/Sec
The amount of data written to the device.
5.2
Iostat Monitors: Solaris Platform

Monitor Name
QoS Name
Units
Description
Version
QOS_IOSTAT_RS
Reads/Sec
The number of reads from the device per second
5.1
QOS_IOSTAT_WS
Writes/Sec
The number of writes from the device per second
5.1
QOS_IOSTAT_KRS
Kilobytes/Sec
The amount of kilobytes read from the device per second
5.1
QOS_IOSTAT_KWS
Kilobytes/Sec
The amount of kilobytes written from the device per second
5.1
Iostat Queue Length
QOS_IOSTAT_QLEN
QueueLength
The average number of transactions waiting for service
5.1
QOS_IOSTAT_ACT
Transactions
The average number of transactions that are actively being

serviced
5.1
Iostat Average Service Time
QOS_IOSTAT_SVCT
Milliseconds
The average service time in milliseconds
5.1
Iostat Percentage Of Time Waiting For

Service
QOS_IOSTAT_PCTW
Percent
The percentage of time there are transactions waiting for

service
5.1
QOS_IOSTAT_PCTB
Percent
The percentage of time the disk is busy
5.1
Iostat Monitors: AIX Platform

Monitor Name
QoS Name
Units
Description
Version
Iostat Percentage Of Time Active
QOS_IOSTAT_PCTA
Percent
The percentage of time the device was active
5.1
QOS_IOSTAT_KBPS
Kilobytes/Sec
The amount of data transferred (read or written) per second
5.1
QOS_IOSTAT_TPS
Transfers/Sec The number of transfers per second.
5.1
QOS_IOSTAT_KR
Kilobytes
The amount of data read per second from the device in kilobytes
5.1
QOS_IOSTAT_KW
Kilobytes
The amount of data written to the device
5.1
QOS_IOSTAT_RS
Reads/Sec
The number of reads from the device per second
5.2
QOS_IOSTAT_WS
Writes/Sec
The number of writes from the device per second
5.2
QOS_IOSTAT_KRS
Kilobytes/Sec
The amount of kilobytes read from the device per second.
5.2
QOS_IOSTAT_KWS
Kilobytes/Sec
The amount of kilobytes written from the device per second
5.2
The following tables list the Alert Metrics Default Settings, by type, for the cdm probe.
Alert Metric
Warning Threshold
Warning Severity
Error Threshold
Error Severity
Description
CPU Usage
75%
Warning
90%
Major
Total CPU above error threshold
Memory Usage in percent
50%
Warning
90%
Major
Memory Percent Usage
Physical memory usage
85%
95%
Swap memory usage
60%
85%
Swap Memory Usage
Memory Paging Activity
150KB/ sec
Warning
2000 KB/ sec
Major
Amount of paging that is occurring
Disk Usage and Thresholds (Disk Error)

Alert Metric
Warning Threshold
Warning
Severity
Error Threshold
Disk usage (%)
20%
Major
10%
Disk usage
(Mb)
default should be 20% of total disk space
Error
Severity
Description
default should be 10% of total disk space
Disk Usage Change and Thresholds (Delta Error)

Alert Metric
Warning Threshold
Disk usage
Warning Severity
Error Threshold
Error Severity
Description
200
Inode Usage and Thresholds

Alert Metric
Warning
Threshold
Warning
Severity
Error
Threshold
Inode usage (%)
20
10
Inode usage (inodes)
20
10
Inode Free
20
10
Disk Metric delta
10
Error
Severity
Description
The number of processes waiting

to run
Max Queue Length

Processor Queue Length
Warning
Maximum
MultiCPU CPU usage of single cpu
90
Difference
MultiCPU Difference in CPU usage between
CPUs
50
lostat
Alert
Metric
Warning
Threshold
Warning
Severity
Error
Threshold
Error
Severity
Description
IostatError
90
Major
The Iostat monitor value of the device is above the threshold

value
cdm Versions 5.5-5.0

This section contains documentation for versions of the cdm probe prior to 5.6.
v5.5 cdm AC Configuration
v5.5 cdm IM Configuration
Contents
Alarm Thresholds

This section describes the minimum configuration settings required to configure the cdm probe for local disk monitoring. You can configure the
Follow these steps:
2. Expand the Disks node and select the diskname node that represents the disk you want to monitor. The Disks node contains all
available disks detected by the probe.
Note: If the monitored environment also includes cluster disks, these disks are also included in the diskname node with the
same alarms configurations as local disks. However, for such environments, a Cluster section is displayed in the cdm node
that enables you to view and modify alarm and QoS sources for the cluster resources.
3. Expand the Disk Usage node. Enable the alarms (options are MB or Percentage) and QoS metrics in the Alarm Thresholds and Disk
Usage sections.
4. Navigate to the Disk Configuration section under the Disks node. Specify the monitoring interval, in minutes, when the probe requests
the disk data.

Follow these steps:
2. Expand the Processor node and enable the alarms for processor queue length from the Processor Queue Length section and the
alarms for total CPU usage from the Total CPU Usage section. The QoS for Total CPU Usage and Processor Queue Length are
enabled by default.
ssor node.

Follow these steps:
2.
2. Expand the Memory node and enable the alarms and QoS for Memory Metrics from the Alarm Thresholds section.
3. Specify the time interval in minutes during which the probe requests for data from the Memory Configuration section.

The cdm probe allows you to monitor the availability state and usage of network disks on Windows robots.
Follow these steps:
5. Click Submit.

The cdm probe allows you to monitor the availability state and usage of network disks on Linux and Solaris robots. The probe automatically
fetches the network disks available on the host system.
Follow these steps:
1. Right click on the network disk that you want to monitor.
Alarm Thresholds
allow the probe to:

allow_remote_disk_info: makes the Device Id of shared drive and local drive identical. Navigate to the setup folder and set this key as N
o to enable this feature.
Default: Yes
Default: No
more seconds.

A regular expression (regex for short) is a special text string for describing a search pattern. Constructing regular expression and pattern
matching requires meta characters. The probe supports Perl Compatible Regular Expression (PCRE) which are enclosed within forward slash (/).
For example, the expression /[0-9A-C]/ matches any character in the range 0 to 9 in the target string.
target string.
Regular
expression
Type of regular
expression
Explanation
[A-Z]
Standard (PCRE)
[A-Z:\\]
Custom
box
Standard (PCRE)
[*.\\]
Custom
Standard (PCRE)
\d*
Custom
v5.5 cdm AC GUI Reference

Contents
cdm node
<hostname> node
Disks node
<diskname> node
Disk Usage node
Memory node
Memory Paging node
Swap Memory node
Network node
Processor node
Individual CPU node
Total CPU node
Device Iostat node
cdm node
Navigation: cdm
Default: 0 - Fatal
Log size (KB): specifies the size of the log file to which the internal log messages of the probe are written, in kilobytes. When this size is
Default: 100 KB
Monitor iostat (Linux and Solaris only): Enables the iostat monitoring of the host system devices.
Calculate Load Average Per Processor: For all Unix systems, the system load measures the computational work that the system is
performing. This means that if your system has a load of 4, four running processes are either using or waiting for the CPU. Load average
refers to the average of the computers load over several periods of time. This option enables you to calculate the load average per
processor and is available for Linux, Solaris, AIX and HP-UX platforms.
Default: Selected
cdm > Cluster
This section is only visible when monitoring clustered environments and displays the cluster resources associated to the monitored system.
<cluster ip>
<cluster name>
cdm > Messages

<hostname> node

Disks node

shared drives of the host system. For example, cifs is a shared Windows disk that is mounted on the Linux environment, and gfs which is a
Default: 15
Samples: specifies how many samples the probe is keeping in memory for calculating average and threshold values.
Default: 4
set to 5 minutes and number of samples is set to 5, the disk utilization is the average for the last 25 minutes.
Default: 1
field excludes the Disk C of the system from monitoring and also stops displaying the disk in navigation pane.
field enables monitoring of only file systems such as ext4 or ext5.

This section lets you configure alarms when a specific disk is missing (not mounted or available for monitoring).
Enable Low Threshold: lets you define a threshold for generating a lower severity alarm.



Default: //
Important! You can only add shared disks to be monitored in Windows robots.
<diskname> node
sent.
been breached.
sent.
Disk Usage node
Between each sample: The change in disk usage is calculated after each sample is collected.
This section allows you to enable network disk usage monitoring for the profile by selecting the Enable Space Monitoring checkbox.
Network Connection
This section allows you to view or edit the user credentials for the shared network disk specified in the Add New Share window while creating a
network disk monitoring profile.
Shared Folder Availability
This section allows you to specify or edit the thresholds and alarms for the availability state of the network disk.
<diskname> node.
Memory node

Default: 5
set to 5 minutes and number of samples is set to 5, the CPU utilization reported will be the average for the last 25 minutes.
Default: 1
Set QoS Target as 'Memory': sets the QoS target to Memory.
Memory Paging node

Physical Memory
System Memory
User Memory
Swap Memory node
Network node

monitored system.
Processor node

Default: 5
not select the Send alarm on each sample checkbox, in the Probe Configuration pane, the probe waits for the number of samples
set to 5 minutes and number of samples is set to 5, the CPU utilization reported will be the average for the last 25 minutes.Set QoS
Target as 'Total': Select this checkbox if you want the QoS target to be set to Total.
Default: 5
Individual CPU node

Individual CPU User - lets you generate QoS data on the amount of time during which CPU executed processes in kernel mode.
Total CPU node
Enable High Threshold: sets the high threshold for disk usage. This threshold is evaluated first and if it is not exceeded, then the low
Enable Low Threshold: sets the low threshold for disk usage. This threshold is evaluated only if the high threshold has not been
exceeded.
Navigation: cdm > host name > iostat

devices.
value must be less than Interval (minutes) field value.
Default: 10
Ignore Iostat Devices: defines the iostat devices to be excluded from monitoring. For example, specifying the regular expression
sda|sdb in this field excludes the sda and sdb iostat devices from monitoring.
Device Iostat node

(OS) as follows:
Operating System
Linux
Iostat Monitors
Solaris

AIX


Contents
Probe Defaults
Options Configured Using Raw Configure

This article describes the minimum configuration settings required to configure the cdm probe for local disk monitoring. You can configure the
Follow these steps:
2. Click the Status tab. This tab is the default tab of the cdm probe GUI. From the Disk Usage section, select the disk you want to monitor
from the list of all available disks.
3. Navigate to the Disk Usage and thresholds tab and enable the QoS (options are MB or Percentage) and alarms.
4. Click the Control Properties tab under the Setup tab. Specify the monitoring interval, in minutes, when the probe requests the disk data.

Follow these steps:
3. Click the Status tab and enable the alarms by configuring the desired values in the CPU usage section.
4. Click the Control Properties tab under the Setup tab. Specify the monitoring interval, in minutes, when the probe requests the CPU
data.

Follow these steps:
3. Click the Status tab and enable the alarms by configuring the desired values in the Memory Usage section.
4. Click the Control Properties tab under the Setup tab. Specify the monitoring interval, in minutes, when the probe requests the Memory
data.
Probe Defaults
Follow these steps:

Note: When you perform this operation with the cdm probe, you must ensure that the disk partitions are the same on the source and
the target computers.
Follow these steps:
3.


Below are some useful options that can be set, using the Raw Configuration tool:
ignore_device
ignore_filesystem
To ignore certain disks and/or file systems, you can edit one of these two keys in the <disk> section:
The value should be a regular expression that would match all disks and/or filesystems that you want the probe to ignore. Here is an
example to ignore Auto-mounted disks that are recognized on each "disk interval":
allow_remote_disk_info
Default: Yes
This key has been introduced in the Raw Configuration section to make the Device Id of shared drive and local drive identical. You
are required to set this key as No to enable this feature.
This feature is introduced because of the following two reasons.
1.
When file system is mounted on linux through cifs, then, on fresh deployment of the cdm probe, the Device Id and Metric Id for QoS
and alarms of respective mounted file system are missing.
qos_disk_total_size
Default: No
sliced_cpu_interval
sliced_memory_interval
Sometimes, the probe can take more than expected time to execute commands (such as VMSTAT and SAR) causing internal alarms.
Configuring time in seconds using the sliced_cpu_interval and sliced_memory_interval keys through the raw configuration section,
enables you to avoid that delay.
the probe collects data through VMSTAT command for (Interval(5 min) 10 seconds), that is, for 290 seconds. Thus, the probe does not
generate internal alarms and seamlessly generates QOS. If still the problem persists, you can increase the sliced_memory_interval few
more seconds.
These keys have been introduced for AIX platform in the Raw Configuration section.

target string.
Regular
expression
Type of regular
expression
Explanation
[A-Z]
Standard (PCRE)
[A-Z:\\]
Custom
box
Standard (PCRE)
[*.\\]
Custom
Standard (PCRE)
\d*
Custom
v5.5 cdm IM GUI Reference

Contents:
Setup Tab
General Tab
Cluster Tab
Status Tab
Disk Usage
UNIX platforms
Delete a Disk
The Multi CPU Tab
Advanced Tab
Custom Tab
New CPU Profile
New Disk Profile
New Memory Profile
Setup Tab
The Setup tab is used to configure general preferences for the probe. There are three tabs within this tab: General, Control Properties and Mes
sage Definitions. A fourth tab, the Cluster tab, appears if the probe is running within a clustered environment.
General Tab

Log level
Log size
Specifies the size of the probe's log file where probe-internal log messages are written. Upon reaching this size, the contents of the file
are cleared.
Default: 100 KB
If selected, the probe generates an alarm on each sample. If not selected, the probe waits for the number of samples (specified in the Sa
mples field of the Control properties tab) before sending the alarm. This check box is selected by default.
For example, if the value in the Interval field is set to 1 minute and the value in the Samples field is set to 2, under the Control
Properties tab, and if this:
Option is Unchecked: the first alarm will be generated in 2 minutes and the respective alarms will be generated in 1 minute time
interval each.
Option is Checked: the first alarm will be generated in 1 minute and the respective alarms will be generated in 1 minute time interval
each.
Note: The sample collected at the start of the probe is considered as the first sample. The sample count is cleared on de-activation of

Many QoS messages use the host name as their target, by default. If selected, the target name is changed to be the same as the QoS
source name.
Calculate Load Average per Processor

For all Unix based systems, the system load measures the computational work that the system is performing. This means that if your
system has a load of 4, four running processes are either using or waiting for the CPU. Load average refers to the average of the
computers load over several periods of time. This option enables you to calculate the load average per processor and is available for
Linux, Solaris, AIX and HP-UX platforms.
Default: Selected
The fields are divided into the following three sections:
Disk properties
CPU properties
Interval
Samples

Allows you to specify the time limit in minutes between sending of QoS data. For example, If the interval is set to 5 minutes and number
of samples is set to 5, the CPU utilization will be the average for the last 25 minutes. This field is common for all three sections.
Ignore Filesystems
Defines the filesystem to be excluded from monitoring. This field is specific to Disk Properties section only. For example, specifying the
regular expression C:\\ in this field excludes the Disk C of the system from monitoring. A red symbol is displayed next to the disk drive
which is excluded from monitoring in the Disk usage section of the Status tab.
Specifies the type of the file system to be monitored as a regular expression. For example, specify ext* in this field to enable monitoring
of only file systems such as ext4 or ext5.
Timeout
Specifies the time limit for the probe to collect CPU, Disk and Memory related data. This option is useful at time of disk fail/crash in stale
File system to avoid hang situation for the probe. A default timeout of 5 seconds can be used to avoid hang situation to get disk statistics.
But when system is having high CPU load, 5 seconds timeout is not good enough in certain situations. Recommended timeout is 10
seconds and should be increased under situations like high CPU load. This option is available for nonwindows platforms only, like Linux.

QOS_CPU_USAGE

Here, Target is the new QoS target to be set and Source is the QoS source for which target need to be changed. Both of these can be
configured by user.
QOS_CPU_MULTI_USAGE
'qos_cpu_multi_usage' AND (target NOT LIKE 'User%' AND target NOT LIKE
'System%' AND target NOT LIKE 'Wait%' AND target NOT LIKE 'Idle%')
Declare @Target varchar(100) Declare @Source varchar(100) SELECT

@Target = 'Total' SELECT @Source = 'tsuse10-32' UPDATE dbo.s_qos_data
SET target=@Target+RIGHT(target,2) WHERE source LIKE @Source AND probe
LIKE 'cdm' AND qos IN ('qos_cpu_multi_usage') AND (target NOT LIKE
'User%' AND target NOT LIKE 'System%' AND target NOT LIKE 'Wait%' AND
target NOT LIKE 'Idle%')

AND (qos LIKE'QOS_MEMORY_PERC_USAGE' or qos LIKE
'QOS_MEMORY_PAGING_PGPS' or qos LIKE 'QOS_MEMORY_PAGING' or qos LIKE
'QOS_MEMORY_PHYSICAL' or qos LIKE 'QOS_MEMORY_PHYSICAL_PERC' or qos
LIKE 'QOS_MEMORY_SWAP' or qos LIKE 'QOS_MEMORY_SWAP_PERC')
SET target=@Target
WHERE
probe LIKE 'cdm'
AND (qos LIKE'QOS_MEMORY_PERC_USAGE' or qos LIKE
'QOS_MEMORY_PAGING_PGPS' or qos LIKE 'QOS_MEMORY_PAGING' or qos LIKE
'QOS_MEMORY_PHYSICAL' or qos LIKE 'QOS_MEMORY_PHYSICAL_PERC' or qos
LIKE 'QOS_MEMORY_SWAP' or qos LIKE 'QOS_MEMORY_SWAP_PERC')
The Message Definitions tab enables you to customize the sent messages whenever a threshold is breached. A message is defined as a text
string with a severity level. Each message has a token that identifies the associated alarm condition.
Message Pool
This section lists all messages with their associated message ID. You can right-click in the message pool window to create a new
message and edit/delete an existing message.
Active Messages
This section contains tabs to allow you to associate messages with the thresholds. You can drag the alarm message from the message
pool and drop it into the threshold field. The available tabs are explained below:
CPU
High (error) threshold for individual CPU usage (alarms are sent when one of the CPUs in multi-CPU systems breaches the
threshold).
the threshold).
Disk
To modify the thresholds for disks, double click the disk-entries under the Status tab.
Memory
Depends on what memory view is selected in the memory usage graph, where you may toggle among three views (see the Status
tab).
Physical memory
Swap memory (Unix systems)
Computer
Other

Cluster Tab
<cluster ip>
<cluster name>
Follow these steps:
3. Click OK.
Status Tab
the cdm probe GUI.
Graphs
yellow.
Memory usage: three separate graphs (% of total available memory, physical, and virtual memory). Use the buttons M, S, and P on the
top right corner of the graph to toggle through the three graphs.
the probe GUI.

Disk Usage
Note: When using NFS mounts in the cdm probe, be aware that the server where the mount point is pointing will appear in the
discovery in USM.

New Share
Edit
Delete
UNIX platforms
your selections.
system.
selections.
Threshold settings
QoS
Delete a Disk
The Multi CPU Tab
The thresholds and options are explained below:
Maximum
threshold).
Difference
Advanced Tab
The Advanced tab enables you to customize the QoS messages, for example an alarm on processor queue length, an alarm on detected reboot,
and paging measurements.
Select any of the following settings to send the QoS messages as per the time intervals defined under the Control properties tab.
Processor Queue Length (For Windows)/System Load (Processor Queue Length)(For AIX, SGI, Linux and Solaris)
Measures the number of queued processes, divided by the number of processors waiting for CPU time for the system.
Load Average 1 min
Specifies the average system load over the last one minute.
Load Average 5 min
Specifies the average system load over the last five minutes.
Load Average 15 min
Specifies the average system load over the last fifteen minutes.
Notes:
The values of the Load Average metrics are calculated per processor. These are dependent on the field Calculate Load
Average per Processor under the Setup -> General tab.
Sampling is not applicable for the three Load Average Metrics.
Memory Usage
Memory in %
and higher).

Swap Memory Usage
Swap Memory in %
CPU Usage
This section is divided into two tabs: Total CPU and Individual CPU. All measurements in these are in percentage.

Measures how much time the CPU spends on user applications and high-level system functions. Even when the CPU usage is 0%,
the CPU is performing basic system tasks, such as responding to mouse movements and keyboard input. The QoS message includes
CPU User, CPU System and optionally CPU Wait information. The optional CPU Wait information requires you to select the CPU Wait
is included in CPU Usage (Total) option.
CPU User
CPU System
Measures the time spent by the CPU on system tasks.
CPU Wait
CPU Idle
Alarm on Processor Queue Length (For Windows)/Alarm on System Load (For AIX, SGI Linux and Solaris)
Select this alarm setting to check the processor queue length. The processor queue length measures the number of threads that are in
the server's processor queue waiting to be executed by the CPU. All servers, whether they have a single CPU, or multiple CPUs, have
only one processor queue. The processor queue length is a measurement of the last observed value, and it is not an average of any kind.
Alarm messages are generated according to the specified threshold value .
Default: 4.
Notes:

Select this option if you want an alarm to be sent when the average system load over the last one minute exceeds the specified
threshold.
Max. Load Average
Default: 0.9
Select this option if you want an alarm to be sent when the average system load over the last five minutes exceeds the specified
threshold.
Max. Load Average
Default: 0.9
Select this option if you want an alarm to be sent when the average system load over the last fifteen minutes exceeds the specified
threshold.
Max. Load Average
Default: 0.9
CPU Usage options:
Select this option if you want the QoS message on CPU Total to include CPU User, CPU System and CPU Wait. Otherwise, the CPU
Total includes only CPU User and CPU System values.
Lparstat i command
Paging measured in
Paging is the amount of memory which has been sent to or read from virtual memory. This option lets you select the paging to be
measured in one of the following units:
Note: When changing the paging selection, the header of the Paging graph on the Status tab immediately changes to show the
selected unit, but the values in the graph do not change until the next sample is measured.

Custom Tab
You can right-click inside the dialog to create new custom profiles to monitor the CPU, disk or memory. Once a custom profile is created you can
select one or more custom profiles to edit, delete or activate/deactivate as and when required.
New CPU Profile

New Disk Profile
change.
New Memory Profile

You can configure the probe to monitor local disks as well as shared disks (cluster). When monitoring shared disks (such as NFS mounts) over
low-performance or over-utilized lines, you may experience slow response times. If quota is turned on for a disk on a Windows system, the size
reported is the total size, and the free disk space is calculated after quota.
Note: This probe can be configured using the probe configuration interface or by copying configuration parameters from another cdm pr
obe.
How to set up disk monitoring

How to set up CPU monitoring
How to set up memory monitoring
Alarm Thresholds
Configuring Network Disk State Monitoring
This section describes the minimum configuration settings required to configure the cdm probe for local disk monitoring.
Follow these steps:
2. Select the disk you want to monitor from the list of all available disks which are displayed under the Disks node.
3. Enable the alarms (either in Mb or in percentage) and QoS from the Alarm Thresholds and Disk Usage sections under the Disk Usage
node.
4. Specify the time interval in minutes during which the probe requests for data from the Disk Configuration section under the Disks node.
Note: If the monitored environment also includes cluster disks, these disks are also included in the diskname node with the same
alarms configurations as local disks. However, for such environments, a Cluster section is displayed in the cdm node where you can
view and modify alarm and QoS sources for the cluster resources.

Follow these steps:
2. Enable the alarms for Processor Queue Length from the Processor Queue Length section under the Processor node and alarms for T
otal CPU Usage from the Total CPU Usage section under the Processor node. Note that the QoS for Total CPU Usage and Processo
r Queue Length are enabled by default.
ssor node.

Follow these steps:
2. Enable the alarms and Qos for Memory Metrics from the Alarm Thresholds section under the Memory node.
3. Specify the time interval in minutes during which the probe requests for data from the Memory Configuration section under the Memory
node.
Alarm Thresholds
allow the probe to:

The cdm probe allows you to monitor the availability state and usage of network disks.
Follow these steps to set up network disk monitoring in windows robots:
Note: To configure cdm probe on robots deployed in other environments such as Linux or Solaris, proceed directly to step 6 since a
shared network disk profile can only be created on windows robots.

5. Click Submit.

Default: Yes
Default: No

cdm node
<hostname> node
Disks node
<diskname> node
Disk Usage node
Memory node
Memory Paging node
Swap Memory node
Total Memory node
Network node
Processor node
Individual CPU node
Total CPU node
Device Iostat node
cdm node
Navigation: cdm
Log Level: Sets the amount of detail that is logged to the log file. Default: 0 - Fatal
Log size (KB): Sets the maximum size of the log. When using the up and down arrows, the value increases or decreases by 5. Default:
100 KB
cdm > Cluster
This section is only visible in when monitoring clustered environments and displays the cluster resources associated to the monitored system.
<cluster ip>
<cluster name>
cdm > Messages

<hostname> node

Disks node

shared drives of the host system. For example, cifs is a shared windows disk that is mounted on the Linux environment, and gfs which is a shared
disk of a clustered environment.
Interval (minutes): specifies the time in minutes for how often the probe retrieves sample data. Default: 15
Samples: specifies how many samples the probe is keeping in memory for calculating average and threshold values. Default: 4
set to 5 minutes and number of samples is set to 5, the CPU utilization is the average for the last 25 minutes. Default: 1
field excludes the Disk C of the system from monitoring. and also stops displaying the disk in navigation pane.
field will enable monitoring of only file systems such as ext4 or ext5.

This section lets you configure alarms when a specific disk is missing (not mounted or available) for monitoring.




Default: //
Important! You can only add shared disks to be monitored in windows robots.
<diskname> node
sent.
been breached.
sent.
Disk Usage node
Between each sample: The change in disk usage is calculated after each sample is collected
Network Connection
<diskname> node.
Memory node

set to 5 minutes and number of samples is set to 5, the CPU utilization reported will be the average for the last 25 minutes. Default: 1
Set QoS Target as 'Memory': sets the QoS target to Memory. Default: Not selected
Memory Paging node

Physical Memory
System Memory
User Memory
Swap Memory node
Total Memory node
Navigation: cdm > Memory > Total Memory > Memory Usage (%)
Network node

monitored system.
Processor node

Target as 'Total': Select this checkbox if you want the QoS target to be set to Total. Default: 5
Individual CPU node

Individual CPU User - llets you generate QoS data on the amount of time during which CPU executed processes in kernel mode.
Total CPU node
exceeded.
Navigation: cdm > iostat

devices.
value must be less than Interval (minutes) field value. Default: 10
Device Iostat node

(OS) as follows:
Operating System
Linux
Iostat Monitors
Solaris

AIX


low-performance or over-utilized lines, you may experience slow response times. When configuring the cdm probe you start with the Status tab.
The Status tab displays graphs of the CPU usage, Memory usage, and Paging activity, and a list of file systems being monitored.
This probe can be configured using the probe configuration interface or by copying configuration parameters from another cdm probe.
If quota is turned on for a disk on a Windows system, the size reported is the total size, and the free disk space is calculated after quota.

Probe Defaults

This article describes the minimum configuration settings required to configure the cdm probe for local disk monitoring.
Follow these steps:
1.

2. Select the disk you want to monitor from the list of all available disks which are displayed in the Disk Usage section under the Status tab
. This tab is the default tab of the cdm probe GUI.
3. Enable the QoS (either in Mb or in percentage) and alarms from the Disk Usage and thresholds tab.
4. Specify the time interval in minutes during which the probe requests for data from the Control Properties tab under the Setup tab.

Follow these steps:
2. Enable the QoS by selecting the desired options under the Advanced tab.
3. Enable the alarms by configuring the desired values in the CPU usage section under the Status tab.

Follow these steps:
3. Enable the alarms by configuring the desired values in the Memory usage section under the Status tab.
Probe Defaults
Follow these steps:

Note: When performing this operation with the cdm probe, you must ensure that the disk partitions are the same on the source and the
target computers.
Follow these steps:

5.

ignore_device
ignore_filesystem
Default: Yes
a. When file system is mounted on linux through cifs, then, on fresh deployment of the cdm probe, the Device Id and Metric Id for QoS
b. On restarting, the probe is unable to mark cifs drives as network drive and hence generates wrong Device Id and Metric Id.
qos_disk_total_size
Default: No

target string.
Regular
expression
Type of regular
expression
Explanation
[A-Z]
Standard (PCRE)
[A-Z:\\]
Custom
box
Standard (PCRE)
[*.\\]
Custom
Standard (PCRE)
\d*
Custom

Contents:
Setup Tab
General Tab
Cluster Tab
Status Tab
Disk Usage
UNIX platforms
Delete a Disk
The Multi CPU Tab
Advanced Tab
Custom Tab
New CPU Profile
New Disk Profile
New Memory Profile
Setup Tab
The Setup tab is used to configure general preferences for the probe. There are tabs within this tab that you can use to specify General, Control
Properties and Message Definitions. A fourth tab, the Cluster tab, displays if the probe is running within a clustered environment.
General Tab

Log level
Sets the level of detail written to the log file. Log as little as possible during normal operation, to minimize disk consumption.
Log size
Sets the size of the probe's log file where probe-internal log messages are written. Upon reaching this size, the contents of the file are cleared.
The default size is 100 KB.
If selected, the probe generates an alarm on each sample. If not selected, the probe waits for the number of samples (specified in the samples
field of the Control properties tab) before sending the alarm. This check box is selected by default.
For example, Interval values is set to 1 minute and number of sample is set to 2 and:
Option is Unchecked: the first alarm will be generated in 2 minutes and the respective alarms will generate in 1 minute time interval
each.
Option is Checked: the first alarm will be generated in 1 minute and the respective alarms will generate in 1 minute time interval each.
Note: The sample collected at the start of the probe is considered to be the first sample. The sample count is cleared on de-activation of

A number of QoS messages by default use the host name as their target. If selected, the target name is changed to be the same as the QoS
source name.
The fields are separated into the following three sections:
Disk properties
CPU properties
Interval
Samples

Allows you to specify the time limit in minutes between sending of QoS data. For example, If the interval is set to 5 minutes and number of
samples is set to 5, the CPU utilization will be the average for the last 25 minutes. This field is common for all three sections.
Ignore Filesystems
Defines the filesystem to be excluded from monitoring. This field is specific to Disk Properties section only. For example, specifying the regular
expression C:\\ in this field excludes the Disk C of the system from monitoring. A red symbol is displayed next to the disk drive which is excluded
from monitoring in the Disk usage section of the Status tab.
Specifies the type of the file system to be monitored as a regular expression. For example, specifying ext* in this field will enable monitoring of
only file systems such as ext4 or ext5.
Timeout
Specifies the time limit for the probe to collect CPU, Disk and Memory related data. This option is useful at time of disk fail/crash in stale File
system to avoid hang situation for the probe. A default timeout of 5 seconds was used to avoid hang situation to get disk statistics. But when
system is having high cpu load, 5 seconds timeout is not good enough in certain situations. Recommended timeout is 10 seconds and should be
increased under situations like high cpu load.
Note: This option is available for nonwindows platforms only, like Linux.

QOS_CPU_USAGE

Here, Target is the new QoS target to be set and Source is the QoS source for which target need to be changed. Both of these can be configured
by user.
QOS_CPU_MULTI_USAGE



SET target=@Target
WHERE
probe LIKE 'cdm'
The Message Definitions tab offers functionality to customize the messages sent whenever a threshold is breached. A message is defined as a
text string with a severity level. Each message has a token that identifies the associated alarm condition.
Message Pool
This section lists all messages with their associated message ID. You can right-click in the message pool window to create new message and
edit/delete an existing message.
Active Messages
This section contains tabs to allow you to associate messages with the thresholds. You can drag the alarm message from the message pool and
drop it into the threshold field. The available tabs are explained below:
CPU
High (error) threshold for individual CPU usage (alarms are sent when one of the CPUs in multi-CPU systems breaches the threshold).
the threshold).
Disk
The thresholds for disks can be modified by double-clicking the disk-entries under the Status tab.
Memory
Depends on what memory view is selected in the memory usage graph, where you may toggle among three views (see the Status tab).
Memory usage
Physical memory
Computer
Other
Cluster Tab
<cluster ip>
<cluster name>
Follow these steps:
3. Click OK.
Status Tab
the cdm probe GUI.
Graphs
yellow.
Memory usage: three separate graphs (% of total available memory, physical, and virtual memory). Use the buttons M, S, and P on the top right
corner of the graph to toggle through the three graphs.

the probe GUI.

Disk Usage
discovery in USM.

New Share
Edit
Delete
UNIX platforms

your selections.
system.
selections.
Threshold settings
QoS
Delete a Disk
The Multi CPU Tab
Maximum
threshold).
Difference
Advanced Tab
Use the Advanced tab to customize the QoS messages, for example an alarm on processor queue length, an alarm on detected reboot, and
paging measurements.
Selecting any of the following settings enables QoS messages to be sent as per the time intervals defined under Control properties tab.
Processor Queue Length (Windows only)
Measures the number of queued processes, divided by the number of processors, waiting for time on the CPU for Windows system. For
AIX, SGI, Linux and Solaris, this QoS message refers to System Load.
Memory Usage
Memory in %
and higher).

Swap Memory Usage
Swap Memory in %
CPU Usage
This section is divided into two tabs: Total CPU and Individual CPU. These measurements are all in %.

Measures how much time the CPU spends on user applications and high-level system functions. Even when the CPU usage is 0%, the
CPU is still performing basic system tasks, like responding to mouse movements and keyboard input. The QoS message includes CPU
User, CPU System and optionally CPU Wait information. The optional CPU Wait information requires you to select the CPU Wait is
included in CPU Usage (Total) option.
CPU User
CPU System
Measures the time the CPU spends on system tasks.
CPU Wait
CPU Idle
Alarm on Processor Queue Length
For AIX, SGI Linux and Solaris, this option monitors system load.
Select this alarm setting to check the processor queue length. The processor queue length measures the number of threads that are in the
server's processor queue waiting to be executed by the CPU. All servers, whether they have a single CPU, or multiple CPUs, have only one
processor queue. The processor queue length is a measurement of the last observed value, and it is not an average of any kind. Alarm messages
are generated according to the threshold value you specify. The default value is 4.
Notes:

CPU Usage options:
Select this option if you want the QoS message on CPU Total to include CPU User, CPU System and CPU Wait. Otherwise, the CPU Total
includes only CPU User and CPU System values.
Lparstat i command
Paging measured in
Paging is the amount of memory which has been sent to or read from virtual memory. This option lets you select the paging to be measured in
one of the following units:
Note: When changing the paging selection, the header of the Paging graph on the Status tab will immediately change to show the
selected unit, but the values in the graph will not change until the next sample is measured.

Custom Tab
New CPU Profile

New Disk Profile
change.
New Memory Profile

low-performance or over-utilized lines, you may experience slow response times. If quota is turned on for a disk on a Windows system, the size
reported is the total size, and the free disk space is calculated after quota.
Note: This probe can be configured using the probe configuration interface or by copying configuration parameters from another cdm pr
obe.

Alarm Thresholds

This section describes the minimum configuration settings required to configure the cdm probe for local disk monitoring.
Follow these steps:
1.

node.
Note: If the monitored environment also includes cluster disks, these disks are also included in the diskname node with the same
alarms configurations as local disks. However, for such environments, a Cluster section is displayed in the cdm node where you can
view and modify alarm and QoS sources for the cluster resources.

Follow these steps:
ssor node.

Follow these steps:
node.
Alarm Thresholds
allow the probe to:

The cdm probe allows you to monitor the availability state and usage of network disks.
Follow these steps to set up network disk monitoring in windows robots:
Note: To configure cdm probe on robots deployed in other environments such as Linux or Solaris, proceed directly to step 6 since a
shared network disk profile can only be created on windows robots.

5. Click Submit.

Default: Yes
Default: No

cdm node
<hostname> node
Disks node
<diskname> node
Disk Usage node
Memory node
Memory Paging node
Swap Memory node
Total Memory node
Network node
Processor node
Individual CPU node
Total CPU node
Device Iostat node
cdm node
Navigation: cdm
100 KB
Count Buffer-Cache as Used Memory (Linux and Solaris only): Counts the buffer and cache memory as used memory while
monitoring the physical and system memory utilization. If not selected, the buffer and cache memory is counted as free memory.
cdm > Cluster
This section is only visible in when monitoring clustered environments and displays the cluster resources associated to the monitored system.
<cluster ip>
<cluster name>
cdm > Messages

<hostname> node

Disks node

shared drives of the host system. For example, cifs is a shared windows disk that is mounted on the Linux environment, and gfs which is a shared
disk of a clustered environment.
field excludes the Disk C of the system from monitoring. and also stops displaying the disk in navigation pane.
field will enable monitoring of only file systems such as ext4 or ext5.




Default: //
Important! You can only add shared disks to be monitored in windows robots.
<diskname> node
sent.
been breached.
sent.
Disk Usage node
Network Connection
<diskname> node.
Memory node

Memory Paging node

Physical Memory
System Memory
User Memory
Swap Memory node
Total Memory node
Network node

monitored system.
Processor node

Individual CPU node

Total CPU node
exceeded.

devices.
Device Iostat node

(OS) as follows:
Operating System
Linux
Iostat Monitors
Solaris

AIX



Probe Defaults

Follow these steps:
5.


Follow these steps:

Follow these steps:
Probe Defaults
Follow these steps:

target computers.
Follow these steps:


ignore_device
ignore_filesystem
Default: Yes
qos_disk_total_size
Default: No

target string.
Regular
expression
Type of regular
expression
Explanation
[A-Z]
Standard (PCRE)
[A-Z:\\]
Custom
box
Standard (PCRE)
[*.\\]
Custom
Standard (PCRE)
\d*
Custom

Contents:
Setup Tab
General Tab
Cluster Tab

Status Tab
Disk Usage
UNIX platforms
Delete a Disk
The Multi CPU Tab
Advanced Tab
Custom Tab
New CPU Profile
New Disk Profile
New Memory Profile
Setup Tab
The Setup tab is used to configure general preferences for the probe. There are tabs within this tab that you can use to specify General, Control
Properties and Message Definitions. A fourth tab, the Cluster tab, displays if the probe is running within a clustered environment.
General Tab

Log level
Log size
each.

source name.
The fields displayed in the above dialog are separated into the following three sections:
Disk properties
CPU properties
Interval
Samples

Ignore Filesystems
Specifies the type of the file system to be monitored as a regular expression. For example, specifying ext* in this field will enable monitoring of
only file systems such as ext4 or ext5.
Timeout

QOS_CPU_USAGE

by user.
QOS_CPU_MULTI_USAGE




SET target=@Target
WHERE
probe LIKE 'cdm'

Message Pool
Active Messages
CPU
the threshold).
Disk
Memory
Memory usage
Physical memory
Computer
Other
Cluster Tab
<cluster ip>
<cluster name>
Follow these steps:
3. Click OK.
Status Tab
the cdm probe GUI.

Graphs
yellow.
the probe GUI.

Disk Usage
discovery in USM.

New Share
Edit
Delete
UNIX platforms

your selections.
system.
selections.
Threshold settings
QoS
Delete a Disk
The Multi CPU Tab
Maximum
threshold).
Difference
Advanced Tab

Memory Usage
Memory in %
and higher).

Swap Memory Usage
Swap Memory in %
CPU Usage

CPU User
CPU System
CPU Wait
CPU Idle
Notes:

CPU Usage options:

Lparstat i command
CPU User = CPU user
*EntCap)/TotCapacity;
cpuStats->fWait = (double)((cpuStats->fWait * cpuStats->fEntCap)/TotCapacity);
cpuStats->fIdle = (double)((cpuStats->fIdle * cpuStats->fEntCap)/TotCapacity);
Paging measured in

Custom Tab
New CPU Profile

New Disk Profile

change.
New Memory Profile


This article explains how to configure the cdm probe.
Alarm Thresholds

Follow these steps:
node.

Follow these steps:
ssor node.

Follow these steps:
node.
Alarm Thresholds
allow the probe to:

Default: Yes
Default: No

<hostname> node
Disks
<diskname> node
Disk Usage node
Add a Shared Disk for Monitoring
Memory node
Memory Paging node
Swap Memory node
Total Memory node
Network node
Processor node
Individual CPU node
Total CPU node
Device Iostat node
cdm node
Navigation: cdm
100 KB
cdm > Messages
<hostname> node

Disks

The Disks node lets you configure the global monitoring metrics and default attribute values for each individual disk. The Disks node also includes
the shared drives of the host system. For example, cifs is a shared windows disk that is mounted on the Linux environment, and gfs which is a
Ignore Filesystems: defines the filesystem to be excluded from monitoring. For example, specifying the regular expression C:\\ in this
field excludes the C drive of the system from monitoring and also stops displaying the disk in navigation pane.



<diskname> node
The disk name node lets you configure alarms and QoS for disk availability and size for an individual disk.
sent.
been breached.
sent.
Disk Usage node
Thresholds and alarms attributes are the same as listed in Disk Usage Change Defaults.
As a system administrator you want to monitor the availability and usage of the shared disk. The disk availability ensures that it is accessible to
authorized users and application. You want get an alarm when the disk is not available and QoS data on disk usage. The CPU, Disk, and Memory
Performance probe lets you add a shared disk or folder which can be configured for monitoring for generating QoS data and alarms as you do for
a local disk.
Follow these steps:
1. Click the Options icon next to the Disks node in the navigation pane.
2. Select Add New Share.
3. Configure following fields in the Add New Share dialog:
Share: defines the network path of the shared disk for folder. The network location is specified in the \\computer\share format.
User: defines the user name for authenticating the probe to have appropriate access to the shared disk or folder. Define the user
name in <domain name>\<user name> when the shared disk is available on a domain.
Password: defines the password for authenticating the user.
Alarm Message: specifies the alarm message when the disk is not available. Default: ConnectionError
Enable Folder Availability Monitoring: activates the QoS data on shared disk availability. Default: Not selected
4. Click Submit.
The shared disk is added under the Disks node in the navigation pane. You can select the shared disk and update user name, password, and
disk availability monitoring properties.
Memory node

Memory Paging node

Physical Memory
System Memory
User Memory
Swap Memory node
Total Memory node
Network node

monitored system.
Processor node

Individual CPU node

Total CPU node
exceeded.

devices.
Device Iostat node

(OS) as follows:
Operating System
Linux
Iostat Monitors
Solaris

AIX


Contents
Probe Defaults


Follow these steps:

Follow these steps:
5.


Follow these steps:
Probe Defaults
Follow these steps:

target computers.
Follow these steps:


ignore_device
ignore_filesystem
Default: Yes
qos_disk_total_size
Default: No

target string.
Regular
expression
Type of regular
expression
Explanation
[A-Z]
Standard (PCRE)
[A-Z:\\]
Custom
box
Standard (PCRE)
[*.\\]
Custom
Standard (PCRE)
\d*
Custom

There are five main tabs:
Setup
Status
Multi CPU
Advanced
Custom
Setup Tab
The Setup tab is used to configure general preferences for the probe. There are tabs within this tab that you can use to specify general, control
properties and message definitions. A fourth tab, the Cluster tab, displays if the probe is running within a clustered environment.
General Tab
Log level
Log size
each.

source name.

Disk properties
CPU properties
Interval
Samples

Ignore Filesystems
from monitoring in the Disk usage section of the Status tab..
Timeout

QOS_CPU_USAGE

by user.
QOS_CPU_MULTI_USAGE



SET target=@Target
WHERE
probe LIKE 'cdm'


Message Pool
Active Messages
CPU
the threshold).
Disk
Memory
Memory usage
Physical memory
Computer
Other
Cluster Tab
It displays a list of detected virtual groups belonging to the cluster. By editing the entries (refer Edit Alarm or QoS source section), you can set the
alarm source and QoS source to be used for disks belonging to that virtual group.
<cluster ip>
<cluster name>

Follow these steps:
3. Click OK.
Status Tab
the cdm probe GUI.
Graphs
yellow.
the probe GUI.

Disk Usage
The disk usage list displays the disks installed on the system and the amount of free space on each disk. You can monitor each disk individually,
with individual threshold values, messages and severity levels.
discovery in USM.

New Share
Edit
Delete

UNIX platforms

your selections.
system.
selections.
Threshold settings
QoS
Delete a Disk


The Multi CPU Tab
Maximum
threshold).
Difference
Advanced Tab
Memory Usage
Memory in %
and higher).

Swap Memory Usage

Swap Memory in %
CPU Usage

CPU User
CPU System
CPU Wait
CPU Idle
Notes:
To enable the QoS metric QOS_PROC_QUEUE_LEN for per cpu, you are required to add a key system_load_per_cpu with

CPU Usage options:
Lparstat i command
Paging measured in

Custom Tab
New CPU Profile
New Disk Profile
change.
New Memory Profile


Overview
Using the Admin Console to Access the cdm Configuration GUI
cdm
Probe Information
General Configuration
Messages
Configuring Computer Uptime and System Reboot QoS Data
Disks
Disk Configuration
Disk Missing Defaults
Disk Usage Defaults
Inode Usage Defaults (UNIX only)
Disk Usage Change Defaults
Disk Read (B/S)
Disk Write (B/S)
Disk Read and Write (B/S)
<diskname> Configuration
Disk Usage Configuration
Disk Usage Change Configuration
<diskname> Inode Usage Configuration
Memory
Memory Paging Configuration
Physical Memory Configuration
Swap Memory Configuration
Total Memory Configuration
Network
Processor
Individual CPU Configuration
Total CPU Configuration
Iostat (Linux, Solaris, and AIX)
Device Iostat Configuration
Overview
The following table provides an overview of the configuration settings available for the cdm probe.
Node
Subnode
cdm
Available settings
Probe information and logging attributes; view alarm messages
<hostname>
Disks
Computer Uptime and System Reboot alarms for the cdm host system
Defaults applied to all newly-discovered disks
<diskname1>
'disk missing' alarm message attributes
Disk Usage
Usage alarms and threshold values for the <diskname1> disk
Disk Usage Change
Change in usage alarms and threshold values for <diskname1>
<diskname2>
Memory
Settings for <diskname2> (same as above)
Memory attributes (interval, samples, QoS interval, QoS target)
Memory Paging
Alarms and threshold values
Physical Memory
Swap Memory
Total Memory
Processor
Processor attributes (CPU configuration, queue length)
Individual CPU
Total CPU

The configuration information and options are available through the Admin Console cdm Configuration GUI. The navigation pane organizes cdm
configuration into the following nodes:
Disks
Memory
Network
Processor
Iostat (Linux, Solaric, and AIX)
cdm
Navigation: cdm
This section lets you view probe and QoS information, change the log level, and set data management values.
Probe Information


100 KB
Messages

You can configure whether or not to enable computer uptime QoS data and system reboot alarms by selecting the following options:
Publish Data: Publishes QoS data on computer uptime; unchecked by default. All other fields are read-only.
cdm > <probe hostname> System Reboot
Publish Alarms: Generates an alarm when the system reboots; unchecked by default
Alarm Message for Detected Reboot: Choose the desired alarm message from the pull-down menu.
See Set Thresholds for more details about setting dynamic, static, Time Over Threshold, and Time To Threshold alarms.
Disks
the shared drives of the host system. For example, cifs is a shared windows disk that is mounted on the Linux environment, and gfs which is a
Disk Configuration
Note: In case, the Send alarm on each sample option is not selected, the probe waits for the number of samples then sends the alarm.
Do not specify 0 (Zero) in this field.
Ignore Filesystems: defines the filesystem to be excluded from monitoring. For example, specifying the regular expression *C:* in this
Disk Usage Defaults
Disk Read (B/S)
thresholds for generating alarms. See Set Thresholds for more details about setting dynamic, static, Time Over Threshold, and Time To
Threshold alarms.
Disk Write (B/S)
Threshold alarms.
and high thresholds for generating alarms. See Set Thresholds for more details.
The disk name node lets you configure alarms and QoS for disk availability and size for an individual disk. See Set Thresholds for more details
about setting dynamic, static, Time Over Threshold, and Time To Threshold alarms.
sent.
been breached.
sent.
You can configure disk usage individually for each monitored disk (diskname1, diskname2, etc). You can set attributes for alarm thresholds, disk
usage (%) and disk usage (MB). See Set Thresholds for more details about setting dynamic, static, Time Over Threshold, and Time To Threshold
alarms.
You can individually configure thresholds and alarm messages sent with changes in disk usage for each monitored disk. See Set Thresholds for
more details about setting dynamic, static, Time Over Threshold, and Time To Threshold alarms.
Summarized over all samples - The change in disk usage is the difference between the latest sample and the first sample in the
Between each sample - The change in disk usage is calculated after each sample is collected

a local disk.
Follow these steps:
4. Click Submit.
Memory


Physical Memory
System Memory
User Memory
Network

monitored system.
Processor

exceeded.
Iostat (Linux, Solaris, and AIX)

devices.

(OS) as follows:
Operating System
Iostat Monitors
Linux

Solaris

AIX


Default: Yes
Default: No

Contents
Probe Defaults
Probe Configuration Interface Installation for cdm
Probe Configuration
Setup Tab
General Tab
Cluster Tab
Status Tab
Delete a Disk
The Multi CPU Tab

Advanced Tab
Custom Tab
New CPU Profile
New Disk Profile
New Memory Profile

Follow these steps:

Follow these steps:
1.


Follow these steps:
Probe Defaults
Follow these steps:

The probe configuration interface is automatically downloaded and installed by the Infrastructure Manager when the probe is deployed on a robot.
Probe Configuration
The CPU, Disk and Memory Monitor (cdm) probe configuration interface displays a screen with tabs for configuring sections of this probe. This
probe can be set up in three types of environments: single computer, multi-CPU and cluster.
Setup
Status
Multi CPU
Advanced
Custom
Setup Tab
General Tab

Log level
Log size
each.

source name.
The fields displayed in the above dialog are separated into the following three sections:
Disk properties
CPU properties
Interval
Samples
Ignore Filesystems
Timeout

QOS_CPU_USAGE

by user.
QOS_CPU_MULTI_USAGE



SET target=@Target
WHERE
probe LIKE 'cdm'
Find the following field description:
Message Pool
Active Messages
CPU
the threshold).
Disk
Memory
Memory usage
Physical memory
Computer
Other
Cluster Tab
<cluster ip>
<cluster name>
Follow these steps:
3. Click OK.
Status Tab
the cdm probe GUI.
Graphs
yellow.
the probe GUI.

Disk Usage
The disk usage section displays the disks installed on the system and the amount of free space on each disk. You can monitor each disk
individually, with individual threshold values, messages and severity levels.
discovery in USM.
New Share
Edit
Delete

UNIX platforms

your selections.
system.
selections.
the "samples window". The number of samples the cdm probe will keep in memory for threshold comparison is set as Samples on the
Setup > Control Properties tab.
Threshold settings
QoS
Delete a Disk


The Multi CPU Tab
Maximum
threshold).
Difference
Advanced Tab
Memory Usage
Memory in %
Notes:
If you have been running CDM version 3.70 or earlier, the QoS settings in the cdm probe GUI are different than CDM version
3.72. However, if CDM version 3.70 or earlier already has created QoS entries in the database for kilobytes per second (Kb/s)
and/or pages per second (Pg/s), these entries will be kept and updated with QoS data from the newer CDM version (3.72 and
higher).

Swap Memory Usage
Swap Memory in %
CPU Usage

CPU User
CPU System
CPU Wait
CPU Idle
Note: If running on a multi-CPU system, the queued processes will be shared on the number of processors. For example, if running on
a system with four processors and using the default Max Queue Length value (4), alarm messages will be generated if the number of
queued processes exceeds 16.

CPU Usage options:

Lparstat i command
CPU User = CPU user
Paging measured in

Custom Tab
New CPU Profile

New Disk Profile
Allow space monitoring: lets you configure three new checkpoints to monitor the disk, which are Disk free space, Inodes free, Space
usage change.
New Memory Profile


ignore_device
ignore_filesystem
Default: Yes
1.
When file system is mounted on linux through cifs, then, on fresh deployment of the cdm probe, the Device Id and Metric Id for QoS
qos_disk_total_size
Default: No

target computers.
Follow these steps:


target string.
Regular
expression
Type of regular
expression
Explanation
[A-Z]
Standard (PCRE)
[A-Z:\\]
Custom
box
Standard (PCRE)
[*.\\]
Custom
Standard (PCRE)
\d*
Custom

Overview
cdm
Probe Information
Messages
Disks
Disk Configuration
Disk Usage Defaults
Disk Read (B/S)
Disk Write (B/S)
Memory
Network
Processor
Overview
The following table provides an overview of the configuration settings available for the cdm probe.
Node
Subnode
cdm
Available settings
Probe information and logging attributes; view alarm messages
<hostname>
Disks
Computer Uptime and System Reboot alarms for the cdm host system
Defaults applied to all newly-discovered disks
<diskname1>
'disk missing' alarm message attributes
Disk Usage
Usage alarms and threshold values for the <diskname1> disk
Disk Usage Change
Change in usage alarms and threshold values for <diskname1>
<diskname2>
Memory
Settings for <diskname2> (same as above)
Memory attributes (interval, samples, QoS interval, QoS target)
Memory Paging
Physical Memory
Swap Memory
Total Memory
Processor
Processor attributes (CPU configuration, queue length)
Individual CPU
Total CPU

In the Admin Console cdm configuration GUI, you can:
Change the Database Connection Properties.
Configure the Data Retention Settings.
Override the Data Retention Settings on Individual QoS Objects.
Schedule Database Maintenance.
Set up Partitioning for Raw Sample Data

Set up Index Maintenance (MS SQL Server)
The configuration information and options are available through the Admin Console cdm Configuration GUI. The navigation pane organizes cdm
configuration into the following nodes:
Disks
Memory
Network
Processor
cdm
Navigation: cdm
Probe Information


100 KB
Messages

You can configure whether or not to enable computer uptime QoS data and system reboot alarms by selecting the following options:
Publish Data: Publishes QoS data on computer uptime; unchecked by default. All other fields are read-only.
cdm > <probe hostname> System Reboot
Publish Alarms: Generates an alarm when the system reboots; unchecked by default
Alarm Message for Detected Reboot: Choose the desired alarm message from the pull-down menu.
Disks

the shared drives of the host system. For example, cifs a shared windows disk that is mounted on the Linux environment, and gfs which is a
Disk Configuration
Note: In case, the Send alarm on each sample option is not selected, the probe waits for the number of samples then sends the alarm.
Do not specify 0 (Zero) in this field.
Ignore Filesystems: defines the filesystem to be excluded from monitoring. For example, specifying the regular expression *C:* in this
Disk Usage Defaults
Disk Read (B/S)
Threshold alarms.
Disk Write (B/S)
Threshold alarms.
and high thresholds for generating alarms. See Set Thresholds for more details.
The disk name node lets you configure alarms and QoS for disk availability and size for an individual disk. See Set Thresholds for more details
about setting dynamic, static, Time Over Threshold, and Time To Threshold alarms.
sent.
been breached.
sent.
You can configure disk usage individually for each monitored disk (diskname1, diskname2, etc). You can set attributes for alarm thresholds, disk
usage (%) and disk usage (MB). See Set Thresholds for more details about setting dynamic, static, Time Over Threshold, and Time To Threshold
alarms.
You can individually configure thresholds and alarm messages sent with changes in disk usage for each monitored disk. See Set Thresholds for
more details about setting dynamic, static, Time Over Threshold, and Time To Threshold alarms.
Summarized over all samples - The change in disk usage is the difference between the latest sample and the first sample in the
Between each sample - The change in disk usage is calculated after each sample is collected

a local disk.
Follow these steps:
4. Click Submit.
Memory

Physical Memory
System Memory
User Memory
Network
monitored system.
Processor

exceeded.

devices.

(OS) as follows:
Operating System
Linux
Iostat Monitors
Solaris

AIX

Updated the QoS Metrics topic.

Contents
Probe Defaults
Probe Configuration
Setup Tab
General Tab
Cluster Tab

Status Tab
Delete a Disk
The Multi CPU Tab
Advanced Tab
Custom Tab
New CPU Profile
New Disk Profile
New Memory Profile
This probe can be configured using the probe configuration interface or by copying configuration parameters from another cdm probe (see the Infr
astructure Manager documentation).
Probe Defaults
Follow these steps:

Probe Configuration
The CPU, Disk and Memory Monitor (cdm) probe configuration interface displays a screen with tabs for configuring sections of this probe. This
probe can be set up in three types of environments: single computer, multi-CPU and cluster.
Setup
Status
Multi CPU
Advanced
Custom
Setup Tab
General Tab

Log level
Log size
each.

source name.
Disk properties
CPU properties
Interval
Samples
Ignore Filesystems
Defines the filesystem to be excluded from monitoring. This field is specific to Disk properties section only. For example, *C:* will not monitor the
disk usage matching the given regular expression *C:* (or Disk C).
Timeout

QOS_CPU_USAGE

by user.
QOS_CPU_MULTI_USAGE



SET target=@Target
WHERE
probe LIKE 'cdm'
Message Pool
Active Messages
CPU
the threshold).
Disk
Memory
Memory usage
Physical memory
Computer
Other
Cluster Tab
<cluster ip>
<cluster name>
Follow these steps:
3. Click OK.
Status Tab
the cdm probe GUI.
Graphs
yellow.
the probe GUI.

Disk Usage
The disk usage list displays the disks installed on the system and the amount of free space on each disk. You can monitor each disk individually,
with individual threshold values, messages and severity levels. See Disk Usage Modifications for more details.

New Share
Edit
Delete

UNIX platforms

your selections.
system.
selections.
the "samples window". The number of samples the cdm probe will keep in memory for threshold comparison is set as Samples on the
Setup > Control Properties tab.
Threshold settings
QoS
Delete a Disk


The Multi CPU Tab
Maximum
threshold).
Difference
Advanced Tab
Memory Usage
Memory in %
and higher).

Swap Memory Usage
Swap Memory in %
CPU Usage

CPU User
CPU System
CPU Wait
CPU Idle
Note: If running on a multi-CPU system, the queued processes will be shared on the number of processors. For example, if running on
a system with four processors and using the default Max Queue Length value (4), alarm messages will be generated if the number of
queued processes exceeds 16.

CPU Usage options:
Lparstat i command
CPU User = CPU user
Paging measured in
Custom Tab
New CPU Profile

New Disk Profile
Allow space monitoring: lets you configure three new checkpoints to monitor the disk, which are Disk free space, Inodes free, Space
usage change.
New Memory Profile

ignore_device
ignore_filesystem
ignore_filesysem = /<regular expression>/
The value should be a regular expression that would match all disks and/or filesystems that you want the probe to ignore. Here is an example to
ignore Auto-mounted disks that are recognized on each "disk interval":
The following key has been introduced in the Raw Configuration section to make the device Id of shared drive and local drive identical. You are
required to set this key as No to enable this feature.
Default: Yes

target computers.
Follow these steps:

celerra (EMC Celerra Monitoring)
EMC Celerra storage systems support environments which include mainframes, desktops, servers, applications, cloud, and business services.
The EMC Celerra Monitoring (celerra) probe monitors the performance and availability of EMC Celerra storage systems. The celerra probe uses
ssh (a secure shell) in combination with the Celerra command interface provided by EMC. The probe connects to a Celerra Network Server node
to collect and store data and information from the monitored system. You can define alarms that are generated when the specified thresholds are
breached.
More information:
celerra (EMC Celerra Monitoring) Release Notes
v1.6 celerra AC Configuration
This article describes the configuration concepts and procedures for setting up the celerra probe. The following figure provides an overview of the
process you must follow to configure a working probe.
How to monitor a storage system

Provide the path of Java JRE
Add New Resource
Delete Resource
Alarm Thresholds

This section describes the minimum configuration settings required to configure the celerra probe.
Follow these steps:
1. Deploy the celerra probe.

3. Provide the path of Java JRE in the probe.
Refer Provide the path of Java JRE for more information.
4. Add a resource for the celerra system you want to monitor.
Refer Add New Resource for more information.
5. Save the configuration to establish the connection and discover the storage components.
The storage components are automatically discovered by the probe and displayed as nodes.
6. Configure the monitors for the required nodes.

The celerra probe requires Java JRE to gather data about the celerra systems.
Follow these steps:
2. Navigate to General Setup section under the celerra node.
3. Provide the absolute path of Java JRE in the field Java Home.
4. Click Save.
The probe now uses this JRE to connect to the celerra systems.
Add New Resource

You can add a resource in the EMC Celerra Monitoring probe. Each resource represents a profile that can be used as a connection to the probe
through which the probe collects, and stores data and information from the monitored components.
Follow these steps:
1. Click the Options icon next to the celerra node in the navigation pane.
2. Click the Add New Resource option.
The resource is saved and you can configure the resource properties that can be used as a connection to the Celerra system.
Delete Resource
You can delete an existing resource when you no longer need it.
Follow these steps:
1. Click the Options icon beside the Profile-resource name node that you want to delete.
2. Click the Delete Resource option.
The resource is deleted.
Alarm Thresholds
allow the probe to:
v1.6 celerra AC GUI Reference

Contents
celerra Node
Profile-<Resource Name> Node
<Resource Name> Node
Storage Node
<Monitor Name> Node
The EMC Celerra Monitoring probe can handle all common monitoring and data collection tasks for EMC Celerra Storage Systems.
You can define alarms to be raised and propagated when the specified thresholds are breached.
The following components are monitored:
Data Movers
Storage Systems and Processors
File Systems
Note: The celerra probe generates an alert if the File System is deleted or renamed. You must manually reconfigure the monitor if the File System
is renamed.
Networks
celerra Node
This node contains configuration details specific to the EMC Celerra Monitoring probe. In this node, you can view the probe information and can
configure the general setup properties of the EMC Celerra Monitoring probe. You can view a list of all alarm messages that are available in the
EMC Celerra Monitoring probe. You can also add a resource in the EMC Celerra Monitoring probe.
Navigation: celerra
celerra > Probe Information
celerra > General Setup
This section allows you to configure the general setup properties of the EMC Celerra Monitoring probe.
Log Level: Specifies the level of details that are written to the log file.
Default: 2 - Warn
Enable GUI Autorefresh (60 sec): Allows you to autorefresh the GUI in 60 seconds. The field reflects the most current measured
values from the checkpoints and status of the nodes in the tree structure.
Java Home: Defines a folder containing Java home.
celerra > Message pool
This section displays a list of all alarm messages that are available in the EMC Celerra Monitoring probe.
Identification Name: Identifies the name of the message.
Token: Identifies the token which is used for internalization.
Error Severity: Indicates the severity level that is assigned to the alarm messages.
Error Alarm Text: Identifies the alarm message text that is issued on the error alarm.
Clear Alarm Text (OK): Identifies the alarm message text that is issued on the clear alarm.
Subsystem String/Id: Identifies the subsystem ID of the alarm that the watcher generates.
celerra > Options Icon > Add New Resource
This section allows you to add a resource in the EMC Celerra Monitoring probe.
Control Station IP: Defines the IP address of the Celerra Network Control Station.
Port: Specifies the ssh port that is used to connect to the Celerra Network Control Station.
Default: 0
Source: Overrides the default QoS source with the provided value. The default value for the QoS source is the robotname where the
probe is deployed.
Important! Recommendation is to not change the Source field after the initial configuration. In case you change the QoS
source later, multiple graphs display on the Unified Service management (USM) Metrics view (one for every QoS source
value). Further, it is also recommended to keep identical source for both alarm and QoS.
Profile-<Resource Name> Node
The Profile-resource name node allows you to configure the host information of EMC Celerra Monitoring probe.
Navigation: celerra > profile-resource name
profile-resource name > Celerra Host Information
This section allows you to configure the host information of the EMC Celerra Monitoring probe.
The resource name node represents the resource name of the profile that is used to monitor the EMC Celerra Monitoring probe.
Note: This node is user-configurable and depends on the resource name of the profile. Hence, this node is referred as the resource
name throughout this document.
Storage Node
The Storage node allows you to configure the resource that has been added. This node also lets you add and delete the monitors to be
measured.
The Storage node is of two types of monitors:
Control Station
Storage
Navigation: celerra > Profile-resource name > resource name > Storage
Storage > Resource Configuration
This section allows you to set up the resource configuration of the EMC Celerra Monitoring probe.
<Monitor Name> Node
The monitor name node allows you to select one or more monitors from a list of all available monitors.
Navigation: celerra > Profile-resource name > resource name > Storage > monitor name
monitor name > Monitors List
This section allows you to select one or more monitors from a list of available monitors.
v1.6 celerra IM Configuration

This article describes the configuration concepts and procedures for setting up the celerra probe. The following figure provides an overview of the

Add a Celerra Resource
Add monitors (checkpoints)
Create a new group
Launch the Message Pool Manager
Create a new template

This section describes the minimum configuration settings required to configure the celerra probe.
Follow these steps:
1. Deploy the celerra probe.
3. Provide the path of Java JRE in the probe.
Refer Provide the path of Java JRE for more information.
4. Add a resource for the celerra system you want to monitor.
Refer Add a Celerra Resource for more information.
5. Save the configuration to establish the connection and discover the storage components.
The storage components are automatically discovered by the probe and displayed as nodes.
7.

The celerra probe requires Java JRE to gather data about the celerra systems.
Follow these steps:
2. Click the Setup tab. From the Setup dialog that appears, click the Environment tab.
3. Provide the absolute path of Java JRE.
4. Click OK.
The probe now uses this JRE to connect to the celerra systems.
Add a Celerra Resource

Start by creating a resource to be used as a connection to the Celerra system, through which the probe collects and stores data and information
from the monitored components.
1. Select the Default Group in the left pane, right-click and select New Resource.
2. The Resource dialog appears. Define a resource that represents a celerra system.
Field
Description
Resource
Name
The name of this Resource.
Source
Name
The source name to be used for generating QoS and alarms.

Note: Recommendation is to not change the Source Name field after the initial configuration. In case you change the
QoS source later, multiple graphs display on the Unified Service Management (USM) Metrics view (one for every QoS
source value). Further, it is also recommended to keep identical source for both alarm and QoS.
Control
Station IP
The IP address of the Celerra Network Control Station.
Port
The ssh port used to connect to the Celerra Network Control Station. Unless specifically created otherwise when the
Control Station was set up, this will be port 22.
Reserved
Enter any character in this field. It is unused in the first release but may be activated in future releases.
Username
This is the username created at the time the Celerra Network Control Station was created. It is usually "nasadmin".
Password
A valid password to be used by the probe to access the Celerra system.
Group
Here you can select which group you want the resource to belong to. Normally you just have the Default group.
Alarm
message
Select the alarm message to be sent if the resource does not respond. Note that you can edit the message or define your
own using the Message Pool Manager.
Check
interval
The check interval defines how often the probe checks the values of the monitors.
Login
Scope
The login scope for the Celerra system user. It is recommended to use Global or Local users for monitoring the Celerra
system in order to remove any dependency on an LDAP server.
3. Click OK to create the resource.

After the link to the celerra system is established, you can select the desired monitors (checkpoints). The probe also enables you to configure
properties (such as monitor name/description, alarms, QoS messages etc.) for the monitors that you have selected for monitoring.
Create a new group

You can create a new group by selecting the New group button in the menu-bar. The new group appears in the pane with the name New Group.
Right-click the new group and select Rename to give the group a name of your own choice.

The Message Pool Manager can be opened by clicking the Message Pool Manager button in the toolbar.
text, and also create your own messages.
be selected:
Resource: specifies the resource mentioned in the alarm message.
Source: specifies the source where the alarm condition occurs.
Monitor: specifies the monitor (checkpoint) mentioned in the alarm message.
Descr: specifies the description of the monitor.
Key: specifies the monitor key (normally the same as the name of the monitor).
Value: specifies the value used in the alarm message.
Oper: specifies the operand to be combined with the value and the threshold in the alarm message.
Thr: specifies the alarm threshold.

Unit: specifies the unit to be combined with the value in the alarm message (for example boolean).

Templates are a useful tool for defining monitors to be measured on the various components. You can create a template and define a set of
checkpoints belonging to that template. After template creation, you can drag and drop the template on the folder where you want to monitor the
checkpoints defined for the template.
To create a template, follow these steps:
1. Click the Create New Template icon in the menu-bar. The Template Properties dialog appears.
2. Specify a name and a short description of the template.
3. Click OK.
The template is created.
v1.6 celerra Advanced IM Configuration

Contents
Manually Selecting Monitors to Be Measured

Using Templates
Using Auto Configurations
Editing the Monitor Properties
There are three different ways to enable monitors to measure Celerra elements:
Manually selecting the monitors
This is done by maneuvering through the tree browser appearing under resource node. Selecting a folder in the tree structure, the
monitors found will be listed in the right pane of the probe GUI, enabling you to select the ones you want to monitor.
See also the section .
Using templates
Templates are a useful tool for defining monitors to be measured. See the section for further information.
Auto Configurations provide a powerful method for automatically adding monitors to be measured. "Auto Monitors" will be created for devi
ces that are currently NOT monitored.
Example:
When new disks are added to the Celerra system, the Auto Configuration feature will, if configured, create Auto Monitor(s) for the new
disks and automatically start monitoring them.

To select a monitor to be measured for a resource, you simply select the resource in the left pane and browse the tree appearing under the
resource node. Selecting a folder in this tree-structure, the monitors found will be listed in the right pane of the probe GUI, enabling you to select
the ones you want to monitor.
Note that you may also add monitors to be measured using templates.
Selecting the All Monitors node, all monitors currently being measured will be listed in the right pane. Note that you can also select/deselect
monitors here.
Enabling the monitors for QoS and Alarming

You can now see the current values for the monitors in the Values column in the monitor list of the GUI. To enable the probe to send QoS data
and/or send alarms on threshold breaches, you have to modify the properties for each of the monitors. This is done by double-clicking a monitor
(or right-clicking and selecting Edit), which brings up the monitors properties dialog.
Using Templates
Templates are useful tools for defining monitors to be measured on the various elements of a Celerra system:
You may create templates and define a set of monitors belonging to that template. These templates can be applied to a folder or element by
dragging and dropping the template on the node in the tree where you want to measure the monitors defined for the template. You may also drop
a template on a resource in the tree structure, and the template will be applied to all elements for the resource.
Creating a template
Right-click the Templates node in the left window pane and select New.
Note that you may also edit an existing template by selecting one of the templates defined (found by expanding the Templates node
and selecting Edit).
The Template Properties dialog appears, letting you specify a Name and a Description for the new template.
Adding monitors to the template

Drag checkpoints from the right pane and drop on the template in the left pane:
You may now edit the properties for the monitors under the template as described in the section .
Applying a template
Drag and drop the template on the element where you want to monitor the checkpoints defined for the template. Note that you may also drop the
template on a folder containing multiple elements.
You will then be asked if you want to apply the template.

You may also drop a template on a resource in the tree structure, and the template will be assigned all elements under that resource structure:

Auto Configurations provide a powerful method for automatically adding monitors to be measured. "Auto Monitors" will be created for devices that
are currently NOT monitored.
Example:
When new Thin Pools are created on the Celerra system, the Auto Configuration feature will, if configured, create Auto Monitor(s) for the new
Thin Pools and automatically start monitoring them.
The Auto Configuration feature consists of two nodes located under the resource node in the left pane:
Auto Configurations
One or more checkpoints (or templates) can be added to this node, using drag and drop. When this is done, you must click the Apply
button and restart the probe to activate the changes.
The probe will search for the appropriate types of objects. Auto Monitors, representing the monitor(s)/template(s) added under the Auto
Configuration node will be created (and listed under the Auto Monitor node, see below) for devices that are currently NOT monitored.
NOTE: Adding many monitors/templates to the Auto Configurations node may result in a very large number of Auto Monitors
(see below).
Auto Monitors
This node lists Auto Monitors created for previously unmonitored devices, based on the contents added to the Auto Configuration node.
The Auto Monitors will only be created for devices that are currently NOT monitored.
Adding a template to the Auto Configurations node
You can add a template (see the section to learn more about templates) by selecting the Templates node in the left pane. All templates available
will now be listed in the right pane. Add a template to the Auto Configurations node by dragging the template, dropping it on the Auto
Configurations node.
Click the Auto Configurations node and verify that the template was successfully added. Note that you must also click the Apply button and restart
the probe to activate the configuration.
Adding a monitor to the Auto Configurations node

You can add a monitor to the Auto Configurations node using drag and drop.
Monitors can be listed in the right pane by selecting the resource in the left pane and navigating through the tree appearing under the resource
node. Selecting a folder in this tree-structure, the monitors found will be listed in the right pane of the probe GUI.
Note that you can also list all checkpoints currently monitored, if any, in the right pane by selecting the All Monitors node.
Add the monitor to the Auto Configurations node by dragging the monitor, dropping it on the Auto Configurations node.
Click the Auto Configurations node and verify that the monitor was successfully added. Note that you must also click the Apply button and restart
Exploring the contents of the Auto Configurations node

Click the Auto Configurations node in the left pane and verify that the monitors and /or templates were successfully added. Note that you must
click the Apply button and restart the probe to activate the Auto Configuration feature.
Right-clicking in the list, selecting Edit, lets you edit the properties for the template or monitor. See the section for detailed information.
Right-clicking in the list, selecting Delete, lets you delete the template or monitor from the list.
Checking the Auto Monitors node

When templates and/or monitors have been added to the Auto Configurations node, you must click the Apply button and restart the probe to
activate the Auto Configuration feature.
The probe will then start searching through Celerra system.
For each element that is currently NOT monitored, an Auto Monitor will be created for each of the templates/monitors listed under the Auto
Configurations node:
Example:
Suppose you have three monitors under the Auto Configurations node; one Thin Pool related monitor and two disk related monitors. This will
result in one Auto Monitor created for each Thin Pool found and two Auto Monitors for each disk found, provided that these devices are currently
not monitored.
All Auto Monitors created will be listed under the Auto Monitors node.
Editing the Monitor Properties

Edit the properties for a monitor by right-clicking it in the window and selecting Edit. When finished, you must click the Apply button to activate the
new configuration.
Field
Description
Name
This is the name of the monitor. The name will be inserted into this field when the monitor is created, but you are allowed to
modify the name.
Key
This is a read-only field, describing the monitor key.
Description
This is a description of the monitor. This description will be inserted into this field when the monitor is created, but you are
allowed to modify it.
Value Definition
This drop-down list lets you select which value to be used, both for alarming and QoS:
The current value, meaning that the most current value measured will be used.
The delta value (current - previous). This means that the delta value calculated from the current and the previous measured
sample will be used.
Delta per second. This means that the delta value calculated from the samples measured within a second will be used.
The average value of the last and current sample:
(current + previous) / 2.
Active
This activates the monitoring of the probe.
Enable
Monitoring
Selecting this option activates the monitoring.

Note that the monitor will also be selected in the list of monitors in the right window pane when this option is selected, and
that you can enable/disable monitoring of the checkpoint from that list.
Alarms
This tab describes the alarm properties for the monitor.

You can define both a high and a low threshold.
Initially the high threshold is set to a default value (or the current value. Set this value to match your needs.
The low threshold is initially disabled. If you want to use it, you must select another operator than "disabled" from the list
and configure it to match your needs.
Operator
Example:
= 90 means alarm condition if the measured value is exactly 90.
Threshold
The alarm threshold value. An alarm message will be sent if this threshold is exceeded.
Unit
This field specifies the unit of the monitored value.

(for example %, Mbytes etc.). The field is read-only.
Message Token
Advanced
Publish Quality
of Service
QoS Name
Select the name to be used on the QoS message issued.
v1.6 celerra IM GUI Reference

The celerra GUI consists of a row of tool buttons and two window panes. In addition, a status bar is located at the bottom of the window, showing
GUI probe version information and when the probe was started.
Contents
The left pane

Groups
Templates
QoS
Right-clicking in the left pane
The right pane
The tool buttons
The left pane

The left pane shows the monitoring groups containing the resources defined and the QoS definitions. Initially the Default Group and the standard
QoS definitions are created and will appear in the pane and templates.
Groups
You can create new groups by right-clicking a group and selecting New Group (or by clicking the New Group tool button).
Resources
A group contains one or more resources. On this probe you normally just create one resource. This resource is configured as a link to the
Celerra system. It is possible to move a resource from one group to another, using drag and drop.
Under the Resource node you will find:
The Auto Configurations sub node
One or more checkpoints (or templates) can be added to this node, using drag and drop to be used for auto configuring unmonitored
devices. See the section Using Automatic Configurations for further information.
The Auto Monitors sub node
This node lists Auto Monitors, created for previously unmonitored devices, based on the contents added to the Auto Configuration
node.
Templates
This section enables you to create a template and define a set of checkpoints belonging to that template. Right-clicking on any template under the
Templates node lets you add a new template, edit or delete an existing template.
QoS
This node contain the standard QoS definitions included with the probe package. These can be selected when editing the monitoring properties
for a monitor. To define your own QoS definitions, right-click the QoS node and select New.
Right-clicking in the left pane opens a pop-up menu, displaying the following options:
New Resource
Available only when a group or a resource is selected.
Opens the Resource dialog, enabling you to define a new resource to be monitored.
New Group
Available only when a group or a resource is selected.
Creates a new group where you can place resources. The new group will appear in the pane with the name New Group.
Edit
Available only when a resource is selected.
Lets you edit the properties for the selected resource.
Delete
Lets you delete the selected element (group, resource or QoS definition). Note that the Default group cannot be deleted, but if you
remove all elements from the group, it will not appear the next time you restart the probe.
Rename
Lets you delete the selected element (group or resource). Note that the Default group cannot be renamed.
Reload
Refreshes the window to display the most current measured values for the monitors.
Note: When selecting refresh, you will not get updated values until the next time the probe has polled the Celerra system. This interval
is set by the Check Interval set on the properties dialog for the Resource.
The right pane
The contents of the right pane depends on what you select in the left pane:
Resources when a group is selected in the left pane.
Monitors when a resource is selected in the left pane.
Note the following icons:
Monitor where no value has been measured yet.
Black: Indicates that the monitor is NOT activated for monitoring. That means that the Enable Monitoring option is not set in the
properties dialog for the monitor.
Green: Indicates that the monitor is activated for monitoring, and the threshold value defined in the properties dialog for the monitor
is not exceeded.
Other colors: Indicates that the monitor is activated for monitoring, and the threshold value defined in the properties dialog for the
monitor is exceeded. The color reflects the message token selected in the properties dialog for the monitor.
Monitor where QoS is enabled but alarms are not.
QoS definitions when the QoS sub-node is selected in the left-pane.
When the QoS definitions are listed in the pane:
Right-clicking in the list opens a small menu, giving you the possibility to Add (New) or Delete a QoS definition.
When the resources are listed in the pane:
Right-clicking in the list opens a small menu, giving you the following options:
New
Opens the Resource dialog, allowing you to define a new resource.
Edit
Opens the Resource dialog for the selected resource, allowing you to modify the properties.
Delete
Deletes the selected resource.
Activate
Activates the selected resource.
Deactivate
Deactivates the selected resource.
When the monitors are listed in the pane:
Edit
Opens the Monitor properties dialog for the selected monitor, allowing you to modify the properties.
Delete
Unavailable in this view. It will greyed-out.
Refresh
Note: When selecting refresh, you will not get updated values until the next time the probe has polled the Celerra system.
This interval is set by the Check Interval set on the properties dialog for the Resource.
Add to Template
Allows for the addition of the specified monitor to any existing template.
The tool buttons

The General Setup button
The New Group button
The New Resource button
The Message Pool Manager button
The Create new Template button.
General Setup
Field
General
Description
Log-level
Sets the level of details written to the log file. Log as little as possible during normal operation, to minimize disk consumption.
0= Fatal errors.
1= Errors.
2= Warnings.
3= Information.
4= Debug info.
5= Debug information, extremely detailed.
Enable GUI
auto-refresh
When this option is selected, the GUI will be refreshed each 60 seconds. This will reflect the most current measured values
from the checkpoints and status of the nodes in the tree structure that can be seen when manoeuvring through the Celerra
system appearing under a resource node.
If not checked, you have to press the F5 button to refresh the GUI.
Note: When pressing F5 to refresh, you will not get updated values until the next time the probe has polled the Celerra system.
Environment
Reflects the folder containing Java home.
celerra Metrics
This section contains the QoS metrics for the EMC Celerra Monitoring (celerra) probe. The probe uses string and numeric monitors. String
monitors generate alarms with text values for resources. Numeric monitors generate Quality of Service (QoS) data and alarms with numeric
values for resources.
The numeric metrics in this probe are categorized according to the monitored resource as follows:
Storage - Control Station

Data Movers - Block Map
Data Movers - File Systems
Data Movers - System Stats
Network - ICMP
Network - IP
Network - TCP
Network - UDP
Storage Systems
Storage Systems - Disk Groups
Storage Systems - Spindles
Storage Systems - Storage Processor
Storage Volumes - Disks
Storage Volumes - Groups
Storage Volumes - Metas
Storage Volumes - Slices
Storage Volumes - Stripes
Storage - Control Station

QoS Monitor
Units
Name
QOS_STORAGE_CFG_TOTAL_CAPACITY
GB
The total configured storage capacity in the system in Gigabytes
QOS_STORAGE_CFG_FREE_CAPACITY
GB
The free storage capacity in the system in Gigabytes
QOS_STORAGE_CFG_FREE_CAPACITY_PERCENT
Percent
The percentage of free storage capacity in the system
QOS_STORAGE_CFG_USED_CAPACITY
GB
The used storage capacity in the system in Gigabytes
QOS_STORAGE_RAW_TOTAL_CAPACITY
GB
The total raw storage capacity in the system in Gigabytes
QOS_STORAGE_RAW_FREE_CAPACITY
GB
The free raw storage capacity in the system in Gigabytes
QOS_STORAGE_RAW_FREE_CAPACITY_PERCENT
Percent
The percentage of free raw storage capacity in the system
QOS_STORAGE_RAW_USED_CAPACITY
GB
The used raw storage capacity in the system in Gigabytes
QOS_STORAGE_NUM_OF_CONFIGURED_DISKS
Count
The total number of configured disks in the system
QOS_STORAGE_NUM_OF_DEVICES
Count
The total number of devices in the system
QOS_STORAGE_NUM_OF_DISKS
Count
The total number of disks in the system
QOS_STORAGE_NUM_OF_HOT_SPARES
Count
The total number of hot spares in the system
QOS_STORAGE_NUM_OF_UNCONFIGURED_DISKS
Count
The total number of unconfigured disks in the system
Data Movers - Block Map

QoS Monitor
Units
Name
QOS_DMBM_BLOCK_MAP_CONSUMED
KB
The size of the block map consumed
QOS_DMBM_BLOCK_MAP_QUOTA
KB
The size of the block map quota
QOS_DMBM_PAGE_IN_RATE
Count
The page-in rate of memory
QOS_DMBM_PAGE_OUT_RATE
Count
The page-out rate of memory
QOS_DMBM_TOTAL_PAGED_IN
Count
The total count of memory paged in
QOS_DMBM_TOTAL_PAGED_OUT
Count
The total count of memory paged out
Data Movers - File Systems

QoS Monitor
Units
Name
QOS_DMFS_AVAILABLE_CAPACITY
KB
The available capacity of the file system in Kilobytes
QOS_DMFS_CAPACITY_FREE_PERCENT
Percent
The percentage of free capacity of the file system
QOS_DMSF_CAPACITY_USED_PERCENT
Percent
The percentage of used capacity of the file system
QOS_DMFS_TOTAL_CAPACITY
KB
The total capacity of the file system in Kilobytes
QOS_DMFS_USED_CAPACITY
KB
The used capacity of the file system in Kilobytes
Data Movers - System Stats

QoS Monitor
Units
Name
QOS_DMSS_IDLE_CPU_PERCENT
Percent
The percentage of time when the CPU is idle
QOS_DMSS_MEMORY_FREE
KB
The size of the memory in Kilobytes
QOS_DMSS_THREADS_BLOCKED
Count
The number of blocked threads in the system
QOS_DMSS_THREADS_IJZ
Count
The number of IJZ threads in the system
QOS_DMSS_THREADS_RUNABLE
Count
The number of runnable threads in the system
Network - ICMP
QoS Monitor
Units
Name
QOS_ICMP_CALLS_TO_ERROR
Count
The number of ICMP calls to error
QOS_ICMP_MESSAGES_RECEIVED
Count
The number of ICMP messages received
QOS_ICMP_MESSAGES_SENT
Count
The number of ICMP messages sent
Network - IP
QoS Monitor
Units
Name
QOS_IP_TOTAL_PACKETS_RECEIVED
Count
The total number of IP packets received
QOS_IP_BAD_HEADER_CHECKSUMS
Count
The number of incorrect IP header checksums
QOS_IP_WITH_UNKNOWN_PROTOCOL
Count
The number of IP packets with unknown protocols
QOS_IP_FRAGMENTS_RECEIVED
Count
The number of IP fragments received
QOS_IP_FRAGMENTS_DROPPED
Count
The number of IP fragments dropped
QOS_IP_FRAGMENTS_DROPPED_AFTER_TIMEOUT
Count
The number of IP fragments that are dropped after timeout
QOS_IP_PACKETS_REASSEMBLED
Count
The number of IP packets reassembled
QOS_IP_PACKETS_FORWARDED
Count
The number of IP packets forwarded
QOS_IP_PACKETS_NOT_FORWARDABLE
Count
The number of IP packets that cannot be forwarded
QOS_IP_NO_ROUTES
Count
The number of unusable IP routes
QOS_IP_PACKETS_DELIVERED
Count
The number of IP packets delivered
QOS_IP_TOTAL_PACKETS_SENT
Count
The total number of IP packets sent
QOS_IP_PACKETS_FRAGMENTED
Count
The number of IP packets fragmented
QOS_IP_PACKETS_NOT_FRAGMENTABLE
Count
The number of IP packets that cannot be fragmented
QOS_IP_FRAGMENTS_CREATED
Count
The number of IP fragments created
Network - TCP
QoS Monitor
Units
Name
QOS_TCP_PACKETS_SENT
Count
The number of TCP packets sent
QOS_TCP_DATA_PACKETS_RETRANSMITTED
Count
The number of TCP data packets retransmitted
QOS_TCP_RESETS
Count
The number of TCP resets
QOS_TCP_PACKETS_RECEIVED
Count
The number of TCP packets received
QOS_TCP_CONNECTION_REQUESTS
Count
The number of TCP connection requests
QOS_TCP_CONNECTIONS_LINGERED
Count
The number of TCP connections that lingered
Network - UDP
QoS Monitor
Units
Name
QOS_UDP_BAD_PORTS
Count
The number of UDP ports that are not functional
QOS_UDP_INPUT_PACKETS_DELIVERED
Count
The number of UDP input packets that are delivered
QOS_UDP_INCOMPLETE_HEADERS
Count
The number of incomplete UDP headers
QOS_UDP_PACKETS_SENT
Count
The number of UDP packets sent
Storage Systems
QoS Monitor
Units
Name
QOS_SS_CACHE_PAGE_SIZE
Count
The size of the cache page
QOS_SS_HIGH_WATER_MARK
Count
The number of high water mark
QOS_SS_LOW_WATER_MARK
Count
The number of low water mark
QOS_SS_NUMBER_OF_DEVICES
Count
The number of devices
QOS_SS_NUMBER_OF_DISKS
Count
The number of disks
QOS_SS_NUMBER_OF_PHYSICAL_DEVICES
Count
The number of physical devices
QOS_SS_NUMBER_OF_RAID_GROUPS
Count
The number of RAID groups
QOS_SS_NUMBER_OF_STORAGE_GROUPS
Count
The number of storage groups
QOS_SS_UNASSIGNED_CACHE
Count
The size of the unassigned cache
Storage Systems - Disk Groups

QoS Monitor
Units
Name
QOS_SSDG_USED_PERCENT
Percent
The percentage of used capacity in the storage system disk group
QOS_SSDG_FREE_PERCENT
Percent
The percentage of free capacity in the storage system disk group
QOS_SSDG_LOGICAL_CAPACITY
Bytes
The logical capacity of the storage system disk group
QOS_SSDG_RAW_CAPACITY
Bytes
The raw capacity of the storage system disk group
QOS_SSDG_USED_CAPACITY
Bytes
The used capacity of the storage system disk group
QOS_SSDG_FREE_CAPACITY
Bytes
The free capacity of the storage system disk group
Storage Systems - Spindles

QoS Monitor
Units
Name
QOS_SSPIN_CAPACITY
Bytes
The total capacity of the storage system spindle
QOS_SSPIN_USED_CAPACITY
Bytes
The used capacity of the storage system spindle
Storage Systems - Storage Processor

QoS Monitor
Units
Name
QOS_SSSP_FREE_MEMORY
Count
The size of free memory in the storage processor
QOS_SSSP_RAID_3_MEMORY_SIZE
Count
The size of RAID 3 memory in the storage processor
QOS_SSSP_READ_CACHE
Count
The size of read cache memory in the storage processor
QOS_SSSP_SYSTEM_BUFFER
Count
The size of system buffer memory in the storage processor
QOS_SSSP_WRITE_CACHE
Count
The size of write cache memory in the storage processor
QOS_SSSP_PHYSICAL_MEMORY
Count
The size of physical memory in the storage processor
Storage Volumes - Disks

QoS Monitor
Units
Name
QOS_SVD_PERCENT_USED
Percent
The percentage of the disk volume used
QOS_SVD_SIZE_TOTAL
MB
The total size of the disk volume in Megabytes
QOS_SVD_SIZE_AVAILABLE
MB
The available size of the disk volume in Megabytes
QOS_SVD_SIZE_USED
MB
The used size of the disk volume in Megabytes
QoS Monitor
Units
Name
QOS_SVG_PERCENT_USED
Percent
The percentage of the disk group volume used
QOS_SVG_SIZE_TOTAL
MB
The total size of the disk group volume in Megabytes
QOS_SVG_SIZE_AVAILABLE
MB
The available size of the disk group volume in Megabytes
QOS_SVG_SIZE_USED
MB
The used size of the disk group volume in Megabytes
QoS Monitor
Units
Name
QOS_SVM_PERCENT_USED
Percent
The percentage of the meta volume used
QOS_SVM_SIZE_TOTAL
MB
The total size of the meta volume in Megabytes
QOS_SVM_SIZE_AVAILABLE
MB
The available size of the meta volume in Megabytes
QOS_SVM_SIZE_USED
MB
The used size of the meta volume in Megabytes
Storage Volumes - Groups
Storage Volumes - Metas
Storage Volumes - Slices

QoS Monitor
Units
Name
QOS_SVSL_PERCENT_USED
Percent
The percentage of the slice volume used
QOS_SVSL_SIZE_TOTAL
MB
The total size of the slice volume in Megabytes
QOS_SVSL_SIZE_AVAILABLE
MB
The available size of the slice volume in Megabytes
QOS_SVSL_SIZE_USED
MB
The used size of the slice volume in Megabytes
QOS_SVSL_SIZE
Count
The size of each slice in the volume
QOS_SVSL_OFFSET
Count
The offset for each slice in the volume
QoS Monitor
Units
Name
QOS_SVST_PERCENT_USED
Percent
The percentage of the stripe volume used
Storage Volumes - Stripes
QOS_SVST_SIZE_TOTAL
MB
The total size of the stripe volume in Megabytes
QOS_SVST_SIZE_AVAILABLE
MB
The available size of the stripe volume in Megabytes
QOS_SVST_SIZE_USED
MB
The used size of the stripe volume in Megabytes
QOS_SVST_SIZE
Count
The size of each stripe in the volume
cisco_monitor (Cisco SNMP Device Monitoring)

The cisco_monitor probe sends SNMP GET queries to the specified SNMP enabled Cisco devices. The probe then changes the query result into
configured alarms and quality of service (QoS) messages for Service Level Agreement (SLA). You can create and configure a profile to integrate
the device with the CA UIM monitoring solution.
The probe supports SNMPv1, SNMPv2c and SNMPv3. The probe includes a set of predefined SNMP OID variables available on most Cisco
devices, such as CPU and memory usage, state of temperatures, fans, power supply and voltages.
More information:
cisco_monitor (Cisco SNMP Device Monitoring) Release Notes
cisco_monitor IM Configuration
You can configure the cisco_monitor probe to map selected SNMP enabled Cisco hardware devices and define variable settings to monitor the
performance of these devices.
SNMP V3 Support
The cisco_monitor probe enables you to monitor hosts/agents based on the SNMP V3 protocol. You must adhere to the following guidelines when
monitoring the SNMP V3 hosts:
If the same probe instance is monitoring multiple SNMP V3 hosts/agent, ensure that the EngineID of all the hosts/agents is unique. The
absence of unique EngineID causes sporadic connection timeouts and failure alarms.
The probe does not support creating multiple monitoring profiles for one V3 host/agent. Adding such duplicate profiles is disabled in the
probe GUI at most of the places, except the Bulk Configure screen. Do not use the Raw Configure option or add directly in the
configuration file for creating multiple profiles for the same V3 host/agent. This can cause some unpredictable results.
The following diagram outlines the process to configure the cisco_monitor probe.
Contents
Configure Agent Group
Create SNMP Agent Profile
Configure the Variable Properties
Set Up Bulk Configuration of SNMP Agents
Get Oid Values
Monitor a Variable
Monitor Devices Using Ping Sweep
Verify that required hardware and software is available before you configure the probe. For more information, see cisco_monitor (Cisco SNMP
Device Monitoring) Release Notes.

You can set up the logging and global monitoring properties of the probe.
Follow these steps:
1. Click General Setup

.
The Setup window appears.
2. Update the following field values under the General tab:
Encrypt Community String: enables you to encrypt the passwords specified for the different agent profiles in the probe configuration
file.
Items in sample array: specifies the default number of samples stored in memory for each interface. You can also override this value
for each interface.
SNMP request timeout: specifies the timeout value for the SNMP requests. You can also override this value for each profile.
Default alarm message string: specifies the default alarm message issued when alarm situations occur.
Log-level: specifies the level of details that are written to the log file.
Note: Log as little as possible during normal operation to minimize disk consumption, and increase the amount of detail
when debugging.
3. Click OK.
The general properties of the probe are now configured.
Configure Agent Group

You can create a group to add agents for monitoring in the probe. You can also use the Default Group that is available when you deploy the
probe. Groups can be used to segregate agents according to your requirement. On selecting a group in the left pane, all agents in that group are
listed in the right pane.
You can right-click a group for the following options:
New Agent
Opens the profile dialog, that enable you to connect with a new agent.
New Group
Adds a new group to the probe.
Edit
Opens the profile dialog for the selected agent, that enable you to modify the properties for the agent. This option is available only when
an agent is selected.
Delete
Lets you delete the selected group or agent. You are not allowed to delete the Default group, but this group disappears on removing all
agents from it.
Note: You can drag and drop agents to move them between groups. Deleting a group also deletes the agents of that group. A
message displays to confirm whether you want to delete the group with its agent definitions or not.
Rename
Lets you rename the selected group or agent. You are not allowed to rename the Default group.
Ping
Pings the selected agent. If the agent responds, you are notified with the ping round-trip time.
This option is available only when an agent is selected.
Information
Opens a dialog containing system and configuration information for the selected agent.
This option is available only when an agent is selected.
Follow these steps:
1. Right click on the Default Group and select New Group. You can also click the Create a New Agent Group button in the tool bar.
A folder New Group(n) is created in the tree.
2. Rename the group name, as required.
3. Click OK to save the group.
When an agent is unavailable, a red icon is displayed next to the agent name.
Create SNMP Agent Profile

You can create a profile for a specific SNMP agent to the probe. A probe can simultaneously monitor multiple SNMP agents. You can also create
multiple profiles to monitor the same agent. On selecting an agent in the left pane, the corresponding SNMP variables are displayed in the right
pane.
Follow these steps:
1. Click Create a New Agent Profile

The Profile [New] window appears.
2. Update the following field values:

Agent hostname or IP address: specifies the hostname or the IP Address of the SNMP agent.
Active: if selected, activates the profile and starts monitoring the selected SNMP agent, on profile creation.
Check Interval: specifies the interval in seconds after which the probe retrieves data from the SNMP agent.
Severity: specifies the severity for alarm messages if the agent host does not respond.
Group: specifies the agent group in which the agent is to be placed.
SNMP Settings: specifies the SNMP parameters for the profile. For more information, see the Configure SNMP Parameters section.
QoS Identification Method: enables you to define a QoS source.
3. Click Test to send a test SNMP query.
The probe displays a successful connection message.
4. Click OK and Apply to save the configuration.
The profile is created for the required SNMP Agent. The probe queries the SNMP agent and displays an
This indicates that the host is active and available for monitoring.
icon next to the profile name.
Configure SNMP Parameters

You must configure the SNMP parameters in profiles to start monitoring.
Follow these steps:
1. Select the SNMP software version number (SNMPv1, SNMPv2c, or SNMPv3).
2. Select the type of authentication strategy (none, MD5, or SHA).
Note: Enabled only when SNMPv3 is selected in Step 1.
3. Specify the port to be used to send SNMP requests to the host.

Default: 161
4. Select the timeout value for the SNMP requests.
Default: 1 second
5. Set the maximum number of attempts to send SNMP requests without response from the device to consider the device as not available.
Default: 5
6. Specify the community, if SNMPv1 or SNMPv2c is selected from the SNMP Version field.
Specify the password, if SNMPv3 is selected from the SNMP Version field and enabled when Security is selected as AuthNoPriv or Au
thPriv.
Note: Password string must be at least 8 characters long.
7. Select Show password to display the string in the Community/password field as plain text.
8. Specify a username to access the monitored device.
Note: The Username, Security, Priv. Protocol, and Priv. Passphrase fields are enabled only when SNMPv3 is selected from
the SNMP Version field.
9.
9. Specify the security level for the user. Valid levels are NoAuthNoPriv, AuthNoPriv, and AuthPriv.
Note: The Priv. Protocol and Priv Passphrase fields are only enabled when AuthPriv is selected.
10. Specify the privacy protocol to use in the Priv. Protocol field.
11. Specify your privacy passphrase in the Priv. Passphrase field. It must be at least eight characters long.
The SNMP parameters are configured for the profile.
Configure the Variable Properties

Configure the alarms and QoS definitions of the variable. The variable status is indicated as one of the following:
Green indicates OK.

Black indicates that the Enable Monitoring option and the QoS option are turned off in the properties dialog for the variable.
Other colors indicate the severity level selected (in the properties dialog for the variable) when the current value breaches the alarm
threshold.
Indicates that this value cannot be measured on the monitored device.
Indicates that the Enable Monitoring option is turned off, but the QoS option is selected in the properties dialog for the variable.
You can right-click an agent for the following options, when the variables are listed:
Edit: opens the properties dialog for the selected variable, enabling you to modify its properties.
Delete: Deletes the selected variable.
Refresh: Refreshes the list to ensure that the most recent values are displayed.
Monitor: Opens the monitor window where you can monitor the selected SNMP variable. For more information, see Monitor a Variable.
Follow these steps:
1. Double click a variable or right-click the variable and select Edit to open the variable properties dialog. The dialog displays the following
non-editable fields:
Name: specifies the name of the variable.
Object Identifier (OID): specifies the variable name in the format of an Object Identifier.
Description: specifies the description of the variable.
Value properties
Calculate average based on samples
Enter the number of samples for which the average value is to be calculated. This value is displayed under the Average Value col
umn against each variable. The probe sends alarms on the basis of this average value. For more information, see Get Oid Values.
2. Update the following field values, as required:
Active: activates the selected variable, on selecting this checkbox.
Enable Monitoring: if selected, enables you to monitor the variable generating alarms when the specified threshold value is breached.
Rule/Extended Rule Tabs
These tabs are activated when the Enable Monitoring option is selected. The fields on these tabs define the alarm and QoS
conditions for the variable. You can use one or two levels of alarm triggering rules. This means that you can define a set of alarm
triggering rules on the Rule tab and you can also define a set of additional alarm triggering rules on the Extend Rule tab.
Important! You must set a rule before the Extend Rule option is selected. The Extend Rule tab is disabled if you select
the operator = in the Rule tab.
For example: If you create a rule as: Operator =>, Threshold Value 5, Severity Level Major, and you create an extended rule as: Op
erator =>, Threshold Value 10, Severity Level Critical. This means that if the measured value is 6, the alarm message specified on
the Rule tab (severity level Major) is issued. If the measured value is 13, the alarm message specified on the Extended Rule tab
(severity level Critical) is issued.
Operator: select an operator when defining a threshold value for alarms to be issued.
Threshold Value: specify an alarm threshold value, which when breached, issues an alarm.
Severity level: select the severity level of the alarms, issued when the specified threshold value is breached.
Unit: indicates the unit that is combined with the threshold value (for example, MB, and, %).
Message String: specifies a text string that describes the alarm situation. If this field is kept blank, the default message (defined
under the General Properties for the probe) is displayed.
Clear Message String: specifies a text string that overrules the default clear message text. If this field is kept blank, the default clear
message is displayed.
Publish Quality of Service (QoS): if selected, enables you to send QoS data at the specified check interval for the profile.
2. Click OK.
Set Up Bulk Configuration of SNMP Agents

The bulk configuration option enables you to configure variables for more than one agents at one go. This option is useful when threshold values
of a variable are same for more than one agent.
Follow these steps:
1. Click the Bulk Configuration option from the tool bar.
The Bulk Configuration dialog box appears.
2. Update the following field values:
Select Agents
All agents: The configuration parameters are distributed to your monitored agents.
Only active ones: The configuration parameters are distributed to all active agents.
All agents matching: The configuration parameters are distributed to all agents matching your input in this field (pattern matching).
All agents in the group: The configuration parameters are distributed to all agents in the selected group.
Selected agent(s): The configuration parameters are distributed to all agents selected from the right navigation pane.
Select Variable: enables you to select the desired variable.
Modify Agent Values: if selected, enables you to configure the agent parameters as follows:
Interval: specifies the time interval between each time the SNMP agent is checked.
Default: 5 min
Version: specifies the SNMP software version number supported by the monitored device.
Auth: enables you to select the type of authentication strategy (none, HMAC-MD5-96 or HMAC-SHA-96). This field is enabled only
when the option SNMPv3 is selected in the Version field.
Port: specifies the port to be used by the SNMP device.
Default: 161
Timeout: enables you to select the timeout value in seconds before a new SNMP Get request is sent to the SNMP agent.
Retries: enables you to select the number of attempts to send SNMP requests without response from the device to consider the
device as not available.
Default: 5
Community/Password: specifies the community, if SNMP version is selected as SNMPv1 or SNMPv2. Specifies the password, if
SNMP version is selected as SNMPv3.
Username: specifies a username defined on the monitored device.
Show Community/Password: select this option to display the entry in the Community/Password field as plain text.
Security: defines the security level for the user. Valid levels are NoAuthNoPriv, AuthNoPriv, and AuthPriv. This field is available
only when the SNMP version is SNMPv3.
Priv. Protocol: specifies the privacy protocol for SNMP. It is not required if the security level is NoAuthNoPriv or AuthNoPriv.
This field is available only when the SNMP version is SNMPv3 and Security field is selected as AuthPriv.
Priv. Passphrase: specifies the privacy pass phrase. It is not required if the security level is NoAuthNoPriv or AuthNoPriv. It
must be at least 8 characters long. This field is available only when the SNMP version is SNMPv3 and Security field is selected
as AuthPriv.
Modify variable values: You can either select to use the default variable settings or you can select to configure the variable settings.
Default: Use the default variable settings option is selected.
For more information, see Configure the Variable Properties.
Get Oid Values

When you select an SNMP agent from the left pane, the values for the respective variables are not populated automatically. You must click the G
et Oid Values button from the tool bar to get the latest values. The latest values for all the variables for the selected SNMP agent are populated in
the Value and Average Value columns in the right pane.
Notes:
The Average Value is calculated on the basis of the value provided in the Calculate average based on samples field in the C
onfigure the Variable Properties section.
For state variables (Fan State, Temperature State, and so on), the cisco_monitor probe does not calculate the average value. It
displays the actual values of these state variables as average values under the Average Value column. The alarms and QoS
for these variables are also generated based on actual values.
The probe generates alarms on the basis of values displayed under the Average Value column, depending on the conditions
specified in the Configure the Variable Properties dialog (through Operator and Threshold Value fields).
The probe always generates QoS on actual value.
The Misses Oids (Big Buffer Misses, Huge Buffer Misses, Large Buffer Misses, and so on) generate alarms on change in
average value and QoS on change in actual value.
Monitor a Variable
The Monitor option for a variable allows for a continuous monitoring of specific variables, and runs independent of the probes general QoS/alarm
monitoring of an agent. You can right click a SNMP variable and select the Monitor option to monitor the variable.
Note: Click the Interval field from the monitor window and select the sample interval from the interval drop-down list, that appears. This
sample interval is for the monitor window only and has nothing to do with the sample rate defined in the agent profile.
Available intervals are:

1 minute 30 seconds
2 minutes
5 minutes
10 minutes
1 hour
Monitor Devices Using Ping Sweep

The Ping Sweep feature enables you to discover Cisco devices within an IP address range and verify the connection to each device. You can
then monitor those devices that are found connected.
Follow these steps:
1. Click the Create New Agent Profile(s) Using Ping Sweep button on the tool bar.
1.
The Ping Sweep dialog appears.
2. Enter the starting IP address of an IP address range in the IP Address field and the number of hosts in the range in the Number field.
3. Click Generate.
The specified range appears in the form of a table in the Ping Sweep dialog.
Note: The probe ignores duplicate IP addresses. You can generate multiple ranges before starting the ping sweep.
4. Select a connection information from the Connection information drop-down list that you want to use for the router detection. The
Advanced Tab in the Setup window is used to Add Connection Information, which is used in the Ping Sweep feature to connect to the
device.
5. Click Start.
If the Auto option is selected in the Connection information dialog then each IP address connection is checked. A red icon indicates
failure and a green icon indicates a successful connection. Further, for device discovery, the sysname OID is checked for Cisco strings.
If the sysname does not contain Cisco string then ping sweep does not detect the Cisco device.
6. You can drag one or more (multi select) discovered agents and drop into any group in the left pane or to the root level.
Add Connection Information

The Advanced tab enables you to add connection information that is used in the Ping Sweep feature to connect to the device.
Add Connection Information
Follow these steps:

1. Click Add in the Setup dialog.
The Add connection information dialog appears.
Set or modify the following values:
Name: specifies the alphanumeric name for the configuration.
1.
SNMP Version: specifies the SNMP version for the configuration.

Authentication: specifies the authentication for the configuration (valid only in case of SNMPv3).
Port: specifies the SNMP port number.
Community/password: specifies the community, if SNMP version is selected as SNMPv1 or SNMPv2. Specifies password, if SNMP
version is selected as SNMPv3.
Username: specifies the username that needs to be used (valid only in case of SNMPv3.
Security: specifies the security descriptor to be used (valid only in case of SNMPv3).
Privacy Protocol: specifies the Privacy protocol to be used (valid only in case of SNMPv3).
Privacy Passphrase: specifies the Privacy Passphrase to be used (valid only in case of SNMPv3).
Note: Privacy Passphrase must be at least 8 characters long.
2. Click OK.
The connection information is now added.
Note: If you do not want to use this connection, select the connection and click Delete.
cisco_monitor Metrics
This article describes the metrics that can be configured using the Cisco SNMP Device Monitoring (cisco_ucm) probe.
QoS Metrics
The following table describes the checkpoint metrics that can be configured using the cisco_monitor probe.
Monitor Name
Units
Description
Version
QOS_CISCO_BUFFER_MISSES
Count
The average number of times that the router failed to queue a packet in a buffer.
3.2
QOS_CISCO_ENVIRONMENT
State
The state of the Cisco Environment.
3.2
QOS_CPU_USAGE
Percent
The CPU Usage of the Cisco device.
3.2
QOS_MEMORY_USAGE
Megabytes
The Memory Usage of the Cisco device.
3.2
QOS_MEMORY_USAGE_PERC
Percent
The Memory Usage of the Cisco device in percent.
3.2
Note: The QoS for the monitor Cisco Buffer Misses are calculated based on the delta value. Thus, these QoS are delayed according
to the check interval, for the first time.
cisco_monitor Alert Metrics Default Settings

This section contains the alert metric default settings for the cisco_monitor probe.
QoS Metric
Error
Threshold
Error
Severity
Description
CPU Last 5 sec
90
Minor
The overall CPU busy percentage in the last 5 second period.
CPU Last 1 Min
90
Minor
The overall CPU busy percentage in the last 1 minute period.
CPU Last 5 Min
90
Minor
The overall CPU busy percentage in the last 5 minute period.
Small Buffer Misses
10240
Minor
The average number of times that the router failed to queue a packet in a small buffer (64 to 104
bytes).
Medium Buffer
Misses
10240
Minor
The average number of times that the router failed to queue a packet in a medium buffer (105 to 600
bytes).
Big Buffer Misses
10240
Minor
The average number of times that the router failed to queue a packet in a big buffer (601 to 1524
bytes).
Large Buffer Misses
10240
Minor
The average number of times that the router failed to queue a packet in a large buffer (1525 to 5024
bytes).
Very Large Buffer

Misses
10240
Minor
The average number of times that the router failed to queue a packet in a very large buffer.
Huge Buffer Misses
10240
Minor
The average number of times that the router failed to queue a packet in a huge buffer (5025 to 120924
bytes).
Memory Free
Minor
Indicates the number of megabytes from the memory pool that are currently unused on the managed
device.
Memory Used
10
Minor
Indicates the number of megabytes from the memory pool that are currently in use by applications on
the managed device.
Memory Percent
Free
10
Minor
The overall available memory percentage in the memory pool.
Power Supply State
Minor
The current power supply state
Temperature State
Minor
The current temperature state
Fan State
Minor
The current fan state.
Voltage State
Minor
The current voltage state
Operational Status
Critical
Resource is not responding.
cisco_qos (Cisco Class-Based QoS Statistics Monitoring)

This probe monitors Cisco devices supporting the Cisco Class-Based QoS MIB (cbQoS) using SNMPv1/2c/3.
More information:
cisco_qos (Cisco Class-Based QoS Statistics Monitoring) Release Notes
cisco_qos Metrics
Contents
The following table describes the QoS metrics that can be configured using the cisco_qos probe.
QoS Name
Units
Description
Version
QOS_CISCO_DROP_BITRATE
Bits/sec
Drop Bitrate per second
1.2
QOS_CISCO_DROP_BYTE
Bytes/sec
Dropped Bytes per second
1.2
QOS_CISCO_DROP_PKTS
Packets
Dropped Packets
1.2
QOS_CISCO_POST_POLICY_BITRATE
Bits/sec
Post Policy Bitrate per second
1.2
QOS_CISCO_POST_POLICY_BYTE
Bytes/sec
Post Policy Bytes per second
1.2
QOS_CISCO_PRE_POLICY_BITRATE
Bits/sec
Pre Policy Bitrate per second
1.2
The following table describes the default settings for the cisco_qos alert metrics.
QoS Metric
Error Threshold
Error Severity
Description
Version
MsgAgentError
Critical
Alarms to be issued when the host is not responding.
1.2
MsgDropBitrate
Minor
Alarms to be issued when the bit rate of drops is below threshold.
1.2
MsgPostPolicyBitrate
Minor
Alarms to be issued when the post policy bitrate is below threshold.
1.2
MsgDropPackets
Minor
Alarms to be issued when the dropped packets per second is below threshold.
1.2
MsgDropBytes
Minor
Alarms to be issued when the dropped bytes is below threshold.
1.2
MsgPostPolicyBytes
Minor
Alarms to be issued when the post policy bytes/sec is below threshold.
1.2
MsgPrePolicyBitrate
Minor
Alarms to be issued when the pre policy bitrate is below threshold.
1.2
v1.2 cisco_qos IM Configuration

The cisco_qos probe performs SNMP GET queries to Cisco SNMP devices supporting the Cisco class-based QoS MIB, transforming the query
result into alarms and/or Quality of Service (QoS) for SLA purposes. You may configure the profile to your requirement in order to integrate the
device seamlessly into the UIM monitoring solution.
The cisco_qos probe includes a UI to configure the probe. The probe supports SNMPv1, SNMPv2c and SNMPv3.
The following counters are monitored on the devices:
Pre Policy Bitrate
The bit rate of the traffic prior to executing any QoS policies.
Post Policy Bitrate
The bit rate of the traffic after executing QoS policies.
Drop Bitrate
The bit rate of the drops per class as the result of all features that can produce drops (e.g., police, random detect, etc.).
Post Policy Byte
The 64 bits count of outbound octets after executing QoS policies.
Dropped Bytes
The 64 bits counter of dropped bytes per class as the result of all features that can produce drops (e.g., police, random detect, etc.).
Dropped Packets
The 64 bits counter of dropped packets per class as the result of all features that can produce drops (e.g., police, random detect, etc.).
QoS Objects
To understand Class-Based QoS features, the key element is to comprehend the relationships among the different QoS objects.
QoS objects consist of ClassMaps, PolicyMaps, Match Statements and Feature Actions.
Match Statement - The specific match criteria to identify packets for classification purposes.
ClassMap - A user-defined traffic class that contains one or many match statements used to classify packets into different categories.
Feature Action - An action is a QoS feature. Features include police, traffic-shaping, queueing, random detect and packet marking(set). After the
traffic is being classified, based on the traffic classification, we can apply these action to each traffic class.
PolicyMap - A user-defined policy that associates each QoS action to the user-defined traffic class (ClassMap).
Service Policy - Service policy is a policymap that is being attached to a logical interface. Because a policymap can also be a part of the
hierarchical structure (inside a classmap), only a policymap that is directly attached to a logical interface is considered a service policy. Each
service policy is uniquely identified by an index called cbQosPolicyIndex. This number is usually identical to its cbQosObjectsIndex as a
policymap.
Probe Configuration Interface Installation

Probe GUI
The cisco_qos probe is configured by double-clicking the line representing the probe in the Infrastructure Manager. This brings up the
configuration tool.
The window consists of two window panes: Left Pane and Right Pane.
The Left Pane

The left-pane shows the various groups and all hosts belonging to a group.
Under each host, all interfaces detected on the host will be listed.
The UI initially comes up with one group called Default. Note that this group cannot be renamed or deleted.
The following symbols indicate if a monitored host responds or not:

The following symbols indicate if a discovered interface has service policies or not:
Indicates that the interface has service policies.

Indicates that the interface has no service policies.
Selecting a host in the left pane, all service policies found on the interfaces on that host will be listed in the right pane.
Selecting a group in the left pane, all hosts in that group will be listed in the right pane.
New
Opens the Host profile dialog, enabling you to define a new host to be monitored.
Rename
Lets you rename the selected group or host.
Note: You are not allowed to rename the Default group.
Delete
Lets you delete the selected group or host from the list of monitored devices. Note that you are not allowed to delete the Default group.
Expand group
Expands/opens the group folder to show all associated hosts.
Collapse group
Collapses/closes the group folder to hide all associated hosts.
Show all agents
Selecting this option shows a folder called All Agents containing all agents (SNMP hosts) defined. If you clear this option, it will hide the
folder.
Note: This overrides the Show 'All Agents' option in the Setup dialog. In other words, if the option is selected here, but not in
the Setup dialog, the All Agents folder will be shown.
Query SNMP Agent Ctrl + Q
Selecting this option sends a query to the selected agent to check the current status. A successful response should look like the one
shown below:
Rediscover interfaces/policies
Rediscovers all interfaces and service policies on the selected host. The option is useful if one or more interfaces have been added on
the host.
Note: All interfaces on the host will be rediscovered, and you will be asked if you want to use the default monitoring parameters
(these can be edited by clicking the Set the default classmap parameters button in the toolbar.
You must click Yes to the following question to proceed, and No or Cancel to exit.
The last dialog asks if you wish to clear the existing interfaces and policies.
Clicking Yes, all interfaces and policies on the host will be rediscovered, and the default parameters will be used for all of them.
Clicking No, all interfaces and policies on the host will be rediscovered:
The ones already monitored (listed in the right pane when the host is selected in the left pane) will keep their monitoring properties.
The policies rediscovered without a current monitoring profile will be assigned the default monitoring parameters.
The Right Pane

The right pane is multifunctional and displays:
Hosts when a group is selected in the left pane.
Service policies when a host is selected in the left pane. All service policies found on interfaces detected on the host will be listed.
If an interface with service policies is selected in the left pane, only the service policies for that interface will be listed in the right pane.
Right-clicking a service policy in the pane gives you the following possibilities:
Edit
Opens the properties dialog for the selected service policy, enabling you to edit the alarm threshold settings and QoS properties.
Delete
Deletes the selected service policy from the list, and the service policy will not be monitored until it is discovered again. This can be done
by right-clicking the host in the left pane, selecting Rediscover interfaces/policies.
Activate
Activates (starts monitoring) the selected service policy.
Deactivate
Deactivates (stops monitoring) the selected service policy.
The Tool Buttons

The General Setup button.

The New Folder button.
The New SNMP Host button.
The New SNMP Host Range button (arrow).
The Message Pool Manager button.

The Set the default classmap parameters button.
Probe Configuration
This section contains specific configuration for the probe.
General Setup
Click the General Setup button

ab.
to open the Setup dialog for the probe. The Setup dialog contains two tabs: General tab and Advanced t
General Tab
The fields in the above dialog are explained below.

Polling interval
Defines the number of seconds between each "run".
Log-level
Sets the detail level for messages logged to the log-file.
Show All Agents
When selected, a group called All Agents containing all hosts defined will appear in the left window pane.
Note: Right-clicking in the left pane of the user interface and selecting Show All Agents overrides this option. In other words,
even if the option is not selected here but is selected in the right-click menu of the left pane, the All Agents folder will be
shown.
Log-size
Sets the size of the probes log file to which probe-internal log messages are written. The default size is 100 KB.
When this size is reached, the contents of the file are cleared.
Advanced Tab

Community String
Specifies (add or delete) SNMP community strings to be used.
Bind to network interface
When selected, all network operations will be bound to the controllers IP address.
Concurrent sessions
Specifies the number of concurrent parallel sessions.
Encrypt community string
Encrypts the community string in the configuration file.
Single SNMP requests
Uses a single PDU to collect the interface data. PDU (Protocol Data Unit) is information delivered through a network layer.
SNMP request timeout
Specifies the timeout value for the SNMP requests. Use the default value, or select another value (in seconds) from the drop-down list.
Hide community strings
Provides the option to hide the community string when listing hosts in the right pane. The hosts will be listed in the right pane when
selecting All Agents in the left pane.
UI config timeout (sec)
Specifies the timeout value for the UI. This is the maximum time the probe is can use to read the configuration file from the controller
before giving up. The default timeout value is 100 seconds. If monitoring a large number of hosts, the configuration file will be large. It is
then recommended to increase this size.
Create New Folder
You may create a new folder/group by selecting the New folder button
Create New Host/Device Profile

You may create a new profile using this functionality.
Follow these steps:
1.
in the menu-bar and giving the new folder a name.
1. Select the group it should belong to and press the New SNMP host icon
in the menu-bar.
The Host Profile [New] dialog will appear and prompt you for the hostname or IP-address to the device/system.
2. Enter the requested data for the fields as described below.
Host address
Defines the host name or ip-address of the host to be monitored.
Poll interval
Specifies the poll interval individually specified for the selected host. You may select the default polling interval, which means the
general value set for the probe (General setup), or you may select another value from the drop-down list.
SNMP version
Defines the SNMP software version number supported by the monitored device.
Authentication (SNMPv3 only)
Specifies the type of authentication strategy (none, HMAC-MD5-96 or HMAC-SHA-96).
Port
Defines the port to be used by the SNMP device. Default is 161.
Timeout
Specifies the timeout value for the SNMP requests. Use the default value, or select another value from the drop-down list. The default
value is 1 second.
Retries
Sets the number of times to send SNMP requests without response from the device before giving up, regarding the device as not
available. The default number of retries is 5.
Community / Password
Specifies a password for the profile.
Username (SNMPv3 only)
Specifies a username defined on the monitored device.
Show Community/ Password
When selected, the entry in the password field will be shown as plain text.
Security
Specifies the security level for the user. Valid levels are NoAuthNoPriv, AuthNoPriv, and AuthPriv.
Priv. Protocol
Specifies the privacy protocol to use.
Priv Passphrase
Defines your privacy passphrase; not needed if the security level is NoAuthNoPriv or AuthNoPriv. Must be at least eight characters
long.
Monitoring group
Specifies the name of the group to which you want the host to belong.
Description
Provides the description of the profile.
Alarm Message
Selects the alarm message to be sent on agent error: Either use the default message ID, or another one defined in the Message Pool
Manager.
Message Identification Settings
Alarm identification method
Select one of the Alarm identification methods in order to specify the alarm source.
QoS identification method
Select one of the QoS identification methods in order to specify the QoS source.
Start Query
Sends a query to the host to check the response and that the communication works.
3. When finished, press the Start Query button and wait for about 10 seconds.
If the query was successful then a dialog-box showing some system information about the device will appear and the OK button will
become active.
4. Press OK to add the device/system to your list of monitored devices.

All monitoring may be disabled by clearing the Device check box.
Create New Host Profile - Alternative II
Click the arrow button in the toolbar
and it provides you the following two options:
New Host: Adding a single host

This option enables you to add a single host and the procedure is identical to the one described when clicking the Add SNMP Host butto
n. Refer section Create New Host/Device Profile.
New Range: Adding multiple hosts
This option enables you to add a range of hosts, specifying an IP address with four octets, number of agents and the option to specify the
number for incrementing the IP address.
Follow these steps:
1. Click the arrow button in the toolbar

and select New Range.
The Add Agent Range dialog appears. In this example, you will add a range of hosts, starting with IP address 193.71.55.28 and 2 more
hosts.
2. Click OK.
The SNMP Query window appears.
3. Set the SNMP properties (refer properties for host profiles as described in section Create New Host/Device Profile) and Monitoring
group (the name of the group in which you want to place the hosts).
4. Click the Start Query button to collect SNMP data from the hosts.
5. Click OK to activate the hosts answering the query (indicated with a green indicator in the SNMP query window).
Click the Message Pool Manager icon in the toolbar
to open the Message Pool dialog.
text, and you may also create your own messages.
be chosen.
Set the Default Service Policy Parameters
Click the Set the default classmap parameters icon in the toolbar
default monitoring properties for the service policies.
to open the Default Classmap Settings dialog, enabling you to set the
These default parameters will be used when running the Rediscover interfaces/policy function. This is activated by right-clicking a host in the
left pane and selecting Rediscover interfaces/policy, if not selecting to merge data.
Note that all interfaces on the host will be rediscovered, and you will be asked if you want to use the default monitoring parameters (defined by
clicking the Default Service policy parameters button in the toolbar of the UI.
You must click Yes to the following question to proceed, and No or Cancel to exit.
The last dialog asks if you wish to clear the existing interfaces and policies.
Clicking Yes, all interfaces and policies on the host will be rediscovered, and the default parameters will be used for all of them.
Clicking No, all interfaces and policies on the host will be rediscovered:
The ones already monitored (listed in the right pane when the host is selected in the left pane) will keep their monitoring properties.
The policies rediscovered without a current monitoring profile will be assigned the default monitoring parameters.
Set the Monitoring Options for Service Policies

Double-clicking a service policy (or right-clicking the selected service policy and then selecting Edit) opens up a dialog box enabling you to
activate various alarm thresholds and QoS messages for the service policy. The parameters can be set individually for the service policies.
Initially when discovered, the service policies are assigned the default parameters.
The dialog lets you:

Select which counters to monitor.
Select an alarm threshold for each of the counters.
Select an alarm message to be issued if the threshold is breached.
Select for which of the counters QoS messages will be sent.
The following counters are monitored on the devices:
Pre Policy Bitrate

The bit rate of the traffic prior to executing any QoS policies.
Post Policy Bitrate
The bit rate of the traffic after executing QoS policies.
Drop Bitrate
The bit rate of the drops per class as the result of all features that can produce drops (e.g., police, random detect, etc.).
Post Policy Byte
The 64 bits count of outbound octets after executing QoS policies.
Dropped Bytes
The 64 bits counter of dropped bytes per class as the result of all features that can produce drops (e.g., police, random detect, etc.).
Dropped Packets
The 64 bits counter of dropped packets per class as the result of all features that can produce drops (e.g., police, random detect, etc.).
The bitrate counters use the actual value measured on the device.
The Dropped packets counter is calculated as (Current - Previous), and the unit is Packets (Pkts).
For the Byte counters, the probe calculates a delta value (current - Previous)/tdiff, where tdiff is the difference in seconds between the measured
samples. Thus the unit is Bytes / second or Packets / second.
cisco_ucm (Cisco Unified Communications Manager Monitoring)

The Cisco Unified Communications Manager Monitoring (cisco_ucm) probe monitors the health and performance of Cisco UCM systems. Cisco
Unified Communications Manager (UCM) is the software-based call-processing component of the Cisco IP Telephony solution. The application
manages IP telephony devices and call services over the data network.
You can use probe to perform the following functions:
Define the hosts to be monitored
Group folders can be created to place the hosts in logical groups.
Set the monitoring conditions for checkpoints.
Create and monitor CAR profiles.
The probe can also be extended to monitor any available Cisco performance counters.
More information:
cisco_ucm (Cisco Unified Communications Manager Monitoring) Release Notes
cisco_ucm AC Configuration
This article describes the configuration concepts and procedures to set up the Cisco Unified Communications Manager Monitoring
(cisco_ucm) probe. The cisco_ucm probe allows you to monitor the health and performance of UCM systems and services.
The probe is configured to create two types of monitoring profiles:
Host Profile: This profile represents the system on which the probe is deployed. You can add custom checkpoints to the host profile and
can enable respective monitors.
CAR Profile: CAR stands for CDR (Call Data Record) Analysis Report. CAR profile lets you track the call statistics and generate health
and performance report of network calls. The cisco_ucm probe uses File Transfer Protocol (FTP) to retrieve CDR files and generate the
CDR Analysis Report. You can configure the FTP settings through the probe.
The following diagram outlines the procedure the configure the probe.
Contents
Create a Resource
Create Host Profile
Select and Configure Host Counters
Create CAR Profile
Alarm Thresholds
View Properties of the Alarm Message
Verify that required hardware and software is available and installation prerequisites are met before you configure the probe. For more
information, see cisco_ucm (Cisco Unified Communications Manager Monitoring) Release Notes.

You can configure the log, interval, and other such information. You can specify the timeout values for the probe connection to monitored Cisco
UCM devices. You can also specify the CAR properties for the probe to fetch CDR data and receive response for CAR profiles.
Follow these steps:
1. Select the cisco_ucm node.
The Probe Information section provides information about the probe name, probe version, start time of the probe, and the probe vendor.
2. Navigate to the General Configuration section and set or modify the following fields, as required:
Log Level: specifies the level of details that are written to the log file.
Default: 0-fatal
Note:Log as little as possible during normal operation to minimize disk consumption, and increase the amount of detail
when debugging.
Log Size: specifies the size of the log file to which the internal log messages of the probe are written, in kilobytes.
Note:New log file entries are added and the older entries are deleted when the log file is of the specified size.
Send Session Alarms: enables you to generate alarms for deactivated sessions.
Check Interval: specifies the time interval to retrieve monitoring information from the UCM system.
Default: 1
Note:Reduce this interval to generate alarms frequently. A shorter interval can also increase the system load.
Check Interval Unit: allows you to select the unit for the Check Interval field.
Default: Minutes
Sample Interval: specifies the time duration for calculation of the average value for the monitors.
Example: if you specify 12 hours, the probe calculates the average value for the monitors from the last 12 hours.
Default: 6
Sample Interval Unit: allows you to select the unit for the Sample Interval field.
Default: Hours
AXL Timeout (sec): specifies the threshold value (in seconds) to connect to the Cisco UCM server through Administrative XML Layer
(AXL). The probe generates an alarm after the connection attempt time exceeds the timeout value.
Default: 60
3. Set or modify the following fields to configure CAR properties of the probe, as required:
Report Timeout (sec): specifies the time interval (in seconds) within which the cisco_ucm probe generates the call session report.
Default: 60
CAR Interval: specifies the time interval between each instance when the probe retrieves the CDR data.
CAR Interval Unit: allows you to select the unit for the CAR Interval field.
Maximum Num of Threads: specifies the total number of profiles that the probe can simultaneously monitor.
Default: 10
Insert CAR Details to SLM NIS Database: enables the probe to write the data, which is collected for the CAR profile, to the tbnCDR
database. The database resides at the path which is specified in the Data Engine Address field.
Note: The probe supports Microsoft SQL Server database as the backend database for the Insert CAR Details to SLM NIS
Database option.
Data Engine Address: specifies the address of the data engine of the robot.
4. Select Validate Data Engine from the Actions menu to verify the data engine path.
Note: The Validate Data Engine is required only for CAR reporting.
5. Click Save.
The general configuration settings of the probe are saved.
Create a Resource
You can add a resource in the probe. The resource connects to the Cisco UCM server and monitors through host and CAR monitoring profiles.
Follow these steps:
1. Click the Options (icon) next to the cisco_ucm node in the navigation pane.
2. Select Add New Resource.

The Resource Configuration dialog appears.
3. Specify the following field values of the monitored Cisco UCM system:
Unified Server Type: allows you to select the version of the Cisco UCM server.
Hostname or IP Address: defines the hostname or IP address of the Cisco UCM server.
Port: specifies the communication port to use to connect to the Cisco UCM server.
Default: 8443
Username: defines a valid username to access the Cisco UCM server.
Password: defines the password for the user account that is specified in the Username field.
Note: Enter valid user credentials with administrative privileges to the Cisco UCM server.
Node List: allows you to select the service of the Cisco UCM to use for monitoring the resource. Each name in the list represents a
service of the Cisco UCM available for monitoring.
The list of values for this field are automatically populated after valid details are provided in the previous fields.
4. Click Submit.
The resource is visible as the hostname node under the cisco_ucm node.
5. Navigate to the hostname node.
The properties of the resource are displayed in the Resource Configuration section.
6. Select Validate Data Engine from the Actions menu to generate a list of nodes available for monitoring.
Note: You can also delete a resource to prevent the probe to connect to the Cisco UCM server. Select Delete from the Options (icon)
next to the hostname node.
Create Host Profile

You can create host profiles in the probe to monitor all services of the Cisco UCM resource. Call sessions, however, are monitored using CAR
profiles. For more information, see Create CAR Profile.
Follow these steps:
1. Click the Options (icon) next to the HOST node of the resource in the navigation pane.
The Host Profile Configuration dialog appears.
Profile Name: defines a unique name for the profile.
Node: defines the Cisco UCM service which is defined for the host profile.
Note: The probe selects the default node name which is specified at the resource profile for an invalid node name.
Active: allows you to activate the profile for monitoring, on creation.

Description: defines additional information about the profile.
Alarm Message: specifies the alarm which is issued when the host does not respond.
Default: MsgAgentError
Authentication Message: specifies the message that is issued when a logging attempt fails due to invalid credentials.
Default: MsgError
QoS Identification Method: specifies the QoS source.
Default: Host Address
Alarm Identification Method: specifies the alarm source.
4. Click Submit.
4.
The host profile is created and is visible as the ProfileName node.
5. Navigate to the ProfileName node.
6. Select Test Profile from the Actions menu to verify the connection information.
7. Click Save.
Note: You can also delete a host profile to prevent the probe to monitor the services of the Cisco UCM. Select Delete from the Options
(icon) next to the ProfileName node.

You can select the counters in active host profiles. You can configure monitors that generate QoS data and alarm messages.
Follow these steps:
1. Click Options (icon) next to the ProfileName node in the navigation pane.
2. Click Select Counters.
The Select Counters dialog appears.
3. Double-click any counter from the Available list to move it to the Selected list for monitoring.
You can also click
to select all the counters.
Note: You can also double-click a counter from the Selected list or click
to remove all the counters from monitoring.
4. Click Submit.
The selected counters are available under the ProfileName node in the navigation pane.
5. Select the required counter.
A list of configurable monitors is displayed as CounterName nodes.
6. Select the required monitor from this list.
7. Set or modify the following fields to configure the monitors to generate QoS data and alarms:
Publish data: allows you to enable QoS.
Note: When you select Publish Data, the value of Data column for the monitor in the table changes from Off to On.
Publish Alarms: allows you to enable alarm message generation.
Note: The Operator, Threshold, Unit, and Message Token fields are enabled only when Publish Alarms is selected.
Active: activates the selected monitor.

Monitoring Object: displays the name of the UCM node, counter, and monitor.
Name: defines a custom name for the checkpoint.
Description: defines additional information from the monitor.
Note: Select Description from the Actions menu to retrieve a predefined description for the monitor. You can also copy the
description text to the Description field.
Last Interval: specifies the time interval when the probe collects values to compare with the threshold value.
Last Interval Unit: allows you to select the unit of measurement for the Last Interval field.
Default: Minutes
Value Definition: specifies the type of value that is compared with the threshold value. The value is used for QoS messages and
alarms. You can select one of the following value types:
Current Value: uses the last retrieved value for comparison.
Average Value: uses the average of retrieved values for comparison. The sample time is specified in the Sample Interval field in
the General Configuration section.
Delta Value (Current - Previous): uses the difference between the current value and previous value for comparison.
Operator: specifies the comparison operator for thresholds.
Threshold: defines the threshold value of the monitor.
Unit: defines the unit of measurement of the threshold value.
Important! Do not specify a value in Unit for monitors that represent the status of the monitored object.
Message Token: specifies the alarm message to be issued when the specified threshold is breached.
QoS Name: specifies the default QoS that are available for the monitor.
8. Click Save to save the configuration.
The probe monitors the specified monitors in the selected counters.
Note: You can also delete a counter in the host profile. Select Delete Counter from the Options (icon) next to the CounterName node.
Create CAR Profile

You can create CAR profiles in the probe to monitor Call Data Records for Cisco UCM. CAR profiles can generate QoS messages.
Follow these steps:
1. Click the Options (icon) next to the CAR node of the resource in the navigation pane.
2. Select Add New CAR Profile.
The CAR Profile Configuration dialog appears.
Profile Name: defines a unique name for the CAR profile.
Active: activates the CAR profile, on creation.
Node: defines the Cisco UCM service which is defined for the CAR profile to monitor call sessions.
FTP Hostname: defines the host name or IP address of the FTP server.
FTP Username: defines a valid user name to access the FTP server.
FTP Password: defines the password for the user account that is specified in the FTP Username field.
Remote Directory: defines the path of the directory with the FTP client to store the CDR data.
FTP Actual path: specifies the path of the directory from where the probe retrieves the CDR data.
Secure FTP: allows you to specify that the FTP connection is secure.
Time Zone Offset: specifies the time zone difference between the location of the Cisco UCM server and the robot with the probe.
QoS Identification Method: specifies whether the FTP server is identified through the profile name or the host name.
4. Click Submit.
The CAR profile is created and is visible as the CARProfileName node.
5. Click Save.
The profile configuration is saved and a list of available monitors is displayed in the created CAR profile.
6. Select the required monitor from the list.
7.
7. Set or modify the following fields to configure the monitors to generate QoS data:
Publish Data: enables the probe to generate QoS data for the selected monitor.

Key: displays the name of the UCM node and monitor.
Name: defines a unique name for the monitor.
The probe monitors the specified monitors in the selected profile.
Note: You can also delete a CAR profile to prevent the probe to monitor Call Data Records. Select Delete from the Options (icon) next
to the CARProfileName node.
Alarm Thresholds
allow the probe to:

You can view the properties of alarm messages that are configured in the probe.
Follow these steps:
1. Navigate to the Message Configuration section of the cisco_ucm node.
2. Select an alarm message from the table to view the following properties:
Message ID: indicates the ID that is associated with the selected alarm message.
Message Text-OK: indicates the message text for a positive alarm.
Message Text-Error: indicates the message text for a negative alarm.
Subsystem: indicates the alarm subsystem ID that defines the source of the alarm.
Token: indicates a predefined alarm which is fetched from the database.
Error Token: indicates a predefined negative alarm.
OK Token: indicates a predefined positive alarm.
Severity: indicates the severity level of the selected alarm message.
cisco_ucm IM Configuration
This article describes the configuration concepts and procedures to set up the Cisco Unified Communications Manager Monitoring
The following diagram outlines the procedure to configure the probe.
Contents
Create a Group
Create a Profile
Apply Monitors to Profile
Configure Monitor Properties
Create and Configure Templates
Display Current Monitor Values
Create and Configure Custom QoS

You can configure the log and session properties of the probe. You can specify the interval and timeout values for the probe connection to
monitored Cisco UCM devices. You can also specify the CAR properties for the probe to fetch CDR data and receive response for CAR profiles.
Follow these steps:
1. Click
.
The Setup dialog appears.
2. Open the General tab.
3. Set or modify the following fields to configure the general probe properties, as required:
Default: 0
3.
when debugging.
Logfile size: specifies the size of the log file where the internal log messages of the probe are written, in kilobytes. When this size is
4. Open the Advanced tab.
5. Set or modify the following fields to configure interval and timeout properties of the probe, as required:
Check interval: specifies the time interval to retrieve monitoring information from the UCM system.
Default: 1 min
Sample period: specifies the time duration for calculation of the average value for the monitors.
Default: 6 hours
AXL timeout: specifies the threshold value (in seconds) to connect to the Cisco UCM server through Administrative XML Layer (AXL).
The probe generates an alarm after the connection attempt time exceeds the timeout value.
Default: 60
Report timeout: specifies the time interval (in seconds) when the cisco_ucm probe generates the call session report.
Default: 60
Maximum num of threads: specifies the total number of profiles that the probe can simultaneously monitor.
Default: 10
Default: 1 min
Insert CAR details to SLM NIS database: enables the probe to write the data, that is collected for the CAR profile, to the tbnCDR da
tabase. The database resides at the path that is selected from the drop-down.
Database option.
7. Click Validate to verify the data engine path.
8. Click OK.
Create a Group
You can create a group to categorize profiles in the probe. You can also use the Default Group that is available when you deploy the
probe. Groups can be used to segregate profiles according to your requirement. On selecting a group, all host profiles in that group are listed in
the right pane.
New Host: opens the profile dialog, enabling you to define a new host to be monitored.
New Group: opens the profile dialog, enabling you to define a new group. Use the group folders to place the hosts in logical groups.
You can select a group and right-click in the right pane for the following options:
New: opens the profile dialog to define a new host to be monitored or a QoS definition.
Edit: opens the profile dialog for the selected host, enabling you to modify the properties for the host.
Delete: allows you to delete the selected host.
Rename: allows you to rename the selected host.
Activate: includes the selected host for monitoring.

Deactivate: removes the selected host from monitoring.
Refresh: retrieves the current values of the objects that are listed in the right window pane.
Reload: retrieves updated configuration information from the selected agent.
Information: opens an informational window, containing system and configuration information about the selected host
Product Info: opens the window containing information about the product that this profile monitors.
Follow these steps:
1. Right-click on the Default Group and select New Group.
A new group is created in the navigation tree.
2. Rename the group, as required.
Note: If you do not want to use a group, right-click on the group and click Delete. You cannot rename or delete the Default
Group.
Move Hosts Between Groups

You can move a host from one group to another. Select the host and drag-and-drop it to the required group.
Create a Profile
You can create monitoring profiles in the probe. A probe can simultaneously monitor multiple Cisco UCM hosts. You can also create multiple
profiles to monitor the same host. The maximum number of active profiles is specified in the Maximum num of threads field of the Advanced tab
of Setup window. On selecting a profile, all activated Cisco UCM monitors are listed in the right pane.
The probe can be configured to create the following types of monitoring profiles:
Host Profile: This profile represents the system where the probe is deployed. You can add custom checkpoints to the host profile and can
enable respective monitors.
CAR Profile: CAR stands for CDR (Call Data Record) Analysis Report. A CAR profile allows you to track call statistics and generate
health and performance reports of network calls. The cisco_ucm probe uses File Transfer Protocol (FTP) to retrieve CDR files and
generate the CDR Analysis Report. You can configure the FTP settings through the probe. For more information, see Create and
Configure CAR Profile.
The profile status is indicated as one of the following indicators:
indicates that the host responds and can access all checkpoints.
indicates that the host does not respond (such as host stopped).
indicates that the host responds, but there are some problems.
indicates that the host is initializing and waiting for measured values from the profile.
indicates that the profile is created and stored, but is not active.
Follow these steps:
1. Click
from the toolbar.
The Select Unified Server Type dialog appears.
2. Select the type of Cisco UCM server that is monitored.
A wizard is launched guiding you through the steps necessary to define a new host.
3. Read the instructions in the Welcome dialog and click Next to continue.
4. Set or modify the following fields to specify the server details:
4.
Default: 8443
5. Click Next to continue.
6. Set or modify the following fields to specify the authentication details of the Cisco UCM server:

A list of nodes available on the host is listed.
8. Select the node that you want to use and click Next to continue.
9. (Optional) Select Enable CDR Analysis & Reporting to configure CAR settings. For more information, see Create and Configure CAR
Profile.
10. Click the Finish button to finish and exit the wizard.
The new host is created in the selected group.
11. Right-click the profile name and select Edit.
The Profile dialog appears.
12. Set or modify the following fields to configure general properties of the profile, as required:
Default: 8443
Default: selected
Group: specifies the group folder that you want to put the host. Use the group folders to place the hosts in logical groups.
13. Set or modify the following details to configure authentication details for the profile:
14. Set or modify the following fields to configure the alarm details for the profile:
Alarm Message: specifies the alarm that is issued when the host does not respond.
Default: MsgAuthError
15. Set or modify the following fields to configure the identification properties of the profile:
16. Click Test to verify the connection to the Cisco UCM server.
17. Click OK.
The profile is active and available for monitoring.
Note: You can also delete a profile to prevent the probe to connect to the Cisco UCM server. Right-click the profile name and select Del
ete.
Create and Configure CAR Profile

You can generate reports and view additional information for CAR profiles, as follows:
Generate CAR Analysis Report
View Phone Table
Custom CAR Analysis Reporting

Follow these steps:
1. Click
from the toolbar.
2. Follow steps 2 through 8 from Create a Profile.

3. In the Set FTP details window, specify the following field values of the monitored Cisco UCM system:
Host Name: defines the host name or IP address of the FTP server.
User Name: defines a valid user name to access the FTP server.
Password: defines the password for the user account that is specified in the FTP Username field.
You can also browse to the required path.
Note: The ftp server is installed on the same system as the cisco_ucm probe. For example, the ftp users home directory is
C:\netpub\wwwroot\user and the remotedir is configured as "/". The actual path must be configured as
C:\netpub\wwwroot\user.

The new CAR profile is created in the CAR Profiles group.
Default: 8443
Default: selected
8. Set or modify the following fields to configure the FTP details of the profile:
10. Click OK.
The profile configuration is saved.
11. Click Apply.
A list of available monitors is displayed in the created CAR profile.
12. Select the required monitors from the list to activate QoS generation for the monitors.
13. (Optional) Right-click a monitor and select Edit.
The CAR Monitor window is displayed.
14.
Publish Quality of Service (QoS): enables the probe to generate QoS data for the selected monitor.
16. Click Apply.
Note: You can also delete a CAR profile to prevent the probe to monitor Call Data Records. Right-click the profile name and select Dele
te.

You can generate CAR analysis report by clicking Show CAR Analysis Report button. In the left pane of this report, you can see the Call
Identifier that is a unique ID for each call. You can also see Call From and Call To details and the Time when the call was made. On clicking
any of the Call Identifier, its respective CMR details are displayed in the right pane.
In the CMR Average Summary Analysis section, Jitter indicates the total Jitters of all CMR and No of Packets Lost indicates the total number
of packets lost in all CMR. The remaining fields in CMR Average Summary Analysis section display the average of their respective values.
The fields in the dialog are explained as follows:
Jitter: provides an estimate of the statistical variance of the RTP data packet interarrival time. The time is measured in milliseconds and
expressed as an unsigned integer. The interarrival jitter J specifies the mean deviation (smoothed absolute value) of the difference D in
packet spacing at the receiver. The value is compared to the sender for a pair of packets. RFC 1889 contains detailed computation
algorithms. The value remains zero if the connection was set in "send only" mode. Default is 0.
No. of Packets Lost: displays the number of packets that are lost during the call.
CCR - Cumulative Conceal Ratio: represents the cumulative ratio of concealment time over speech time that is observed after starting a
call.
ICR - Interval Conceal Ratio: represents an interval-based average concealment rate. The rate is the ratio of concealment time over
speech time for the last 3 seconds of active speech.
ICRmx - Interval Conceal Ratio Max: represents the maximum concealment ratio that is observed during the call.
CS - Conceal Secs: represents the time when some concealment is observed during a call.
SCS - Severely Conceal Secs: represents the time when a significant amount of concealment is observed. If the observed concealment
is greater than 50 milliseconds or 5 percent, the speech is not audible.
MLQK - MOS Listening Quality K-factor: provides an estimate of the MOS score of the last 8 seconds of speech on the reception
signal path.
MLQKmn - MOS Listening Quality K-factor Min: represents the minimum score that is observed from the beginning of a call and
represents the worst sounding 8-second interval.
MLQKmx - MOS Listening Quality K-factor Max: represents the maximum score that is observed from the beginning of a call and
represents the best sounding 8-second interval.
MLQKav - MOS Listening Quality K-factor Avg: represents the running average of scores that are observed from the beginning of a
call.
View Phone Table

The Show Phone Table button in the toolbar allows you to view information about registered phone devices.
Follow these steps:
1. Select a configured profile from the left pane.
2. In the toolbar, click Show Phone Table.
The phone details report appears.
Note: If phone details are not available, the probe generates a blank Phone Table report.
2.

The CAR data is stored in the tbnCDR and tbnCMR database tables in your NIS database. Using reporting tools, such as Unified Reporter, you
can create your own CAR Analysis reports.

You can apply monitors to the probe that measure the Cisco UCM performance objects. You can select monitors in one of the following ways:
Manually select monitors from the available list.
Use monitoring templates to apply consistent monitoring patterns across profiles.
Auto-configure monitors to allow auto monitors to be created and automatically monitored for new disks.
Important! CA recommends you to use auto-configuration to create auto-monitors to monitor the Cisco UCM system. You can
configure static monitors for specific instances. Multiple static monitors can increase the size of the .cfg file and causes performance
issues.
You can view and configure all monitors that are applied to a profile in the All Monitors node.
Manually Select Monitors

You can manually select a monitor from the list of monitors in the profile.
Note: The profile monitors initially are not activated. You can activate the ones that you want to monitor. The Enable Monitoring option
on the Monitor Properties dialog for the checkpoint is automatically selected.
Follow these steps:

1. Select a resource or Cisco UCM component in the left pane.
The available monitors for the selected resource are listed in the right pane.
2. Click the checkbox next to the monitor you want to add.
3. Double-click the monitor to open the Monitor Properties dialog.
4. Configure the monitor properties, as required.
5. Click Yes, when prompted to restart the probe.
Use Monitoring Templates

Templates can be applied to multiple profiles to measure the same parameters on multiple Cisco UCM systems. A default template is available.
You can drag-and-drop a template on a host profile to apply to all elements for the resource.
You can create templates and can define a set of monitors in that template. For information about creating templates, see Create and Configure
Templates.
Important! If the templates are applied to the inventory tree, the inventory is recursively navigated to create static monitors. The
monitors are created for every checkpoint applicable to the template. Auto-monitor behavior in static form creates a large cfg file and
also creates issues with the performance of your probe.
Auto Configure Monitors
You can add monitors and templates to the Auto Configurations node of a resource. Auto configuration applies the selected monitors to all
components of a resource. Monitors or checkpoints are automatically created for devices that are currently not monitored.
The Auto Configuration feature consists of two nodes that are located under the resource node in the left pane:
Auto Configurations: displays a list of monitor configurations that are automatically applied to the profile.
Auto Monitors: displays a list of all monitors that are configured using the monitor configurations in the Auto Configurations node.
Follow these steps:
1. Select a monitor from a template or the list of available monitors.
2. Drag-and-drop the selected monitor to the auto configuration node.
You can drag-and-drop a template to apply configurations of all monitors in the template.
3. Click the Apply button and restart the probe to activate the changes.
A list of monitors with the applied configurations are displayed in the Auto Monitors node.
Note: Adding multiple monitor or templates to the Auto Configurations node results in multiple Auto Monitors.

5. Click Apply to restart the probe and activate the changes.
Note: If you want to edit an existing Auto Configuration, double-click it and select Edit.

You can configure monitors that generate QoS data and alarm messages in host profiles.
Monitors have an indicator that represents the following status:
Green: indicates that everything is OK.
Black: indicates that the checkpoint is not active.
Other colors: indicates that the monitor is activated for monitoring and the threshold value for the monitor has exceeded. The color
reflects the message token that is selected in the properties dialog for the monitor.
indicates that the checkpoint is not available at the host. This indicator also appears for monitors that are available at the host after
configuration changes. The indicator disappears when measured values are returned from the monitor.
You can right-click a monitor for the following options:
Edit: opens the Monitor Properties dialog, enabling you to modify the monitoring properties for the selected monitor.
Delete: deletes the monitor from the list. If you want to monitor again, locate the monitor in its group in the left pane and activate it.
Activate: activates the selected monitor to be monitored by the probe. You can also activate it by clicking the check box belonging to the
checkpoint.
Deactivate: deactivates the selected monitor (if activated), and the probe stops monitoring the monitor.
Monitor: Opens the Monitor window. The window displays the values that are recorded for the selected monitor during the sample
period. For more information, see View Graphical Monitoring.
Add to Template: allows you to add this monitor to a template.
Follow these steps:
1. Navigate to the monitor category or template in the left pane.
2. Double-click the required monitor from the list of monitors.
3.
Note: Click Query Description to retrieve a predefined description for the monitor. Closing the window copies the
last (mins): specifies the time interval when the probe collects values to compare with the threshold value.
Enable Monitoring: allows you to enable alarm message generation.
Note: The Operator, Threshold Value, Unit, and Message Token fields are enabled only when Publish Alarms is
selected.

Threshold Value: defines the threshold value of the monitor.
Publish Quality of Service (QoS): allows you to enable QoS generation.
5. Select the checkbox next to the monitor name to activate the monitor.
6. Click Apply.
The probe uses the specified monitor.
View Graphical Monitoring

The Monitor window displays the values that are recorded for the selected monitor during the sample period. The sample period in the Setup sec
tion sets the maximum time range that is shown in the window. This time range can be set to a lower value, changing the backlog to a lower
value.
Note: The horizontal red line in the graph indicates the alarm threshold that is defined for the monitor.
When clicking and holding the left mouse button inside the graph, a red vertical line appears. You can continue to hold the left mouse button down
and move the cursor. The window displays the exact value at different points in the graph. The value is displayed in the upper part of the graph on
the format: <Day> <Time> <Value>.
Right-clicking inside the monitor window lets you select the backlog (the time range that is shown in the monitor window). In addition, the
right-click menu lets you select the option Show Average. A horizontal blue line is added in the graph, representing the average sample value.
The following information can be found in the status bar at the bottom of the monitor window:
The number of samples from the probe start
The minimum value measured
The average value measured
The maximum value measured

The backlog is the time range that is shown in the monitor window. The backlog can be selected to 6, 12, 24 or 48 hours by right-clicking
inside the graph.
Note: The graph cannot display time ranges that are greater than the selected Sample Period in the Setup section.

You can create templates in the probe and can configure monitors for that template.
Note: You can drag-and-drop a template to the Auto Configurations node to apply all the monitors in the template as Auto Monitors,
as applicable. For more information, see Auto Configure Monitors.
Follow these steps:

1. Right-click the Templates node in the left pane and select New.
The Template Properties dialog appears.
2. Specify a Name and a Description for the template.
3. Click OK.
4. You can use the following options to add monitors to templates:
Select monitors from other templates and drag-and-drop them to the created template.
Select a monitor from the list of available monitors in the probe. Drag-and-drop it from the right pane to the template in the left pane.
6. Drag-and-drop the template to the required profile or group in the left pane to apply the template.
The monitors that are defined in the template are assigned to the corresponding Cisco UCM monitors.
Notes:
If you want to edit a template, right-click on the template and select Edit.
If you do not want to use a template, right-click on the template and select Delete.

You can verify the current values for the monitors by clicking the Get Values button in the toolbar. Click a profile to display the current values in
the Values column.

You can create and configure custom QoS in the probe can be used by monitors.
Follow these steps:
1. Right-click the QoS node in the left pane and select New QOS.
You can also edit an existing QoS or select Add New QoS Definition from the QoS Name field of the Monitor Properties window.
2. Set or modify the following fields, as required to configure the QoS:
Name: enters a name for the QoS.
Group: selects a group where the new QoS belongs.
Default: QOS_STORAGE
Description: enters any additional information for the QoS.

Unit and Unit Abbreviation: selects an appropriate unit and its abbreviation for the QoS.
Flag: allows you to specify whether a QoS is boolean or numeric and has a maximum value.
Has Max: enters the maximum permissible value for the QoS.
3. Click OK to create the QoS.
The QoS Properties dialog closes.
4. Click Apply to save the QoS to the probe.

text and also create your own messages. You can add, modify, and delete an alarm message by right-clicking on the message row.
Note: Variable expansion in the message text is supported. For more information, see Variable Expansion.
Follow these steps:
1. Click
from the toolbar.
The Message Pool window appears.
2. Click
from the toolbar.
The Message Properties window appears.
3. Specify the following values, as applicable:
Identification Name: specifies an identification code as a name for the message.
Token: allows you to select the message token to identify the type of message.
Error Alarm Text: specifies the alarm text in case error occurs.
Clear Alarm Text (OK): specifies the alarm text in case no error occurs.
Error Severity: allows you to select the severity level for the error message.
Subsystem string/id: allows you to select the subsystem id for the message.
4. Click OK.
The new message is added.
Variable Expansion
You can enter a $ symbol in the alarm message text to select from the list of variables. The following variables are available in the alarm message
text:
Profile variables
profile
host
node
description
Monitor variables
name
key
value
oper
threshold
unit
state
The values of these variables are retrieved from the monitored system.
cisco_ucm Version 1.8

This section contains documentation for versions 1.83 and earlier of the cisco_ucm probe:
v1.8 cisco_ucm AC Configuration
v1.8 cisco_ucm IM Configuration
v1.8 cisco_ucm AC Configuration

This article describes the process to configure the admin console GUI of the Cisco Unified Communications Manager Monitoring
The probe is configured to create two types of monitoring profiles:
Host Profile: This profile represents the system on which the probe is deployed. You can add custom checkpoints to the host profile and
can enable respective monitors.
CAR Profile: CAR stands for CDR (Call Data Record) Analysis Report. CAR profile lets you track the call statistics and generate health
and performance report of network calls. The cisco_ucm probe uses File Transfer Protocol (FTP) to retrieve CDR files and generate the
CDR Analysis Report. You can configure the FTP settings through the probe.
The following diagram outlines the process to configure the probe to collect QoS data for Cisco Unified Communications Manager systems.
Contents
Create a Resource
Create Host Profile
Create CAR Profile
Alarm Thresholds

You can configure the log, interval, and other such information. You can specify the timeout values for the probe connection to monitored Cisco
UCM devices. You can also specify the CAR properties for the probe to fetch CDR data and receive response for CAR profiles.
Follow these steps:
1. Select the cisco_ucm node.
The Probe Information section provides information about the probe name, probe version, start time of the probe, and the probe vendor.
2. Navigate to the General Configuration section and set or modify the following fields, as required:
Default: 0-fatal
when debugging.
Log Size: specifies the size of the log file to which the internal log messages of the probe are written, in kilobytes.
Note: New log file entries are added and the older entries are deleted when the log file is of the specified size.
Check Interval: specifies the time interval to retrieve monitoring information from the UCM system.
Default: 1
Check Interval Unit: allows you to select the unit for the Check Interval field.
Default: Minutes
Sample Interval: specifies the time duration for calculation of the average value for the monitors.
Default: 6
Sample Interval Unit: allows you to select the unit for the Sample Interval field.
Default: Hours
AXL Timeout (sec): specifies the threshold value (in seconds) to connect to the Cisco UCM server through Administrative XML Layer
(AXL). The probe generates an alarm after the connection attempt time exceeds the timeout value.
Default: 60
Report Timeout (sec): specifies the time interval (in seconds) within which the cisco_ucm probe generates the call session report.
Default: 60
CAR Interval Unit: allows you to select the unit for the CAR Interval field.
Maximum Num of Threads: specifies the total number of profiles that the probe can simultaneously monitor.
Default: 10
Insert CAR Details to SLM NIS Database: enables the probe to write the data, which is collected for the CAR profile, to the tbnCDR
database. The database resides at the path which is specified in the Data Engine Address field.
Database option.
Data Engine Address: specifies the address of the data engine of the robot.
4. Select Validate Data Engine from the Actions menu to verify the data engine path.
Note: The Validate Data Engine is required only for CAR reporting.
5. Click Save.
Create a Resource
You can add a resource in the probe. The resource connects to the Cisco UCM server and monitors through host and CAR monitoring profiles.
Follow these steps:
1. Click the Options (icon) next to the cisco_ucm node in the navigation pane.
2. Select Add New Resource.
The Resource Configuration dialog appears.
Unified Server Type: allows you to select the version of the Cisco UCM server.
Default: 8443
Node List: allows you to select the service of the Cisco UCM to use for monitoring the resource. Each name in the list represents a
service of the Cisco UCM available for monitoring.
The list of values for this field are automatically populated after valid details are provided in the previous fields.
4. Click Submit.
The resource is visible as the hostname node under the cisco_ucm node.
5. Navigate to the hostname node.
The properties of the resource are displayed in the Resource Configuration section.
6. Select Validate Data Engine from the Actions menu to generate a list of nodes available for monitoring.
Note: You can also delete a resource to prevent the probe to connect to the Cisco UCM server. Select Delete from the Options (icon)
next to the hostname node.
Create Host Profile

You can create host profiles in the probe to monitor all services of the Cisco UCM resource. Call sessions, however, are monitored using CAR
profiles. For more information, see Create CAR Profile.
Follow these steps:

1. Click the Options (icon) next to the HOST node of the resource in the navigation pane.
The Host Profile Configuration dialog appears.
Node: defines the Cisco UCM service which is defined for the host profile.

Alarm Message: specifies the alarm which is issued when the host does not respond.
Default: MsgError
4. Click Submit.
The host profile is created and is visible as the ProfileName node.
5. Navigate to the ProfileName node.
6. Select Test Profile from the Actions menu to verify the connection information.
7. Click Save.
Note: You can also delete a host profile to prevent the probe to monitor the services of the Cisco UCM. Select Delete from the Options
(icon) next to the ProfileName node.

You can select the counters in active host profiles. You can configure monitors that generate QoS data and alarm messages.
Follow these steps:
1. Click Options (icon) next to the ProfileName node in the navigation pane.
2. Click Select Counters.
The Select Counters dialog appears.
3. Double-click any counter from the Available list to move it to the Selected list for monitoring.
You can also click
to select all the counters.
Note: You can also double-click a counter from the Selected list or click
counters from monitoring.
4. Click Submit.
The selected counters are available under the ProfileName node in the navigation pane.
5. Select the required counter.
A list of configurable monitors is displayed as CounterName nodes.
6. Select the required monitor from this list.
7.
to remove all the
Publish data: allows you to enable QoS.
Publish Alarms: allows you to enable alarm message generation.
Note: The Operator, Threshold, Unit, and Message Token fields are enabled only when Publish Alarms is selected.

Note: Select Description from the Actions menu to retrieve a predefined description for the monitor. You can also copy the
Last Interval: specifies the time interval when the probe collects values to compare with the threshold value.
Last Interval Unit: allows you to select the unit of measurement for the Last Interval field.
Default: Minutes
Threshold: defines the threshold value of the monitor.
The probe monitors the specified monitors in the selected counters.
Note: You can also delete a counter in the host profile. Select Delete Counter from the Options (icon) next to the CounterName node.
Create CAR Profile

Follow these steps:
1. Click the Options (icon) next to the CAR node of the resource in the navigation pane.
2. Select Add New CAR Profile.
The CAR Profile Configuration dialog appears.
3.
Profile Name: defines a unique name for the CAR profile.
Active: activates the CAR profile, on creation.
Node: defines the Cisco UCM service which is defined for the CAR profile to monitor call sessions.
FTP Hostname: defines the host name or IP address of the FTP server.
FTP Username: defines a valid user name to access the FTP server.
FTP Password: defines the password for the user account that is specified in the FTP Username field.
QoS Identification Method: specifies whether the FTP server is identified through the profile name or the host name.
4. Click Submit.
The CAR profile is created and is visible as the CARProfileName node.
5. Click Save.
The profile configuration is saved and a list of available monitors is displayed in the created CAR profile.
6. Select the required monitor from the list.
Publish Data: enables the probe to generate QoS data for the selected monitor.

Note: You can also delete a CAR profile to prevent the probe to monitor Call Data Records. Select Delete from the Options (icon) next
to the CARProfileName node.
Alarm Thresholds
allow the probe to:

You can view the properties of alarm messages that are configured in the probe.
Follow these steps:

1. Navigate to the Message Configuration section of the cisco_ucm node.
2. Select an alarm message from the table to view the following properties:
Message ID: indicates the ID that is associated with the selected alarm message.
Message Text-OK: indicates the message text for a positive alarm.
Message Text-Error: indicates the message text for a negative alarm.
Subsystem: indicates the alarm subsystem ID that defines the source of the alarm.
Token: indicates a predefined alarm which is fetched from the database.
Error Token: indicates a predefined negative alarm.
OK Token: indicates a predefined positive alarm.
Severity: indicates the severity level of the selected alarm message.
v1.8 cisco_ucm IM Configuration

This article describes the process to configure the Infrastructure Manager GUI of the Cisco Unified Communications Manager Monitoring
The following diagram outlines the process to configure the probe to collect QoS data for Cisco Unified Communications Manager systems.
Contents
Create a Group
Create a Profile


You can configure the log and session properties of the probe. You can specify the interval and timeout values for the probe connection to
monitored Cisco UCM devices. You can also specify the CAR properties for the probe to fetch CDR data and receive response for CAR profiles.
Follow these steps:
1. Click
2. Open the General tab.

3. Set or modify the following fields to configure the general probe properties, as required:
Default: 0
when debugging.
Logfile size: specifies the size of the log file where the internal log messages of the probe are written, in kilobytes. When this size is
5. Set or modify the following fields to configure interval and timeout properties of the probe, as required:
Check interval: specifies the time interval to retrieve monitoring information from the UCM system.
Default: 1 min
Sample period: specifies the time duration for calculation of the average value for the monitors.
Default: 6 hours
AXL timeout: specifies the threshold value (in seconds) to connect to the Cisco UCM server through Administrative XML Layer (AXL).
The probe generates an alarm after the connection attempt time exceeds the timeout value.
Default: 60
Report timeout: specifies the time interval (in seconds) when the cisco_ucm probe generates the call session report.
Default: 60
Maximum num of threads: specifies the total number of profiles that the probe can simultaneously monitor.
Default: 10
Default: 1 min
Insert CAR details to SLM NIS database: enables the probe to write the data, that is collected for the CAR profile, to the tbnCDR da
tabase. The database resides at the path that is selected from the drop-down.
Database option.
7. Click Validate to verify the data engine path.
8.
8. Click OK.
Create a Group
You can create a group to categorize profiles in the probe. You can also use the Default Group that is available when you deploy the
probe. Groups can be used to segregate profiles according to your requirement. On selecting a group, all host profiles in that group are listed in
the right pane.
New Host: opens the profile dialog, enabling you to define a new host to be monitored.
New Group: opens the profile dialog, enabling you to define a new group. Use the group folders to place the hosts in logical groups.
You can select a group and right-click in the right pane for the following options:
New: opens the profile dialog to define a new host to be monitored or a QoS definition.
Edit: opens the profile dialog for the selected host, enabling you to modify the properties for the host.
Delete: allows you to delete the selected host.
Rename: allows you to rename the selected host.
Activate: includes the selected host for monitoring.
Deactivate: removes the selected host from monitoring.
Refresh: retrieves the current values of the objects that are listed in the right window pane.
Reload: retrieves updated configuration information from the selected agent.
Information: opens an informational window, containing system and configuration information about the selected host
Product Info: opens the window containing information about the product that this profile monitors.
Follow these steps:
1. Right-click on the Default Group and select New Group.
A new group is created in the navigation tree.
2. Rename the group, as required.
Note: If you do not want to use a group, right-click on the group and click Delete. You cannot rename or delete the Default
Group.

Move Hosts Between Groups
You can move a host from one group to another. Select the host and drag-and-drop it to the required group.
Create a Profile
You can create monitoring profiles in the probe. A probe can simultaneously monitor multiple Cisco UCM hosts. You can also create multiple
profiles to monitor the same host. The maximum number of active profiles is specified in the Maximum num of threads field of the Advanced tab
of Setup window. On selecting a profile, all activated Cisco UCM monitors are listed in the right pane.
The probe can be configured to create the following types of monitoring profiles:
Host Profile: This profile represents the system where the probe is deployed. You can add custom checkpoints to the host profile and can
enable respective monitors.
CAR Profile: CAR stands for CDR (Call Data Record) Analysis Report. A CAR profile allows you to track call statistics and generate
health and performance reports of network calls. The cisco_ucm probe uses File Transfer Protocol (FTP) to retrieve CDR files and
generate the CDR Analysis Report. You can configure the FTP settings through the probe. For more information, see Create and
Configure CAR Profile.
The profile status is indicated as one of the following indicators:
indicates that the host responds and can access all checkpoints.
indicates that the host does not respond (such as host stopped).
indicates that the host responds, but there are some problems.
indicates that the profile is created and stored, but is not active.
Follow these steps:
1. Click
from the toolbar.
The Select Unified Server Type dialog appears.
2. Select the type of Cisco UCM server that is monitored.
A wizard is launched guiding you through the steps necessary to define a new host.
3. Read the instructions in the Welcome dialog and click Next to continue.
4. Set or modify the following fields to specify the server details:
Default: 8443
6. Set or modify the following fields to specify the authentication details of the Cisco UCM server:

A list of nodes available on the host is listed.
8. Select the node that you want to use and click Next to continue.
9. (Optional) Select Enable CDR Analysis & Reporting to configure CAR settings. For more information, see Create and Configure CAR
Profile.
The new host is created in the selected group.
Default: 8443
Default: selected
Group: specifies the group folder that you want to put the host. Use the group folders to place the hosts in logical groups.
14. Set or modify the following fields to configure the alarm details for the profile:
Alarm Message: specifies the alarm that is issued when the host does not respond.
Default: MsgAuthError
15.
16. Click Test to verify the connection to the Cisco UCM server.
17. Click OK.
The profile is active and available for monitoring.
Note: You can also delete a profile to prevent the probe to connect to the Cisco UCM server. Right-click the profile name and select Del
ete.
Create and Configure CAR Profile
You can generate reports and view additional information for CAR profiles, as follows:
View Phone Table
Follow these steps:
1. Click
from the toolbar.
2. Follow steps 2 through 8 from Create a Profile.

3. In the Set FTP details window, specify the following field values of the monitored Cisco UCM system:
Note: The ftp server is installed on the same system as the cisco_ucm probe. For example, the ftp users home directory is
C:\netpub\wwwroot\user and the remotedir is configured as "/". The actual path must be configured as
C:\netpub\wwwroot\user.

The new CAR profile is created in the CAR Profiles group.
Default: 8443
Default: selected
8. Set or modify the following fields to configure the FTP details of the profile:
8.
10. Click OK.
The profile configuration is saved.
11. Click Apply.
A list of available monitors is displayed in the created CAR profile.
12. Select the required monitors from the list to activate QoS generation for the monitors.
13. (Optional) Right-click a monitor and select Edit.
The CAR Monitor window is displayed.
Publish Quality of Service (QoS): enables the probe to generate QoS data for the selected monitor.
16. Click Apply.
Note: You can also delete a CAR profile to prevent the probe to monitor Call Data Records. Right-click the profile name and select Dele
te.
You can generate CAR analysis report by clicking Show CAR Analysis Report button. In the left pane of this report, you can see the Call
Identifier that is a unique ID for each call. You can also see Call From and Call To details and the Time when the call was made. On clicking
any of the Call Identifier, its respective CMR details are displayed in the right pane.
In the CMR Average Summary Analysis section, Jitter indicates the total Jitters of all CMR and No of Packets Lost indicates the total number
of packets lost in all CMR. The remaining fields in CMR Average Summary Analysis section display the average of their respective values.
The fields in the dialog are explained as follows:
Jitter: provides an estimate of the statistical variance of the RTP data packet interarrival time. The time is measured in milliseconds and
expressed as an unsigned integer. The interarrival jitter J specifies the mean deviation (smoothed absolute value) of the difference D in
packet spacing at the receiver. The value is compared to the sender for a pair of packets. RFC 1889 contains detailed computation
algorithms. The value remains zero if the connection was set in "send only" mode. Default is 0.
No. of Packets Lost: displays the number of packets that are lost during the call.
CCR - Cumulative Conceal Ratio: represents the cumulative ratio of concealment time over speech time that is observed after starting a
call.
ICR - Interval Conceal Ratio: represents an interval-based average concealment rate. The rate is the ratio of concealment time over
speech time for the last 3 seconds of active speech.
ICRmx - Interval Conceal Ratio Max: represents the maximum concealment ratio that is observed during the call.
CS - Conceal Secs: represents the time when some concealment is observed during a call.
SCS - Severely Conceal Secs: represents the time when a significant amount of concealment is observed. If the observed concealment
is greater than 50 milliseconds or 5 percent, the speech is not audible.
MLQK - MOS Listening Quality K-factor: provides an estimate of the MOS score of the last 8 seconds of speech on the reception
signal path.
MLQKmn - MOS Listening Quality K-factor Min: represents the minimum score that is observed from the beginning of a call and
represents the worst sounding 8-second interval.
MLQKmx - MOS Listening Quality K-factor Max: represents the maximum score that is observed from the beginning of a call and
represents the best sounding 8-second interval.
MLQKav - MOS Listening Quality K-factor Avg: represents the running average of scores that are observed from the beginning of a
call.
View Phone Table
The Show Phone Table button in the toolbar allows you to view information about registered phone devices.
Follow these steps:
1. Select a configured profile in the left pane.
2. In the toolbar, click Show Phone Table.
The phone details report appears.
Note: If phone details are not available, the probe generates a blank Phone Table report.
The CAR data is stored in the tbnCDR and tbnCMR database tables in your NIS database. Using reporting tools, such as Unified Reporter, you
can create your own CAR Analysis reports.

You can apply monitors to the probe that measure the Cisco UCM performance objects. You can select monitors in one of the following ways:
Manually select monitors from the available list.
Use monitoring templates to apply consistent monitoring patterns across profiles.
Auto-configure monitors to allow auto monitors to be created and automatically monitored for new disks.
Important! CA recommends you to use auto-configuration to create auto-monitors to monitor the Cisco UCM system. You can
configure static monitors for specific instances. Multiple static monitors can increase the size of the .cfg file and causes performance
issues.
You can view and configure all monitors that are applied to a profile in the All Monitors node.
Manually Select Monitors
You can manually select a monitor from the list of monitors in the profile.
Note: The profile monitors initially are not activated. You can activate the ones that you want to monitor. The Enable Monitoring option
on the Monitor Properties dialog for the checkpoint is automatically selected.
Follow these steps:

1. Select a resource or Cisco UCM component in the left pane.
2. Click the checkbox next to the monitor you want to add.
3. Double-click the monitor to open the Monitor Properties dialog.

5. Click Yes, when prompted to restart the probe.
Use Monitoring Templates
Templates can be applied to multiple profiles to measure the same parameters on multiple Cisco UCM systems. A default template is available.
You can drag-and-drop a template on a host profile to apply to all elements for the resource.
You can create templates and can define a set of monitors in that template. For information about creating templates, see Create and Configure
Templates.
Important! If the templates are applied to the inventory tree, the inventory is recursively navigated to create static monitors. The
monitors are created for every checkpoint applicable to the template. Auto-monitor behavior in static form creates a large cfg file and
also creates issues with the performance of your probe.
Auto Configure Monitors
You can add monitors and templates to the Auto Configurations node of a resource. Auto configuration applies the selected monitors to all
components of a resource. Monitors or checkpoints are automatically created for devices that are currently not monitored.
The Auto Configuration feature consists of two nodes that are located under the resource node in the left pane:
Auto Configurations: displays a list of monitor configurations that are automatically applied to the profile.
Auto Monitors: displays a list of all monitors that are configured using the monitor configurations in the Auto Configurations node.
Follow these steps:
1. Select a monitor from a template or the list of available monitors.
2. Drag-and-drop the selected monitor to the auto configuration node.
You can drag-and-drop a template to apply configurations of all monitors in the template.
3. Click the Apply button and restart the probe to activate the changes.
A list of monitors with the applied configurations are displayed in the Auto Monitors node.
Note: Adding multiple monitor or templates to the Auto Configurations node results in multiple Auto Monitors.

Note: If you want to edit an existing Auto Configuration, double-click it and select Edit.

You can configure monitors that generate QoS data and alarm messages in host profiles.
Monitors have an indicator that represents the following status:
Green: indicates that everything is OK.
Black: indicates that the checkpoint is not active.
Other colors: indicates that the monitor is activated for monitoring and the threshold value for the monitor has exceeded. The color
reflects the message token that is selected in the properties dialog for the monitor.
indicates that the checkpoint is not available at the host. This indicator also appears for monitors that are available at the host after
configuration changes. The indicator disappears when measured values are returned from the monitor.
You can right-click a monitor for the following options:
Edit: opens the Monitor Properties dialog, enabling you to modify the monitoring properties for the selected monitor.
Delete: deletes the monitor from the list. If you want to monitor again, locate the monitor in its group in the left pane and activate it.
Activate: activates the selected monitor to be monitored by the probe. You can also activate it by clicking the check box belonging to the
checkpoint.
Deactivate: deactivates the selected monitor (if activated), and the probe stops monitoring the monitor.
Monitor: Opens the Monitor window. The window displays the values that are recorded for the selected monitor during the sample
period. For more information, see View Graphical Monitoring.
Add to Template: allows you to add this monitor to a template.
Follow these steps:
1. Navigate to the monitor category or template in the left pane.
2. Double-click the required monitor from the list of monitors.
Note: Click Query Description to retrieve a predefined description for the monitor. Closing the window copies the
last (mins): specifies the time interval when the probe collects values to compare with the threshold value.
Enable Monitoring: allows you to enable alarm message generation.
Note: The Operator, Threshold Value, Unit, and Message Token fields are enabled only when Publish Alarms is
selected.

Threshold Value: defines the threshold value of the monitor.
Publish Quality of Service (QoS): allows you to enable QoS generation.
5. Select the checkbox next to the monitor name to activate the monitor.
6. Click Apply.
The probe uses the specified monitor.
View Graphical Monitoring
The Monitor window displays the values that are recorded for the selected monitor during the sample period. The sample period in the Setup sec
tion sets the maximum time range that is shown in the window. This time range can be set to a lower value, changing the backlog to a lower
value.
Note: The horizontal red line in the graph indicates the alarm threshold that is defined for the monitor.
When clicking and holding the left mouse button inside the graph, a red vertical line appears. You can continue to hold the left mouse button down
and move the cursor. The window displays the exact value at different points in the graph. The value is displayed in the upper part of the graph on
the format: <Day> <Time> <Value>.
Right-clicking inside the monitor window lets you select the backlog (the time range that is shown in the monitor window). In addition, the
right-click menu lets you select the option Show Average. A horizontal blue line is added in the graph, representing the average sample value.
The following information can be found in the status bar at the bottom of the monitor window:
The number of samples from the probe start
The minimum value measured
The average value measured
The maximum value measured
The backlog is the time range that is shown in the monitor window. The backlog can be selected to 6, 12, 24 or 48 hours by right-clicking
inside the graph.
Note: The graph cannot display time ranges that are greater than the selected Sample Period in the Setup section.

You can create templates in the probe and can configure monitors for that template.
Note: You can drag-and-drop a template to the Auto Configurations node to apply all the monitors in the template as Auto Monitors,
as applicable. For more information, see Auto Configure Monitors.
Follow these steps:

1. Right-click the Templates node in the left pane and select New.
2. Specify a Name and a Description for the template.
3. Click OK.
4. You can use the following options to add monitors to templates:
Select monitors from other templates and drag-and-drop them to the created template.
Select a monitor from the list of available monitors in the probe. Drag-and-drop it from the right pane to the template in the left pane.
6. Drag-and-drop the template to the required profile or group in the left pane to apply the template.
The monitors that are defined in the template are assigned to the corresponding Cisco UCM monitors.
Notes:
If you want to edit a template, right-click on the template and select Edit.
If you do not want to use a template, right-click on the template and select Delete.
You can verify the current values for the monitors by clicking the Get Values button in the toolbar. Click a profile to display the current values in
the Values column.

You can create and configure custom QoS in the probe can be used by monitors.
Follow these steps:
1. Right-click the QoS node in the left pane and select New QOS.
You can also edit an existing QoS or select Add New QoS Definition from the QoS Name field of the Monitor Properties window.
2. Set or modify the following fields, as required to configure the QoS:
Name: enters a name for the QoS.
Group: selects a group where the new QoS belongs.
Default: QOS_STORAGE
Description: enters any additional information for the QoS.
Unit and Unit Abbreviation: selects an appropriate unit and its abbreviation for the QoS.
Flag: allows you to specify whether a QoS is boolean or numeric and has a maximum value.
Has Max: enters the maximum permissible value for the QoS.
3. Click OK to create the QoS.
The QoS Properties dialog closes.
4. Click Apply to save the QoS to the probe.

Note: Variable expansion in the message text is supported. For more information, see Variable Expansion.
Follow these steps:
1. Click
from the toolbar.
2. Click
from the toolbar.
Identification Name: specifies an identification code as a name for the message.
Token: allows you to select the message token to identify the type of message.
Error Alarm Text: specifies the alarm text in case error occurs.
Clear Alarm Text (OK): specifies the alarm text in case no error occurs.
Error Severity: allows you to select the severity level for the error message.
Subsystem string/id: allows you to select the subsystem id for the message.
4. Click OK.
The new message is added.
Variable Expansion
You can enter a $ symbol in the alarm message text to select from the list of variables. The following variables are available in the alarm message
text:
Profile variables
profile
host
node
description
Monitor variables
name
key
value
oper
threshold
unit
state
The values of these variables are retrieved from the monitored system.
cisco_ucm Metrics
This section describes the metrics that can be configured for the Cisco Unified Communications Manager (cisco_ucm) probe.
Contents
QoS Metrics
Metrics
QoS Metrics
The following table describes the QoS metrics that can be configured using the cisco_ucm probe.
Monitor Name
Units
Description
Version
QOS_CCM_CALLS
Calls
Cisco Communications Manager Calls
v1.8
QOS_CCM_DEVICES
Value
Cisco Communications Manager Devices
v1.8
QOS_CCM_DISK_USAGE
MBytes
Disk Usage (Communications Manager)
v1.8
QOS_CCM_RESOURCE
Resources
Cisco Communications Manager Resources
v1.8
QOS_CPU_USAGE
Percent
CPU Usage
v1.8
QOS_DISK_USAGE_PERC
Percent
Disk Usage (%)
v1.8
QOS_MEMORY_USAGE_CCM
Kilobytes
Cisco Communications Manager Memory Usage
v1.8
QOS_MEMORY_USAGE_PERC
Percent
Memory Usage (%)
v1.8
QOS_PROCESS_CPU
Percent
Process CPU Usage
v1.8
QOS_PROCESS_MEMORY
Kilobytes
Process Memory Usage
v1.8
QOS_SERVICE_STATE
State
Cisco Communications Manager Service Availability
v1.8
Metrics
The following table provides the description of the monitors that can be configured using the cisco_ucm probe.
Resource
Monitor Name
Units
Description
Cisco
Annunciator
Device
(ANN_2)\OutOfResources
Represents the total number of times an attempt was

made to allocate an annunciator resource from this
annunciator device and failed, for example, because all
resources were already in use.
Cisco
Annunciator
Device
(ANN_2)\ResourceActive
Represents the total number of annunciator resources

that are currently active (in use) for this annunciator
device.
Cisco
Annunciator
Device
(ANN_2)\ResourceAvailable
Represents the total number of resources that are not

active and are still available to be used at the current
time for the annunciator device.
Cisco
Annunciator
Device
(ANN_2)\ResourceTotal

configured for this annunciator device.
Cisco AXL Web

Service
ThrottleCount
Represents the number of times Administrative XML

Layer (AXL) throttling has been engaged since the last
restart of the Cisco AXL Web Service. Throttling occurs
when the AXL service receives more change requests
than it is able to process.
Cisco AXL Web

Service
ThrottleState
Represents whether Administrative XML Layer (AXL)

throttling is currently active (throttling is engaged). A
value of 1 in this counter indicates that throttling is
currently engaged, which means that any application
attempting to send a write request to Cisco Unified
Communications Manager via AXL will be denied due to
AXL throttling. Read requests will continue to be allowed
and processed while AXL throttling is engaged. A value
of zero indicates that throttling is not occurring at this
time and all read and write requests will be processed.
Cisco Call
Restriction
AdHocConferenceFailures
Represents the number of attempts that failed to add a

participant to an Ad Hoc Conference because the call
path between the geolocation of the devices already in
conference and the device being invited to the
conference was restricted due to a logical partition policy.
Cisco Call
Restriction
BasicCallFailures
Represents the number of basics calls that have failed

because of logical partition policy restrictions between
the geolocations of the called and calling parties. A basic
call is any call that does not utilize supplementary
services such as transfer, forward, and so on.
Cisco Call
Restriction
ForwardingFailures
Represents the number of attempts to forward an

incoming call which failed because of a logical partition
policy restriction between the geolocations of the two
parties involved.
Cisco Call
Restriction
LogicalPartitionFailuresTotal
Represents the total number of call attempts that have

failed because of a restriction of calls between
geolocations of the calling and called parties. This
includes the number of failures for Transfer, Ad Hoc
Conference, Meet-Me Conference, PickUp, Call Park,
Shared Lines and Basic Calls.
Cisco Call
Restriction
MeetMeConferenceFailures
Represents the number of attempts that failed to add a

participant to a Meet-Me Conference because the call
path between the geolocation of the devices already in
conference and the device attempting to join the
conference was restricted due to a logical partition policy.
Cisco Call
Restriction
MidCallFailures
Represents the number of calls that have failed because

of a restriction between the geolocations of the called or
connected parties after the initial policy check.
Cisco Call
Restriction
ParkRetrievalFailures
Represents the number of attempts to perform a Call

Park operation that failed because the device that was
attempting to retrieve the call had a logical partition policy
restriction with the geolocation of the parked party.
Cisco Call
Restriction
PickUpFailures
Represents the number of attempts to perform a PickUp

operation that failed because the device on which the
pickup was being attempted had a logical partition policy
restriction with the geolocation of the calling device.
Cisco Call
Restriction
SharedLineFailures
Represents the number of attempts to use a shared line

which failed because the caller or callee has a logical
partition policy restriction with the geolocation of the
devices having the shared lines.
Cisco Call
Restriction
TransferFailures
Represents the number of call transfer attempts that

failed due to restriction of calls between the geolocation
of the transferred party and the transferred destination
Cisco Call
Manager
AnnunciatorOutOfResources
Represents the total number of times that

Communications Manager attempted to allocate an
annunciator resource from those that are registered to
this Communications Manager when none were
available.
Cisco Call
Manager
AnnunciatorResourceActive

that are currently in use on all annunciator devices
registered with this Communications Manager.
Cisco Call
Manager
AnnunciatorResourceAvailable

that are not active and are currently available.
Cisco Call
Manager
AnnunciatorResourceTotal

provided by all annunciator devices that are currently
Cisco Call
Manager
AuthenticatedCallsActive
Represents the number of authenticated calls that are

currently active (in use) on this Communications
Manager. An authenticated call is one in which all the
endpoints participating in the call are authenticated. An
authenticated phone uses the Transport Layer Security
(TLS) authenticated Skinny protocol signaling with
Communications Manager.
Cisco Call
Manager
AuthenticatedCallsCompleted
Represents the number of authenticated calls that were

connected and subsequently disconnected through this
Communications Manager. An authenticated call is one
in which all the endpoints participating in the call are
authenticated. An authenticated phone uses the
Transport Layer Security (TLS) authenticated Skinny
protocol signaling with Communications Manager.
Cisco Call
Manager
AuthenticatedPartiallyRegisteredPhone
Represents the number of partially registered

authenticated SIP Phones.
Cisco Call
Manager
AuthenticatedRegisteredPhones
Represents the total number of authenticated phones

registered to this Communications Manager. An
authenticated phone uses the Transport Layer Security
(TLS) authenticated Skinny protocol signaling with
Cisco Call
Manager
BRIChannelsActive
Represents the number of BRI voice channels that are

currently in an active call on this Communications
Manager.
Cisco Call
Manager
BRISpansInService
Represents the number of BRI spans that are currently

available for use.
Cisco Call
Manager
Communications ManagerHeartBeat
Represents the heartbeat of Communications Manager.

This is an incremental count that indicates that
Communications Manager is alive and running. If the
count does not increment, then Communications
Manager is down (dead).
Cisco Call
Manager
CallsActive
Represents the number of voice or video streaming

connections that are currently in use (active). In other
words, the number of calls that actually have a voice path
connected on this Communications Manager.
Cisco Call
Manager
CallsAttempted
Represents the total number of attempted calls. Any time

a phone goes off-hook and back on-hook, it is considered
an attempted call, regardless of whether any digits were
dialed or if it connected to a destination. Some call
attempts are made by the system during feature
operations (such as transfer and conference) and are
considered attempted calls
Cisco Call
Manager
CallsCompleted
Represents the number of calls that were actually

connected (a voice path or video stream was
established) through this Communications Manager. This
number increments when the call is terminated.
Cisco Call
Manager
CallsInProgress
Represents the number of voice or video calls that are

currently in progress on this Communications Manager,
including all active calls. When a phone goes off-hook, it
is a call in progress until it goes back on-hook. When all
voice or video calls that are in progress are connected,
the number of CallsInProgress and the number of
CallsActive are the same.
Cisco Call
Manager
CumulativeAllocatedResourceCannotOpenPort
Represents the total number of calls that failed when the

allocated resource failed to open a port for media
transmission.
Cisco Call
Manager
EncryptedCallsActive
Represents the number of encrypted calls that are

currently active (in use) on this Communications
Manager. An encrypted call is one in which all the
endpoints participating in the call are encrypted.
Cisco Call
Manager
EncryptedCallsCompleted
Represents the number of encrypted calls that were

connected and subsequently disconnected through this
Communications Manager. An encrypted call is one in
which all the endpoints participating in the call are
encrypted.
Cisco Call
Manager
EncryptedPartiallyRegisteredPhones
Represents the number of partially registered encrypted

SIP Phones.
Cisco Call
Manager
EncryptedRegisteredPhones
Represents the total number of encrypted phones

registered to this Communications Manager.
Cisco Call
Manager
ExternalCallControlEnabledCallsAttempted
Specifies the total number of calls to devices that have

the External Call Control feature enabled. This is a
cumulative count of all calls to intercept-enabled patterns
or DNs since the last restart of the Cisco
Communications Manager service.
Cisco Call
Manager
ExternalCallControlEnabledCallsCompleted
Specifies the total number of calls that were connected to

a device that had the External Call Control feature
enabled. This is a cumulative count of all calls to
intercept-enabled patterns or DNs since the last restart of
the Cisco Communications Manager service.
Cisco Call
Manager
ExternalCallControlEnabledFailureTreatmentApplied
Specifies the total number of calls that were cleared or

routed based on failure treatments (such as Allow or
Deny) that are defined in the External Call Control profile.
Cisco Call
Manager
FXOPortsActive
Represents the number of FXO ports that are currently in

use (active) on this Communications Manager.
Cisco Call
Manager
FXOPortsInService
Represents the number of FXO ports that are currently

available for use in the system.
Cisco Call
Manager
FXSPortsActive
Represents the number of FXS ports that are currently in

use (active) on this Communications Manager.
Cisco Call
Manager
FXSPortsInService
Represents the number of FXS ports that are currently

available for use in the system.
Cisco Call
Manager
HuntListsInService
Represents the number of hunt/route lists that are

currently in service on this Communications Manager.
Cisco Call
Manager
HWConferenceActive
Represents the number of active conferences on all

hardware conference devices registered with this
Cisco Call
Manager
HWConferenceCompleted
Represents the total number of conferences that used a

hardware conference bridge (hardware-based
conference devices such as Cisco Catalyst 6000, Cisco
Catalyst 4000, Cisco VG200, Cisco series 26xx and
36xx) allocated from this Communications Manager and
have been completed, which means that the conference
bridge has been allocated and released. A conference is
activated when the first call is connected to the bridge.
The conference is completed when the last call
disconnects from the bridge.
Cisco Call
Manager
HWConferenceResourceActive
Represents the total number of times Communications

Manager attempted to allocate a hardware conference
resource from those that are registered to this
Communications Manager when none were available.
Cisco Call
Manager
HWConferenceResourceAvailable
Represents the total number of conference resources

that are in use on all hardware conference devices (such
as Cisco Catalyst 6000, Catalyst 4000, Cisco VG200,
Cisco series 26xx and 36xx) that are registered with this
Communications Manager. A conference is considered
active when one or more calls are connected to a bridge.
One resource is equal to one stream.
Cisco Call
Manager
HWConferenceResourceTotal
Represents the total number of hardware conference

resources provided by all hardware conference bridge
devices that are currently registered with this
Cisco Call
Manager
InitializationState
Represents the current state of Cisco Communications

Manager initialization. The following values specify
initialization states: 1-Database; 2-Regions; 3-Locations;
4-QoS Policy; 5-Time Of Day; 6-AAR Neighborhoods;
7-Digit Analysis; 8-Route Plan; 9-Call Control; 10-RSVP
Session Manager; 11-Mobility Generic Device;
12-Mobility Call Park; 13-Supplementary Services;
14-SDL Link; 15-Device; 100-Initialization Complete. Not
all states will be displayed using this counter. This is not
an error; it simply indicates that the state(s) were
processed to completion within the refresh period of the
performance monitor.
Cisco Call
Manager
LocationOutOfResources
Represents the total number of times that a call through

Locations failed due to lack of bandwidth.
Cisco Call
Manager
MCUConferencesActive
Represents the total number of active conferences on all

Cisco Telepresence MCU conference bridge devices
Cisco Call
Manager
MCUConferencesCompleted

Cisco Telepresence MCU conference bridge allocated
from this Communications Manager and have been
completed, which means that the conference bridge has
been allocated and released. A conference is activated
when the first call is connected to the bridge. The
conference completes when the last call disconnects
from the bridge that were connected and released.
Cisco Call
Manager
MCUHttpConnectionErrors

made by Communications Manager to create HTTP
connections to this Cisco Telepresence MCU conference
bridge device and failed because of connection error on
Cisco Telepresence MCU conference bridge side.
Cisco Call
Manager
MCUHttpNon200OkResponse

Manager received a non 200 OK HTTP Response from
Cisco Telepresence MCU conference bridge (for any
HTTP query sent by Communications Manager).
Cisco Call
Manager
MCUOutOfResources

made by Communications Manager to allocate a
conference resource from this Cisco Telepresence MCU
conference bridge device and failed, for example,
because all resources were already in use.
Cisco Call
Manager
MOHMulticastResourceActive
Represents the total number of multicast MOH resources

that are currently in use (active) on all MOH servers
Cisco Call
Manager
MOHMulticastResourceAvailable
Represents the total number of active multicast MOH

connections that are not being used on all MOH servers
that are registered with this Communications Manager.
Cisco Call
Manager
MOHOutOfResources
Represents the total number of times that the Media

Resource Manager attempted to allocate an MOH
resource when all available resources on all MOH
servers registered with this Communications Manager
were already active.
Cisco Call
Manager
MOHTotalMulticastResources
Represents the total number of multicast MOH resources

or connections provided by all MOH servers that are
currently registered with this Communications Manager.
Cisco Call
Manager
MOHTotalUnicastResources
Represents the total number of unicast MOH resources

or streams provided by all MOH servers that are currently
registered with this Communications Manager. Each
MOH unicast resource uses one stream.
Cisco Call
Manager
MOHUnicastResourceActive

that are currently in use (active) on all MOH servers that
are registered with this Communications Manager. Each
MOH unicast resource uses one stream.
Cisco Call
Manager
MOHUnicastResourceAvailable

that are currently available on all MOH servers registered
with this Communications Manager. Each MOH unicast
resource uses one stream.
Cisco Call
Manager
MTPOutOfResources

Manager attempted to but failed to allocate an MTP
resource from one of the MTP devices that is registered
with this Communications Manager. This also means that
no transcoders were available to act as MTPs.
Cisco Call
Manager
MTPRequestsThrottled
Represents the total number of media termination point

(MTP) resource requests that have been denied due to
throttling (a resource from this MTP was not allocated
because, as specified by the Cisco Communications
Manager service parameter, MTP and Transcoder
Resource Throttling Percentage, the MTP was being
utilized beyond the configured throttle percentage). This
counter increments each time a request for an MTP on
this Cisco Unified Communications Manager (Unified
CM) node is requested and denied due to MTP throttling
and reflects a running total since the start of the Cisco
Cisco Call
Manager
MTPResourceActive
Represents the total number of Media Termination Point

(MTP) resources that are currently in use (active) on all
MTP devices registered with this Communications
Manager. Each MTP resource uses two streams. An
MTP in use is one MTP resource that has been allocated
for use in a call.
Cisco Call
Manager
MTPResourceAvailable
Represents the total number of MTP resources that are

not in use and are available to be allocated on all MTP
devices that are registered with this Communications
Manager. Each MTP resource uses two streams. An
MTP in use is one MTP resource that has been allocated
for use in a call.
Cisco Call
Manager
MTPResourceTotal

resources provided by all MTP devices that are currently
Cisco Call
Manager
PartiallyRegisteredPhone
Represents the number of partially registered SIP

Phones.
Cisco Call
Manager
PRIChannelsActive
Represents the number of PRI voice channels that are in

an active call on this CallManager.
Cisco Call
Manager
PRISpansInService
Represents the number of PRI spans that are currently

available for use.
Cisco Call
Manager
RegisteredAnalogAccess
Represents the number of registered Cisco Analog

Access gateways that are registered with this system.
This does not include the number of Cisco Analog
Access ports.
Cisco Call
Manager
RegisteredHardwarePhones
Represents the number of Cisco hardware IP phones (for

example, models 7960, 7940, 7910, etc.) that are
currently registered in the system.
Cisco Call
Manager
RegisteredMGCPGateway
Represents the number of MGCP gateways currently

registered in the system.
Cisco Call
Manager
RegisteredOtherStationDevices
Represents the number of station devices other than

Cisco hardware IP phones that are currently registered in
the system (for example, Cisco IP SoftPhone, CTI port,
CTI route point, Cisco voice mail port).
Cisco Call
Manager
SIPLineServerAuthorizationChallenges
Represents the number of authentication challenges for

incoming SIP requests that Cisco Communications
Manager has issued to SIP phones. An authentication
challenge occurs when a SIP phone sends a SIP line
request to Cisco Communications Manager and Digest
Authentication is enabled for that phone.
Cisco Call
Manager
SIPLineServerAuthorizationFailures
Represents the number of authentication challenge

failures for incoming SIP requests from SIP phones to
Cisco Communications Manager. An authentication
failure occurs when a SIP phone sends a SIP line
request with bad credentials to Cisco Communications
Manager and Digest Authentication is enabled for that
phone.
Cisco Call
Manager
SIPTrunkApplicationAuthorizationFailures
Represents the number of application-level authorization

failures for incoming SIP requests that have occurred on
Cisco Communications Manager SIP trunks. An
application-level authorization failure occurs when Cisco
Communications Manager compares an incoming SIP
request to the SIP feature settings on the Application
User Configuration window in Cisco Communications
Manager Administration and finds that application-level
authorization for one or more of the SIP features on that
window is not allowed.
Cisco Call
Manager
SIPTrunkApplicationAuthorizations
Represents the number of application-level authorization

checks for incoming SIP requests that Cisco
Communications Manager has issued to SIP trunks. An
application-level authorization check occurs when Cisco
request to the SIP feature settings on the Application
User Configuration window in Cisco Communications
Manager Administration. Note: This check only occurs if
Enable Digest Authentication and Enable Application
Level Authorization checkboxes are enabled in the SIP
Trunk Security Profile Configuration window.
Cisco Call
Manager
SIPTrunkAuthorizationFailures
Represents the number of trunk-level authorization

failures for incoming SIP requests that have occurred on
Cisco Communications Manager SIP trunks. A trunk-level
authorization failure occurs when Cisco Communications
Manager compares an incoming SIP request to the SIP
feature authorization settings on the SIP Trunk Security
Profile Configuration window in Cisco Communications
Manager Administration and finds that authorization for
one or more of the SIP features on that window is not
allowed.
Cisco Call
Manager
SIPTrunkAuthorizations
Represents the number of trunk-level authorization

checks for incoming SIP requests that Cisco
Communications Manager has issued to SIP trunks. A
trunk-level authorization check occurs when Cisco
request to the SIP feature authorization settings on the
SIP Trunk Security Profile Configuration window in Cisco
Communications Manager Administration.
Cisco Call
Manager
SIPTrunkServerAuthenticationChallenges
Represents the number of authentication challenges for

incoming SIP requests that that Cisco Communications
Manager has issued to SIP trunks. An authentication
challenge occurs when a SIP trunk sends a SIP request
to Cisco Communications Manager and Digest
Authentication is enabled for that trunk.
Cisco Call
Manager
SIPTrunkServerAuthenticationFailures
Represents the number of authentication challenge

failures for incoming SIP requests from SIP trunks to
Cisco Communications Manager. An authentication
failure occurs when a SIP trunk sends a SIP request with
bad credentials to Cisco Communications Manager and
Digest Authentication is enabled for that trunk.
Cisco Call
Manager
SWConferenceActive
Represents the number of active conferences on all

software conference devices registered with this
Cisco Call
Manager
SWConferenceCompleted

software conference bridge allocated from this
Communications Manager and have been completed,
which means that the conference bridge has been
allocated and released. A conference is activated when
the first call is connected to the bridge. The conference is
completed when the last call disconnects from the bridge.
Cisco Call
Manager
SWConferenceOutOfResources

Manager attempted to allocate a software conference
resource from those that are registered to this
This counter includes failed attempts to add a new
participant to an existing conference.
Cisco Call
Manager
SWConferenceResourceActive

that are in use on all software conference devices
registered with this Communications Manager. A
conference is considered active when one or more calls
are connected to a bridge. One resource is equal to one
stream.
Cisco Call
Manager
SWConferenceResourceAvailable
Represents the number of new software-based

conferences that can be started at this point in time for
this Communications Manager. A minimum of three
streams must be available for each new conference. One
resource is equal to one stream.
Cisco Call
Manager
SWConferenceResourceTotal
Represents the total number of software conference

resources provided by all software conference bridge
Cisco Call
Manager
SystemCallsAttempted
Represents the total number of server Originated calls

and attempted calls to Unity Message waiting
indicator(MWI) numbers.
Cisco Call
Manager
T1ChannelsActive
Represents the number of T1 CAS voice channels that

are in an active call on this Communications Manager.
Cisco Call
Manager
T1SpansInService
Represents the number of T1 CAS spans that are

currently available for use.
Cisco Call
Manager
TLSConnectedSIPTrunks
Represents the number of SIP Trunks configured and

connected via Transport Layer Security (TLS).
Cisco Call
Manager
TLSConnectedWSM
Represents the number of WSM Connectors configured

and connected to Motorola WSM via Transport Layer
Security (TLS).
Cisco Call
Manager
TranscoderOutOfResources

Manager attempted to allocate a transcoder resource
from one of the transcoder devices that is registered to
this Communications Manager when none were
available.
Cisco Call
Manager
TranscoderRequestsThrottled
Represents the total number of transcoder resource

requests that have been denied due to throttling (a
resource from this transcoder was not allocated because,
as specified by the Cisco Communications Manager
service parameter, MTP and Transcoder Resource
Throttling Percentage, the transcoder was being utilized
beyond the configured throttle percentage). This counter
increments each time a request for a transcoder on this
Cisco Unified Communications Manager (Unified CM)
node is requested and denied due to transcoder throttling
and reflects a running total since the start of the Cisco
Cisco Call
Manager
TranscoderResourceActive
Represents the total number of transcoders that are in

use on all transcoder devices registered with this
Communications Manager. A transcoder in use is one
transcoder resource that has been allocated for use in a
call. Each transcoder resource uses two streams.
Cisco Call
Manager
TranscoderResourceAvailable
Represents the total number of transcoders that are not

in use and are available to be allocated on all transcoder
devices that registered with this Communications
Manager. Each transcoder resource uses two streams.
Cisco Call
Manager
TranscoderResourceTotal
Represents the total number of transcoder resources

provided by all transcoder devices that are currently
Cisco Call
Manager
VCBConferencesActive
Represents the total number of active video conferences

on all video conference bridge devices registered with
this Communications Manager.
Cisco Call
Manager
VCBConferencesAvailable
Represents the total number of new video conferences

that can be started on all video conference bridge
devices registered with this Communications Manager.
Cisco Call
Manager
VCBConferencesCompleted
Represents the total number of video conferences that

used a video conference bridge allocated from this
Communications Manager and have been completed,
which means that the conference bridge has been
allocated and released. A conference is activated when
the first call is connected to the bridge. The conference
completes when the last call disconnects from the bridge
that were connected and released.
Cisco Call
Manager
VCBConferencesTotal
Represents the total number of video conferences

supported on all video conference bridge devices
registered with this -Communications Manager.
Cisco Call
Manager
VCBOutOfConferences
Represents the total number of failed new video

conference requests. A conference request can fail
because, for example, the configured number of
conferences are already in use.
Cisco Call
Manager
VCBOutOfResources
Represents the total number of times that

Communications Manager attempted to allocate a video
conference resource from those that are registered to this
Cisco Call
Manager
VCBResourceActive
Represents the total number of video conference

resources that are currently in use on all video
conference devices that are registered with this
Cisco Call
Manager
VCBResourceAvailable

resources that are not active and are currently available.
Cisco Call
Manager
VCBResourceTotal

resources provided by all video conference bridge
Cisco Call
Manager
VideoCallsActive
Represents the number of active video calls with active

video streaming connections on all video conference
bridge devices registered with this Communications
Manager.
Cisco Call
Manager
VideoCallsCompleted
Represents the number of video calls that were actually

connected with video streams and then released.
Cisco Call
Manager
VideoOutOfResources

Manager attempted to allocate a video streaming
resource from one of the video conference bridge
devices that is registered to this Communications
Manager when none were available.
Cisco Unified
Communications
Manager
System
Performance
AverageExpectedDelay
Represents the current average expected delay to handle

any incoming message.
Cisco Unified
Communications
Manager
System
Performance
CallsRejectedDueToThrottling
Represents the total number of calls rejected since the

start of service due to call throttling.
Cisco Unified
Communications
Manager
System
Performance
CallThrottlingGenericCounter3
Represents a generic counter used for call throttling

purposes.
Cisco Unified
Communications
Manager
System
Performance
CodeRedEntryExit
Indicates whether Communications Manager has entered

or exited a Code Red state (call throttling mode). Valid
values are 0 (Exit) and 1 (Entry).
Cisco Unified
Communications
Manager
System
Performance
CodeYellowEntryExit
Indicates whether Communications Manager has entered

or exited a Code Yellow state (call throttling mode). Valid
values are 0 (Exit) and 1 (Entry).
Cisco Unified
Communications
Manager
System
Performance
EngineeringCounter1
This counter is not used unless directed by a Cisco

Engineering Special build. Information in this counter will
be used by Cisco for diagnostic purposes.
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsPresent 1-High
Indicates the number of high-priority signals in the Cisco

Unified Communications Manager (Unified CM) queue.
High priority signals include timeout events, internal
Cisco Unified Communications Manager KeepAlives,
certain gatekeeper events, and internal process creation,
among other events. A large number of high priority
events will cause degraded performance on Unified CM,
resulting in slow call connection or loss of dial tone. Use
this counter in conjunction with the
QueueSignalsProcessed 1-High counter to determine the
processing delay on Unified CM.
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsPresent 2-Normal
Indicates the number of normal-priority signals in the

Cisco Unified Communications Manager (Unified CM)
queue. Normal priority signals include call processing
functions, key presses, on-hook and off-hook
notifications, among other events. A large number of
normal priority events will cause degraded performance
on Unified CM, sometimes resulting in delayed dial tone,
slow call connection, or loss of dial tone. Use this counter
in conjunction with the QueueSignalsProcessed
2-Normal counter to determine the call processing delay
on Unified CM. Remember that high priority signals must
complete before normal priority signals begin to process,
so check the high priority counters as well to get an
accurate picture of the potential delay.
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsPresent 3-Low
Indicates the number of low-priority signals in the Cisco

Unified Communications Manager queue. Low priority
signals include station device registration (except the
initial station registration request message), among other
events. A large number of signals in this queue could
result in delayed device registration, among other events.
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsPresent 4-Lowest
Indicates the number of lowest-priority signals in the

Cisco Unified Communications Manager queue. Lowest
priority signals include the initial station registration
request message during device registration, among other
events. A large number of signals in this queue could
result in delayed device registration, among other events.
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsPresent 5-Database
Indicates the number of database-priority signals in the

Cisco Unified Communications Manager queue.
Database priority signals are generally restricted to
database updates (add, move, and delete operations). A
large number of signals in this queue will not affect call
processing.
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsPresent 6-Interleaved
Indicates the number of interleaved-priority signals in the

Cisco Unified Communications Manager queue.
Interleaved priority signals include gatekeeper
unregistration, among other events. A large number of
signals in this queue will not significantly affect call
processing. Note that signals in this queue interleave
(alternate) with the signals from all other queues,
regardless of the signal priority.
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsProcessed 1-High
Indicates the number of high-priority signals processed

by Cisco Unified Communications Manager (Unified CM)
for each one-second interval. Use this counter in
conjunction with the QueueSignalsPresent 1-High
counter to determine the processing delay on this queue.
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsProcessed 2-Normal
Indicates the number of normal-priority signals processed

by Cisco Unified Communications Manager for each
one-second interval. Use this counter in conjunction with
the QueueSignalsPresent 2-Normal counter to determine
the processing delay on this queue. Remember that high
priority signals are processed before normal priority
signals.
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsProcessed 3-Low
Indicates the number of low-priority signals processed by

Cisco Unified Communications Manager for each
the QueueSignalsPresent 3-Low counter to determine
the processing delay on this queue. The number of
signals processed gives an indication of how much
device registration activity is being processed in this time
interval.
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsProcessed 4-Lowest
Indicates the number of lowest-priority signals processed

by Cisco Unified Communications Manager for each
the QueueSignalsPresent 4-Lowest counter to determine
the processing delay on this queue. The number of
signals processed gives an indication of how many
devices began the Communications Manager registration
process in this time interval.
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsProcessed 5-Database
Indicates the number of database priority signals

processed by Cisco Unified Communications Manager
conjunction with the QueueSignalsPresent 5-Database
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsProcessed 6-Interleaved
Indicates the number of interleaved-priority signals

processed by Cisco Unified Communications Manager
conjunction with the QueueSignalsPresent 6-Interleaved
Cisco Unified
Communications
Manager
System
Performance
QueueSignalsProcessed Total
Provides a sum total of all queue signals processed by

Cisco Unified Communications Manager for each
one-second period for all queue levels: high, normal, low,
and lowest.
Cisco Unified
Communications
Manager
System
Performance
SkinnyDevicesThrottled
Represents the total number of Skinny devices being

throttled. A Skinny device is throttled (asked to shutdown
and reregister) when the total number of events
generated by a Skinny device exceeds the configured
maximum threshold value (default value is 2000 events)
within a 5 second time period.
Cisco Unified
Communications
Manager
System
Performance
ThrottlingSampleActivity
Indicates how many samples, out of configured sample

size, are having non-zero averageExpectedDelay values.
This counter gets reset when any sample has zero
averageExpectedDelay value. This process is repeated
for each batch of samples. A batch represents the
configured sample size.
Cisco Unified
Communications
Manager
System
Performance
TotalCodeYellowEntry
Indicates the number of times CCM call processing

enters code yellow state. This counter is cumulative since
the start of the CCM process.
Cisco Car
Database
(CAR_DB_Perfmon_Instance)\CARDBSpaceUsed
Represents the amount in percentage (%) of cardbspace

consumed. The CAR DB space cardbspace is used by
CAR database in CAR IDS instance.
Cisco Car
Database
(CAR_DB_Perfmon_Instance)\CARTempDBSpaceUsed
Represents the amount in percentage (%) of cartempdbs

consumed. The CAR Temp DB space cartempdbs is
used by temporary tables in CAR IDS instance, used by
CAR applications.
Cisco Car
Database
(CAR_DB_Perfmon_Instance)\FreeSharedMemory
Represents the total shared memory that is free in

kilobytes (KB). Shared memory is used by database
system and all database applications in CAR IDS
instance.
Cisco Car
Database
(CAR_DB_Perfmon_Instance)\RootDBSpaceUsed
Represents the amount in percentage (%) of rootdbs

consumed. The root DB space rootdbs is used by IDS
system tables in CAR IDS instance.
Cisco Car
Database
(CAR_DB_Perfmon_Instance)\UsedSharedMemory
Represents the total shared memory that is used in

kilobytes (KB). Shared memory is used by database
system and all database applications in CAR IDS
instance.
Cisco CTI
Manager
CcmLinkActive
Represents the active Communications Manager link to

CTIManager.
Cisco CTI
Manager
CTIConnectionActive
Represents the number of applications connected to this

CTIManager.
Cisco CTI
Manager
DevicesOpen
Represents the number of devices open by all

applications connecting to this CTIManager.
Cisco CTI
Manager
LinesOpen
Represents the number of lines open by all applications

connecting to this CTIManager.
Cisco CTI
Manager
QBEVersion
Represents the QBE Protocol version supported by

CTIManager.
Cisco Extension
Mobility
Active Inter-cluster Sessions
Represents the total number of inter cluster Extension

Mobility requests requests that are currently in progress.
Cisco Extension
Mobility
EMCC Check User Requests Handled
Represents the total number of EMCC check user

requests that came from remote clusters.
Cisco Extension
Mobility
Number of Unknown Remote Users
Represents the total number of users who were not found

in any of the remote cluster during inter-cluster extension
mobility login.
Cisco Extension
Mobility
Requests Handled
Represents the total number of HTTP requests handled

by the Extension Mobility service since the last restart of
the service. A typical login would constitute two HTTP
requests: one to query the initial login state of the device
and another to login the user on a device. Similarly, a
typical logout also results in two HTTP requests.
Cisco Extension
Mobility
Requests In Progress
Represents the number of HTTP requests currently being

handled by the Extension Mobility service. A typical login
would constitute two HTTP requests:one to query the
initial login state of the device and another to login the
user on a device. Similarly, a typical logout also results in
two HTTP requests.
Cisco Extension
Mobility
Requests Throttled
Represents the total number of Login/Logout Requests

that failed due to throttling.
Cisco Extension
Mobility
Successful Logins
Represents the total number of successful login requests

completed through EM Service.
Cisco Extension
Mobility
Successful Logouts
Represents the total number of successful logout

requests completed through EMService.
Cisco Extension
Mobility
Total Attempted Login/Logout Requests
Represents the total number of Login and Logout

requests attempted through this EM Service. This
includes both successful and unsuccessful attempts.
Cisco Extension
Mobility
Total Number of EMCC Messages
Represents the total number of messages related to

EMCC Requests that came from remote clusters.
Cisco Extension
Mobility
Total Number of Remote Devices
Represents the total number of devices from other

clusters that are currently using an EMCC Base Device
(EMCC Logged in).
Cisco Extension
Mobility
Total Number of Remote Users
Represents the total number of users from other cluster

who use a local device of this cluster and have logged
into a remote cluster.
Cisco H323
(InterClusterTrunkToAvaya)\CallsActive
Represents the number of streaming connections that

are currently active (in use) on the configured H.323
device. In other words, the number of calls that actually
have a voice path connected.
Cisco H323
(InterClusterTrunkToAvaya)\CallsAttempted
Represents the total number of calls that have been

attempted on this device, including both successful and
unsuccessful call attempts.
Cisco H323
(InterClusterTrunkToAvaya)\CallsCompleted
Represents the total number of successful calls made

from the device.
Cisco H323
(InterClusterTrunkToAvaya)\CallsInProgress
Represents the number of calls currently in progress on

this device.
Cisco H323
(InterClusterTrunkToAvaya)\CallsRejectedDueToICTCallThrottling
Represents the total number of calls rejected since the

start of the Cisco Communications Manager service due
to Intercluster Trunk (ICT) call throttling. When the
threshold limit of 140 calls per 5 seconds is met, the ICT
will start throttling (rejecting) new calls. One cause for
ICT call throttling occurs when calls across an ICT enter
a route loop condition.
Cisco H323
(InterClusterTrunkToAvaya)\VideoCallsActive
Represents the number of video calls with video

streaming connections that are currently active (in use)
on all H.323 trunks registered with this Communications
Manager. In other words, the number of calls that actually
have video streaming connections on this
Cisco H323
(InterClusterTrunkToAvaya)\VideoCallsCompleted

connected with video streams for all H.323 trunks
registered with this Communications Manager. This
Cisco IP
Manager
Assistant
AssistantsActive
Represents the number of assistant consoles that are

currently active. An assistant console is considered
active when an assistant is logged in from his or her
assistant console desktop application.
Cisco IP
Manager
Assistant
LinesOpen
Represents the number of phone lines opened by the

Cisco IPMA application. A phone line is considered open
when the IPMA application assumes line control from
CTI.
Cisco IP
Manager
Assistant
ManagersActive
Represents the current number of manager consoles that

are currently being serviced by the Cisco IPMA
application.
Cisco IP
Manager
Assistant
SessionsCurrent
Represents the total number of managers/assistants

currently using the Cisco IPMA application. Each
manager and each assistant constitutes an active
session, so for one manager/assistant pair, this counter
would reflect two sessions.
Cisco Lines
(5001)\Active
Represents the state of the line, either active or not

active. A zero indicates the line is not in use. If the
number is greater than zero, the line is active and the
number represents the number of calls currently in
progress on that line. If more than one call is active, this
indicates the call is on hold either because of being
placed on hold specifically (user hold), or because of a
network hold operation (for example, a transfer is in
progress and it is on transfer hold). This applies to all
directory numbers assigned to any device.
Cisco Locations
(Hub_None)\BandwidthAvailable
Represents the current bandwidth available in a given

location. A value of zero indicates that no bandwidth is
available. Note that when Directionalization is configured,
this counter represents the sum of the
AudioBWAvailableInbound, AudioBWAvailableOutbound
and AudioBWAvailableCommon counters. Calls in
progress on this Unified CM and on other Unified CM
nodes impact this value.
Cisco Locations
(Hub_None)\BandwidthMaximum
Represents the maximum bandwidth available in a given

location. A value of zero indicates that unlimited
bandwidth is available. Note that when Directionalization
is configured, this counter represents the sum of the
AudioBWReservedInbound, AudioBWReservedOutbound
and AudioBWReservedCommon counters.
Cisco Locations
(Hub_None)\CallsInProgress
Represents the number of calls currently in progress on

this Unified CM.
Cisco Locations
(Hub_None)\OutOfResources
Represents the total number of times that a call on this

Communications Manager through the location failed due
to lack of bandwidth.
Cisco Locations
(Hub_None)\RSVP AudioReservationErrorCounts
Represents the number of RSVP reservation error counts

for audio stream.
Cisco Locations
(Hub_None)\RSVP MandatoryConnectionsInProgress
Represents the number of connections in progress that

has mandatory RSVP.
Cisco Locations
(Hub_None)\RSVP OptionalConnectionsInProgress
Represents the number of connections in progress that

has optional RSVP.
Cisco Locations
(Hub_None)\RSVP TotalCallsFailed
Represents the number of total calls that failed due to

RSVP reservation failure.
Cisco Locations
(Hub_None)\RSVP VideoCallsFailed
Represents the number of video calls that failed due to

RSVP reservation failure.
Cisco Locations
(Hub_None)\RSVP VideoReservationErrorCounts
Represents the number of RSVP reservation error counts

for video stream.
Cisco Locations
(Hub_None)\VideoBandwidthAvailable
Represents the bandwidth currently available for video in

the location where the video call participant resides. A
value of zero indicates that no bandwidth is available.
Cisco Locations
(Hub_None)\VideoBandwidthMaximum
Represents the maximum bandwidth available for video

in the location where the video call participant resides. A
value of zero indicates no bandwidth is allocated for
video while a value of -1 indicates that unlimited video
bandwidth is available.
Cisco Locations
(Hub_None)\VideoOutOfResources
Represents the total number of failed video calls in the

location where the video call participant resides.
Cisco Media
Streaming App
ANNConnectionsLost
Represents the total number of times since the last

restart of the Cisco IP Voice Media Streaming Application
that a Communications Manager connection was lost.
Cisco Media
Streaming App
ANNConnectionState
Represents the total number of annunciator instances

that have been started since the Cisco IP Voice Media
Streaming Application service started.
Cisco Media
Streaming App
ANNConnectionsTotal
Represents the total number of annunciator instances

that have been started since the Cisco IP Voice Media
Streaming Application service started.
Cisco Media
Streaming App
ANNInstancesActive
Represents the number of actively playing (currently in

use) announcements.
Cisco Media
Streaming App
ANNStreamsActive
Represents the total number of currently active simplex

(one direction) streams for all connections. Each stream
direction counts as one stream. There is one internal
stream providing the audio input and another output
stream to the endpoint device.
Cisco Media
Streaming App
ANNStreamsAvailable
Represents the remaining number of streams allocated

for the annunciator device that are available for use. This
counter starts as 2 multiplied by the number of
configured connections (defined in the Cisco IP Voice
Media Streaming App service parameter for the
Annunciator, Call Count) and is reduced by one for each
active stream started.
Cisco Media
Streaming App
ANNStreamsTotal
Represents the total number of simplex (one direction)

streams that have been connected to the annunciator
device since the Cisco IP Voice Media Streaming
Application service started.
Cisco Media
Streaming App
CFBConferencesActive
Represents the number of active (currently in use)

conferences.
Cisco Media
Streaming App
CFBConferencesTotal
Represents the total number of conferences that have

been started since the Cisco IP Voice Media Streaming
Cisco Media
Streaming App
CFBConferencesLost

Cisco Media
Streaming App
CFBConferenceState
For each Communications Manager associated with a

SW Conference Bridge, this represents the current
registration state to Communications Manager; 0
indicates no registration to Communications Manager; 1
indicates registration to the primary Communications
Manager; 2 indicates connection to the secondary
Communications Manager (connected to
Communications Manager but not registered until the
primary Communications Manager connection fails).
Cisco Media
Streaming App
CFBStreamsActive

(one direction) streams for all conferences. Each stream
direction counts as one stream. In a three-party
conference, the number of active streams is 6.
Cisco Media
Streaming App
CFBStreamsAvailable

for the conference bridge that are available for use. This
Media Streaming App service parameter for Conference
Bridge, Call Count) and is reduced by one for each active
stream started.
Cisco Media
Streaming App
CFBStreamsTotal

streams that have been connected to the conference
bridge since the Cisco IP Voice Media Streaming
Cisco Media
Streaming App
MOHAudioSourcesActive
Represents the number of active (currently in use) audio

sources for this MOH server. Some of these audio
sources may not be actively streaming audio data if there
are no devices listening. The exception is for multicast
audio sources, which will always be streaming audio.
NOTE: Current behavior for this counter is such that
when an audio source is in use, even after the listener
has disconnected, this counter will always have one input
stream for each configured MOH codec. For unicast
streams, the stream may be in a suspended state where
no audio data is received until a device connects to listen
to the stream. Each MOH multicast resource uses one
stream for each audio source and codec combination.
For example, if you have configured the default audio
source for multicast, G.711 mu-law and wideband
codecs, then two streams are used (default audio source
+ G.711 mu-law and default audio source + wideband).
Cisco Media
Streaming App
MOHConnectionsLost

Cisco Media
Streaming App
MOHConnectionState
For each Communications Manager associated with an

MOH, this represents the current registration state to
Communications Manager; 0 indicates no registration to
Communications Manager; 1 indicates registration to the
primary Communications Manager; 2 indicates
connection to the secondary Communications Manager
(connected to Communications Manager but not
registered until the primary Communications Manager
connection fails).
Cisco Media
Streaming App
MOHStreamsActive
Represents the total number of active (currently in use)

simplex (one direction) streams for all connections. There
is one output stream for each device listening to a
unicast audio source and one input stream for each
active audio source, multiplied by the number of MOH
codecs. NOTE: Current behavior for this counter is such
that when an audio source has been used once, it will
always have one input stream for each configured MOH
codec. For unicast streams, the stream may be in a
suspended state where no audio data is received until a
device connects to listen to the stream. Each MOH
multicast resource uses one stream for each audio
source and codec combination. For example, if you have
configured the default audio source for multicast, G.711
mu-law and wideband codecs, then two streams are
used (default audio source + G.711 mu-law and default
audio source + wideband).
Cisco Media
Streaming App
MOHStreamsAvailable

for the MOH device that are available for use. This
counter starts as 408 plus the number of configured
half-duplex unicast connections, and is reduced by 1 for
each active stream started. The counter is reduced by 2
for each multicast audio source, multiplied by the number
of MOH codecs configured. The counter is reduced by 1
for each unicast audio source, multiplied by the number
of MOH codecs configured.
Cisco Media
Streaming App
MOHStreamsTotal

streams that have connected to the MOH server since
the Cisco IP Voice Media Streaming Application service
started.
Cisco Media
Streaming App
MTPConnectionsLost

Cisco Media
Streaming App
MTPConnectionsState
For each Communications Manager associated with an

MTP, this represents the current registration state to
Communications Manager; 0 indicates no registration to
Communications Manager; 1 indicates registration to the
primary Communications Manager; 2 indicates
connection to the secondary Communications Manager
(connected to Communications Manager but not
registered until the primary Communications Manager
connection fails).
Cisco Media
Streaming App
MTPConnectionsTotal
Represents the total number of MTP instances that have

been started since the Cisco IP Voice Media Streaming
Cisco Media
Streaming App
MTPInstancesActive
Represents the number of active (currently in use)

instances of MTP.
Cisco Media
Streaming App
MTPStreamsActive

(one direction) streams for all connections. Each stream
direction counts as one stream.
Cisco Media
Streaming App
MTPStreamsAvailable

for the MTP device that are available for use. This
Media Streaming App service parameter for MTP, Call
Count) and is reduced by one for each active stream
started.
Cisco Media
Streaming App
MTPStreamsTotal

streams that have been connected to the MTP device
since the Cisco IP Voice Media Streaming Application
service started.
Cisco
Messaging
Interface
HeartBeat
Represents the heartbeat of the CMI service. This is an

incremental count that indicates that CMI service is alive
and running. If the count does not increment, then the
CMI service is down (dead).
Cisco
Messaging
Interface
SMDIMessageCountInbound
Represents the running count of inbound SMDI

messages since the last restart of the CMI service.
Cisco
Messaging
Interface
SMDIMessageCountInbound24Hour
Represents the rolling count of inbound SMDI messages

in the last 24 hours.
Cisco
Messaging
Interface
SMDIMessageCountOutbound
Represents the running count of outbound SMDI

messages since the last restart of the CMI service.
Cisco
Messaging
Interface
SMDIMessageCountOutbound24Hour
Represents the rolling count of outbound SMDI

messages in the last 24 hours.
Cisco
Messaging
Interface
StartTime
Represents the time in milliseconds when the CMI

service started. This time is based on the real-time clock
in the computer, which is simply a reference point that
indicates the current time and the length of time that has
elapsed, in milliseconds, since the service started. The
reference point is midnight, January 1, 1970.
Cisco MGCP
Gateways
(nclabrtr01.ca.com)\BRIChannelsActive
Represents the number of BRI voice channels that are

currently active in a call in the gateway.
Cisco MGCP
Gateways
(nclabrtr01.ca.com)\BRISpansInService
Represents the number of BRI spans that are currently

available for use in the gateway.
Cisco MGCP
Gateways
(nclabrtr01.ca.com)\FXOPortsActive

active in a call in the gateway.
Cisco MGCP
Gateways
(nclabrtr01.ca.com)\FXOPortsInService

Cisco MGCP
Gateways
(nclabrtr01.ca.com)\FXSPortsActive

active in a call in the gateway.
Cisco MGCP
Gateways
(nclabrtr01.ca.com)\FXSPortsInService

Cisco MGCP
Gateways
(nclabrtr01.ca.com)\PRIChannelsActive
Represents the number of PRI voice channels that are

currently active in a call in the gateway.
Cisco MGCP
Gateways
(nclabrtr01.ca.com)\PRISpansInService
Represents the number of PRI spans that are currently

Cisco MGCP
Gateways
(nclabrtr01.ca.com)\T1ChannelsActive
Represents the number of T1 CAS voice channels that

are currently active in a call in the gateway.
Cisco MGCP
Gateways
(nclabrtr01.ca.com)\T1SpansInService
Represents the number of T1 CAS spans that are

currently available for use in the gateway.
Cisco MGCP
PRI Device
(nclabrtr01.ca.com::S0_SU1_DS1-0)\CallsActive
Represents the number of calls that are currently active

(in use) on this MGCP PRI device.
Cisco MGCP
PRI Device
(nclabrtr01.ca.com::S0_SU1_DS1-0)\CallsCompleted
Represents the total number of successful calls made

from this MGCP PRI device.
Cisco MGCP
PRI Device
(nclabrtr01.ca.com::S0_SU1_DS1-0)\Channel 1 Status
Represents the status of the indicated B-Channel

associated with this MGCP PRI device. Possible values:
0 (Unknown) indicates the status of the channel could not
be determined; 1 (Out of service) indicates that this
channel is not available for use; 2 (Idle) indicates that this
channel has no active call and is ready for use; 3 (Busy)
indicates an active call on this channel; 4 (Reserved)
indicates that this channel has been reserved for use as
a D-channel or for use as a Synch-Channel for E-1.
Cisco MGCP
PRI Device
(nclabrtr01.ca.com::S0_SU1_DS1-0)\DatalinkInService
Represents the state of the Data Link (D-Channel) on the

corresponding Digital Access gateway. This value will be
set to 1 (one) if the Data Link is up (in service) or 0 (zero)
if the Data Link is down (out of service).
Cisco MGCP
PRI Device
(nclabrtr01.ca.com::S0_SU1_DS1-0)\OutboundBusyAttempts
Represents the total number of times a call through this

MGCP PRI device was attempted when there were no
voice channels available.
Cisco Mobility
Manager
MobileCallsAnchored
Represents the total number of call legs associated with

single-mode/dual-mode phones currently anchored in
Cisco Communications Manager. Call anchoring occurs
when a call enters an enterprise gateway and connects
to a mobility application that, in turn, uses redirection to
send the call back out an enterprise gateway. For
example, this counter increments twice for a dual-mode
phone-to-dual-mode phone call: once for the originating
call and once for the terminating call. When the call is
terminated, this counter decrements accordingly.
Cisco Mobility
Manager
MobileHandinsCompleted
Represents the total number of handins completed by

dual-mode phones. A completed handin occurs when the
call successfully connects in the enterprise network when
the phone moves from WAN to WLAN.
Cisco Mobility
Manager
MobileHandoutsCompleted
Represents the total number of handouts (calls on mobile

devices that move from the enterprise WLAN network to
the cellular network) that were completed. A completed
handout occurs when the call successfully connects.
Cisco Mobility
Manager
MobileHandoutsFailed
Represents the total number of handouts (calls on mobile

devices that move from cellular to the wireless network)
that failed.
Cisco Mobility
Manager
MobilityFollowMeCallsAttempted
Represents the total number of follow-me calls

attempted.
Cisco Mobility
Manager
MobilityFollowMeCallsIgnoredDueToAnswerTooSoon
Represents the total number of follow-me calls ignored

before AnswerTooSoon timer pops.
Cisco Mobility
Manager
MobilityHandinsAborted
Represents the total number of handins aborted.
Cisco Mobility
Manager
MobilityHandinsFailed
Represents the total number of handins (calls on mobile

devices that move from cellular to the wireless network)
that failed.
Cisco Mobility
Manager
MobilityHandoutsAborted
Represents the total number of handouts aborted.
Cisco Mobility
Manager
MobilityIVRCallsAttempted
Represents the total number of IVR calls attempted.
Cisco Mobility
Manager
MobilityIVRCallsFailed
Represents the total number of failed IVR calls.
Cisco Mobility
Manager
MobilityIVRCallsSucceeded
Represents the total number of successful IVR calls.
Cisco Mobility
Manager
MobilitySCCPDualModeRegistered
Represents the total number of dual mode SCCP devices

registered.
Cisco Mobility
Manager
MobilitySIPDualModeRegistered
Represents the total number of dual mode SIP devices

registered.
Cisco MOH
Device
(MOH_2)\MOHHighestActiveResources
Represents the largest number of simultaneously active

MOH connections for this MOH server. This includes
both multicast and unicast connections.
Cisco MOH
Device
(MOH_2)\MOHMulticastResourceActive
Represents the number of currently active multicast

connections to multicast addresses served by this MOH
server.
Cisco MOH
Device
(MOH_2)\MOHMulticastResourceAvailable
Represents the number of multicast MOH connections to

multicast addresses served by this MOH server that are
not active and are still available to be used at the current
time for this MOH server.
Cisco MOH
Device
(MOH_2)\MOHOutOfResources
Represents the total number of times that the Media

Resource Manager attempted to allocate an MOH
resource when all available resources on all MOH
servers registered with this Communications Manager
were already active.
Cisco MOH
Device
(MOH_2)\MOHTotalMulticastResources
Represents the total number of multicast MOH

connections allowed to multicast addresses served by
this MOH server.
Cisco MOH
Device
(MOH_2)\MOHTotalUnicastResources
Represents the total number of unicast MOH connections

allowed by this MOH server. Each MOH unicast resource
uses one stream.
Cisco MOH
Device
(MOH_2)\MOHUnicastResourceActive
Represents the number of active unicast MOH

connections to this MOH server. Each MOH unicast
Cisco MOH
Device
(MOH_2)\MOHUnicastResourceAvailable
Represents the number of unicast MOH connections that

are not active and are still available to be used at the
current time for this MOH server. Each MOH unicast
Cisco MTP
Device
(MTP_2)\AllocatedResourceCannotOpenPort

allocated MTP resource failed to open a port for media
transmission.
Cisco MTP
Device
(MTP_2)\OutOfResources

made to allocate an MTP resource from this MTP device
and failed, for example, because all resources were
already in use.
Cisco MTP
Device
(MTP_2)\RequestsThrottled

(MTP) resource requests that have been denied due to
throttling (a resource from this MTP was not allocated
because, as specified by the Cisco Communications
Manager service parameter, MTP and Transcoder
Resource Throttling Percentage, the MTP was being
utilized beyond the configured throttle percentage). This
counter increments each time a resource is requested
and denied from this MTP due to throttling. This counter
reflects a running total since the MTP device registered
with the Cisco Communications Manager service.
Cisco MTP
Device
(MTP_2)\ResourceActive
Represents the number of MTP resources that are

currently in use (active) for this MTP device. Each MTP
resource uses two streams. An MTP in use is one MTP
resource that has been allocated for use in a call.
Cisco MTP
Device
(MTP_2)\ResourceAvailable
Represents the total number of MTP resources that are

not active and are still available to be used at the current
time for the MTP device. Each MTP resource uses two
streams. An MTP in use is one MTP resource that has
been allocated for use in a call.
Cisco MTP
Device
(MTP_2)\ResourceTotal
Represents the total number of MTP resources provided

by this MTP device. This counter is equal to the sum of
the counters ResourceAvailable and ResourceActive.
Cisco Phones
(SEP00170EF03493)\CallsAttempted
Represents the number of calls that has been attempted

to and from this phone. This increments each time a
phone Goes Offhook/Onhook, or when it receives a call.
No increments take place under call waiting. However it
gets incremented for every call leg that is Destroyed in
the case of Hold/ Resume, Park, PickUp Conference,
CallForward No Answer etc.
Cisco Presence
Features
ActiveCallListAndTrunkSubscriptions
Represents the active presence subscriptions for the call

list feature as well as presence subscriptions through SIP
trunk.
Cisco Presence
Features
ActiveSubscriptions
Represents all active incoming and outgoing Presence

subscriptions.
Cisco Presence
Features
CallListAndTrunkSubscriptionsThrottled
Represents the cumulative count of rejected call list and

trunk side presence subscriptions due to throttling.
Cisco Presence
Features
IncomingLineSideSubscriptions
Represents cumulative count of presence subscriptions

received on the line side.
Cisco Presence
Features
IncomingTrunkSideSubscriptions

received on the trunk side.
Cisco Presence
Features
OutgoingTrunkSideSubscriptions

sent on the trunk side.
Cisco QSIG
Features
(CiscoQSIGFeatureObject)\CallForwardByRerouteCompleted
Represents the number of successful call forward by

reroutes that have occurred. Call forward by reroute
enables the path for a forwarded call to be as optimal
(minimize the number of B-Channels in use) as possible
from the originator's perspective. This counter resets
when the Communications Manager service parameter
Call Forward by Reroute Enabled is enabled or disabled,
or when the Cisco Communications Manager service
restarts.
Cisco QSIG
Features
(CiscoQSIGFeatureObject)\PathReplacementCompleted
Represents the number of successful path replacements

that have occurred. Path replacement is used in a QSIG
network to optimize the path between two edge PINX
(PBXs) involved in a call. This counter resets when the
Communications Manager service parameter Path
Replacement Enabled is enabled or disabled, or when
the Cisco Communications Manager service restarts.
Cisco SAF
Client
SAFFConnectionsFailed
Represents the total number of SAF client connections

that have failed on this Unified CM node. A failed
connection is a connection that did not register with the
SAF Forwarder.
Cisco SAF
Client
SAFFConnectionsSucceeded
Represents the total number of SAF client connections

currently active on this Unified CM node.
Cisco Signaling
SIPTCPConnectionsClosed
Represents the total number of TCP connections closed

because they exceeded the per-second dataRateLimit
threshold for number of incoming bytes allowed from a
single IP address. The threshold is set via the Cisco
Communications Manager service parameters, SIP
Station TCP Port Throttle Threshold and SIP Trunk TCP
Port Throttle Threshold. This counter increments for
every TCP connection closed since the last restart of the
Cisco Communications Manager service.
Cisco Signaling
TCPSIPMaxIncomingMessageHeadersExceeded
Represents the number of incoming TCP SIP messages

that were dropped and caused the TCP connection to be
reset because they exceeded the maximum number of
allowed headers.
Cisco Signaling
TCPSIPMaxIncomingMessageSizeExceeded
Represents the number of incoming TCP SIP messages

that were dropped and caused the TCP connection to be
reset because they exceeded the maximum allowed
message size.
Cisco Signaling
UDPPacketsThrottled
Represents the total number of incoming UDP packets

that were throttled (dropped) because they exceeded the
per-second threshold for number of incoming packets
allowed from a single IP address. The threshold is
configured via the SIP Station UDP Port Throttle
Threshold and SIP Trunk UDP Port Throttle Threshold
service parameters in the Cisco Communications
Manager service. This counter increments for every
throttled UDP packet since the last restart of the Cisco
Cisco Signaling
UDPSIPMaxIncomingMessageHeadersExceeded
Represents the number of incoming UDP SIP messages

that were dropped because they exceeded the maximum
number of allowed headers..
Cisco Signaling
UDPSIPMaxIncomingMessageSizeExceeded
Represents the number of incoming UDP SIP messages

that were dropped because they exceeded the maximum
allowed message size.
Cisco SIP
(InterClusterTrunkToCM80)\CallsActive
Represents the number of calls that are currently active

(in use) on this SIP device.
Cisco SIP
(InterClusterTrunkToCM80)\CallsAttempted
Represents the number of calls which have been

attempted on this SIP device, including both successful
and unsuccessful call attempts.
Cisco SIP
(InterClusterTrunkToCM80)\CallsCompleted
Represents the number of calls that were actually

connected (a voice path was established) from this SIP
device. This number increments when the call is
terminated.
Cisco SIP
(InterClusterTrunkToCM80)\CallsInProgress
Represents the number of calls that are currently in

progress on this SIP device, including all active calls.
When all calls that are in progress are connected, the
number of CallsInProgress and the number of CallsActive
are the same.
Cisco SIP
(InterClusterTrunkToCM80)\VideoCallsActive
Represents the number of video calls with streaming

video connections that are currently active (in use) on
this SIP device.
Cisco SIP
(InterClusterTrunkToCM80)\VideoCallsCompleted

connected with video streams for this SIP device. This
Cisco SIP Stack
AckIns
Represents the total number of ACK requests received

by the SIP device.
Cisco SIP Stack
AckOuts
Represents the total number of ACK requests sent by the

SIP device.
Cisco SIP Stack
ActiveTcpTlsConnections
Represents the total number of TCP and TLS

connections currently in use by the SIP stack.
Cisco SIP Stack
ByeIns
Represents the total number of BYE requests received

by the SIP device, including retransmissions.
Cisco SIP Stack
ByeOuts
Represents the total number of BYE requests sent by the

SIP device, including retransmissions.
Cisco SIP Stack
CancelIns
Represents the total number of CANCEL requests

received by the SIP device, including retransmissions.
Cisco SIP Stack
CancelOuts
Represents the total number of CANCEL requests sent

Cisco SIP Stack
CCBsAllocated
Represents the number of Call Control Blocks (CCB) that

are currently in use by the SIP stack. One CCB is used
for each active SIP dialog.
Cisco SIP Stack
GlobalFailedClassIns
Represents the total number of 6xx class SIP responses

This class of responses indicates failure responses
received by a SIP device that provides a client function.
The responses generally indicate that a server has
definitive information about a particular called party, not
just the particular instance indicated in the Request-URI.
Cisco SIP Stack
GlobalFailedClassOuts

sent by the SIP device, including retransmissions. This
class of responses indicates failure responses sent by a
SIP device that provides a server function. The
responses generally indicate that a server has definitive
information about a particular called party, not just the
particular instance indicated in the Request-URI.
Cisco SIP Stack
InfoClassIns

This class of responses provides information concerning
the progress of processing a SIP request.
Cisco SIP Stack
InfoClassOuts

class of responses provides information concerning the
progress of processing a SIP request.
Cisco SIP Stack
InfoIns
Represents the total number of INFO requests received

Cisco SIP Stack
InfoOuts
Represents the total number of INFO requests sent by

the SIP device, including retransmissions.
Cisco SIP Stack
InviteIns
Represents the total number of INVITE requests received

Cisco SIP Stack
InviteOuts
Represents the total number of INVITE requests sent by

Cisco SIP Stack
NotifyIns
Represents the total number of NOTIFY requests

Cisco SIP Stack
NotifyOuts
Represents the total number of NOTIFY requests sent by

Cisco SIP Stack
OptionsIns
Represents the total number of OPTIONS requests

Cisco SIP Stack
OptionsOuts
Represents the total number of OPTIONS requests sent

Cisco SIP Stack
PRAckIns
Represents the total number of PRACK requests

Cisco SIP Stack
PRAckOuts
Represents the total number of PRACK requests sent by

Cisco SIP Stack
PublishIns
Represents the total number of PUBLISH requests

Cisco SIP Stack
PublishOuts
Represents the total number of PUBLISH requests sent

Cisco SIP Stack
RedirClassIns

This class of responses provides information about
redirections to addresses where the callee might be
reachable.
Cisco SIP Stack
RedirClassOuts

class of responses provides information about
redirections to addresses where the callee might be
reachable.
Cisco SIP Stack
ReferIns
Represents the total number of REFER requests

Cisco SIP Stack
ReferOuts
Represents the total number of REFER requests sent by

Cisco SIP Stack
RegisterIns
Represents the total number of REGISTER requests

Cisco SIP Stack
RegisterOuts
Represents the total number of REGISTER requests sent

Cisco SIP Stack
RequestsFailedClassIns

This class of responses indicates request failure by a SIP
device that provides a client function.
Cisco SIP Stack
RequestsFailedClassOuts

class of responses indicates request failure by a SIP
device that provides a server function.
Cisco SIP Stack
RetryByes
Represents the total number of BYE retries that have

been sent by the SIP device. To determine the number of
'first attempt' BYEs, subtract the value of this counter
from the value of the sipStatsByeOuts counter.
Cisco SIP Stack
RetryCancels
Represents the total number of CANCEL retries that

have been sent by the SIP device. To determine the
number of 'first attempt' CANCELs, subtract the value of
this counter from the value of the sipStatsCancelOuts
counter.
Cisco SIP Stack
RetryInfo
Represents the total number of INFO retries that have

'first attempt' INFOs, subtract the value of this counter
from the value of the sipStatsInfoOuts counter.
Cisco SIP Stack
RetryInvites
Represents the total number of INVITE retries that have

'first attempt' INVITEs, subtract the value of this counter
from the value of the sipStatsInviteOuts counter.
Cisco SIP Stack
RetryNotify
Represents the total number of NOTIFY retries that have

'first attempt' NOTIFYs, subtract the value of this counter
from the value of the sipStatsNotifyOuts counter.
Cisco SIP Stack
RetryPRAck
Represents the total number of PRACK retries that have

'first attempt' PRACKs, subtract the value of this counter
from the value of the sipStatsPRAckOuts counter.
Cisco SIP Stack
RetryPublish
Represents the total number of PUBLISH re tries that

number of 'first attempt' PUBLISHs, subtract t he value of
this counter from the value of the sipStatsPublishOuts
counter.
Cisco SIP Stack
RetryRefer
Represents the total number of REFER retries that have

'first attempt' REFERs, subtract the value of this counter
from the value of the sipStatsReferOuts counter.
Cisco SIP Stack
RetryRegisters
Represents the total number of REGISTER retries that

number of 'first attempt' REGISTERSs, subtract the value
of this counter from the value of the sipStatsRegisterOuts
counter.
Cisco SIP Stack
RetryRel1xx
Represents the total number of Reliable 1xx retries that

have -been sent by the SIP device.
Cisco SIP Stack
RetryRequestsOut
Represents the total number of Request retries that have

been sent by the SIP device.
Cisco SIP Stack
RetryResponsesFinal
Represents the total number of Final Response retries

that have been sent by the SIP device.
Cisco SIP Stack
RetryResponsesNonFinal
Represents the total number of non-Final Response

retries that have been sent by the SIP device.
Cisco SIP Stack
RetrySubscribe
Represents the total number of SUBSCRIBE retries that

number of 'first attempt' SUBSCRIBEs, subtract the value
of this counter from the value of the
sipStatsSubscribeOuts counter.
Cisco SIP Stack
RetryUpdate
Represents the total number of UPDATE retries that

number of 'first attempt' UPDATEs, subtract the value of
this counter from the value of the sipStatsUpdateOuts
counter.
Cisco SIP Stack
SCBsAllocated
Represents the number of Subscription Control Blocks

(SCB) that are currently in use by the SIP stack. One
SCB is used for each subscription.
Cisco SIP Stack
ServerFailedClassIns

This class of responses indicates failure responses
received by a SIP device that provides a client function.
Cisco SIP Stack
ServerFailedClassOuts

class of responses indicates failure responses sent by a
SIP device that provides a server function.
Cisco SIP Stack
SIPHandlerSDLQueueSignalsPresent
Represents the number of SDL signals currently on all

four of the SIPHandler component's SDL priority queues.
The SIPHandler component contains the SIP stack.
Cisco SIP Stack
SIPMessagesAllocated
Represents the number of SIPMessage_t objects that are

currently in use by the SIP stack.
Cisco SIP Stack
SIPNewRegistrationPending
Represents the number of SIP device registrations that

are pending. The counter increments when Cisco Unified
Communications Manager (Unified CM) receives a
Register message from a SIP endpoint and decrements
when Unified CM acknowledges the Register message.
Information in this counter will be used by Cisco for
diagnostic purposes.
Cisco SIP Stack
StatusCode100Ins
Represents the total number of 100 Trying response

messages received by the SIP device, including
retransmissions.
Cisco SIP Stack
StatusCode100Outs
Represents the total number of 100 Trying response

messages sent by the SIP device, including
retransmissions.
Cisco SIP Stack
StatusCode180Ins
Represents the total number of 180 Ringing response

retransmissions.
Cisco SIP Stack
StatusCode180Outs
Represents the total number of 180 Ringing response

retransmissions.
Cisco SIP Stack
StatusCode181Ins
Represents the total number of 181 Call Is Being

Forwarded response messages received by the SIP
device, including retransmissions.
Cisco SIP Stack
StatusCode181Outs
Represents the total number of 181 Call Is Being

Forwarded response messages sent by the SIP device,
including retransmissions.
Cisco SIP Stack
StatusCode182Ins
Represents the total number of 182 Queued response

retransmissions.
Cisco SIP Stack
StatusCode182Outs
Represents the total number of 182 Queued response

retransmissions.
Cisco SIP Stack
StatusCode183Ins
Represents the total number of 183 Session Progress

response messages received by the SIP device,
Cisco SIP Stack
StatusCode183Outs
Represents the total number of 183 Session Progress

response messages sent by the SIP device, including
retransmissions.
Cisco SIP Stack
StatusCode200Ins
Represents the total number of 200 OK response

retransmissions.
Cisco SIP Stack
StatusCode200Outs
Represents the total number of 200 OK response sent

Cisco SIP Stack
StatusCode202Ins
Represents the total number of 202 Success Accepted

Cisco SIP Stack
StatusCode202Outs
Represents the total number of 202 Success Accepted

retransmissions.
Cisco SIP Stack
StatusCode300Ins
Represents the total number of 300 Multiple Choices

Cisco SIP Stack
StatusCode301Ins
Represents the total number of 301 Moved Permanently

Cisco SIP Stack
StatusCode302Ins
Represents the total number of 302 Moved Temporarily

Cisco SIP Stack
StatusCode302Outs
Represents the total number of 302 Moved Temporarily

retransmissions.
Cisco SIP Stack
StatusCode303Ins
Represents the total number of 303 Incompatible

Bandwidth Units response messages received by the SIP
Cisco SIP Stack
StatusCode305Ins
Represents the total number of 305 Use Proxy response

retransmissions.
Cisco SIP Stack
StatusCode380Ins
Represents the total number of 380 Alternative Service

Cisco SIP Stack
StatusCode400Ins
Represents the total number of 400 Bad Request

Cisco SIP Stack
StatusCode400Outs
Represents the total number of 400 Bad Request

retransmissions.
Cisco SIP Stack
StatusCode401Ins
Represents the total number of 401 Unauthorized

Cisco SIP Stack
StatusCode401Outs
Represents the total number of 401 Unauthorized

retransmissions.
Cisco SIP Stack
StatusCode402Ins
Represents the total number of 402 Payment Required

Cisco SIP Stack
StatusCode402Outs
Represents the total number of 402 Payment Required

retransmissions.
Cisco SIP Stack
StatusCode403Ins
Represents the total number of 403 Forbidden response

retransmissions.
Cisco SIP Stack
StatusCode403Outs
Represents the total number of 403 Forbidden response

retransmissions.
Cisco SIP Stack
StatusCode404Ins
Represents the total number of 404 Not Found response

retransmissions.
Cisco SIP Stack
StatusCode404Outs
Represents the total number of 404 Not Found response

retransmissions.
Cisco SIP Stack
StatusCode405Ins
Represents the total number of 405 Method Not Allowed

Cisco SIP Stack
StatusCode405Outs
Represents the total number of 405 Method Not Allowed

retransmissions.
Cisco SIP Stack
StatusCode406Ins
Represents the total number of 406 Not Acceptable

Cisco SIP Stack
StatusCode406Outs

retransmissions.
Cisco SIP Stack
StatusCode407Ins
Represents the total number of 407 Proxy Authentication

Required response messages received by the SIP
Cisco SIP Stack
StatusCode407Outs
Represents the total number of 407 Proxy Authentication

Required response messages sent by the SIP device,
Cisco SIP Stack
StatusCode408Ins
Represents the total number of 408 Request Timeout

Cisco SIP Stack
StatusCode408Outs
Represents the total number of 408 Request Timeout

retransmissions.
Cisco SIP Stack
StatusCode409Ins
Represents the total number of 409 Conflict response

retransmissions.
Cisco SIP Stack
StatusCode409Outs
Represents the total number of 409 Conflict response

retransmissions.
Cisco SIP Stack
StatusCode410Ins
Represents the total number of 410 Gone response

retransmissions.
Cisco SIP Stack
StatusCode410Outs
Represents the total number of 410 Gone response

retransmissions.
Cisco SIP Stack
StatusCode413Ins
Represents the total number of 413 Request Entity Too

Large response messages received by the SIP device,
Cisco SIP Stack
StatusCode413Outs
Represents the total number of 413 Request Entity Too

Large response messages sent by the SIP device,
Cisco SIP Stack
StatusCode414Ins
Represents the total number of 414 Request-URI Too

Long response messages received by the SIP device,
Cisco SIP Stack
StatusCode414Outs
Represents the total number of 414 Request-URI Too

Long response messages sent by the SIP device,
Cisco SIP Stack
StatusCode415Ins
Represents the total number of 415 Unsupported Media

Type response messages received by the SIP device,
Cisco SIP Stack
StatusCode415Outs
Represents the total number of 415 Unsupported Media

Type response messages sent by the SIP device,
Cisco SIP Stack
StatusCode416Ins
Represents the total number of 416 Unsupported URI

Scheme response messages received by the SIP device,
Cisco SIP Stack
StatusCode416Outs
Represents the total number of 416 Unsupported URI

Scheme response messages sent by the SIP device,
Cisco SIP Stack
StatusCode417Ins
Represents the total number of 417 Unknown

Resource-Priority response messages received by the
Cisco SIP Stack
StatusCode417Outs
Represents the total number of 417 Unknown

Resource-Priority response messages sent by the SIP
Cisco SIP Stack
StatusCode420Ins
Represents the total number of 420 Bad Extension

Cisco SIP Stack
StatusCode420Outs
Represents the total number of 420 Bad Extension

retransmissions.
Cisco SIP Stack
StatusCode422Ins
Represents the total number of 422 Session Expires

Value Too Small response messages received by the
Cisco SIP Stack
StatusCode422Outs
Represents the total number of 422 Session Expires

Value Too Small response messages sent by the SIP
Cisco SIP Stack
StatusCode423Ins
Reflects the total number of 423 Interval Too Brief

Cisco SIP Stack
StatusCode423Outs
Reflects the total number of 423 Interval Too Brief

retransmissions.
Cisco SIP Stack
StatusCode424Ins
Reflects the total number of 424 Bad Location

Information response messages received by the SIP
Cisco SIP Stack
StatusCode424Outs
Reflects the total number of 424 Bad Location

Information response messages sent by the SIP device,
Cisco SIP Stack
StatusCode480Ins
Represents the total number of 480 Temporarily

Unavailable response messages received by the SIP
Cisco SIP Stack
StatusCode480Outs
Represents the total number of 480 Temporarily

Unavailable response messages sent by the SIP device,
Cisco SIP Stack
StatusCode481Ins
Represents the total number of 481 Call/Transaction

Does Not Exist response messages received by the SIP
Cisco SIP Stack
StatusCode481Outs
Represents the total number of 481 Call/Transaction

Does Not Exist response messages sent by the SIP
Cisco SIP Stack
StatusCode482Ins
Represents the total number of 482 Loop Detected

Cisco SIP Stack
StatusCode482Outs
Represents the total number of 482 Loop Detected

retransmissions.
Cisco SIP Stack
StatusCode483Ins
Represents the total number of 483 Too Many Hops

Cisco SIP Stack
StatusCode483Outs
Represents the total number of 483 Too Many Hops

retransmissions.
Cisco SIP Stack
StatusCode484Ins
Represents the total number of 484 Address Incomplete

Cisco SIP Stack
StatusCode484Outs
Represents the total number of 484 Address Incomplete

retransmissions.
Cisco SIP Stack
StatusCode485Ins
Represents the total number of 485 Ambiguous response

retransmissions.
Cisco SIP Stack
StatusCode485Outs
Represents the total number of 485 Ambiguous response

retransmissions.
Cisco SIP Stack
StatusCode486Ins
Represents the total number of 486 Busy Here response

retransmissions.
Cisco SIP Stack
StatusCode486Outs
Represents the total number of 486 Busy Here response

retransmissions.
Cisco SIP Stack
StatusCode487Ins
Represents the total number of 487 Request Terminated

Cisco SIP Stack
StatusCode487Outs
Represents the total number of 487 Request Terminated

retransmissions.
Cisco SIP Stack
StatusCode488Ins
Represents the total number of 488 Not Acceptable Here

Cisco SIP Stack
StatusCode488Outs
Represents the total number of 488 Not Acceptable Here

retransmissions.
Cisco SIP Stack
StatusCode489Ins
Represents the total number of 489 Bad Subscription

Event response messages received by the SIP device,
Cisco SIP Stack
StatusCode489Outs
Represents the total number of 489 Bad Subscription

Event response messages sent by the SIP device,
Cisco SIP Stack
StatusCode491Ins
Represents the total number of 491 Request Pending

Cisco SIP Stack
StatusCode491Outs
Represents the total number of 491 Request Pending

retransmissions.
Cisco SIP Stack
StatusCode500Ins
Represents the total number of 500 Server Internal Error

Cisco SIP Stack
StatusCode500Outs
Represents the total number of 500 Server Internal Error

retransmissions.
Cisco SIP Stack
StatusCode501Ins
Represents the total number of 501 Not Implemented

Cisco SIP Stack
StatusCode501Outs
Represents the total number of 501 Not Implemented

retransmissions.
Cisco SIP Stack
StatusCode502Ins
Represents the total number of 502 Bad Gateway

Cisco SIP Stack
StatusCode502Outs
Represents the total number of 502 Bad Gateway

retransmissions.
Cisco SIP Stack
StatusCode503Ins
Represents the total number of 503 Service Unavailable

Cisco SIP Stack
StatusCode503Outs
Represents the total number of 503 Service Unavailable

retransmissions.
Cisco SIP Stack
StatusCode504Ins
Represents the total number of 504 Server Time-out

Cisco SIP Stack
StatusCode504Outs
Represents the total number of 504 Server Time-out

retransmissions.
Cisco SIP Stack
StatusCode505Ins
Represents the total number of 505 Version Not

Supported response messages received by the SIP
Cisco SIP Stack
StatusCode505Outs
Represents the total number of 505 Version Not

Supported response messages sent by the SIP device,
Cisco SIP Stack
StatusCode580Ins
Represents the total number of 580 Precondition Failed

Cisco SIP Stack
StatusCode580Outs
Represents the total number of 580 Precondition Failed

retransmissions.
Cisco SIP Stack
StatusCode600Ins
Represents the total number of 600 Busy Everywhere

Cisco SIP Stack
StatusCode600Outs
Represents the total number of 600 Busy Everywhere

retransmissions.
Cisco SIP Stack
StatusCode603Ins
Represents the total number of 603 Decline response

retransmissions.
Cisco SIP Stack
StatusCode603Outs
Represents the total number of 603 Decline response

retransmissions.
Cisco SIP Stack
StatusCode604Ins
Represents the total number of 604 Does Not Exist

Anywhere response messages received by the SIP
Cisco SIP Stack
StatusCode604Outs
Represents the total number of 604 Does Not Exist

Anywhere response messages sent by the SIP device,
Cisco SIP Stack
StatusCode606Ins

Cisco SIP Stack
StatusCode606Outs

retransmissions.
Cisco SIP Stack
SubscribeIns
Represents the total number of SUBSCRIBE requests

Cisco SIP Stack
SubscribeOuts
Represents the total number of SUBSCRIBE requests

sent by the SIP device, including retransmissions.
Cisco SIP Stack
SuccessClassIns

This class of responses provides information about the
successful completion of a SIP request.
Cisco SIP Stack
SuccessClassOuts

class of responses provides information about the
successful completion of a SIP request.
Cisco SIP Stack
SummaryRequestsIn
Represents the total number of SIP request messages

Cisco SIP Stack
SummaryRequestsOut
Represents the total number of SIP request messages

sent out (originated and relayed) by the device. Where a
particular message is sent more than once, for example
as a retransmission or as a result forking, each
transmission is counted separately.
Cisco SIP Stack
SummaryResponsesIn
Represents the total number of SIP response messages

Cisco SIP Stack
SummaryResponsesOut
Represents the total number of SIP response messages

sent (originated and relayed) by the SIP device, including
retransmissions.
Cisco SIP Stack
UpdateIns
Represents the total number of UPDATE requests

Cisco SIP Stack
UpdateOuts
Represents the total number of UPDATE requests sent

Cisco SIP
Station
ConfigMismatchesPersistent
Represents the number of times since the last restart of

the Cisco Unified Communications Manager service that
a SIP phone was persistently unable to register due to a
configuration version mismatch between the TFTP server
and Cisco Unified Communications Manager. This
counter increments each time Cisco Unified
Communications Manager cannot resolve this condition
automatically and manual intervention is required (such
as a configuration update or device reset).
Cisco SIP
Station
ConfigMismatchesTemporary
Represents the number of times since the last restart of

the Cisco Unified Communications Manager service that
a SIP phone was temporarily unable to register due to a
configuration version mismatch between the TFTP server
and Cisco Unified Communications Manager. This
counter increments each time Cisco Unified
Communications Manager is able to resolve this
condition automatically.
Cisco SIP
Station
ConfigMismatchesTracking
Represents the number of phones that are currently

being monitored for configuration mismatches. It is
incremented each time a new config mismatch is
detected from a phone. It is decremented each time a
phone sends 4 successful register refresh messages in a
row.
Cisco SIP
Station
ConnectionsDedicated
Represents the number of non-shared TCP/TLS

connections in use for SIP devices.
Cisco SIP
Station
ConnectionsShared
Represents the number of shared TCP/TLS connections

in use for SIP devices.
Cisco SIP
Station
DBTimeouts
Represents the number of new registrations that failed

because of a timeout when attempting to retrieve the
device configuration from the database.
Cisco SIP
Station
DeviceEntries
Represents the total number of SIP endpoints that have

registered, requested a fallback token, and/or sent a
Transport Layer Security (TLS) certificate to Cisco
Communications Manager. This counter increments once
for every SIP device that performs one or more of the
preceding actions and decrements once for each device
that unregisters.
Cisco SIP
Station
DevicesByContactSocket
Represents the number of SIP devices that are known by

their contact sockets. The contact socket is the
'user@ip:port' string from the Contact socket in the
REGISTER message.
Cisco SIP
Station
DevicesByName
Represents the number of SIP devices that are known by

their device name. The device name is usually based on
the MAC address (e.g. SEPmac) or an arbitrary string.
These are the identifiers configured on the Device
Configuration web page.
Cisco SIP
Station
DeviceTypeAssociated
Represents the number of SIP statically allocated

devices. This includes Remote Destinations.
Cisco SIP
Station
DeviceTypeDualMode
Represents the number of SIP DualMode devices.
Cisco SIP
Station
NewRegAccepted
Represents the total number of new REGISTRATION

requests that have been removed from the
NewRegistration queue and processed since the last
Cisco Communications Manager restart.
Cisco SIP
Station
NewRegQueueSize
Represents the number of REGISTRATION requests

currently on the NewRegistration queue.
REGISTRATION requests received from devices that are
not currently registered are placed on this queue before
being processed.
Cisco SIP
Station
NewRegRejected
Represents the total number of new REGISTRATION

requests that have been rejected with a 486 Busy Here
response and not placed on the NewRegistration queue
since the last Cisco Communications Manager restart.
REGISTRATION requests are rejected if the
NewRegistration queue exceeds a programmed size.
Cisco SIP
Station
StationErrors
Represents the total number of errors encountered while

processing SIP station requests. These errors
correspond to LVL_ERROR traces in the SDI log files.
Cisco SIP
Station
StationErrorsMsgRouting
Represents the total number of errors encountered while

routing an incoming SIP message. This counter will
increment each time Cisco Communications Manager
receives a SIP message from a device that is not
registered.
Cisco SIP
Station
TokensAccepted
Represents the total number of token requests that have

been granted since the last Cisco Communications
Manager restart. Cisco Communications Manager grants
tokens as long as the number of outstanding tokens are
below the number specified in the Cisco Communications
Manager service parameter Maximum Phone Fallback
Queue Depth.
Cisco SIP
Station
TokensOutstanding
Represents the number of devices which have been

granted a token but have not yet registered. Devices
falling back to a higher priority Cisco Communications
Manager must be granted a token before registering.
Tokens protect Cisco Communications Manager from
being overloaded with registration requests when it
comes back online after a failover situation.
Cisco SIP
Station
TokensRejected
Represents the total number of token requests that have

been rejected since the last Cisco Communications
Manager restart. CCM will reject token request if the
number of outstanding tokens is greater than the number
specified in the Cisco Communications Manager service
parameter Maximum Phone Fallback Queue Depth.
Cisco SW
Conference
Bridge Device
(CFB_2)\AllocatedResourceCannotOpenPort

allocated SW Conference bridge device failed to open a
port for media transmission.
Cisco SW
Conference
Bridge Device
(CFB_2)\OutOfResources

made to allocate a conference resource from this SW
Conference device and failed, for example, because all
resources were already in use.
Cisco SW
Conference
Bridge Device
(CFB_2)\ResourceActive
Represents the number of resources that are currently in

use (active) for this SW Conference device. One
resource is equal to one stream.
Cisco SW
Conference
Bridge Device
(CFB_2)\ResourceAvailable
Represents the total number of resources that are not

active and are still available to be used at the current
time for this SW Conference device. One resource is
equal to one stream.
Cisco SW
Conference
Bridge Device
(CFB_2)\ResourceTotal

provided by this SW Conference device. One resource is
equal to one stream. This counter is equal to the sum of
the counters ResourceAvailable and ResourceActive.
Cisco SW
Conference
Bridge Device
(CFB_2)\SWConferenceActive
Represents the number of software-based conferences

that are currently active (in use) on this SW Conference
bridge device.
Cisco SW
Conference
Bridge Device
(CFB_2)\SWConferenceCompleted
Represents the total number of conferences that have

been allocated and released on this SW Conference
device. A conference is started when the first call is
connected to the bridge. The conference is completed
when the last call disconnects from the bridge.
Cisco TFTP
BuildAbortCount
Represents the number of times Build was aborted due

to Incoming build ALL request. This counter is updated
every time building of device/unit/softkey/dialrule is
aborted due to Group Level change notifications.
Cisco TFTP
BuildCount
Represents the number of times since the TFTP service

started that the TFTP server has built all the configuration
files in response to a database change notification that
affects all devices or a start of the TFTP service. This
counter increments by one every time the TFTP server
performs a new build of all the configuration files.
Cisco TFTP
BuildDeviceCount
Represents the number of devices processed in the last

build of all the configuration files. This counter is also
updated while processing device change notifications.
The counter increments when a new device is added and
decrements when an existing device is deleted.
Cisco TFTP
BuildDialruleCount
Represents the number of Dialrules processed in the last

updated while processing Dialrule change notifications.
The counter increments when a new Dialrule is added
and decrements when an existing Dialrule is deleted.
Cisco TFTP
BuildDuration
Represents the length of time in seconds that the last

build of all the configuration files took.
Cisco TFTP
BuildFeaturePolicyCount
Represents the number of Feature Control Policy files

processed in the last build of all the configuration files.
This counter is also updated while processing
FeatureControlPolicy change notifications. The counter
increments when a new Feature Control Policy is added
and decrements when an existing Feature Control Policy
is deleted.
Cisco TFTP
BuildSignCount
Represents the number of security-enabled phone

devices for which the configuration file was digitally
signed with the Communications Manager server key in
the last build of all the configuration files. This counter is
also updated while processing security-enabled phone
device change notifications.
Cisco TFTP
BuildSoftkeyCount
Represents the number of Softkeys processed in the last

updated while processing Softkey change notifications.
The counter increments when a new Softkey is added
and decrements when an existing Softkey is deleted.
Cisco TFTP
BuildUnitCount
Represents the number of gateways processed in the

last build of all the configuration files. This counter is also
updated while processing unit change notifications. The
counter increments when a new gateway is added and
decrements when an existing gateway is deleted.
Cisco TFTP
ChangeNotifications
Represents the total number of all the Communications

Manager database change notifications received by the
TFTP server. Each time a device configuration is updated
in Cisco Communications Manager Administration, the
TFTP server is sent a database change notification to
rebuild the XML file for the updated device.
Cisco TFTP
DeviceChangeNotifications
Represents the number of times the TFTP server has

received database change notification to create, update
or delete configuration files for devices.
Cisco TFTP
DialruleChangeNotifications

or delete configuration files for Dialrules.
Cisco TFTP
EncryptCount
Represents the number of config files that were

encrypted. This counter is updated each time a config file
is successfully encrypted.
Cisco TFTP
FeaturePolicyChangeNotifications

or delete configuration files for Feature Control Policies.
Cisco TFTP
GKFoundCount
Represents the number of GK files that were found in the

cache. This counter is updated each time a GK file is
found in the cache.
Cisco TFTP
GKNotFoundCount
Represents the number of GK files that were not found in

the cache. This counter is updated each time a request to
get a GK file results in the cache not finding it.
Cisco TFTP
HeartBeat
Represents the heartbeat of the TFTP server. This is an

incremental count that indicates that the TFTP server is
alive and running. If the count does not increment, then
the TFTP server is down (dead).
Cisco TFTP
HttpConnectRequests
Represents the number of current HTTP Connect

requests to GET the file request.
Cisco TFTP
HttpRequests
Represents the total number of file requests (such as

requests for XML configuration files, phone firmware files,
audio files, etc.) handled by the HTTP server. This
counter represents the sum total of the following counters
since the HTTP service started: RequestsProcessed,
RequestsNotFound, RequestsOverflow,
RequestsAborted, RequestsInProgress.
Cisco TFTP
HttpRequestsAborted
Represents the total number of HTTP requests that were

canceled (aborted) unexpectedly by the HTTP server.
Requests could be aborted if the requesting device
cannot be reached (for instance, the device lost power)
or if the file transfer was interrupted due to network
connectivity problems.
Cisco TFTP
HttpRequestsNotFound
Represents the total number of HTTP requests where the

requested file was not found. When the HTTP server
does not find the requested file, an error message is sent
to the requesting device.
Cisco TFTP
HttpRequestsOverflow
Represents the total number of HTTP requests that were

rejected because the maximum number of allowable
client connections was exceeded, because requests
arrived while the TFTP server was building the
configuration files, or because of some other resource
limitation. The maximum number of allowable
connections is set in the Cisco TFTP advanced service
parameter, Maximum Serving Count.
Cisco TFTP
HttpRequestsProcessed
Represents the total number of HTTP requests

successfully processed by the HTTP server.
Cisco TFTP
HttpServedFromDisk
Represents the number of requests served from the files

on disk, while serving files that are not cached in memory
by the HTTP server.
Cisco TFTP
LDFoundCount
Represents the number of LD files that were found in the

cache. This counter is updated each time a LD file is
found in the cache.
Cisco TFTP
LDNotFoundCount
Represents the number of LD files that were not found in

get an LD file results in the cache not finding it.
Cisco TFTP
MaxServingCount
Represents the maximum number of client connections

that can be served files simultaneously by the TFTP
server. This value is set in the Cisco TFTP advanced
service parameter, Maximum Serving Count.
Cisco TFTP
Requests
Represents the total number of file requests (such as

requests for XML configuration files, phone firmware files,
audio files, etc.) handled by the TFTP server. This
counter represents the sum total of the following counters
since the TFTP service started: RequestsProcessed,
RequestsNotFound, RequestsOverflow,
RequestsAborted, RequestsInProgress.
Cisco TFTP
RequestsAborted
Represents the total number of TFTP requests that were

canceled (aborted) unexpectedly by the TFTP server.
Requests could be aborted if the requesting device
cannot be reached (for instance, the device lost power)
or if the file transfer was interrupted due to network
connectivity problems.
Cisco TFTP
RequestsInProgress
represents the number of file requests currently being

processed by the TFTP server. This counter increments
for each new file request and decremented for each file
request completed. This counter gives you an indication
of the current load of the TFTP server.
Cisco TFTP
RequestsInProgress
Represents the number of file requests currently being

processed by the TFTP server. This counter increments
for each new file request and decremented for each file
request completed. This counter gives you an indication
of the current load of the TFTP server.
Cisco TFTP
RequestsNotFound
Represents the total number of TFTP requests where the

requested file was not found. When the TFTP server
does not find the requested file, an error message is sent
to the requesting device. In a cluster that is configured as
secure, it is usually an indicator of an error condition if
this counter increments. However, when the cluster is
configured as non-secure it is normal for the CTL file to
be absent (not found), resulting in an error message
being sent to the requesting device and a corresponding
increment in this counter. For non-secure clusters, this
occurrence is normal and does not represent an error
condition.
Cisco TFTP
RequestsOverflow
Represents the total number of TFTP requests that were

rejected because the maximum number of allowable
client connections was exceeded, because requests
arrived while the TFTP server was building the
configuration files, or because of some other resource
limitation. The maximum number of allowable
connections is set in the Cisco TFTP advanced service
parameter, Maximum Serving Count.
Cisco TFTP
RequestsProcessed
Represents the total number of TFTP requests

successfully processed by the TFTP server.
Cisco TFTP
SegmentsAcknowledged
Represents the total number of data segments

acknowledged by the client devices. Files are sent to the
requesting device in data segments of 512 bytes and for
each 512 byte segment, the device sends the TFTP
server an acknowledgment message. Each additional
data segment is sent upon receipt of the
acknowledgement for the previous data segment until the
complete file has been successfully transmitted to the
requesting device.
Cisco TFTP
SegmentsFromDisk
Represents the number of data segments read from the

files on disk, while serving files that are not cached in
memory by the TFTP server.
Cisco TFTP
SegmentsSent
Represents the total number of data segments sent by

the TFTP server. Files are sent to the requesting device
in data segments of 512 bytes.
Cisco TFTP
SEPFoundCount
Represents the number of SEP files that were found in

the cache. This counter is updated each time a SEP file
is found in the cache.
Cisco TFTP
SEPNotFoundCount
Represents the number of SEP files that were not found

in the cache. This counter is updated each time a request
to get a SEP file results in the cache not finding it.
Cisco TFTP
SIPFoundCount
Represents the number of SIP files that were found in the

cache. This counter is updated each time a SIP file is
found in the cache.
Cisco TFTP
SIPNotFoundCount
Represents the number of SIP files that were not found in

get a SIP file results in the cache not finding it.
Cisco TFTP
SoftkeyChangeNotifications

or delete configuration files for Softkeys.
Cisco TFTP
UnitChangeNotifications

or delete gateway-related configuration files.
Cisco Tomcat
Connector
(http-8080)\Errors
Represents the total number of HTTP errors (for

example, 401 Unauthorized ) encountered by the
Connector. A Tomcat Connector represents an endpoint
that receives requests and sends responses. The
Connector handles HTTP/HTTPS requests and sends
HTTP/HTTPS responses that occur when Cisco
Communications Manager-related web pages are
accessed. The instance name for each Tomcat
Connector is based on the Secure Sockets Layer (SSL)
status of the URLs for the web application. For example,
https://IP Address:8443 for SSL or http://IP Address:8080
for non-SSL.
Cisco Tomcat
Connector
(http-8080)\MBytesReceived
Represents the amount of data that the Connector has

received. A Tomcat Connector represents an endpoint
that receives requests and sends responses. The
Connector handles HTTP/HTTPS requests and sends
HTTP/HTTPS responses that occur when Cisco
for non-SSL.
Cisco Tomcat
Connector
(http-8080)\MBytesSent
Represents the amount of data that the Connector has

sent. A Tomcat Connector represents an endpoint that
receives requests and sends responses. The Connector
handles HTTP/HTTPS requests and sends HTTP/HTTPS
responses that occur when Cisco Communications
Manager-related web pages are accessed. The instance
name for each Tomcat Connector is based on the Secure
Sockets Layer (SSL) status of the URLs for the web
application. For example, https://IP Address:8443 for SSL
or http://IP Address:8080 for non-SSL.
Cisco Tomcat
Connector
(http-8080)\Requests
Represents the total number of requests that have been

handled by the Connector. A Tomcat Connector
represents an endpoint that receives requests and sends
responses. The Connector handles HTTP/HTTPS
requests and sends HTTP/HTTPS responses that occur
when Cisco Communications Manager-related web
pages are accessed. The instance name for each
Tomcat Connector is based on the Secure Sockets Layer
(SSL) status of the URLs for the web application. For
example, https://IP Address:8443 for SSL or http://IP
Address:8080 for non-SSL.
Cisco Tomcat
Connector
(http-8080)\ThreadsBusy
Represents the Connector's current number of

busy/in-use request processing threads. A Tomcat
Connector represents an endpoint that receives requests
and sends responses. The Connector handles
HTTP/HTTPS requests and sends HTTP/HTTPS
responses that occur when Cisco Communications
Manager-related web pages are accessed. The instance
name for each Tomcat Connector is based on the Secure
Sockets Layer (SSL) status of the URLs for the web
application. For example, https://IP Address:8443 for SSL
or http://IP Address:8080 for non-SSL.
Cisco Tomcat
Connector
(http-8080)\ThreadsMax
Represents the Connector's max number of request

processing threads. Each incoming request on a Cisco
Communications Manager-related web page requires a
thread for the duration of that request. If more
simultaneous requests are received than the available
request processing threads can handle, additional
threads are created up to the maximum shown in this
counter. If still more simultaneous requests occur, they
accumulate in the server socket created by the
Connector, up to a fixed maximum. Any further
simultaneous requests receive Connection Refused
errors until resources are freed. A Tomcat Connector
represents an endpoint that receives requests and sends
responses. The Connector handles HTTP/HTTPS
requests and sends HTTP/HTTPS responses that occur
when Cisco Communications Manager-related web
pages are accessed. The instance name for each
Tomcat Connector is based on the Secure Socket Layer
(SSL) status of the URLs for the web application. For
example, https://IP Address:8443 for SSL or http://IP
Address:8080 for non-SSL.
Cisco Tomcat
Connector
(http-8080)\ThreadsTotal
Represents the Connector's current total number of

request processing threads, including available and
in-use threads. A Tomcat Connector represents an
endpoint that receives requests and sends responses.
The Connector handles HTTP/HTTPS requests and
sends HTTP/HTTPS responses that occur when Cisco
for non-SSL.
Cisco Tomcat
JVM
KBytesMemoryFree
KBytes
Represents the amount of free dynamic memory block

(heap memory) in the Tomcat Java Virtual Machine. The
dynamic memory block stores all objects created by
Tomcat and its web applications such as Cisco
Communications Manager Administration and Cisco
Communications Manager Serviceability. When the
amount of free dynamic memory is low, more memory is
automatically allocated and total memory size
(represented by the KbytesMemoryTotal counter)
increases but only up to the maximum (represented by
the KbytesMemoryMax counter). You can determine the
amount of memory in use by subtracting
KBytesMemoryFree from KbytesMemoryTotal.
Cisco Tomcat
JVM
KBytesMemoryMax
KBytes
Represents the Tomcat Java Virtual Machine maximum

dynamic memory block size. The dynamic memory block
stores all objects created by Tomcat and its web
applications such as Cisco Communications Manager
Administration and Cisco Communications Manager
Serviceability.
Cisco Tomcat
JVM
KBytesMemoryTotal
KBytes
Represents the Tomcat Java Virtual Machine current

total dynamic memory block size including free and
in-use memory. The dynamic memory block stores all
objects created by Tomcat and its web applications such
as Cisco Communications Manager Administration and
Cisco Communications Manager Serviceability.
Cisco Tomcat
Web Application
(_root)\Errors
Represents the total number of HTTP errors (for

example, 401 Unauthorized) encountered by a Cisco
Communications Manager-related web application. The
instance name for each Tomcat Web Application is
based on the URLs for the web application. For example,
Cisco Communications Manager Administration (https://I
P Address:8443/ccmadmin) is identified by ccmadmin,
Cisco Communications Manager Serviceability is
identified by ccmservice, Cisco Communications
Manager User Options is identified by ccmuser, and
URLs that do not have an extension, such as https://IP
Address:8443 or http://IP Address:8080), are identified by
_root.
Cisco Tomcat
Web Application
(_root)\Requests
Represents the total number of requests handled by the

web application. Each time a web application is
accessed, its Requests counter will increment
accordingly. The instance name for each Tomcat Web
Application is based on the URLs for the web application.
For example, Cisco Communications Manager
Administration (https://IP Address:8443/ccmadmin) is
identified by ccmadmin, Cisco Communications Manager
Serviceability is identified by ccmservice, Cisco
Communications Manager User Options is identified by
ccmuser, and URLs that do not have an extension, such
as https://IP Address:8443 or http://IP Address:8080), are
identified by _root.
Cisco Tomcat
Web Application
(_root)\SessionsActive
Represents the number of currently active (in use)

sessions the web application currently has. The instance
name for each Tomcat Web Application that displays is
based on the URLs for the web application. For example,
Cisco Communications Manager Administration
(https://IP Address:8443/ccmadmin) is identified by
ccmadmin, Cisco Communications Manager
Serviceability is identified by ccmservice, Cisco
Communications Manager User Options is identified by
ccmuser, and URLs that do not have an extension, such
as https://IP Address:8443 or http://IP Address:8080), are
identified by _root.
Cisco WebDialer
CallsCompleted
Represents the number of Make Call and End Call

requests that have been successfully completed by the
WebDialer servlet.
Cisco WebDialer
CallsFailed

requests that were unsuccessful.
Cisco WebDialer
RedirectorSessionsHandled
Represents the total number of HTTP sessions handled

by the Redirector servlet since the last service startup.
Cisco WebDialer
RedirectorSessionsInProgress
Represents the number of HTTP sessions currently being

serviced by the Redirector servlet.
Cisco WebDialer
RequestsCompleted

requests that have been successfully completed by the
WebDialer servlet.
Cisco WebDialer
RequestsFailed

requests that were unsuccessful.
Cisco WebDialer
SessionsHandled
Represents the total number of CTI sessions handled by

the WebDialer servlet since the last service startup.
Cisco WebDialer
SessionsInProgress
Represents the number of CTI sessions currently being

serviced by the WebDialer servlet.
DB Change
Notification
Client
MessagesProcessed
Represents the number of database change notifications

that have been processed. This counter refreshes every
15 seconds by default.
DB Change
Notification
Client
MessagesProcessing
Represents the number of change notification messages

in the change notification queue for this client that are
currently being processed or are waiting to be processed.
This counter refreshes every 15 seconds by default.
DB Change
Notification
Client
QueueHeadPointer
Represents the head pointer of the change notification

queue. The head pointer is the starting point in the
change notification queue. To determine the number of
notifications in the queue, subtract the head pointer value
from the tail pointer value. This counter refreshes every
DB Change
Notification
Client
QueueMax
Represents the largest number of change notification

messages to be processed for this client. This counter is
cumulative since the last restart of the Cisco Database
Layer Monitor service.
DB Change
Notification
Client
QueueTailPointer
Represents the tail pointer of change notification queue.

The tail pointer represents the ending point in the change
notification queue. To determine the number of
notifications in the queue, subtract the head pointer value
from the tail pointer value. This counter refreshes every
DB Change
Notification
Client
TablesSubscribed
Represents the number of tables to which this client has

subscribed.
DB Change
Notification
Server
Clients
Represents the total number of change notification

clients.
DB Change
Notification
Server
CNProcessed
Represents the total number of change notification

messages processed by server since reboot.
DB Change
Notification
Server
QueueDelay
Provides the number of seconds that the change

notification process has messages to process, but is not
processing them. This condition is true if either Change
Notification Requests Queued in Database
(QueuedRequestsInDB) and Change Notification
Requests Queued in Memory
(QueuedRequestsInMemory) are non-zero. Or, the Latest
Change Notification Messages Processed count must not
be changing. This condition is checked every 15
seconds.
DB Change
Notification
Server
QueuedRequestsInDB
Represents the number of records from DBCNQueue

table.
DB Change
Notification
Server
QueuedRequestsInMemory
Represents the number of change notification requests

queued in memory.
DB Change
Notification
Subscription
SubscribedTable
Represents the table(s) for which the service or servlet

will receive change notifications. This information is
provided for informational purposes only; no counter will
increment.
DB Local DSN
(DSN=ccm;: NodeName =
cisco-ucm85.HCLT.CORP.HCL.IN)\CcmDbSpace_Used
Represents the amount of ccm dbspace consumed.
DB Local DSN
cisco-ucm85.HCLT.CORP.HCL.IN)\CcmtempDbSpace_Used
Represents the amount of ccmtemp dbspace consumed.
DB Local DSN
cisco-ucm85.HCLT.CORP.HCL.IN)\CNDbSpace_Used
Represents the percentage of CN dbspace consumed.
DB Local DSN
cisco-ucm85.HCLT.CORP.HCL.IN)\LocalDSN
Displays the data source name (DSN) that is being

referenced from the local machine.
DB Local DSN
cisco-ucm85.HCLT.CORP.HCL.IN)\RootDbSpace_Used
Represents the amount of root dbspace consumed.
DB Local DSN
cisco-ucm85.HCLT.CORP.HCL.IN)\SharedMemory_Free
Represents total shared memory that is free.
DB Local DSN
cisco-ucm85.HCLT.CORP.HCL.IN)\SharedMemory_Used
Represents total shared memory that is used.
DB User Host
Information
Counters
(ccm8_6_2_22900_9:database:cisco-ucm85)\DB:User:Host
Instances
Displays the number of connections that is present for

each instance of DB:User:Host.
Enterprise
Replication
DBSpace
Monitors
cisco-ucm85.HCLT.CORP.HCL.IN)\ERDbSpace_Used
Represents the amount of enterprise replication DbSpace

consumed.
Enterprise
Replication
DBSpace
Monitors
cisco-ucm85.HCLT.CORP.HCL.IN)\ERSBDbSpace_Used
Represents the amount of ERDbSpace consumed.
External Call
Control
ConnectionsActiveToPDPServer
Specifies the total number of connections that Cisco

Unified Communications Manager has established
(currently active) with PDP servers.
External Call
Control
ConnectionsLostToPDPServer
Specifies the total number of times that active

connections between Cisco Unified Communications
Manager and the PDP servers were disconnected. This
is a cumulative count since the last restart of the Cisco
External Call
Control
PDPServersInService
Defines the total number of in-service (active) PDP

servers.
External Call
Control
PDPServersOutOfService
Defines the total number of times that PDP servers have

transitioned from in-service to out-of-service. This is a
cumulative count of out-of-service PDP servers since the
last restart of the Cisco Communications Manager
service.
External Call
Control
PDPServersTotal
Defines the total number of PDP servers in all External

Call Control Profiles configured in Cisco Unified CM
Administration. This counter increments when a new
PDP server is added and decrements when a PDP
server is removed.
IME Client
CallsAccepted
Indicates the number of IME calls that have been

successfully received by Unified CM and answered by
the called party, resulting in an IP call.
IME Client
CallsAttempted
Indicates the number of all calls initiated by Unified CM

through Cisco Intercompany Media Engine (IME),
including calls that are accepted, busy, unanswered, and
failed calls. This counter increments each time a call
through IME is initiated.
IME Client
CallsReceived
Indicates the number of calls received by Unified CM

through IME, including calls that are accepted
(connected), busy, unanswered and failed calls. This
counter increments each time a call is received by
Unified CM through IME.
IME Client
CallsSetup
Indicates the number of IME calls that have been

successfully placed by Unified CM and answered by the
remote party, resulting in an IP call.
IME Client
DomainsUnique
Indicates the number of unique domain names of peer

enterprises discovered by IME client. It is an indicator of
overall usage of the system.
IME Client
FallbackCallsFailed
Indicates the total number of unsuccessful fallback

attempts.
IME Client
FallbackCallsSuccessful
Indicates the total number of IME calls that have fallen

back to the PSTN mid-call due to a quality problem,
including calls initiated and calls received by this Unified
CM.
IME Client
IMESetupsFailed
Indicates the total number of call attempts for which an

IME route was available but which the call was set up
through the PSTN due to a failure to connect to the target
over the IP network.
IME Client
RoutesLearned
Indicates the total number of distinct phone numbers that

have been learned by Unified CM and are present as
routes in Unified CM Administration. If this number grows
too large, it may exceed the per-cluster limit and require
additional clusters to scale to the demand.
IME Client
RoutesPublished
Indicates the total number of DIDs published successfully

into the IME distributed cache across all IME services. It
is a dynamic measurement, and as such, gives you an
indication of your own provisioned usage in addition to a
sense of how successful the system has been in storing
the DIDs into the network.
IME Client
RoutesRejected
Indicates the number of learned routes which were

rejected because the number or domain were configured
as Untrusted. This provides an indication of the number
of missed opportunities: cases where a VoIP call could
happen in the future, but will not due to the blocked
validation.
IME Client
VCRUploadRequests
Indicates the number of voice call record (VCR) upload

requests that have been sent by the Unified CM to the
IME server to be stored in the IME distributed cache. This
is a cumulative count since the last restart of the Cisco
IP and IP6
Frag Creates
Represents the number of IP datagrams fragments that

have been generated as a result of fragmentation at this
entity.
IP and IP6
Frag Fails
Represents the number of IP datagrams that have been

discarded because they needed to be fragmented at this
entity but could not, for example because their Do not
Fragment flag was set.
IP and IP6
Frag OKs

successfully fragmented at this entity.
IP and IP6
In Delivers
Represents the total number of input datagrams

successfully delivered to IP user-protocols (including
Internet Control Message Protocol [ICMP]).
IP and IP6
In Discards
Represents the number of input IP datagrams for which

no problems were encountered to prevent their continued
processing, but which were discarded (for example, for
lack of buffer space). This counter does not include any
datagrams that were discarded while awaiting
reassembly.
IP and IP6
In HdrErrors
Represents the number of input datagrams discarded

due to errors in their IP header, including bad
checksums, version number mismatch, other format
errors, time-to-live exceeded, errors discovered in
processing their IP options, etc.
IP and IP6
In Receives
Represents the number of input datagrams received from

all network interfaces, including those received with
errors.
IP and IP6
In UnknownProtos
Represents the number of locally-addressed datagrams

that were received successfully but discarded because of
unknown or unsupported protocols (protos).
IP and IP6
InOut Requests
Represents the total number of IP datagrams received

and the number of IP datagrams sent.
IP and IP6
Out Discards
Represents the number of output IP datagrams that was

not transmitted and was discarded. One reason may be a
lack of buffer space.
IP and IP6
Out Requests
Represents the total number of IP datagrams which local

IP user-protocols (including Internet Control Message
Protocol [ICMP]) supply to IP in requests transmission.
This counter does not include any datagrams counted in
ForwDatagrams.
IP and IP6
Reasm Fails
Represents the number of failures detected by the IP

reassembly algorithm (for various reasons, for example
timed out, errors, and so on). This is not necessarily a
count of discarded IP fragments since some algorithms,
notably the algorithm in RFC 815, can lose track of the
number of fragments by combining them as they are
received.
IP and IP6
Reasm OKs

successfully reassembled.
IP and IP6
Reasm Reqds
Represents the number of IP fragments received which

needed to be reassembled at this entity.
Memory
% Mem Used
Percent
Represents the percentage of system physical memory

utilization on the system. The value of the % Mem Used
counter is equal to the value derived from either of the
following equations: (Total KBytes - Free KBytes Buffers KBytes - Cached KBytes + Shared KBytes) /
Total KBytes; OR: Used Mem KBytes / Total KBytes.
Memory
% Page Usage
Percent
Represents the percentage of active pages.
Memory
% VM Used
Percent
Represents the percentage of system virtual memory

utilization on the system. The value of the % VM Used
counter is equal to the value derived from either of the
following two equations: (Total KBytes - Free KBytes Buffers KBytes - Cached KBytes + Shared KBytes +
Used Swap KBytes ) / (Total KBytes + Total Swap
KBytes); OR: Used VM KBytes / Total VM KBytes.
Memory
Buffers KBytes
KBytes
Represents the capacity of buffers in the system in

kilobytes.
Memory
Cached KBytes
KBytes
Represents the amount of cached memory in kilobytes.
Memory
Free KBytes
KBytes
Represents the total amount of memory that is available

in the system in kilobytes.
Memory
Free Swap KBytes
KBytes
Represents the amount of free swap space, in kilobytes,

that is available in the system.
Memory
HighFree
Represents the amount of free memory in the high

region. Linux kernel splits the virtual memory address
space into memory regions. The high memory is memory
above certain physical address, and its amount depends
on the total memory and the type of kernel on the
system. For the Cisco Unified Communications Manager
system with 4GB memory, the high memory is roughly in
the address of 896M to 4096M.
Memory
HighTotal
Represents the total amount of memory in the high

region. Linux kernel splits the virtual memory address
space into memory regions. The high memory is memory
above certain physical address, and its amount depends
on the total memory and the type of kernel on the
system. For the Cisco Unified Communications Manager
system with 4GB memory, the high memory is roughly in
the address of 896M to 4096M.
Memory
Low Free
Represents the free low (non-paged) memory for kernel.
Memory
Low Total
Represents the total low (non-paged) memory for kernel.
Memory
Page Faults Per Sec
Represents the number of page faults (major + minor)

made by the system per second (post 2.5 kernels only).
This is not a count of page faults that generate I/O,
because some page faults can be resolved without I/O.
Memory
Page Major Faults Per Sec
Represents the number of major faults the system has

made per second, those which have required loading a
memory page from disk (post 2.5 kernels only).
Memory
Pages
Pages
Represents the number of pages that the system paged

in from the disk plus the number of pages that the system
paged out to the disk.
Memory
Pages Input
Pages

in from the disk.
Memory
Pages Input Per Sec
Pages
Represents the total number of kilobytes the system

paged in from disk per second.
Memory
Pages Output
Pages

out to the disk.
Memory
Pages Output Per Sec
Pages
Represents the total number of kilobytes the system

paged out to disk per second.
Memory
Shared KBytes
KBytes
Represents the amount of shared memory in the system

in kilobytes.
Memory
SlabCache
Represents all memory used by created slabcaches by

various kernel components, as a macroscopic counter
representing the sum of all the individual entries in the
proc's slabinfo.
Memory
SwapCached
Represents the amount of Swap used as cache memory.

Memory that once was swapped out, is swapped back in,
but is still in the swapfile.
Memory
Total KBytes
KBytes
Represents the total amount of memory in the system in

kilobytes.
Memory
Total Swap KBytes
KBytes
Represents the total amount of swap space, in kilobytes,

in the system.
Memory
Total VM KBytes
KBytes
Represents the total amount of system physical memory

and swap space that is in use, in kilobytes, in the system.
The value of the Total VM KBytes counter is equal to the
value derived from the following equation: Total KBytes +
Total Swap KBytes.
Memory
Used KBytes
KBytes
Represents the amount of system physical memory that

is in use, in kilobytes, in the system. The value of the
Used KBytes counter is equal to the value derived from
the following equation: Total KBytes - Free KBytes Buffers KBytes - Cached KBytes + Shared KBytes. The
Used KBytes value is different from the Linux term used
value shown in top or free command output. The used
value shown in Linux top or free command output is
equal to Total KBytes - Free KBytes, and it also includes
the sum of Buffer KBytes and Cached KBytes.
Memory
Used Swap KBytes
KBytes
Represents the amount of swap space, in kilobytes, that

is in use on the system.
Memory
Used VM KBytes
KBytes
Represents the system physical memory and the amount

of swap space that is in use, in kilobytes, in the system.
The value of the Used VM KBytes counter is equal to the
value derived from the following equation: Total KBytes Free KBytes - Buffers KBytes - Cached KBytes + Shared
KBytes + Used Swap KBytes; OR: Used Mem KBytes +
Used Swap KBytes.
Network
Interface
(eth0)\Rx Bytes
Represents the number of bytes, including framing

characters, that was received on the interface.
Network
Interface
(eth0)\Rx Dropped
Represents the number of inbound packets that was

chosen to be discarded even though no errors had been
detected. Discarding packets prevents the packet from
being delivered to a higher layer protocol, for example, to
free up buffer space.
Network
Interface
(eth0)\Rx Errors
Represents the number of inbound packets (for

packet-oriented interfaces) and the number of inbound
transmission units (for character-oriented or fixed-length
interfaces) that contained errors that prevented them
from being deliverable to a higher layer protocol.
Network
Interface
(eth0)\Rx Multicast
Represents the number of multicast packets that was

received on this interface.
Network
Interface
(eth0)\Rx Packets
Represents the number of packets that this sublayer

delivered to a higher sublayer. This does not include the
packets that were addressed to a multicast or broadcast
address at this sublayer.
Network
Interface
(eth0)\Total Bytes
Represents the total number of received (Rx) bytes and

transmitted (Tx) bytes.
Network
Interface
(eth0)\Total Packets
Represents the total number of received (Rx) packets

and transmitted (Tx) packets.
Number of
Replicates
Created and
State of
Replication
(ReplicateCount)\Number of Replicates Created
Represents the number of replicates created by Informix

for the DB tables. For every table there should be one
replicate. This counter displays information during
Replication Setup
Number of
Replicates
Created and
State of
Replication
(ReplicateCount)\Replicate_State
Displays the state of replication: Thus 0 = Initializing

ReplTask thread; 1 = Replication setup script fired from
this node; 2 = Replication is good, replication is setup
correctly and most of the tables in the database should
be in sync for all nodes of the cluster. Please run -- utils
dbreplication status -- to see if any tables are out of
sync.; 3 = Replication data transfer is bad in the cluster; 4
= Replication Setup didn't succeed. When the counter
shows a value of 3, it means replication is bad in the
cluster. It doesn't mean that replication is bad on that
particular node. It is advised that the user run utils
dbreplication status cli to find out where and what exactly
is broken.
Partition
(Active)\% CPU Time
Percent
Represents the percentage of CPU time that is dedicated

to handling IO requests that were issued to the disk.
Partition
(Active)\% Used
Percent
Represents the percentage of disk space that is in use on

this file system.
Partition
(Active)\Await Read Time
ms
Represents the average time, measured in milliseconds,

for read requests issued to the device to be served.
Partition
(Active)\Await Time
ms

for I/O requests issued to the device to be served. This
includes the time spent by the requests in queue and the
time spent servicing them.
Partition
(Active)\Await Write Time
ms

for write requests issued to the device to be served.
Partition
(Active)\Queue Length
Represents the average queue length for the requests

that were issued to the disk.
Partition
(Active)\Read Bytes Per Sec
Bytes per
second
Represents the amount of data that was read from the

disk, measured in bytes per second.
Partition
(Active)\Total Mbytes
Mbytes
Represents the amount of total disk space, in megabytes,

that is on this file system. The number in this counter
may differ from other total size values for disk space that
you may see on the system. That is because the value of
the Total Mbytes counter is the sum of Used Mbytes
performance counter and the Free value shown in the
CLI (show status) output. The Total Mbytes value is less
than this CLI output for Total which includes the minfree
percentage of reserved file system disk blocks. Keeping
a minfree reserved is one way to ensure a sufficient
amount of disk space for the file system to operate at
high efficiency.
Partition
(Active)\Used Mbytes
Mbytes
Represents the amount of disk space, in megabytes, that

is in use on this file system.
Partition
(Active)\Write Bytes Per Sec
Bytes per
second
Represents the amount of data that was written to the

disk, measured in bytes per second.
Process
(acpid)\% CPU Time
Percent
Expressed as a percentage of total CPU time, represents

the tasks share of the elapsed CPU time since the last
update.
Process
(acpid)\% Memory Usage
Percent
Represents the percentage of physical memory that a

task is currently using.
Process
(acpid)\Data Stack Size
Represents the stack size for task memory status.
Process
(acpid)\Nice
Represents the nice value of the task. A negative nice

value indicates that the process has a higher priority
while a positive nice value indicates that the process has
a lower priority. If the nice value equals zero, do not
adjust the priority when you are determining the
dispatchability of a task.
Process
(acpid)\Page Fault Count
Represents the number of major page faults that a task

encountered that required the data to be loaded into
memory.
Process
(acpid)\PID
Represents the task's unique process ID, which

periodically wraps, though never restarting at zero.
Process
(acpid)\Process Status
Process
(acpid)\Shared Memory Size
KBytes
Displays the amount of shared memory, in KB, that a

task is using. Other processes could potentially share the
same memory.
Process
(acpid)\STime
Jiffies
Displays the amount of system time (STime), measured

in jiffies, for which this process has been scheduled in
kernel mode. A jiffy corresponds to a unit of CPU time
and gets used as a base of measurement. One second is
equal to 100 jiffies.
Process
(acpid)\Thread Count
Displays the number of threads that are currently

grouped with the task. A negative value -1 indicates that
this counter is currently not available because thread
statistics (including all performance counters in the
Thread object as well as the Thread Count counter in the
Process object) have been turned off because the
system's total processes and threads have exceeded the
default threshold value.
Process
(acpid)\Total CPU Time Used
Jiffies
Displays the total CPU time, measured in jiffies that the

task has consumed in user mode and kernel mode since
the start of the task. One second is equal to 100 jiffies.
Process
(acpid)\UTime
Jiffies
Displays the amount of time, measured in jiffies, that the

task has been scheduled for in user mode. One second
is equal to 100 jiffies.
Process
(acpid)\VmData
KBytes
Displays the virtual memory usage of the heap for the

task in kilobytes (KB).
Process
(acpid)\VmRSS
KBytes
Displays the virtual memory (Vm) resident set size (RSS)

that is currently in physical memory in kilobytes (KB),
including Code, Data, and Stack.
Process
(acpid)\VmSize
KBytes
Displays the total amount of virtual memory, in KB, that

the task is using. It includes all code, data, shared
libraries, and pages that have been swapped out: Virtual
Image = swapped size + resident size.
Processor
(_Total)\% CPU Time
Percent
Indicates the processors share of the elapsed CPU time

excluding the idle time since last update, expressed as a
percentage of CPU time.
Processor
(_Total)\Idle Percentage
Percent
Displays the percentage of time that the CPU or CPUs

were idle and the system did not have an outstanding
disk I/O request.
Processor
(_Total)\IOwait Percentage
Percent
Displays the percentage of time that the CPU or CPUs

were idle, during which the system had an outstanding
disk I/O request.
Processor
(_Total)\Irq Percentage
Percent
Displays the percentage of time that the processor is

executing the interrupt request which is assigned to
devices for interrupt, or sending a signal to the computer
when it is finished processing.
Processor
(_Total)\Nice Percentage
Percent
Displays the percentage of CPU utilization that occurred

while executing at the user level with nice priority.
Processor
(_Total)\Softirq Percentage
Percent
Displays the percentage of time that the processor is

executing the softirq, which means that task switching is
deferred until later to achieve better performance.
Displays the task's process status: 0 - Running, 1 Sleeping, 2 - Uninterruptible disk sleep, 3 - Zombie, 4 Traced or stopped (on a signal), 5 - Paging, 6 Unknown.
Processor
(_Total)\System Percentage
Percent

while executing at the system level (kernel).
Processor
(_Total)\User Percentage
Percent

while executing at the user level (application).
Ramfs
(ccm_calllogs)\FilesTotal
Represents the total number of files in the ram-based

filesystem (ramfs).
Ramfs
(ccm_calllogs)\SpaceFree
Represents the amount of free data blocks in the

ram-based filesystem (ramfs). A block is a uniformly
sized unit of data storage for a filesystem. The block size
specifies the size that the filesystem will use to read and
write data; on the Cisco Unified Communications
Manager system, the block size is 4096 bytes.
Ramfs
(ccm_calllogs)\SpaceUsed
Represents the amount of used data blocks in the

ram-based filesystem (ramfs). A block is a uniformly
sized unit of data storage for a filesystem. The block size
specifies the size that the filesystem will use to read and
write data; on the Cisco Unified Communications
Manager system, the block size is 4096 bytes.
System
Allocated FDs
FDs
Represents the total number of allocated file descriptors.
System
Being Used FDs
FDs
Represents the number of file descriptors that is currently

in use in the system.
System
Freed FDs
FDs
Represents the total number of allocated file descriptors

on the system that is freed.
System
IOAwait
Milliseconds
Represents the average time, in milliseconds, for I/O

requests issued to all devices to be served. This includes
the time spent by the requests in queue and the time
spent servicing the requests.
System
IOCpuUtil
Percent
Represents the percentage of CPU time during which I/O

requests were issued to the device (bandwidth utilization
for the device) on this server.
System
IOKBytesReadPerSecond
Represents the total number of KBytes read per second

from all devices on this server.
System
IOKBytesWrittenPerSecond
Represents the total number of KBytes written per

second to all devices on this server.
System
IOPerSecond
Represents the total number of input/output operations

on all disk partitions per second on this server. If you
experience a system performance issue, use the
information in this counter to measure the impact of the
aggregate I/O operations on this server.
System
IOReadReqMergedPerSecond
Represents the total number of read requests merged

per second that were queued to all devices on this
server.
System
IOReadReqPerSecond
Represents the total number of read requests per second

that were issued to all devices on this server.
System
IOReqQueueSizeAvg
Represents the average queue length of the requests

System
IOSectorsReadPerSecond
Represents the total number of sectors read per second

from all devices on this server.
System
IOSectorsReqSizeAvg
Represents the average size in sectors of the requests

System
IOSectorsWrittenPerSecond
Represents the total number of sectors written per

second to all devices on this server.
System
IOServiceTime
Represents the average service time, in milliseconds, for

I/O requests that were issued to all devices on this
server.
System
IOWriteReqMergedPerSecond
Represents the total number of write requests merged

per second that were queued to all devices on this
server.
System
IOWriteReqPerSecond
Represents the total number of write requests per second

System
Max FDs
FDs
Represents the maximum number of file descriptors that

is allowed on the system.
System
Total CPU Time
Jiffies
Represents the total time, measured in jiffies, that the

system has been up and running. A jiffy corresponds to a
unit of CPU time and gets used as a base of
measurement. One second is equal to 100 jiffies.
System
Total Processes
Represents the total number of processes on the system.
System
Total Threads
Represents the total number of threads on the system.
TCP
Active Opens
Represents the number of times that TCP connections

have made a direct transition to the SYN-SENT state
from the CLOSED state.
TCP
Attempt Fails

have made a direct transition to the CLOSED stated from
either the SYN-RCVD state or the SYN-RCVD state, plus
the number of times TCP connections have made a
direct transition to the LISTEN state from the SYS-RCVD
state.
TCP
Curr Estab
Represents the number of TCP connections for which the

current state is either ESTABLISHED or CLOSE-WAIT.
TCP
Estab Resets
Represents the number of times that the TCP

connections have made a direct transition to the
CLOSED state from either the ESTABLISHED state or
the CLOSE-WAIT state.
TCP
In Segs
Represents the total number of segments received,

including those received in error. This count includes
segments received on currently established connections.
TCP
InOut Segs
Represents the total number of segments that were sent

and the total number of segments that were received.
TCP
Out Segs
Represents the total number of segments sent, including

those on current connections but excluding those
containing only retransmitted octects.
TCP
Passive Opens

have made a direct transition to the SYN-RCVD state
from the LISTEN state.
TCP
RetransSegs
Represents the total number of segments retransmitted,

that is, the number of TCP segments transmitted
containing one or more previously transmitted octets.
Thread
ccm_8782\% CPU Time
Percent
Displays the threads share of the elapsed CPU time

since the last update, expressed as percentage of total
CPU time.
Thread
ccm_8782\PID
Represents the threads leader process ID.

The following table describes the default settings for the cisco_ucm alert metrics.
Alert Metric
Error Threshold
MsgError
Error Severity
Description
Critical
Alarms to be issued when the connection to the host has failed.
MsgAgentError
Critical
Alarms to be issued when the host is not responding.
MsgAuthError
Critical
Alarms to be issued when the host authentication has failed.
MsgSessionError
Critical
Alarms to be issued when it is unable to create session.
SessionDataFailed
Critical
Alarms to be issued when it is unable to collect session data.
MsgServices
Critical
Alarms to be issued when the service is not created.
MsgWarning
Warning
Alarms to be issued when the monitor is below threshold.
MsgCritical
Critical
Alarms to be issued when the monitor is below threshold.
cisco_ucs (Cisco UCS Server Monitoring)

The Cisco UCS server monitoring (cisco_ucs) probe is a tool for managing the health and performance of your Unified Computing System (UCS).
The Cisco Unified Computing System is a next-generation data center platform that unites computing, networking, storage access, and
virtualization into a cohesive system designed to reduce total cost of ownership (TCO) and increase business agility.
The cisco_ucs probe is capable of monitoring the state of VMWare ESX Hypervisors and VMs installed on UCS blade servers.
This requires a secure communication between the VMWare vCenter and Cisco UCS Manager (using vCenter extension files).
The following component entities may be monitored:
Equipment
Chassis
Fabric Interconnects
Rack Mounts
Pools
UCS Service Profiles
More information:
cisco_ucs (Cisco UCS Server Monitoring) Release Notes
v2.3 cisco_ucs AC Configuration

This section describes the Admin Console configuration for the Cisco UCS Server Monitoring (cisco_ucs) probe.
Contents
Overview
Add New Profile
Set Log Level
Set the Number of Connection Retries
Add Monitors
Manually Selecting Monitors to be Measured
Edit Monitor Properties
Monitors of Type Value
Monitors of Type Event
Overview
After installing the probe, you must define what to monitor. At a high level there are three steps:
1. Connect to the UCS Manager environment.
2. Add monitors (checkpoints) either manually or with templates.
For adding monitors manually, see the descriptions in the section Adding Monitors. For applying monitors with templates, see the
descriptions on the separate page titled Apply Monitoring with Templates.
3. Configure the properties for the monitors, in which you define QoS data, and define alarms to be sent if specified thresholds are
breached.
Add New Profile

To connect to Cisco UCS, you add a profile.
Follow these steps:
1. In Admin Console, select the probe and click Configure.

The Probe Configuration window opens.
2. In the left navigation pane, select the cisco_ucs node and click the Options (...) icon > Add New Profile.
The Add New Profile dialog appears.
3. Enter the appropriate field information:
Hostname or IP Address
The hostname or IP address of the Cisco UCS system to monitor.
Note: You must follow the Java standard of enclosing the IPv6 address in square brackets. For example: The input string
[f0d0:0:0:0:0:0:0:10.0.00.0] works. But the input string f0d0:0:0:0:0:0:0:10.0.00.0 causes a stack trace error that includes the
exception: Caused by: java.lang.NumberFormatException: For input string: "f0d0:0:0:0:0:0:0:10.0.00.0".
Port
The port number for the UCS Manager REST API environment. Default is 443.
Username
A valid username to be used by the probe to log on to the UCS Manager environment.
Note: If Cisco UCS has been set up for LDAP Authentication, the login will require an LDAP label in addition to the user
name. The LDAP label is an arbitrary string used to identify the LDAP realm; it is configured in the Cisco UCS Manager by
the Cisco UCS administrator. You may need to contact your Cisco UCS administrator to get this LDAP label. When you set
up the login to work with LDAP authentication, use this convention: ucs-<LDAP Label>\<username>. The LDAP label is
case-sensitive and the username can be either lower or upper case.
Password
A valid password to be used by the probe to log on to the UCS Manager environment.
Active
Select this checkbox to activate or deactivate monitoring of the Resource.
Interval
The interval defines how often the probe checks the values of the monitors. This can be set in seconds, minutes or hours. We
recommend polling once every 10 minutes. The polling interval should not be smaller than the time required to collect the data.
Alarm Message
Select the alarm message to be sent if the Resource does not respond.
Actions - Verify Selection
Click Actions>Verify Selection buttons to verify the connection to the Resource.
4. After completing the fields and testing that the connection works, click OK to add the Resource.
The profile is added. The initial data collection/polling cycle starts. The resource hierarchy will populate once the polling cycle has
completed.
Set Log Level

The log level is a sliding scale. The scale ranges from zero (the probe logs only fatal errors) to five (the probe logs extremely detailed information
useful for debugging). The default log level is three. Log as little as possible during normal operation to minimize disk consumption.
Follow these steps:
2. In the details pane, go to Probe Setup.
3. Next to the Log level field, click the drop-down list.
4. Select the log level based on the level of details you want written to the log file for the probe.
5. Click Save and Reload to implement the new log level immediately.
Note: The probe allows you to change the log level without restarting the probe.
Set the Number of Connection Retries

By default, the probe tries to reconnect to the Cisco UCS Manager server three more times after failing to connect. This setting will work for most
customers, but you can adjust the number of connection retries if necessary. This may be necessary, for example, if your Cisco UCS Manager
has a relatively slow response time.
Follow these steps:
1. In Admin Console, select the probe and click Raw Configure.
2. Click the setup folder, then click Add Key.
3. Create a new key named max_retries with the value of the number of retries you want.
4. Click Apply.
A dialog opens and prompts you to restart the probe to configure the change.
Add Monitors
In Admin Console, there are two different ways to add monitors to Cisco UCS entities:
Manually select the monitors
To manually select and enable monitors, navigate to the target entity within the Resource. This lists its monitors in the right pane. Use the
available check-boxes to enable QoS monitoring for the selected metrics. To enable Alarm thresholding, you will need to launch the Edit
Monitor dialog.
Apply Monitoring with Templates
Templates let you define reusable sets of monitors to apply to various Cisco UCS monitored entities.
For more information, see the Apply Monitoring with Templates page.

All monitors are turned off by default. To turn on a monitor, you select it and then check Publish Data or Publish Alarms.
Follow these steps:
1. To select a monitor you want to be measured for a Resource, click the Resource node in the navigation pane, and navigate through the
Resources hierarchy.
2. Select a folder in the hierarchy to see the monitors for a resource, listed in the details pane.
3. To turn on a monitor, select it then check the boxes for Publish Data and/or Publish Alarms.
The monitor is turned on and monitor properties can be edited.
Note: You can also add monitors to be measured using templates (see v2.3 cisco_ucs AC Apply Monitoring with Templates).

Click a monitor to launch the monitors properties dialog. Enter the desired values for each of the monitor's properties.
Note: On the far left column of the details pane, the Monitor column describes either the type value of the monitor (such as Operability)
or describes it as an Event. Monitors of type value and type event have different properties.
The properties for monitors of type value are as follows:

QoS Name
This is the name of the monitor. The name will be inserted into this field when the monitor is retrieved from the UCS Manager
environment.
Description
This is a description of the monitor. This description will be inserted into this field when the monitor is retrieved from the UCS Manager
environment.
Metric Type
This is the metric type of the monitor. This type will be inserted into this field when the monitor is retrieved from the UCS Manager
environment.
Units
This field specifies the unit of the monitored value (for example, Mbytes). The field is read-only. This unit type will be inserted into this
field when the monitor is retrieved from the UCS Manager environment.
Value Definition
The current value. The most current value measured will be used.
The delta value (current - previous). The delta value calculated from the current and the previous measured sample will be used.
Delta per second. The delta value calculated from the samples measured within a second will be used.
The average value of the last and current sample: (current + previous) / 2.
The average value last ... The user specifies a count. The value is then averaged based on the last "count" items.
Publish Alarms
Selecting this option activates the alarming.
Initially the high threshold is set to the current value. Set this value to match your needs.
The low threshold is initially disabled. If you want to use it, you must select another operator than "disabled" from the list and configure it
to match your needs.
Operator
Example:
>= 90 means the monitor is in alarm condition if the measured value is equal to or above 90.
= 90 means the monitor is in alarm condition if the measured value is exactly 90.
Threshold
The alarm threshold value. An alarm message is sent when this threshold is violated.
Message ID
Select the alarm message to be issued if the specified threshold value is breached. These messages reside in the message pool.
You can monitor Cisco UCS Faults on each Resource. The event is forwarded as an alarm message and the suppression key is based on the
entity.
The properties for monitors of type event are:
Description
environment.
Metric Type
This is the metric type of the monitor. This type will be inserted into this field when the monitor is retrieved from the UCS Manager
environment.
High Operator
Select the high operator to be used when setting the alarm threshold for the event. This threshold refers to the events severity level in
Cisco UCS
High Threshold
The high alarm threshold value. An alarm message is sent when this threshold is violated.
High Message Name
Select the alarm message to be issued if the specified threshold value is breached. These messages reside in the message pool.
For more information about configuring thresholds for numeric monitors for the Cisco UCS Server monitoring (cisco_ucs) probe v2.3 or later, see
Configuring Alarm Thresholds. The link takes you to a page that describes how to configure centralized thresholds for select probes in CA Unified
v2.3 cisco_ucs AC Apply Monitoring with Templates

This article describes how to apply monitoring for the Cisco UCS Server Monitoring (cisco_ucs) probe with templates.
Note: This article describes how to apply monitoring with templates for a single probe. For more information about how to use policies
to configure templates for multiple probes, see Configure Probes with Policies in the CA Unified Infrastructure Management wiki.
Contents
Overview
Enable Bulk Configuration
Using Templates
Modify and Apply a Default Template
Create a Template
Create Template Filters
Add Rules to a Template Filter
Add Monitors to a Template Filter
Activate a Template
Using the Template Summary View
View Configuration in the All Monitors Table
Overview
Applying monitoring with templates saves time compared to manual monitor configuration and provides consistent monitoring across multiple
devices. At a high level, applying monitoring with templates is a two-step process in which you:
1. Enable bulk configuration
Before using the template editor, you first enable bulk configuration. This feature is disabled by default. It is also disabled if the probe has
been previously configured. Bulk configuration is possible only on a newly deployed probe (v2.3 or later) with no configuration.
2. Use the template editor
Once bulk configuration is enabled, you can copy and modify default template or create a new template to define unique monitoring
configurations for an individual device or groups of devices in your environment.
Important! Bulk configuration is only possible on a newly deployed v2.3 (or later) probe with no previous configuration. When you
enable bulk configuration, Infrastructure Manager is disabled and the Template Editor appears in the Admin Console GUI. Once you
enable bulk configuration, there is no supported process for going back to manual configuration. Be sure that you fully understand and
accept the consequences of enabling bulk configuration before enabling it.

Before using the template editor, first enable bulk configuration, which is disabled by default.
Follow these steps:
1. In Admin Console, select the probe.
2. Click Configure.
3. In the Probe Setup dialog, select Enable Bulk Configuration.
A dialog appears.
4. Click Reload.
Bulk configuration is enabled.
Using Templates
The template editor allows you to configure and apply monitoring templates. Templates reduce the time that you need for manual configuration
and provide consistent monitoring across the devices in your network. You can configure monitoring on many targets with a well-defined template.
You can also create multiple templates to define unique configurations for all devices and groups of target devices in your environment.
You can use the template editor to:
Copy and apply a default template
Copy, modify, and apply a default template
Create and apply a new template
You can further customize any template by configuring:
Precedence
precedence of one overrides the settings in the other template. If the precedence numbers are equal, then the templates are applied in
alphabetical order.
Note: The default template is applied with a precedence of 100. Be sure to set the precedence of your other templates to a
number lower than 100 so that the probe applies them at a higher priority than the default template. We recommend using incre
ments of 10. Using increments of 10, you can easily add custom templates and assign them a precedence that results in the
probe applying them in the order that you desire.
Filters
Rules
Monitors
Note: Wait for the component discovery process to complete before using templates. Some QoS metrics are only applied to
components on specific devices. Determine what device types exist in your environment before you activate a template.
The default templates contain settings for a recommended monitor configuration. These default configurations include high-value metrics for
supported interfaces and network devices. Using these default configurations helps you to quickly start collecting data for your environment. To
save these recommended monitor configurations, the default templates are read-only. Because a default template is read-only, you first copy and
rename it before you apply it.

Follow these steps:
2. Click cisco_ucs >Template Editor.
3. Select any default template.
BladeServer
Chassis
FabricInterconnects
Vblock UCS Dashboard
VM
6. (Optional) Determine if you want to modify the default precedence setting.
7. Check Active.
8. Click Submit.
9. Click Save.
The probe applies the template with the default settings.
You can modify a default template to meet your specific needs. When your modifications are complete, you activate the template. The probe then
applies the template to the appropriate devices and components.
Follow these steps:
2. Click cisco_ucs > Template Editor.
3. Select any default template.
BladeServer
Chassis
FabricInterconnects
VM
7. Click Submit.
8. Click Save.
9. (Optional) Create template filters.
10. (Optional) Add rules to a template filter.
11. (Optional) Add monitors to a template filter.
12. In the navigation tree, select the template that you created in steps 1-5.
The template set up dialog appears in the detail pane.
13. Check Active.
The probe applies the template with the modified settings.
Create a Template
You can create your own template.

Follow these steps:
2.
2. Click cisco_ucs > Template Editor.

3. Click Options (...) > Create Template.
Note: Do not activate the template if you want to configure template monitoring filters or rules. If you change the template state
to active, the probe immediately applies the configuration.
6. Click Submit.
7. Click Save.
The system creates a template that you can configure and activate.
For more information, see Create Template Filters, Add Rules to a Template Filter, Add Monitors to a Template Filter, and Activate a
Template.
Follow these steps:
1. In the template editor, select the template that you created.
2. Choose any node that has the Options (...) icon next to it.
3. Enter a descriptive name for the filter and a precedence.
4. Repeat the previous steps for every template that requires filters.
5. Click Submit.
The template filter is created.
Note: You must activate the template for the probe to apply the filter configuration. When you change the template state to
active, the probe immediately applies all template configuration, including filters, rules, and monitors.
A filter allows you to control which devices and monitors are associated with a particular template. You specify more device criteria by using rules.
Filters usually contain one or more rules to define the types of devices for the template. You can add rules to a device filter to create divisions
within a group of systems or reduce the set of devices that the probe monitors. For example, you can add a rule to apply a configuration to all
devices with the name Cisco.
Note: If no rules exist, the probe always applies the monitor configuration in an active template to all applicable devices.
Follow these steps:

1. To add a filter that applies to the entire template, click cisco_ucs > Template Editor >cisco_ucs node > template name.
Or, to add a rule to a specific device filter, go to Template Editor > cisco_ucs probe > template name > Device Filters > device filter
.
The details pane displays the filter configuration.
2. In the details pane, go to the Rules section. Select New.
3. Select the type of rule.
For example, these are a few of the commonly available rule types for device filters:
Computer Name - Devices that match the entered computer name name.
Label - Devices that match the entered component name.
Primary DNS - Devices that match the entered primary DNS server.
Primary IPV4 - Devices that match the entered IPV4 address.
4. Select a condition. The conditions that you can apply to the rules are:
4.
Contains
Does not contain
Ends with
Equals
Not equals
Regex (regular expression)
Starts with
5. Enter a value for the rule.
6. Click Save.
The rule is created.
Note: You must activate the template for the probe to apply the rule configuration. When you change the template state to active, the
probe immediately applies all template configuration, including filters, rules, and monitors.
Device filters contain a set of commonly used monitors that you can configure to meet you specific needs.
Follow these steps:
1. Click cisco_ucs > Template Editor >cisco_ucs probe > template name.
2. Click the desired device filter.
3. In the Detail pane, in the Monitors section, select any monitor.
A configuration dialog for the monitor appears below.
4. Check Include in Template to turn on the monitor.
5. (Optional) Check Publish Data.
6. (Optional) Check Publish Alarms.
Enter the desired settings for these required fields:
Value Definition
High Threshold
High Message Name
Low Operator
Low Threshold
Low Message Name
See Configure Alarm Thresholds for details.
7. Click Save.
The monitor is added.
Activate a Template
The probe does not automatically apply the template configuration. The probe only applies templates in an active state. The template icon in the
navigation pane indicates the state of the template. The states are inactive (
to apply it.
) and active (
). You must activate a template for the probe
Important! The monitor settings in a template override any monitor settings in the probe configuration GUI.
Follow these steps:

1. Go to the Template Editor > cisco_ucs > template name.
2. Check the Active box.
3. Click Save.
3.
The probe applies the monitoring configuration.
Note: You cannot modify a configured monitor in the probe configuration GUI once you activate a template.

The Template Summary View appears in the detail pane. It contains three sections.
1. The top section shows the basic configuration of the template:
Template Name
Description
Precedence
Activation Status
2. The middle section shows the All Monitors table that lists all monitors available in the template.
3. The bottom section shows the detailed configuration for a monitor selected in the table.
You can view all of the monitors included in any template configuration in the All Monitors table.
Follow these steps:
1. In the left-hand navigation tree, select a template.
The Template Summary view appears in the detail pane. In the Monitors Included in Template table, you see all of the monitors available
for the template and their configuration status.
2. To see details for a specific monitor, click on it.
The configuration details appear below the table.
Edit Configuration in Context
When you copy a default read-only template or create your own new template, you can edit the template's monitors from the Template Summary
View.
Note: For a default read-only template, you can view but cannot edit the template's monitor configuration in Template Summary View.
Follow these steps:

1. Select a monitor from the Monitors Included in Template table.
2. In the detail pane below the table, click on the Edit in Context hyperlink.
The hyperlink takes you to the autofilter that contains the selected monitor.
For more information about how to configure monitors, see Add Monitors to a Template Filter. For more information about how to configure
alarms, see Configuring Alarm Thresholds.
v2.3 cisco_ucs AC GUI Reference

This article describes the fields and features in the Cisco UCS Server Monitoring (cisco_ucs) probe.
Contents
Tree Hierarchy
Tree Icons
cisco_ucs Node
Template Editor
Profiles Node
Resource Node
<Managed System> Node
<Device> Nodes
Tree Hierarchy
Once a Resource profile is added, the components of the Resource are displayed in the tree. Click a node in the tree to see the alarms, events, or
monitors available for that component. The tree contains a hierarchical representation of the components that exist in the Cisco UCS
environment.
Tree Icons
The icons in the tree indicate the type of object the node contains.
- Closed folder. Organizational node that is used to group similar objects. Click the node to expand it.
- Open folder. Organizational node that is used to group similar objects. Click the triangle next to the folder to collapse it.
- Detached Configuration folder. Organizational node that is used to group objects that once had configuration that is no longer valid.
- The profile icon indicates the status of subcomponent discovery.

- OK. Discovery of subcomponents is completed.
- Pending. Discovery of subcomponents is in progress.
- Unknown.
- Failed. Discovery of subcomponents failed.
- Server, managed system, or resource
- Storage pool
- Storage Controller
- Chassis
- Shared processor pool or individual CPU processor

- Disk
- Memory
- Network interface
- Fan
- Power Supply Unit
- Port
cisco_ucs Node
Navigation: cisco_ucs Node
The cisco_ucs node contains the following sections:

cisco_ucs > Probe Information
cisco_ucs > Probe Setup
Use Probe-Oriented Bulk Config
Enabling bulk configuration allows you to apply monitoring with templates.
Important! Enabling this feature and applying monitoring with templates overwrites any manual monitoring configurations. Before
enabling probe-oriented bulk configuration, see v2.3 cisco_ucs AC Apply Monitoring with Templates.
Log Level
The probe's default log level is 3 (Recommended). You can set the log level to 4 or 5 for troubleshooting and return it to 3 for normal
operations.
cisco_ucs > (...) >Add New Profile
You can manually add a device profile. The profile icon indicates the status of subcomponent discovery.
Fields to know:
Hostname
The hostname or IP address of the IBM server you want to monitor.
Note: You must follow the Java standard of enclosing an IPv6 address in square brackets. For example: The input string
Active
Select this checkbox to activate monitoring of the resource.
Port
The SSH port for the target system.
Interval (secs)
The time to wait for connection to establish.
Username
A valid username to be used by the probe to log in to the IBM server.
Password
A valid password to be used by the probe to log in to the IBM server.
Alarm Message
Template Editor
You use the template editor to apply monitoring templates, with optional filters, rules, and monitors, to one or more resources.
The template editor contains the following default templates:
VM
Chassis
BladeServer
FabricInterconnects
The default templates contain settings for a recommended monitor configuration. These default configurations include high-value metrics for
Note: For more information about how to use the Template Editor, see v2.3 cisco_ucs AC Apply Monitoring with Templates.
Profiles Node
This section describes how to manage your device configuration. You can modify or delete a device profile, and validate the credentials for each
device.
Navigation: cisco_ucs Node > profile name
profile name > (...) > Delete Profile
Select this option to delete the profile.
profile name > Actions > Verify Selection
Use this section to modify settings for the profile.
profile name > Resource Setup
Fields to know:
Hostname
Active
Port
Interval (secs)
Username
Password
Alarm Message
Resource Node
The Resource node contains the managed systems that are associated with the resource.
Navigation: cisco_ucs > profile name > resource name
Click to view a Hosts node containing the managed systems that are on the resource.

Under each <managed system> node you can view device nodes and can manage the QoS metrics and thresholds for the managed system.
Navigation: cisco_ucs Node > profile name > resource name > Hosts > managed system name
managed system name > Monitors
You can change monitor settings in the fields below the table. Select a monitor in the table to view the monitor configuration fields.
Fields to know:
QoS Name
Description
This is a read-only field, describing the monitor.
Units
The unit of the monitored value (for example %, Mbytes etc.). The field is read-only.
Metric Type Id
Publish Data
Publish Alarms
Value Definition
Current Value -- The most current value that is measured will be used.
Delta Per Second -- The delta value that is calculated from the samples that are measured within a second will be used.
Note: The value definition effects the QoS publication interval. For example: If you set the value definition to an "average
of n," the probe will wait n cycles before it sends any QoS data to the Discovery server. If you set the value definition to
"delta," the probe will wait two cycles before it sends any QoS data to the Discovery server.
Number of Samples
The count of items for the Value Definition when set to Average Value Last n Samples .
Operator
The operator to be used when setting the high or low alarm threshold for the measured value. You must select Publish Alarms to
enable this setting.
Example:
Threshold
Message Name
The alarm message to be issued if the specified high or low threshold value is breached. These messages are kept in the message
pool.
<Device> Nodes
<Device> nodes exist for managed system devices.
Note: If you click a <Device> node, you might see a table with QoS metrics or more named device nodes. You must click the named device
nodes to view a table with QoS metrics.
<Device> > Monitors
Fields to know:
QoS Name
Description
Units
Metric Type Id
Publish Data
Publish Alarms
Value Definition
Current Value -- The most current value that is measured
Delta Value (Current - Previous) -- The delta value that is calculated from the current and the previous measured sample
Delta Per Second -- The delta value that is calculated from the samples that are measured within a second
Average Value Last n Samples -- The user specifies a count and the value is averaged based on the last "count" items
Number of Samples
Operator
Example:
Threshold
Message Name
pool.
v2.3 cisco_ucs Configure Alarm Thresholds

For more information about configuring thresholds for numeric monitors for the Cisco UCS Server Monitoring (cisco_ucs) probe v2.3 or later, see
Configuring Alarm Thresholds. The link takes you to a page that describes how to configure centralized thresholds for select probes in CA Unified
Important!
Thresholds for the following three types of monitors can only be configured in Admin Console:
Event Forwarding Monitors
Alarm Forwarding Monitors
Monitors with Boolean, Enumeration, or String-only Metrics
v2.3 cisco_ucs IM Configuration
This article describes how to configure the Cisco UCS Server Monitoring (cisco_ucs) probe in the Infrastructure Manager GUI.
Contents
Overview
General Setup
Create a New Resource
Using the Message Pool Manager
Add a New Alarm Message
Edit an Alarm Message
Delete an Alarm Message
Setting the Number of Connection Retries
Adding Monitors
Enabling the Monitors for QoS and Alarming
Using Templates
Copy a Default Template
Create a New Template
Add Monitors to a Template

Apply a Template
Using Automatic Configurations
Adding a Template to the Auto Configurations Node
Adding a Monitor to the Auto Configurations Node
Exploring the Contents of the Auto Configurations Node
Checking the Auto Monitors Node
Overview
After installing the probe, you must define what to monitor. At a high level there are three steps:
2. Add monitors (checkpoints). See the description in the section Adding Monitors.
3. Configure the properties for the checkpoints, in which you define QoS data, and define alarms to be sent if specified thresholds are
breached.
Important! Configuration of the probe -- through the Unified Management Portal (UMP), using the Admin Console portlet (AC) -- is not
compatible with the configuration through the Infrastructure Manager interface described here. Do not mix or interchange configuration
methods! If you do, the result will be unpredictable monitoring of your system.
General Setup
Click the General Setup button to set the level of details written to the log file for the probe. Log as little as possible during normal operation to
minimize disk consumption. This is a sliding scale with the range of information logged being fatal errors all the way to extremely detailed
information used for debugging.
Click the Apply button to implement the new log level immediately.

There are two ways to create a Resource:
Click the New Resource button on the toolbar.
Right click Resources in the navigation pane and select New Resource.
The Resource (New) dialog box appears. Enter the appropriate field information:
Port
Active
Username
Note: If Cisco UCS has been set up for LDAP Authentication, the login will require an LDAP label in addition to the user name.
The LDAP label is an arbitrary string used to identify the LDAP realm; it is configured in the Cisco UCS Manager by the Cisco
UCS administrator. You may need to contact your Cisco UCS administrator to get this LDAP label. When you set up the login
to work with LDAP authentication, use this convention: ucs-<LDAP Label>\<username>. The LDAP label is case-sensitive and
the username can be either lower or upper case.
Password
Alarm Message
Note: You can edit the message or define a new message using the Message Pool Manager.
Check Interval
The check interval defines how often the probe checks the values of the monitors. This can be set in seconds, minutes or hours. We
Test button
Click the Test button to verify the connection to the Resource.
After completing the fields and testing that the connection works, click OK to add the Resource. The initial data collection/polling cycle starts. The
resource hierarchy will populate once the polling cycle has completed.

You can add, remove, or modify alarm messages.These are the messages sent when a monitor threshold has been breached.

To add a new alarm message:
1. Click the Message Pool Manager button on the toolbar.
The Message Pool dialog appears.
2. Click the Add button.
The Message Properties dialog appears.
3. Complete the field information:
Identification Name
The name of the message.
Token
The type of alarm, either "monitor_error" or "resource_error".
Error Alarm Text
The alarm text sent when a violation occurs. Variables can be used in this field.
Example: $monitor
This variable will put the actual monitor name in the alarm text. There are several available variables: $resource, $host, $port, $descr,
$key, $unit, $value, $oper, and $thr.
Clear Alarm Text (OK)
The text sent when an alarm is cleared.
Error Severity
Severity of the alarm.
Subsystem string/id
The NAS subsystem ID for the Cisco UCS system.
4. Click OK to save the new message.

To edit an alarm message:
2. Select a message id in the list.
3.
3. Click the Edit button.

4. Update the message properties as needed.
5. Click OK.
6. Close the Message Pool Manager window and click Apply to implement the changes.

To delete an alarm message:
2. Select the message to remove.
3. Click the Remove button.
The alarm message is removed.

By default, the probe tries to reconnect to the Cisco UCS Manager server three more times after failing to connect. This setting will work for most
customers, but you can adjust the number of connection retries if necessary. This may be necessary, for example, if your Cisco UCS Manager
has a relatively slow response time.
Follow these steps:
1. In Infrastructure Manager, hold the Shift key down, right-click on the name of the probe and select Raw Configure.
2. Click the setup folder, then click New Key.
4. Save changes.
Adding Monitors
There are three different ways to add monitors to Cisco UCS entities:
Monitor dialog.
Use Templates
See the section Using Templates for further information.
Use Auto Configurations
Auto Configuration is a powerful way to automatically add monitors to be measured. Monitors are created for new devices (that is, ones
not currently monitored) that would otherwise need manual configuration to be monitored.
Example: Auto Configuration contains an auto-monitor for server 'Front Temperature'. When a new server is added to the Cisco UCS, the Auto
Configuration feature creates a monitor automatically for monitoring the new server.
See the section Using Automatic Configurations for further information.

To select a monitor you want to be measured for a Resource, click the Resource node in the navigation pane, and navigate through the
Resources hierarchy. Select a folder in the hierarchy to see the monitors for it, listed in the right pane. Click the check box beside the Monitors
you want to be active.
Note: You can also add monitors to be measured using templates (see the section Using Templates).
Select the All Monitors node to list all monitors currently being measured in the right pane. You can select or deselect monitors here as well.
Green icon - the monitor is configured and active
Gray icon - the monitor is configured but not active
Black icon - the monitor is not configured
Note: If a monitor name is in italics you have changed the configuration but have not applied the changes.

You can now see the current values for the monitors in the Values column in the monitor list. Selecting the checkbox next to a monitor name only
enables the monitor. To configure the probe to send QoS data and/or send alarms you must modify the properties for each monitor.
Double-click a monitor (or right-click and select Edit) to launch the monitors properties dialog.

Note the Type column when monitors are listed in the right pane. Monitors of type value and type event have different properties.

Name
environment.
Key
Description
environment.
Value Definition
Active
Enable Alarming
Note that the monitor will also be selected in the list of monitors in the right window pane when this option is selected, and that you can
enable or disable monitoring of the checkpoint from that list.
This section describes the alarm properties for the monitor.
Operator
Example:
Threshold
Unit
This field specifies the unit of the monitored value (for example %, Mbytes etc.). The field is read-only.
Message ID
Select the alarm message to be issued if the specified threshold value is breached. These messages reside in the message pool. You
can modify the messages in the Message Pool Manager.
Publish Quality of Service
QoS Name
The unique QoS metric. This is a read-only field.
entity.
Name
This is the name of the monitor. The name will be inserted into this field when the monitor is retrieved from the Cisco UCS, and you are
allowed to modify the name.
Key
Description
This is a description of the monitor. This description will be inserted into this field when the monitor is retrieved from the Cisco UCS. This
is a read-only field.
Subscribe
Selecting this option, an alarm will be sent when this event has been triggered.
Operator
Select the operator to be used when setting the alarm threshold for the event.
This threshold refers to the events severity level in Cisco UCS.
Example: >= 1 means alarm condition if the event is triggered, and the severity level in Cisco UCS is equal to or higher than 1 (Warning).
Severity
The threshold severity level for the event in Cisco UCS.
Message Token
Select the alarm message to be issued if the specified threshold value is breached. These messages are kept in the message pool. The
messages can be modified in the Message Pool Manager.
Important! Monitoring events may cause a larger than expected increase in alarm messages and possibly decrease in system
performance.
Using Templates
Templates let you define reusable sets of monitors to be measured on multiple Equipment, Pools, and UCS Service Profiles. They provide an
easy way to accomplish consistent monitoring of your UCS Manager environment.
The following default templates come with the probe:
Chassis
BladeServer
FabricInterconnects
VM
The default templates contain commonly used monitoring configurations that enable you to quickly apply monitoring.
You can also create your own templates and define a set of monitors belonging to each. You can then apply these templates to anything in the
Resources or Auto Configurations hierarchies in the navigation pane by dragging the template and dropping it on the appropriate item. This
assigns the template monitors to the drop point and everything below it.
If you apply a template to the Auto Configuration, its monitors are applied to all Cisco UCS monitored entities as they appear in the system. If you
need a finer level of control, you can apply a template to anything in the Resources hierarchy; in this case the monitors are applied to the
drop-point and everything subordinate to it. Any templates applied within the Resources hierarchy are static monitors. The static monitors override
any auto monitors for that specific resource entity.
Note: You can do both, placing general-purpose templates in Auto Configuration, and applying special-purpose templates that override
the Auto Configuration templates on specific nodes, for specific purposes.
See the Using Automatic Configurations section for details on Auto Configuration.
You can apply a default template as you do any other template. However, you may want to copy the default template and then apply the copy.
Copying the default template allows you to make modifications to the copies without losing the original default template's monitor settings.
Follow these steps:
1. Click the Templates node in the navigation pane.
2. Select the default template.
3. Right-click>Copy Template.
The Templates Properties dialog appears.
4. Give the copy a name and description.
The default template is copied and appears under the Templates node and in the content pane.
There are two ways to create a template:

Click the toolbar button for New Template ( ).
Right click the Templates node in the navigation pane, and choose New Template from the menu.
In the resulting Template Properties dialog, specify a Name and a Description for the new template.
Note that you can also edit an existing template: Select one of the templates defined under the Templates node in the navigation pane,
right-click it, and select Edit from the menu.
There are two ways to add a monitor to a template:

Drag the monitor from the content pane and drop it on the template in the navigation pane.
Right-click on a monitor in the content pane and select Add to Template.
You can edit the properties for monitors in the template as described in the section Edit Monitor Properties.
Apply a Template
Drag the template to the Auto Configuration node or the Resource (Equipment, Pools, or UCS Service Profiles) where you want it applied, and
drop it there.
Note: You can drop the template on an object containing multiple subordinate objects. This applies the template to the entity and all its
subordinate entities. A static monitor is created for this entity.

Automatic configuration is an optional but powerful way to automatically add monitors to be measured. This is the preferred method for
configuring your resources. When new Cisco UCS monitored entities are detected, "Auto Monitors" are created for devices that are not currently
monitored using a static monitor.
The Auto Configuration feature consists of two sub-nodes located under the Resource node in the navigation pane:
Auto Configurations node:
You can add contents from one or more templates or individual checkpoints to this node, using drag and drop. You must click the Apply
button and restart the probe to activate the changes. The probe then searches through the UCS Manager environment for applicable
entities. Auto Monitors representing the monitor(s) under the Auto Configuration node are created (and listed under the Auto Monitor
node, see below) for applicable entities where the metric does not already have a static monitor configured against it.
Auto Monitors node:
This node lists Auto Monitors, created based on the contents added to the Auto Configuration node. The Auto Monitors are only created
for content without a pre-existing static monitor.
Important! If you are experiencing performance problems, we recommend increasing the polling cycle and/or the memory configuration
for the probe. Increase memory when the probe is running out of memory. Increase polling cycle when the collection takes longer than
the configured interval.
You can add a template's content to the Auto Configurations as follows:

1. Click the Templates node in the navigation pane to list all available templates in the content pane.
2. Add a template to the Auto Configurations node by dragging the template from the list and dropping it on the Auto Configurations nod
e in the navigation pane.
3. Click the Auto Configurations node to verify that the template's content was successfully added.
See the Using Templates section to learn more about templates.
Note: You must click the Apply button and restart the probe to activate configuration changes.
You can add a single monitor (checkpoint) to the Auto Configurations node.
To list available monitors:
1. Select the Resource node in the navigation pane and navigate to the point of interest.
2. Select an object to list its monitors in the right pane.
3. Add the monitor to the Auto Configurations node by dragging the monitor to the Auto Configurations node and dropping it there.
4. Click the Auto Configurations node and verify that the monitor was successfully added.
To verify that the monitors were successfully added, click the Auto Configurations node in the navigation pane.
To edit the properties for a monitor, right-click in the list and choose Edit from the menu. See the section Edit Monitor Properties for
detailed information.
To delete a monitor from the list, right-click in the list and choose Delete from the menu.
Note: You must click the Apply button and restart the probe to activate the Auto Configuration feature.
When you restart the probe, it searches through the Resource's entities. For each one that is currently not monitored, an Auto Monitor is created
for each of the monitors listed under the Auto Configurations node.
All defined Auto Monitors are listed under the Auto Monitors node.
v2.3 cisco_ucs IM GUI Reference
This section contains the basic Infrastructure Manager GUI information for the Cisco UCS Server Monitoring (cisco_ucs) probe.
Contents
Probe Configuration Interface Overview

Configuration Interface Navigation
The Toolbar Buttons
The Navigation (left-side) Pane
Resources
Templates
Navigation Pane Updates
The Content (right-side) Pane
Content Pane Updates
Equipment
Chassis Interface Card
Rack Mounts
Pools

Double-click the line representing the cisco_ucs probe in the Infrastructure Manager to launch the probe configuration interface. It initially appears
with the Resources hierarchy empty.
The probe configuration lets you:
Define the IBM resource for monitoring.
Configure the monitors for getting required alarms and data.
Use templates and auto configuration options for configuring the monitors.
Manage the alarm messages.
Note: The probe GUI does not provide any option for managing the QoS list. This list is preconfigured in the probe and must not be
tampered with.
The configuration interface consists of a row of tool buttons above a window split into two parts:
The Navigation pane
The Content pane
In addition, a status bar at the bottom of the window shows version information and date and time when the probe was last started.
Note: The probe is only configurable in Admin Console if you see the following message: "The probe is running in bulk configure mode.
This GUI is not supported in bulk configure mode. Exiting." For more information, see the cisco_ucs AC Configuration guide.
The Toolbar Buttons
The configuration interface contains a row of toolbar buttons:
The General Setup button allows you to configure the log level for the probe.
The New Resource button allows you to add a new resource.
The Message Pool Manager button allows you to add, remove or edit alarm messages.
The Create New Template button allows you to create a new template.
The division on the left side of the window is the navigation pane. It displays the monitored Resources and any Templates you have created.
Resources
You can create a new Resource by clicking the New Resource button, or by right-clicking Resources and selecting New Resource.
Note: If you use an IPv6 address for a resource, you must follow the Java standard of enclosing the IPv6 address in square brackets.
For example: The input string [f0d0:0:0:0:0:0:0:10.0.00.0] works. But the input string f0d0:0:0:0:0:0:0:10.0.00.0 causes a stack trace
error that includes the exception: Caused by: java.lang.NumberFormatException: For input string: "f0d0:0:0:0:0:0:0:10.0.00.0".
The Resource is configured as a link to the UCS Manager environment. Note the following icons for the Resource node:
Resource is inactive
Resource is marked for deletion
Resource is unable to connect
New resource (not yet saved)
Resource is loading inventory. Not ready to browse
Resource is connected and inventory is ready to browse
The Resources node contains the following sub-hierarchies:
The Auto Configurations node
One or more checkpoints (or templates) can be added to this node, using drag and drop. These checkpoints can to be used for auto
configuring unmonitored devices. See the section Using Automatic Configurations for further information.
The Auto Monitors node
This is a list of the monitors that have been created based on the Auto-Configuration entries and the inventory available on the Resource.
The All Monitors node
This node contains the complete list of Monitors for the Resource. This includes Auto Monitors and manually configured Monitors. See
the section Using Automatic Configurations for further information.
The Cisco UCS hierarchy
This is a list of the Equipment, Pools, UCS Service Profiles and child components available in the UCS Manager environment for
monitoring.
Templates
This node contains the following default templates:

VM
Chassis
BladeServer
FabricInterconnects
Templates let you define reusable sets of monitors to apply to the various Cisco UCS components. After you create a template and define a set of
checkpoints belonging to that template, you can either:

Drag and drop the template into the cisco_ucs resource hierarchy where you want to monitor the checkpoints defined for the template.
This creates a static monitor for that resource component and its children (recursively) based on the template contents at the time the
static monitor is created.
Drag and drop the template into the Auto Configuration to add the template contents to the list of auto configuration monitors.
For more information, see the section Using Templates in the v2.3 cisco_ucs IM Configuration article.
A right-click with the mouse pointer in the navigation pane over the hostname or IP address node opens a pop-up menu with menu items for
managing the selected object or creating new objects of its type. Options typically include: New, Edit, Delete, Deactivate, and Refresh.
Note: When available, the Refresh menu item retrieves updated values and refreshes the display.
The content of the right pane depends on the current selection in the navigation pane.
If you select a Resources node in the navigation pane, the content pane lists the UCS Manager environments.
If you select Equipment, Pools, UCS Service Profiles or a child component in the navigation pane, the content pane lists the available monitors.
Active Monitors are check-marked. The following icons can appear:
Monitor is active but not enabled to send alarms. The Enable Monitoring checkbox is not selected for this monitor.
Black: Monitor is NOT activated. The Action option is not set in the properties dialog for the monitor.
Green: Monitor is activated for monitoring and, if an alarm threshold is set, the threshold value defined in the properties dialog for the monitor
is not exceeded.
Gray: Monitor is an inactive static monitor.
Other colors: Monitor is activated for monitoring and the threshold value defined in the properties dialog for the monitor is exceeded. The
color reflects the message token selected in the properties dialog for the monitor.
No value has been measured.
Note: A monitor name in italics indicates that the monitor has been modified and you must apply the changes before the monitor results
are updated.
A right-click with the mouse pointer on objects in the content pane opens a pop-up menu with menu items for managing the selected object type (
Edit, Delete, and Add to Template).
Note: When available, the Refresh menu item fetches updated values and refreshes the display.
Equipment
The server blade interface cards provide the traffic metric states.
If configured, the NICs on the server blade interface cards also provide traffic metrics (number of packets sent, packets dropped, errors,
etc.).
The information of the disks attached to the server blades is available at Equipment > Chassis/Rack Mounts > Servers. The metrics
collect the disk status values.
The ports in the Fixed Module / Expansion Module(s) are grouped into the following categories, based on the "ifRole" property in the Cisco UCS
Manager.
Expansion Module
Storage FC Ports
Unconfigured Ports
Uplink FC Ports
Fixed Module
Appliance Ports
FCoE Storage Ports
Server Ports
Unconfigured Ports
Uplink Ethernet Ports
Uplink FC Ports
The NIC nodes display an aggregated view of bandwidth (the bandwidth available for the Chassis, for Uplink to VSANs etc.).
Rack Mounts
Rack Mounts class is available in the Equipment node. The children nodes of this class are FEX and Servers. Rack Mounts have many
similarities with the equipmentChassis class. The cisco_ucs probe should automatically detect if any RackUnits are managed by the UCS
Manager.
Pools
The Cisco UCS contains a number of pools such as a MAC Pool (list of available MAC addresses), WWNN pool, WWPN pools, etc. It is useful
for the system administrators to be aware of how many of these pools are empty, how many are assigned, and so on.
The cisco_ucs probe supports the following pools. They are displayed in the tree view of the probe GUI.
MAC Pools
Server Pools
UUID Pools
WWNN Pools
WWPN Pools
The service profiles created in the Cisco UCSM are displayed in the tree view of cisco_ucs probe GUI under the UCS Service Profiles node.
v2.1 cisco_ucs IM Configuration
Contents
General Setup

Adding Monitors
Using Templates
Apply a Template
This section describes how to configure the cisco_ucs probe in Infrastructure Manager.
After installing the cisco_ucs probe, you must define what to monitor. At a high level there are three steps:
2. Add monitors (checkpoints). See the description in the section Adding Monitors (Checkpoints).
3. Configure the properties for the checkpoints, in which you define QoS data, and define alarms to be sent if specified thresholds are
breached.
Note: You must always click the Apply button to activate any configuration changes.
General Setup
Click the General Setup button to set the level of details written to the log file for the cisco_ucs probe. Log as little as possible during normal
operation to minimize disk consumption. This is a sliding scale with the range of information logged being fatal errors all the way to extremely
detailed information used for debugging.

Port
Active
Username
Note: If Cisco UCS has been set up for LDAP Authentication, the login will require an LDAP label in addition to the user name.
The LDAP label is an arbitrary string used to identify the LDAP realm; it is configured in the Cisco UCS Manager by the Cisco
UCS administrator. You may need to contact your Cisco UCS administrator to get this LDAP label. When you set up the login
to work with LDAP authentication, use this convention: ucs-<LDAP Label>\<username>. The LDAP label is case-sensitive and
the username can be either lower or upper case.
Password
Alarm Message
Note: You can edit the message or define a new message using the Message Pool Manager.
Check Interval
The check interval defines how often the probe checks the values of the monitors. This can be set in seconds, minutes or hours. We
Test button
After completing the fields and testing that the connection works, click OK to add the Resource. The initial data collection/polling cycle starts. The
resource hierarchy will populate once the polling cycle has completed.

You can add, remove, or modify alarm messages.These are the messages sent when a monitor threshold has been breached.

Identification Name
Token
Error Alarm Text
Example: $monitor
Error Severity
Subsystem string/id
The NAS subsystem ID for the Cisco UCS system.

5. Click OK.


By default, the cisco_ucs probe tries to reconnect to the Cisco UCS Manager server three more times after failing to connect. This setting will
work for most customers, but you can adjust the number of connection retries if necessary. This may be necessary, for example, if your Cisco
UCS Manager has a relatively slow response time.
Follow these steps:
1. In Infrastructure Manager, hold the Shift key down, right-click on the name of the probe and select Raw Configure.
2. Click the setup folder, then click New Key.
4. Save changes.
Adding Monitors
There are three different ways to add monitors to Cisco UCS entities:
Monitor dialog. See the section Manually Selecting Monitors to be Measured.
Use Templates
Example: Auto Configuration contains an auto-monitor for server 'Front Temperature'. When a new server is added to the Cisco UCS, the Auto
Configuration feature creates a monitor automatically for monitoring the new server.

Note: If a monitor name is in italics you have changed the configuration however have not applied the changes.

You can now see the current values for the monitors in the Values column in the monitor list. Selecting the checkbox next to a monitor name only
enables the monitor. To configure the probe to send QoS data and/or send alarms you must modify the properties for each monitor.
Double-click a monitor (or right-click and select Edit) to launch the monitors properties dialog. See To Edit Monitor Properties for further
information.

Note the Type column when monitors are listed in the right pane. Monitors of type value and type event have different properties.

Name
environment.
Key
Description
environment.
Value Definition
Active
Enable Alarming
Note that the monitor will also be selected in the list of monitors in the right window pane when this option is selected, and that you can
enable or disable monitoring of the checkpoint from that list.
This section describes the alarm properties for the monitor.

Operator
Example:
Threshold
Unit
This field specifies the unit of the monitored value (for example %, Mbytes etc.). The field is read-only.
Message ID
Select the alarm message to be issued if the specified threshold value is breached. These messages reside in the message pool. You
can modify the messages in the Message Pool Manager.
QoS Name
The unique QoS metric. This is a read-only field.
entity.
Name
This is the name of the monitor. The name will be inserted into this field when the monitor is retrieved from the Cisco UCS, and you are
allowed to modify the name.
Key
Description
This is a description of the monitor. This description will be inserted into this field when the monitor is retrieved from the Cisco UCS. This
is a read-only field.
Subscribe
Selecting this option, an alarm will be sent when this event has been triggered.
Operator
Select the operator to be used when setting the alarm threshold for the event.
This threshold refers to the events severity level in Cisco UCS.
Example: >= 1 means alarm condition if the event is triggered, and the severity level in Cisco UCS is equal to or higher than 1 (Warning).
Severity
The threshold severity level for the event in Cisco UCS.
Message Token
Select the alarm message to be issued if the specified threshold value is breached. These messages are kept in the message pool. The
Important! Monitoring events may cause a larger than expected increase in alarm messages and possibly decrease in system
performance.
Using Templates
Templates let you define reusable sets of monitors to be measured on multiple Equipment, Pools, and UCS Service Profiles. They provide an
easy way to accomplish consistent monitoring of your UCS Manager environment.
You can create your own templates and define a set of monitors belonging to each. You can then apply these templates to anything in the
assigns the template monitors to the drop point and everything below it.
If you apply a template to the Auto Configuration, its monitors are applied to all Cisco UCS monitored entities as they appear in the system. If you
need a finer level of control, you can apply a template to anything in the Resources hierarchy; in this case the monitors are applied to the
drop-point and everything subordinate to it. Any templates applied within the Resources hierarchy are static monitors. The static monitors override
any auto monitors for that specific resource entity.
Note: You can do both, placing general-purpose templates in Auto Configuration, and applying special-purpose templates that override
the Auto Configuration templates on specific nodes, for specific purposes.
See the Using Automatic Configurations section for details on Auto Configuration.

Note that you can also edit an existing template: Select one of the templates defined under the Templates node in the navigation pane,

Drag it from the content pane and drop it on the template in the navigation pane.
You can edit the properties for monitors in the template as described in the section To Edit Monitor Properties.
Apply a Template
Drag the template to the Auto Configuration node or the Resource (Equipment, Pools, or UCS Service Profiles) where you want it applied, and
drop it there.

configuring your resources. When new Cisco UCS monitored entities are detected, "Auto Monitors" are created for devices that are not currently
Auto Configurations node
You can add contents from one or more templates or individual checkpoints to this node, using drag and drop. You must click the Apply button
and restart the probe to activate the changes. The probe then searches through the UCS Manager environment for applicable entities. Auto
Monitors representing the monitor(s) under the Auto Configuration node are created (and listed under the Auto Monitor node, see below) for
applicable entities where the metric does not already have a static monitor configured against it.
IMPORTANT: If you are experiencing performance problems, we recommend increasing the polling cycle and/or the memory configuration for the
probe. Increase memory when the probe is running out of memory. Increase polling cycle when the collection takes longer than the configured
interval. .
Auto Monitors node
This node lists Auto Monitors, created based on the contents added to the Auto Configuration node. The Auto Monitors are only created for
content without a pre-existing static monitor.

To edit the properties for a monitor, right-click in the list and choose Edit from the menu. See the section To Edit Monitor Properties for
Note: When monitors have been added to the Auto Configurations node, you must click the Apply button and restart the probe to activate the
Auto Configuration feature.
When you restart the probe, it searches through the Resource's entities. For each one that is currently not monitored, an Auto Monitor is created
for each of the monitors listed under the Auto Configurations node.
All defined Auto Monitors are listed under the Auto Monitors node.
v2.1 cisco_ucs IM GUI Reference

This section contains the basic GUI information for the Cisco UCS Server Monitoring (cisco_ucs) probe.
Contents

The Toolbar Buttons

Resources
Templates
Equipment
Rack Mounts
Pools

Double-click the line representing the cisco_ucs probe in the Infrastructure Manager to launch the probe configuration interface. It initially appears
with the Resources hierarchy empty.
The probe configuration lets you:
tampered with.
The configuration interface consists of a row of tool buttons above a window split into two parts:
The Navigation pane
The Content pane
In addition, a status bar at the bottom of the window shows version information and date and time when the probe was last started.
The Toolbar Buttons
The division on the left side of the window is the navigation pane. It displays the monitored Resources and any Templates you have created.
Resources
You can create a new Resource by clicking the New Resource button, or by right-clicking Resources and selecting New Resource.
The Resource is configured as a link to the UCS Manager environment. Note the following icons for the Resource node:
Resource is inactive
Resource is marked for deletion
Resource is unable to connect
New resource (not yet saved)
Resource is loading inventory. Not ready to browse
Resource is connected and inventory is ready to browse
The Resources node contains the following sub-hierarchies:
The Auto Configurations node
One or more checkpoints (or templates) can be added to this node, using drag and drop. These checkpoints can to be used for auto
configuring unmonitored devices. See the section Using Automatic Configurations for further information.
The Auto Monitors node
This is a list of the monitors that have been created based on the Auto-Configuration entries and the inventory available on the Resource.
The All Monitors node
This node contains the complete list of Monitors for the Resource. This includes Auto Monitors and manually configured Monitors. See
the section Using Automatic Configurations for further information.
The Cisco UCS hierarchy
This is a list of the Equipment, Pools, UCS Service Profiles and child components available in the UCS Manager environment for
monitoring.
Templates
Templates let you define reusable sets of monitors to apply to the various Cisco UCS components. After you create a template and define a set of
checkpoints belonging to that template, you can either:
Drag and drop the template into the cisco_ucs resource hierarchy where you want to monitor the checkpoints defined for the template.
This creates a static monitor for that resource component and its children (recursively) based on the template contents at the time the
static monitor is created.
Drag and drop the template into the Auto Configuration to add the template contents to the list of auto configuration monitors.
See the section Using Templates for details.
A right-click with the mouse pointer in the navigation pane over the hostname or IP address node opens a pop-up menu with menu items for
managing the selected object or creating new objects of its type. Options typically include: New, Edit, Delete, Deactivate, and Refresh.
Note: When available, the Refresh menu item retrieves updated values and refreshes the display.
The content of the right pane depends on the current selection in the navigation pane.
If you select a Resources node in the navigation pane, the content pane lists the UCS Manager environments.
If you select Equipment, Pools, UCS Service Profiles or a child component in the navigation pane, the content pane lists the available monitors.
Active Monitors are check-marked. The following icons can appear:
Monitor is active but not enabled to send alarms. The Enable Monitoring checkbox is not selected for this monitor.
Black: Monitor is NOT activated. The Action option is not set in the properties dialog for the monitor.
Green: Monitor is activated for monitoring and, if an alarm threshold is set, the threshold value defined in the properties dialog for the monitor
is not exceeded.
Gray: Monitor is an inactive static monitor.
Other colors: Monitor is activated for monitoring and the threshold value defined in the properties dialog for the monitor is exceeded. The
color reflects the message token selected in the properties dialog for the monitor.
No value has been measured.
Note: A monitor name in italics indicates that the monitor has been modified and you must apply the changes before the monitor results
are updated.
A right-click with the mouse pointer on objects in the content pane opens a pop-up menu with menu items for managing the selected object type (
Edit, Delete, and Add to Template).
Note: When available, the Refresh menu item fetches updated values and refreshes the display.
Equipment
The server blade interface cards provide the traffic metric states.
If configured, the NICs on the server blade interface cards also provide traffic metrics (number of packets sent, packets dropped, errors,
etc.).
The information of the disks attached to the server blades is available at Equipment > Chassis/Rack Mounts > Servers. The metrics
collect the disk status values.
The ports in the Fixed Module / Expansion Module(s) are grouped into the following categories, based on the "ifRole" property in the Cisco UCS
Manager.
Expansion Module
Storage FC Ports
Unconfigured Ports
Uplink FC Ports
Fixed Module
Appliance Ports
FCoE Storage Ports
Server Ports
Unconfigured Ports
Uplink Ethernet Ports
Uplink FC Ports
The NIC nodes display an aggregated view of bandwidth (the bandwidth available for the Chassis, for Uplink to VSANs etc.).
Rack Mounts
Rack Mounts class is available in the Equipment node. The children nodes of this class are FEX and Servers. Rack Mounts have many
similarities with the equipmentChassis class. The cisco_ucs probe should automatically detect if any RackUnits are managed by the UCS
Manager.
Pools
The Cisco UCS contains a number of pools such as a MAC Pool (list of available MAC addresses), WWNN pool, WWPN pools, etc. It is useful
for the system administrators to be aware of how many of these pools are empty, how many are assigned, and so on.
The cisco_ucs probe supports the following pools. They are displayed in the tree view of the probe GUI.
MAC Pools
Server Pools
UUID Pools
WWNN Pools
WWPN Pools
The service profiles created in the Cisco UCSM are displayed in the tree view of cisco_ucs probe GUI under the UCS Service Profiles node.
cisco_ucs Metrics
The following table contains the metrics for the Cisco UCS Server Monitoring (cisco_ucs) probe.
Resource Entity
CHA_EQUIPMENTCHASSIS
Metric Name
Unit
Description
Version
Administrative
State
State
The administrative status of the chassis. Possible values are: 1 (acknowledged),

2 (re-acknowledge), 3 (decommission), 4 (remove).
v1.0
Config State
State
The configuration status of the chassis. Possible values are: 0 (un-initialized), 1

(un-acknowledged), 2 (unsupported-connectivity), 3 (ok), 4 (removing), 6
(ack-in-progress)
v1.0
Input Power
Watts
The input power to the chassis in watts
v1.0
Operability
State
The operability status of the chassis. Possible values are: 0 (unknown), 1

(operable), 2 (inoperable), 3 (degraded), 4 (powered-off), 5 (power-problem), 6
(removed), 7 (voltage-problem), 8 (thermal-problem), 9 (performance-problem),
10 (accessibility-problem), 11 (identity-unestablishable), 12 (bios-post-timeout),
13 (disabled), 51 (fabric-conn-problem), 52 (fabric-unsupported-conn), 81
(config), 82 (equipment-problem), 83 (decomissioning), 84
(chassis-limit-exceeded), 100 (not-supported), 101 (discovery), 102
(discovery-failed), 103 (identify), 104 (post-failure), 105 (upgrade-problem), 106
(peer-comm-problem), 107 (auto-upgrade).
v1.0
Output Power
Watts
The output power of the chassis in watts
v1.0
Overall Status
State
The overall status of the chassis. Possible values are: 0 (unknown), 1

v1.0
Power
State
The power status of the chassis. Possible values are: 0 (unknown), 1 (ok), 2
(failed), 3 (input-failed), 4 (input-degraded), 5 (output-failed), 6
(output-degraded), 7 (redundancy-failed), 8 (redundancy-degraded).
v1.0
Presence
State
The presence status of the chassis. Possible values are: 0 (unknown), 1

(empty), 10 (equipped), 11 (missing), 12 (mismatch), 13 (equipped-not-primary),
20 (equipped-identity-unestablishable), 21 (mismatch-identity-unestablishable),
30 (inaccessible), 40 (unauthorized), 100 (not-supported).
v1.0
CHA_EQUIPMENTFANMODULE
CHA_EQUIPMENTFAN
Thermal
State
The thermal status of the chassis. Possible values are: 0 (unknown), 1 (ok), 2
(upper-non-recoverable), 3 (upper-critical), 4 (upper-non-critical), 5
(lower-non-critical), 6 (lower-critical), 7 (lower-non-recoverable), 100
(not-supported).
v1.0
Exhaust
Temperature
Celsius
The exhaust temperature of the chassis fan module in celsius
Operability
State
The operability status of the chassis fan module. Possible values are: 0
(unknown), 1 (operable), 2 (inoperable), 3 (degraded), 4 (powered-off), 5
(power-problem), 6 (removed), 7 (voltage-problem), 8 (thermal-problem), 9
(performance-problem), 10 (accessibility-problem), 11 (identity-unestablishable),
12 (bios-post-timeout), 13 (disabled), 51 (fabric-conn-problem), 52
(fabric-unsupported-conn), 81 (config), 82 (equipment-problem), 83
(decomissioning), 84 (chassis-limit-exceeded), 100 (not-supported), 101
(discovery), 102 (discovery-failed), 103 (identify), 104 (post-failure), 105
(upgrade-problem), 106 (peer-comm-problem), 107 (auto-upgrade).
Overall Status
State
The overall status of the chassis fan module. Possible values are: 0 (unknown),
1 (operable), 2 (inoperable), 3 (degraded), 4 (powered-off), 5 (power-problem), 6
Performance
State
The performance status of the chassis fan module. Possible values are: 0
(unknown), 1 (ok), 2 (upper-non-recoverable), 3 (upper-critical), 4
(upper-non-critical), 5 (lower-non-critical), 6 (lower-critical), 7
(lower-non-recoverable), 100 (not-supported).
Power
State
The power status of the chassis fan module. Possible values are: 0 (unknown), 1 v1.0
(on), 2 (test), 3 (off), 4 (online), 5 (offline), 6 (offduty), 7 (degraded), 8
(power-save), 9 (error), 100 (not-supported).
Presence
State
The presence status of the chassis fan module. Possible values are: 0
(unknown), 1 (empty), 10 (equipped), 11 (missing), 12 (mismatch), 13
(equipped-not-primary), 20 (equipped-identity-unestablishable), 21
(mismatch-identity-unestablishable), 30 (inaccessible), 40 (unauthorized), 100
(not-supported).
v1.0
Thermal
State
The thermal status of the chassis fan module. Possible values are: 0 (unknown),
1 (ok), 2 (upper-non-recoverable), 3 (upper-critical), 4 (upper-non-critical), 5
(not-supported).
v1.0
Voltage
State
The voltage status of the chassis fan module. Possible values are: 0 (unknown),
(not-supported).
Operability
State
The operability status of the chassis fan. Possible values are: 0 (unknown), 1
v1.0
Overall Status
State
The overall status of the chassis fan. Possible values are: 0 (unknown), 1
v1.0
Performance
State
The performance status of the chassis fan. Possible values are: 0 (unknown), 1
(ok), 2 (upper-non-recoverable), 3 (upper-critical), 4 (upper-non-critical), 5
(not-supported).
v1.0
Power
State
The power status of the chassis fan. Possible values are: 0 (unknown), 1 (on), 2
(test), 3 (off), 4 (online), 5 (offline), 6 (offduty), 7 (degraded), 8 (power-save), 9
(error), 100 (not-supported).
v1.0
Presence
State
The presence status of the chassis fan. Possible values are: 0 (unknown), 1
v1.0
Speed
RPM
The speed of the chassis fan measured in rotations per minute
Thermal
State
The thermal status of the chassis fan. Possible values are: 0 (unknown), 1 (ok),
2 (upper-non-recoverable), 3 (upper-critical), 4 (upper-non-critical), 5
(not-supported).
v1.0
v1.0
CHA_EQUIPMENTPSU
CHA_EQUIPMENTIOCARD
Voltage
State
The voltage of the chassis fan. Possible values are: 0 (unknown), 1 (ok), 2
(not-supported).
v1.0
Input 210v
Volts
The input to the chassis power supply unit measured in 210v
v1.0
Internal
Temperature
Celsius
The internal temperature of the chassis power supply unit
v1.0
Operability
State
The operability status of the chassis power supply unit. Possible values are: 0
v1.0
Output 12v
Volts
The output 12v of the chassis power supply unit measured in volts
v1.0
Output 3v3
Volts
The output 3v3 of the chassis power supply unit measured in volts
v1.0
Output Current
Amps
The output current of the chassis power supply unit measured in volts
v1.0
Output Power
Watts
The output power of the chassis power supply unit measured in watts
v1.0
Overall Status
State
The overall status of the chassis power supply unit. Possible values are: 0
v1.0
Performance
State
The performance status of the chassis power supply unit. Possible values are : 0
v1.0
Power
State
The power status of the chassis power supply unit. Possible values are 0
(unknown), 1 (on), 2 (test), 3 (off), 4 (online), 5 (offline), 6 (offduty), 7
(degraded), 8 (power-save), 9 (error), 100 (not-supported).
v1.0
Presence
State
The presence status of the chassis power supply unit. Possible values are: 0
(not-supported).
v1.0
Thermal
State
The thermal status of the chassis power supply unit. Possible values are: 0
v1.0
Voltage
State
The voltage status of the chassis power supply unit. Possible values are: 0
v1.0
ASIC
Temperature
Celsius
The temperature of the chassis IO card ASIC measured in celsius
v1.2
Admin Power
State
State
The admin power status of the chassis IO card. Possible values are: 1 (policy), 2
(cycle-immediate), 3 (cycle-wait).
v1.2
Ambient
Temperature
Celsius
The ambient temperature of the chassis IO card measured in celsius
v1.2
Config State
State
The configuration status of the chassis IO card. Possible values are: 0

(un-initialized), 1 (un-acknowledged), 2 (unsupported-connectivity), 3 (ok), 4
(removing), 6 (ack-in-progress).
v1.2
Discovery
State
The discovery status of the chassis IO card. Possible values are: 0 (unknown), 1
(online), 2 (offline), 3 (discovered), 4 (unsupported-connectivity), 5
(auto-upgrading).
v1.2
Operability
State
The operability status of the chassis IO card. Possible values are: 0 (unknown),
v1.2
CHA_ETHERSERVERINTFIO
CHA_ETHERSWITCHINTFIO
CHA_COMPUTEBLADE
Overall Status
State
The overall status of the chassis IO card. Possible values are: 0 (unknown), 1
v1.2
Peer
Communication
Status
State
The peer communication status of the chassis IO card. Possible values are: 0
(unknown), 1 (connected), 2 (disconnected)..
v1.2
Performance
State
The performance of the chassis IO card. Possible values are: 0 (unknown), 1

(not-supported).
v1.2
Power
State
The power status of the chassis IO card. Possible values are: 0 (unknown), 1
v1.2
Presence
State
The presence status of the chassis IO card. Possible values are: 0 (unknown), 1
v1.2
Thermal
State
The thermal status of the chassis IO card. Possible values are: 0 (unknown), 1
(not-supported).
v1.2
Voltage
State
The voltage status of the chassis IO card. Possible values are: 0 (unknown), 1
(not-supported).
v1.2
Administrative
State
State
The administrative status of the chassis ethernet server interface IO. Possible
values are: 0 (enabled), 1 (disabled).
v1.2
Overall Status
State
The overall status of the chassis ethernet server interface IO. Possible values
are: 0 (indeterminate), 1 (up), 2 (admin-down), 3 (link-down), 4 (failed), 5
(no-license), 6 (link-up), 7 (hardware-failure), 8 (software-failure), 9
(error-disabled), 10 (sfp-not-present).
v1.2
Acknowledged
State
The acknowledged status of the chassis ethernet switch interface IO. Possible
values are: 0 (un-initialized), 1 (un-acknowledged), 2 (unsupported-connectivity),
3 (ok), 4 (removing), 6 (ack-in-progress).
v1.2
Administrative
State
State
The administrative status of the chassis ethernet switch interface IO. Possible
values are: 0 (enabled), 1 (disabled).
v1.2
Discovery
State
The discovery status of the chassis ethernet switch interface IO. Possible values
are: 0 (absent), 1 (present), 2 (mis-connect).
v1.2
Overall Status
State
The overall status of the chassis ethernet switch interface IO. Possible values
are: 0 (indeterminate), 1 (up), 2 (admin-down), 3 (link-down), 4 (failed), 5
v1.2
Administrative
State
State
The administrative status of the chassis blade. Possible values are: 1

(in-service), 2 (out-of-service).
v1.0
Association
State
The association status of the blade. Possible values are: 0 (none), 1

(establishing), 2 (associated), 3 (removing), 4 (failed), 5 (throttled).
v1.0
Availability
State
The availability of the blade. Possible values are: 0 (unavailable), 1 (available).
v1.0
Consumed Power
Watts
The consumed power of the blade measured in watts
v1.0
Front
Temperature
Celsius
The front temperature of the blade measured in celsius
v1.0
Input Current
Amps
The input current of the blade measured in amps
v1.0
Input Voltage
Volts
The input voltage of the blade
v1.0
Operability
State
The operability status of the blade. Possible values are: 0 (unknown), 1

v1.0
CHA_ADAPTORUNIT
CHA_ADAPTOREXTETHIF
CHA_ADAPTORHOSTFCIF
Overall Status
State
The overall status of the blade. Possible values are: 0 (indeterminate), 1

(unassociated), 10 (ok), 11 (discovery), 12 (config), 13 (unconfig), 14
(power-off), 15 (restart), 20 (maintenance), 21 (test), 29 (compute-mismatch), 30
(compute-failed), 31 (degraded), 32 (discovery-failed), 33 (config-failure), 34
(unconfig-failed), 35 (test-failed), 36 (maintenance-failed), 40 (removed), 41
(disabled), 50 (inaccessible), 60 (thermal-problem), 61 (power-problem), 62
(voltage-problem), 63 (inoperable), 101 (decomissioning), 201 (bios-restore),
202 (cmos-reset), 203 (diagnostics), 204 (diagnostics-failed), 210
(pending-reboot), 211 (pending-reassociation).
v1.0
Power State
State
The power status of the blade. Possible values are: 0 (unknown), 1 (on), 2 (test),
3 (off), 4 (online), 5 (offline), 6 (offduty), 7 (degraded), 8 (power-save), 9 (error),
100 (not-supported).
v1.0
Presence
State
The presence status of the blade. Possible values are: 0 (unknown), 1 (empty),
10 (equipped), 11 (missing), 12 (mismatch), 13 (equipped-not-primary), 20
(equipped-identity-unestablishable), 21 (mismatch-identity-unestablishable), 30
(inaccessible), 40 (unauthorized), 100 (not-supported).
v1.0
Rear
Temperature
Celsius
The rear temperature of the blade measured in celsius
v1.0
Operability
State
The operability status of the chassis adaptor unit. Possible values are: 0
v1.0
Overall Status
State
The overall status of the chassis adaptor unit. Possible values are: 0 (unknown),
v1.0
Performance
State
The performance of the chassis adaptor unit. Possible values are: 0 (unknown),
(not-supported).
v1.0
Power
State
The power status of the chassis adaptor unit. Possible values are: 0 (unknown),
1 (on), 2 (test), 3 (off), 4 (online), 5 (offline), 6 (offduty), 7 (degraded), 8
v1.0
Presence
State
The presence status of the chassis adaptor unit. Possible values are: 0
(not-supported).
v1.0
Thermal
State
The thermal status of the chassis adaptor unit. Possible values are: 0
Voltage
State
The voltage of the chassis adaptor unit. Possible values are: 0 (unknown), 1
(not-supported).
v1.0
Administrative
State
State
The administrative status of the network facing adaptor interface. Possible

values are: 0 (enabled), 44 (reset-connectivity-active), 45
(reset-connectivity-passive), 46 (reset-connectivity).
v1.0
Overall Status
State
The overall status of the network facing adaptor interface. Possible values are: 0
(indeterminate), 1 (up), 2 (admin-down), 3 (link-down), 4 (failed), 5 (no-license),
6 (link-up), 7 (hardware-failure), 8 (software-failure), 9 (error-disabled), 10
(sfp-not-present).
v1.0
Administrative
State
State
The administrative status of the adaptor host fibre channel interface. Possible
Operability
State
The operability status of the adaptor host fibre channel interface. Possible
values are: 0 (unknown), 1 (operable), 2 (inoperable), 3 (degraded), 4
(powered-off), 5 (power-problem), 6 (removed), 7 (voltage-problem), 8
(thermal-problem), 9 (performance-problem), 10 (accessibility-problem), 11
(identity-unestablishable), 12 (bios-post-timeout), 13 (disabled), 51
(fabric-conn-problem), 52 (fabric-unsupported-conn), 81 (config), 82
(equipment-problem), 83 (decomissioning), 84 (chassis-limit-exceeded), 100
(not-supported), 101 (discovery), 102 (discovery-failed), 103 (identify), 104
(post-failure), 105 (upgrade-problem), 106 (peer-comm-problem), 107
(auto-upgrade).
v1.0
CHA_ADAPTORhostTHIF
CHA_MEMORYARRAY
Overall Status
State
The overall status of the adaptor host fibre channel interface. Possible values
are: 0 (unknown), 1 (operable), 2 (inoperable), 3 (degraded), 4 (powered-off), 5
v1.0
Performance
State
The performance of the adaptor host fibre channel interface. Possible values
are: 0 (unknown), 1 (ok), 2 (upper-non-recoverable), 3 (upper-critical), 4
v1.0
Power
State
The power status of the adaptor host fibre channel interface. Possible values
are: 0 (unknown), 1 (on), 2 (test), 3 (off), 4 (online), 5 (offline), 6 (offduty), 7
v1.0
Presence
State
The presence status of the adaptor host fibre channel interface. Possible values
are: 0 (unknown), 1 (empty), 10 (equipped), 11 (missing), 12 (mismatch), 13
(not-supported).
v1.0
Thermal
State
The thermal status of the adaptor host fibre channel interface. Possible values
v1.0
Voltage
State
The voltage status of the adaptor host fibre channel interface. Possible values
v1.0
Administrative
State
State
The administrative status of the adaptor host ethernet interface. Possible values
are: 0 (enabled), 44 (reset-connectivity-active), 45 (reset-connectivity-passive),
46 (reset-connectivity).
v1.0
Operability
State
The operability status of the adaptor host ethernet interface. Possible values are: v1.0
0 (unknown), 1 (operable), 2 (inoperable), 3 (degraded), 4 (powered-off), 5
Overall Status
State
The overall status of the adaptor host ethernet interface. Possible values are: 0
v1.0
Performance
State
The performance of the adaptor host ethernet interface. Possible values are: 0
v1.0
Power
State
The power status of the adaptor host ethernet interface. Possible values are: 0
v1.0
Presence
State
The presence status of the adaptor host ethernet interface. Possible values are:
0 (unknown), 1 (empty), 10 (equipped), 11 (missing), 12 (mismatch), 13
(not-supported).
v1.0
Thermal
State
The thermal status of the adaptor host ethernet interface. Possible values are:0
v1.0
Voltage
State
The voltage status of the adaptor host ethernet interface. Possible values are: 0
v1.0
Current Capacity
Megabytes
The current capacity of the memory array measured in megabytes
v1.0
Max Capacity
Megabytes
The max capacity of the memory array measured in megabytes
v1.0
CHA_MEMORYUNITENVSTATS
CHA_PROCESSORENVSTATS
CHA_STORAGECONTROLLER
CHA_STORAGELOCALDISK
Operability
State
The operability status of the memory unit environment. Possible values are: 0
v2.3
Presence
State
The presence status of the memory unit environment. Possible values are: 0
(not-supported).
v1.0
Temperature
Celsius
The temperature of the memory unit environment measured in celsius
v1.0
Visibility
State
The visibility of the memory unit environment; active = yes.
v1.0
CPU
Temperature
Celsius
The CPU temperature of the processor environment measured in celsius
v1.0
Input Current
Amps
The input current of the processor environment measured in amps
v1.0
Operability
State
The operability status of the processor environment. Possible values are: 0

v1.0
Visibility
State
The visibility of the processor environment; active = yes.
v1.0
Operability
State
The operability status of the storage controller. Possible values are: 0

v1.0
Overall Status
State
The overall status of the storage controller. Possible values are: 0 (unknown), 1
v1.0
Performance
State
The performance status of the storage controller. Possible values are: 0

v1.0
Power
State
The power status of the storage controller. Possible values are: 0 (unknown), 1
v1.0
Presence
State
The presence status of the storage controller. Possible values are: 0 (unknown),
1 (empty), 10 (equipped), 11 (missing), 12 (mismatch), 13
(not-supported).
v1.0
Thermal
State
The thermal status of the storage controller. Possible values are: 0 (unknown), 1
(not-supported).
v1.0
Voltage
State
The voltage status of the storage controller. Possible values are: 0 (unknown), 1
(not-supported).
v1.0
Operability
State
The operability status of the storage local disk. Possible values are: 0
v1.0
CHA_STORAGELOCALLUN
CHA_STORAGERAIDBATTERY
SWENVSTATS
EQUIPMENTFAN
Presence
State
The presence status of the storage local disk. Possible values are: 0 (unknown),
(not-supported).
v1.0
Operability
State
The operability state. Possible values are: 0 (unknown), 1 (operable), 2

(inoperable), 3 (degraded), 4 (powered-off), 5 (power-problem), 6 (removed), 7
(voltage-problem), 8 (thermal-problem), 9 (performance-problem), 10
(accessibility-problem), 11 (identity-unestablishable), 12 (bios-post-timeout), 13
(disabled), 51 (fabric-conn-problem), 52 (fabric-unsupported-conn), 81 (config),
82 (equipment-problem), 83 (decomissioning), 84 (chassis-limit-exceeded), 100
(auto-upgrade).
v1.0
Presence
State
The presence state. Possible values are: 0 (unknown), 1 (empty), 10 (equipped),

11 (missing), 12 (mismatch), 13 (equipped-not-primary), 20
Operability
State
The operability status of the storage RAID battery. Possible values are: 0
v1.0
Presence
State
The presence status of the storage RAID battery. Possible values are: 0
(not-supported).
v1.0
Available Memory
Megabytes
The available memory of the fabric interconnect in megabytes
v1.0
Cached Memory
Megabytes
The cached memory of the fabric interconnect in megabytes
v1.0
Load
Percent
The load percentage of the fabric interconnect data points
v1.0
Operability
State
The operability status of the fabric interconnect. The possible values are: 0
(unknown), 1 (operable), 2 (inoperable).
v1.0
fanCtrlrInlet1
Celsius
The temperature of the fabric interconnect fan controller 1
v1.0
fanCtrlrInlet2
Celsius
v1.0
fanCtrlrInlet3
Celsius
v1.0
fanCtrlrInlet4
Celsius
v1.0
mainBoardOutlet1 Celsius
The temperature of the fabric interconnect main board outlet 1
v1.0
mainBoardOutlet2 Celsius
The temperature of the fabric interconnect main board outlet 2
v1.0
psuCtrlrInlet1
Celsius
The temperature of the fabric interconnect power supply unit controller inlet 1
v1.0
psuCtrlrInlet2
Celsius
The temperature of the fabric interconnect power supply unit controller inlet 2
v1.0
Operability
State
The operability status of the fan. Possible values are: 0 (unknown), 1 (operable),
2 (inoperable), 3 (degraded), 4 (powered-off), 5 (power-problem), 6 (removed), 7
(auto-upgrade).
v1.0
Overall Status
State
The overall status of the fan. Possible values are: 0 (unknown), 1 (operable), 2
(inoperable), 3 (degraded), 4 (powered-off), 5 (power-problem), 6 (removed), 7
(auto-upgrade).
v1.0
Performance
State
The performance status of the fan. Possible values are: 0 (unknown), 1 (ok), 2
(not-supported).
v1.0
Power
State
The power status of the fan. Possible values are: 0 (unknown), 1 (on), 2 (test), 3
(off), 4 (online), 5 (offline), 6 (offduty), 7 (degraded), 8 (power-save), 9 (error),
100 (not-supported).
Presence
State
The presence status of the fan. Possible values are: 0 (unknown), 1 (empty), 10
(equipped), 11 (missing), 12 (mismatch), 13 (equipped-not-primary), 20
v1.0
EQUIPMENTPSU
EQUIPMENTSWITCHCARD
ETHERPIO
Thermal
State
The thermal status of the fan. Possible values are: 0 (unknown), 1 (ok), 2
(not-supported).
v1.0
Voltage
State
The voltage of the fan. Possible values are: 0 (unknown), 1 (ok), 2

(not-supported).
v1.0
Input Current
Amps
The input current of the equipment power supply unit measured in amps
Input Power
Watts
The input power of the equipment power supply unit measured in watts
v1.0
Input Voltage
Volts
The input voltage of the equipment power supply
v1.0
Operability
State
The operability status of the equipment power supply. Possible values are: 0
v1.0
Overall Status
State
The overall status of the equipment power supply. Possible values are: 0
v1.0
Performance
State
The performance status of the equipment power supply. Possible values are: 0
Power
State
The power status of the equipment power supply. Possible values are: 0
v1.0
Presence
State
The presence status of the equipment power supply. Possible values are: 0
(not-supported).
v1.0
Thermal
State
The thermal status of the equipment power supply. Possible values are: 0
v1.0
Voltage
State
The voltage of the equipment power supply, Possible values are: 0 (unknown), 1
(not-supported).
v1.0
Operability
State
The operability status of the equipment switch card. Possible values are: 0
v1.0
State
State
The status of the equipment switch card. Possible values are: 0 (unknown), 1
v1.0
Administrative
State
State
The administrative status of the ether port IO. Possible values are: 0 (enabled),
1 (disabled).
v1.0
Align
errors
The errors of the alignment of the ether port IO
v1.0
Broadcast
Packets Rx
packets
The broadcast packets Rx of the ether port IO
v1.0
Broadcast
Packets Tx
packets
The broadcast packets Tx of the ether port IO
v1.0
Byte Rate Rx
mbps
The byte rate Rx of the ether port IO
v1.0
Byte Rate Tx
mbps
The byte Rate Tx of the ether port IO
v1.0
Carrier Sense
errors
The carrier sense errors of the ether port IO
v1.0
Deferred Tx
errors
The deferred Tx errors of the ether port IO
v1.0
Excess Collision
errors
The excess collision errors of the ether port IO
v1.0
FCPIO
Fcs
errors
The Fcs errors of the ether port IO
v1.0
Giants
errors
The giants errors of the ether port IO
v1.0
Int Mac Rx
errors
The Int Mac Rx errors of the ether port IO
v1.0
Int Mac Tx
errors
The Int Mac Tx errors of the ether port IO
v1.0
Jumbo Packets
Rx
packets
The jumbo packets Rx errors of the ether port IO
v1.0
Jumbo Packets
Tx
packets
The jumbo packets Tx errors of the ether port IO
v1.0
Late Collision
errors
The late collision errors of the ether port IO
v1.0
Multi Collision
errors
The multi collision errors of the ether port IO
v1.0
Multicast Packets
Rx
packets
The multicast packets Rx of the ether port IO
v1.0
Multicast Packets
Tx
packets
The multicast packets Tx of the ether port IO
v1.0
Out Discard
errors
The out discard errors of the ether port IO
v1.0
Overall Status
State
The overall status of the ether port IO. Possible values are: 0 (indeterminate), 1
(up), 2 (admin-down), 3 (link-down), 4 (failed), 5 (no-license), 6 (link-up), 7
(hardware-failure), 8 (software-failure), 9 (error-disabled), 10 (sfp-not-present).
v1.0
Rcv
errors
The Rx errors of the ether port IO
v1.0
Recv Pause
pause
The Rx pauses of the ether port IO
v1.0
Resets
resets
The resets of the ether port IO
v1.0
SQETest
errors
The SQE test errors of the ether port IO
v1.0
Single Collision
errors
The single collision errors of the ether port IO
v1.0
Symbol
errors
The symbol errors of the ether port IO
v1.0
Total Bytes Rx
Bytes
The total bytes Rx of the ether port IO
v1.0
Total Bytes Tx
Bytes
The total bytes Tx of the ether port IO
v1.0
Total Packets Rx
packets
The total packets Rx of the ether port IO
v1.0
Total Packets Tx
packets
The total packets Tx of the ether port IO
v1.0
Under Size
errors
The under size errors of the ether port IO
v1.0
Unicast Packets
Rx
packets
The unicast packets Rx of the ether port IO
v1.0
Unicast Packets
Tx
packets
The unicast packets Tx of the ether port IO
v1.0
Xmit
errors
The Tx errors of the ether port IO
v1.0
Xmit Pause
pause
The Tx pauses of the ether port IO
v1.0
ifRole
State
The ifRole status of the ether port IO. Possible values are: 0 (unknown), 1
(network), 2 (server), 3 (mgmt), 4 (diag), 5 (storage), 6 (monitor), 7
(fcoe-storage), 8 (nas-storage), 9 (fcoe-nas-storage), 10 (fcoe-uplink), 11
(network-fcoe-uplink).
v1.0
operSpeed
State
The operation speed status of the ether port IO. Possible values are: 0
(indeterminate), 1 (1gbps), 2 (10gbps), 3 (20gbps), 4 (40gbps).
v1.0
utilization
Percent
The percentage of utilization of the ether port IO
v1.0
Administrative
State
State
The administrative status of the fibre channel port IO. Possible values are: 0
(enabled), 1 (disabled).
v1.0
Byte Rate Rx
mbps
The byte rate Rx of the fibre channel port IO
v1.0
Byte Rate Tx
mbps
The byte rate Tx of the fibre channel port IO
v1.0
Bytes Rx
Bytes
The bytes Rx of the fibre channel port IO
v1.0
Bytes Tx
Bytes
The bytes Tx of the fibre channel port IO
v1.0
Crc Rx
errors
The cyclic redundancy check Rx errors of the fibre channel port IO
v1.0
Discard Rx
errors
The discard Rx errors of the fibre channel port IO
v1.0
Discard Tx
errors
The discard Tx errors of the fibre channel port IO
v1.0
Link Failures
errors
The link failures errors of the fibre channel port IO
v1.0
Overall Status
State
The overall status of the fibre channel port IO. Possible values are: 0
(sfp-not-present).
v1.0
Packets Rx
Packets
The packets Rx of the fibre channel port IO
v1.0
Packets Tx
Packets
The packets Tx of the fibre channel port IO
v1.0
Rx
errors
The Rx errors of the fibre channel port IO
v1.0
Signal Losses
errors
The signal loss errors of the fibre channel port IO
v1.0
Sync Losses
errors
The sync loss errors of the fibre channel port IO
v1.0
Too Long Rx
errors
The too long Rx errors of the fibre channel port IO
v1.0
Too Short Rx
errors
The too short Rx errors of the fibre channel port IO
v1.0
Tx
errors
The Tx errors of the fibre channel port IO
v1.0
ifRole
State
The ifRole status of the fibre channel port IO. Possible values are: 0 (unknown),
1 (network), 2 (server), 3 (mgmt), 4 (diag), 5 (storage), 6 (monitor), 7
(fcoe-storage), 8 (nas-storage), 9 (fcoe-nas-storage), 10 (fcoe-uplink), 11
(network-fcoe-uplink).
v1.0
operSpeed
State
The operation speed of the fibre channel port IO. Possible values are: 0
(indeterminate), 1 (1gbps), 2 (2gbps), 3 (4gbps), 4 (8gbps), 5 (auto).
v1.0
utilization
Percent
The percentage of utilization of the fibre channel port IO
v1.0
Size
Integer
The size of the storage item
v1.0
Used
Percent
The percentage used of the storage item
v1.0
VMHV
Status
State
The status of the VMHZ. Possible values are: 0 (unknown), 1 (online), 2 (offline).
v1.0
VMINSTANCE
Status
State
The status of the VM instance. Possible values are: 0 (unknown), 1 (online), 2

(offline).
v1.0
LSSERVER
Assign State
State
The assigned status of the LS server. Possible values are: 0 (unassigned), 1

(assigned), 2 (failed).
v1.0
Assoc State
State
The association status of the LS server. Possible values are: 0 (unassociated), 1

(associating), 2 (associated), 3 (disassociating), 4 (failed).
v1.0
Config State
State
The configuration status of the LS server. Possible values are: 0 (not-applied), 1

(applying), 2 (failed-to-apply), 3 (disassociating), 4 (applied).
v1.0
Overall Status
State
The overall status of the LS server. Possible values are: 0 (indeterminate), 1

(unassociated), 10 (ok), 11 (discovery), 12 (config), 13 (unconfig), 14
(power-off), 15 (restart), 20 (maintenance), 21 (test), 29 (compute-mismatch), 30
(compute-failed), 31 (degraded), 32 (discovery-failed), 33 (config-failure), 34
(unconfig-failed), 35 (test-failed), 36 (maintenance-failed), 40 (removed), 41
(disabled), 50 (inaccessible), 60 (thermal-problem), 61 (power-problem), 62
(voltage-problem), 63 (inoperable), 101 (decomissioning), 201 (bios-restore),
202 (cmos-reset), 203 (diagnostics), 204 (diagnostics-failed), 210
(pending-reboot), 211 (pending-reassociation).
v1.0
% Used
Percent
The percentage of the mac pool used
v1.2
Assigned
Count
The count of of the assigned mac pool
v1.2
Size
Count
The size of the mac pool
v1.2
% Used
Percent
The percentage of the UUID pool used
v1.2
Assigned
Count
The count of of the assigned UUID pool
v1.2
Size
Count
The size of the UUID pool
v1.2
% Used
Percent
The percentage of the WWPN pool used
v1.2
Assigned
Count
The count of of the assigned WWPN pool
v1.2
Size
Count
The size of the WWPN pool
v1.2
% Used
Percent
The percentage of the WWNN pool used
v1.2
Assigned
Count
The count of of the assigned WWNN pool
v1.2
Size
Count
The size of the WWNN pool
v1.2
% Used
Percent
The percentage of the computer pool used
v1.2
Assigned
Count
The count of the assigned computer pool
v1.0
Size
Count
The size of the computer pool
v1.0
Admin State
State
The admin status of the fabric extender. Possible values are: 1 (acknowledged),
2 (re-acknowledge), 3 (decommission), 4 (remove).
v1.0
Config State
State
The configuration status of the fabric extender. Possible values are: 0

v1.0
Operability
State
The operability status of the fabric extender. Possible values are: 0 (unknown), 1
v1.0
STORAGEITEM
MACPOOLPOOL
UUIDPOOLPOOL
WWPNPOOL
WWNNPOOL
COMPUTEPOOL
FEX_EQUIPMENTFEX
FEX_EQUIPMENTFAN
FEX_EQUIPMENTPSU
Overall Status
State
The overall status of the fabric extender. Possible values are: 0 (unknown), 1
v1.0
Power
State
The power status of the fabric extender. Possible values are: 0 (unknown), 1
v1.0
Presence
State
The presence status of the fabric extender. Possible values are: 0 (unknown), 1
v1.0
Thermal
State
The thermal status of the fabric extender. Possible values are: 0 (unknown), 1
(not-supported).
v1.0
Voltage
State
The voltage status of the fabric extender. Possible values are: 0 (unknown), 1
(not-supported).
v1.0
Operability
State
The operability status of the fabric extender fan. Possible values are: 0
v1.0
Overall Status
State
The overall status of the fabric extender fan. Possible values are: 0 (unknown), 1
v1.0
Performance
State
The performance status of the fabric extender fan. Possible values are: 0
v1.0
Power
State
The power status of the fabric extender fan. Possible values are: 0 (unknown), 1
v1.0
Presence
State
The presence status of the fabric extender fan. Possible values are: 0
(not-supported).
v1.0
Thermal
State
The thermal status of the fabric extender fan. Possible values are: 0 (unknown),
(not-supported).
v1.0
Voltage
State
The voltage status of the fabric extender fan. Possible values are: 0 (unknown),
(not-supported).
v1.0
Input Current
Amps
The input current of the fabric extender power supply unit measured in amps
v1.0
Input Power
Watts
The input power of the fabric extender power supply unit measured in watts
v1.0
Input Voltage
Volts
The input voltage of the fabric extender power supply unit
v1.0
Operability
State
The operability status of the fabric extender power supply unit. Possible values
are: 0 (unknown), 1 (operable), 2 (inoperable), 3 (degraded), 4 (powered-off), 5
v1.0
FEX_EQUIPMENTIOCARD
Overall Status
State
The overall status of the fabric extender power supply unit. Possible values are:
0 (unknown), 1 (operable), 2 (inoperable), 3 (degraded), 4 (powered-off), 5
v1.0
Performance
State
The performance status of the fabric extender power supply unit. Possible
values are: 0 (unknown), 1 (ok), 2 (upper-non-recoverable), 3 (upper-critical), 4
v1.0
Power
State
The power status of the fabric extender power supply unit. Possible values are:
0 (unknown), 1 (on), 2 (test), 3 (off), 4 (online), 5 (offline), 6 (offduty), 7
v1.0
Presence
State
The presence status of the fabric extender power supply unit. Possible values
(not-supported).
v1.0
Thermal
State
The thermal status of the fabric extender power supply unit. Possible values are:
0 (unknown), 1 (ok), 2 (upper-non-recoverable), 3 (upper-critical), 4
v1.0
Voltage
State
The voltage status of the fabric extender power supply unit. Possible values are:
0 (unknown), 1 (ok), 2 (upper-non-recoverable), 3 (upper-critical), 4
v1.0
Admin Power
State
State
The admin power status of the fabric extender IO card. Possible values are: 1
(policy), 2 (cycle-immediate), 3 (cycle-wait).
v1.4
Config State
State
The configuration status of the fabric extender IO card. Possible values are: 0
v1.4
Discovery
State
The discovery status of the fabric extender IO card. Possible values are: 0
(unknown), 1 (online), 2 (offline), 3 (discovered), 4 (unsupported-connectivity), 5
(auto-upgrading).
v1.4
Operability
State
The operability status of the fabric extender IO card. Possible values are: 0
v1.4
Overall Status
State
The overall status of the fabric extender IO card. Possible values are: 0
v1.4
Peer
Communication
Status
State
The peer communication status of the fabric extender IO card. Possible values
are: 0 (unknown), 1 (connected), 2 (disconnected).
v1.4
Performance
State
The performance status of the fabric extender IO card. Possible values are: 0
v1.4
Power
State
The power status of the fabric extender IO card. Possible values are: 0
v1.4
Presence
State
The presence status of the fabric extender IO card. Possible values are: 0
(not-supported).
v1.4
Thermal
State
The thermal status of the fabric extender IO card. Possible values are: 0
v1.4
FEX_ETHERRXSTATS
FEX_ETHERSWITCHINTFIO
Voltage
State
The voltage status of the fabric extender IO card. Possible values are: 0
v1.4
Administrative
State
State
The administrative state of the fabric extender ethernet. Possible values are: 0
(enabled), 1 (disabled).
v1.0
Align
errors
The alignment errors of the fabric extender ethernet
v1.0
Broadcast
Packets Rx
packets
The broadcast packets Rx of the fabric extender ethernet
v1.0
Broadcast
Packets Tx
packets
The broadcast packets Tx of the fabric extender ethernet
v1.0
Carrier Sense
errors
The carrier sense errors of the fabric extender ethernet
v1.0
Deferred Tx
errors
The deferred Tx errors of the fabric extender ethernet
v1.0
Excess Collision
errors
The excess collision errors of the fabric extender ethernet
v1.0
Fcs
errors
The Fcs errors of the fabric extender ethernet
v1.0
Giants
errors
The giants errors of the fabric extender ethernet
v1.0
Int Mac Rx
errors
The Int Mac Rx errors of the fabric extender ethernet
v1.0
Int Mac Tx
errors
The Int Mac Tx errors of the fabric extender ethernet
v1.0
Jumbo Packets
Rx
packets
The jumbo packets Rx errors of the fabric extender ethernet
v1.0
Jumbo Packets
Tx
packets
The jumbo packets Tx errors of the fabric extender ethernet
v1.0
Late Collision
errors
The late collision errors of the fabric extender ethernet
v1.0
Multi Collision
errors
The multi collision errors of the fabric extender ethernet
v1.0
Multicast Packets
Rx
packets
The multicast packets Rx errors of the fabric extender ethernet
v1.0
Multicast Packets
Tx
packets
The multicast packets Tx errors of the fabric extender ethernet
v1.0
Out Discard
errors
The out discard errors of the fabric extender ethernet
v1.0
Overall Status
State
The overall status of the fabric extender ethernet. Possible values are: 0
(sfp-not-present).
v1.0
Rcv
errors
The receive errors of the fabric extender ethernet
v1.0
Recv Pause
pause
The receive pause errors of the fabric extender ethernet
v1.0
Resets
resets
The reset errors of the fabric extender ethernet
v1.0
SQE test
errors
The SQE test errors of the fabric extender ethernet
v1.0
Single Collision
errors
The single collision errors of the fabric extender ethernet
v1.0
Symbol
errors
The symbol errors of the fabric extender ethernet
v1.0
Total Bytes Rx
Bytes
The total bytes Rx of the fabric extender ethernet
v1.0
Total Bytes Tx
Bytes
The total bytes Tx of the fabric extender ethernet
v1.0
Total Packets Rx
packets
The total packets Rx of the fabric extender ethernet
v1.0
Total Packets Tx
packets
The total packets Tx of the fabric extender ethernet
v1.0
Under Size
errors
The under size errors of the fabric extender ethernet
v1.0
Unicast Packets
Rx
packets
The unicast packets Rx of the fabric extender ethernet
v1.0
Unicast Packets
Tx
packets
The unicast packets Tx of the fabric extender ethernet
v1.0
Xmit
errors
The transmit errors of the fabric extender ethernet
v1.0
Xmit Pause
pause
The transmit pause errors of the fabric extender ethernet
v1.0
Acknowledged
State
The acknowledged status of the fabric extender ethernet switch interface IO.
Possible values are: 0 (un-initialized), 1 (un-acknowledged), 2
(unsupported-connectivity), 3 (ok), 4 (removing), 6 (ack-in-progress).
v1.0
Administrative
State
State
The administrative status of the fabric extender ethernet switch interface IO.
Possible values are: 0 (enabled), 1 (disabled).
v1.0
Discovery
State
The discovery status of the fabric extender ethernet switch interface IO. Possible
values are: 0 (absent), 1 (present), 2 (mis-connect).
v1.0
Overall Status
State
The overall status of the fabric extender ethernet switch interface IO. Possible
values are: 0 (indeterminate), 1 (up), 2 (admin-down), 3 (link-down), 4 (failed), 5
v1.0
RACK_COMPUTERACKUNIT
RACK_EQUIPMENTFANMODULE
Administrative
State
State
The administrative status of the computer rack unit. Possible values are: 1
(in-service), 2 (out-of-service).
v1.0
Association
State
The association status of the computer rack unit. Possible values are: 0 (none),
1 (establishing), 2 (associated), 3 (removing), 4 (failed), 5 (throttled).
v1.0
Availability
State
The availability status of the computer rack unit. Possible values are: 0
(unavailable), 1 (available).
v1.0
Consumed Power
Watts
The consumed power of the computer rack unit
v1.0
Front
Temperature
Celsius
The front temperature of the computer rack unit
v1.0
IO Hub 1
Temperature
Celsius
The temperature of the IO Hub 1 computer rack unit
v1.0
IO Hub 2
Temperature
Celsius
The temperature of the IO Hub 2 computer rack unit
v1.0
Input Current
Amps
The input current of the computer rack unit
v1.0
Input Voltage
Volts
The input voltage of the computer rack unit
v1.0
Internal
Temperature
Celsius
The internal temperature of the computer rack unit
v1.0
Operability
State
The operability status of the computer rack unit. Possible values are: 0
v1.0
Overall Status
State
The overall status of the computer rack unit. Possible values are: 0
(indeterminate), 1 (unassociated), 10 (ok), 11 (discovery), 12 (config), 13
(unconfig), 14 (power-off), 15 (restart), 20 (maintenance), 21 (test), 29
(compute-mismatch), 30 (compute-failed), 31 (degraded), 32 (discovery-failed),
33 (config-failure), 34 (unconfig-failed), 35 (test-failed), 36 (maintenance-failed),
40 (removed), 41 (disabled), 50 (inaccessible), 60 (thermal-problem), 61
(power-problem), 62 (voltage-problem), 63 (inoperable), 101 (decomissioning),
201 (bios-restore), 202 (cmos-reset), 203 (diagnostics), 204 (diagnostics-failed),
210 (pending-reboot), 211 (pending-reassociation).
v1.0
Power State
State
The power status of the computer rack unit. Possible values are: 0 (unknown), 1
v1.0
Presence
State
The presence status of the computer rack unit. Possible values are: 0
(not-supported).
v1.0
Rear
Temperature
Celsius
The rear temperature of the computer rack unit.
v1.0
Operability
State
The operability status of the rack fan module. Possible values are: 0 (unknown),
v1.0
Overall Status
State
The overall status of the rack fan module. Possible values are: 0 (unknown), 1
v1.0
Performance
State
The perfermance status of the rack fan module. Possible values are: 0
v1.0
Power
State
The power status of the rack fan module. Possible values are: 0 (unknown), 1
v1.0
Presence
State
The presence status of the rack fan module. Possible values are: 0 (unknown), 1
v1.0
RACK_EQUIPMENTFAN
RACK_EQUIPMENTPSU
Thermal
State
The thermal status of the rack fan module. Possible values are: 0 (unknown), 1
(not-supported).
v1.0
Voltage
State
The voltage status of the rack fan module. Possible values are: 0 (unknown), 1
(not-supported).
v1.0
Operability
State
The operability status of the rack fan. Possible values are: 0 (unknown), 1
v1.0
Overall Status
State
The overall status of the rack fan. Possible values are: 0 (unknown), 1
v1.0
Performance
State
The performance status of the rack fan. Possible values are: 0 (unknown), 1
(not-supported).
v1.0
Power
State
The power status of the rack fan. Possible values are: 0 (unknown), 1 (on), 2
(test), 3 (off), 4 (online), 5 (offline), 6 (offduty), 7 (degraded), 8 (power-save), 9
(error), 100 (not-supported).
v1.0
Presence
State
The presence status of the rack fan. Possible values are: 0 (unknown), 1
v1.0
Speed
RPM
The speed status of the rack fan
v1.0
Thermal
State
The thermal status of the rack fan. Possible values are: 0 (unknown), 1 (ok), 2
(not-supported).
v1.0
Voltage
State
The voltage status of the rack fan. Possible values are: 0 (unknown), 1 (ok), 2
(not-supported).
v1.0
Input Power
Watts
The input power of the rack power supply unit
v1.0
Input Voltage
Volts
The input voltage of the rack power supply unit
v1.0
Internal
Temperature
Celsius
The internal temperature of the rack power supply unit
v1.0
Operability
State
The operability status of the rack power supply unit. Possible values are: 0
v1.0
Output Current
Amps
The output current of the rack power supply unit
v1.0
Output Power
Watts
The output power of the rack power supply unit
v1.0
Output Voltage
Volts
The output voltage of the rack power supply unit
v1.0
Overall Status
State
The overall status of the rack power supply unit. Possible values are: 0
v1.0
Performance
State
The performance status of the rack power supply unit. Possible values are: 0
v1.0
RACK_MEMORYARRAY
RACK_MEMORYUNITENVSTATS
RACK_PROCESSORENVSTATS
RACK_STORAGECONTROLLER
Power
State
The power status of the rack power supply unit. Possible values are: 0
v1.0
Presence
State
The presence status of the rack power supply unit. Possible values are: 0
(not-supported).
v1.0
Thermal
State
The thermal status of the rack power supply unit. Possible values are: 0
v1.0
Voltage
State
The voltage status of the rack power supply unit. Possible values are: 0
v1.0
Current Capacity
Megabytes
The current capacity of the rack memory array
v1.0
Max Capacity
Megabytes
The max capacity of the rack memory array
v1.0
Operability
State
The operability status of the rack memory array. Possible values are: 0
v2.3
Presence
State
The presence status of the rack memory array. Possible values are: 0
(not-supported).
v1.0
Temperature
Celsius
The temperature of the rack memory array
v1.0
Visibility
State
The visibility status of the rack memory array; active = yes.
v2.3
CPU
Temperature
Celsius
The CPU temperature of the rack processor environment
v1.0
Input Current
Amps
The input current of the rack processor environment
v1.0
Operability
State
The operability status of the rack processor environment. Possible values are: 0
v2.3
Visibility
State
The visibility status of the rack processor environment; active = yes.
v2.3
Operability
State
The operability status of the rack storage controller. Possible values are: 0
v1.0
Overall Status
State
The overall status of the rack storage controller. Possible values are: 0
v1.0
Performance
State
The performance status of the rack storage controller. Possible values are: 0
v1.0
Power
State
The power status of the rack storage controller. Possible values are: 0
v1.0
Presence
State
The presence status of the rack storage controller. Possible values are: 0
(not-supported).
v1.0
Thermal
State
The thermal status of the rack storage controller. Possible values are: 0
v1.0
Voltage
State
The voltage status of the rack storage controller. Possible values are: 0
v1.0
Operability
State
The operability status of the rack storage local disk. Possible values are: 0
v1.0
Presence
State
The presence status of the rack storage local disk. Possible values are: 0
(not-supported).
v1.0
Operability
State
The operability status of the rack storage local unit. Possible values are: 0
v1.0
Presence
State
The presence status of the rack storage local unit. Possible values are: 0
(not-supported).
v1.0
Operability
State
The operability status of the rack storage RAID battery. Possible values are: 0
v1.0
Presence
State
The presence status of the rack storage local RAID battery. Possible values are:
0 (unknown), 1 (empty), 10 (equipped), 11 (missing), 12 (mismatch), 13
(not-supported).
v1.0
Event
Integer
The number of UCS faults
v1.0
UCS API
Available
Boolean
Indicates whether the UCS API is available
v1.0
UCS API
Response Time
milliseconds The UCS API response time in milliseconds
v1.0
ETHERNET_UNCONFIGURED_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet unconfigured ports in mbps
v1.0
ETHERNET_NETWORK_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet network ports in mbps
v1.0
ETHERNET_SERVER_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet server ports in mbps
v1.0
ETHERNET_MGMT_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet management ports in mbps
v1.0
ETHERNET_DIAG_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet diagonal ports in mbps
v1.0
ETHERNET_STORAGE_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet storage ports in mbps
v1.0
ETHERNET_MONITOR_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet monitor ports in mbps
v1.0
RACK_STORAGELOCALDISK
RACK_STORAGELOCALLUN
RACK_STORAGERAIDBATTERY
RESOURCE
ETHERNET_FCOE_STORAGE_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet fibre channel over ethernet storage
ports in mbps
v1.0
ETHERNET_NAS_STORAGE_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet NAS storage ports in mbps
v1.0
ETHERNET_FCOE_NAS_STORAGE_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet fibre channel over ethernet NAS ports
in mbps
v1.0
ETHERNET_FCOE_UPLINK_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet fibre channel over ethernet uplink
ports in mbps
v1.0
ETHERNET_NETWORK_FCOE_UPLINK_PORTS Aggregated
Bandwidth
mbps
The aggregated bandwidth of the ethernet network fibre channel over ethernet
uplink ports in mbps
v1.0
FC_UNCONFIGURED_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the fibre channel unconfigured ports in mbps
v1.0
FC_NETWORK_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the fibre channel network ports in mbps
v1.0
FC_SERVER_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the fibre channel server ports in mbps
v1.0
FC_MGMT_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the fibre channel management ports in mbps
v1.0
FC_DIAG_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the fibre channel diagonal ports in mbps
v1.0
FC_STORAGE_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the fibre channel storage ports in mbps
v1.0
FC_MONITOR_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the fibre channel monitor ports in mbps
v1.0
FC_FCOE_STORAGE_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the fibre channel over ethernet storage ports in
mbps
v1.0
FC_NAS_STORAGE_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the fibre channel NAS storage ports in mbps
v1.0
FC_FCOE_NAS_STORAGE_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the fibre channel over ethernet NAS storage ports
in mbps
v1.0
FC_FCOE_UPLINK_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the fibre channel over ethernet uplink ports in
mbps
v1.0
FC_NETWORK_FCOE_UPLINK_PORTS
Aggregated
Bandwidth
mbps
The aggregated bandwidth of the network of fibre channel over ethernet uplink
ports in mbps
v1.0
CHA_ADAPTOREXTETHIF_ERROR_RX
Bad CRC
packets
The bad cyclic redundancy check (CRC) Rx packets of the adaptor external
ethernet interface
v1.0
Bad Length
packets
The bad length Rx packets of the adaptor external ethernet interface
v1.0
MAC Discarded
packets
The MAC discarded Rx packets of the adaptor external ethernet interface
v1.0
Bad CRC
packets
The bad cyclic redundancy check (CRC) Tx packets of the adaptor external
ethernet interface
v1.0
Bad Length
packets
The bad length Tx packets of the adaptor external ethernet interface
v1.0
MAC Discarded
packets
The MAC discarded Tx packets of the adaptor external ethernet interface
v1.0
Broadcast
packets
The Rx broadcast packets of the adaptor external ethernet interface
v1.0
Multicast
packets
The Rx multicast packets of the adaptor external ethernet interface
v1.0
Unicast
packets
The Rx unicast of the adaptor external ethernet interface
v1.0
Broadcast
packets
The Tx broadcast packets of the adaptor external ethernet interface
v1.0
Multicast
packets
The Tx multicast packets of the adaptor external ethernet interface
v1.0
Unicast
packets
The Tx unicast packets of the adaptor external ethernet interface
v1.0
Greater Than Or
Equal To 9216
packets
The Rx packets of the adaptor external ethernet interface greater than or equal
to 9216
v1.0
Less Than 2048
packets
The Rx packets of the adaptor external ethernet interface greater than or equal
to 2048
v1.0
Less Than 4096
packets
The Rx packets of the adaptor external ethernet interface less than 4096
v1.0
Less Than 8192
packets
v1.0
Less Than 9216
packets
v1.0
Less Than Or
Equal To 1518
packets
The Rx packets of the adaptor external ethernet interface less than or equal To
1518
v1.0
No Breakdown
Greater Than
1518
packets
The Rx packets of the adaptor external ethernet interface with no

breakdown greater than 1518
v1.0
Greater Than Or
Equal To 9216
packets
The Tx packets of the adaptor external ethernet interface greater than or equal
to 9216
v1.0
CHA_ADAPTOREXTETHIF_ERROR_TX
CHA_ADAPTOREXTETHIF_COMM_RX
CHA_ADAPTOREXTETHIF_COMM_TX
CHA_ADAPTOREXTETHIF_LARGE_RX
CHA_ADAPTOREXTETHIF_LARGE_TX
CHA_ADAPTOREXTETHIF_SMALL_RX
CHA_ADAPTOREXTETHIF_SMALL_TX
CHA_ADAPTOREXTETHIF_OUTSIZED_RX
CHA_ADAPTOREXTETHIF_OUTSIZED_TX
CHA_ADAPTOREXTETHIF_PACKETS_RX
CHA_ADAPTOREXTETHIF_PACKETS_TX
CHA_NIC_ADAPTORhostTHIF_ERROR_RX
Less Than 2048
packets
The Tx packets of the adaptor external ethernet interface less than 2048
v1.0
Less Than 4096
packets
v1.0
Less Than 8192
packets
v1.0
Less Than 9216
packets
v1.0
Less Than Or
Equal To 1518
packets
The Tx packets of the adaptor external ethernet interface less than or equal to
1518
v1.0
No Breakdown
Greater Than
1518
packets
The Tx packets of the adaptor external ethernet interface with no breakdown

greater than 1518
v1.0
Equal To 64
packets
The Rx packets of the adaptor external ethernet interface equal to 64
v1.0
Less Than 1024
packets
v1.0
Less Than 128
packets
v1.0
Less Than 256
packets
v1.0
Less Than 512
packets
v1.0
Less Than 64
packets
v1.0
Equal To 64
packets
The Tx packets of the adaptor external ethernet interface equal to 64
v1.0
Less Than 1024
packets
v1.0
Less Than 128
packets
v1.0
Less Than 256
packets
v1.0
Less Than 512
packets
v1.0
Less Than 64
packets
v1.0
Oversized
packets
The oversized Rx packets of the adaptor external ethernet interface
v1.0
Oversized Bad
CRC
packets
The oversized bad cyclic redundancy check (CRC) Rx packets of the adaptor
external ethernet interface
v1.0
Oversized Good
CRC
packets
The oversized good cyclic redundancy check (CRC) Rx packets of the adaptor
v1.0
Undersized Bad
CRC
packets
The undersized bad cyclic redundancy check (CRC) Rx packets of the adaptor
v1.0
Undersized Good
CRC
packets
The undersized good cyclic redundancy check (CRC) Rx packets of the adaptor
v1.0
Oversized
packets
The oversized Tx packets of the adaptor external ethernet interface
v1.0
Oversized Bad
CRC
packets
The oversized bad cyclic redundancy check (CRC) Tx packets of the adaptor
v1.0
Oversized Good
CRC
packets
The oversized good cyclic redundancy check (CRC) Tx packets of the adaptor
v1.0
Undersized Bad
CRC
packets
The undersized bad cyclic redundancy check (CRC) Tx packets of the adaptor
v1.0
Undersized Good
CRC
packets
The undersized good cyclic redundancy check (CRC) Tx packets of the adaptor
v1.0
Good
packets
The good Rx packets of the adaptor external ethernet interface
v1.0
PPP
packets
The point-to-point protocol (PPP) Rx packets of the adaptor external ethernet

interface
v1.0
Pause
packets
The paused Rx packets of the adaptor external ethernet interface
v1.0
Per Priority
packets
The per priority Rx packets of the adaptor external ethernet interface
v1.0
Total
packets
The total Rx packets of the adaptor external ethernet interface
v1.0
VLAN
packets
The VLAN Rx packets of the adaptor external ethernet interface
v1.0
Good
packets
The good Tx packets of the adaptor external ethernet interface
v1.0
PPP
packets
The point-to-point protocol (PPP) Tx packets of the adaptor external ethernet

interface
v1.0
Pause
packets
The pause Tx packets of the adaptor external ethernet interface
v1.0
Per Priority
packets
The per priority Tx packets of the adaptor external ethernet interface
v1.0
Total
packets
Total Tx packets of the adaptor external ethernet interface
v1.0
VLAN
packets
The VLAN Tx packets of the adaptor external ethernet interface
v1.0
Bad CRC
packets
The bad cyclic redundancy check (CRC) Rx packets of the NIC adaptor host
ethernet interface
v1.0
Bad Length
packets
The bad length Rx packets of the NIC adaptor host ethernet interface
v1.0
MAC Discarded
packets
The MAC discarded Rx packets of the NIC adaptor host ethernet interface
v1.0
CHA_NIC_ADAPTORhostTHIF_ERROR_TX
CHA_NIC_ADAPTORhostTHIF_COMM_RX
CHA_NIC_ADAPTORhostTHIF_COMM_TX
CHA_NIC_ADAPTORhostTHIF_LARGE_RX
CHA_NIC_ADAPTORhostTHIF_LARGE_TX
CHA_NIC_ADAPTORhostTHIF_SMALL_RX
CHA_NIC_ADAPTORhostTHIF_SMALL_TX
CHA_NIC_ADAPTORhostTHIF_OUTSIZED_RX
CHA_NIC_ADAPTORhostTHIF_OUTSIZED_TX
Bad CRC
packets
The bad cyclic redundancy check (CRC) Tx packets of the NIC adaptor host
ethernet interface
v1.0
Bad Length
packets
The bad length Tx packets of the NIC adaptor host ethernet interface
v1.0
MAC Discarded
packets
The MAC discarded Tx packets of the NIC adaptor host ethernet interface
v1.0
Broadcast
packets
The broadcast Rx packets of the NIC adaptor host ethernet interface
v1.0
Multicast
packets
The multicast Rx packets of the NIC adaptor host ethernet interface
v1.0
Unicast
packets
The unicast Rx packets of the NIC adaptor host ethernet interface
v1.0
Broadcast
packets
The broadcast Tx packets of the NIC adaptor host ethernet interface
v1.0
Multicast
packets
The multicast Tx packets of the NIC adaptor host ethernet interface
v1.0
Unicast
packets
The unicast Tx packets of the NIC adaptor host ethernet interface
v1.0
Greater Than Or
Equal To 9216
packets
The NIC adaptor host ethernet interface Rx packets greater than or equal to
9216
v1.0
Less Than 2048
packets
The NIC adaptor host ethernet interface Rx packets less than 2048
v1.0
Less Than 4096
packets
v1.0
Less Than 8192
packets
v1.0
Less Than 9216
packets
v1.0
Less Than Or
Equal To 1518
packets
The NIC adaptor host ethernet interface Rx packets less than or equal to 1518
v1.0
No Breakdown
Greater Than
1518
packets
The NIC adaptor host ethernet interface Rx packet with no breakdown greater
than 1518
v1.0
Greater Than Or
Equal To 9216
packets
The NIC adaptor host ethernet interface Tx packets greater than or equal to
9216
v1.0
Less Than 2048
packets
The NIC adaptor host ethernet interface Tx packets less than 2048
v1.0
Less Than 4096
packets
v1.0
Less Than 8192
packets
v1.0
Less Than 9216
packets
v1.0
Less Than Or
Equal To 1518
packets
The NIC adaptor host ethernet interface Tx packets less than or equal to 1518
v1.0
No Breakdown
Greater Than
1518
packets
The NIC adaptor host ethernet interface Tx packets with no breakdown greater
than 1518
v1.0
Equal To 64
packets
The NIC adaptor host ethernet interface Rx packets equal To 64
v1.0
Less Than 1024
packets
v1.0
Less Than 128
packets
v1.0
Less Than 256
packets
v1.0
Less Than 512
packets
v1.0
Less Than 64
packets
v1.0
Equal To 64
packets
The NIC adaptor host ethernet interface Tx packets equal to 64
v1.0
Less Than 1024
packets
v1.0
Less Than 128
packets
v1.0
Less Than 256
packets
v1.0
Less Than 512
packets
v1.0
Less Than 64
packets
v1.0
Oversized
packets
The oversized Rx packets of the NIC adaptor host ethernet interface
v1.0
Oversized Bad
CRC
packets
The oversized bad cyclic redundancy check (CRC) Rx packets of the NIC
adaptor host ethernet interface
v1.0
Oversized Good
CRC
packets
The oversized good cyclic redundancy check (CRC) Rx packets of the NIC
v1.0
Undersized Bad
CRC
packets
The undersized bad cyclic redundancy check (CRC) Rx packets of the NIC
v1.0
Undersized Good
CRC
packets
The undersized good cyclic redundancy check (CRC) Rx packets of the NIC
v1.0
Oversized
packets
The oversized Tx packets of the NIC adaptor host ethernet interface
v1.0
Oversized Bad
CRC
packets
The oversized bad cyclic redundancy check (CRC) Tx packets of the NIC
v1.0
Oversized Good
CRC
packets
The oversized good cyclic redundancy check (CRC) Tx packets of the NIC
v1.0
CHA_NIC_ADAPTORhostTHIF_PACKETS_RX
CHA_NIC_ADAPTORhostTHIF_PACKETS_TX
CHA_NIC_ADAPTORhostTHIF_VNIC
RACK_ADAPTORUNIT
RACK_ADAPTOREXTETHIF
Undersized Bad
CRC
packets
The undersized bad cyclic redundancy check (CRC) Tx packets of the NIC
v1.0
Undersized Good
CRC
packets
The undersized good cyclic redundancy check (CRC) Tx packets of the NIC
v1.0
Good
packets
The good Rx packets of the NIC adaptor host ethernet interface
v1.0
PPP
packets
The point-to-point protocol (PPP) Rx packets of the NIC adaptor host ethernet
interface
v1.0
Pause
packets
The pause Rx packets of the NIC adaptor host ethernet interface
v1.0
Per Priority
packets
The per priority Rx packets of the NIC adaptor host ethernet interface
v1.0
Total
packets
The total Rx packets of the NIC adaptor host ethernet interface
v1.0
VLAN
packets
The VLAN Rx packets of the NIC adaptor host ethernet interface
v1.0
Good
packets
The good Tx packets of the NIC adaptor host ethernet interface
v1.0
PPP
packets
The point-to-point protocol (PPP) Tx packets of the NIC adaptor host ethernet
interface
v1.0
Pause
packets
The paused Tx packets of the NIC adaptor host ethernet interface
v1.0
Per Priority
packets
The per priority Tx packets of the NIC adaptor host ethernet interface
v1.0
Total
packets
The total Tx packets of the NIC adaptor host ethernet interface
v1.0
VLAN
packets
The VLAN Tx packets of the NIC adaptor host ethernet interface
v1.0
Rx (bytes)
Bytes
The Rx bytes of the NIC adaptor host ethernet interface VNIC
v1.0
Rx (packets)
packets
The Rx packets of the NIC adaptor host ethernet interface VNIC
v1.0
Rx Dropped
packets
The Rx packets dropped of the NIC adaptor host ethernet interface VNIC
v1.0
Rx Errors
packets
The Rx errors of the NIC adaptor host ethernet interface VNIC
v1.0
Tx (bytes)
Bytes
The Tx bytes of the NIC adaptor host ethernet interface VNIC
v1.0
Tx (packets)
packets
The Tx packets of the NIC adaptor host ethernet interface VNIC
v1.0
Tx Dropped
packets
The Tx dropped of the NIC adaptor host ethernet interface VNIC
v1.0
Tx Errors
packets
The Tx errors of the NIC adaptor host ethernet interface VNIC
v1.0
Operability
State
The operability status of the rack adaptor unit. Possible values are: 0 (unknown),
v1.0
Overall Status
State
The overall status of the rack adaptor unit. Possible values are: 0 (unknown), 1
v1.0
Performance
State
The performance status of the rack adaptor unit. Possible values are: 0
v1.0
Power
State
The power status of the rack adaptor unit. Possible values are: 0 (unknown), 1
v1.0
Presence
State
The presence status of the rack adaptor unit. Possible values are: 0 (unknown),
(not-supported).
v1.0
Thermal
State
The thermal status of the rack adaptor unit. Possible values are: 0 (unknown), 1
(not-supported).
v1.0
Voltage
State
The voltage status of the rack adaptor unit. Possible values are: 0 (unknown), 1
(not-supported).
v1.0
Administrative
State
State
The administrative status of the adaptor external ethernet interface. Possible

v1.0
RACK_ADAPTORHOSTFCIF
RACK_ADAPTORhostTHIF
Overall Status
State
The overall status of the adaptor external ethernet interface. Status Possible
values are: 0 (indeterminate), 1 (up), 2 (admin-down), 3 (link-down), 4 (failed), 5
v1.0
Administrative
State
State
The administrative status of the rack adaptor host fibre channel interface.
Possible values are: 0 (enabled), 44 (reset-connectivity-active), 45
v1.0
Operability
State
The operability status of the rack adaptor host fibre channel interface. Possible
(auto-upgrade).
v1.0
Overall Status
State
The overall status of the rack adaptor host fibre channel interface. Possible
(auto-upgrade).
v1.0
Performance
State
The performance status of the rack adaptor host fibre channel interface.
Possible values are: 0 (unknown), 1 (ok), 2 (upper-non-recoverable), 3
(upper-critical), 4 (upper-non-critical), 5 (lower-non-critical), 6 (lower-critical), 7
v1.0
Power
State
The power status of the rack adaptor host fibre channel interface. Possible
values are: 0 (unknown), 1 (on), 2 (test), 3 (off), 4 (online), 5 (offline), 6 (offduty),
7 (degraded), 8 (power-save), 9 (error), 100 (not-supported).
v1.0
Presence
State
The presence status of the rack adaptor host fibre channel interface. Possible
values are: 0 (unknown), 1 (empty), 10 (equipped), 11 (missing), 12 (mismatch),
13 (equipped-not-primary), 20 (equipped-identity-unestablishable), 21
(not-supported).
v1.0
Thermal
State
The thermal status of the rack adaptor host fibre channel interface. Possible
v1.0
Voltage
State
The voltage status of the rack adaptor host fibre channel interface. Possible
v1.0
Administrative
State
State
The administrative status of the rack adaptor host ethernet interface. Possible
v1.0
Operability
State
The operability status of the rack adaptor host ethernet interface. Possible
(auto-upgrade).
v1.0
Overall Status
State
The overall status status of the rack adaptor host ethernet interface. Possible
(auto-upgrade).
v1.0
Performance
State
The performance status of the rack adaptor host ethernet interface. Possible
v1.0
Power
State
The power status of the rack adaptor host ethernet interface. Possible values
are: 0 (unknown), 1 (on), 2 (test), 3 (off), 4 (online), 5 (offline), 6 (offduty), 7
v1.0
RACK_ADAPTOREXTETHIF_ERROR_RX
RACK_ADAPTOREXTETHIF_ERROR_TX
RACK_ADAPTOREXTETHIF_COMM_RX
RACK_ADAPTOREXTETHIF_COMM_TX
RACK_ADAPTOREXTETHIF_LARGE_RX
RACK_ADAPTOREXTETHIF_LARGE_TX
RACK_ADAPTOREXTETHIF_SMALL_RX
RACK_ADAPTOREXTETHIF_SMALL_TX
Presence
State
The presence status of the rack adaptor host ethernet interface. Possible values
(not-supported).
v1.0
Thermal
State
The thermal status of the rack adaptor host ethernet interface. Possible values
v1.0
Voltage
State
The voltage status of the rack adaptor host ethernet interface. Possible values
v1.0
Bad CRC
packets
The bad cyclic redundancy check (CRC) Rx packets of the rack adaptor external
ethernet interface
v1.0
Bad Length
packets
The bad length Rx packets of the rack adaptor external ethernet interface
v1.0
MAC Discarded
packets
The MAC discarded Rx packets of the rack adaptor external ethernet interface
v1.0
Bad CRC
packets
The bad cyclic redundancy check (CRC) Tx packets of the rack adaptor external
ethernet interface
v1.0
Bad Length
packets
The bad length Tx packets of the rack adaptor external ethernet interface
v1.0
MAC Discarded
packets
The MAC discarded Tx packets of the rack adaptor external ethernet interface
v1.0
Broadcast
packets
The broadcast Rx packets of the rack adaptor external ethernet interface
v1.0
Multicast
packets
The multicast Rx packets of the rack adaptor external ethernet interface
v1.0
Unicast
packets
The unicast Rx packets of the rack adaptor external ethernet interface
v1.0
Broadcast
packets
The broadcast Tx packets of the rack adaptor external ethernet interface
v1.0
Multicast
packets
The multicast Tx packets of the rack adaptor external ethernet interface
v1.0
Unicast
packets
The unicast Tx packets of the rack adaptor external ethernet interface
v1.0
Greater Than Or
Equal To 9216
packets
The rack adaptor external ethernet interface Rx packets greater than or equal to
9216
v1.0
Less Than 2048
packets
The rack adaptor external ethernet interface Rx packets less than 2048
v1.0
Less Than 4096
packets
v1.0
Less Than 8192
packets
v1.0
Less Than 9216
packets
v1.0
Less Than Or
Equal To 1518
packets
The rack adaptor external ethernet interface Rx packets less than or equal to
1518
v1.0
No Breakdown
Greater Than
1518
packets
The rack adaptor external ethernet interface Rx packets with no breakdown

greater than 1518
v1.0
Greater Than Or
Equal To 9216
packets
The rack adaptor external ethernet interface Tx packets greater than or equal to
9216
v1.0
Less Than 2048
packets
The rack adaptor external ethernet interface Tx packets less than 2048
v1.0
Less Than 4096
packets
v1.0
Less Than 8192
packets
v1.0
Less Than 9216
packets
v1.0
Less Than Or
Equal To 1518
packets
The rack adaptor external ethernet interface Tx packets less than or equal to
1518
v1.0
No Breakdown
Greater Than
1518
packets
The rack adaptor external ethernet interface Tx packets with no breakdown

greater than 1518
v1.0
Equal To 64
packets
The rack adaptor external ethernet interface Rx packets that are equal to 64
v1.0
Less Than 1024
packets
The rack adaptor external ethernet interface Rx packets that are less than 1024
v1.0
Less Than 128
packets
v1.0
Less Than 256
packets
v1.0
Less Than 512
packets
v1.0
Less Than 64
packets
The rack adaptor external ethernet interface Tx packets that are less than 64
v1.0
Equal To 64
packets
The rack adaptor external ethernet interface Tx packets that are equal to 64
v1.0
Less Than 1024
packets
v1.0
Less Than 128
packets
v1.0
Less Than 256
packets
v1.0
Less Than 512
packets
v1.0
RACK_ADAPTOREXTETHIF_OUTSIZED_RX
RACK_ADAPTOREXTETHIF_OUTSIZED_TX
RACK_ADAPTOREXTETHIF_PACKETS_RX
RACK_ADAPTOREXTETHIF_PACKETS_TX
RACK_NIC_ADAPTORhostTHIF_ERROR_RX
RACK_NIC_ADAPTORhostTHIF_ERROR_TX
RACK_NIC_ADAPTORhostTHIF_COMM_RX
RACK_NIC_ADAPTORhostTHIF_COMM_TX
RACK_NIC_ADAPTORhostTHIF_LARGE_RX
Less Than 64
packets
v1.0
Oversized
packets
The oversized Rx packets of the rack adaptor external ethernet interface
v1.0
Oversized Bad
CRC
packets
The oversized bad cyclic redundancy check (CRC) Rx packets of the rack
adaptor external ethernet interface
v1.0
Oversized Good
CRC
packets
The oversized good cyclic redundancy check (CRC) Rx packets of the rack
v1.0
Undersized Bad
CRC
packets
The undersized bad cyclic redundancy check (CRC) Rx packets of the rack
v1.0
Undersized Good
CRC
packets
The undersized good cyclic redundancy check (CRC) Rx packets of the rack
v1.0
Oversized
packets
The oversized Tx packets of the rack adaptor external ethernet interface
v1.0
Oversized Bad
CRC
packets
The oversized bad cyclic redundancy check (CRC) Tx packets of the rack
v1.0
Oversized Good
CRC
packets
The oversized good cyclic redundancy check (CRC) Tx packets of the rack
v1.0
Undersized Bad
CRC
packets
The undersized bad cyclic redundancy check (CRC) Tx packets of the rack
v1.0
Undersized Good
CRC
packets
The undersized good cyclic redundancy check (CRC) Tx packets of the rack
v1.0
Good
packets
The good Rx packets of the rack adaptor external ethernet interface
v1.0
PPP
packets
The point-to-point protocol (PPP) Rx packets of the rack adaptor external ethern
et interface
v1.0
Pause
packets
The pause Rx packets of the rack adaptor external ethernet interface
v1.0
Per Priority
packets
The per priority Rx packets of the rack adaptor external ethernet interface
v1.0
Total
packets
The total Rx packets of the rack adaptor external ethernet interface
v1.0
VLAN
packets
The VLAN Rx packets of the rack adaptor external ethernet interface
v1.0
Good
packets
The good Tx packets of the rack adaptor external ethernet interface
v1.0
PPP
packets
The point-to-point protocol (PPP) Tx packets of the rack adaptor external ethern
et interface
v1.0
Pause
packets
The paused Tx packets of the rack adaptor external ethernet interface
v1.0
Per Priority
packets
The per priority Tx packets of the rack adaptor external ethernet interface
v1.0
Total
packets
The total Tx packets of the rack adaptor external ethernet interface
v1.0
VLAN
packets
The VLAN Tx packets of the rack adaptor external ethernet interface
v1.0
Bad CRC
packets
The bad cyclic redundancy check (CRC) Rx packets of the rack NIC adaptor
host ethernet interface
v1.0
Bad Length
packets
The bad length Rx packets of the rack NIC adaptor host ethernet interface
v1.0
MAC Discarded
packets
The MAC discarded Rx packets of the rack NIC adaptor host ethernet interface
v1.0
Bad CRC
packets
The bad cyclic redundancy check (CRC) Tx packets of the rack NIC adaptor
host ethernet interface
v1.0
Bad Length
packets
The bad Length Tx packets of the rack NIC adaptor host ethernet interface
v1.0
MAC Discarded
packets
The MAC discarded Tx packets of the rack NIC adaptor host ethernet interface
v1.0
Broadcast
packets
The broadcast Rx packets of the rack NIC adaptor host ethernet interface
v1.0
Multicast
packets
The multicast Rx packets of the rack NIC adaptor host ethernet interface
v1.0
Unicast
packets
The unicast Rx packets of the rack NIC adaptor host ethernet interface
v1.0
Broadcast
packets
The broadcast Tx packets of the rack NIC adaptor host ethernet interface
v1.0
Multicast
packets
The multicast Tx packets of the rack NIC adaptor host ethernet interface
v1.0
Unicast
packets
The unicast Tx packets of the rack NIC adaptor host ethernet interface
v1.0
Greater Than Or
Equal To 9216
packets
The rack NIC adaptor host ethernet interface large Rx packets that are greater
than or equal to 9216
v1.0
Less Than 2048
packets
The rack NIC adaptor host ethernet interface large Rx packets that are less than
2048
v1.0
Less Than 4096
packets
4096
v1.0
Less Than 8192
packets
8192
v1.0
Less Than 9216
packets
9216
v1.0
RACK_NIC_ADAPTORhostTHIF_LARGE_TX
RACK_NIC_ADAPTORhostTHIF_SMALL_RX
RACK_NIC_ADAPTORhostTHIF_SMALL_TX
RACK_NIC_ADAPTORhostTHIF_OUTSIZED_RX
RACK_NIC_ADAPTORhostTHIF_OUTSIZED_TX
RACK_NIC_ADAPTORhostTHIF_PACKETS_RX
Less Than Or
Equal To 1518
packets
The rack NIC adaptor host ethernet interface large Rxt packets that are less
v1.0
No Breakdown
Greater Than
1518
packets
The rack NIC adaptor host ethernet interface large Rx packets that have no
v1.0
Greater Than Or
Equal To 9216
packets
The rack NIC adaptor host ethernet interface large Tx packets that are greater
v1.0
Less Than 2048
packets
The rack NIC adaptor host ethernet interface large Tx packets that are less than
2048
v1.0
Less Than 4096
packets
4096
v1.0
Less Than 8192
packets
8192
v1.0
Less Than 9216
packets
9216
v1.0
Less Than Or
Equal To 1518
packets
or equal to 1518
v1.0
No Breakdown
Greater Than
1518
packets
The rack NIC adaptor host ethernet interface large Tx packets that have no
v1.0
Equal To 64
packets
The rack NIC adaptor host ethernet interface small Rx packets that are Equal To
64
v1.0
Less Than 1024
packets
The rack NIC adaptor host ethernet interface small Rx packets that are less than
1024
v1.0
Less Than 128
packets
128
v1.0
Less Than 256
packets
256
v1.0
Less Than 512
packets
512
v1.0
Less Than 64
packets
64
v1.0
Equal To 64
packets
The rack NIC adaptor host ethernet interface small Tx packets that are equal To
64
v1.0
Less Than 1024
packets
The rack NIC adaptor host ethernet interface small Tx packets that are less than
1024
v1.0
Less Than 128
packets
128
v1.0
Less Than 256
packets
256
v1.0
Less Than 512
packets
512
v1.0
Less Than 64
packets
64
v1.0
Oversized
packets
The oversized Rx packets of the rack NIC adaptor host ethernet interface
v1.0
Oversized Bad
CRC
packets
The oversized Rx bad cyclic redundancy check (CRC) packets of the rack NIC
v1.0
Oversized Good
CRC
packets
The oversized Rx good cyclic redundancy check (CRC) packets of the rack NIC
v1.0
Undersized Bad
CRC
packets
The undersized Rx bad cyclic redundancy check (CRC) packets of the rack NIC
v1.0
Undersized Good
CRC
packets
The undersized Rx good cyclic redundancy check (CRC) packets of the rack
NIC adaptor host ethernet interface
v1.0
Oversized
packets
The oversized Tx packets of the rack NIC adaptor host ethernet interface
v1.0
Oversized Bad
CRC
packets
The oversized Tx bad cyclic redundancy check (CRC) packets of the rack NIC
v1.0
Oversized Good
CRC
packets
The oversized Tx good cyclic redundancy check (CRC) packets of the rack NIC
v1.0
Undersized Bad
CRC
packets
The undersized Tx bad cyclic redundancy check (CRC) packets of the rack NIC
v1.0
Undersized Good
CRC
packets
The undersized Tx good cyclic redundancy check (CRC) packets of the rack NIC v1.0
Good
packets
The good Rx packets of the rack NIC adaptor host ethernet interface
v1.0
RACK_NIC_ADAPTORhostTHIF_PACKETS_TX
RACK_NIC_ADAPTORhostTHIF_VNIC
PPP
packets
The point-to-point protocol (PPP) Rx packets of the rack NIC adaptor host
ethernet interface
v1.0
Pause
packets
The paused Rx packets of the rack NIC adaptor host ethernet interface
v1.0
Per Priority
packets
The per priority Rx packets of the rack NIC adaptor host ethernet interface
v1.0
Total
packets
The total Rx packets of the rack NIC adaptor host ethernet interface
v1.0
VLAN
packets
The Rx packets of the rack NIC adaptor host ethernet interfaceVLAN
v1.0
Good
packets
The Tx packet status of the of the rack NIC adaptor host ethernet interface
v1.0
PPP
packets
The point-to-point protocol (PPP) Tx packets of the rack NIC adaptor host
ethernet interface
v1.0
Pause
packets
The paused Tx packets of the rack NIC adaptor host ethernet interface
v1.0
Per Priority
packets
The per priority packets of the rack NIC adaptor host ethernet interface
v1.0
Total
packets
The total Tx packets of the rack NIC adaptor host ethernet interface
v1.0
VLAN
packets
The Tx packets of the rack NIC adaptor host ethernet interface VLAN
v1.0
Rx (bytes)
Bytes
The Rx bytes of the rack NIC adaptor host ethernet interface VNIC
v1.0
Rx (packets)
packets
The Rx packets of the rack NIC adaptor host ethernet interface VNIC
v1.0
Rx Dropped
packets
The dropped Rx packets of the rack NIC adaptor host ethernet interface VNIC
v1.0
Rx Errors
errors
The Rx errors of the rack NIC adaptor host ethernet interface VNIC
v1.0
Tx (bytes)
Bytes
The Tx bytes of the rack NIC adaptor host ethernet interface VNIC
v1.0
Tx (packets)
packets
The Tx packets of the rack NIC adaptor host ethernet interface VNIC
v1.0
Tx Dropped
packets
The dropped Tx packets of the rack NIC adaptor host ethernet interface VNIC
v1.0
Tx Errors
errors
The Tx errors of the rack NIC adaptor host ethernet interface VNIC
v1.0
clariion (Clariion Monitoring)

EMC clariion storage systems represent a critical infrastructure component. These systems support environments from mainframes to desktops
and every flavor of server, application, cloud and business service. The Clariion Monitoring probe monitors the performance and availability
of EMC clariion CX4 storage systems. The clariion probe uses naviseccli (a command line tool available from EMC) to collect and store data and
information from the monitored clariion systems at customizable intervals. You can define alarms that are generated when the specified
thresholds are breached.
The clariion probe can monitor the following storage components:
Fast Cache
Hosts
LUNs
RAID Groups
Storage Groups
Thin Pools
Mirror Views
Storage Processors
Note: The 2.0 and later versions of the probe are now available only through the web-based GUI and not through the Infrastructure
Manager (IM) GUI.
The 2.10 and later versions of the probe include the standard static alarm threshold parameters.
Notes:
The standard static alarm threshold parameters are supported for only the 2.10 version or later of the probe using CA UIM 8.2.
All the probe specific alarm configurations in the probe monitors are replaced by Static alarms and Time over Threshold confi
gurations.
More information:
clariion (Clariion Monitoring) Release Notes
v2.1 clariion AC Configuration

This article describes the configuration concepts and procedures for setting up the clariion probe. This probe is configured to monitor the
performance of EMC storage platforms. The following diagram outlines the process to configure the probe to monitor the storage components.
Prerequisites
Verify that required hardware, software, and information is available before you configure the probe. The clariion probe requires Navisphere CLI
executable (naviseccli.exe) to gather data about the clariion systems. You are required to install the Navisphere CLI on the box where the clariion
probe is deployed. For more information, see clariion (Clariion Monitoring) Release Notes.
How to Monitor a Storage System

This section describes the minimum configuration settings required to configure the clariion probe.
Follow these steps:
2. Navigate to Navisphere CLI section under the clariion node.
3. Provide the absolute path of naviseccli.exe by clicking Browse. Click Save to save the configuration.
The probe now uses this executable to connect to the clariion systems.
4. Click the Options (icon) next to the clariion node in the navigation pane.
6. Set or modify the following values in the Add New Profile window:
6.
Storage Processor A: specifies the host name or IP address of Storage Processor A.
Storage Processor B: specifies the host name or IP address of Storage Processor B.
Source: specifies the source to be used for QoS metrics and alarms. This is typically the IP address of Storage Processor A.
Username: enables you to enter a valid username to be used by the probe to access the clariion system.
Password: enables you to enter a valid password to be used by the probe to access the clariion system.
Active: activates the profile for monitoring. By default, the profile is active.
Interval (seconds): specifies the time interval (in seconds) after which the probe collects the data from the clariion system for the
specific profile.
Default: 600
Alarm Message: specifies the alarm to be generated when the profile is not responding. For example, the profile does not respond if
there is a connection failure or inventory update failure.
Send Faults as Alarm: If selected, the probe sends the alarm for all the faults generated in the system.
Send Events as Alarm: If selected, the probe sends the alarm for all the events generated in the system.
Login Scope: defines the login scope for the Clariion system user. There can be following three types of clariion system users:
0(Global): A global user has access to the entire domain.
1(Local): A local user has access to a single system in the domain.
2(LDAP): LDAP users can access any system that uses the LDAP server to authenticate users.
Minimum Event Severity: enables you to configure the minimum event severity.
7. Click Submit.
The new monitoring profile is created and displayed under the clariion node. The monitoring categories for the storage components are
displayed as nodes below the profile name node.
8. Verify the connection between the probe and the storage server through the Verify Selection button under the Actions drop down.
9. Configure the alarms and thresholds in the monitors for the desired storage component. For example, to configure the alarms and
thresholds in the monitors for the Fast Cache node:
a. Navigate to clariion > Profile Name > Host Name > Fast Cache > Monitors
b. The performance counters are visible in a tabular form. Select any one counter from the table, and configure its properties.
Alarm Thresholds
allow the probe to:
v2.1 clariion AC GUI Reference

This article describes the fields and features of the clariion probe.
Contents
clariion Node
<Profile Name> Node
<Host Name> Node
<Storage Component Name> Node
clariion Node
The clariion node contains configuration details specific to the clariion probe. This node enables you to view the probe information, configure the
log properties and the location of the Navisphere CLI executable (naviseccli.exe) which is used to gather data about the Clariion system.
Navigation: clariion
clariion > Configuring Clariion Monitoring
This section describes the minimum configuration settings required to monitor a storage system using the clariion probe.
clariion > Probe Information
clariion > Probe Setup
clariion > Navisphere CLI
This section enables you to configure the location of naviseccli.exe.
Provide the absolute path of naviseccli.exe by clicking the Browse (icon). Click Save to save the configuration.
clariion > Options (icon)
This button allows you to add a resource as a monitoring profile to the probe.
<Profile Name> Node
This node lets you configure a profile for the storage component you want to monitor. The clariion probe uses each profile as a connection to the
storage component through which the probe collects and stores data and information from the monitored components. You can check the
connection between the probe and the storage server through the Verify Selection button under the Actions drop down.
Note: This node is referred to as Profile Name node in the article and is user-configurable.
Navigation: clariion > profile name > Resource Setup

Interval (seconds): specifies the time interval (in seconds) after which the probe collects the data from the clariion system for the specific
profile.
Default: 600
Note: It is recommended to use Global or Local users for monitoring the Clariion system in order to remove any dependency on LDAP
server.
Profile Name > Options (icon)
This button allows you to delete the monitoring profile from the probe.
<Host Name> Node
This node allows you to enable monitors to measure the performance of different storage components.
The monitors for the clariion elements are visible in a tabular form. You can select any one monitor from the table and configure its properties.
Navigation: clariion > Profile Name > Host Name > Monitors
Host Name > Monitors
This section lets you edit the properties of a monitor and configure the performance counters for generating QoS.
Note: The performance counters are visible in a tabular form. You can select any one counter in the table and configure its properties.
Value Definition: enables you to select which value to be used for generating alarms and QoS. The following options are available:
Current Value: The most current value measured will be used.
Average Value Last n Samples: The average value of the last and current sample, that is, (current + previous) / 2 will be used.
Delta Value (Current-Previous): The delta value calculated from the current and the previous measured sample will be used.
Delta Per Second: The delta value calculated from the samples measured within a second will be used.
The Storage Component Name node represents the actual name of the storage component which is available in the clariion storage system. This
node contains only the Monitors section. Select any of the monitors and configure its properties.
Note: The name varies for each storage component. So, this node is referred to as the Storage Component Name node in the
document.
Navigation: clariion > Profile Name > Host Name > Storage Component Name > Monitors
The Storage Component Name node contains the following sub nodes for representing various storage elements:
Fast Cache
Hosts
LUN Folders
Mirror Views
Physical
RAID Groups
Storage Groups
Storage Processor
Thin Pools
v2.0 clariion AC Configuration
performance of EMC storage platforms.
The following diagram outlines the process to configure the probe to monitor the storage components.
How to provide the path of naviseccli.exe

The clariion probe requires Navisphere CLI executable (naviseccli.exe) to gather data about the clariion systems.
Follow these steps:
2. Navigate to Navisphere CLI section under the clariion node.
3. Provide the absolute path of naviseccli.exe by clicking Browse.
Add a clariion profile

You can add a profile under the clariion node for monitoring purposes. This profile is used as a connection to the clariion system through which
the probe collects and stores information from the monitored components. Each profile represents one clariion system.
Follow these steps:
1. Click Options next to the clariion node in the navigation pane.
3. Update the field information with the storage processor details, the source to be used for QoS metrics and alarms, and valid username
and password.
4. Click Submit.
The new monitoring profile is saved and is visible under the clariion node in the navigation pane. You can now configure the monitors for
the desired storage component.
Delete a profile
You can delete a profile if you do not want the probe to monitor the performance of a specific storage component.
Follow these steps:
3. Click Save.
The monitoring profile is deleted.
Alarm Thresholds
allow the probe to:
v2.0 clariion AC GUI Reference

This article describes the fields and features of the clariion probe.
Contents
clariion node
<Profile Name> node
<Host Name> Node
clariion node
The clariion node contains configuration details specific to the clariion probe. This node enables you to view the probe information, configure the
log properties and the location of the Navisphere CLI executable (naviseccli.exe) which is used to gather data about the Clariion system.
Navigation: clariion
clariion > Configuring Clariion Monitoring
This section describes the minimum configuration settings required to monitor a storage system using the clariion probe.
clariion > Probe Information

clariion > Probe Setup
Clariion > Navisphere CLI
This section enables you to configure the location of naviseccli.exe.
<Profile Name> node
This node lets you configure a profile for the storage component you want to monitor. The clariion probe uses each profile as a connection to the
storage component through which the probe collects and stores data and information from the monitored components. You can check the
connection between the probe and the storage server through the Verify Selection button under the Actions drop down.
Note: This node is referred to as Profile Name node in the document and is user-configurable.
Navigation: clariion > profile name > Resource Setup

Interval (seconds): specifies the time interval (in seconds) after which the probe collects the data from the clariion system for the specific
profile.
Default: 600
Note: It is recommended to use Global or Local users for monitoring the Clariion system in order to remove any dependency on LDAP
server.
<Host Name> Node
This node allows you to enable monitors to measure the performance of different storage components.
The monitors for the clariion elements are visible in a tabular form. You can select any one monitor from the table and configure its properties.
Navigation: clariion > Profile Name > Host Name > Monitors
Host Name > Monitors

This section lets you edit the properties of a monitor and configure the performance counters for generating QoS.
Value Definition: enables you to select which value to be used for generating alarms and QoS. The following options are available:
Current Value: The most current value measured will be used.
Average Value Last n Samples: The average value of the last and current sample, that is, (current + previous) / 2 will be used.
Delta Value (Current-Previous): The delta value calculated from the current and the previous measured sample will be used.
Delta Per Second: The delta value calculated from the samples measured within a second will be used.
The Storage Component Name node represents the actual name of the storage component which is available in the clariion storage system. This
node contains only the Monitors section. Select any of the monitors and configure its properties.
Note: The name varies for each storage component. So, this node is referred to as the Storage Component Name node in the
document.
The Storage Component Name node contains the following sub nodes for representing various storage elements:
Fast Cache
Hosts
LUN Folders
Mirror Views
Physical
RAID Groups
Storage Groups
Storage Processor
Thin Pools
v1.6 clariion IM Configuration

performance of EMC storage platforms.
The following figure provides an overview of the process you must follow to configure a working probe.

This section describes the minimum configuration settings required to configure the clariion probe.
Follow these steps:
1. Ensure that the applicable preconfiguration requirements have been met.
Refer Preconfiguration Requirements for more information.
2. Deploy the clariion probe.
3. Provide the absolute path of naviseccli.exe in the probe.
Refer Provide the path of naviseccli.exe for more information.
4. Configure a resource for the clariion system you want to monitor.
Refer Add a clariion resource for more information.
5. Add monitors and configure the properties for the monitors.
The clariion probe requires Navisphere CLI executable (naviseccli.exe) to gather data about the clariion systems. You are required to install the
Navisphere CLI on the box where the clariion probe is deployed.
Provide the path of naviseccli.exe

Follow these steps:
2.
2. Click the Setup tab and open the Navisphere CLI section.
3. Provide the absolute path of naviseccli.exe by clicking Browse.
4. Click OK.
Add a clariion resource

Start by creating a resource to be used as a connection to the clariion system, through which the probe collects and stores data and information
from the monitored components.
Select the Default group in the left pane, right-click and select New Resource. The Resource dialog appears.
Define a resource that represents a clariion system.
Click the Test button to verify the connection to the host. You should receive a response like the one shown below.
Click the Apply button in the probe GUI to activate the new resource configuration.
The new resource should now appear under the Default group.

After the link to the clariion system is established, you can select the desired monitors (checkpoints).
Configure the properties for the monitors

The probe enables you to configure properties (such as monitor name/description, alarms, QoS messages etc.) for the monitors you have chosen
to be monitored.
When finished, click the Apply button in the probe GUI to activate the configuration.
Create a new group
You can create a new group by selecting the Create New Group button from the toolbar. The new group appears in the pane with the name New
Group.
Create a new resource

You can create a resource by selecting the group it should belong to (normally Default) and clicking the Create New Resource icon from the
toolbar.
The Resource dialog will be launched, guiding you through the process of creating a resource.

The Message Pool Manager can be opened by clicking the Message Pool Manager button in the toolbar.
text, and also create your own messages.
Note that the probe supports variable expansion in the message text. If you type a $ in the Alarm text field, a dialog pops up, offering a set of
variables to be selected:
Resource: specifies the resource mentioned in the alarm message.
Source: specifies the source where the alarm condition occurs.
Monitor: specifies the monitor (checkpoint) mentioned in the alarm message.
Descr: specifies the description of the monitor.
Key: specifies the monitor key (normally the same as the name of the monitor).
Value: specifies the value used in the alarm message.
Oper: specifies the operand to be combined with the value and the threshold in the alarm message.
Thr: specifies the alarm threshold.
Unit: specifies the unit to be combined with the value in the alarm message (for example boolean).

Templates are a useful tool for defining monitors to be measured on the various components. You can create a template and define a set of
checkpoints belonging to that template. After template creation, you can drag and drop the template on the folder where you want to monitor the
checkpoints defined for the template.
Follow these steps:
Click the Create New Template icon in the toolbar to create a template. The template dialog appears
Specify a name and a short description of the template.

The template is created.
v1.6 clariion IM Operation and Use

This article contains information on how to use the clariion probe.
Contents
Creating a Resource
Adding Monitors to be Measured
Using Templates
Editing Monitor Properties
Turning on Statistics Monitoring
Creating a Resource
You can edit the properties for a resource by right-clicking a resource and selecting Edit. This brings up the Resource dialog.
Field
Description
Resource
Name
The name of the CLARiiON system
Source
The source to be used for QoS metrics and Alarms. This is typically the IP address of Storage Processor A.
Storage
Processor A
The IP address of Storage Processor A
Storage
Processor B
The IP address of Storage Processor B
Username
A valid username to be used by the probe to access the CLARiiON system.
Password
A valid password to be used by the probe to access the CLARiiON system.
Group
Select which group you want the resource to belong to. Normally you just have the Default group.
Alarm
message
Select the alarm message to be sent if the resource does not respond. Note that you can edit the message or define your
own using the Message Pool Manager.
Check interval
The check interval defines how often the probe checks the values of the monitors.
Login Scope
The login scope for the CLARiiON system user. It is recommended to use Global or Local users for monitoring the CLARiiON
system in order to remove any dependency on an LDAP server.
Faults
When the Send Clariion Faults as Nimsoft Alarms checkbox is selected, the probe sends the alarm with severity major for
all the faults generated in the system.
Events
When the Send Clariion Events as Nimsoft Alarms checkbox is selected, the probe sends all the events whose error code
is greater than or equal to configured severity.
Minimum
Event Severity
This dropdown enables you to configure the minimum event severity.
Test button
Press the test button to verify the connection to the CLARiiON system. You should receive a response like the one shown
below.
Adding Monitors to be Measured

There are three different ways to enable monitors to be measured CLARiiON elements:
Manually selecting the monitors
This is done by maneuvering through the tree browser appearing under resource node. Selecting a folder in the tree structure, the
monitors found will be listed in the right pane of the probe GUI, enabling you to select the ones you want to monitor.
See also the section .
Using templates
Templates are a useful tool for defining monitors to be measured. See the section for further information.
Auto Configurations provide a powerful method for automatically adding monitors to be measured. "Auto Monitors" will be created for
devices that are currently NOT monitored.
Example:
When new disks are added to the CLARiiON system, the Auto Configuration feature will, if configured, create Auto Monitor(s) for the new
disks and automatically start monitoring them.
See the section for further information.
To select a monitor to be measured for a resource, select the resource in the left pane and browse the tree under the resource node. Selecting a
folder in this tree-structure, the monitors found will be listed in the right pane of the probe GUI, enabling you to select the ones you want to
monitor.
Note that you may also add monitors to be measured using templates (see the section ).
Selecting the All Monitors node, all monitors currently being measured will be listed in the right pane. Note that you can also select/deselect
monitors here.
Enabling the monitors for QoS and Alarming

You can now see the current values for the monitors in the Values column in the monitor list of the GUI. To enable the probe to send QoS data
and/or send alarms on threshold breaches, you have to modify the properties for each of the monitors. This is done by double-clicking a monitor
(or right-clicking and selecting Edit), which brings up the monitors properties dialog.
Using Templates
Templates are useful tools for defining monitors to be measured on the various elements of a CLARiiON system:
You may create templates and define a set of monitors belonging to that template. These templates can be applied to a folder or element by
dragging and dropping the template on the node in the tree where you want to measure the monitors defined for the template. You may also drop
a template on a resource in the tree structure, and the template will be applied to all elements for the resource.
Creating a template
Right-click the Templates node in the left window pane and select New.
Note that you may also edit an existing template by selecting one of the templates defined (found by expanding the Templates node and selecting
Edit).
The Template Properties dialog appears, letting you specify a Name and a Description for the new template.
Adding monitors to the template

Drag checkpoints from the right pane and drop on the template in the left pane:
You may now edit the properties for the monitors under the template as described in the section .
Applying a template
Drag and drop the template on the element where you want to monitor the checkpoints defined for the template. Note that you may also drop the
template on a folder containing multiple elements.
You will then be asked if you want to apply the template.

You may also drop a template on a resource in the tree structure, and the template will be assigned all elements under that resource structure:
Auto Configurations provide a powerful method for automatically adding monitors to be measured. "Auto Monitors" will be created for devices that
are currently NOT monitored.
Example:
When new Thin Pools are created on the CLARiiON system, the Auto Configuration feature will, if configured, create Auto Monitor(s) for the new
Thin Pools and automatically start monitoring them.
The Auto Configuration feature consists of two nodes located under the resource node in the left pane:
Auto Configurations
One or more checkpoints (or templates) can be added to this node, using drag and drop. When this is done, you must click the Apply
button and restart the probe to activate the changes.
The probe will search for the appropriate types of objects. Auto Monitors, representing the monitor(s)/template(s) added under the Auto
Configuration node will be created (and listed under the Auto Monitor node, see below) for devices that are currently NOT monitored.
NOTE: Adding many monitors/templates to the Auto Configurations node may result in a very large number of Auto Monitors
(see below).
Auto Monitors
This node lists Auto Monitors created for previously unmonitored devices, based on the contents added to the Auto Configuration node.
The Auto Monitors will only be created for devices that are currently NOT monitored.
Adding a template to the Auto Configurations node
You can add a template (see the section to learn more about templates) by selecting the Templates node in the left pane. All templates available
will now be listed in the right pane. Add a template to the Auto Configurations node by dragging the template, dropping it on the Auto
Click the Auto Configurations node and verify that the template was successfully added. Note that you must also click the Apply button and restart
Adding a monitor to the Auto Configurations node

You can add a monitor to the Auto Configurations node using drag and drop.
Monitors can be listed in the right pane by selecting the resource in the left pane and maneuvering through the tree appearing under the resource
node. Selecting a folder in this tree-structure, the monitors found will be listed in the right pane of the probe GUI.
Note that you can also list all checkpoints currently monitored, if any, in the right pane by selecting the All Monitors node.
Add the monitor to the Auto Configurations node by dragging the monitor, dropping it on the Auto Configurations node.
Click the Auto Configurations node and verify that the monitor was successfully added. Note that you must also click the Apply button and restart
Exploring the contents of the Auto Configurations node

Click the Auto Configurations node in the left pane and verify that the monitors and /or templates were successfully added. Note that you must
click the Apply button and restart the probe to activate the Auto Configuration feature.
Right-clicking in the list, selecting Edit, lets you edit the properties for the template or monitor. See the section for detailed information.
Right-clicking in the list, selecting Delete, lets you delete the template or monitor from the list.
Checking the Auto Monitors node

When templates and/or monitors have been added to the Auto Configurations node, you must click the Apply button and restart the probe to
activate the Auto Configuration feature.
The probe will then start searching through CLARiiON system.
For each element that is currently NOT monitored, an Auto Monitor will be created for each of the templates/monitors listed under the Auto
Configurations node:
Example:
Suppose you have three monitors under the Auto Configurations node; one Thin Pool related monitor and two disk related monitors. This will
result in one Auto Monitor created for each Thin Pool found and two Auto Monitors for each disk found, provided that these devices are currently
not monitored.
All Auto Monitors created will be listed under the Auto Monitors node.
Editing Monitor Properties

Edit the properties for a monitor by right-clicking it in the window and selecting Edit. When finished, you must click the Apply button to activate the
new configuration.
Field
Description
Name
This is the name of the monitor. The name will be inserted into this field when the monitor is created, but you are allowed to
modify the name.
Key
Description
This is a description of the monitor. This description will be inserted into this field when the monitor is created, but you are
allowed to modify it.
Value Definition
The current value, meaning that the most current value measured will be used.
The delta value (current - previous). This means that the delta value calculated from the current and the previous measured
sample will be used.
Delta per second. This means that the delta value calculated from the samples measured within a second will be used.
The average value of the last and current sample:
(current + previous) / 2.
Active
Enable
Monitoring
Selecting this option activates the monitoring.

Note that the monitor will also be selected in the list of monitors in the right window pane when this option is selected, and
that you can enable/disable monitoring of the checkpoint from that list.
Alarms
This tab describes the alarm properties for the monitor.

Initially the high threshold is set to a default value (or the current value. Set this value to match your needs.
The low threshold is initially disabled. If you want to use it, you must select another operator than "disabled" from the list
and configure it to match your needs.
Operator
Example:
= 90 means alarm condition if the measured value is exactly 90.
Threshold
Unit
This field specifies the unit of the monitored value.

(for example %, Mbytes etc.). The field is read-only.
Message Token
Advanced
Post with subject
Checking this option, the alarm messages for the checkpoints will be attached/posted with the displayed subject.
Publish Quality
of Service
QoS Name
Select the name to be used on the QoS message issued.
Note: Select Add New QoS Definition option from the QoS Name dropdown to add a custom QoS. Enter the
details in the QoS Definition dialog that appears and click OK.
Turning on Statistics Monitoring

In order to receive data for some performance metrics from the CLARiiON system, reporting of statistics must be enabled on the CLARiiON
system.
Statistics reporting affects metrics for disks and LUNS, such as read and write statistics for measuring throughput. If statistics reporting is not
enabled for the CLARiiON system, these metrics have a value of null in the clariion probe GUI, as in the following image.
Statistics reporting may have a slight performance impact on the CLARiiON system. Administrators may want to disable statistics reporting except
when troubleshooting the CLARiiON system.
You can determine whether such monitoring is enabled by viewing a setting in the clariion probe configuration GUI. Turning statistics monitoring
on or off is done via the command line interface for the CLARiiON system.
Note: You cannot enable or disable the collection of statistics on the CLARiiON system using the clariion probe GUI. This is because
this action is typically restricted to CLARiiON administrators.
Checking statistics monitoring status

To see whether statistics monitoring is enabled on the CLARiiON system, follow these steps:
1. In the clariion probe GUI, click on the name of a storage processor, such as SP A, in the tree.
2. View the value for the Statistics Logging metric in the right pane.
If the value is ON, statistics monitoring is enabled on the CLARiiON system.
Turning on statistics monitoring
To turn on statistics monitoring on the CLARiiON system, your CLARiiON administrator can send the following command via the Navisphere CLI
(command line interface):
naviseccli -h <array-ip> -scope 0 -user <storage system username> -pass

word <storage system password> setstats -on
v1.6 clariion IM GUI Reference

Double-click the line representing the probe in the Infrastructure Manager to bring up the GUI.
The GUI initially appears as the one shown below:
An empty group called Default Group.
The QoS node containing some QoS definitions.
The Templates node, containing the templates available.
The window consists of a row of tool buttons and two window panes. In addition, a status bar is located at the bottom of the window, showing GUI
probe version information and when the probe was started.
The left pane

The left pane shows the monitoring groups containing the resources defined and the QoS definitions. Initially the Default Group and the
standard QoS definitions are created that appear in the pane.
Groups
You can create new groups by right-clicking a group and selecting New Group (or by clicking the New Group toolbar button).
Resources
A group contains one or more resources. On this probe you normally just create one resource. This resource is configured as a link to the
clariion system. It is possible to move a resource from one group to another, using drag and drop.
Note the following icons for the Resource node:

Means the connection to the host is OK.
Means the host is not available.
Means the host is trying to connect.
Under the Resource node you will find:
The Auto Configurations sub node
One or more checkpoints (or templates) can be added to this node, using drag and drop to be used for auto configuring unmonitored
devices. See the section for further information.
The Auto Monitors sub node
This node lists Auto Monitors, created for previously unmonitored devices, based on the contents added to the Auto Configuration
node.
See the section for further information.
Templates
Templates are a useful tool for defining reusable sets of checkpoints to be monitored on the various clariion components.
You can create templates and define a set of monitors belonging to that template. Drag-and-drop the template on a node containing objects you
want to monitor.
Right-clicking the Templates node lets you add a template.
Right-clicking one of the templates defined lets you edit or delete the selected template.
The properties for a template are Name and Description.
This node contains the following default templates:

FAST Cache
LUN
Raid Groups
Storage Groups
Storage Processors
System
Thin Pools
QoS
This node contains the standard QoS definitions included with the probe package. These can be selected when editing the monitoring properties
for a monitor. To define your own QoS definitions, right-click the QoS node and select New.
Right-clicking in the pane opens a pop-up menu, displaying the following options:
When a Resource node is selected:
New Resource
New Group
Creates a new group where you may place resources. The new group will appear in the pane with the name New Group. Right-click the
new group and select Rename to give the group a name of your own choice.
Edit
Delete
Lets you delete the selected resource. Note that the Default group cannot be deleted, but if you remove all elements from the group, it will
not appear the next time you restart the probe.
Rename
Lets you delete the selected resource.
Reload
Refresh the window to display the most current measured values for the monitors.
Note: When selecting reload, you will not get updated values until the next time the probe has polled the CLARiiON system.
When a QoS node is selected:

New: Create a new QoS definition by using the QoS Definition dialog.
Delete: Delete the QoS definition.
When a Template node is selected
New: Create a new template by entering a name (required) and description (optional) in the Template Properties dialog.
Edit: Edit the description for the selected template.
Delete: Delete the selected template.
When a Group node is selected:
New Resource
New Group
Creates a new group where you may place resources. The new group will appear in the pane with the name New Group.
Edit
Delete
Lets you delete the selected group. Note that the Default group cannot be deleted, but if you remove all elements from the group, it will
not appear the next time you restart the probe.
Rename
Lets you rename the group. Note that the Default group cannot be renamed.
The right pane

The contents of the right pane depends on what you select in the left pane:
Resources when a group is selected in the left pane.
Monitors when a resource is selected in the left pane.
Note the following icons:
Monitor where no value has been measured yet.
Black: Indicates that the monitor is NOT activated for monitoring. That means that the Enable Monitoring option is not set in the
properties dialog for the monitor.
Green: Indicates that the monitor is activated for monitoring, and the threshold value defined in the properties dialog for the monitor
is not exceeded.
Other colors: Indicates that the monitor is activated for monitoring, and the threshold value defined in the properties dialog for the
monitor is exceeded. The color reflects the message token selected in the properties dialog for the monitor.
Monitor where QoS is enabled but alarms are not.
QoS definitions when the QoS sub-node is selected in the left-pane.
Right-clicking in the pane gives you the following options:

When the QoS definitions are listed in the pane:
Right-clicking in the list opens a small menu, giving you the possibility to add (New) or delete a QoS definition.
When the resources are listed in the pane:
New
Opens the Resource dialog, allowing you to define a new resource.
Edit
Opens the Resource dialog for the selected resource, allowing you to modify the properties.
Delete
Deletes the selected resource.
Activate
Activates the selected resource.
Deactivate
Deactivates the selected resource.
When the monitors are listed in the pane:
Edit
Opens the Monitor properties dialog for the selected monitor, allowing you to modify the properties.
Delete
Deletes the selected monitor.
Refresh
Note: When selecting refresh, you will not get updated values until the next time the probe has polled the CLARiiON system. This
interval is set by the Check Interval set on the properties dialog for the Resource.
The Toolbar Buttons

The General Setup button

The Create New Group button
The Create New Resource button
The Message Pool Manager button
The Create New Template button.
General Setup
Log-level: Sets the level of details written to the log file. Log as little as possible during normal operation, to minimize disk consumption.
The available options are: 0-Fatal errors, 1-Errors, 2-Warnings, 3-Information.
Enable GUI auto-refresh: When this option is selected, the GUI will be refreshed each 60 seconds. This will reflect the most current
measured values from the checkpoints and status of the nodes in the tree structure that can be seen when navigating through the clariion
system appearing under a resource node. If not selected, you are required to press the F5 button to refresh the GUI.
Note: When pressing F5 to refresh, you will not get updated values until the next time the probe has polled the clariion system. This
interval is set by the Check Interval option on the properties dialog for the Resource.
clariion Metrics
The following table describes the checkpoint metrics that can be configured using the Clariion Monitoring (clariion) probe.
Monitor Name
QoS Name
Units
Description
Version
Total Configured Storage

Capacity
QOS_STORAGE_CFG_TOTAL_CAPACITY
Gigabytes
Measures the total configured disk

capacity.
1.6
Number of LUNs
QOS_STORAGE_DISK_LUNS
Count
Measures the number of LUNs using the

disk.
1.6
Capacity
QOS_STORAGE_DISK_CAPACITY
Megabytes
Measures the capacity of the disk in

megabytes.
1.6
Percent Busy
QOS_STORAGE_DISK_PCT_BUSY
Percent
Measures the percent of time that the

disk is busy.
1.6
Percent Idle
QOS_STORAGE_DISK_PCT_IDLE
Percent

disk is idle.
1.6
Long-term Percent Busy
QOS_STORAGE_DISK_PCT_BUSY_LT
Percent
Measures the long-term percent of time

that the disk was busy.
1.6
Long-term Percent Idle
QOS_STORAGE_DISK_PCT_IDLE_LT
Percent
Measures the long-term percent of time

that the disk was idle.
1.6
Percent Rebuilt
QOS_STORAGE_DISK_PCT_REBUILT
Percent
Measures the average percent rebuilt for

the disk (for all LUNs).
1.6
Present (For Fan)
QOS_STORAGE_FAN_PRESENT
Boolean
Indicates the presence of the fan

(1=Present).
1.6
Percent Dirty SPA
QOS_STORAGE_FAST_CACHE_PCT_DIRTY_SPA
Percent
Measures the Fast Cache Percentage

Dirty for Storage Processor A.
1.6
Percent Dirty SPB
QOS_STORAGE_FAST_CACHE_PCT_DIRTY_SPB
Percent
Measures the Fast Cache Percentage

Dirty for Storage Processor B.
1.6
Size
QOS_STORAGE_FAST_CACHE_SIZE
Gigabytes
Measures the size of the fast cache.
1.6
Present (For LCC)
QOS_STORAGE_LCC_PRESENT
Boolean
Indicates the presence of the LCC

(1=Present).
1.6
Present (For IO Module)
QOS_STORAGE_IOMODULE_PRESENT
Boolean
Indicates the presence of the Input

Output Module (1=Present).
1.6
Service Time
QOS_STORAGE_LUN_SERVICETIME
Milliseconds
Measures the total time spent to serve

the request.
1.6
User Capacity
QOS_STORAGE_DISK_USER_CAPACITY
Gigabytes
Measures the disk capacity available to

users in gigabytes.
1.6
LUN Capacity
QOS_STORAGE_LUN_CAP
Megabytes
Measures the capacity of the LUN in

megabytes.
1.6
Total Hard Errors
QOS_STORAGE_LUN_HARD_ERRORS
Count
Measures the Hard errors on the LUN.
1.6
Total IOPS
QOS_STORAGE_LUN_IOPS
IO per
second
Measures the total number of IO

operations per second for the LUN.
1.6
Total Soft Errors
QOS_STORAGE_LUN_SOFT_ERRORS
Count
Measures the Soft errors on the LUN.
1.6
Percent Busy (For LUN)
QOS_STORAGE_LUN_PCT_BUSY
Percent

LUN is busy.
1.6
Percent Idle (For LUN)
QOS_STORAGE_LUN_PCT_IDLE
Percent

LUN is idle.
1.6
Percent Rebuilt
QOS_STORAGE_LUN_PCT_REBUILT
Percent
Measures the percent of the LUN that

has been rebuilt.
1.6
Trespasses
QOS_STORAGE_LUN_TRESPASSES
Count
Measures the total number of trespasses

for the LUN.
1.6
Trespassed
QOS_STORAGE_LUN_TRESPASSED
Boolean
True if this LUN is currently in a

trespassed state.
1.6
Trespasses (Past Hour)
QOS_STORAGE_LUN_TRESPASSES_PH
Count
Measures the number of trespasses for

the LUN in the past hour.
1.6
Trespasses SPA
QOS_STORAGE_LUN_TRESPASSES_SPA
Count
Measures the number of trespasses by

SP A for the LUN.
1.6
Trespasses SPB
QOS_STORAGE_LUN_TRESPASSES_SPB
Count
Measures the number of trespasses by

SP B for the LUN.
1.6
Present (For
Management Module)
QOS_STORAGE_MANAGEMENTMODULE_PRESENT
Boolean
Indicates the presence of the

Management Module (1=Present).
1.6
Actual User Capacity
QOS_STORAGE_ML_ACTUAL_USER_CAP
Megabytes
Measures the actual user capacity of the

MetaLUN.
1.6
Percent Expanded
QOS_STORAGE_ML_PERCENT_EXPANDED
Percent
Measures the percent expanded of the

MetaLUN.
1.6
Total User Capacity
QOS_STORAGE_ML_TOTAL_USER_CAP
Megabytes
Measures the total user capacity of the

MetaLUN.
1.6
Faulted
QOS_STORAGE_MIRROR_VIEW_FAULTED
Boolean
Indicates the faulted status of the

MirrorView (1=faulted)
1.6
Total Number Disks

Configured
QOS_STORAGE_NUM_OF_CONFIGURED_DISKS
Count
Measures the total number of configured

disks.
1.6
Total Number LUNs
QOS_STORAGE_NUM_OF_DEVICES
Count
Measures the total number of LUNs.
1.6
Total Number Disks
QOS_STORAGE_NUM_OF_DISKS
Count
Measures the total number of disks.
1.6
Total Number Hot Spare

Disks
QOS_STORAGE_NUM_OF_HOT_SPARES
Count
Measures the total number of hot spare

disks which are ready.
1.6
Total Number Disks

Unconfigured
QOS_STORAGE_NUM_OF_UNCONFIGURED_DISKS
Count
Measures the number of unconfigured

disks.
1.6
Present (For PSU)
QOS_STORAGE_PSU_PRESENT
Boolean
Indicates the status of the Power Supply

Unit (1=present).
1.6
Total Raw Storage

Capacity
QOS_STORAGE_RAW_TOTAL_CAPACITY
Gigabytes
Measures the total raw storage capacity.
1.6
Free Capacity
QOS_STORAGE_RG_FREE_CAP
Blocks
Measures the free capacity of the RAID

Group.
1.6
Logical Capacity
QOS_STORAGE_RG_LOG_CAP
Blocks
Measures the logical capacity of the

RAID Group.
1.6
Number of LUNs
QOS_STORAGE_RG_NUM_LUNS
Count
Measures the number of LUNs using the

RAID Group.
1.6
Percent Free
QOS_STORAGE_RG_PCT_FREE
Percent
Measures the percent of the RAID Group

that is free.
1.6
Raw Capacity
QOS_STORAGE_RG_RAW_CAP
Blocks
Measures the raw capacity of the RAID

Group.
1.6
Number of Hosts
QOS_STORAGE_SG_NUM_HOSTS
Count
Measures the number of hosts attached

to the Storage Group.
1.6
Number of LUNs
QOS_STORAGE_SG_NUM_LUNS
Count
Measures the number of LUNs in the

Storage Group.
1.6
Total Capacity
QOS_STORAGE_SG_TOTAL_CAP
Megabytes
Measures the total capacity of the

Storage Group.
1.6
Average Busy Queue

Length
QOS_STORAGE_SP_AverageBusyQueueLength
Count
Measures the average number of

outstanding requests.
1.6
Blocks Read Per Second
QOS_STORAGE_SP_BLOCKS_READ_PER_SECOND
Blocks/sec
Measures the number of blocks read per

second.
1.6
Blocks Written Per

Second
QOS_STORAGE_SP_BLOCKS_WRITTEN_PER_SECOND
Blocks/sec
Measures the number of blocks written

per second.
1.6
Total IOPs
QOS_STORAGE_SP_IOPS
Ops/sec
Measures the total number of Read and

Write operations per second.
1.6
System Fault LED On
QOS_STORAGE_SP_FAULT_ON
Boolean
Indicates whether the system fault LED

is on. (1 = ON)
1.6
Read IOPs
QOS_STORAGE_SP_READ_IOPS
Ops/sec
Measures the Storage Processor Read

Operations Per Second.
1.6
Write IOPs
QOS_STORAGE_SP_WRITE_IOPS
Ops/sec
Measures the Storage Processor Write

Operations Per Second.
1.6
Percent Busy (For SP)
QOS_STORAGE_SP_PCT_BUSY
Percent
Measures the percent of time the

Storage Processor is busy.
1.6
Percent Idle (For SP)
QOS_STORAGE_SP_PCT_IDLE
Percent
Measures the percent of time the

Storage Processor is idle.
1.6
Read Cache Enabled
QOS_STORAGE_SP_READ_CACHE_ENABLED
Boolean
Indicates the read cache status of the

Storage Processor.
1.6
Write Cache Enabled
QOS_STORAGE_SP_WRITE_CACHE_ENABLED
Boolean
Indicates the write cache status of the

Storage Processor.
1.6
Percent Dirty Cache

Pages
QOS_STORAGE_SP_PCT_DIRTY
Percent
Measures the percent of dirty cache

pages.
1.6
Percent Cache Pages

Owned
QOS_STORAGE_SP_PCT_OWNED
Percent
Measures the percent of cache pages

owned.
1.6
Response Time (For SP)
QOS_STORAGE_SP_RESPONSETIME
Milliseconds
Measures the total Storage Processor

Response Time.
1.6
Service Time (For SP)
QOS_STORAGE_SP_SERVICETIME
Milliseconds
Measures the total time spent to serve

the request.
1.6
Utilization
QOS_STORAGE_SP_UTILIZATION
Percent
Measures the percent of Storage

Processor Utilization.
1.6
Number of Faults
QOS_STORAGE_SYS_FAULTS
Count
Measures the number of faults in the

system.
1.6
Present (For SPS)
QOS_STORAGE_SPS_PRESENT
Boolean
Indicates the presence of the Standby

Power Supplies (1=Present).
1.6
Read Cache Enabled

Count
QOS_STORAGE_SYS_READ_CACHE_COUNT
Count
Measures the number of SPs with read

cache enabled.
1.6
Write Cache Enabled

Count
QOS_STORAGE_SYS_WRITE_CACHE_COUNT
Count
Measures the number of SPs with write

cache enabled.
1.6
Available Capacity
QOS_STORAGE_TP_AVAILABLE_CAPACITY
Gigabytes
Measures the available capacity of the

Thin Pool.
1.6
Consumed Capacity
QOS_STORAGE_TP_CONSUMED_CAPACITY
Gigabytes
Measures the consumed capacity of the

Thin Pool.
1.6
Oversubscribed By
QOS_STORAGE_TP_OVERSUBSCRIBED_BY
Gigabytes
Measures the amount the Thin Pool is

oversubscribed by.
1.6
Percent Subscribed
QOS_STORAGE_TP_PERCENT_SUBSCRIBED
Percent
Measures the percent of the Thin Pool

subscribed.
1.6
Percent Available
QOS_STORAGE_TP_PERCENT_AVAILABLE
Percent

available.
1.6
Percent Full
QOS_STORAGE_TP_PERCENT_FULL
Percent

full.
1.6
Relocating
QOS_STORAGE_TP_RELOCATING
Boolean
Indicates whether the thin pool is

currently relocating (1=relocating).
1.6
Subscribed Capacity
QOS_STORAGE_TP_SUBSCRIBED_CAPACITY
Gigabytes
Measures the subscribed capacity of the

Thin Pool.
1.6
User Capacity
QOS_STORAGE_TP_USER_CAPACITY
Gigabytes
Measures the User Capacity of the Thin

Pool.
1.6
Disk State
String
Measures the operational state of the

disk.
1.6
Mode
String
Indicates the fast cache mode.
1.6
State (For Fast Cache)
String
Measures the face cache state.
1.6
State (For PSU)
String
Measures the state of the power supply

unit.
1.6
State (For Fan)
String
Measures the state of the fan.
1.6
State (For LCC)
String
Measures the state of the Link Control

Cards.
1.6
State (For IOMODULE)
String
Measures the state of the Input Output

module.
1.6
State (For Management

Module)
String
Measures the state of the Management

Module.
1.6
State (For SPS)
String
Measures the state of the Standby

Power Supplies.
1.6
State (For MirrorView)
String
Measures the state of the MirrorView.
1.6
LUN Expansion Enabled
String
Indicates whether LUN expansion is

enabled for this RAID group or not.
1.6
Statistics Logging
String
Indicates whether statistics logging is

enabled or not.
1.6
Relocation Status
String
Indicates whether the thin pool is

currently relocating. (1=Relocating)
1.6
Reads IOPs
QOS_STORAGE_LUN_READ_REQUESTS_PER_SECOND
Reads/s
Measures the total number of read IO

2.1
Write IOPs
QOS_STORAGE_LUN_WRITE_REQUESTS_PER_SECOND
Writes/s
Measures the total number of write IO

2.1
Read Bandwidth
QOS_STORAGE_LUN_READ_THROUGHPUT_PER_SEC
KB/s
Measures the total read bandwidth for

the LUN.
2.1
Write Bandwidth
QOS_STORAGE_LUN_WRITE_THROUGHPUT_PER_SEC
KB/s
Measures the total write bandwidth for

the LUN.
2.1
Bandwidth
QOS_STORAGE_LUN_TOTAL_THROUGHPUT_PER_SEC
KB/s
Measures the total bandwidth for the

LUN.
2.1
State Number
QOS_STORAGE_MIRROR_VIEW_STATE_NUMBER
Number
Measures the state of the MirrorView (0

= Inactive, 1 = Active, 2 = Attention).
2.1
Blocks Read
QOS_STORAGE_SP_BLOCKS_READ
Count
Measures the total number of blocks

read.
2.1
Blocks Written
QOS_STORAGE_SP_BLOCKS_WRITTEN
Count
Measures the total number of blocks

written.
2.1
Total Reads
QOS_STORAGE_SP_READ
Count
Measures the total number of read

operations.
2.1
Total Writes
QOS_STORAGE_SP_WRITE
Count
Measures the total number of write

operations.
2.1
LUN Utilization
QOS_STORAGE_LUN_UTILIZATION
Percent
Measures the LUN utilization.
2.1
QOS_STORAGE_CFG_FREE_CAPACITY
Gigabytes
Measures the total configured disk free

capacity.
1.6
QOS_STORAGE_CFG_FREE_CAPACITY_PERCENT
Gigabytes
Measures the total configured disk free

capacity in percent.
1.6
QOS_STORAGE_CFG_USED_CAPACITY
Gigabytes
Measures the total configured disk used

capacity.
1.6
QOS_STORAGE_MIRROR_VIEW_ACTIVE
Boolean
Indicates the active status of the

MirrowView (1=active)
1.6
QOS_STORAGE_RAW_FREE_CAPACITY
Gigabytes
Measures the total raw disk free

capacity.
1.6
QOS_STORAGE_RAW_FREE_CAPACITY_PERCENT
Gigabytes
Measures the total raw disk free capacity

in percent.
1.6
QOS_STORAGE_RAW_USED_CAPACITY
Gigabytes
Measures the total raw disk used

capacity.
1.6
Bandwidth (LUN)
QOS_STORAGE_LUN_TOTAL_THROUGHPUT
KB/s
Measures the total bandwidth.
1.6
cluster (Clustered Environment Monitoring)

A cluster comprises of one or more resource groups and cluster nodes. A resource group is shared between the cluster nodes. Only one cluster
node has the control of a resource group at any given time. A resource group is a collection of shared resources like disk drives, IP addresses,
host names, and applications.
The cluster probe monitors Microsoft, Red Hat, HP-UX service guard and Veritas clusters.
The cluster probe enables failover support for a set of CA UIM probes in clustered environments. The probe configurations that are saved in a
resource group remain the same, even when that resource group moves to another cluster node. The cluster probe sends alarms when a
resource group or cluster node changes state.
Resource group states:
1 indicates Online state.
2 indicates Offline state.
3 indicates any state other than Online, and Offline.
Cluster node states:
1 indicates Up state.
2 indicates Down state.

3 indicates any state other than Up, and Down.
A resource group is visible under an active cluster node in the navigation pane that currently controls the resources. When one of the cluster
nodes fails, the control of all the resources is transferred to another functioning node. The resource group is then visible under the new functioning
node in the navigation pane. The resource group failover alarm does not get clear till the resource group moves back to the original cluster node.
Supported Probes
The following table lists the supported probes and their corresponding supported cluster environment:
Important! Use the cluster probe with other probes only when you configure the cluster probe on a robot in a clustered environment.
Supported Probe
cdm
The probe supports only disk profile monitoring on cluster version 2.20 and later.
Supported Cluster Node Configuration
Active/Passive
N+I node cluster
Note: For more information, see the Set up Cluster Monitoring in cdm section.
dirscan
unique
exchange_monitor
The probe supports only Microsoft Cluster Server (MSCS) monitoring on cluster version 1.61
and later.
logmon
Active/Active
Active/Passive
N+I node cluster
unique
nperf
unique
ntservices
unique
oracle
unique
processes
unique
sqlserver
unique
The cdm probe receives information about the cluster disk resources from the cluster probe. Monitoring profiles are created for the resources that
are based on the fixed_default settings in the cdm probe. The profile is automatically registered with the cluster probe to ensure continuous
monitoring on cluster group failover. In the cdm probe, the cluster IP is used as Alarm and Quality of Service source instead of the cluster node.
You can change the source to cluster name or group name through Infrastructure Manager (IM).
More information:
cluster (Clustered Environment Monitoring) Release Notes
v3.3 cluster AC Configuration

The CA UIM cluster probe enables failover support for profiles in the CA UIM probes. Probe profiles of standard CA UIM probes can be
associated with different resource groups and follow that group if it is transferred to another cluster node.
CA UIM supports monitoring HP-UX service guard cluster, using the cluster probe. Some important information regarding HP-UX service
guard clusters is given as follows:
Supports package failover.
A package is equivalent to a resource group.
Supports only processes, logmon, and cdm probes.
url_response probe is not supported on HP-UX service guard cluster. The url mode profiles are not functional in logmon deployed on
cluster probe.
Supports clustered drives in cdm probe if the serviceguard has veritas CFS file system.
Supports Serviceguard version A.11.19.00
Alarms are only be generated for discovered packages.
GUI only shows packages that are attached to a particular node.
The following diagram outlines the process to configure the cluster probe.
Contents
Create a Cluster Profile

Add Shared Section
Verify that required hardware and software is available before you configure the probe. For more information, see cluster (Clustered Environment

Follow these steps to set up the cluster probe:
1. Open the the cluster probe configuration interface.
2. Click the cluster node.
3. Select the cluster type (Microsoft, Red Hat, Veritas, or HP-UX service guard) that you want to monitor from the Select the Cluster Type f
ield options in the Set Up Configuration section.
Note: The Cluster Type option list depends on the platform.

Windows: Microsoft, Veritas
Linux: Red Hat, Veritas
HP-UX: HP-UX service guard
The probe can monitor only one cluster at a time.
4. Select the Cluster Name that you want to monitor.

5. Click the Save button.
Probe discovers nodes and resource groups.
Create a Cluster Profile

You need to create an associated profile for the target probe profile that you want to monitor.
Notes:
A clustered probe must be deployed on more than one node of the cluster.
Profile(s) created on these probes can have failover support from the cluster probe.
All nodes in the cluster must have the same probes with the same general configuration.
Follow these steps:

1. Click the Options (icon) in the Profiles node.
The Profile Configuration window opens.
3. Specify the name of the profile.
4. Select the probe from the list of deployed probes.
5. Select the profile where the failover support is to be monitored.
6. Click Submit.
The profile is visible under the Profiles node in the navigation pane.
Add Shared Section
Shared sections can be set up in the cluster probe to follow a Resource Group upon failover. All shared sections that the cluster probe has been
configured for, are automatically synchronized between the probes running on the different nodes in the cluster. A shared section is linked to only
the "/connections" or "/messages" section of the configuration files of the probe that runs on the node. Shared sections represent shared
resources that are defined for that resource group.
Note: Any changes to a shared section must be implemented on the probe running on the cluster node currently in control of the
associated Resource Group.
The following procedure enables you to add a shared section to a resource group on the cluster probe.
Follow these steps:
1. Click Options (icon) next to the Shared Section node in the navigation pane.
2. Select Add New Shared Section.
3. Specify the name of the section.
4. Select the probe from the list of deployed probes.
5. Select the shared section of the selected deployed probe.
6. Click Submit.
The shared section is visible under the Shared Section node in the navigation pane.

Alarms are classified by their subsystem ID, identifying the part of the system that the alarm relates to. These subsystem IDs are kept in a table
maintained by the NAS probe. If you are working on CA UIM 8.1 or earlier, you must add the subsystem IDs manually using ci_defn_pack version
1.02 or later. However, if you have upgraded to CA UIM 8.2 or later, then you do not have to add the subsystem IDs.

You are required to restart the nis_server when you deploy the ci_defn_pack.
The subsystem IDs that must be added are as follows:

Key Name
Value
1.1.16
Cluster
1.1.16.1
Node
1.1.16.2
Resource Group
1.1.16.3
Package
Note: 1.1.16.3 subsystem ID is HP-UX service guard cluster specific.
1. Open the Raw Configure interface of the nas probe.
3. Click the New Key menu item.
4. Enter the Key Name in the Add key window.
5. Click Add.
6. The new key appears in the list of keys with a blank value.
9. Click Apply.
v3.3 cluster AC GUI Reference

This article shows the GUI Reference of Clustered Environment Monitoring (cluster) probe.
Contents
cluster Node
<Node Name (selected)> Node
<Resource Group Name> Node
Profiles Node
<Profile Name> Node
<Shared Section> Node
<Shared Section Name> Node
The cluster probe enables failover support for the supported probes. The profiles of these probes can be associated with different resource
groups. The probe configurations that are saved in a resource group remain the same, even when that resource group moves to another cluster
node.
Notes:
A shared section is a common section between different monitoring profiles. The CA UIM probes get exposed to the shared
sections. The cluster probe also sends alarms when a cluster node or resource group changes state.
In case of HP_UX service guard cluster, a package is equivalent to resource group.
All cluster nodes must have the same set of CA UIM probes installed. The cluster probe updates the changes that are made to the profile setup.
When any probe profile is updated, the changes must be implemented on the probe that runs on the node which is in control of the associated
resource group. The cluster probe automatically updates most of the changes of the probe profiles. However, general probe parameters must be
updated manually on the different nodes.
The collected data must contain the name and state of the cluster nodes, the name and state of each resource group, and node on what they run.
This information is used to identify the recommended cluster node where you can run the probe configurations.
You can view the cluster node status metrics when you select any one of the available cluster nodes. However, you can view the related group
metrics only under that particular cluster node to which the group belongs.
cluster Node
This node lets you view the probe information and set the initial probe configurations.
Navigation: cluster
cluster > Probe Information
cluster > Set Up Configuration
This section lets you select the cluster type and the cluster name for the node to which you want to add the resource group. The cluster software
MSCS which stands for Microsoft Cluster Service (Windows only) or VCS which stands for VERITAS Cluster Service (Windows, Linux, Solaris,
and AIX), or RedHat Cluster Service (Linux), or Serviceguard cluster (HP_UX) is required for this probe to work.
Select the Cluster Type: specifies the type of cluster software.
Cluster Name: specifies the type of cluster node.

cluster > General Configuration
This section lets you set the log file detail level.
Default: 0-Fatal
Log Size: Specifies the maximum size (in KB) for the log file after which a new log file is created.
Default: 100 KB
Use Cluster Name as Alarm Source: uses the cluster name as the source of alarm that the probe generates. If this check box is not
selected, then the cluster node name is used as the source of the alarms.
cluster > Node Alarm Configuration
This section lets you configure the probe for generating QoS data and alarms for various performance counters. The alarms are generated when
the node changes its state.
Publish Data: generates the QoS data.
Publish Alarm: activates the alarms from the cluster node.
Message: indicates the alarm message text that comes from the cluster node.
Clear: indicates the clear message text that comes from the cluster node.
Subsystem ID: indicates the subsystem ID that comes from the Alarm Server.
Severity Up: indicates the severity level of the alarms when the node is up.
Severity Down: indicates the severity level of the alarms when the node is down.
Severity Other: indicates the alarm severity level other than high or low.
Similarly you can configure the Resource Group Alarm Configuration and Resource Group Failover Alarm Configuration sections.
This node represents one of the machines of the cluster on which the CA UIM robot is installed. You can configure the resource group properties
and the alarm properties on the active node. All cluster nodes must have the same set of CA UIM probes installed.
Note: This node is referred to as the node name (selected) node in the document and it represents an active node of the cluster. The
Admin Console GUI is initiated from the active cluster node.
Navigation: cluster > node name

node name > Resource Configuration
This section lets you configure the resource group properties.
Name: indicates the node name.
IP: defines the IP address of the node computer.
Description: defines the node description.
Check Group Interval (seconds): specifies the time interval after which the probe checks the resource group status.
Check Node Interval (seconds): specifies the time interval after which the probe checks the node status.
Note: QoS data and alarms are not generated after every check interval. They are generated on events like, probe restart, resource
group state change, or node state change.
Status: indicates the node state. Available states are: 1=online, 2=offline, 3=partially online.
This node lets you configure the properties of a resource group. A resource group comprises of shared sections and profile sections.
Note: This node is referred to as resource group name node in the document and it represents a resource group on an active cluster
node.
Navigation: cluster > node name > resource group name

resource group name > Resource Group Configuration
This section lets you configure the resource group properties:
Name: indicates the resource group name.
Description: defines a description for the resource group.
Allow Partially Online: interprets the partially online resource groups as online for the cluster probe.
Note: The profiles, or shared sections, that are created when the resource group is online, are not visible when the same group goes
offline.
Status: indicates the resource group state. Available states are: 1=online, 2=offline, 3=partially online.
Alarm messages are sent when a resource group changes its state. An alarm is sent when the state of the resource group changes (for example,
when a resource group goes from Online to Pending or from Offline to Pending).
Note: In case a resource group is detected in the FAIL state (not ONLINE), the alarm message displays which resource(s) in that group
is/are not online. In other words, the resource(s) name(s) and status are updated in the alarm message with the resource group status.
If this flag is turned ON:

Monitoring Profiles associated with a Resource Group that is NOT Online are deactivated.
Upon state change from Online to Pending:
You get an alarm from the cluster probe indicating the state of the resource group.
No alarms from other CA UIM probe monitoring profiles that are associated with this resource group (these profiles are
deactivated/removed when the state changes to Pending and is inserted/activated again when state changes back to Online).
If this flag is turned OFF:
Monitoring profiles that are associated with a resource group are kept active independently of resource group state.
No alarm from cluster probe about the state of the resource group.
Other CA UIM probes monitoring profiles that are associated with this resource group send alarms if applicable (Not considering the state
of the resource group).
Active
Alarms from the resource groups are activated when this option is checked.
Message
Here you can define the message text for alarms coming from the resource groups. The following variables can be used in the text string:
name
node
state
state_text
Clear
Here you can define the text for clear messages coming from resource groups in the cluster. The following variables can be used in the text string:
name
node
state
state_text
Subs ID
This is the NimBUS subsystem ID. The mapping is listed in the NAS (Nimsoft Alarm Server).
Severity
Defines the severity level for alarms from the resource groups. You can select different severity levels for state down, state up and other state
than up or down.
Profiles Node
This node lets you add a profile to the resource group. The profiles of various CA UIM probes are associated with different resource groups and
the configurations of these profiles are transferred with the resource group in a failover scenario.
Navigation: cluster > node name > resource group name > Profiles
Profiles > Options (icon) > Add New Profile
This option lets you add a profile to the resource group and configure its properties.
Profile Name: defines a unique profile name.
Probe: specifies the probe name that you want to associate with the resource group.
Note: Make sure that the specified probe is deployed on the cluster node.
Description: defines the description of the specified probe.

Profile: specify any one of the monitoring profiles of the probe.
<Profile Name> Node
This node lets you configure the properties of the profile that you add to a resource group.
Note: This node is referred to as profile name node in the document and it represents a profile on the resource group.
Navigation: cluster > node name > resource group name > Profiles > profile name
Refer to the Add New Profile section of the Profiles node for field descriptions.
Profile name > Options (icon) > Delete
This option allows you to delete a profile.
A shared section is a common section between different monitoring profiles. The cluster probe is configured for various shared sections that are
synchronized between the probes that run on different clustered nodes. Any change in the shared section is also applied to the probe that runs on
an active node.
A shared section is linked to only /connections and /messages section of the probe configuration file.
Navigation: cluster > node name > resource group name > Shared Section
Shared Section > Options (icon) > Add New Shared Section
This option lets you implement one or more shared sections on the probe configuration.
Shared Section Name: defines the name of the shared section.
Probe: specifies the probe name for which you want to configure the shared section.
Description: defines a short description of the specified probe.

Section: specifies one of the shared sections of the probe.
This node lets you configure the properties of the shared section that you implement on the probe configuration.
Note: This node is referred to as shared section name node in the document and it represents a shared section on the resource group.
Navigation: cluster > node name > resource group name > Shared Section > shared section name
Refer the Add New Shared Section of the Shared Section node for field descriptions.
Shared Section Name > Options (icon) > Delete
This option allows you to delete a shared section.
v3.3 cluster IM Configuration

A cluster contains one or more resource groups that are shared between the nodes (only one node has the control of a resource group at any
given time). A resource group is a collection of shared resources, such as disk drives, IP-addresses, host names, applications, etc. A resource
group is visible under an active node in the tree structure that currently controls the resources.
When one of the node(s) fails, the control of all resources is automatically transferred to another functioning node. The resource group is then
visible under the new functioning node in the tree structure on the GUI.
The CA UIM cluster probe enables failover support for the standard CA UIM probes. Probe profiles of standard CA UIM probes can be associated
with different resource groups and will then follow that group if it is transferred to another cluster node.
CA UIM supports monitoring HP-UX service guard clusters using the cluster probe. Some important information regarding HP-UX service
guard clusters is given below:
Supports processes, logmon and cdm probes.
url_response probe is not supported on HP-UX service guard cluster, hence url mode profiles will not be functional in logmon deployed
on cluster probe.
Supports clustered drives in cdm probe if the service guard has veritas CFS file system.
Supports service guard version A.11.19.00
Alarms will only be generated for discovered packages.
GUI will only show packages that are attached to a particular node.
Note: You can configure the monitoring profile on the probe, residing on the Cluster Node that is currently in control of
shared resources. These monitoring profiles are automatically uploaded to the other nodes when they gain control of the resource
group.
The following diagram outlines the process to configure the probe to monitor clusters.
Contents
Create Profile
Add Shared Section
Update NAS Subsystem ID Requirements
Verify that required hardware, software, and related information is available before you configure the probe. For more information, see cluster
(Clustered Environment Monitoring) Release Notes.
Follow these steps to set up the probe for cluster monitoring:
1. Deploy the cluster probe on the robot.
2. Double-click the probe to open the Probe Installation Wizard window.
3. Select the type of cluster (Microsoft, Red Hat, Veritas or HP-UX service guard) that you want to monitor.
Note: You need to install a separate instance of the probe for each cluster.
4. Select the name of the cluster and save the configuration.

Probe discovers nodes and resource groups.
Create Profile
You need to create an associated profile for the target probe profile that you want to monitor.
Note: The cluster probe will monitor only those probes that are already deployed on cluster node, and for which the profile(s) has been
created. Both the nodes should have same probes and general configuration. Refer the respective document of the probe(s) to create
the monitoring profile.
Follow these steps:

1. Right-click the Resource group under which you want to create monitoring profile and select New Profile. You can also select the group,
and right-click in the right pane.
1.
Notes:
This should be done on the cluster currently in control of the Resource group.
In HP_UX service guard cluster, a package is equivalent to a resource group.
The New Monitor Resource properties dialog appears.

2. Select a probe that you want to monitor from the drop-down list.
The description and configured profiles of the monitored probe are listed in the Description and Profile fields.
3. Select a profile where the failover support is to monitored from the list and then click OK.
The monitoring profiles saved in the cluster probe are automatically uploaded to the other node.
Add Shared Section

Shared sections can be set up in the cluster probe to follow a Resource Group upon failover. All shared sections that the cluster probe has been
configured for, are automatically synchronized between the probes running on the different nodes in the cluster. A shared section is linked to only
the "/connections" or "/messages" section of the configuration files of the probe that runs on the node. Shared sections represent shared
resources that are defined for that resource group.
Note: Any changes to a shared section must be implemented on the probe running on the Node currently in control of the associated
Resource Group.
Follow these steps:
1. Right-click a group and select New Shared Section.
The New Shared Section properties dialog appears.
2. Select a probe from the drop-down list.
The description and configured sections are listed in the Description and Section fields, respectively.
3. Select a section from the list and then click OK.
The sections that are saved in the cluster probe are automatically uploaded to the other node.
Update NAS Subsystem ID Requirements

maintained by the NAS probe. If you are working on CA UIM 8.1 or earlier, you must add the following subsystem IDs manually using
ci_defn_pack version 1.02 or later. However, If you have upgraded to CA UIM 8.2 or later, then you do not have to add the subsystem IDs.
Important! You can install the ci_defn_pack probe from https://support.nimsoft.com.

Key Name
Value
1.1.16
Cluster
1.1.16.1
Node
1.1.16.2
Resource Group
1.1.16.3
Package
Note: 1.1.16.3 subsystem ID is HP-UX service guard cluster specific only.
Follow these steps to update the Subsystem IDs using Infrastructure Manager:
3. Click on the New Key button.
6. Click Apply.
v3.3 cluster IM GUI Reference

This article describes the fields and features of the cluster probe.
given time). A resource group is a collection of shared resources, such as disk drives, IP-addresses, host names, applications.
Note: In case of HP_UX service guard cluster, a package is equivalent to resource group.
A resource group or a package is visible under an active node in the tree structure that currently controls the resources.
When one of the nodes fails, the control of all resources is automatically transferred to another functioning node. The resource group is then
The CA UIM Cluster probe enables failover support for the standard CA UIM probes. In HP-UX service guard cluster, package failover is also
supported. Probe profiles of standard CA UIM probes can be associated with different resource groups and will then follow that group if it is
transferred to another cluster node.
Note: CA UIM probes can also expose one or more so-called shared sections. The cluster probe also sends alarms if a cluster node or
resource group changes state.
The cluster probe is configured by double-clicking the line representing the probe in the Infrastructure Manager, which brings up the configuration
tool for the cluster probe. The configuration tool consists of a tree-structure in the left pane and a list in the right pane.
The tree detects and displays the cluster structure (Nodes > Resource groups > Resources/Shared sections). The list in the right pane changes
its contents according to the selected item in the left pane. When a Resource group is selected in the left pane, then resources/shared sections th
at are defined for that resource group is listed in the right pane.
Note the following symbols:
Note: While naming resources or resource groups, ensure that there are no preceding or trailing white spaces in the resource name.
For example, "Test<space> Group" is a valid resource name; however names such as "<space>TestGroup" or "TestGroup<space><sp
ace>" are not permissible.
In case you have resource names with preceding or trailing white spaces in the existing cluster probe configuration, the upgrade from cluster
probe version 2.3x to any higher version requires a clean install.
Cluster Properties Dialog

General Tab
Alarm Settings Tab
QoS Settings Tab
Node Properties
Restart Node
Open Log Viewer
Properties
Resource Group Properties
New Profile
New Shared Section
Properties
Configuration File Versions
You open the Cluster Properties dialog by clicking the icon in the upper left corner or by right-clicking the cluster icon in the tree-structure and
selecting Properties. You can also add and delete nodes from this right-click menu.
The dialog has three tabs:
General
Alarm Settings
QoS Settings
General Tab
The fields are:

Name
The name of the cluster
Use Cluster Name as Alarm Source
The cluster name is used as the source of alarms that are generated by probes on Nodes in the Cluster when this option is checked. If
not checked, the node name is used.
Log Level
Sets the level of details that are written to the log file.
Default: 0
Log Size
Sets the maximum size of the log file to which probe-internal log messages are written. When this size is reached, the contents of the file
are cleared.
Default: 100 KB
For more information, see section Open Log Viewer.
Alarm Settings Tab
This section lets you know how to set the alarm message properties for both Node alarms and Resource Group alarms.
The fields are:
Node Alarm Properties (Active)
These alarm messages are sent when a node changes its state (for example, the node is shut down). Alarms from the cluster nodes are
activated when this option is checked.
Message
Here you can define the message text for alarms coming from nodes in the cluster. The following variables can be used in the text
string:
name
state
state_text
Clear
You can define the text for clear messages coming from nodes in the cluster. The following variables can be used in the text string:
name
state
state_text
Subs ID
Defines NimBUS subsystem ID. The mapping is listed in the NAS (Nimsoft Alarm Server).
Severity
Defines the severity level for alarms from the nodes. You can select different severity levels for state down, state up and state other
than up or down.
Resource Group Alarm Properties (Active)
These alarm messages are sent when a resource group changes its state. The alarm is sent when the state of the resource group changes (for
example, when a resource group goes from Online to Pending or from Offline to Pending).

Monitoring Profiles that are associated with a Resource Group that are NOT Online are deactivated.
No alarm from cluster probe about the state of the resource group
Other CA UIM probes monitoring profiles that are associated with this resource group send alarms if applicable (Not considering the
state of the resource group).
Active
Message
Here you can define the message text for alarms coming from the resource groups. The following variables can be used in the text
string:
name
node
state
state_text
Clear
Here you can define the text for clear messages coming from resource groups in the cluster. The following variables can be used in
the text string:
name
node
state
state_text
Subs ID
Severity
Defines the severity level for alarms from the resource groups. You can select different severity levels for state down, state up and
other state than up or down.
Resource Group Failover Alarm Properties (Active)
These alarm messages are sent when a Resource group is moved to another node (due to a failover situation).
Active
Message
Here you can define the message text for alarms coming from the resource group if the group has been moved to another node (either
manually or due to an error situation). The following variables can be used in the text string:
name
node
state
state_text
Clear
Resource groups can be moved to another node either manually or due to an error situation. A clear message is issued when the
resource group is moved back to the original node again. Here you can define the message text. The following variables can be used
in the text string:
name
node
state
state_text
Subs ID
Displays the NimBUS subsystem ID. The mapping is listed in the NAS (Nimsoft Alarm Server).
Severity
Defines the severity level for failover alarms from the resource groups.
QoS Settings Tab
This section lets you know how the cluster probe sends QoS messages on different resource group and node states.
The fields are:
Send QoS Message
Resource Group State
Selecting this check box enables the probe to send QoS messages. These QoS messages are sent when a resource group changes
its state to online, offline, or other.
Node State
Selecting this check box enables the probe to send QoS message when the node has state up, down or other.
Node Properties
You can right-click the node and select the following actions:
Restart Node
You can restart the cluster probes on the different nodes in the cluster by right-clicking the node in the tree-structure and selecting Restart Probe.
Open Log Viewer
You can open the Log viewer window to study the log file for the cluster probe on the different nodes.
Right-click a node in the tree-structure and select View log.The Log Viewer window appears, displaying log information for the selected cluster.
Note: There are two different log files in the cluster probe directory - cluster.log and plugin.log.
Cluster.log is default log file, but the user can change to view the log file plugin.log by right-clicking the cluster probe in the Infrastructure
Manager and selecting Edit.
Change from cluster.log to plugin.log in the Log File field of the dialog and click the OK button.
Note:
Cluster.log logs the cluster probe activity, such as the communication between the cluster probes and also other tasks that are
performed by the cluster probe (sending alarms, activating/deactivating profiles for other probes etc.).
Plugin.log logs information from the cluster software (via the different plugins). This is mainly status from Nodes and Resource
Groups).
One plugin fetching information is from Microsoft Clusters and another plugin for VERITAS clusters.
Properties
The Node Properties dialog is displayed when you right-click a node icon in the tree-structure and select Properties.
After you select the Properties option, the Node properties dialog appears. The dialog has two tabs:
General
Configuration
General
The fields are:
Name
Specifies the name of the node.
Description
Specifies the description of the node.
IP Address
Specifies the IP address of the node computer.
Probe
Specifies the probe address, full path: /Domain/Hub/Node/Probe
Configuration
The Configuration tab contains options for setting check intervals for the node.
Select the Configuration tab. Specify the time interval (in seconds) for Check Group Interval (sets the check interval of the Resource groups on
the node), and Check Node Interval (sets the check interval of the Node).
You can right-click a Resource Group icon in the tree-structure and select any of the following options:
New Profile
Allows to create a monitoring profile for monitoring clusters.

New Shared Section
CA UIM probes expose one or more shared sections for the cluster probe. These sections can be set up in the cluster probe to follow a Resource
Group upon failover.

All shared sections that the cluster probe has been configured for, are automatically synchronized between the probes running on the different
nodes in the cluster.
The shared section is not removed from the probe running on the node that loses control of the resource group. Any change that is made to that
shared section is reflected in probe configurations on the node taking over control of the associated resource group.
A shared section is linked to only the "/connections" or "/messages" section of the configuration files of the probe that runs on the node. Shared
sections represent shared resources that are defined for that resource group.
Whereas, a profile is associated with the monitoring profiles of any probe that runs on the node.
Note: Any changes to a shared section must be implemented on

of the associated Resource Group
the probe running on the Node currently in control
Note: You can select all the checkpoints by clicking the option under the Section column. Alternatively, you can also select individual
checkpoints by clicking them.
Properties
Defines the Resource Group Properties.

The fields are:
Name
Defines the name of the Resource Group.
Description
Specify the description of the Resource Group
Allow 'Partially Online'
By selecting this check box, you can make the cluster probe interpret 'Partially Online' resource groups as 'Online'.
The cluster.cfg file displays version numbers and md5 values for the Cluster, Group, and Shared Disks.
You can open the cluster probe configuration file by selecting the cluster probe in the Infrastructure Manager and pressing CTRL + N keys.
When a checkpoint selected under Shared Sections is modified, the version number and md5 value of the relevant Cluster Group or Shared Disks
is updated on the node where the change has occurred.
As per the check intervals that are specified in the Configuration tab of Cluster Node Properties dialog, the version numbers and md5 values
are compared between the groups and nodes. In the case where the version numbers differ, the change is affected across the nodes.

CA UIM supports monitoring HP-UX service guard cluster, using the cluster probe. Some important information regarding HP-UX service
Supports package fail-over.
Supports only processes, logmon and cdm probes.
url_response probe is not supported on HP-UX service guard cluster, hence the url mode profiles will not be functional in logmon
deployed on cluster probe.
Supports clustered drives in cdm probe if the serviceguard has veritas CFS file system.
Supports Serviceguard version A.11.19.00
The following diagram outlines the process to configure the cluster probe.
How to set up monitoring in cluster probe

How to deploy a probe in cluster node
How to add monitoring profiles
How to Delete Monitoring Profiles
How to Add Shared Section
How to Delete Shared Section

Follow these steps:
2. Select the type of cluster (Microsoft, Red Hat, Veritas or HP-UX service guard ) from the Probe Installation Wizard.
3.
3. Select the name of the cluster and save the configuration.

4. Probe will discover nodes and resource groups
5. Create a monitoring profile on the probe(s) that is to be monitored. The probe has to be deployed on the cluster probe.
Note: Refer the respective probe(s) document to create a monitoring profile.
6. Deploy the probe(s) to be monitored in the cluster node.

Refer How to deploy a probe in cluster node.
7. Fetch the profiles of the probes that are to be monitored.
Refer How to add a monitoring profile.
8. Save the profile and start monitoring.
How to deploy a probe in cluster node

Follow these steps:
1. Navigate to the section within cluster node that you want to configure.
2. Update the required field information and
3. Save the probe.
Notes:
Each section within the node lets you configure the properties of the probe for adding resource groups to the cluster.
The monitoring profile should be created on the probe, which is already deployed on the cluster node.
How to add monitoring profiles

Follow these steps:
1. Click Options next to the Profiles tab in the navigation pane.
3. Update the required field information in the Profile Configuration dialog and click Submit.
The monitoring profile is visible under the Profiles node in the navigation pane.
How to Delete Monitoring Profiles

Follow these steps:
1. Click the Options icon next to the profile name that you want to delete.
3. Click Save.
The profile is deleted from the resource group or package in case of cluster.
How to Add Shared Section

Follow these steps:
1. Click Options next to the Shared Section node in the navigation pane.
2.

3. Update the field information in the Shared Section Configuration dialog and click Submit.
How to Delete Shared Section

If you want to disassociate a probe from the cluster probe, you can delete a shared section from the resource group.
Follow these steps:
1. Click the Options icon next to the shared section name node that you want to delete.
2. Select Delete Shared Section.
3. Click Save.
The shared section is deleted from the resource group.

maintained by the NAS probe. If you are working on NMS 7.6 or later, you must add the following subsystem IDs manually using ci_defn_pack
version 1.02 or later. However, if you have upgraded to NMS 8.2 or later, then you do not have to manually add the following subsystem IDs:
Key Name
Value
1.1.16
Cluster
1.1.16.1
Node
1.1.16.2
Resource Group
1.1.16.3
Package
Note: 1.1.16.3 subsystem ID is HP-UX service guard cluster specific.
5. The new key appears in the list of keys with a blank value.
8. Click Apply.

This article shows the GUI Reference of Clustered Environment Monitoring (cluster) probe.
Contents
cluster Node
Profiles Node
<Profile Name> Node
node.
Notes:
A shared section is a common section between different monitoring profiles. The CA UIM probes get exposed to the shared
In case of HP_UX service guard cluster, a package is equivalent to resource group.
The collected data must contain the name and state of the cluster nodes, the name and state of each resource group and on what node they run.
This information is used to identify the recommended cluster node where you can run the probe configurations.
cluster Node
Navigation: cluster
This section lets you select the cluster type and the cluster name for the node to which you want to add the resource group. The cluster software
MSCS which stands for Microsoft Cluster Service (Windows only) or VCS which stands for VERITAS Cluster Service (Windows, Linux, Solaris,
and AIX), or RedHat Cluster Service (Linux), or Serviceguard cluster (HP_UX) is required for this probe to work.
Default: 0-Fatal

Note: This node is referred to as node name (selected) node in the document and it represents an active node of the cluster. The

Check Node Interval (seconds): specifies the time interval after which the probe checks the node status
group state change or node state change.
Status: indicates the node state. 1 indicates up, 2 indicates down, and 3 indicates any other state.
node.


offline.
Status: indicates the resource group state. 1 indicates online, 2 indicates offline, 3 indicates partially online.
Alarm messages are sent when a resource group changes its state. An alarm is sent as soon as the state of the resource group changes (for
example when a resource group goes from "Online" to "Pending" or from "Offline" to "Pending").
Note: In case a resource group is detected in the FAIL state (not ONLINE), the alarm message will display which resource(s) in that
group is/are not online. In other words, the resource(s) name(s) and status are updated in the alarm message along with the resource
group status.

Monitoring Profiles associated with a Resource Group that are NOT "Online" will be deactivated.
Upon state change from "Online" to "Pending":
You will get an alarm from the cluster probe indicating the state of the resource group.
No alarms from other CA UIM probe monitoring profiles associated with this resource group (these profiles are deactivated/removed
when the state changes to "Pending" and is inserted/activated again when state changes back to "Online").
Monitoring profiles associated with a resource group will be kept active independently of resource group state.
No alarm from cluster probe about the state of the resource group.
Other CA UIM probes monitoring profiles associated with this resource group will send alarms if applicable (Not considering the state of
the resource group).
Active
Message
Here you can define the message text for alarms coming from the resource groups. The following variables can be used in the text string:
name
node
state
state_text
Clear
Here you can define the text for clear messages coming from resource groups in the cluster. The following variables can be used in the text string:
name
node
state
state_text
Subs ID
Severity
Defines the severity level for alarms from the resource groups. You can select different severity levels for state down, state up and other state
than up or down.
Profiles Node
the configurations of these profiles are transferred along with the resource group in a failover scenario.
Profiles > Add New Profile
This section lets you add a profile to the resource group and configure its properties.

<Profile Name> Node
an active node.
Shared Section > Add New Shared Section
This section lets you implement one or more shared sections on the probe configuration.
Section: specifies one of the shared section of the probe.

given time). A resource group is a collection of shared resources, such as disk drives, IP-addresses, host names, applications, etc. A resource
group is visible under an active node in the tree structure that currently controls the resources.
When one of the node(s) fails, the control of all resources is automatically transferred to another functioning node. The resource group is then
CA UIM supports monitoring HP-UX service guard clusters using the cluster probe. Some important information regarding HP-UX service
Supports processes, logmon and cdm probes.
url_response probe is not supported on HP-UX service guard cluster, hence url mode profiles will not be functional in logmon deployed
on cluster probe.
Supports clustered drives in cdm probe if the service guard has veritas CFS file system.
Supports service guard version A.11.19.00
Note: You must configure the monitoring profile on the probe, residing on the Cluster Node that is currently in control of
shared resources. These monitoring profiles will automatically be uploaded to the other nodes when they gain control of the resource
group.
The cluster probe is configured by double-clicking the line representing the probe in the Infrastructure Manager. This brings up the configuration
tool for the cluster probe. The configuration tool consists of a tree-structure on the left-hand side and a list on the right-hand side.
Note: CA UIM probes also may expose one or more shared sections, see Add New Shared section for further information. The cluster
probe will also send alarms if a cluster node or resource group changes state.
The following diagram outlines the process to configure the probe to monitor cluster probe.

How to deploy a probe on cluster node
How to add monitoring profile

Follow these steps:
2. Select the type of cluster (Microsoft, Red Hat, Veritas or HP-UX service guard ) from the Probe Installation Wizard.
3. Select the name of the cluster from the Probe Installation Wizard and save the configuration.
4. Probe will discover nodes and resource groups.
5. Create a monitoring profile on the deployed probe(s) in the cluster node.
Note: Refer the respective document of the probe(s) to create the monitoring profile.
6. Deploy the probe(s) to be monitored in the cluster node.

Refer How to deploy a probe in cluster node.
7. Fetch the profiles of the probes that are to be monitored.
Refer How to add a monitoring profile.
8. Save the profile and start monitoring.
How to deploy a probe on cluster node

Follow these steps:
1. Download the probe to be monitored.
2. Distribute the downloaded probe, on the cluster node.
Alternatively, drag the downloaded probe to the cluster node.
Notes:
Cluster will only monitor those probes for which the profile has been created.
The monitoring profile should be created on the probe, which is already deployed on the cluster node
How to add monitoring profile

Follow these steps:
1. Select the resource group under which you want to add monitoring profile and select New Profile.
Notes:
This should be done on the cluster currently in control of the Resource group.
In HP_UX service guard cluster, a package is equivalent to a resource group.

3. The description and configured profiles will be listed in the Description and Profile fields.
4. Select a profile from the list and then click OK.
The monitoring profiles saved in the cluster probe will be automatically uploaded to the other node.

maintained by the NAS probe. If you are working on NMS 7.6 or later, you must add the following subsystem IDs manually using ci_defn_pack
version 1.02 or later. However, if you have upgraded to NMS 8.2 or later, then you do not have to manually add the following subsystem IDs:
Key Name
Value
1.1.16
Cluster
1.1.16.1
Node
1.1.16.2
Resource Group
1.1.16.3
Package
Note: 1.1.16.3 subsystem ID is HP-UX service guard cluster specific only.
3. Click on the New Key button.
6. Click Apply.

v3.2 cluster IM GUI Reference

given time). A resource group is a collection of shared resources, such as disk drives, IP-addresses, host names, applications.
Note: In case of HP_UX service guard cluster, a package is equivalent to resource group.
A resource group or a package is visible under an active node in the tree structure that currently controls the resources.
The CA UIM Cluster probe enables failover support for the standard CA UIM probes. In HP-UX service guard cluster, package failover is also
supported. Probe profiles of standard CA UIM probes can be associated with different resource groups and will then follow that group if it is
transferred to another cluster node.
Note: CA UIM probes can also expose one or more so-called shared sections, see Add New Shared section for further information.
The cluster probe also sends alarms if a cluster node or resource group changes state.
If configuring CA UIM probes to monitor shared resources, configure the monitoring profile on the probe residing on the Cluster Node currently in
control of these resources. When these monitoring profiles are defined as resources in the cluster probe, then the profiles are saved in the cluster
probe. The profiles are then automatically uploaded to the other nodes when they gain control of the resource group.
The cluster probe is configured by double-clicking the line representing the probe in the Infrastructure Manager, which brings up the configuration
tool for the cluster probe. The configuration tool consists of a tree-structure in the left pane and a list in the right pane.
The tree detects and displays the cluster structure (Nodes > Resource groups > Resources/Shared sections). The list in the right pane changes
its contents according to the selected item in the left pane. When a Resource group is selected in the left pane, then resources/shared sections th
at are defined for that resource group is listed in the right pane.
probe version 2.3x to any higher version requires a clean install.
Probe Defaults
Probe Configuration

General Tab
Alarm Settings Tab
QoS Settings Tab
Node Properties
General
Configuration
Add New Shared Section
Restart Node
Open Log Viewer
Probe Defaults
Alarms, QoS, Profiles, and so on, which save time to configure the default settings. These probe defaults are seen on a fresh install, that is no
instance of that probe is already available on that robot in activated or deactivated state.
Probe Configuration
This section contains specific configuration for the cluster probe.
This dialog has three tabs:
General
Alarm Settings
QoS Settings
General Tab
The fields are:

Name
The name of the cluster
The cluster name is used as the source of alarms that are generated by probes on Nodes in the Cluster when this option is checked. If
not checked, the node name is used.
Log Level
Sets the level of details that are written to the log file.
Log Size
Sets the maximum size of the log file to which probe-internal log messages are written. When this size is reached, the contents of the file
are cleared.
Default: 100 KB
Alarm Settings Tab
This section lets you know how to set the alarm message properties for both Node alarms and Resource Group alarms.
The fields are:
These alarm messages are sent when a node changes its state (for example, the node is shut down). Alarms from the cluster nodes are
Message
string:
name
state
state_text
Clear
You can define the text for clear messages coming from nodes in the cluster. The following variables can be used in the text string:
name
state
state_text
Subs ID
Defines NimBUS subsystem ID. The mapping is listed in the NAS (Nimsoft Alarm Server).
Severity
than up or down.
These alarm messages are sent when a resource group changes its state. The alarm is sent when the state of the resource group changes (for
example, when a resource group goes from Online to Pending or from Offline to Pending).

Monitoring Profiles that are associated with a Resource Group that are NOT Online are deactivated.
No alarm from cluster probe about the state of the resource group
Other CA UIM probes monitoring profiles that are associated with this resource group send alarms if applicable (Not considering the
state of the resource group).
Active
Message
string:
name
node
state
state_text
Clear
the text string:
name
node
state
state_text
Subs ID
Severity
Active
Message
name
node
state
state_text
Clear
Resource groups can be moved to another node either manually or due to an error situation. A clear message is issued when the
in the text string:
name
node
state
state_text
Subs ID
Displays the NimBUS subsystem ID. The mapping is listed in the NAS (Nimsoft Alarm Server).
Severity
QoS Settings Tab
This section lets you know how the cluster probe sends QoS messages on different resource group and node states.
The fields are:
Send QoS Message
Node State
Selecting this check box enables the probe to send QoS message when the node has state up, down or other.
Node Properties
Note: You can also open the Log viewer (through View Log option) window or restart the Cluster probe (through Restart Probe option
) on the selected Node from this right-click menu.
General
Configuration
General
The fields are:

Name
Description
IP Address
Probe
Specifies the probe address, full path: /Domain/Hub/Node/Probe
Configuration
To check intervals of the node, follow these steps:
1. Select the Configuration tab.
2. Specify the time interval (in seconds) for Check Group Interval (sets the check interval of the Resource groups on the node) and Check
Node Interval (sets the check interval of the Node).
3. Click OK button.
Right-click a Resource Group icon in the tree-structure and select Properties. The Resource Group Properties dialog appears.
The fields are:
Name
Description
The description and configured profiles are listed in the Description and Profile fields.
The monitoring profiles that are saved in the cluster probe are automatically uploaded to the other nodes.
All shared sections that the cluster probe has been configured for, are automatically synchronized between the probes running on the different
The shared section is not removed from the probe running on the node that loses control of the resource group. Any change that is made to that
shared section is reflected in probe configurations on the node taking over control of the associated resource group.
sections represent shared resources that are defined for that resource group.
Resource Group.
Follow these steps:

The configured sections are listed in the profile window.
The sections that are saved in the cluster probe are automatically uploaded to the other nodes.
Note: You can select all the checkpoints by clicking the
option under the Section column.
Alternatively, you can also select individual checkpoints by clicking them.
Restart Node
Open Log Viewer
You can open the Log viewer window to study the log file for the cluster probe on the different nodes.
Follow these steps:
1. Right-click a node in the tree-structure and select View log.
The Log Viewer window appears, displaying log information for the selected cluster.
Note: There are two different log files in the cluster probe directory - cluster.log and plugin.log.
Cluster.log is default log file, but the user can change to view the log file plugin.log by right-clicking the cluster probe in the Infrastructure
Note:
Cluster.log logs the cluster probe activity, such as the communication between the cluster probes and also other tasks that are
performed by the cluster probe (sending alarms, activating/deactivating profiles for other probes etc.).
Plugin.log logs information from the cluster software (via the different plugins). This is mainly status from Nodes and Resource
Groups).
One plugin fetching information is from Microsoft Clusters and another plugin for VERITAS clusters.
The cluster.cfg file displays version numbers and md5 values for the Cluster, Group, and Shared Disks.
When a checkpoint selected under Shared Sections is modified, the version number and md5 value of the relevant Cluster Group or Shared Disks
is updated on the node where the change has occurred.
As per the check intervals that are specified in the Configuration tab of Cluster Node Properties dialog, the version numbers and md5 values
are compared between the groups and nodes. In the case where the version numbers differ, the change is affected across the nodes.

This section shows you the configuration details of Clustered Environment Monitoring (cluster) probe.
Contents
Configure a Node
Add Monitoring Profiles
Delete Monitoring Profiles
Add Shared Section
Delete Shared Section
Configure a Node
The following procedure provides information to configure a section within a node.

Each section within the node lets you configure the properties of the probe for adding resource groups to the cluster.
Follow these steps:
Add Monitoring Profiles

The following procedure enables you to add a profile to a resource group on the cluster probe.
Follow these steps:
1. Click Options next to the Profiles node in the navigation pane.
3. Update the field information in the Profile Configuration dialog and click Submit.
The monitoring profile is visible under the Profiles node in the navigation pane.
Delete Monitoring Profiles

If you want to disassociate a probe from the cluster probe, you can delete a profile from the resource group.
Follow these steps:
3. Click Save.
The profile is deleted from the resource group.
Add Shared Section

Follow these steps:
1. Click Options next to the Shared Section node in the navigation pane.
3. Update the field information in the Shared Section Configuration dialog and click Submit.
Delete Shared Section

If you want to disassociate a probe from the cluster probe, you can delete a shared section from the resource group.
Follow these steps:
1. Click the Options icon next to the shared section name node that you want to delete.
2. Select Delete Shared Section.
3. Click Save.
The shared section is deleted from the resource group.

This section shows the GUI Reference of Clustered Environment Monitoring (cluster) probe.
Contents
cluster Node
Profiles Node
<Profile Name> Node
node.
Note: A shared section is a common section between different monitoring profiles. The CA UIM probes get exposed to the shared
The collected data must contain the name, and state of the cluster nodes, the name, and state of each resource group, and on what node they
run. This information is used to identify the recommended cluster node where you can run the probe configurations.
cluster Node
Navigation: cluster
This section lets you select the cluster type and the cluster name for the node to which you want to add the resource group. The cluster software,
MSCS (Microsoft Cluster Service (Windows only)) is required for this probe to work.
Note: The cluster probe supports all Microsoft Cluster configurations on Windows operating systems only.

Default: 0-Fatal

Note: This node is referred to as node name (selected) node in the document and it represents an active node of the cluster. The

Check Node Interval (seconds): specifies the time interval after which the probe checks the node status
group state change, or node state change.
Status: indicates the node state. 1 indicates up, 2 indicates down, and 3 indicates any other state.
node.

offline.
Status: indicates the resource group state. 1 indicates online, 2 indicates offline, 3 indicates partially online.
Profiles Node
the configurations of these profiles are transferred along with the resource group in a failover scenario.
Profiles > Add New Profile
This section lets you add a profile to the resource group and configure its properties.

<Profile Name> Node
an active node.
Shared Section > Add New Shared Section

This section lets you implement one or more shared sections on the probe configuration.
Section: specifies one of the shared section of the probe.

given time). A resource group is a collection of shared resources, such as disk drives, IP-addresses, host names, applications, etc.
A resource group is visible under an active node in the tree structure that currently controls the resources.
The CA UIM Cluster probe enables fail-over support for the standard CA UIM probes. Probe profiles of standard CA UIM probes can be
associated with different resource groups, and will then follow that group if it is transferred to another cluster node.
Note: CA UIM probes also may expose one or more so-called shared sections, see Add New Shared Section for further information.
The cluster probe will also send alarms if a cluster node or resource group changes state.
Contents
Probe Defaults
Probe Configuration Interface Installation for cluster
Probe Configuration
General Tab
Alarm Settings Tab
QoS Settings Tab
Node Properties
General
Configuration
Restart Node
Open Log Viewer
Configuration File versions
The Cluster software, MSCS which stands for Microsoft Cluster Service (Windows only) or VCS which stands for VERITAS Cluster Service
(Windows, Linux, Solaris, and AIX), or RedHat Cluster Service (Linux) is required for this probe to work.
Each of the nodes in the cluster must have the same set of CA UIM probes installed. The cluster probe will automatically update changes to
profile setup. These changes must be implemented on the probe running on the node currently in control of the associated resource group.
General probe parameters must be updated manually on the different nodes.
The collected data must contain the name and state of the nodes, the name and state of each resource group and on what node they are running.
This information is used to manage where the different probe configurations should run and not run.
When the cdm probe runs in a clustered environment in co-operation with the cluster probe:
If the flag /disk/fixed_default/active=yes; then cdm will issue alarms about disks which no longer is available at the current node (because
it has been failed over to another node in the cluster). The cluster probe has removed the configuration, but cdm will use the default
settings and issue an alarm about the disk size being 0MB.
The solution is to set the flag /disk/fixed_default/active=no.
As mentioned previously, each of the nodes in the cluster must have the same set of CA UIM probes installed. These CA UIM probes must be
configured with setup parameters and monitoring parameters according the description of the different probes involved.
If configuring CA UIM probes to monitor shared resources, you must configure the monitoring profile on the probe residing on the Cluster Node
currently in control of these resources. When these monitoring profiles are defined as resources in the cluster probe then the profiles will be saved
in the cluster probe and will be automatically uploaded to the other nodes when they gain control of the resource group.
The cluster probe is configured by double-clicking the line representing the probe in the Infrastructure Manager. This brings up the configuration
tool for the cluster probe. The configuration tool consists of a tree-structure on the left-hand side and a list on the right-hand side.
The tree detects and displays the cluster structure (Nodes > Resource groups > Resources/Shared sections). The list on the right-hand side will
change its contents according to the selected item on the left-hand side. When a Resource group is selected on the left-hand side, then resources
/shared sections defined for that resource group will be listed on the right-hand side.
probe version 2.3x to any higher version will require a clean install.
Probe Defaults
At the time of deploying a probe for the first time on robot, some default configuration will get deployed automatically. These probe defaults could
be Alarms, QoS, Profiles and so on which save time to configure the default settings. These probe defaults will be seen on a fresh install, that is
no instance of that probe is already available on that robot in activated or deactivated state.
Probe Configuration Interface Installation for cluster

Probe Configuration
This section contains specific configuration for the cluster probe.

This dialog has three tabs:
General
Alarm Settings
QoS Settings
General Tab
The fields are:

Name
The name of the cluster.
The cluster name will be used as the source of alarms generated by probes on Nodes in the Cluster when this option is checked. If not
checked, the node name will be used.
Log Level
Sets the level of details written to the log file.
Alarm Settings Tab
This section will let you know how to set the alarm message properties for both Node alarms and Resource Group alarms.
The fields are:
These alarm messages are sent when a node changes its state (for example the node is shut down). Alarms from the cluster nodes are
Message
string:
name
state
state_text
Clear
Here you can define the text for clear messages coming from nodes in the cluster. The following variables can be used in the text
string:
name
state
state_text
Subs ID
Severity
than up or down.
These alarm messages are sent when a resource group changes its state. Note that the alarm is sent as soon as the state of the
resource group changes (for example when a resource Group goes from "Online" to "Pending" or from "Offline" to "Pending").
Note: In case a resource group is detected in the FAIL state (not ONLINE), the alarm message will display which resource(s) in that
group is/are not online. In other words, the resource(s) name(s) and status are updated in the alarm message along with the resource
group status.
Important: If this flag is turned ON:
Monitoring Profiles associated with a Resource Group that is NOT "Online" will be deactivated.
You will get an alarm from the cluster probe indicating the state of the resource group.
NO alarms from other CA UIM probes monitoring profiles associated with this resource group (these profiles will be
deactivated/removed when state changes to "Pending", and inserted/activated again when state changes back to "Online").
Monitoring profiles associated with a resource group will be kept active independently of resource group state.
NO alarm from cluster probe about the state of the resource group.
Other CA UIM probes monitoring profiles associated with this resource group will send alarms if applicable (Not considering the state
of the resource group).
Active
Message
string:
name
node
state
state_text
Clear
the text string:
name
node
state
state_text
Subs ID
Severity

Active
Message
name
node
state
state_text
Clear
Resource groups can be moved to another node either manually or due to an error situation. A clear message will be issued when the
in the text string:
name
node
state
state_text
Subs ID
Severity
QoS Settings Tab
This section will let you know how the cluster probe sends QoS messages on different resource group and node states.
The fields are:
Send QoS Message
Node State
Selecting this check box enables the probe to send QoS message when the node has state up, down, or other.
Node Properties
Note: You may also open the Log viewer (through View Log option) window or restart the Cluster probe (through Restart Probe option) on the
selected Node from this right-click menu.
General
Configuration
General
The fields are:

Name
Description
IP Address
Probe
Specifies the probe address, full path: /Domain/Hub/Node/Probe.
Configuration
To check intervals of the node, follow these steps:
1. Select the Configuration tab.
2. Specify the time interval (in seconds) for Check Group Interval (sets the check interval of the Resource groups on the node) and Check
Node Interval (sets the check interval of the Node).
3. Click OK button.

Right-click a Resource Group icon in the tree-structure and select Properties. The Resource Group Properties dialog appears.
The fields are:
Name
Description
Add Monitoring Profile
Follow these steps:
1. Select the resource group under which you want to add monitoring profile and further select New Profile.
Note: This should be done on the Cluster currently in control of the Resource group.

The description and configured profiles will be listed in the Description and Profile fields.
The monitoring profiles saved in the cluster probe will be automatically uploaded to the other nodes.

All shared sections that the cluster probe has been configured for, will automatically be synchronized between the probes running on the different
The shared section is not removed from the probe running on the node that loses control of the resource group. Any changes made to that shared
section will be reflected in probe configurations on the node taking over control of the associated resource group.
sections represents shared resources that are defined for that resource group.
Resource Group.
Follow these steps:

1.
The configured sections will be listed in the profile window.
The sections saved in the cluster probe will be automatically uploaded to the other nodes.
Note: You can select all the checkpoints by clicking the

Alternatively, you can also select individual checkpoints by clicking them.
option under the Section column.
Restart Node
Open Log Viewer

You can open the Log viewer window to study the log file for the cluster probe on the different nodes
Follow these steps:
1. Right-click a node in the tree-structure and select View log.
The Log Viewer window appears, displaying log information for the selected cluster.
NOTE: There are two different log files in the cluster probe directory - cluster.log and plugin.log.
Cluster.log is default log file, but the user may change to view the log file plugin.log by right-clicking the cluster probe in the Infrastructure
Notes:
Cluster.log logs the cluster probe activity, such as the communication between the cluster probes, and also other tasks performed by the
cluster probe (sending alarms, activating/deactivating profiles for other probes etc.).
Plugin.log logs information from the cluster software (via the different plugins). This is mainly status from Nodes and Resource Groups).
There is one plugin fetching information from Microsoft Clusters, and another plugin for VERITAS clusters.
Configuration File versions

The cluster.cfg file displays version numbers and md5 values for the Cluster, Group and Shared Disks.
When a checkpoint selected under Shared Sections is modified, the version number as well as md5 value of the relevant Cluster Group or Shared
Disks is updated on the node where the change has occurred.
As per the check intervals specified in the Configuration tab of Cluster Node Properties dialog, the version numbers and md5 values are
compared between the groups and nodes. In the case where the version numbers differ, the change is affected across the nodes.
cluster Metrics
This article describes the metrics that can be configured for the Clustered Environment Monitoring (cluster) probe.
Contents
QoS Metrics

QoS Metrics for HP-UX cluster
Alert Metrics Default Settings for HP-UX probe
QoS Metrics
The following table describes the checkpoint metrics that can be configured using the cluster probe.
QoS Name
Units
Description
Version
QOS_CLUSTER_GROUP_STATE
State
Monitors the change in the resource group state.
3.0
QOS_CLUSTER_NODE_STATE
State
Monitors the change in the node state.
3.0

This section contains the alert metric default settings for the cluster probe.
Alert Metric
Warning
Threshold
Warning
Severity
Error
Threshold
Error
Severity
Description
Node Alarm
none
minor
none
none
Node state is changed.
Resource Group
Alarm
none
minor
none
none
Resource group state is changed.
Resource Group
Failover Alarm
none
minor
none
none
Resource group has moved to another node due to failover. This alarm is not cleared
untill the resource group moves back to the original cluster node.
QoS Metrics for HP-UX cluster

The following table describes the checkpoint metrics that can be configured using the HP-UX cluster probe.
QoS Name
Units
Description
Version
QOS_CLUSTER_PACKAGE_STATE
State
Monitors the change in the package state.
3.2
QOS_CLUSTER_NODE_STATE
State
Monitors the change in the node state.
3.2
Alert Metrics Default Settings for HP-UX probe

This section contains the alert metric default settings for the cluster probe.
Alert Metric
Warning
Threshold
Warning
Severity
Error
Threshold
Error
Severity
Description
Node Alarm
none
minor
none
none
Node state is changed.
Package State
Alarm
none
minor
none
none
Package state is changed.
Package Fail
over Alarm
none
minor
none
none
Package has moved to another node due to failover. This alarm is not cleared until the
package moves back to the original cluster node.
cluster Troubleshooting
This article describes the troubleshooting steps for Clustered Environment Monitoring (cluster) probe.
Symptom:
The cluster node name and its corresponding hostname do not match. Hence the probe gives an error "The node has no valid cluster address ***"
while creating the profile/section."
Solution:
For example, you have 2 nodes with their corresponding cluster node name as lcl-node1 and lclnode2 and their corresponding hostname as
HN1 & HN2 respectively.
Follow these steps:
1. Open cluster Raw Configuration on node HN1
2. In Setup section, enter lcl-node1 key in 'node' textbox.
3. Click OK and restart the probe.
4. Follow the above steps for hostname HN2 and cluster node name lclnode2.
cm_data_import (CM Data Import)

This probe processes an XML file that describes devices and authentication profiles. Device information is added to your inventory. Authentication
profiles are accessible in the Discovery Wizard. The cm_data_import probe is usually co-located with discovery_server, typically on the primary
hub. When you run file-based import from the Discovery Wizard, cm_data_import does the work.
More information:
See the CA Unified Infrastructure Management site for information on how to Discover Systems to Monitor.
controller
The controller probe is a core component of the CA UIM robot.
Controllers schedule, start, and stop the probes that the robot manages.
Controllers keep configured probes running according to the probe configurations.
Controllers maintain contact with parent hubs and handle CA UIM operations, including hub state, name-lookup services, and licenses.
Controllers respond to directives in the robot.cfg and the controller.cfg files, and to commands issued over the
registered port TCP/48000.
Note: SSL communication mode options are more meaningful with the release of controller v7.70. The controller creates the robot.
pem certificate file during startup. The file enables encrypted communication over the OpenSSL transport layer. The treatment of
the robot.pem certificate file has changed. For details, see Impact of Hub SSL Mode When Upgrading Nontunneled Hubs in the h
ub Release Notes. Changes in treatment impact communication for:
Hubs set to mode 0 (unencrypted)
Hubs set to mode 2 (SSL only)
Hub managed components
Important! The cloning of robots is not supported. Use the cloud installation option for the robot to ensure that it starts after the
instance is created. For more information, see Install a Windows Robot in the CA Unified Infrastructure Management documentation.
More information:
Controller Release Notes
See the Robot Attribute Reference in the CA Unified Infrastructure Management documentation for information about required
and optional robot attributes.
v7.8 controller AC Configuration

This section describes the configuration information and options available through the Admin Console controller configuration UI. For an overview
of the probe, see controller. The controller probe does not require configuration after deployment. If needed, you can fine-tune the controller
configuration. The navigation pane organizes the configuration options into the following nodes:
Controller
Setup
To access the controller configuration interface, select the robot in the Admin Console navigation pane. In the Probes list, click the checkmark
icon to the left of the controller probe and select Configure.
Controller
The Controller node lets you view information about the hub and adjust settings.
Probe Information (read only) provides the probe name, start time, version, and vendor.
Hub Connectivity (read only) provides the name of the current hub, the names of the primary (parent) hub and nonprimary hub that this
robot attaches to during failover.
Identification property User Tag 1 and Identification property User Tag 2
User tags are optional values that can be attached to probe-generated messages to control access to the data in USM.
On a robot system, user tags are specified in robot.cfg.
In hub v7.80, if user tags do not exist in the hub.cfg file and the os_user_retrieve_from_robot option is true
(default):
The user tags are copied from the robot.cfg file to the hub.cfg file when the hub restarts.
After the user tags are copied, the os_user_retrieve_from_robot option is set to false in the hub.cfg file.
When the option is set to false, a user can clear the user tags in the
hub.cfg file later.
In hub v7.70, user tags on a hub system are specified in hub.cfg. User tags that are defined in robot.cfg are ignored.
Before hub v7.70, user tags on a hub system are read from
robot.cfg. Default, blank
Log Level
Sets the amount of detail to be logged in the log file
Log as little as possible during normal operation to reduce disk consumption
Increase the log level for debugging. Default, 0 - Fatal
Log Size (KB)
Change the size of the log file
When the log size is reached, new entries are added and the oldest log file entries are deleted. Default, 1024 KB
Hub update interval (minutes)
The interval at which the hub is contacted with an alive message.
The range is 1 through 180 minutes. Default, 15 minutes
The hub is notified on a shorter interval when changes occur in the probe list.
On Robot uptime, reported as state changes If this option is selected, QoS messages on robot uptime are sent.
The QoS message status = up is sent when the robot starts.
The QoS message status
= down is sent when the robot stops. Default, not selected
Set QoS source to robot name instead of computer host name
Select this option to use the robot name for the QoS source for alarms.
By default, the host name of the computer hosting the probe is used as the QoS source. Default, Enabled
Status (read only) provides information about the status of the robot.
Setup
The controller, Setup node lets you view and modify robot configuration settings.
Robot Name
The default name is the computer host name, and is auto-detected by default. Default, Auto Detect (recommended)
Secondary Hub Robot Name
If the robot parent hub is unavailable, specify the method to use to locate a temporary parent hub.
By default, the robot auto-detects the nearest active hub (recommended).
Search the subnet for a temporary hub when primary and nonprimary hubs are unavailable
Select this option to enable the robot process and port controller to search the Internet for a temporary hub. Default, Automatically
Detect (Search the subnet)
Advanced
Automatically unregister from hub on shutdown
When the robot stops, an unregister message is sent to the parent hub.
When selected, the robot disappears from Infrastructure Manager.
When not selected, the stopped robot displays a red icon, enabling the operator to detect the situation.
Suspend all probes when no network connection is available
When a robot does not have a network connection, the robot can remain active or can enter a sleep mode. In sleep mode, all
probes are suspended until a network connection is available.
If this option is not selected, the alarm messages are spooled and flushed when a network connection becomes available. Default,
selected (recommended)
Configuration file locking
Lock the configuration.
First Probe port number
Daemon type probes typically register a command port, which is allocated at runtime during probe start-up.
Use this option to specify a specific range of port numbers for router or firewall purposes. Default, 48000
Time offset from UTC (override the local time zone setting) sec
This option overrides the local time zone setting
The time specification must be entered as a time offset from UTC in seconds
When no contact with hub
An unmanaged robot is one which has lost connection with a hub. Default, Allow move only within domain (recommended)
Environment Variables
Variable Name The name of an environment variable that is defined in the robot. The robot manages the probes that inherit the
variable.
Variable Value The value that is assigned to the variable name.
Alarms
Probe restart when the probe does not respond Select the alarm to send when a probe does not respond and is restarted. Default,
no alarm
Dispatch error (internal) Select the alarm to send when there is a dispatch error for the probe. Default, major
Max restart attempts reached for the probe Select the alarm to send when the maximum number of restart attempts are reached.
Default, major
Error starting probe Select the alarm to send when there is an error starting the probe. Default, major
Timed probe not finished at the next start time Select the alarm to send when a timed probe is not complete at the next start time.
Default, warning
Timed probe did not return 0 on termination Select the alarm to send when the probe does not return a value of 0. Default, warning
Probe unregisters port but keeps running Select the alarm to send when a running probe unregisters the port. Default, major
Probe distribution request error Select the alarm to send when there is an error during probe distribution. Default, major
Distribution post-install error Select the alarm to send when there is an error after the probe is distributed and installed. Default, no
alarm
Time interval at which alarm will be resent (minutes) Select the number of minutes elapsed before resending an alarm. Default, 0
Virtual Remote probes install and run on computers without a robot. The remote probe is configured with the path to the robot. Virtual en
ables the controller to set up the communication between the robot and the virtual probe running a remote probe. Virtual robots, using the
proxy probe, are created for remote probes.
Important! The Netware System probe is the only probe that can be set up on a virtual robot.
NAT lets you allocate an external IP address to a robot residing on an IP network with addressing which is incompatible to the hub. The
robot is able to send alarms and QoS messages. The hub is not able to communicate with the robot. When Network Address Translation
(NAT) is used, the robot must be configured to provide the correct address to the hub. All communication from the hub to the robot uses
this address. NAT can be set for the primary and the nonprimary hubs.
IP of the Robot as seen from the primary hub - Enter the name of the robot as shown in the primary hub configuration. Default,
Re
al_IP
IP of the Robot as seen from the secondary hub - Enter the name of the robot as shown in the secondary hub configuration.
Default, Real_IP
IP
Robot IP Address - Select the option for detecting the IP address, either automatically detect or enter a specific hub address.
IP version support - Select the IP version support for the robot.
Local IP validation - Select this option to perform local IP validation.
Data origin
Origin - Enter the origin name to associate with the robot.
Note: Changing the origin might cause probes (other than hub, controller, and spooler) to restart to pick up the changes.
Marketplace Settings
Marketplace Username - The username that is used to run the marketplace probes.
Important! The username applies to all marketplace probes on the same robot. We highly recommend that you do not use
the root or the Administrator account. Grant to the marketplace user the least privileges required to run the probes.
Changing the marketplace settings might cause marketplace probes to start or restart to pick up the changes.
Password (Windows Only) - The password for the marketplace username

Passive Mode Required - The robot must be in passive mode for the marketplace probes to run. Default, Selected
Important! If the controller is not in passive mode, select Passive Mode Required. If passive mode is not required, the
robot allows marketplace probes to run anyway. For security reasons, we highly recommend that marketplace probes run
on passive robots. Changing the marketplace settings might cause marketplace probes to start or restart to pick up the
changes.
Note: Use Infrastructure Manager to convert a controller to passive mode.
v7.8 controller IM Configuration

This article describes the Infrastructure Manager controller configuration UI, and provides information about advanced configuration. To open the
UI, double-click the controller probe in the Infrastructure Manager. For an overview, see controller.
Setup
Nimsoft
Misc
Advanced
Environment
Virtual
Alarm
NAT
IP
Status
Advanced Configuration
Using DNS Names for the Hub Server in robot.cfg
Limiting the Number of Open Ports
Robot Maintenance Mode
Setup
Nimsoft
Set up the robot and a secondary failover hub in the Nimsoft tab.
The tab contains two sections:

Robot Name - attaches to the parent hub when the hub is active.
Note: if the Search the subnet for a temporary hub option is selected, this option changes to the Automatically detect option.
Automatically detect (searches the subnet) - the robot searches the subnet for a responding hub within the domain when the
parent and secondary hubs are unavailable.
Note: This option is displayed if the Search the subnet for a temporary hub option is selected.
Specify Hub (IP/name) - the robot attaches to the hub specified by IP address or host name
Specify Hub (domain name) - the robot attaches to the hub within the specified CA UIM domain
Search the subnet for a temporary hub when primary and secondary hubs are unavailable - If the parent and secondary hubs
are unavailable, the robot searches the subnet for a failover hub
Note: Selecting this option changes the Wait for the primary hub to become available option to the Automatically
detect (searches the subnet) option.
Misc
Use the Misc tab to set logging information, identification properties, quality of service, and the robot interaction mode.
Identification properties - specify User tag 1 and User tag 2. User tags are user-defined tags which are used as a grouping and
locating mechanism. The tags display in various lists in Infrastructure Manager.
Log Level - set the amount of detail to be logged to the log file. Log as little as possible during normal operation to reduce disk
consumption. Increase the level of detail when you are debugging.
Log Size - change the maximum size of the log file. The default size of the log file is 1024 KB.
Hub update Interval - the interval, in minutes, the hub is contacted with an alive message. The range is 1 through 180 minutes. The
hub is notified at a shorter interval when changes occur in the probe list.
Quality of Service Robot mode - select normal or passive. Passive robots do not initiate the communication with a hub. The hub
initiates all contact with the robot.
On Robot uptime, reported as state change - sends QoS messages for robot up time. The QoS message status
sent when the robot starts, and status
= up is
= down is sent when the robot stops.
Set QoS source to robot name instead of computer hostname - use the robot name that is specified on the Setup, Nimsoft tab.
Note: This option is disabled unless the Set specific name (override) option is selected on the Setup, Nimsoft tab.
Advanced
Use the Advanced tab to set robot options, and the data origin.
Robot options - set options for the robot:

Automatically unregister from HUB at shutdown
When the robot is stopped, an unregister message is sent to the hub on which it is registered. The robot disappears from
Infrastructure Manager. If this option is not selected, the robot appears with a red icon, enabling the operator to detect the situation.
When the robot does not have a network connection, specify whether the robot is in active mode or sleep mode. In sleep mode, all
probes are suspended when a network connection is not available. If this option is not selected, the alarm messages are spooled and
flushed when a network connection becomes available.
First probe port number
Daemon type probes typically register a command port. The port is allocated at run time during probe startup. Setting the probe port
number makes the robot allocate specific port numbers for the probes as they start. Use this option to allocate probe port numbers in
a specific range for router and firewall purposes.
Time offset from UTC
Use this option to override the local time zone setting. Enter the time specification as a time offset from UTC in seconds.
When no contact with hub - An unmanaged robot is a robot that has lost contact with the parent hub. This option sets limitations on
attempts to connect to a hub, using the Tools, Connect Robot option in Infrastructure Manager.
Data Origin (override origin set by the Hub) - specify the Origin. The origin is a string that is attached to QoS data from probes. The
origin identifies the originator of the data. The default origin is the name of the parent hub.
Environment
The robot controller reads the variable, value pair in the list and inserts it into the robot environment. The probes inherit the environment from the
robot.
You can add, edit, or delete environment variables. Right-click and select the appropriate menu option. Only add environment variables that all
probes on the robot use.
Virtual
Virtual robots are robots for probes that are installed on computers lacking a local robot. Probes of this type are named remote probes. The Virtua
l tab lists the virtual robots.
The netware probe is the only probe that can be set up on a virtual robot.
The proxy probe creates virtual robots for remote probes. The configuration of the remote probe determines which virtual robot to use.
In Infrastructure Manager, the remote probe appears as a probe on a virtual robot.
To add user tags for a virtual robot:
1. Select the hub in Infrastructure Manager. The robots are listed in the main window.
The Version column identifies the virtual robots.
In the following example, lab
5 is a virtual robot on xpkost. The robot xpkost serves the virtual robot lab 5.
2. Right-click the xpkost robot in the navigation pane, and select Properties to open the controller configuration tool.
3. Select the Setup, Virtual tab. Right-click to define user tags for the virtual robot.
Alarm
The controller issues alarms for error conditions. The Alarm tab lists the internal alarm messages. Select the severity level for each alarm
message. You can select no alarm for the condition Probe restart when the probe does not respond.
Time interval at which alarms will be resent - the time interval in minutes between alarms which are sent for an error condition.
If this field is left blank, the controller does not resend the alarms.
NAT
Use the Network Address Translation (NAT) feature to allocate an external IP address to a robot. Use NAT when the network addresses of the
hub and robot are incompatible.
Use the Setup, NAT tab to setup NAT.
If the robot and the hub are separated by a NAT device, the robot can send alarms and QoS messages. The hub cannot respond. To solve the
problem, set up static NAT mappings for each robot behind the NAT device. Use Raw Configure to add the key robotip_alias to the
controller section of the robot.cfg file on the robot.
connects to the hub.
robotip_alias sets the IP address that is registered when the robot
robotip_alias specifies the static NAT to IP address mapping. The hub and the clients on the other side of the NAT device use the
mapping to access the robot. For example:
<controller>
robotip_alias = 193.71.55.153
...
<\controller>
IP
Use the IP tab to configure the IP information for the robot.
Robot IP address:
Automatically detect
The host IP address is used
Set specific address(es) (override)
Specify an IP address or set of IP addresses for the robot. An override is typically used when a host has more than one network
interface.
Separate multiple IP addresses with a comma. IP addresses can contain asterisk wildcards.
Valid entries:
198.2.3.5, 138.3.4.10
198.2.*.*, 138.3.4.10
The controller and the probes it starts only listen for connections on the NIC addressed by
ses, the controller and the probes listen on
198.2.
If there are no 198.2 addres
138.3.4.10
IP version support - Select the IP version that you are using

Local IP validation - When this option is enabled, and the robot IP address is not set to localhost, the robot IP address is
checked against a list of known, valid IP addresses for that server before it is used.
IP binding:
Listen only on the first valid address from configured IP addresses
This option is available when an override robot IP address is specified. If servers have multiple NICs, the controller only listens on the
specific IP address on servers with multiple NICs.
Status
Robot name
The actual or current name of the robot
Robot IP address
The actual or current IP address of the robot
Robot version
The version of the robot
Op. Sys.
Operating system name
Op. Sys. type
The type of the operating system (UNIX, Windows)
Op. Sys descr
Operating system description
Indicator and status information
The status indicator, together with a status message, gives information about the current controller status.
Green - OK
Red - error condition
Right-click the indicator to put the robot into maintenance mode for the period specified.
Installed packages
The Installed Packages button opens a window which lists all the packages which are installed on the robot.
Robot environment
The Robot Environment button opens the Environment window, which displays the variables and values for the computer running the
robot.
Note: Any probes that the robot starts inherit the environment.
Hub connectivity
Display the current, primary, and nonprimary hubs
Using DNS Names for the Hub Server in robot.cfg
Version 2.80 or higher of the controller, allows the DNS name of the hub server to be used in the
robot.cfg file in two ways:
use the full DNS name instead of the IP address in the hubip parameter
use the full DNS name in the hub_dns_name parameter
Use the full DNS name of the server as the hubip parameter to allow the robot to recognize the main hub and return to it after a failover.
The robot move operation replaces the hubip parameter with an IP address. If the DNS server is down, the robot can fail over to a different
hub.
Use the full DNS name in the parameter hub_dns_name to allow the robot to use the hub_dns_name to look up the hub IP address. If
the lookup fails, the hubip parameter is used. When the DNS name lookup is successful, and the IP address is different from the hubip par
ameter, the parameter is replaced.
The same functionality is available for the secondary hub, using the secondary_hub_dns_name parameter.
The
hub_dns_name is lost on a robot move.
the secondary_hub_dns_name is lost when the controller configuration tool changes the secondary hub.
<controller>
hubip =
hub_dns_name =
secondary_hub_dns_name =
</controller>

Set the proxy_mode key in the robot.cfg to limit the number of open ports in the environment (for example, in a network with a
firewall).
In the
robot.cfg, set proxy_mode = 1 to send all the traffic through a specific port, for example, port 48000.

Controller version 2.80 or higher supports maintenance mode. Right-click one or more robots in the Infrastructure Manager main window and
select Maintenance to put the selected robots into maintenance mode for the period specified.
The robot stops all probes and stops sending messages. The robot does a full restart, and only starts the core components ( controller, s
pooler, hdb, hub, distsrv, nas, and proxy). Any other probes are suspended while the robot is in maintenance mode.
When the maintenance mode is invoked, supply the stop time for the maintenance mode. When the stop time is reached, the robot returns to
normal operation. Any suspended probes are restarted.
Probe distribution and activation can be performed while the robot is in maintenance mode. When the maintenance mode is complete, the
affected probes are started.

This section describes the configuration information and options available through the Admin Console controller configuration GUI. For an
overview of the probe, see controller. The navigation pane organizes configuration into the following nodes:
Controller
Setup
To access the controller configuration interface, select the robot in the Admin Console navigation pane. In the Probes list, click the arrow to the
left of the controller probe and select Configure.
Controller
The Controller node lets you view information about the hub and adjust log file settings.
Probe Information (read only) provides the probe name, start time, version, and vendor.
Hub Connectivity (read only) provides the name of the hub, the names of the primary (parent) hub and secondary hub that this hub's
robots will attach to during failover.
General Configuration lets you configure the following items.
Identification property User Tag 1 and Identification property User Tag 2: User tags are optional values that can be attached to
probe-generated messages to control access to the data in USM. On a robot system, user tags are specified in robot.cfg. As of hub
v7.70, user tags on a hub system are specified in hub.cfg, and user tags defined in robot.cfg are ignored. Prior to hub v7.70, user tags
on a hub system were read from robot.cfg. Default: blank
Log Level: Sets the amount of detail to be logged to the log file. Log as little as possible during normal operation to reduce disk
consumption, and increase the level of detail when debugging. Default: 0 - Fatal
Log Size (KB): Allows you to change the size of the log file according to your needs. When the log file size is reached, new entries
are added and the oldest log file entries will be deleted. Default: 1024 KB
Hub update interval (minutes): Determines at what interval the hub is contacted with an "alive" message. The range is 1 to 180
minutes. Note that the hub is notified on a shorter interval when changes occur in the probe list.
On Robot uptime, reported as state changes: If this option is selected, QoS messages on robot uptime will be sent. The QoS
message status = up is sent when the robot starts, and status = down is sent when the robot stops.
Set QoS source to robot name instead of computer host name: Select this option to use the robot name for the QoS source when
sending alarms. By default, the host name of the computer hosting the probe is used as the QoS source. Default: Disabled
Status provides the status of the robot and is read-only.
Setup
Th controller > Setup node lets you view and modify robot configuration settings.
Nimsoft lets you specify:
Robot Name: The default name is the computer host name, and is auto-detected by default (recommended). Default: Auto Detect
(recommended).
Secondary Hub Robot Name: Defines the method used to locate a temporary parent hub if the robot's own parent hub is
unavailable. By default, the robot will auto-detect the nearest active hub (recommended).
Search the subnet for a temporary hub when primary and secondary hubs are unavailable: Select this option to enable the
robot process and port controller to search the internet for a temporary hub. Default: not selected.
Advanced lets you specify:
Automatically unregister from hub at shutdown: When the robot is stopped, an unregister message is sent to the hub on which it
is registered. This will make the robot disappear from Infrastructure Manager. If this is not selected, the stopped robot will appear with
a red icon, enabling the operator to detect the situation.
Suspend all probes when no network connection is available: When running the robot on a computer with no network connection,
you can determine whether the robot should be active or enter a sleep mode where all probes are suspended until a network
connection is again available. If this option is not selected the alarm messages will be spooled and flushed when a network connection
is again available. Default: selected (recommended).
Note: This function is available only on Windows platforms.
Configuration file locking: Locks the configuration.

First Probe port number: Daemon type probes normally register a command port, which is allocated run-time on probe start-up.
Setting the probe port number makes the robot allocate specific port numbers for the probes as they are started. Use this option if you
want the probes to have port numbers in a specific range for router or firewall purposes.
Time offset from UTC (override the local time zone setting) sec: Overrides the local time zone setting. The time specification must
be entered as time offset from UTC (in seconds).
When no contact with hub: Set limitations for attempts to connect an unmanaged robot (a robot that has lost the contact with the
hub) to a hub.
Default: Allow move only within domain (recommended)
Variable Name: Environment variable for your UIM system. This variable is inherited by all the probes managed by this robot.
Variable Value: The value assigned to the variable name.
Alarms
Probe restart when the probe does not respond: Select the alarm to be sent when a probe is not responding and is restarted.
Dispatch error (internal): Select the alarm to be sent when there is a dispatch error for the probe.
Max restart attempts reached for the probe: Select the alarm to be sent when the maximum restart attempts have been reached.
Error starting probe: Select the alarm to be sent when there is an error starting the probe.
Timed probe did not return 0 on termination: Select the alarm to be sent when the probe does not return a value of 0.
Probe unregisters port but keeps running: Select the alarm to be sent when the probe unregisters the port but continues to run.
Probe distribution request error: Select the alarm to be sent when there is an error during probe distribution.
Distribution post-install error: Select the alarm to be sent when there is an error after the probe is distributed and installed.
Time interval at which alarm will be resent (minutes): Select the length of time (in minutes) when an alarm will be resent.
Virtual enables the controller to set up the communication between the robot and the virtual probe running a remote probe. Virtual
robots, using the proxy probe, will be created for 'remote' probes. remote probes are installed and running on computers without a robot.
The remote probe is configured with the path to the robot.
NAT lets you allocate an external IP address to a robot that resides on another IP network with incompatible addressing. The robot will
be able to send alarms and QoS messages, but the hub will not be able to communicate back to the robot. When Network Address
Translation (NAT) is in effect between the robot and the hub, the robot must be configured to provide the correct address to the hub. All
communication from the hub to the robot will use this address. NAT can be set for the primary and secondary hubs.
IP of the Robot as seen from the primary hub: Enter the name of the robot as shown in the primary hub configuration.
IP of the Robot as seen from the secondary hub: Enter the name of the robot as shown in the secondary hub configuration.
IP
Robot IP Address: Select the option for detecting the IP address, either automatically detect or enter a specific hub address.
IP version support: Select the IP version support for the robot.
Local IP validation: Select this option if you want local IP validation performed.
Data origin
Origin: Enter the origin name you would like associated with this robot.
Update button: Click this button to update the origin name associated with this robot.

This article describes the Infrastructure Manager controller configuration GUI and provides information on advanced configuration. To open the
GUI, double-click the controller probe in the Infrastructure Manager. For an overview of the probe, see controller.
See the following topics for details:
Setup
Nimsoft
Misc
Advanced
Environment
Virtual
Alarm
NAT
IP
Status
Using DNS Names for the Hub Computer in robot.cfg
Setup
The Setup tab contains the following sections:
Nimsoft
Misc
Advanced
Environment
Virtual
Alarms
NAT
IP
Nimsoft
The Nimsoft tab allows you to set up the robot and a secondary hub.

Robot Name
Automatically detect uses the system host name as the robot name.
Set specific name (override) lets you specify the robot name to be used.
Secondary HUB defines the method used to determine the secondary hub. The secondary hub will be used if the primary hub is
unavailable. Options are:
Wait for primary hub to become available prevents the robot from attaching to another hub. It will attach to its parent hub when the
hub is active.
Note: This option is replaced by the Automatically detect option if the Search the subnet for a temporary hub option is
selected.
Automatically detect (searches the subnet) allows the robot to search the subnet for a responding hub within the domain when the
Specify Hub (IP/name) allows the robot to attach to the specified hub.
Specify Hub (domain name) allows the robot to attach to the specified hub.
Search the subnet for a temporary hub when primary and secondary hubs are unavailable allows the robot to search for a
temporary hub if the parent and secondary hubs are unavailable. Selecting this option changes the Wait for the primary hub to
become available option to Automatically detect (searches the subnet) option.
Misc
The Misc tab allows you to set logging information, identification properties, quality of service and robot interaction mode.
Identification properties lets you specify User tag 1 and User tag 2, which are user-defined tags to be used as a grouping/locating
mechanism. The tags are displayed in various lists in Infrastructure Manager.
Log Level sets the amount of detail to be logged to the log file. Log as little as possible during normal operation to reduce disk
consumption, and increase the level of detail when debugging.
Log Size allows you to change the size of the log file according to your needs. The default size of the log file is 1024 KB.
Hub update Interval determines at what interval the hub is contacted with an "alive" message. The range is 1 to 180 minutes. Note that
the hub is notified at a shorter interval when changes occur in the probe list.
Quality of Service:
On Robot uptime, reported as state change sends QoS messages on robot uptime. The QoS message status = up is sent when the
robot starts; status down is sent when the robot stops.
Set QoS source to robot name instead of computer hostname uses the robot name specified on the Setup > Nimsoft tab.
Note: This option is disabled unless the Set specific name (override) option is selected on the Setup > Nimsoft tab.
Robot mode is normal or passive. Passive robots cannot initiate communication with a hub. All contact must be initiated by the hub.
Advanced
The Advanced tab allows you to set robot options and the data origin.
Robot options allows you to set options for the robot:

When the robot is stopped, an unregister message is sent to the hub on which it is registered. This will make the robot disappear from
Infrastructure Manager. If this is not selected, the stopped robot will appear with a red icon, enabling the operator to detect the
situation.
When running the robot on a computer with no network connection, you can determine whether the robot should be active or enter a
sleep mode where all probes are suspended until a network connection is again available. If this option is not selected the alarm
messages will be spooled and flushed when a network connection is again available.

Daemon type probes will normally register a command port, which is allocated run-time on probe start-up. Setting the probe port
number will make the robot allocate specific port numbers for the probes as they are started. Use this option if you want the probes to
have port numbers in a specific range for router / firewall purposes.
This option lets you override the local time zone setting. The time specification must be entered as time offset from UTC (in seconds).
When no contact with hub sets limitations for attempts to connect an unmanaged robot (a robot that has lost the contact with its hub) to
a hub, using the Tools > Connect Robot option in Infrastructure Manager. The options are:
Do not allow robot to be moved
Allow move only within domain
Data Origin (override origin set by the Hub) lets you specify the Origin, which is a string attached to QoS data from probes to identify
the origin of the data. The default origin is the name of the parent hub.
Environment
The robot controller will read the variable/value pair in the list and insert it into the robot environment. This environment is inherited by the probes
managed by the robot.
You can add, edit or delete these environment variables by right-clicking in the screen and selecting the appropriate menu option. Only add
environment variables that you want all probes on this robot to use.
Virtual
This tab lists virtual robots served by the robot controller. The netware probe is the only probe that can be set up on a virtual robot.
Virtual robots will, via the proxy probe, be created for remote probes (probes installed and running on computers without a robot). The remote
probe is configured to know which robot to be served by.
In Infrastructure Manager, the remote probe will appear as a probe on a virtual robot.

1. Select the hub in Infrastructure Manager, and the robots will be listed in the Main Window.
The Version column will notify if it is a virtual robot or not.
In the example below, lab 5 is virtual on xpkost, which means that the robot xpkost serves the virtual robot lab 5.
2. Right-click the xpkost robot in the Navigation Pane and select Properties to bring up the controller configuration tool.
Now you may select the Setup > Virtual tab, right-click and define user tags for the virtual robot.
Alarm
This tab contains the internal alarm messages issued by the controller on the different error situations that may occur. You are allowed to select
the severity level for each alarm message. For the condition Probe restart when the probe does not respond, you can also select that no alarm
message is issued.
The option Time interval at which alarms will be resent defines the time interval in minutes between alarms being sent on an error condition.
If this field is left blank, the controller will never attempt to resend the alarms.
NAT
The feature allows you to allocate an external IP address to a robot that resides on another IP network with incompatible addressing.
This tab contains the setup for NAT (Network Address Translation).
If the robot is separated from the hub by a NAT (Network Address Translation) device, the robot will be able to send alarms and QoS messages,
but the hub will be unable to communicate back. One solution is to setup static NAT mappings for each robot behind the NAT device. Using Raw
Configure, you can then add the key robotip_alias to the controller section of the robot.cfg file on the robot computer. This key changes the IP
address that gets registered when the robot initially connects to the hub.
The key robotip_alias should specify the static NAT mapping IP address that the hub and the clients on the other side of the NAT device should
use to access the robot. For example:
<controller>
...
<\controller>
IP
The IP tab allows you to configure the IP information for this robot.
Robot IP-address:
The host IP address will be used.

Specify an IP-address or set of IP-addresses for the robot. This is typically used when a host has more than one network interface.
For more than one IP-address, the addresses must be separated by a comma. IP addresses can also contain wildcards (*).
Valid entries:
198.2.3.5, 138.3.4.10
198.2.*.*, 138.3.4.10
The controller and all probes it starts only listen for connections ON their NIC attached to addresses that start 198.2. If there are not
any addresses then they would listen ON 138.3.4.10.
IP version support Select the appropriate IP version you are running.
Local IP validation With this option enabled, if the robot IP address is not set to localhost, it is checked against a list of IP addresses
that are known valid for that server before it is used.
IP-binding:
You can only select this option if you set a specific address in the Robot IP-address section of this screen. The controller will only list
ON a specific IP address on servers with multiple NICs.
Status
This section describes the properties for the Status tab.
Robot name
The actual/current name of the robot.
Robot IP-addr.
The actual/current ip-address of the robot.
Robot version
The version of the robot.
Op. Sys.
Operating system name.
Op. Sys. type
The type of the operating system (UNIX/Windows etc.).
Op. Sys descr
Operating system description.
The status indicator will, together with a status message, give information about the current controller status (Green icon means OK, Red
icon means an error situation).
Right-clicking on the indicator lets you set the robot into maintenance mode for the period specified. See the section for more information.
Installed packages
Lists all packages installed on the robot in a separate window.
Robot environment
Opens the Robot Environment window. This window displays the variables and values for the computer running the robot.
Note: The values are inherited by any probe started by this robot.
Hub connectivity
Displays the current, primary and secondary hubs.
Version 2.80 or higher of the probe allows the DNS name of the hub machine to be used in the robot.cfg file in two ways: using the full DNS name
instead of the IP address in the hubip parameter or using the full DNS name in the hub_dns_name parameter.
Using the full DNS name of the computer instead of the IP address (as the hubip parameter) allows the robot to recognize its main hub and return
to it after a failover situation.
The hubip parameter will be replaced by an IP address on a robot move operation. The robot can fail over to a different hub if the DNS is down.
Using the full DNS name in the parameter hub_dns_name allows the robot to attempt to use the hub_dns_name to look up the hub IP address. If
this fails, the hubip parameter is used. When the DNS name lookup is successful and the ip address found is different from the hubip parameter,
this parameter is replaced.
Note that the hub_dns_name is lost on robot move and secondary_hub_dns_name is lost on change of secondary hub initiated by the controller
configuration tool.
<controller>
hubip =
hub_dns_name =
</controller>

You can limit the number of open ports in your environment (for example, in a network with a firewall) by setting the proxy_mode key in the robot.c
fg.
In the robot.cfg, set the proxy_mode = 1 to send all the traffic through a specific port, for example, port 48000.

Controller version 2.80 or higher supports maintenance mode. Right-clicking one or more robots in the Infrastructure Manager main window pane
and selecting Maintenance, lets you set the selected robot (s) into maintenance mode for the period specified.
The robot will stop all probes and stop sending messages. The robot does a full restart and only starts the core components ( controller, spooler, h
db, hub, distsrv, nas and proxy ). In Infrastructure Manager the probe icon of other probes will indicate that these probes are suspended while the
robot is in maintenance mode.
On entering maintenance mode, the end time of the maintenance mode period must be given. When this time is reached the robot will go back to
normal operation and start up any suspended probes.
Probe distribution and activation can be performed while the robot is in maintenance mode, however the affected probes will be suspended and
not actually started.

This section describes the configuration information and options available through the Admin Console controller configuration GUI. For an
overview of the probe, see controller. The navigation pane organizes configuration into the following nodes:
Controller
Setup
To access the controller configuration interface, select the robot in the Admin Console navigation pane. In the Probes list, click the arrow to the
left of the controller probe and select Configure.
Controller
Navigation: controller
This section lets you view information about the hub and adjust log file settings.
Probe Information
Hub Connectivity
This section provides the hub information and is read-only.
This section lets you configure the following items.
Identification property User Tag 1: User defined tag used as a grouping/locating mechanism.
Default: blank
Identification property User Tag 2: User defined tag used as a grouping/locating mechanism.
Default: blank
Log Level: Sets the amount of detail to be logged to the log file. Log as little as possible during normal operation to reduce disk
Default: 0 - Fatal
Log Size (KB): Allows you to change the size of the log file according to your needs. When the log file size is reached, new entries
are added and the oldest log file entries will be deleted.
Default: 1024 KB
Hub update interval (minutes): Determines at what interval the hub is contacted with an "alive" message. The range is 1 to 180
minutes. Note that the hub is notified on a shorter interval when changes occur in the probe list.
On Robot uptime, reported as state changes: If this option is selected, QoS messages on robot uptime will be sent. The QoS
message status = up is sent when the robot starts, and status = down is sent when the robot stops.
Set QoS source to robot name instead of computer host name: Select this option to use the robot name for the QoS source when
sending alarms. By default, the host name of the computer hosting the probe is used as the QoS source.
Default: Disabled
Status
This section provides the status of the robot and is read-only.
Setup
Navigation: controller > Setup
This section lets you view and modify robot configuration settings.
Nimsoft
This section lets you specify:
Robot Name: The default name is the computer host name, and is auto-detected by default (recommended).
Default: Auto Detect (Recommended)
Secondary Hub Robot Name: Defines the method used to locate a temporary parent hub if the robot's own parent hub is
unavailable. By default, the robot will auto-detect the nearest active hub (recommended).
Search the subnet for a temporary hub when primary and secondary hubs are unavailable: Select this option to enable the
robot process and port controller to search the internet for a temporary hub. Default: not selected.
Advanced
Automatically unregister from hub at shutdown: When the robot is stopped, an unregister message is sent to the hub on which it
is registered. This will make the robot disappear from Infrastructure Manager. If this is not selected, the stopped robot will appear with
a red icon, enabling the operator to detect the situation.
Suspend all probes when no network connection is available: When running the robot on a computer with no network connection,
you can determine whether the robot should be active or enter a sleep mode where all probes are suspended until a network
connection is again available. If this option is not selected the alarm messages will be spooled and flushed when a network connection
is again available.
Default: selected (recommended)

Configuration file locking: Locks the configuration.
First Probe port number: Daemon type probes normally register a command port, which is allocated run-time on probe start-up.
Setting the probe port number makes the robot allocate specific port numbers for the probes as they are started. Use this option if you
want the probes to have port numbers in a specific range for router or firewall purposes.
Time offset from UTC (override the local time zone setting) sec: Overrides the local time zone setting. The time specification must
be entered as time offset from UTC (in seconds).
When no contact with hub: Set limitations for attempts to connect an unmanaged robot (a robot that has lost the contact with the
hub) to a hub.
Default: Allow move only within domain (recommended)
Variable Name: Environment variable for your UIM system. This variable is inherited by all the probes managed by this robot.
Variable Value: The value assigned to the variable name.
Alarms
Probe restart when the probe does not respond: Select the alarm to be sent when a probe is not responding and is restarted.
Dispatch error (internal): Select the alarm to be sent when there is a dispatch error for the probe.
Max restart attempts reached for the probe: Select the alarm to be sent when the maximum restart attempts have been reached.
Error starting probe: Select the alarm to be sent when there is an error starting the probe.
Timed probe did not return 0 on termination: Select the alarm to be sent when the probe does not return a value of 0.
Probe unregisters port but keeps running: Select the alarm to be sent when the probe unregisters the port but continues to run.
Probe distribution request error: Select the alarm to be sent when there is an error during probe distribution.
Distribution post-install error: Select the alarm to be sent when there is an error after the probe is distributed and installed.
Time interval at which alarm will be resent (minutes): Select the length of time (in minutes) when an alarm will be resent.
Virtual
The Controller probe sets up the communication between the robot and the virtual probe running a remote probe.
Virtual robots, using the proxy probe, will be created for 'remote' probes. remote probes are installed and running on computers without a
robot. The remote probe is configured with the path to the robot.
NAT
You can allocate an external IP address to a robot that resides on another IP network with incompatible addressing using Network
Address Translation. The robot will be able to send alarms and QoS messages, but the hub will not be able to communicate back to the
robot.
When Network Address Translation (NAT) is in effect between the robot and the hub, the robot must be configured to provide the correct
address to the hub. All communication from the hub to the robot will use this address. NAT can be set for the primary and secondary
hubs.
IP of the Robot as seen from the primary hub: Enter the name of the robot as shown in the primary hub configuration.
IP of the Robot as seen from the secondary hub: Enter the name of the robot as shown in the secondary hub configuration.
IP
Robot IP Address: Select the option for detecting the IP address, either automatically detect or enter a specific hub address.
IP version support: Select the IP version support for the robot.
Local IP validation: Select this option if you want local IP validation performed.
Data origin
Origin: Enter the origin name you would like associated with this robot.
Update button: Click this button to update the origin name associated with this robot.

This article describes the tabs in the controller configuration GUI and provides information on advanced configuration. For an overview of the
probe, see controller.
See the following topics for details:
Setup
Nimsoft
Misc
Advanced
Environment
Virtual
Alarm
NAT
IP
Status
Double-clicking the controller probe in the Infrastructure Manager application brings up the configuration GUI.
Setup
The Setup tab contains the following sections:
Nimsoft
Misc
Advanced
Environment
Virtual
Alarms
NAT
IP
Nimsoft
The Nimsoft tab allows you to set up the robot and a secondary hub.

Robot Name
Automatically detect: Host name is the robot name.
Set specific name (override): You can specify the robot name to be used.
Secondary HUB defines the method used to determine the secondary hub. The secondary hub will be used if the primary hub is
unavailable. Options are:
Wait for primary hub to become available prevents the robot from attaching to another hub. It will attach to its parent hub when the
hub is active.
Note: This option is replaced by the Automatically detect option if the Search the subnet for a temporary hub option is
selected.
Automatically detect (searches the subnet) allows the robot to search the subnet for a responding hub within the domain when the
Specify Hub (IP/name) allows the robot to attach to the specified hub.
Specify Hub (domain name) allows the robot to attach to the specified hub.
Search the subnet for a temporary hub when primary and secondary hubs are unavailable allows the robot to search for a
temporary hub if the parent and secondary hubs are unavailable. Selecting this option changes the Wait for the primary hub to
become available option to Automatically detect (searches the subnet) option.
Misc
The Misc tab allows you to set logging information, identification properties, quality of service and robot interaction mode.
Identification properties lets you specify User tag 1 and User tag 2, which are user-defined tags to be used as a grouping/locating
mechanism. The tags are displayed in various lists in Infrastructure Manager.
Log Level sets the amount of detail to be logged to the log file. Log as little as possible during normal operation to reduce disk
Log Size allows you to change the size of the log file according to your needs. The default size of the log file is 1024 KB.
Hub update Interval determines at what interval the hub is contacted with an "alive" message. The range is 1 to 180 minutes. Note that
the hub is notified at a shorter interval when changes occur in the probe list.
Quality of Service:
On Robot uptime, reported as state change sends QoS messages on robot uptime. The QoS message status = up is sent when the
robot starts; status down is sent when the robot stops.
Set QoS source to robot name instead of computer hostname uses the robot name specified on the Setup > Nimsoft tab.
Note: This option is disabled unless the Set specific name (override) option is selected on the Setup > Nimsoft tab.
Robot mode is normal or passive. Passive robots cannot initiate communication with a hub. All contact must be initiated by the hub.
Advanced
The Advanced tab allows you to set robot options and the data origin.
Robot options allows you to set options for the robot:

When the robot is stopped, an unregister message is sent to the hub on which it is registered. This will make the robot disappear from
Infrastructure Manager. If this is not selected, the stopped robot will appear with a red icon, enabling the operator to detect the
situation.
When running the robot on a computer with no network connection, you can determine whether the robot should be active or enter a
sleep mode where all probes are suspended until a network connection is again available. If this option is not selected the alarm
messages will be spooled and flushed when a network connection is again available.

Daemon type probes will normally register a command port, which is allocated run-time on probe start-up. Setting the probe port
number will make the robot allocate specific port numbers for the probes as they are started. Use this option if you want the probes to
have port numbers in a specific range for router / firewall purposes.
This option lets you override the local time zone setting. The time specification must be entered as time offset from UTC (in seconds).
When no contact with hub sets limitations for attempts to connect an unmanaged robot (a robot that has lost the contact with its hub) to
a hub, using the Tools > Connect Robot option in Infrastructure Manager. The options are:
Do not allow robot to be moved
Allow move only within domain
Data Origin (override origin set by the Hub) lets you specify the Origin, which is a string attached to QoS data from probes to identify
the origin of the data. The default origin is the name of the parent hub.
Environment
The robot controller will read the variable/value pair in the list and insert it into the robot environment. This environment is inherited by the probes
managed by the robot.
You can add, edit or delete these environment variables by right-clicking in the screen and selecting the appropriate menu option. Only add
environment variables that you want all probes on this robot to use.
Virtual
This tab lists virtual robots served by the robot controller. The netware probe is the only probe that can be set up on a virtual robot.
Virtual robots will, via the proxy probe, be created for remote probes (probes installed and running on computers without a robot). The remote
probe is configured to know which robot to be served by.
In Infrastructure Manager, the remote probe will appear as a probe on a virtual robot.

1. Select the hub in Infrastructure Manager, and the robots will be listed in the Main Window.
The Version column will notify if it is a virtual robot or not.
In the example below, lab 5 is virtual on xpkost, which means that the robot xpkost serves the virtual robot lab 5.
2. Right-click the xpkost robot in the Navigation Pane and select Properties to bring up the controller configuration tool.
Now you may select the Setup > Virtual tab, right-click and define user tags for the virtual robot.
Alarm
This tab contains the internal alarm messages issued by the controller on the different error situations that may occur. You are allowed to select
the severity level for each alarm message. For the condition Probe restart when the probe does not respond, you can also select that no alarm
message is issued.
The option Time interval at which alarms will be resent defines the time interval in minutes between alarms being sent on an error condition.
If this field is left blank, the controller will never attempt to resend the alarms.
NAT
The feature allows you to allocate an external IP address to a robot that resides on another IP network with incompatible addressing.
This tab contains the setup for NAT (Network Address Translation).
If the robot is separated from the hub by a NAT (Network Address Translation) device, the robot will be able to send alarms and QoS messages,
but the hub will be unable to communicate back. One solution is to setup static NAT mappings for each robot behind the NAT device. Using Raw
Configure, you can then add the key robotip_alias to the controller section of the robot.cfg file on the robot computer. This key changes the IP
address that gets registered when the robot initially connects to the hub.
The key robotip_alias should specify the static NAT mapping IP address that the hub and the clients on the other side of the NAT device should
use to access the robot. For example:
<controller>
...
<\controller>
IP
The IP tab allows you to configure the IP information for this robot.
Robot IP-address:
The host IP address will be used.
Specify an IP-address or set of IP-addresses for the robot. This is typically used when a host has more than one network interface.
For more than one IP-address, the addresses must be separated by a comma. IP addresses can also contain wildcards (*).
Valid entries:
198.2.3.5, 138.3.4.10
198.2.*.*, 138.3.4.10
The controller and all probes it starts only listen for connections ON their NIC attached to addresses that start 198.2. If there are not
any addresses then they would listen ON 138.3.4.10.
IP version support Select the appropriate IP version you are running.
Local IP validation With this option enabled, if the robot IP address is not set to localhost, it is checked against a list of IP addresses
that are known valid for that server before it is used.
IP-binding:
You can only select this option if you set a specific address in the Robot IP-address section of this screen. The controller will only list
ON a specific IP address on servers with multiple NICs.
Status
This section describes the properties for the Status tab.
Robot name
The actual/current name of the robot.
Robot IP-addr.
The actual/current ip-address of the robot.
Robot version
The version of the robot.
Op. Sys.
Operating system name.
Op. Sys. type
The type of the operating system (UNIX/Windows etc.).
Op. Sys descr
Operating system description.
The status indicator will, together with a status message, give information about the current controller status (Green icon means OK, Red
icon means an error situation).
Right-clicking on the indicator lets you set the robot into maintenance mode for the period specified. See the section for more information.
Installed packages
Lists all packages installed on the robot in a separate window.
Robot environment
Opens the Robot Environment window. This window displays the variables and values for the computer running the robot.
Note: The values are inherited by any probe started by this robot.
Hub connectivity
Displays the current, primary and secondary hubs.
Version 2.80 or higher of the probe allows the DNS name of the hub machine to be used in the robot.cfg file in two ways: using the full DNS name
instead of the IP address in the hubip parameter or using the full DNS name in the hub_dns_name parameter.
Using the full DNS name of the computer instead of the IP address (as the hubip parameter) allows the robot to recognize its main hub and return
to it after a failover situation.
The hubip parameter will be replaced by an IP address on a robot move operation. The robot can fail over to a different hub if the DNS is down.
Using the full DNS name in the parameter hub_dns_name allows the robot to attempt to use the hub_dns_name to look up the hub IP address. If
this fails, the hubip parameter is used. When the DNS name lookup is successful and the ip address found is different from the hubip parameter,
this parameter is replaced.
Note that the hub_dns_name is lost on robot move and secondary_hub_dns_name is lost on change of secondary hub initiated by the controller
configuration tool.
<controller>
hubip =
hub_dns_name =
</controller>

You can limit the number of open ports in your environment (for example, in a network with a firewall) by setting the proxy_mode key in the robot.c
fg.
In the robot.cfg, set the proxy_mode = 1 to send all the traffic through a specific port, for example, port 48000.

Controller version 2.80 or higher supports maintenance mode. Right-clicking one or more robots in the Infrastructure Manager main window pane
and selecting Maintenance, lets you set the selected robot (s) into maintenance mode for the period specified.
The robot will stop all probes and stop sending messages. The robot does a full restart and only starts the core components ( controller, spooler, h
db, hub, distsrv, nas and proxy ). In Infrastructure Manager the probe icon of other probes will indicate that these probes are suspended while the
robot is in maintenance mode.
On entering maintenance mode, the end time of the maintenance mode period must be given. When this time is reached the robot will go back to
normal operation and start up any suspended probes.
Probe distribution and activation can be performed while the robot is in maintenance mode, however the affected probes will be suspended and
not actually started.
cuegtw (Cloud Monitoring Gateway)

The Cloud Monitoring Gateway probe subscribes to CA Unified Infrastructure Management Cloud Monitor RSS feeds and routes them to the
Alarm Server (nas). The probe pools the Cloud Monitor API using valid credentials for collecting data and generating alarms. The CA Unified
Infrastructure Management Cloud Monitor is a software-as-a-service (SaaS) solution for monitoring web applications, websites, and cloud
services around the globe.
Note: The support integration of CA Unified Infrastructure Management Cloud User Experience Monitor or CUE in UMP 2.6 and cuegtw
probe is only for English locale.
When upgrading the probe from a previous version to 1.07 in the German locale, you must enter the password for each profile and save
changes. The process ensures that the probe reads the password and lets you connect to the probe.
More information:
cuegtw (Cloud Monitoring Gateway) Release Notes
v1.0 cuegtw AC Configuration

You can configure the Cloud Monitoring Gateway probe to create a profile and connect with the CA Unified Infrastructure Management Cloud
Monitor API.
Contents
cuegtw Node
CA Unified Infrastructure Management Cloud Monitor URL Node
<Profile Name> Node
Configure a Node
Manage Profiles
Delete Profile
cuegtw Alert Metrics Default Settings
cuegtw Node
The cuegtw node lets you configure general properties and the internet proxy settings. You can view the probe information and the alarm details.
Navigation: cuegtw
cuegtw > Probe Information
cuegtw > General Configuration
Default: 2 - Warn
Interval: defines the time interval for fetching the new RSS feeds from the CA Unified Infrastructure Management Cloud Monitor.
Default: 5
Interval Unit: specifies the time interval unit.
Default: Minutes
cuegtw > Proxy Configuration
This section lets you configure the proxy user authentication details for the probe to connect with the CA Unified Infrastructure
Management Cloud Monitor API.
Enable Proxy: enables the proxy settings.
Proxy Type: specifies the proxy type of your networking environment.
User ID: defines the user name for authenticating the probe on the proxy server.
Proxy URL: defines the IP address of the proxy server.
Port: defines the port number where the proxy server listens to the incoming requests.
Domain Name: defines the domain of the user. This option is applicable only when the proxy type is NTLM.
cuegtw > Message Configuration
This section lets you view the alarm messages of the probe. You can view the message name, message text, and the message severity.
The probe has two alarm messages and are read only.
CA Unified Infrastructure Management Cloud Monitor URL Node

The CA Unified Infrastructure Management Cloud Monitor URL node represents the URL, http://api.watchmouse.com/1.6/, for accessing the CA
Unified Infrastructure Management Cloud Monitor API. This node does not contain any section and is used for displaying the list of monitoring
profiles in the navigation pane.
<Profile Name> Node

The profile name node represents the actual monitoring profile name. This node is used for activating the monitoring profile and configuring the
alarm properties.
Navigation: cuegtw > CA Unified Infrastructure Management Cloud Monitor URL > profile name
profile name > Profile Configuration
This section lets you activate the monitoring profile and configure the user details for accessing the cloud monitor API. Use the Test optio
n of the Actions drop-down list for verifying the credentials.
Important: The username and password for the CA Unified Infrastructure Management Cloud Monitor web site and API can be
different. The probe requires credentials for cloud monitor API. You can change the API password by selecting the Subscriptio
n > Change Password option after logging on to the cloud monitor web site.
profile name > Alert/Reminder Monitor Configuration
This section lets you generate an alarm when the probe receives an RSS feed from the cloud monitor API.
Publish Alarms: activates the profile for generating the alarm.
Alert: specifies the alarm message when the RSS feed type is alert.
Reminder: specifies the alarm message when the RSS feed type is reminder.
Configure a Node
This procedure provides the information to configure a particular section within a node. Each section in a node lets you configure probe properties
for connecting to the cloud monitor website and fetching RSS feeds.
Follow these steps:
1. Navigate to the section in a node that you want to configure.
Manage Profiles
This procedure provides the information to create a monitoring profile for connecting to the cloud monitor API. A monitoring profile contains valid
user details to fetch RSS feeds for generating alarms.
Follow these steps:
1. Click the Options icon next to the CA Unified Infrastructure Management Cloud Monitor URL node in the navigation pane.
3. Enter profile details in the Profile Configuration dialog and click Submit.
The profile is saved for fetching the RSS feeds from the cloud monitor API. You can configure alarms for each RSS feed for populating
the NAS.
Delete Profile
You can delete a monitoring profile when it no longer requires monitoring the RSS feeds of the cloud monitor.
Follow these steps:
2. Click the Delete option.
3. Click Save.
cuegtw Alert Metrics Default Settings

This section contains the alert metric default settings for the Cloud Monitoring Gateway probe.
Alert Metric
Warning Threshold
Warning Severity
Error Threshold
Error Severity
Description
Alert
Critical
The RSS feed message text with error details.
Reminder
Warning
The RSS feed message text with error details.
data_engine
The data_engine probe manages and maintains data that is collected by Quality of Service (QoS) enabled probes. The data_engine creates all
tables and stored procedures necessary to manage the collected data.
Data that is produced by the QoS probes is stored in the UIM database, in tables named raw data tables (table prefix is RN_). Raw data is kept
for a user-defined period, then summarized and aggregated into Hourly data (HN_tables). Hourly data is then summarized and aggregated into
Daily data (DN_ tables).
Note: The data_engine probe does not generated alarms and has no metrics.
The topics covered in this article include the following:
Tables
How the data_engine Probe Collects and Maintains QoS Data
RN_QOS_DATA Table Columns
RN_table Indexes
Data_engine Start Up
Parallel Mode
Serial Mode
Tables
The tables created in the UIM database have prefixes indicating the type of data they contain.
The naming convention for the tables is as follows:
S_ for tables used to store system data
D_ for data tables
H_ for tables containing historic data
HN_ for data tables containing hourly/compressed data
DN_for data tables containing daily/compressed data
RN_ for data tables containing unprocessed (raw) data directly from the probes
The QoS data structure is dynamically created by the data_engine on the first startup, and when the first unique QOS_DEFINITION or
QOS_MESSAGE message is received from a probe. The S_QOS_DEFINITION table contains the definitions of known QoS types (for example,
QOS_CPU_USAGE), and is updated when a probe sends a QOS_DEFINITION describing a new QoS type.
The S_QOS_DATA table contains an index of all data tables for the QoS objects. When a probe sends a QOS_MESSAGE containing a QoS
object that is not already defined in the S_QOS_TABLE, a new entry is added to the table and the data is inserted into the table referenced in
column r_table (typically RN_QOS_DATA_nnnn) with the table_id that the new row is given when inserted into the S_QOS_DATA table.
Note: Do not drop the data tables manually. Instead delete the entry from the S_QOS_DATA table, and the tables will be dropped by a
trigger. You must restart the data_engine afterwards.
How the data_engine Probe Collects and Maintains QoS Data

During data collection, data_engine performs the following actions:
1. The data_engine probe receives a QoS definition from another probe.
2. The data_engine probe queries the S_QOS_DEFINITION table to determine if the QoS type in the message already exists in the table
(for example, QOS_CPU_USAGE).
3. If the QoS type does not exist, a new entry is added to the S_QOS_DEFINITION table. New RN, HN, BN and DN tables are created in
the UIM database to store monitoring data from the probe.
4. When the first qos_message from the probe arrives, the data_engine probe adds QoS object data into the S_QOS_DATA table. The
S_QOS_DATA table contains the object data for each unique combination of qos, source, and target attributes.
5. The data_engine probe inserts the raw data from the probes into the appropriate RN tables.
6. During the scheduled maintenance runs, the data_engine probe summarizes and aggregates raw data from RN tables into hourly data
that is stored in HN tables.
7. Older RN data is purged based on a user-defined period.
8. The data_engine probe then summarizes and aggregates hourly data from HN tables into daily data that is stored in DN tables.
9. Older HN data is purged based on a user-defined period.
10. Last sample value coming from the probes for each qos object is populated in the S_QOS_SNAPSHOT table. This data is used to
provide fast QoS data access for CA Unified Management Portal (UMP) portlets.
RN_QOS_DATA Table Columns

RN_QoS_Data_tables hold raw QoS data. QoS data is written once and never updated.
Column Name
Description
TableID
unique identifier; key for looking up timeseries data
Sampletime
time the sample was taken
Samplevalue
QoS value
Samplestdev
standard deviation of the sample
Samplerate
Rate of sampling
Tz_offset
time zone offset
RN_table Indexes
The default indexes in RN_tables are optimized for writing data:
Index
Description
Idx0
sampletime, table_id
Idx1
table_id, sampletime (with samplevalue, samplerate, tz_offset included in the index)
The RN_QoS_DATA_tables do not have primary keys, as both tableID and sampletime can be duplicated.
Data_engine Start Up
By default, the data_engine commits data to a database in parallel mode using ten parallel threads. In parallel mode, the data_engine uses
multiple threads to do work in parallel and makes the data_engine less vulnerable to performance issues when commits to a particular table are
slow. For more details, see Parallel Mode, Serial Mode, and Thread Count.
When the data_engine probe starts, it loads both S_QOS_DATA and S_QOS_DEFINITION into memory and establishes a bulk connection to the
database.
Parallel Mode
The data_engine probe can run in either parallel or serial mode. The mode is determined by the thread count, which is the number of preallocated
threads used to commit data to a database. Earlier versions of data engine ran in serial mode by default, but the current default is parallel mode.
When the thread_count_insert parameter in Raw Configure is set to a value of greater than one, the data_engine commits data to the database in
parallel mode; when set to a value less than one serial mode is used.
Note: The default setting for the thread_count_insert parameter is 10.
In parallel mode, the data_engine:

1. Continuously reads data from the hub.
2. Stores the data in a shared list and begins reading more messages.
3. Iterates over all lists using another thread to see if any of the lists need to be flushed to the database.
Note: The actual writing of data does not happen now.
4. All objects are marked as ready to commit and a reference is placed onto another list.
5. Concurrently, a thread continuously runs to validate, sort, and place messages into a list that is written to the database.
6. Writes any messages that have been marked as 'ready to commit data' to the database using a thread pool of worker threads.
Serial Mode
Serial mode is the original mode for the data_engine probe. If the thread_count_insert parameter is set to zero in the Raw Configure menu, the
data_engine probe defaults to serial mode.
In this mode, the data_engine:
1. Reads messages from the hub for a given time period (default around 1 second).
From 1 through 20 messages are read at a time, depending on how many are in the queue or if the hub queue size has changed
(default 20).
The read messages are then validated and sorted into lists that can be quickly inserted into the database.
2. Stops reading new messages and iterates over all the lists, checking to see if any are full. By default the list is flushed if it contains more
than 5000 messages or if it has not been flushed in the last 5 seconds.
3. Goes back to reading messages from hub. If one bulk object takes too long to insert, then the writing of all data to the database is
delayed.
v8.3 data_engine AC Configuration

The topics covered in this article include the following:
Use the Admin Console to Access the data_engine Configuration GUI

Change the Database Connection Properties
Configure the Data Retention Settings
Override the Data Retention Settings on Individual QoS Objects
Set up Index Maintenance for Microsoft SQL Server Databases
Partition a Database
Partitioning a Microsoft SQL Server Database
Partitioning an Oracle Database
Before You Begin
Select the Partition Option
Partitioning a MySQL 5.6 Database
Before You Begin
Schedule Database Maintenance
Use the Admin Console to Access the data_engine Configuration GUI

In the Admin Console data_engine configuration GUI, you can:
Set up Partitioning for Raw Sample Data.
Set up Index Maintenance.

Important! The database connection properties should only be changed in limited circumstances such as recovery operations.
Changing the Database Vendor can cause connection issues. If you are changing database vendors, CA recommends reinstalling CA
Unified Infrastructure Management.
Follow these steps:

1. In the data_engine probe configuration menu, click the Database Configuration folder.
2. Modify connection settings, as needed. See Database Configuration for more details.
3. Select Actions > Test Connection. A Response dialog appears to indicate if the connection status. If the connection is good, the
Connected and Ping values are set to yes. Close the dialog to return to the database configuration page.
4. Click Save.
The configuration changes are saved and the probe is restarted.

You can change the data retention settings to meet your auditing or security requirements.
Follow these steps:
1. In the data_engine probe configuration menu, click the data_engine heading.
2. Change the desired retention settings in the General Section. See General Configuration for more information about each field.
3. Click Save.

You can override the data retention settings for individual QoS items.
Follow these steps:
1. In the data_engine probe configuration menu, click the Quality of Service folder.
2. In the Quality of Service Table, click the row of the QoS metric you want to modify.
3. Change the desired retention settings. See Quality of Service for more information about each field.
4. Click Save.

You can set up Index Maintenance for Microsoft SQL Server to improve the speed of data retrieval operations.
Important! (MS SQL Server) It is not possible to rebuild the index for single partitions prior to SQLServer 2014. You can only
reorganize individual partitions. Performing automatic indexing for large tables from the data_engine is discouraged, as indexing might
not complete in a reasonable amount of time.
Follow these steps:

2. Select the Index Maintenance check box.
3. Change the desired Index Maintenance options. See Database Configuration for more information about the individual fields for each
database vendor.
4. Click Save.
Index Maintenance is performed during the next maintenance period.
Microsoft SQL Server Enterprise Edition
Oracle
MySQL 5.6
Note: When you install a new database or database maintenance is performed, 14 extra partitions are created to allow you up to two
weeks to correct an issue if an error occurs during data maintenance.
Partitioning a Microsoft SQL Server Database

If you are not using the System Administrator (sa) login and require SQL Authentication on Microsoft SQL Server, your user account must have
the following permissions:
The db_owner database role for the UIM database.
Read and update permissions on the master and tmpdb system databases.
The serveradmin database role to create and execute stored procedures properly.
Microsoft SQL Server Enterprise Edition databases are partitioned online, meaning the data_engine can continue to write data to tables. You can
set up partitioning to improve performance when accessing the raw sample data tables.
Follow these steps:

2. In the Connection Information field select the type of database from the drop-down menu.
3. Select the Partition data tables check box.
4. Click Save.
Partitioning will be performed during the next maintenance period. The time required to execute the partitioning is dependent on both the amount
of data and the performance of the disk subsystem. Partitioning can take up to several days on especially large installations.
Partitioning an Oracle Database

Before You Begin
For the data_engine to perform the partitioning process, you must license the Oracle Partitioning Option (from Oracle) and it must be enabled for
the Oracle database on UIM Servers.
Although partitioning your Oracle database provides enhanced performance, be aware that depending on the size and number of data tables in
your database, the partitioning process can take a few minutes, several hours, or possibly several days and can be resource intensive.
In addition to the processing time required to complete partitioning, the partitioning process requires the availability of enough free disk space to
create a partitioned interim table. The partitioning process copies the contents from the original data tables into the interim data tables, swaps the
original data tables and interim data tables, and finally deletes the original data tables. This process is performed while the tables and indexes are
online.
If there is not enough free disk space for the interim tables, the partitioning process will not be able to finish. The process is similar to the one
described in this Oracle article.
We recommend you perform the following tasks before selecting the Partition Data Tables option.
1. The partitioning process requires the default tablespace (for the interim table) to be 1.6 times larger than the largest data table to be
partitioned. In general, RN tables are the largest data tables in the database. To find the largest RN table, generate and run the following
script:
Script to find the largest RN table
Expand source
select
segment_name
table_name,
sum(bytes)/(1024*1024) table_size_meg
from
user_extents
where
(segment_type='TABLE' or segment_type='TABLE PARTITION')
and
segment_name like 'RN_QOS_DATA_%'
group by segment_name
order by table_size_meg desc;
2. Initial partitioning of the tables online also consumes disk space in the SYSTEM tablespace. The disk space required prior to partitioning
is approximately the same as that required by the largest unpartitioned RN table. Determine the utilization of the system tables by
generating and running the following script:
Script to determine the utilization of the system tables
Expand source
column dummy noprint

column pct_used format 999.9
heading "%|Used"
column name
format a19
heading "Tablespace Name"
column Kbytes
format 999,999,999
heading "KBytes"
column used
format 999,999,999
heading "Used"
column free
format 999,999,999 heading "Free"
column largest
format 999,999,999 heading "Largest"
column max_size format 999,999,999 heading "MaxPoss|Kbytes"
column pct_max_used format 999.9
heading "%|Max|Used"
break
on report
compute sum of kbytes on report
compute sum of free on report
compute sum of used on report
select (select decode(extent_management,'LOCAL','*',' ') ||

decode(segment_space_management,'AUTO','a ','m ')
from dba_tablespaces where tablespace_name = b.tablespace_name) ||
nvl(b.tablespace_name,
nvl(a.tablespace_name,'UNKOWN')) name,
kbytes_alloc mbytes,
kbytes_alloc-nvl(kbytes_free,0) used,
nvl(kbytes_free,0) free,
((kbytes_alloc-nvl(kbytes_free,0))/
kbytes_alloc)*100 pct_used,
nvl(largest,0) largest,
nvl(kbytes_max,kbytes_alloc) Max_Size,
decode( kbytes_max, 0, 0, (kbytes_alloc/kbytes_max)*100) pct_max_used
from ( select sum(bytes)/1024/1024 Kbytes_free,
max(bytes)/1024/1024 largest,
tablespace_name
from sys.dba_free_space
group by tablespace_name ) a,
( select sum(bytes)/1024/1024 Kbytes_alloc,
sum(maxbytes)/1024/1024 Kbytes_max,
tablespace_name
from sys.dba_data_files
group by tablespace_name
union all
select sum(bytes)/1024/1024 Kbytes_alloc,
tablespace_name
from sys.dba_temp_files
group by tablespace_name )b
where a.tablespace_name (+) = b.tablespace_name
order by PCT_USED
/
3. Initial partitioning of the tables also consumes storage in the TEMP tablespace. The free disk space required prior to partitioning is
approximately the same as that required by the largest unpartitioned RN table. Determine the utilization of the TEMP tablespace by
Script to determine the utilization of the TEMP tablespace
Expand source
SELECT tablespace_name, SUM(bytes_used)/1024/1024 M_Used,

SUM(bytes_free)/1024/1024 M_Free
FROM
V$temp_space_header
GROUP BY tablespace_name;
Note: data_engine might have a slower data throughput rate with Oracle Database 12c than with Oracle Database 11g.
Oracle databases are partitioned online, meaning the data_engine can continue to write data to tables. You can set up partitioning to improve
performance when accessing the raw sample data tables.
Follow these steps:
4. Click Save.
Partitioning a MySQL 5.6 Database

Before You Begin
By default, the MySQL 5.6 innodb_file_per_table parameter is ON. When working with larger MySQL databases, it is recommended to turn off
innodb_file_per_table to improve data_engine's insert rate and thus performance.
To change the setting for the innodb_file_per_table parameter, follow these steps:
1. Depending on your operating system access the my.ini or my.cnf files.
2. Set the parameter to OFF by entering:
innodb_file_per_table = 0
MySQL 5.6 databases are partitioned offline, meaning data is blocked in the queue while a data table is being partitioned, and then written to the
database when the partitioning process is finished. Depending on the size of the table being partitioned (for example, if a table is 10 GB or larger)
and the rate of the data being sent to the data_engine, you might want to stop partitioning periodically to allow the data_engine to write the
backed-up data to the database (see step 7 in the following procedure).
Note: Due to database performance issues, we do not support partitioning on MySQL 5.5 and earlier. CA UIM Server requires that you
are using MySQL 5.6 to support partitioning.
Follow these steps:

1. Click the Scheduler folder.
2. For the Recurring fields, select Yearly and leave default values in the remaining fields.
This temporarily turns off daily maintenance.
4. In the Connection Information field, verify the value is set to MySQL.
6. Open the Probe Utility from the data engine context menu and run the run_admin_now callback to perform manual maintenance that will
partition data tables.
7. If the partitioning process runs for 24 hours:
a. Restart the data_engine. It might take the data_engine several hours to write all the data from the queue to the database.
b. Run the run_admin_now probe utility again to continue the partitioning process.
8. Repeat step 7 every 24 hours until all the tables in the database are partitioned.

You can schedule automatic database maintenance to optimize system performance.
Follow these steps:
1. In the data_engine probe configuration menu, click the Scheduler folder.
2. Enter a maintenance start date. You can set the start date for a future date or can start the maintenance schedule immediately.
3. Enter a maintenance end date. The end date can either be a calendar date or a set number of occurrences.
4. Select a Recurrence pattern. The additional time options appear for your selected duration pattern.
5. Enter the additional time options that are required for your selected duration. For example, if you select a daily duration pattern of days=6,
hours=0, and minutes=0, maintenance occurs every 6th day at midnight.
6. Click Apply.
The configuration changes are saved. If the start now option was selected, the new schedule for maintenance begins.
More information:
See v8.3 data_engine AC GUI Reference for more details about partitioning a database.
v8.3 data_engine AC GUI Reference

The configuration information and options are available through the Admin Console data_engine Configuration GUI. The navigation pane
organizes data_engine configuration into the following nodes:
data_engine
Probe Information
Quality of Service Type Status
Database Configuration
MySQL 5.6
Oracle
Quality of Service
Scheduler
To access the data_engine configuration interface, select the robot that the data_engine probe resides on in the Admin Console navigation pane.
In the Probes list, click the arrow to the left of the probe and select Configure.
data_engine
Navigation: data_engine
Probe Information


Log Level: Sets the amount of detail that is logged to the log file.
Data Management default values: The default settings for data maintenance. These settings apply to all QoS settings unless they have
been individually overwritten in the Quality of Service settings.
Compress data before delete: If selected, then by default, data from the raw (RN) tables is summarized into the Hourly (HN) tables, and
then deleted from the raw tables. In addition, the data from the Hourly (HN) tables is summarized into Daily (DN) tables, and then deleted
from the Hourly tables. This is only completed before a delete is performed.
Delete raw data older than: Raw data older than the indicated number of days is deleted.
Delete historic data older than: Hourly table data older than the indicated number of days is deleted.
Delete daily average data older than: Daily table data older than the indicated number of days is deleted.
Note: Do not enter a zero for delete raw, historic, or daily average datathis means the data is never deleted.
Action Button: Click the button located on the right side of the page to display a table populated with the QoS status data.
Click Actions > QoS Status (located on the right side of the page) to display a table populated with the QoS status data. This table is read-only.
Note: The status information is created based on statistics that are generated by the database provider. If incorrect information is
displayed, you might need to update the table statistics. For more information, see the "Out-of-date Information in the Quality of Service
Type Status Table" section in the Troubleshooting article for more details.
UIM.
The Database Configuration section allows you to specify the database connection settings. These settings are different for each database
vendor (MySQL, MS SQL Server, and Oracle).
To test the connection for all vendors, select Actions>Test Connection at the top of the page.
MySQL 5.6
Navigation: data_engine > Database configuration > MySQL

This section lets you configure the connection options for a MySQL database.
Schema: The database schema name.
Server Host: The database server name or IP address.
Port: The port number to connect to the database server. The default port number is 3306.
Username: The login user name.
Password: The login user password.
Note: The password cannot have any special characters, such as ";".
Partition Data Tables: Select this check box to perform partitioning on the raw sample data tables.
Navigation: data_engine > Database configuration > Microsoft

When selecting options, use the following table to determine the appropriate settings for your environment. Go here for up to date information
about the features supported for each edition of Microsoft SQL Server.
Edition
Partition
Data
Tables
Index
Maintenance
Index Maintenance Mode
Mode for
Index
Maintenance
SQL Server
Enterprise Edition
Online or
offline
Supported
Dynamic - select dynamic when you're not sure which edition of SQL Server is used in
your environment, or you want data_engine to choose the reorganize or rebuild mode
based on the Fragmentation Level threshold settings.
Online or
offline
Reorganize - a partition or an entire index for a table can be reorganized online or offline
when the Partition Data Table option is selected.
Rebuild - only an entire index for a table can be rebuilt online (this process can take some
time), but a partition or an entire index for a table can be rebuilt offline when the Partition
Data Table option is selected.
SQL Server 2014

Standard Edition
and earlier
Offline
Supported
Reorganize - only an index for a table can be rebuilt offline when the Partition Data Table
option is selected.
Rebuild - only an index for a table can be rebuilt offline when the Partition Data Table
option is selected.
SQL Server
Express Edition
Not supported
Index Maintenance in not recommended for large tables (over 10 GB).
This section lets you configure the connection and maintenance options for a Microsoft SQL Server database.
Provider: The SQL server provider.
Initial Catalog: The database name.
Data Source: The database server.
User ID: The login user.
Parameters: Other parameters for the OLEDB connection.

For SQL Server 2014 databases, and prior versions, if you select this option set maintenance mode to reorganize.
Note: This option is not available in the Microsoft SQL Express edition.
Offline
Index Maintenance: Perform table re-indexing with other maintenance routines, which by default are executed every 24 hours.
Note: On very large tables (over 10 GB), running index maintenance may not complete in a reasonable amount of time.
Compression mode: The method that is used for data compression:

None: No compression occurs.
Page: Optimizes storage of multiple rows in a page, a super-set of row compression.
Row: Stores fixed-length data types in variable-length storage format.
Maintenance mode: How the indexes are maintained:
Dynamic: Maintenance is performed based on the index statistics.
Reorganize: Maintenance is performed using the "alter index ... reorganize" SQL Server script.
Rebuild: Maintenance is performed using the "alter index ... rebuild" SQL Server script.
Online mode: The effect of maintenance on concurrent use of the QoS tables:
Dynamic: The maintenance is determined by the edition of SQL Server. If you're using SQL Server Enterprise Edition, then Online
mode is used for maintenance (if the chosen maintenance mode supports it); otherwise, Offline mode is used.
Online: The QoS tables are available for update and query during the data maintenance period. Online mode offers greater
concurrency but demands more resources. Choosing "Rebuild" above, and "Online" here requires SQL Server Enterprise Edition
(SQL Server Standard Edition and earlier do not support online index rebuilding).
Offline: The QoS tables are unavailable for update and query during the data maintenance period. Benign alarms may be generated
about failures to insert QoS data during the maintenance period, but the data will be re-inserted by data_engine at a later time when
the tables are once again made available for update.
Fragmentation level: Low threshold: If the fragmentation for an index is less than the low threshold percent value, then no maintenance
is performed.
Fragmentation level: High threshold: If dynamic maintenance mode is selected and fragmentation is between the low and high threshold
percentages, then the Reorganize mode is used; otherwise the Rebuild mode is used.
Index name pattern: The indexes that are maintained. The default is Blank (a blank entry results in all indexes being considered for
maintenance).
Oracle
Navigation: data_engine > Database configuration > Oracle

This section lets you configure the connection and database maintenance options for an Oracle database.
Hostname: The database server name or IP address
Port: The port number to connect to the database server
Username: The login user name
Service Name: The Oracle SID or Service name.

Dynamic: The maintenance is determined by the edition of Oracle. If Oracle is the Enterprise Edition, then Online mode is used for
maintenance; otherwise, Offline mode is used.
concurrency but demands more resources.
Offline: The QoS tables are unavailable for update and query during the data maintenance period.
Fragmentation Level (%): The percentage of fragmentation required before index maintenance is performed.
Quality of Service
Navigation: data_engine > Quality of Service

The Quality of Service section displays the attributes for the QoS metrics.
Name: The QoS type name.
Description: Description of the QoS type.
QoS Group: The QoS group is a logical group to which the QoS belongs (optional).
Unit: The unit of the QoS data (the abbreviated form of the QoS data unit).
Has Max Value: The data type has an absolute maximum. For example, disk size or memory usage have absolute maximums.
Is Boolean: The data type is logical (yes/no). For example, a host is available/unavailable or printer is up/down.
Type: Different data types:
0 = Automatic (The sample value is read at fixed intervals, which are set individually for each probe).
1 = Asynchronous (The sample value is read only when the value changes, and the new value is read).
Override Raw Age: Select this check box to override the raw age of the QoS metric.
Raw Age: The number of days you want to retain the QoS metric information.
Override History Age: Select this check box to override the history age for the QoS metric.
History Age: The number of days you want to retain the history information.
Override Daily Average Age: Select this check box to override the daily average age for the QoS metric.
Daily Average Age: The number of days you want to retain the daily average information.
Override Compression: Select this check box to override compression settings for data in RN and HN tables.
Compress: Raw data is summarized and aggregated into Hourly (or historic) data before it is deleted from the RN tables. This Hourly
data is then summarized and aggregated into Daily data before it is deleted from the HN tables.
Scheduler
Navigation: data_engine > Scheduler
This section allows you to schedule database maintenance.
Start time - Select either Now or a specific date and time. Selecting now begins the new database maintenance schedule immediately.
Ending - Select Never, After x occurrences, or By a specific date and time.
Recurring - select one of the following occurrence patterns:
Minutely
Hourly
Daily (including a specific time)
Weekly (including a specific time and days of the week)
Monthly (including occurrence, calendar day, and specific time)
Yearly (including month and specific time)
v8.3 data_engine IM Configuration

Prerequisites
The data_engine probe requires the appropriate version of the compat-libstdc++ runtime library to be installed on your system. This is required for
C++ runtime compatibility. The copy of distribution specific compat-libstdc++ runtime library can be obtained from one of the following links:
http://rpmfind.net
For CentOS, follow these steps to get the compat-libstdc library:
1. Go to Programs > System > Add/Remove Software.
2. Select the Search tab and search for compat-libstdc and use 33 library.
3.
3. For 5 compatibilities, select the appropriate version of the compat-libstdc++ library for your distribution and install it.
Contents
Prerequisites
The General Tab
Index Maintenance Properties (SQL Server only)
The Quality of Service Type Status Window
The Database Tab
Microsoft SQL Server Options
MySQL Options
Oracle Options
The Quality of Service Tab
The Schedule Tab
Configure the data_engine by selecting the data_engine probe in Infrastructure Manager, then right-click and select Configure. This opens the
data_engine configuration dialog.
The General Tab

The General tab displays the appropriate data management default attributes based on the database you are using. These attributes differ for
SQL Server, MySQL, and Oracle databases.
The General tab contains the following subsections:

Data Management default values: The default settings for data maintenance. These settings apply to all QoS settings unless they have been
individually overwritten in the Quality of Service settings.
Compress data before delete: If selected, then by default, compression will be done on raw data and copied into historic tables when
deleting raw data. This will only be completed before a delete is performed. In addition, historic data will be compressed and aggregated
into Daily Data, before deleting it from the HN tables.
Delete historic data older than: Historic table data older than the indicated number of days is deleted.
Automatically reindex tables: Perform table re-indexing with other maintenance routines, which by default are executed every 24 hours.
Important! It is not possible to rebuild the index for single partitions prior to SQLServer 2014. You can only reorganize
individual partitions. Performing automatic indexing for large tables from the data_engine is discouraged, as indexing may not
complete in a reasonable amount of time.
Index maintenance properties (SQL Server option only): Click the Advanced button to activate or deactivate the index maintenance
properties. For more details, go to the Index Maintenance Properties section. This option will not appear if you are using Oracle or
MySQL.
Partition data tables (SQL Server option only): Option to partition the data tables.
Note: Although you can select the Partition data tables check box for data_engine v8.3, this function has been disabled within
IM. If you select this check box in IM, no actions occur and the data tables is not partitioned. Access the data_engine
configuration in Admin Console to turn on partitioning for Microsoft SQL Server Enterprise Edition database.
Log Setup: This section allows you to set the log level details.
Log Level: Sets the level of details written to the log file. Log as little as possible during normal operation to minimize disk consumption,
and increase the amount of detail when debugging.
Status: This button opens the Status window and provides the current work status of the probe. For more details, see the Status Window section.
Statistics: This section displays the current transmission rate for transferring QoS messages into the database.

To configure the index maintenance properties, click the Advanced button in the General tab.
Maintenance mode: Defines how the indexes are maintained.
Note: It is not possible to rebuild the index for single partitions prior to SQLServer 2014. You can only reorganize individual
partitions. Performing automatic indexing for very large tables from the data_engine is strongly discouraged, as indexing may
Online mode: Defines the effect of maintenance on concurrent use of the QoS tables.
Note: This option is not supported if partitioning is enabled on SQL Server.
Dynamic: The maintenance is determined by the edition of SQL Server. If SQL Server is the Enterprise Edition, then Online mode will be
used for maintenance (if the chosen maintenance mode supports it); otherwise, offline mode will be used.
Online: The QoS tables are available for update and query during the table maintenance period. Online mode offers greater concurrency
but requires more resources.
Offline: The QoS tables are unavailable for update and query during the table maintenance period.
Fragmentation Level: The fragmentation level information is used if Index name pattern is anything other than "All".
Low Threshold: If the fragmentation for an index is less than the low threshold percent value, then no maintenance will be performed.
High Threshold: If Dynamic maintenance mode is selected and fragmentation is between the low and high threshold percentages, then
the Reorganize mode will be used; otherwise the Rebuild mode will be used.
Index name pattern: The indexes that are maintained. The default is Blank, which indicates a blank entry that results in all indexes being
considered for maintenance.

Clicking the Status button opens the Quality of Service Type Status window. This window provides data regarding the QoS tables and is
read-only.
The status information is created based on statistics generated by the database provider. If incorrect information is displayed, you may need to
update the table statistics. For more information, see Out-of-date Information in the Quality of Service Type Status Table section in the
Troubleshooting article.
The Database Tab

The Database tab enables you to specify the database connection settings. The currently supported databases include:
MySQL
Oracle
The database settings specified here are used by various other probes, such as dashboard_engine, discovery_server, sla_engine, wasp, and
dap.

Database vendor: Select the name of the vendor of the database. For MS-SQL, select Microsoft option.
Provider: The ADO provider used for the database connection.
Initial Catalog: The database name
Data Source: The database server
User ID: The login user
Password: The login users password. Ensure that the password does NOT contain any special characters (such as ";").
Parameters: Other parameters to the OLEDB connection
Click the Test Connection button to check the current connection setup.
Important: If you install CA Unified Infrastructure Management (UIM) and MS-SQL on a nonstandard port you must configure the
data_engine "server" parameter to include the port. Example: "<server>,< port>".
MySQL Options
Database vendor: Select MySQL option.
Schema: Enter the database schema name
Server Host: Enter the database server name or IP address
Port: Enter the port number to connect to the database server
Oracle Options
Database vendor: Select Oracle option.

Hostname: Enter the database server name or IP address
Password: The login user's password. Ensure that the password does NOT contain any special characters (such as ";")
Service Name: Enter the Service name

The tab contains a list of all the QoS types defined in the database.
QoS Name: The QoS type name. On the form QOS_xxx
Unit (abbrev.): The unit of the QoS data (The abbreviated form of the QoS data unit).
Has Max Value: Has the data type an absolute max. Example: disk size, memory usage.
Is Boolean: Is the data type a logical type? Example: host is available, printer is up.
0 = Automatic (The sample value is read at fixed intervals, individually set for each of the probes).
1 = Asynchronous (the sample value is read only each time the value changes, and the new value is read.
The individual QoS definitions can be edited to have specific values:
1. Double click on a row in the Quality of Service tab to open the Override window.
2. Select "Override with" to specify a value to change the default QoS definitions.
3. Click OK, then click Apply to save your changes.
The Schedule Tab

The Schedule tab is used to schedule the process of data maintenance.
Range
Start now: Select this option to start the data maintenance process now.
Start at: Select the date from the calendar by clicking the drop-down arrow. This date and time indicates the time when the data
maintenance starts.
No end date/End after/End by: Select an option to end the data maintenance process.
Select No end date option to continue the data maintenance process non-stop.
If you select the End After option, enter number of occurrences in the box.
If you select the End by option, then select the date from the calendar by clicking the drop-down arrow.
Pattern: The options for the pattern changes depending on your duration selection.
Minutely/Hourly/Daily/Weekly/Monthly/Yearly: Select the duration pattern at which the data maintenance process should run.
Every/ Every <pattern>: For the selected pattern, specify time more precisely. The options in this section change for each duration
pattern. For example, if you select Minutely:
Select Every to set minutes manually by entering the minute in the box.
Select Every minute to run the data maintenance every minute.

This article explains how to configure the data_engine probe.
Prerequisites
Verify that you have the proper permissions to access a Microsoft SQL Server database when you are not using the sa login. See SQL
Authentication on Microsoft SQL Server.
Oracle
Before partitioning an Oracle database, review prerequisites to ensure that you have enabled the Oracle Partitioning Option and have
enough free disk space to create a partitioned interim table that is used during the partitioning process.
Contents
Prerequisites
Using the Admin Console to Access the data_engine Configuration GUI
Microsoft SQL Server Prerequisite: SQL Authentication
Oracle Database Prerequisite: Oracle Partitioning Option Required
Oracle Database Prerequisite: Verify Tablespace Before Partitioning
Partition an Oracle or Microsoft SQL Server Enterprise Edition Database

Set up Partitioning for Raw Sample Data (Microsoft SQL Server and Oracle)
Set up Index Maintenance (Microsoft SQL Server)

Follow these steps:

2. Click the Connection Information drop-down list, select the Database Vendor for your database.
3. Enter the connection settings. Settings are different for each database vendor. See Database Configuration for more information about
the fields that are required for each vendor.
4. Click the Test Connection button. The Test ADO Connection String window appears. If the connection is good, the Connected and Ping
values are set to yes.
5. Click Save.

Follow these steps:

3. Click Save.

Follow these steps:
4. Click Save.

Follow these steps:

database vendor.
4. Click Save.
Prerequisites
Oracle database
Procedures
Oracle database
Microsoft SQL Server Prerequisite: SQL Authentication


In order for the data_engine to perform the partitioning process, you must license the Oracle Partitioning Option (from Oracle) and it must be
enabled for the Oracle database on UIM Servers.
Oracle Database Prerequisite: Verify Tablespace Before Partitioning

online.
This section provides a list of tasks we recommend you perform before selecting the Partition Data Tables option.
script:
select
segment_name
table_name,
from
user_extents
where
and

heading "%|Used"
column name
format a19
column Kbytes
format 999,999,999
heading "KBytes"
column used
format 999,999,999
heading "Used"
column free
column largest
break
on report
from dba_tablespaces where tablespace_name =
b.tablespace_name) || nvl(b.tablespace_name,
decode( kbytes_max, 0, 0, (kbytes_alloc/kbytes_max)*100)
pct_max_used
tablespace_name
tablespace_name
union all
tablespace_name
order by PCT_USED
/

FROM
V$temp_space_header

Oracle and Microsoft SQL Server Enterprise Edition databases are partitioned online, meaning the data_engine can continue to write data to
tables. You can set up partitioning to improve performance when accessing the raw sample data tables.
Follow these steps:
4. Click Save.

Follow these steps:
6. Click Apply.
For more information:

See the data_engine AC GUI Reference for more details about partitioning a database.

data_engine
Probe Information
MySQL 5.6
Oracle
Quality of Service
Scheduler
data_engine
Probe Information


Note: Do not enter a zero for delete raw, historic, or daily average datathis means the data is never deleted.
This section provides data regarding the QoS tables and is read-only.
displayed, you might need to update the table statistics. For more information, see the "Out-of-date Information in the Quality of Service
Type Status Table" in the Troubleshooting article.
UIM.
vendor:
MySQL
Microsoft
Oracle
MySQL 5.6


When selecting options, use the following table to determine the appropriate settings for your environment. Go here for up to date information
about the features supported for each edition of Microsoft SQL Server.
Edition
Partition
Data
Tables
Index
Maintenance
Index Maintenance Mode
Mode for
Index
Maintenance
SQL Server
Enterprise Edition
Online or
offline
Supported
Online or
offline
Reorganize - a partition or an entire index for a table can be reorganized online or offline
when the Partition Data Table option is selected.
Rebuild - only an entire index for a table can be rebuilt online (this process can take some
time), but a partition or an entire index for a table can be rebuilt offline when the Partition
Data Table option is selected.
SQL Server 2014

Standard Edition
and earlier
Offline
Supported
Reorganize - only an index for a table can be rebuilt offline when the Partition Data Table
option is selected.
Rebuild - only an index for a table can be rebuilt offline when the Partition Data Table
option is selected.
SQL Server
Express Edition
Not supported
Index Maintenance in not recommended for large tables (over 10 GB).
Offline


For SQL Server 2014 databases, and prior versions, if you select this option set maintenance mode to reorganize.
Note: This option is not available in the Microsoft SQL Express edition.
Note: On very large tables (over 10 GB), running index maintenance may not complete in a reasonable amount of time.

Dynamic: The maintenance is determined by the edition of SQL Server. If you're using SQL Server Enterprise Edition, then Online
mode is used for maintenance (if the chosen maintenance mode supports it); otherwise, Offline mode is used.
concurrency but demands more resources. Choosing "Rebuild" above, and "Online" here requires SQL Server Enterprise Edition
(SQL Server Standard Edition and earlier do not support online index rebuilding).
Offline: The QoS tables are unavailable for update and query during the data maintenance period. Benign alarms may be generated
about failures to insert QoS data during the maintenance period, but the data will be re-inserted by data_engine at a later time when
the tables are once again made available for update.
is performed.
maintenance).
Oracle


Quality of Service
Scheduler
Minutely
Hourly

Prerequisites
http://rpmfind.net
Contents
Prerequisites
The General Tab
Partitioning of Raw Sample Data (SQL Server)
The Database Tab
MySQL Options
Oracle Options
The Schedule Tab
The General Tab


MySQL.
Note: This option is only available for Microsoft SQL Server Enterprise Edition. It is not available in the Microsoft SQL Express edition.

Important! It is not possible to rebuild the index for single partitions prior to SQLServer 2014. You can only reorganize individual
partitions. Performing automatic indexing for very large tables from the data_engine is strongly discouraged, as indexing may not
complete in a reasonable amount of time
Important! This option is not supported if partitioning is enabled on SQL Server.
Important! When using the Partitioning feature, schedule maintenance to run daily.The time required to execute the partitioning
depends on amount of data as well as performance of disk subsystem but can for large installations take several hours or even up to
several days.
The sample data tables can be partitioned in order to achieve improved performance.
The sample data will be partitioned by day so if you for instance have configured the system to delete raw sample data older than 365 days, then
the sample data tables (RN_QOS_DATA_xxxx) will each be configured with 365 partitions (plus a few extra partitions in order allow for faster
maintenance).
SQL Server: If using partitioning then the property Delete raw data older than must be between 1 and 900. SQL Server, up to and including 2008
SP1, limits a table to 1000 partitions.
The partitioning will contribute to improved performance when accessing the raw sample data tables:
higher insert rates
faster read access to data
faster data maintenance (delete/compress of sample data)
faster index maintenance
You enable/disable the partition by checking or unchecking the Partition data tables checkbox in the data_engine configuration dialog.
If the state of the data_engine partitioning table changes, you will then be asked to choose how to execute the partitioning:
If you chose "Start now" you'll be asked to define for how long you'll allow the partitioning to run, and a confirmation message box will
show the progress of the execution compared to the length of time you specified. A successful completion message will be displayed
when the partitioning successfully has been executed.
You can let the scheduled maintenance execute the partitioning by choosing "Run at maintenance". In this case the partitioning will be
executed before the actual data maintenance is executed.
When using the Partitioning feature all maintenance activities will be optimized to use the optimizations partitioning offers, in particular
Purging of raw sample data will be done by dropping partitions
Index maintenance will be done on last partition only (SQL Server only)
While the default settings for partitioned maintenance will work well for most installations running daily maintenance, it is possible to override
these settings. Go to Override Default Partition Maintenance Settings for further details.

read-only.
The Database Tab

MySQL
Oracle
dap.

MySQL Options
Oracle Options

The Schedule Tab

Range
maintenance starts.

This article provides the procedures to use to configure the data_engine probe.
Prerequisites
Verify that you have the proper permissions to access a Microsoft SQL Server database when you are not using the sa login. See SQL
Authentication on Microsoft SQL Server.
Oracle
Before partitioning an Oracle database, review prerequisites to ensure that you have enabled the Oracle Partitioning Option and have
enough free disk space to create a partitioned interim table that is used during the partitioning process.
Contents
Prerequisites
SQL Authentication on Microsoft SQL Server

Verify Tablespace Before Partitioning an Oracle Database

Set up Partitioning for Raw Sample Data
Set up Index Maintenance (MS SQL Server)
To open the data_engine configuration GUI:
1. In the Admin Console navigation pane, click the down arrow next to the hub, then the robot the data_engine probe resides on.
2. Click the down arrow next to the data_engine probe, and select Configure.

Follow these steps:

5. Click Save.

Follow these steps:
3. Click Save.

Follow these steps:

4. Click Save.

Follow these steps:

database vendor.
4. Click Save.

Verify Tablespace Before Partitioning an Oracle Database

online.
script:
select
segment_name
table_name,
from
user_extents
where
and

heading "%|Used"
column name
format a19
column Kbytes
format 999,999,999
heading "KBytes"
column used
format 999,999,999
heading "Used"
column free
column largest
break
on report
pct_max_used
tablespace_name
tablespace_name
union all
tablespace_name
order by PCT_USED
/

FROM
V$temp_space_header

Oracle and Microsoft SQL Server Enterprise Edition databases are partitioned online, meaning the data_engine can continue to write data to
tables. You can set up partitioning to improve performance when accessing the raw sample data tables.
Follow these steps:
4. Click Save.

Follow these steps:
6. Click Apply.

data_engine
Probe Information
MySQL
Oracle
Quality of Service
Scheduler
data_engine
Probe Information


displayed, you might need to update the table statistics. For more information, see Out-of-date Information in the Quality of Service
Type Status Table.
UIM.
vendor:
MySQL
Microsoft
Oracle
MySQL


Important for users of database partitioning: SQL Server 2012 and earlier can only reorganize the indexes for individual partitions
and cannot rebuild them. For this reason, if you have enabled partitioning for your UIM database, you should set maintenance mode to
Reorganize. However, if you have large tables in your environment, automatic indexing from the data_engine is discouraged, as index
maintenance may not complete in a reasonable amount of time. In this case, you can disable automatic indexing and work with your
DBA to design a custom solution to manage the index maintenance for your database.
Dynamic: The maintenance is determined by the edition of SQL Server. If SQL Server is the Enterprise Edition, then Online mode is
used for maintenance (if the chosen maintenance mode supports it); otherwise, Offline mode is used.
Note: Setting maintenance mode to Rebuild, and setting online mode to Online requires SQL Server Enterprise Edition.
SQL Server Standard Edition and earlier does not support online index rebuilding. If you're unsure of the SQL Server edition
you're using, set online mode to Dynamic.
Offline: The QoS tables are unavailable for update and query during the data maintenance period. Benign alarms might be generated
for failure to insert QoS data during the maintenance period, but the data will be re-inserted by data_engine at a later time when the
tables are once again made available for updates.
is performed.
Note: This option is only available for Microsoft SQL Server Enterprise Edition. It is not available when using the Microsoft SQL Express
edition.
maintenance).
Oracle


Quality of Service

Scheduler
Minutely
Hourly

Prerequisites
http://rpmfind.net
Contents
Prerequisites
The General Tab
The Database Tab
MySQL Options
Oracle Options

The Schedule Tab
The General Tab


MySQL.

Important! It is not possible to rebuild the index for single partitions prior to SQLServer 2014. You can only reorganize individual
partitions. Performing automatic indexing for very large tables from the data_engine is strongly discouraged, as indexing may not
complete in a reasonable amount of time
Important! This option is not supported if partitioning is enabled on SQL Server.

several days.
maintenance).
higher insert rates

read-only.
The Database Tab

MySQL
Oracle
dap.


MySQL Options
Oracle Options

The Schedule Tab

Range
maintenance starts.

This article explains how to edit the data_engine probe.
Prerequisites
Oracle Database Prerequisite: Verify Tablespace Before Partitioning an Oracle Database
Upgrade Prerequisites for Deployments with an Oracle Database
Set up Index Maintenance (MS SQL Server and Oracle)
Set up Partitioning for Raw Sample Data (MS SQL Server and Oracle)
Prerequisites
If you are using SQL Authentication on Microsoft SQL Server, see SQL Authentication on Microsoft SQL Server.
Review Preparing to Partition Your Oracle Database to ensure that you you have enabled the Oracle Partitioning Option and have enough free
disk space to create a partitioned interim table that is used during the partitioning process.
Before upgrading UIM Server 8.0 in deployments with an Oracle database, you must grant the appropriate user permissions. See Upgrade
Prerequisites for Deployments with an Oracle Database for details.


Oracle Database Prerequisite: Verify Tablespace Before Partitioning an Oracle Database

your database, the partitioning process can take a few minutes, several hours, or possibly several days and can be resource intensive. In addition
to the processing time required to complete partitioning, the partitioning process requires the availability of enough free disk space to create a
partitioned interim table. The partitioning process copies the contents from the original data tables into the interim data tables, swaps the original
data tables and interim data tables, and finally deletes the original data tables. This process is performed while the tables and indexes are online.
script:
select
segment_name
table_name,
from
user_extents
where
and

heading "%|Used"
column name
format a19
column Kbytes
format 999,999,999
heading "KBytes"
column used
format 999,999,999
heading "Used"
column free
column largest
break
on report
pct_max_used
tablespace_name
tablespace_name
union all
tablespace_name
order by PCT_USED
/

FROM
V$temp_space_header
Upgrade Prerequisites for Deployments with an Oracle Database

Before upgrading UIM Server 8.0 in deployments with an Oracle database, you must grant the appropriate user permissions. Grant the
permissions using a tool such as Oracle SQL Developer. You must be logged in as SYSDBA. The command to grant user permissions is:
grant execute on dbms_redefinition to <UIM_USER>;
If the upgrade is performed before you grant the appropriate user permissions, UIM Server errors will occur during scheduled maintenance for
data_engine. The following error message appears in the data_engine log file:
SPN_DE_DATAMAINT is invalid
To correct this situation, use the following procedure to grant the appropriate permissions and recompile the stored procedures.
Follow these steps:
1. Log in to the database server as SYSDBA and execute:
grant execute on dbms_redefinition to <UIM_USER>;
2. Use a tool such as Oracle SQL Developer to recompile the following stored procedures:SPN_DE_DATAMAINT
SPN_DE_DATAMAINTDELETEOLDDATA
SPN_DE_UNPARTITIONTABLE
SPN_DE_PARTITIONTABLE
SPN_DE_UPDATEQOSDEFMETRIC
3. Execute run_admin_now to perform data maintenance.

To open the data_engine configuration GUI:
1. In the Admin Console navigation tree, click the down arrow next to the hub, then the robot the data_engine probe resides on.
2. Click the down arrow next to the data_engine probe, select Configure.

Follow these steps:

5. Click Save.

Follow these steps:
3. Click Save.

Follow these steps:
4. Click Save.

You can set up Index Maintenance to improve the speed of data retrieval operations.
Follow these steps:
database vendor.
Important! (Oracle) If you have partitioned your Oracle data tables, there is no need to select the Index Maintenance option.
4. Click Save.
You can set up partitioning to improve performance when accessing the raw sample data tables.
Follow these steps:
2. Select the Partition Data Tables check box.
3. Click Save.

Follow these steps:
6. Click Apply.

data_engine
Probe Information
MySQL
Oracle
Quality of Service
Scheduler
data_engine
Probe Information


displayed, you might need to update the table statistics. For more information, see Out-of-date Information in the Quality of Service
Type Status Table.
vendor:
MySQL
Oracle
MySQL



Important! It is not possible to rebuild the index for single partitions prior to SQL Server 2014. You can only reorganize individual
partitions. Performing automatic indexing for large tables from the data_engine is discouraged, as indexing might not complete in a
reasonable amount of time.
Dynamic: The maintenance is determined by the edition of SQL Server. If SQL Server is the Enterprise Edition, then Online mode is
used for maintenance (if the chosen maintenance mode supports it); otherwise, Offline mode is used.
is performed.
Note: This option is only available for Microsoft SQL Server Enterprise Edition. It is not available when using the Microsoft SQL Express
edition.
maintenance).
Oracle


Quality of Service
Scheduler
Minutely
Hourly

Prerequisites
http://rpmfind.net
Contents
Prerequisites
The General Tab
The Database Tab
MySQL Options
Oracle Options
The Schedule Tab
The General Tab


MySQL.
Note: This option is only available for Microsoft SQL Server Enterprise Edition. It is not available in the Microsoft SQL Express
edition.

Maintenance mode
Defines how the indexes are maintained. The available options are:
Note: It is not possible to rebuild the index for single partitions prior to SQLServer 2014. You can only reorganize individual
partitions. Performing automatic indexing for very large tables from the data_engine is strongly discouraged, as indexing may
Online mode
Defines the effect of maintenance on concurrent use of the QoS tables.
Note: The online maintenance option is not supported if partitioning is enabled on SQL Server.
The available options are:

Fragmentation Level
The fragmentation level information is used if Index name pattern is anything other than "All". The available options are:
Index name pattern
The indexes that are maintained. The default is Blank, which indicates a blank entry that results in all indexes being considered for maintenance.

several days.
maintenance).
higher insert rates

read-only.
The Database Tab

MySQL
Oracle
dap.
MySQL Options
Oracle Options


The Schedule Tab

Range
maintenance starts.
data_engine IM Basic Benchmarking

Configuration Parameters
Flushing Data to SQL Server Rules
Enable Throughput Logging
Viewing Output
What Does the Log File Contain?
Unified Infrastructure Manager has a built-in basic throughput logging capability for the data_engine probe. If this option is turned on, the
data_engine will start logging values to a text file indicating what is flowing through the data_engine (number of messages), and how much time
the data_engine spent at various checkpoints.
Configuration Parameters
bucket_flush_size = 5000
Number of allowed buckets before its flushed
bucket_flush_time = 5
Number of seconds before flushing a bucket
dispatcher_time = 1000
Number of milliseconds to spend in dispatcher loop
hub_bulk_size = 20
Number of messages to receive each time from hub
thread_count_insert = 0
Number of preallocated threads used to commit data to database. If this key is zero or not present, serial mode will be used. If this
number is 1 or higher, the number indicates the number of threads that will be preallocated for the commit task.
queue_limit_total = 100000
This number indicates how many messages you want to allow data_engine to keep in memory before suspending reading messages
from hub. This configuration is used in case committing to the database server starts to fall behind.
Note: The more rows you have in memory, the more data will potentially be lost if there is a power surge or data_engine crashes for an
unknown reason.
Flushing Data to SQL Server Rules

The data to be flushed to database server are determined on two criteria:
1. If a list reaches a configurable amount of messages (default 5000 messages) it will be written to the database.
2. If the data in a list is more than x seconds old (default 5 seconds), it will be written to the database.
Note that these rules are checked when QoS thread is iterating over all RN bulk objects and not during the time it is subscribing to messages.
This means more than 5000 messages per commit may be written to the database.
Enable Throughput Logging

Logging is enabled on the General tab of the probe configuration GUI.
Viewing Output
The text file will be updated continuously after each QoS thread cycle, meaning after one round of dispatching messages, one round of iterating rn
buckets to commit data to database.
User may want to use a utility which can tail files, otherwise you need to close and reopen the file.
What Does the Log File Contain?

The name of the log file will be the name of the queue + .txt
For example: If user is draining data_engine main queue, the text file will be data_engine.txt.
The output of the log might look something like this:
AT: 2010-09-03 11:41:19

time
msg per sec msg
2010-09-03 11:41:20 0
2010-09-03 11:41:21 0
2010-09-03 11:41:22 18
2010-09-03 11:41:23 0
queue: data_engine flags: Unpack, Process, Sort, Commit

count
time dispatcher time callback
time commit time tot
0
999 0
0
999 0
0
0
0
0
202 0
0
202 0
0
0
0
20 1000
2
50 1063
20 5
0
5
0
999 0
0
999 0
0
0
0
There is basic header information, which includes the following:

1. Timestamp
2. Name of queue being processed
3. Operation mode flags (documented earlier in this document)
There are 11 columns, separated by tabular character, they are:
1. Time: The time this line in the log was written.
2. Msg per sec: A calculated value showing current throughput (messages per second, based on the number of messages last "dispatcher
time" divided by "total time")
3. Msg count: Number of messages received during last "dispatcher time"
4. Time dispatcher: The amount of milliseconds data_engine used receiving and processing QoS messages from hub during last iteration.
5.
5. Time callback: The amount of milliseconds data_engine used to validate and sort QoS messages into RN bulk objects.
Note: The callback time is included as part of the "dispatcher time", which covers both receiving and validating/sorting
messages.
6. Time commit: The amount of milliseconds data_engine used last iteration to bulk commit data to database server.
7. Time total: The summarized time in milliseconds data_engine used both in dispatcher and committing data to database server. This also
includes the time data_engine used to check if connection was still up.
8. Rows committed: Number of rows committed last iteration
9. Lists flushed: This is the number of RN bulk objects that had data in them that were just flushed to database server
10. Lists flushed size: The number of lists (of the total lists flushed) that were flushed because they exceeded the number of messages we
need before a bulk insert is conducted.
11. Lists flushed time: The number of lists (of the total lists flushed) that were flushed because the age of the data in the lists exceeded the
allowed delay before committing to database server.
To turn off the logging, user can call the log_statistics callback again and pass in parameter log_stats = no.
The output of the log might look something like this for parallel mode:
Start: 2011-01-24 12:17:47 queue: data_engine flags: Unpack, Process, Sort, Commit,
time
used ms
| hub/s
proc/s
com/s
|
mem
| com
-----------------------------------------------------------------------------------2011-01-24 14:44:51
999
|
0
14
0
|
19
|
2011-01-24 14:44:52
1000
|
0
0
0
|
19
|
2011-01-24 14:44:53
1005
|
0
0
18
|
0
|
2011-01-24 14:44:54
999
|
0
0
0
|
0
|
2011-01-24 14:44:55
1000
|
0
0
0
|
0
|
2011-01-24 14:44:56
1000
|
0
0
0
|
0
|
The header is the same as for serial mode.

There are 10 columns in the report, they are:
1. Time: The time at which this line in the log was written
2. Used ms time: the amount of milliseconds that was used in the dispatcher (reading messages from hub. Even though this is for example
configured 1 second, there is no guarantee that it will run for 1 second. This reported number is the amount of milliseconds it actually is
active.)
3. Hub/s: This is the number of messages we did process during the time given, divided by the "used ms time" which yields approximately
messages per second throughput. The rate we can read messages from the hub.
4. Proc/s: the amount of messages that has been processed for the given time, divided by the "used ms time" which yields approximately
messages per second.
5. Com/s: the amount of messages committed to database server (summarized for all the worker threads that do database commit) divided
by the "used ms time", to give an approximately throughput of how many messages we can commit to database server per second.
6. Mem: this column reports the current number of messages in memory in data_engine when this log line is written (messages stored in
RN bulk objects, not yet committed to database server).
7. Committed: number of messages committed during the last round of dispatcher time.
8. Buckets: Number of bulk objects that were flushed total.
9. Time: Number of bulk objects (of the number in "Buckets") that was flushed because of the aging rule (more than x seconds since last
time bucket was committed)
10. Size: Number of bulk objects (of the number in "Buckets") that was flushed because of the size rule (more than x messages in bucket =>
flush/commit)
data_engine Best Practices

The data_engine performs most tasks with little or no interaction from the administrator. However there are some configurations that can improve
performance.
data_engine Probe Location

Thread Count
Hub Bulk Size
data_engine Probe Location

In order to reduce the network traffic, run the data_engine on a Hub as close to the database server as possible.
Thread Count
Multi-threading is not enabled by default in the data_engine probe. To increase data_engine performance, you can increase the number of
threads for the thread_count_insert parameter in Raw Configure. The optimum thread count is highly dependent on several factors, including:
The number of CPUs running on the system.
The number of RN tables in the UIM database.
The size of your CA UIM deployment.
Hub Bulk Size

By default, the hub bulk size is set to 20. A low bulk size is optimal for small environments with small message rate throughput in the data_engine.
However, if your UIM deployment has a high message rate you can increase the hub_bulk_size parameter in Raw Configure to values in the
1800-2000 range. This action increases the number of QoS messages that are sent at once between the hub and data_engine.
data_engine Troubleshooting
This article provide troubleshooting information for issues you might encounter while upgrading, configuring, or using different version of the
data_engine probe.
Upgrading to a Newer Version of CA UIM with an Oracle Database

Data Maintenance on an Oracle Database Doesn't Work After Upgrading From NMS 7.6
S_QOS_SNAPSHOT Database Table Missing Updates
Viewing the Log File
Corrupted QoS Definition Values
Out-of-date Information in the Quality of Service Type Status Table
Table Statistics for Oracle
Table Statistics for MySQL
Table Statistics for Microsoft SQL Server
Check Microsoft SQL Server Partitioning Jobs
Upgrading to a Newer Version of CA UIM with an Oracle Database

Symptom:
(Oracle databases only) My Oracle database is unpartitioned before I upgrade to a newer version of CA UIM. After the upgrade is complete, I do
not partition my Oracle database before I start to use CA UIM. When I attempt to perform data maintenance, it fails and an error similar to the
following appears in the data_engine log file:
[140713318672128] de: Data Maintenance - RC: -1000 [ORA-20008:

spn_de_DataMaint_DeleteOldData: Error: -20005 ORA-20005:
spn_de_CreateBNTableIndex: Error: -1408 ORA-01408: such column list
already indexed], Purge: RN_QOS_DATA_0021, Error, Raw Rows:0,
Time used: 204 ms ~= (0 seconds) (QOS_ORACLE_CHECK_DBALIVE)
Solution:
The index names for the BN and RN tables used by older versions of data_engine (versions 7.6 and earlier) do not match the index names for the
index tables used by the data_engine v8.0 and later. If you partition the Oracle database after an upgrade, the index names for the BN and RN
tables are updated. However, if you do not partition the Oracle database after upgrading to a newer version of CA UIM, the old index names
remain for the BN and RN tables and data maintenance fails. To correct this issue, run the following stored procedures on your Oracle database.
Script to change IDX2 to IDX0 for all the RN tables:
set serveroutput on size 30000;

declare
lOldIndex
varchar2(80);
lNewIndex
varchar2(80);
lCmd
varchar2(255);
cursor lCursorIndexes is
select INDEX_NAME
from user_indexes
where index_name like '%_IDX2'
AND table_name like 'RN_QOS_DATA_%';
begin
for lIdx in lCursorIndexes loop
lOldIndex := lIdx.INDEX_NAME;
lNewIndex := lOldIndex;
dbms_output.put_line(lNewIndex);
lNewIndex := replace(lNewIndex, '_IDX2','_IDX0');
lCmd := 'ALTER INDEX ' || lOldIndex || ' RENAME TO ' ||
dbms_output.put_line(lCmd);
EXECUTE IMMEDIATE lCmd;
end loop;
end;
Script to change the IDX2 to IDX1 for all the BN tables:
lNewIndex;
set serveroutput on size 30000;

declare
lOldIndex
varchar2(80);
lNewIndex
varchar2(80);
lCmd
varchar2(255);
cursor lCursorIndexes is
select INDEX_NAME
from user_indexes
where index_name like '%_IDX2'
AND table_name like 'BN_QOS_DATA_%';
begin
for lIdx in lCursorIndexes loop
lOldIndex := lIdx.INDEX_NAME;
lNewIndex := lOldIndex;
lNewIndex := replace(lNewIndex, '_IDX2','_IDX1');
lCmd := 'ALTER INDEX ' || lOldIndex || ' RENAME TO ' ||
dbms_output.put_line(lCmd);
EXECUTE IMMEDIATE lCmd;
end loop;
end;
lNewIndex;
Data Maintenance on an Oracle Database Doesn't Work After Upgrading From NMS 7.6
Symptom:
(Oracle databases only) I upgraded from NMS 7.6 to a newer version of CA UIM. When I attempt to partition my Oracle database, data
maintenance is not performed and I receive the following error in the data_engine log file:
ORA-01031: insufficient privileges
Solution:
Execute the grant command as sysdba before or after upgrading from NMS 7.6 to CA UIM 8.0 or later.
Follow these steps:
1. Log in to the database server as SYSDBA using a tool such as Oracle SQL Developer and execute:
grant
grant
grant
grant
grant
grant
execute on dbms_redefinition to <db_owner>;

alter any table to <db_owner>;
select any table to <db_owner>;
create any table to <db_owner>;
drop any table to <db_owner>;
lock any table to <db_owner>;
2. Recompile the stored procedures in the CA UIM schema.

3. Run data maintenance again.
Note: When you do an upgrade from a fresh install of CA UIM 8.0 or later, the appropriate user permissions to an Oracle
database are granted and it is not necessary to run the grant command.
S_QOS_SNAPSHOT Database Table Missing Updates

Symptom:
It looks like my S_QOS_SNAPSHOT database table is not updating properly. For example, when I look at the table, I see no new values added to
the table or there are null values for new QoS metrics.
Solution:
If you have a smaller system that is monitoring less than 20 QoS metrics, change the value for the thread_count_insert parameter to zero in Raw
Configure.

Advanced users may find it helpful to view the log file. To view the log file, click the data_engine probe and select View Log. You also can modify
the log file settings so that it retains more data for troubleshooting.
Corrupted QoS Definition Values

Symptom:
I see corrupted QoS Definition values in QoS data within reports or dashboards, for example user-defined units
such as degrees F or C, watts, etc. being labeled variant". Customized QoS definition units have been incorrectly replaced (overridden) by
data_engine version 7.85 (NM Server 5.60) or data_engine 7.86 (NM Server 5.61).
Solution:
Versions 7.87 through 7.90 of data_engine include a patch utility to recover and restore customized QoS definition units incorrectly replaced
(overridden) by data_engine version 7.85 (NM Server 5.60) or data_engine 7.86 (NM Server 5.61). This patch utility uses a conditional override
approach that corrects the issue.
Follow these steps:
1. From a command prompt, navigate to the directory that contains the utility:
(Unix) cd <UIM install location>/probes/slm/data_engine/tools

(Windows) CD <UIM install location>\probes\slm\data_engine\tools
2. Execute the tool in report mode (-r flag set) with the java version installed with UIM Server (formerly name NM Server):
(Unix) ../../../../jre/jre1.6.0_24/bin/java -jar qos_def_unit_repair_kit.jar -r

(Windows)..\..\..\..\jre\jre1.6.0_24\bin\java -jar qos_def_unit_repair_kit.jar -r
3. The patch utility scans the S_QOS_DEF_SKIP_UNIT table in the database and finds QoS Definitions that are suspected to be corrupt.
Important! The S_QOS_DEF_SKIP_UNIT table holds QoS definition values that should not override what is sent by a QoS
probe. This table is pre-populated with three values: variant, none, and user defined.
If you have defined additional custom values, which have been incorrectly overridden by a previous data_engine version, add these
values as new rows to the S_QOS_DEF_SKIP_UNIT table prior to step 5 below, so that the patch utility will find, report, and fix them
as well. (Use standard database management tools to connect to the NIS database and add the rows and new values to the
S_QOS_DEF_SKIP_UNIT table.)
The report generated by the utility shows corrupt QoS Definitions (if any) and the probe or probes associated with that data. Here is an
excerpt from an example report:
List current problems...
S_QOS_DEFINITION { name=QOS_CPUSAMPLECOUNT, qosDefId=12, group=QOS_VMWARE, unit=none,unitShort=sc }

S_QOS_DATA { source=esxiqa1.i9.x, target=CPU sample count, origin=w2k8-vm0hub, host=10.0.0.1, robot=w2k8-vm0, probe=vmware }
S_QOS_DEFINITION { name=QOS_SNMP_VARIABLE, qosDefId=11, group=QOS_SNMP_VARIABLE, unit=variant, unitShort=value }
S_QOS_DATA { source=w2k8-vm0, target=interfaces.ifTable.ifREntry.ifOutOctets.1, origin=w2k8-vm0hub, host=10.0.0.1,
robot=w2k8-vm0, probe=snmpget }
S_QOS_DATA { source=w2k8-vm0, target=system.sysServices.0, origin=w2k8-vm0hub,host=10.0.0.1, robot=w2k8-vm0, probe=snmpget
}
End of current problems list.
Running in report-only mode.
4. Run the utility without the -r flag set to make repairs:

(Unix) ../../../../jre/jre1.6.0_24/bin/java jar qos_def_unit_repair_kit.jar
(Windows)..\..\..\..\jre\jre1.6.0_24\bin\java jar qos_def_unit_repair_kit.jar
The utility subscribes to the UIM message bus to receive QoS Definitions and corrects any in the database that have been incorrectly
replaced.
5. Restart each of the probes listed in the report. In the example above the vmware and snmpget probes would be restarted so that the
correct units are received. Probes are identified at the end of each S_QOS_DATA listing in the report. For example:
S_QOS_DATA { source=esxiqa1.i9.x, target=CPU sample count, origin=w2k8-vm0hub, host=10.0.0.1, robot=w2k8-vm0, probe=vmware }
Once the patch utility has repaired all QoS Definitions it does not need to be run again and no other action is required.
Out-of-date Information in the Quality of Service Type Status Table

Symptom:
I see out-of-date information in the Quality of Service Type Status Table.
Solution:
Table statistics are collected by database software to create the best execution plan for a query. Some examples of collected statistics include:
Rows that are stored in a table
Available indexes
How many pages store the rows
The data_engine probe uses these table statistics to generate the Quality of Service Type Status table. Table statistics can be manually updated
if they become out of date.
The procedure for updating the table statistics is different for each database vendor:
Important! Updating table statistics significantly impacts performance on all database platforms, especially on larger databases.

To receive correct statistics in Oracle, following the instructions found at:
http://docs.oracle.com/cd/B28359_01/server.111/b28274/stats.htm#PFGRF003

To receive correct statistics in MySQL, run one of the following queries on all RN_, HN_, BN_, and DN_ tables:
ANALYZE table RN_QOS_DATA_XXXX ESTIMATE STATISTICS; - Samples from the table are taken and stored in the data dictionary.
ANALYZE table RN_QOS_DATA_XXXX COMPUTE STATISTICS; - The entire table is analyzed using a full table scan and stored in the
data dictionary.
Using the ANALYZE command in MySQL can be a time-consuming operation, especially for large databases. Only perform the command
sporadically and do not use Automated Maintenance Tasks.
In MySQL, the ANALYZE command holds a read lock on tables, which can negatively impact database performance.
For more information, refer to the following MySQL documentation:
http://dev.mysql.com/doc/refman/5.5/en/tables-table.html
http://dev.mysql.com/doc/refman/5.6/en/analyze-table.html

Normally table statistics are automatically managed by the SQL Server. However, this functionality does not work in some cases.
For example, if you are performing bulk inserts using the OLE DB FastLoad API, the statistics for data tables are not automatically updated. This
can lead to poor performance and extra work for SQL Server.
The data_engine probe contains options that can automatically update statistics for Microsoft SQL Server. The code is in a stored procedure in
the SLM database that is named spn_de_UpdateStatistics.
Updating tables statistics in Microsoft SQL server causes queries to recompile. For more information, refer to the following Microsoft SQL
documentation:
http://msdn.microsoft.com/en-us/library/ms187348.aspx
http://msdn.microsoft.com/en-us/library/ms187348(v=sql.100).aspx
The behavior can be controlled with the following variables in the raw configure menu:
Key name
Default value
Type
statistics_age
24
Time in hours. This means when the stored procedure is called, statistics that are older than this
number will be updated. This value is used by the stored procedure, not data_engine itself.
If this number is set to 0 (zero), statistics will be disabled and not be run at all by the
data_engine.
statistics_pattern
RN_QOS_DATA%
String pattern to which data tables will be updated.
statistics_loglevel
Numbers 0 to 5 used by the stored procedure when logging to tbnLogging.
statistics_time_pattern
<not set>
The scheduling string that determines when to run statistics. If this key is empty or not set, the
same schedule that is defined for data management will be used. This
means the statistics will be run when data_engine has finished index maintenance and data
management.
If this value is specified to a different schedule, the statistics will be updated independently of
when data management is scheduled.
The string will be used by the calendar scheduling library, which is used by various UIM
components. It supports RFC2445. See short example below.
Some string examples that are copied from the library help file.
/**********************************************************************
******************
** nimCalCreate - Creates a handle to a nimCal structure
***********************************************************************
******************
** PARAMETERS:
**
char
*pattern
- RFC2445 ,'weekly' or 'dts'
** char
*start
- startdate: yyyy-mm-dd [hh:mm:ss] || NULL
**
: weekly format 1 or 2
**
**
start = 'yyyy-mm-dd [hh:mm:ss]' will expect the 'pattern' to
comply with RFC2445.
**
= NULL results in setting start to 'now'
**
e.g.
**
h =
nimCalCreate("DTSTART:19970610T090000|RRULE:FREQ=YEARLY;COUNT=10",NULL)
;
**
h =
nimCalCreate("DTSTART:19970610T090000|RRULE:FREQ=YEARLY;COUNT=10","2007
-07-25");
**
** pattern = 'weekly' handles two 'start' formats:
**
1. 0123,10:00,14:00 [,NOT]
(old NAS
format)
**
2. MO=12:00-14:00,15:30-17:00;TU=08:00-16:00
(new, allow
8-16)
**
**
h = nimCalCreate("weekly","012,10:00,14:00");
**
h =
nimCalCreate("weekly","MO=12:00-14:00,15:30-17:00;TU=08:00-16:00");
**
h = nimCalCreate("dts","2007-08-20 08:00,2007-08-27
08:00,2007-09-03 08:00,2007-09-10"
**
** Note: Free the handle using nimCalFree.
***********************************************************************
*****************/
You can also create a schedule in nas and use the resulting string from there or use data_engine scheduler to create a string.
Check Microsoft SQL Server Partitioning Jobs

Use the following Microsoft SQL Server statement to determine which partitioning jobs are running:
SELECT sqltext.TEXT,
req.session_id,
req.status,
req.command,
req.cpu_time,
req.total_elapsed_time
FROM sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sqltext;
If the results display multiple "CREATE nonclustered index" statements, you have more than one partitioning job running.
To stop a partitioning job:
KILL [session_id]
db2 (DB2 Database Monitoring)

The DB2 Database Monitoring probe monitors DB2 instances, databases, table spaces, and applications. This probe uses the DB2 snapshot and
tablespace statistic APIs to extract information about your DB2 servers.
The DB2 Database Monitoring probe supports DB2 versions 10.1 and 10.5 only.
The probe monitors around 280 DB2 snapshots and statistic counters, and calculates values such as:
db_pool_hit_ratio
db_avg_sort_time
db_avg_sort_heap
db_pool_sync_reads
db_pool_sync_writes
db_pool_sync_write_time
app_avg_sort_time
app_pool_hit_ratio
app_avg_direct_read_time
app_avg_direct_write_time
app_cat_cache_hit_rto
app_locklist_util
bp_pool_hit_ratio
bp_pool_sync_reads
bp_pool_sync_writes
ts_usable_pages_pct
ts_used_pages_pct
ts_free_pages_pct
More information:
db2 (DB2 Database Monitoring) Release Notes
v4.0 db2 AC Configuration

You can configure the db2 probe by defining various profiles and connections to the DB2 server. The connections that you set up are used for
running monitoring profiles on the DB2 server. These profiles monitor real-time events occurring in the server using various checkpoints. You can
select the required checkpoints and activate the profile that notifies you when any unwanted event occurs in the server. The probe provides
predefined checkpoints that you can customize. For example, you can create a profile that uses db_status checkpoint to monitor the status of
database at a given time. You can also create checkpoints.
These profiles can also be configured to generate alarm and QoS messages.
The following diagram outlines the process to configure the db2 probe.
Contents
Set up General Properties
Create a Connection
Test the Connection
Create a Profile
Add Profile Checkpoints
Configure Checkpoints
Alarm Thresholds
Create Custom Checkpoints
Add Exclude Patterns
Use Regular Expressions
Verify that required hardware, software, and related information is available before you configure the probe. For more information, see db2 (DB2
Database Monitoring) Release Notes.

You can set up the logging and alarm severity conditions of the db2 probe. The probe uses the default settings if you do not configure the general
properties.
Follow these steps:
1. Select the db2 node and specify the following values as required:
Clear Alarm on Restart Only: enables you to clear all alarms when the probe restarts.
Default: Selected
Alarm Severity Filter: sets a filter on severity levels of an event that can become potential alarms. For example, as a database
administrator, you want to convey important events on to the operations center or help-desk, so that the event can trigger emails. The
Alarm Severity Filter considers the events matching or exceeding the selected severity level alarms. If you select major, then only
the messages with severity level as major and above are considered as alarms.
Default: clear
You can select from the following options:
clear
information
warning
minor
major
critical
Log Size(KB): specifies the maximum size of the probe log file.
Default: 100
LogLevel: specifies the level of details that are written to the log file. Log as little as possible during normal operations to minimize the
disk consumption, and increase the amount of detail when debugging.
Default: 2 - High
QoS V2 Compatibility: allows you to provide backward compatibility to the V2 framework.
All Database Status: enables you to retrieve status of all database instances except the default database.
2. Click Save.
Create a Connection
A connection can be used by more than one monitoring profile. The probe allows you to define connections that helps you monitor required
database instances.
Follow these steps:
1. Click the Options icon next to the db2 node in the navigation pane.
2. Click Create new connection option.
3. Enter a name of the connection in the Connection Name field.
4. Specify the User ID and password for connecting to the monitoring server.
5. Specify the DB Default Details as required:
DB Default Name(Manually): allows you to manually specify the database instance node and the associated database node that you
want to connect.
DB Default Name: allows you to select the database instance node and the associated database node that you want to connect.
Retry Attempts: allows you to specify the number of attempts made by the probe to connect in case of connection failure.
Default: 3
Retry Delay: allows you to specify the time that the probe waits between the two connection attempts.
Default: 5
Retry Delay(Units): allows you to specify the unit to measure the retry delay value.
Default: sec
Timeout: allows you to specify the time before considering a connection failure.
Default: 0
Timeout(Units): allows you to specify the timeout unit.
Default: sec
7. Click Submit.
Test the Connection
Navigate to db2 > Connection name > DB2 > Connection name node. Click Actions > Test Connection in the Connection Name node. If the
connection is successful, it returns the instance name and database name. If the connection is unsuccessful, the probe displays a failure
message.
Create a Profile
You can create multiple profiles that monitor the DB2 server performance using various parameters. The profile runs on the DB2 server using the
connections that you have defined.
Follow these steps:
1. Navigate to db2 > Connection name > DB2 > Connection name node and click the Options (icon).
2. Click the Create new profile option.
3. Enter a unique name of the profile in the Name field.
4. Select the connection to be used in the profile from the Connection field.
5. Click Submit.
The profile is saved.
Note: The probe adds default checkpoints to the profile, however, they are inactive by default. For more information about activating the
required checkpoint, see the Add Profile Checkpoints section.

When you create a profile, default checkpoints are added to it. You can also add more predefined checkpoints to this profile. Each checkpoint
corresponds to the real-time object that you want to monitor in the server.
Follow these steps:
1. Navigate to the required profile name node and click the Options icon.
2. Click Add profile checkpoints icon.
3. Select the checkpoints to be added from the Available list and click Submit.
The profile checkpoint is added to the profile.
You can configure the properties of a checkpoint to monitor the DB2 server performance or unwanted events. The checkpoint monitors the
corresponding real-time object in the DB2 server. When the configured profile runs on the DB2 server, the set criteria for the checkpoints are
scanned against the real-time objects. If any unwanted event occurs, the probe generates alarms or QoS messages.
Follow these steps:
1. Navigate to the checkpoint name node under the required profile.
Note: You can also configure a checkpoint from db2 > Checkpoints > checkpoint name.
All changes that are made to a checkpoint are applied to all instances of the checkpoint in the configured profiles.
2. Select Active to activate the checkpoint.

3. Specify the following values as required:
Description: allows you to specify additional information about the checkpoint.
Check Interval: allows you to specify the time interval at which the db2 database is scanned for the checkpoint.
Check interval (Units): allows you to specify the check interval unit. You can select any of the following units:
sec
min
hrs
Samples: allows you to specify the number of samples to calculate an average value. This average value is compared to the specified
alarm threshold.
Default: 1
When the probe starts, the average value from the number of available samples is calculated. For example, if you specify the Sample
s value as 3, the probe performs the following actions:
uses the first sample value in the first interval
uses the average of samples 1 and 2 in the second interval.
Clear message: allows you to specify the message name that is used for the clear alarm.
Clear severity: enables you to select the severity that is used for generating the clear alarm message.
Default: clear
clear
information
warning
minor
major
critical
Use Exclude: enables the exclude list, which defines objects that are excluded from monitoring.
4. Click Save to save the checkpoint configuration details.
Alarm Thresholds
allow the probe to:

You can define a custom checkpoint for monitoring the DB2 server.
Follow these steps:
1. Navigate to the Checkpoints node in the navigation pane.
2. Click the Options (icon) next to the Checkpoints node.
3. Click Create New Checkpoint option.
4. Enter the name of the checkpoint that you want to create in the Name field.
5. Specify the connection in the Connection Name field.
6. Specify the file name in the Query File field for storing the query.
7. Specify the query to retrieve the data for the checkpoint in the Query field.
8. Enable the Interval Modus check box to subtract the variable value from the value generated at the end of the interval.
If you select Interval Modus, the probe subtracts the variable value at the beginning of an interval from the value found at the end.
The probe uses this result for checking alarms and adds $column_interval_value.i to the list of message variables for each column
(threshold object). This list can be viewed in the Edit Threshold dialog box.
If you do not select the Interval Modus check box, the value of variable as returned from the query will be used for checking and
generating QoS.
9. Click Submit.
Add Exclude Patterns

You can define exclude patterns to define objects that you do not want to monitor for the checkpoint.
Follow these steps:
1. Click the checkpoints name node in the navigation pane.
2. Select Use Exclude check box in the Use Exclude Configuration section.
3. Click New in the Exclude List section.
4. Specify the regular expression in the Exclude Pattern field to omit the pattern from monitoring.
5. Click Test in the Action drop-down list.
Response dialog opens displaying the list of objects that are excluded. The excluded objects have their Exclude value set to 1.
Note: This test is possible only for running active profiles and checkpoints that you do not want to monitor on the checkpoint.
6. Click Save.
The exclude pattern is added to the checkpoint.

requires meta characters. The probe supports Perl Compatible Regular Expressions (PCRE) which are enclosed within forward slash (/). For
target string.
The db2 probe uses regular expressions to search patterns that are excluded from the template checkpoint. For example, you want to exclude the
pattern, no_connection in a given checkpoint. Specify /no_connection/ in the Exclude Pattern field and click Test in the Action drop-down list.
The probe searches the DB2 Server and excludes the specified pattern for monitoring. For more information on adding exclude patterns in a
checkpoint, see Add Exclude Patterns.
v4.0 db2 AC GUI Reference

This article describes the Admin Console interface and fields to configure the db2 (DB2 Database Monitoring) probe.
Contents
db2 Node
Checkpoints Node
<Checkpoint Name> Node
Monitors Node
Connection <Connection Name> Node
<Profile Name> Node
db2 Node
The db2 node contains the configuration details specific to the db2 probe. This node lets you view the probe information and configure the general
properties of the probe. You can also view a list of all alarm messages that are available in the probe.
Navigation: db2
db2 > Probe Information

db2 > General
This section lets you configure the setup properties of the probe.
Clear Alarm on Restart Only: enables you to clear all alarms when the probe restarts.
Default: Selected
Alarm Severity Filter: sets a filter on severity levels of an event that can become potential alarms. For example, as a database
administrator, you want to convey important events on to the operations center or help-desk, so that the event can trigger emails. The Ala
rm Severity Filter considers the events matching or exceeding the selected severity level alarms. If you select major, then only the
messages with severity level as major and above are considered as alarms.
Default: clear
clear
information
warning
minor
major
critical
Log Size(KB): specifies the maximum size of the probe log file.
Default: 100
LogLevel: specifies the level of details that are written to the log file. Log as little as possible during normal operations to minimize the
Default: 2 - High
QoS V2 Compatibility: Provides backward compatibility to the V2 framework.
All Database Status: enables you to retrieve status of all database instances except the default database.
db2 > Message pool
This section displays a list of all alarm messages available in the probe. You cannot edit any existing message, or cannot add a new message
Text: identifies the message text.
i18n_token: identifies the predefined alarms fetched from the database.
db2 > Options icon > Create New Connection
This section lets you create connections to database instances that the probe monitors. Specify the user ID, password, and server name to
connect to the instance.
Connection Name: specifies a unique name of the connection.
Description: specifies additional information about the connection.
User ID: specifies the user id with necessary authorization.
Password: specifies the valid password that is associated with the User ID.
DB Default Details:
DB Default Name(Manually): allows you to manually specify the database instance node and the associated database node that you
want to connect.
DB Default Name: allows you to select the database instance node and the associated database node that you want to connect, from
a pre-defined list.
Retry Attempts: specifies the number of attempts made by the probe to connect in case of connection failure.
Default: 3
Retry Delay: specifies the time that the probe waits between the two connection attempts.
Default: 5
Retry Delay(Units): specifies the unit to measure the retry delay value.
Default: sec
Timeout: specifies the time before considering a connection failure.
Default: 0
Timeout(Units): specifies the timeout unit.
Default: sec
Checkpoints Node
The Checkpoints node lets you create a checkpoint to monitor the DB2 database. The default checkpoints are in this node, and you can also
create custom checkpoints.
Navigation: db2 > Checkpoints
Checkpoint > Options icon > Create New Checkpoint
This section lets you create a checkpoint.
Name: specifies the name of the checkpoint.
Connection Name: specifies the name of the connection.
Query File: defines the query file name where the query is stored.
Query: defines the query for creating the checkpoint.
Interval Modus: subtracts the variable value from the value that is generated at the end of the interval.
If you select Interval Modus, the probe subtracts the variable value at the beginning of an interval from the value found at the end.
The probe uses this result for checking alarms and adds $column_interval_value.i to the list of message variables for each column
(threshold object). This list can be viewed in the Edit Threshold dialog box.
If you do not select the Interval Modus check box, the value of variable as returned from the query will be used for checking and
generating QoS.
<Checkpoint Name> Node

The checkpoint name node lets you configure the checkpoint attributes, such as general properties and exclude patterns.
Navigation: db2 > Checkpoints > checkpoint name
checkpoint name > General
This section lets you configure the general setup parameters of the checkpoint of the probe.
Checkpoint Name: specifies the name of the checkpoint.
Active: activates the checkpoint for monitoring.
Description: specifies additional information about the checkpoint.
Condition: specifies the conditional operator to evaluate threshold values.
Default: > =
Check Interval: specifies the time interval at which the db2 database is scanned for a checkpoint.
Check Interval(Units): specifies the check interval unit. You can select any of the following units:
sec
min
hrs
Samples: specifies the number of samples to calculate an average value. This average value is compared to the specified alarm
threshold.
Default: 1
When the probe starts, the average value from the number of available samples is calculated. For example, if you specify the Samples v
alue as 3, the probe performs the following actions:
uses the average of samples 1 and 2 in the second interval.
Clear severity: enables you to select the severity that is used for generating the clear alarm message.
Default: clear
clear
information
warning
minor
major
critical
Clear message: specifies the message name that is used for the clear alarm.
Use Exclude: enables the exclude list, which defines objects that are excluded from monitoring.
checkpoint name > Exclude List
This section lets you add an exclude list, which defines objects that you do not want to monitor.
Exclude Pattern: defines a regular expression on which the exclude functionality works.
checkpoint name > Checkpoint Config
This section lets you configure the checkpoint.
Query File: defines the query file name where the query is stored.
Query: defines the query statement.
Interval Modus/ Report Per Second Metric: subtracts the variable value from the value that is generated at the end of the interval.
Note: This section appears only for the custom checkpoints.
checkpoint name > Row Identifier

This section lets you pick the rows as variables to set an alarm message and suppression key. If the query returns more than one row, the probe
needs a unique identification for each row.
checkpoint name > Message Variable

This section lets you select the columns as variables used for creating alarm messages. You can select the column and variables from a list of all
available columns and their possible usage.
Data Type: specifies the data type of the variable of the new alarm message.
Column Use: specifies the column use of the variable.
Monitors Node
The Monitors node lets you view and define the QoS and thresholds for monitoring the checkpoint.
Navigation: db2 > Checkpoints > checkpoint name > Monitors
Monitors > Quality of Service
This section lets you configure the QoS for the checkpoint.
Description: defines the additional information about the QoS.
Unit: defines the QoS unit.
Abbreviation: defines the QoS abbreviation.
Metric: specifies the metric to be used for the checkpoint QoS.
Max value: specifies the maximum value of the QoS.
Object: specifies the name of the database object that you want to monitor.
Monitors > Threshold
This section lets you configure threshold values for a checkpoint.
Threshold object name: displays the name of the threshold object. The probe uses this field value as default for a checkpoint.
Threshold value: specifies the value that is used for threshold evaluation.
Severity: specifies the severity level of the alarm message that is generated for the threshold.
Message: specifies the message name used.
Message Text: specifies the message text containing variables that are replaced at run time. If the message text is changed from a
profile list, you must create a new message.
Connection <Connection Name> Node

The Connection-connection name node displays information about the properties of the connection setup.
Navigation: db2 > Connection-connection name
Connection-connection name > Connection Setup
This section displays the attributes of the connection setup.
Note: The field descriptions are the same as described in Create New Connection section in the db2 node.

The connection name node lets you view and modify the connection setup properties.
Navigation: db2 > Connection-connection name > connection name
connection name > Edit Connection
This section lets you modify the connection setup properties.
Note: The field descriptions are the same as described in Create New Connection section in the db2 node.
connection name > Options icon > Create new profile

This section lets you create a profile, which enables to execute the checkpoints for a particular connection.
<Profile Name> Node

The profile name node lets you modify the profile parameters.
Navigation: db2 > Connection-connection name > profile name
profile name > Profile
This section allows you to modify the parameters of the profile.
Active: activates the profile for monitoring, after creation.
Description: specifies additional information about the profile.
Heartbeat: specifies the interval at which all profile checkpoint schedules are tested and executed.
Default: 10
Note: This number is a common denominator to all used check interval values. The higher the value the lower is the profile
overhead.
Heartbeat(Units): specifies the heartbeat unit.
Default: sec
Connection: specifies the connection that is used in the profile. The drop-down list displays the list of connections that you have defined
to connect to the DB2 database.
Check Interval: specifies the time interval at which the DB2 database is scanned. Reduce this interval to generate alarms frequently.
Default: 1
Check Interval(Units): specifies the check interval unit.
Default: min
Clear message: specifies the message for the timeout clear alarm message.
Default: p_timeout_1
SQL Timeout: specifies the SQL query timeout. Every checkpoint query runs asynchronously. In case the query reaches the SQL
timeout, the checkpoint processing is terminated. The probe starts processing the next checkpoint and issues an alarm message.
Default: 15
SQL Timeout(Units): specifies the SQL Timeout unit.
Default: sec
Message: specifies the message name that is used for SQL timeout alarm.
Default: sql_timeout_1
Profile Timeout: specifies the maximum processing time for all checkpoints in the profile. If this timeout is reached, the interval
processing finishes and the probe waits for next heartbeat to evaluate any checkpoint schedules. Alarm message is issued.
Default: 10
Profile Timeout(Units): specifies the profile timeout unit.
Default: min
Message: specifies the profile timeout message.
Default: p_timeout_1
Timeout Severity: defines the severity for timeout messages.
Default: major
Alarm Source: overrides the source name of the alarm on the Unified Service Management (USM). If you do not specify a value, robot
IP address is used.
v4.0 db2 IM Configuration
You can configure the db2 probe by defining various profiles and connections to the DB2 server. The connections that you set up are used for
running monitoring profiles on the DB2 server. These profiles monitor real-time events occurring in the server using various checkpoints. You can
select the required checkpoints and activate the profile that notifies you when any unwanted event occurs in the server. The probe provides
predefined checkpoints that you can customize. For example, you can create a profile that uses db_status checkpoint to monitor the status of
database at a given time. You can also create checkpoints.
These profiles can also be configured to generate alarm and QoS messages.
The following diagram outlines the process to configure the db2 probe.
Contents
Create a Connection
Create a Profile
Configure Alarm Thresholds
Define Schedules
View Profile Status
Create a Group
Verify that required hardware, software, and related information is available before you configure the probe. For more information, see db2 (DB2
Database Monitoring) Release Notes.

You can set up the logging and alarm severity conditions of db2 probe. The probe uses the default settings if you do not configure the general
properties.
Follow these steps:
1. Click the Setup tab and specify the following values as required:
Generate status only: instructs the probe to only generate status and not to issue an alarm when a threshold is breached. Select the
Status tab to see the status for the different checkpoints.
Clear Alarm On Restart: allows you to clear alarms when the probe restarts.
Default: Selected
Alarm severity filter: sets a filter on severity levels that can become potential alarms. For example, as a database administrator, you
want to convey important events on to the operations center or help-desk, so that the event can trigger emails. The Alarm severity
filter considers the events matching or exceeding the selected severity level alarms. If you select major, then only the messages with
severity level as major and above are considered as alarms.
Note: The probe verifies the events matching the selected severity level only when you disable the Generate status only fi
eld.

clear
information
warning
minor
major
critical
Status Auto-Update: select to specify the automatic refresh time of the monitoring profile. By default, this check box is not selected.
The Status Auto-Update parameter specifies the automatic refresh interval of monitoring profiles displayed in the Status tab.
Default: 60 sec
Note: The Status Auto-Update value is saved in the configuration file but the checkbox is cleared when you restart the
probe.
Log Size: specifies a maximum size of the probe log file.

Default:100 KB
Log Level: specifies the level of details that are written to the log file. Log as little as possible during normal operation to minimize
Default: 0-Fatal
QoS V2 compatibility: enables the backward-compatibility of the probe to the V2 framework.
All Database Status: enables you to get the status of all existing databases. If not selected, this option enables you to get the status
only for the default database.
Create a Connection
A connection can be used by more than one monitoring profile. You can create separate connections to access the Data Source Name (DSN) or
DB2 instances, as required.
Follow these steps:
1. Right-click in the Connections tab and select New.

The Add New Connection dialog is displayed.
2. Enter a connection name and click OK.
The New Connection [Connection Name] dialog is displayed.
3. Specify the User ID and Password for connecting to the DB2 server.
4. Click
adjacent to the Instance node field and double-click the required instance that you want to monitor from the Node List dial
og.
The Node List dialog displays the list of instance nodes available for the DB2 connection.
5. Click
adjacent to Default DB name field and double-click the required database that you want to monitor from the Database Lis
t dialog.
The Database List dialog displays the list of databases associated with the selected instance node.
6. Specify values for the following fields:
DSN: select to specify the ODBC Data Source Name. The probe enables only the Password field when you select this check box.
See Define an ODBC Connection for more information on how to create an ODBC connection.
Description: specifies additional information about the connection.
Retry attempts: specifies the number of attempts that the probe tries to connect in case of connection failure.
Retry delay: specifies the time period for which the probe waits between two connection attempts.
Timeout: specifies the connection timeout value.
7. Click Test to verify the status of connection. If the connection is successful, it returns the instance name and database name. If the
connection is unsuccessful, the probe displays an error message.
8. Click OK.
The new connection is added to the Connections tab.

You must create an ODBC connection to specify a DSN while defining a new connection.
Follow these steps:
1. In the Control Panel, select Administrative Tools.
2. Select Data Sources (ODBC).
The ODBC Data Source Administrator dialog appears.
3. Select the System DSN tab and click the Add button.
The Create New Data Source wizard is launched.
4. Select the driver you want to use (for example IBM DB2 ODBC DRIVER) and click the Next button.
5. Follow the steps through the wizard to finish the definition.
Create a Profile
You can create multiple profiles that monitor the DB2 server to verify that the performance always remains optimal.
Follow these steps:
1. Right-click in the Profiles tab and select New.
2. Enter a unique name for the profile in Add New Profile dialog and click OK.
The New Profile[Profile Name] dialog appears.
Heartbeat: specifies the interval at which all profile checkpoint schedules are tested and executed. This number is a common
denominator to all used check interval values. The higher the value, the lower is the profile overhead.
Default: 1 seconds
Connection: specifies the connection used in this profile. The drop-down lists all the connections displayed in the Connections tab.
Check Interval: specifies the time interval at which the DB2 server is scanned.
Default: 5 minutes
Clear message: specifies the message name used for clear alarm.
SQL Timeout: specifies the SQL query timeout. Every checkpoint query runs asynchronously. In case the query reaches the SQL
timeout, the checkpoint processing is terminated. The probe starts processing the next checkpoint and issues an alarm message.
Default: 30 seconds
Note: On every check interval, the SQL timeout alert is first cleared based on the query of the particular checkpoint. The
SQL timeout alert is thrown again if the issue remains.
Message: specifies the message name used for SQL timeout alarm.
Profile Timeout: specifies the maximum processing time for all checkpoints in the profile. If this timeout is reached, the interval
processing is done. The probe waits for next heartbeat to evaluate any checkpoint schedules and issues an alarm message.
Default: 15 minutes
Message: specifies the message name used for profile timeout alarm.
Timeout severity: specifies the severity for timeout messages.
Group: specifies the name of the group. When you select a group, all the checkpoints enabled under the group becomes available for
monitoring. The drop-down lists the defined groups from the Groups tab.
Alarm Source: overrides the source name of the alarm on the Unified Service Management. If you do not specify a value, robot IP
address is used.
Suspended/Resumed: specifies the profile state as running or suspended. This indicator is green when the profile is active. The
indicator changes to yellow when the profile is suspended and to black when deactivated.
4. Select the required checkpoints that you want to add from the Profile Checkpoints section.
5. Click OK to save the profile for monitoring.

Select the Profile Checkpoints that you want from the list in the New Profile dialog. Profile checkpoints are predefined parameters that can be
used for monitoring the server performance or unwanted events. The global and default checkpoint settings are used, unless you modify the
settings locally for your profile.
You can set the checkpoint attributes to monitor the DB2 server performance. You can use dynamic checkpoint templates, which means that the
checkpoints are defined globally (under the Templates tab) and represent the default settings. So, when you change the template value, it
reflects on all profiles using dynamic templates strategy.
Follow these steps:
1. Double-click the required checkpoint from the Edit Profile dialog.
The Edit template checkpoint dialog appears.
2. Select Active to activate a checkpoint.
Check Interval: specifies the time interval at which the DB2 server is scanned.
Send Quality of Service: enables you to activate QoS values being sent into the QoS database. If no QoS is available for a
checkpoint, the check box is disabled.
QoS List: allows you to define QoS to be used in the checkpoint. Click
to open the QoS list dialog that displays the current
QoS definition list. Right-click in the list to add new QoS definitions and copy, or edit any existing QoS definition.
Note: Some checkpoints cannot be used for generating QoS . For such checkpoints, the QoS dialog cannot be activated.
Samples: specifies the number of samples to be used for calculating an average value. This average value should be compared to
the specified alarm threshold.
Use excludes: allows you to specify the patterns to be excluded in the template checkpoint. Click
to open the Exclude list dial
og and specify the patterns to be excluded for the checkpoint. You can define objects that you do not want to monitor in the
template checkpoint.
Note: This checkbox is available for a custom checkpoint from version 4.9 or later. In previous versions, this check box is
disabled after you create a custom checkpoint.
Scheduling: allows you to specify the schedule settings, if defined. You can select any of the following:
a.
rules: defines rules for running the schedules of the template checkpoint.
exceptions: defines exceptions for running the schedules of the template checkpoint.
Clear message: specifies the message name used for clear alarm message.
Clear severity: specifies the severity used for message issued when the threshold is not breached. You can select from the following:
clear
information
warning
minor
major
critical
4. Click OK.
The checkpoint is configured. If you want specific settings to be valid for one profile only, right-click the checkpoint in the list and select C
hange to Static.

This section describes how to create a custom checkpoint for the db2 probe. The checkpoints can be used to monitor various database events
occurring in the DB2 server.
Follow these steps:
1. Navigate to the Templates tab, right-click and select Create new from the context menu.
2. Specify the name for the custom checkpoint in Add New User Template dialog and click OK.
The Edit template checkpoint dialog opens.
3. Click the Query tab.
4. Specify the name of column that you want to monitor in the Checked Value field.
5. Select the required connection from the Connection drop-down list that displays a list of pre-configured connections, created from the C
onnections tab.
6. Set or modify the following values in the Query tab of Edit template checkpoint dialog:
Condition: specifies one of the conditional operators such as =, != ,>= and, <=
Row identification: specifies the unique identification code of the row for which reporting is done.
Message variables: specifies the variables to be used in the message. Click Edit to choose one or more message variables.
Query file: specifies the file that stores the query.
7. Navigate to the General tab of Edit template checkpoint dialog and provide the details as mentioned in Configure Checkpoints.
8.
8. After you have entered values for the above mentioned fields, click QoS List.
The QoS list dialog appears.
9. Right-click in the grid view and select New from the context menu.
10. Enter a name and description of the QoS metric that you want to define.
11. Set or modify the following values as required in the Edit dialog:
Unit: indicates the unit of QoS metric.
Abbreviation: specifies the abbreviated name of the QoS metric.
Metric: selects the required QoS metric.
Max value: specifies the maximum value of the QoS metric.
12. Click OK in the Edit dialog and in the QoS list dialog.

The threshold list contains the predefined set of monitoring parameters that you can use in your profiles. The probe allows you to modify the
thresholds as required. The threshold values can be defined by modifying checkpoints in the respective profile. Every checkpoint must have at
least one threshold, but you can define additional thresholds. The probe scans the entire server to verify any matching events. When any given
event breaches the set threshold, the probe generates an alarm message.
Threshold values are descending or ascending, depending on condition used in a checkpoint, starting with the highest severity threshold
condition.
Follow these steps:
1. In the Thresholds/Schedules section of the Edit template checkpoint dialog, right-click and select the New option.
The Edit Threshold dialog appears.

2. Define the Threshold Value.
3. Select the Message for the threshold alarm.
4.
4. Set or modify the following values as required:

Severity: specifies the severity of alarm message to be used for the threshold.
Message text: specifies text of the message, containing variables. If the message text is changed from a profile list, you must create
new message.
Variables: displays the list of variables that are available only for the custom checkpoints. For example, $check, $profile, $instance,
$idle_agents. The variables for every custom checkpoint are different, depending on the variable query.
5. Click OK to add the threshold object.
Define Schedules
You can specify a schedule for running a checkpoint. A schedule is the execution period of the checkpoint on specified days, time and date
values. If you are using exceptions, the schedule is considered as an execution break.
If the schedules list is empty, the checkpoint is executed in every 24 hours. Additionally, there can be defined number of schedules for each
checkpoint. These schedules define additional rules to the check interval or exceptions of it. The rules and exceptions cannot be mixed in one
checkpoint.
Follow these steps:
1. Right-click in the Schedules section of General tab and select New from the context menu.
The Schedule ID dialog appears.
Notes:
First execution of schedule happens when you specify the value in Date from and Time from fields.
Run once causes the checkpoint to run only once a day in the defined period (unlike multiple times if Run interval used).
2. Click OK and click Yes to confirm the modification of template.

The new schedule is added to the Templates tab.
View Profile Status

The Status tab lists the profiles that are defined and their corresponding checkpoint templates. You can also modify the properties of an individual
checkpoint object from the Status tab.
Follow these steps:
1. Select a profile in the right pane and a monitored checkpoint in the left pane.
2. Double-click an object in the right pane.
The New Threshold dialog appears.
3. Set or modify the following values as required:
Threshold values: enables you to select the required threshold values.
Current interval value: enables you to select the required interval values. Click
Threshold values list.
to add the selected interval values to the
Message: specifies the message that you want to generate.

Message text: specifies text of the message, containing variables. If the message text is changed from a profile list, you must create
new message.
Variables: specifies the variables to be used in the message. Click
to add the selected variable in the message text.
Severity: specifies the severity of alarm message. Select from the following options:
clear
information
warning
minor
major
critical
4. Click OK.
Create a Group
You can define a group to enable a set of checkpoints that are logically related. If you select the required group, all the checkpoints defined under
the selected group will be attached to the monitoring profile. This saves time while configuring a profile. You can add, copy, or modify a group.
Follow these steps:
1. Right click in the Group tab and select the New option.
The Add New Group dialog appears.
2. Enter a unique name for the group and click OK.
The New Group dialog appears.
3. Enter a description for the new group in the Description text box.
4. From the Group checkpoints section, select the check points that you want to enable for the new group.
5. Click OK.
The new group is added in the Groups list.

target string.
The db2 probe uses regular expressions to search patterns that are excluded from the template checkpoint. For example, you are searching for
the pattern, no_connection. Enter /no_connection/ in the Match expression dialog and click OK. The probe searches for all the matching
instances of the specified pattern.
v4.0 db2 IM GUI Reference

This article describes the Infrastructure Manager configuration GUI for DB2 Database Monitoring probe.
Contents
Setup Tab
Connections Tab
Profiles Tab
Templates Tab
Status Tab
Group Tab
Setup Tab
The Setup tab contains the following two sub-tabs:
General
Message pool
By default, the General sub-tab is selected.
General Tab
The General tab enables you to set the clear alarms on the probe restart, log size, and log level.
This tab contains the following fields:
Generate status only: instructs the probe to only generate status, not to issue an alarm when a threshold is breached. Select the Status
Tab to see the status for the different checkpoints.
Clear Alarm On Restart: allows you to clear alarms on probe restart.
Default: Selected
Alarm severity filter: allows you to set a filter on the severity levels that can become potential alarms. For example, as a database
administrator, you want to convey important events on to the operations center or help-desk, so that the event can trigger emails. The Ala
rm severity filter considers the events matching or exceeding the selected severity level alarms. If you select major, then only the
messages with severity level as major and above are considered as alarms.
Note: The probe verifies the events matching the selected severity level only when you disable the Generate status only field.
Status Auto-Update: select to specify the automatic refresh time of the monitoring profile. By default, this checkbox is not selected.
The Status Auto-Update parameter specifies the automatic refresh interval of monitoring profiles displayed in the Status tab.
Default: 60 sec
Note: The Status Auto-Update value is saved in the configuration file but the checkbox is cleared when you restart the probe.
Log Size: specifies the maximum size of the probe log file.
Default: 100 KB
QoS V2 compatibility: enables the backward-compatibility of the probe to the V2 framework.
All Database Status: enables you to get the status of all existing databases. If not selected, this option enables you to get the status only
for the default database.
Message Pool Tab
The Message Pool tab lets you to view the list of all alarm messages defined in the probe.
Name: specifies the name of the alarm message.

Text: specifies the alarm message text.
You can right-click in this section and select the required message to create, edit, copy or delete alarm messages.
Double-click the required message that you want to modify. Set or modify the following values, as needed:
Checkpoint: selects the checkpoint to create an alarm message.
Message text: specifies the required message text for the checkpoint.
Variables: selects the variables to be used in the message. Click
to add the selected variable in the Message text field.
Connections Tab
This tab displays one predefined connection and allows you to view, create, modify, or delete the connections to different instances of the DB2
server. You need to specify the user name, password, and server name to be used to connect to the server instance. The password information is
encrypted and placed in the configuration file. A connection can be used by more than one profile. The following commands are available in the
right-click menu of the Connections tab:
New: creates a new connection to the DB2 server
Copy: creates a copy of the selected connection
Edit: modifies the fields of the selected connection
Delete: deletes the selected connection
New Connection Dialog
You can right-click in the Connections tab and select New to create a new connection set up to the DB2 server. Specify a unique name in the Na
me field of the Add New Connection dialog and click OK.
Set or modify the following fields in the New Connection[Connection Name] dialog, as needed:
DSN: specifies the ODBC Data Source Name.
Description: specifies the additional information about the connection.
User ID: defines the user identification code with SYSADM, SYSCTRL or SYSMAINT authorization.
Password: defines a valid password for the specified user.
Instance node: specifies the node name under which the DB2 instance (that the probe connects) is cataloged in the node directory.
Default DB name: specifies the database name used for connection tests (for example in i_check_dbalive).
Retry attempts: specifies the number of attempts made by the probe to connect in case of connection failure.
Retry delay: specifies the time for which the probe waits between two connection attempts.
Timeout: specifies the connection timeout value.
Test button: enables you to test the connection status. If the connection is successful, it returns the instance name and version number.
If the connection is unsuccessful, the probe displays an error message.
Profiles Tab
This tab displays the list of profiles that are defined for monitoring the DB2 server. Every profile runs as a separate thread, and multiple profiles
can be used to monitor one instance. Thus, the probe enables you to independently monitor several instances simultaneously.
The color of indicator icon appearing before the profile name indicates the following:
Green icon: profile is active and running.
Yellow icon: profile is active but suspended.
Black icon: profile is inactive.
The following commands are available in the right-click menu of the Profiles tab:
New: enables you to create a profile for monitoring the DB2 server.
Copy: enables you to create a copy of the selected monitoring profile.
Edit: enables you to modify the fields of the selected monitoring profile.
Delete: enables you to delete the selected monitoring profile.
Suspend: enables you to stop the selected profile from monitoring the server.
Resume: enables you to restart the selected profile to monitor the server.
You can add, edit, delete and copy profiles.
New Profile Dialog
The New option on right clicking in the Profiles tab enables you to create a profile for monitoring the DB2 server. The New Profile [Profile
Name] dialog allows you to configure the general profile properties and available checkpoints properties. The Suspended / Resumed commands
allows stopping/starting profile monitoring dynamically without deactivating/activating the probe.
Heartbeat: specifies the interval at which all profile checkpoints schedules are tested and executed.
Default: 5 seconds
Note: This number is a common denominator to all used check interval values. The higher the value of heartbeat, the lower is the
profile overhead.
Connection: specifies the connection used in this profile. You must define the connection in the Connections dialog before creating a
profile.
Check Interval: specifies the time interval at which the DB2 server is scanned. This is used if nothing else is defined in the checkpoint
and overwrites the default checkpoint list setting.
Default: 1 minute
Clear message: specifies the message name for clear alarm.

SQL Timeout: specifies the SQL query timeout. Every checkpoint query runs asynchronously. When the query reaches the SQL timeout,
the checkpoint processing is terminated and the probe processes the next checkpoint. The probe also generates an alarm message.
Default: 30 sec
Message: specifies the message name used for SQL timeout alarm.
Profile Timeout: defines the maximum processing time for all checkpoints in the profile. If this timeout is reached, the interval processing
is finished and the probe waits for next heartbeat to evaluate any checkpoint schedules. The probe also generates an alarm message.
Message: specifies the message name used for profile timeout alarm.
Timeout severity: specifies the severity for timeout messages.
Suspended/Resumed: specifies the profile state as running or suspended. This indicator is green when the profile is active. The
indicator changes to yellow when the profile is suspended and to black when deactivated.
Alarm source: overrides the source name of the alarm on the Unified Service Management (USM). If you do not specify a value, robot IP
address is used.
Checkpoint Types
At the bottom of New Profile dialog, a list of available checkpoints is displayed. Select the required checkpoints that you want to attach to your
profile. The default checkpoint settings are used globally, unless you modify the settings locally for your profile.
When defining a profile, you can use the following two different strategies while configuring the checkpoints:
Dynamic: allows you to define the checkpoint properties globally (under the Templates tab) that represent the default settings. Every
time that you change the template value, it reflects on all profiles that uses these dynamic templates. Double-click the checkpoint in the P
rofile Checkpoints list or Templates tab. When modified, the new settings becomes valid for all profiles, unless overruled by static
settings in the profile.
Static: allows you to manage the checkpoint properties locally. Set the checkpoint to static in your profile before modifying it. When
modified, the new settings becomes valid for this profile only.
There can be both template and static checkpoints in one profile. If a checkpoint is static, the checkpoint name appears in the list with
a blue color, and it is marked as static in the column type.
Note: If you want to have specific settings valid for one profile, right-click the checkpoint in the list and select Change to static. The
probe displays a warning message if you attempt to modify a template checkpoint in the Profile dialog without changing it to static.
When deciding which checkpoints to activate/deactivate for a profile, see v4.0 db2 Checkpoint Metrics for a description of the different
checkpoints.
Templates Tab
The Templates tab displays a list of predefined set of checkpoints that can be used in your profiles. You can modify, create, or delete the required
checkpoints.
Double-click the required checkpoint that you want to modify.
By default, most checkpoints are active with a default threshold value. The checkpoint attributes can be managed either globally (using Template
option) or locally (using Static option) for a profile.
Edit Template Checkpoint Dialog
The Create new option on right clicking in the Templates tab displays the Edit Template Checkpoint dialog. This dialog consists of the
following sub-tabs:
General tab
Hint Editor tab
Query tab
General Tab
The upper section of General tab contains general checkpoint settings. The lower section is divided into two parts: the first part displays the list of
thresholds and the second part displays the list of schedules.
Active: allows you to activate the checkpoint.
Condition: displays the conditional operator to evaluate the threshold values.
Check Interval: specifies the time interval for scanning the checkpoint. Every checkpoint can have a different check interval value. The
probe considers the default value from the profile definition, if it is not defined there, than considers the value from the default checkpoint
list.
Send Quality of Service: activates QoS values being sent into the QoS database. If not available in a checkpoint, this field is disabled.
QoS List: allows you to define the QoS to be used in the checkpoint. Clicking on
icon opens the QoS list dialog that displays the
current QoS definition list. By default, the current checkpoint definition is listed. Right-clicking in this list enables you to add new QoS
definitions and copy, edit, or delete an existing QoS definition.
The Edit QoS dialog offers available metrics (numerical variables that are reported as QoS) and available object variables (to be added
to the QoS source).
The name of the QoS has to start with the checkpoint name. QoS can be activated/deactivated as usual.
Note: Some checkpoints cannot be used for generating QoS . For such checkpoints, the QoS dialog cannot be activated.
Samples: specifies the number of samples for calculating an average value. This average value is compared to the specified alarm
threshold.
When the probe starts running, the average value from the number of samples that are available is calculated.
For example,
if you specify the value of Samples as 3, the probe performs the following:
uses the average of samples 1 and 2 in the second interval
if you specify the value of Samples as 1, the probe does not perform any sampling.
if you specify the value of Samples as 0, the probe takes the number of samples from the template
Note: Many checkpoints calculate an interval value, so the probe does not use any value in the first interval (and there is no threshold
checking).
Use excludes: allows you to specify the patterns to be excluded in the template checkpoint. Click
to open the Exclude list dialog
and specify the patterns to be excluded for the checkpoint. You can define objects that you do not want to monitor in the
template checkpoint.
Excludes list: displays a list that contains the patterns that are excluded from the template checkpoint. Click
to open the Exclude
list dialog that contains these patterns. These patterns are used for the checkpoint if the Use excludes checkbox is selected.
Right-clicking in the list lets you add new excludes or edit, copy or delete existing excludes.
When adding (or editing) an exclude pattern, a Match expression dialog is displayed, letting you edit or define the exclude pattern.
Excludes are defined using regular expression patterns. A test button in the Match expression dialog lets you test the defined exclude
pattern. This test is possible only for running active profiles and checkpoints. The test uses the status list (on the status tab) as input.
Note: If there already are active excludes, the excluded objects are excluded from the status list before the test.
When you click Test, an Exclude test list appears that shows the result of the test. Red text lines show the objects that are
excluded using the tested pattern.
The "object thresholds" function as an "include list". This means that if there are specific thresholds defined for a specific
object, this object will always stay in, even if the exclude pattern would eliminate it normally. This is considered also in the test
function.
Scheduling: allows you to specify how to use the schedules settings, if defined. You can select any of the following:
rules: defines rules for running the schedules of the template checkpoint.
exceptions: defines exceptions for running the schedules of the template checkpoint.
For example, if you specify the Scheduling as rules, then the probe runs the defined schedules on the specified dates to generate
alarms/QoS for the checkpoint. If you specify the Scheduling as exceptions, the probe does not run the defined schedules on the
specified dates.
Clear message: specifies the message name used for clear alarm message.
Clear severity: enables you to select the severity used for message issued when the threshold is not breached. You can select from the
following:
clear
information
warning
minor
major
critical
Thresholds/Schedules: displays the list of thresholds and schedules defined for the template checkpoint. Refer section Thresholds and
Schedules.
Hint Editor Tab
This tab allows you to specify the help text messages to be shared between the database administrators.
Query Tab
When you create a new template checkpoint, the probe allows you to define and associate a query to the checkpoint for retrieving the required
data from the DB2 server. For default checkpoints, the query is already defined.
Checked value: specifies the name of the columns for which monitoring is required.
Condition: specifies one of the comparison operators such as =, != ,>= and, <=
Row identification: specifies the unique identification code for the row.
Message variables: specifies the variables to be used in the message.
Query File: specifies the file that stores the query.
Query: defines a query to the database. Clicking Test enables you to validate the query.
Read: enables you to read the query from the file specified in the Query file field. The probe reads the query from the file and displays
the query in the Query textbox.
Test: enables you to test whether the defined query is valid or not. Clicking Test displays the Query Result dialog.
Interval modus: enables you to subtract the variable value from the value generated at the end of the interval.
Thresholds
The Thresholds section contains the list of object profiles that are used for monitoring their corresponding real-time object counterparts. These
object profiles are set to a threshold value that notify you if any matching real-time objects meet the set criteria. You can define multiple threshold
objects in a template checkpoint. By default, most checkpoints are active with a default threshold value. The threshold values are modified as
defined by modifying checkpoints in the respective profile. Every checkpoint has to have at least one threshold object.
The probe allows you to identify a specific monitoring object by defining various parameters for an object name (if applicable), such as tablespace
name, userid, and threshold ID that is numbered from 0. Threshold values should be descending or ascending, depending on the condition used
in a checkpoint, starting with the highest severity threshold condition.
Double clicking on an object profile from the Thresholds section displays the Edit threshold dialog
Threshold object name: specifies the monitoring object name, if applicable. If you do not specify the object name, the probe uses the
name as default. Some special checkpoints have a second threshold called count (for example, locked_users).
Threshold value: specifies the value used for threshold evaluation.
Current value: specifies the last measured value, if invoked from the status report.
Severity: specifies the severity of alarm message to be used for the threshold.
Message: specifies name of message used for threshold alarm.
Message text: specifies the message text, containing variables. If the message text is changed from a profile list, you must create new
message.
Variables: displays the list of variables that are available only for the custom checkpoints. For example, $check, $profile, $instance,
$object, $state. The variables for every custom checkpoint are different, depending on the variable query.
Note: To view the list of variables, double-click on the custom checkpoint and then double-click on the threshold object from
the Thresholds/Schedule section. The list of variables is displayed in the Edit threshold dialog.
Schedules
If the schedules list is empty, the checkpoint will be executed at an interval of 24 hours.
You can also define several schedules per checkpoint, each defining additional rules to the check interval or exceptions of it. The rules and exc
eptions cannot be mixed in one checkpoint.
In principle, a schedule is a definition of an execution period (or execution break if exceptions used) with specified days, time from/to and date
from/to values. If only Date from and Time from is defined, first execution can be defined. Run once will cause the checkpoint run only once a
day in the defined period (unlike multiple times if Run interval used).
Status Tab
The Status tab lists the defined profiles and their corresponding checkpoint templates. The status is displayed in an hierarchical fashion, with
profile name nodes in right pane and one or more checkpoint nodes in the left pane (only active checkpoints are considered here). The highest
status is propagated. Select the checkpoint in the navigation tree (to your left) to bring up the corresponding events.
This tab also enables you to modify the properties of an individual checkpoint object.
Group Tab
This tab lets you create multiple groups which can be associated with profiles. You can add, copy, modify, or delete a group.
v4.0 db2 Checkpoint Metrics

There are five kind of metrics used:
Count
Absolute number of events in the interval. It is calculated as delta between count at the beginning of the interval and at the end. In the
first interval, counts are not checked because their interval value cannot be calculated. If there is a "total" value in the message, it means
"since the start of the instance".
Gauge
Absolute number describing the actual state of the system.
Ratio
Calculated percentage using interval counts. In the first interval, it is calculated from total counts (as the interval count cannot be
calculated).
Average
Calculated using interval counts. In the starting interval, it is calculated from absolute counts.
Status
Absolute value like ONLINE etc.
Single Counter Description

Most of the checkpoints are measuring single DB2 snapshot counter values. Description of these counters can be found in the IBM DB2 "System
Monitor Guide and Reference" manual or in DB2 Information Center under "Monitor elements":
The IBM used counter names are hierarchically organized and therefore not unique. For this reason, the probe is adding to every name a prefix,
depending on its source:
"i_" for instance snapshot
"db_" for database
"bp_" for bufferpool
"app_" for application
"ts_" for tablespace statistics counter.
So the description for the counter "i_comm_private_mem" can be found under "comm_private_mem" in the IBM sources.
Calculated Checkpoint Description

The app_ checkpoints do not generate QoS.
i_agents_created_ratio - ratio
Calculated as: (i_agents_created_empty_pool / i_agents_from_pool) * 100.
Description: Monitors % of agents created due to empty agent pool by agents assigned from pool.
i_piped_sorts_rejected - count
Calculated as: i_piped_sorts_requested - i_piped_sorts_accepted.
Description: Monitors number of piped sort requests rejected.
db_pool_hit_ratio - ratio
Calculated as: (1.0 - ((db_pool_data_p_reads + db_pool_index_p_reads) / (db_pool_data_l_reads + db_pool_index_l_reads))) * 100.
Description: Monitors percentage of time a page was found in buffer pool on request.
db_avg_sort_time - average
Calculated as: (db_total_sort_time / db_total_sorts) / 1000.
Description: Monitors average sort time in interval in seconds.
db_pct_sort_overflows - ratio
Calculated as: (db_sort_overflows / db_total_sorts) * 100.
Description: Monitors % of sort overflows in interval.
db_avg_sort_heap - average
Calculated as: db_sort_heap_allocated / db_active_sorts.

Description: Monitors average number of pages allocated to sort heap in interval.
db_pct_hjs_overflows - ratio
Calculated as: (db_hash_join_small_overflows / db_hash_join_overflows) * 100.
Description: Monitors percentage of hash join small overflows.
db_pool_sync_reads - count
Calculated as: db_pool_data_p_reads - db_pool_async_data_reads.
Description: Monitors number of synchronous data reads per interval.
db_pool_sync_writes - count
Calculated as: db_pool_data_writes - db_pool_async_data_writes
Description: Monitors number of synchronous data writes per interval.
db_pool_sync_idx_reads - count
Calculated as: db_pool_index_p_reads - db_pool_async_index_reads
Description: Monitors number of synchronous index page reads per interval.
db_pool_sync_idx_writes - count
Calculated as: db_pool_index_writes - db_pool_async_index_writes
Description: Monitors number of synchronous index page writes per interval.
db_pool_avg_async_read_time - average
Calculated as: db_pool_async_read_time / db_pool_async_data_reads
Description: Monitors average asynchronous read time in ms in interval.
db_pool_avg_async_write_time - average
Calculated as: db_pool_async_write_time / (db_pool_async_data_writes + db_pool_async_index_writes)
Description: Monitors average asynchronous write time in ms in interval.
db_pool_sync_write_time - count
Calculated as: db_pool_write_time - db_pool_async_write_time
Description: Monitors synchronous write time in ms in interval.
db_pool_avg_write_time - average
Calculated as: db_pool_async_write_time / (db_pool_async_data_writes + db_pool_async_index_writes)
Description: Monitors average write time in ms in interval.
db_avg_direct_read_time - average
Calculated as: db_direct_read_time / db_direct_reads
Description: Monitors average time for direct read in ms.
db_avg_direct_write_time - average
Calculated as: db_direct_write_time / db_direct_writes
Description: Monitors average time for direct write in ms.
db_cat_cache_hit_rto - ratio
Calculated as: (1- (db_cat_cache_inserts / db_cat_cache_lookups)) * 100.
Description: Monitors percent of times, information was found in catalog cache.
db_log_util_rto - ratio
Calculated as: (db_total_log_used / (db_total_log_used + db_total_log_available)) * 100.
Description: Monitors database log utilization.
db_since_last_backup - count
Calculated as: (tNow - ((elapsed_exec_time_s + (elapsed_exec_time_ms / 1000000.0)))) / 3600.
Description: Monitors number of hours since last backup.
db_status - status
Calculated as: db_status based on the below values.
Description: Monitors database status.
#. State Value Alarm QoS
1. ACTIVE 0 Yes Yes
2. QUIESCE_PEND 1Yes Yes
3. QUIESCED 2 Yes Yes
4. ROLLFWD 3 Yes Yes
5. Not defined Log No Yes
app_avg_sort_time - average
Calculated as: app_total_sort_time / app_total_sorts
Description: Monitors the average sort time in interval in ms.
app_pct_sort_overflows - ratio
Calculated as: (app_sort_overflows / app_total_sorts) * 100.
Description: Monitors the percentage of sort overflows per interval.
app_pool_hit_ratio - ratio
Calculated as: (1 - ((app_pool_data_p_reads + app_pool_index_p_reads) / (app_pool_data_l_reads + app_pool_index_l_reads))) * 100.
Description: Monitors percentage of time a page was found in buffer pool on application request.
app_avg_direct_read_time - average
Calculated as: app_direct_read_time / app_direct_reads.
Description: Monitors the average time for direct read in ms.
app_avg_direct_write_time - average
Calculated as: app_direct_write_time / app_direct_writes
Description: Monitors the average time for direct write in ms.
app_cat_cache_hit_rto - ratio
Calculated as: (1 - (app_cat_cache_inserts / app_cat_cache_lookups)) * 100.
Description: Monitors percentage of time table descriptor was found in catalog cache.
Calculated as: (1 - (app_pkg_cache_inserts / app_pkg_cache_lookups)) * 100.
Description: Monitors percentage of time package section was found in package cache.
app_locklist_util - ratio
Calculated as: ((app_locks_held * locksize) / (app_dbcfg_lock_list * 4096)) * 100.
Description: Monitors lock list utilization by application in percent.
app_sys_cpu_time - count
Calculated as: agent_sys_cpu_time_s + (agent_sys_cpu_time_ms / 1000000.0).
Description: Monitors the total system CPU time (in seconds) used by database manager agent process.
app_usr_cpu_time - count
Calculated as: agent_usr_cpu_time_s + (agent_usr_cpu_time_ms / 1000000.0).
Description: Monitors the total user CPU time (in seconds) used by database manager agent process.
app_uow_elapsed_time - count
Calculated as: uow_elapsed_time_s + (uow_elapsed_time_ms / 1000000.0).
Description: Monitors the elapsed execution time of the most recently completed UOW.
bp_pool_hit_ratio - ratio
Calculated as: (1 - ((bp_pool_data_p_reads + bp_pool_index_p_reads) / (bp_pool_data_l_reads + bp_pool_index_l_reads))) * 100.
Description: Monitors percentage of time a page was found in buffer pool.
bp_pool_avg_async_read_time - average
Calculated as: bp_pool_async_read_time / bp_pool_async_data_reads.
Description: Monitors average asynchronous read time in ms in interval.
bp_pool_avg_async_write_time - average
Calculated as: (bp_pool_async_write_time / (bp_pool_async_data_writes + bp_pool_async_index_writes)).
bp_pool_sync_write_time - count
Calculated as: bp_pool_write_time - bp_pool_async_write_time.
Description: Monitors synchronous write time in ms in interval.
bp_pool_avg_write_time - average
Calculated as: bp_pool_async_write_time / (bp_pool_async_data_writes + bp_pool_async_index_writes).
bp_avg_direct_read_time - average
Calculated as: bp_direct_read_time / bp_direct_reads.
Description: Monitors average time for direct read in ms in interval.
bp_avg_direct_write_time - average
Calculated as: bp_direct_write_time / bp_direct_writes.
Description: Monitors average time for direct write in ms in interval.
bp_pool_sync_reads - count
Calculated as: bp_pool_data_p_reads - bp_pool_async_data_reads.
Description: Monitors number of synchronous data reads in interval.
bp_pool_sync_writes - count
Calculated as: bp_pool_data_writes - bp_pool_async_data_writes.
Description: Monitors number of synchronous data writes in interval.
bp_pool_sync_idx_writes - count
Calculated as: bp_pool_index_writes - bp_pool_async_index_writes.
Description: Monitors number of synchronous index page writes in interval.
bp_pool_sync_idx_reads - count
Calculated as: bp_pool_index_p_reads - bp_pool_async_index_reads.
Description: Monitors number of synchronous index page reads in interval.
ts_usable_pages_pct - ratio
Calculated as: (ts_usable_pages / ts_total_pages) * 100.
Description: Monitors percent of usable pages in DMS table space (exlc. overhead).
ts_used_pages_pct - ratio
Calculated as: (ts_used_pages / ts_total_pages) * 100.
Description: Monitors percent of used pages in table space.

ts_free_pages_pct - ratio
Calculated as: (ts_free_pages / ts_total_pages) * 100.
Description: Monitors percent of free pages in DMS table space.
ts_max_used_pages_pct - ratio
Calculated as: (ts_max_used_pages / ts_total_pages) * 100.
Description: Monitors maximum of used pages in % reached in DMS table space.
ts_max_used_pages - count
Calculated as: ts_max_used_pages for DMS type only.
Description: Monitors maximum of used pages reached in DMS table space.
ts_free_pages - count
Calculated as: ts_free_pages for DMS type only.
Description: Monitors number of free pages in DMS table space.
ts_usable_pages - count
Calculated as: ts_usable_pages for DMS type only.
Description: Monitors number of usable pages in table space (exlc. overhead).
ts_status - status
Calculated as: ts_state
Description: Monitors status of the tablespace.
i_pct_active_connections - ratio
Calculated as: ((i_rem_cons_in + i_rem_cons_in_exec + i_local_cons + i_local_cons_in_exec) / i_max_connections) * 100.
Description: Monitors % of active connections to total allowed connections.
db2 Metrics
The following table describes the QoS metrics that can be configured using the db2 probe.
Monitor Name
Units
Description
Version
QOS_DB2_ACTIVE_CONNECTIONS_PERCENTAGE
Active connections percentage
4.0
QOS_DB2_ACTIVE_SORTS
count
Database Active Sorts
4.0
QOS_DB2_AGENTS_CREATED_EMPTY_POOL
count
Agents Created Empty Pool
4.0
QOS_DB2_AGENTS_CREATED_RATIO
Agents Created Ratio
4.0
QOS_DB2_AGENTS_FROM_POOL
count
Agents from Pool
4.0
QOS_DB2_AGENTS_REGISTERED
count
Agents curr. Registered
4.0
QOS_DB2_AGENTS_REGISTERED_TOP
count
Agents Registered Top
4.0
QOS_DB2_AGENTS_STOLEN
count
Agents Stolen
4.0
QOS_DB2_AGENTS_TOP
count
Database Agents Top
4.0
QOS_DB2_AGENTS_WAITING_ON_TOKEN
count
Agents Waiting on Token
4.0
QOS_DB2_AGENTS_WAITING_TOP
count
Agents Waiting Top
4.0
QOS_DB2_APPL_SECTION_INSERTS
count
Database SQL Section Inserts
4.0
QOS_DB2_APPL_SECTION_LOOKUPS
count
Database SQL Section Lookups
4.0
QOS_DB2_APPLS_CUR_CONS
count
Database Connected
4.0
QOS_DB2_APPLS_IN_DB2
count
Database Active Connections
4.0
QOS_DB2_AVG_DIRECT_READ_TIME
ms
Average Direct Read Time
4.0
QOS_DB2_AVG_DIRECT_WRITE_TIME
ms
Average Direct Write Time
4.0
QOS_DB2_AVG_SORT_HEAP
count
Database Average Sort Heap
4.0
QOS_DB2_AVG_SORT_TIME
sec
Database Average Sort Time
4.0
QOS_DB2_BINDS_PRECOMPILES
count
Database Binds/Precompiles
4.0
QOS_DB2_CAT_CACHE_HEAP_FULL
count
Database Catalog Cache Overflows Full Heap
4.0
QOS_DB2_CAT_CACHE_HIT_RTO
Database Catalog Cache Hit Ratio
4.0
QOS_DB2_CAT_CACHE_INSERTS
count
Database Catalog Cache Inserts
4.0
QOS_DB2_CAT_CACHE_LOOKUPS
count
Database Catalog Cache Lookups
4.0
QOS_DB2_CAT_CACHE_OVERFLOWS
count
Database Catalog Cache Overflows
4.0
QOS_DB2_CHECK_DBALIVE
Availability
DB2 Instance Availability
4.0
QOS_DB2_COMM_PRIVATE_MEM
Byte
Comitted Private Memory
4.0
QOS_DB2_COMMIT_SQL_STMTS
count
Database Commits
4.0
QOS_DB2_CON_LOCAL_DBASES
count
Databases with Connections
4.0
QOS_DB2_CONNECTIONS_TOP
count
Database Connections Top
4.0
QOS_DB2_COORD_AGENTS_TOP
count
Coordinating Agents Top
4.0
QOS_DB2_DB_CONNECT_TIME
seconds
Database Connection Time
4.0
QOS_DB2_DB_HEAP_TOP
Bytes
Database Memory Usage
4.0
QOS_DB2_DB_LOG_UTIL_RTO
Database Log Utilization
4.0
QOS_DB2_DB_STATUS
status
Database Status
4.0
QOS_DB2_DDL_SQL_STMTS
count
Database DDL SQL
4.0
QOS_DB2_DEADLOCKS
count
Database Deadlocks
4.0
QOS_DB2_DIRECT_READ_REQS
count
Direct Read Requests
4.0
QOS_DB2_DIRECT_READ_TIME
ms
Direct Read Time
4.0
QOS_DB2_DIRECT_READS
count
Direct Reads
4.0
QOS_DB2_DIRECT_WRITE_REQS
count
Direct Write Requests
4.0
QOS_DB2_DIRECT_WRITE_TIME
ms
Direct Write Time
4.0
QOS_DB2_DIRECT_WRITES
count
Direct Writes
4.0
QOS_DB2_DYNAMIC_SQL_STMTS
count
Database Dynamic SQL
4.0
QOS_DB2_FAILED_SQL_STMTS
count
Database Failed SQL
4.0
QOS_DB2_FILES_CLOSED
count
Bufferpool File Close
4.0
QOS_DB2_FREE_PAGES
count
Tablespace Free Pages
4.0
QOS_DB2_FREE_PAGES_PCT
Tablespace Pct. Free Pages
4.0
QOS_DB2_GW_CONS_WAIT_CLIENT
count
Connections Waiting on Client
4.0
QOS_DB2_GW_CONS_WAIT_HOST
count
Connections Waiting on Host
4.0
QOS_DB2_GW_CUR_CONS
count
Gateway Current Connections
4.0
QOS_DB2_GW_TOTAL_CONS
count
Gateway Connection Attempts
4.0
QOS_DB2_HASH_JOIN_OVERFLOWS
count
Database Hash Join Overflows
4.0
QOS_DB2_HASH_JOIN_SMALL_OVERFLOWS
count
Database Hash Join Small Overflows
4.0
QOS_DB2_IDLE_AGENTS
count
Unassigned Agents
4.0
QOS_DB2_INT_AUTO_REBINDS
count
Database Auto Rebinds
4.0
QOS_DB2_INT_COMMITS
count
Database Internal Commits
4.0
QOS_DB2_INT_DEADLOCK_ROLLBACKS
count
Database Internal Deadlock Rollbacks
4.0
QOS_DB2_INT_ROLLBACKS
count
Database Internal Rollbacks
4.0
QOS_DB2_INT_ROWS_DELETED
count
Database Internal Deletes
4.0
QOS_DB2_INT_ROWS_INSERTED
count
Database Internal Inserts
4.0
QOS_DB2_INT_ROWS_UPDATED
count
Database Internal Updates
4.0
QOS_DB2_LOCAL_CONS
count
Current Local Connections
4.0
QOS_DB2_LOCAL_CONS_IN_EXEC
count
Current Local Connections Executing
4.0
QOS_DB2_LOCK_ESCALS
count
Database Lock Escalations
4.0
QOS_DB2_LOCK_LIST_IN_USE
Bytes
Database Lock List Use
4.0
QOS_DB2_LOCK_TIMEOUTS
count
Database Locks Waiting
4.0
QOS_DB2_LOCK_WAIT_TIME
ms
Database Lock Wait Time
4.0
QOS_DB2_LOCK_WAITS
count
Database Lock Waits
4.0
QOS_DB2_LOCKS_HELD
count
Database Locks Held
4.0
QOS_DB2_LOCKS_WAITING
count
Database Locks Waiting
4.0
QOS_DB2_LOG_READS
count
Database Log Pages Read
4.0
QOS_DB2_LOG_WRITES
count
Database Log Pages Written
4.0
QOS_DB2_MAX_AGENT_OVERFLOWS
count
MAXAGENT Overflows
4.0
QOS_DB2_MAX_USED_PAGES
count
Tablespace Max Used Pages
4.0
QOS_DB2_MAX_USED_PAGES_PCT
Tablespace Pct. Max Used Pages
4.0
QOS_DB2_NEW_CHECKPOINT_12345
test checkpoint
4.0
QOS_DB2_NUM_ASSOC_AGENTS
count
Database Agents
4.0
QOS_DB2_PCT_HJS_OVERFLOWS
Database Hash Join Small Overflows
4.0
QOS_DB2_PCT_SORT_OVERFLOWS
Database Sort Overflows
4.0
QOS_DB2_PIPED_SORTS_ACCEPTED
count
Piped Sorts Accepted
4.0
QOS_DB2_PIPED_SORTS_REJECTED
count
Piped Sorts Rejected
4.0
QOS_DB2_PIPED_SORTS_REQUESTED
count
Piped Sorts Requested
4.0
QOS_DB2_PKG_CACHE_INSERTS
count
Database Package Cache Inserts
4.0
QOS_DB2_PKG_CACHE_LOOKUPS
count
Database Package Cache Lookups
4.0
QOS_DB2_POOL_ASYNC_DATA_READ_REQS
count
Bufferpool Async. Read Requests
4.0
QOS_DB2_POOL_ASYNC_DATA_READS
count
Bufferpool Async. Page Reads
4.0
QOS_DB2_POOL_ASYNC_DATA_WRITES
count
Bufferpool Async. Data Writes
4.0
QOS_DB2_POOL_ASYNC_INDEX_READS
count
Bufferpool Async. Index Reads
4.0
QOS_DB2_POOL_ASYNC_INDEX_WRITES
count
Bufferpool Async. Index Writes
4.0
QOS_DB2_POOL_ASYNC_READ_TIME
ms
Bufferpool Async. Read Time
4.0
QOS_DB2_POOL_ASYNC_WRITE_TIME
ms
Bufferpool Async. Write Time
4.0
QOS_DB2_POOL_AVG_ASYNC_READ_TIME
ms
Bufferpool Avg. Async. Read Time
4.0
QOS_DB2_POOL_AVG_ASYNC_WRITE_TIME
ms
Bufferpool Avg. Async. Write Time
4.0
QOS_DB2_POOL_AVG_WRITE_TIME
ms
Bufferpool Avg. Write Time
4.0
QOS_DB2_POOL_DATA_FROM_ESTORE
count
Bufferpool Index Pages from Estore
4.0
QOS_DB2_POOL_DATA_L_READS
count
Bufferpool Logical Reads
4.0
QOS_DB2_POOL_DATA_P_READS
count
Bufferpool Physical Reads
4.0
QOS_DB2_POOL_DATA_TO_ESTORE
count
Bufferpool Data Pages to Estore
4.0
QOS_DB2_POOL_DATA_WRITES
count
Bufferpool Physical Writes
4.0
QOS_DB2_POOL_DRTY_PG_STEAL_CLNS
count
Database Dirty Page Cleans
4.0
QOS_DB2_POOL_DRTY_PG_THRSH_CLNS
count
Database Dirty Page Thd. Reached
4.0
QOS_DB2_POOL_HIT_RATIO
Bufferpool Hit Ratio
4.0
QOS_DB2_POOL_INDEX_FROM_ESTORE
count
Bufferpool Index Pages from Estore
4.0
QOS_DB2_POOL_INDEX_L_READS
count
Bufferpool Logical Index Reads
4.0
QOS_DB2_POOL_INDEX_P_READS
count
Bufferpool Physical Index Reads
4.0
QOS_DB2_POOL_INDEX_TO_ESTORE
count
Bufferpool Index Pages to Estore
4.0
QOS_DB2_POOL_INDEX_WRITES
count
Bufferpool Index Writes
4.0
QOS_DB2_POOL_LSN_GAP_CLNS
count
Database Log Space Cleans
4.0
QOS_DB2_POOL_READ_TIME
ms
Bufferpool Total Read Time
4.0
QOS_DB2_POOL_SYNC_IDX_READS
count
Bufferpool Sync. Index Reads
4.0
QOS_DB2_POOL_SYNC_IDX_WRITES
count
Bufferpool Synchronous Index Writes
4.0
QOS_DB2_POOL_SYNC_READS
count
Bufferpool Synchronous Reads
4.0
QOS_DB2_POOL_SYNC_WRITE_TIME
ms
Bufferpool Sync. Write Time
4.0
QOS_DB2_POOL_SYNC_WRITES
count
Bufferpool Sync. Writes
4.0
QOS_DB2_POOL_WRITE_TIME
ms
Bufferpool Physical Write Time
4.0
QOS_DB2_POST_THRESHOLD_HASH_JOINS
count
Post Treshold Hash Joins
4.0
QOS_DB2_POST_THRESHOLD_SORTS
count
Post Threshold Sorts
4.0
QOS_DB2_PREFETCH_WAIT_TIME
ms
Database Prefetch Wait Time
4.0
QOS_DB2_REM_CONS_IN
count
Current Remote Connections
4.0
QOS_DB2_REM_CONS_IN_EXEC
count
Current Remote Connections Executing
4.0
QOS_DB2_ROLLBACK_SQL_STMTS
count
Database Rollbacks
4.0
QOS_DB2_ROWS_DELETED
count
Database Rows Deleted
4.0
QOS_DB2_ROWS_INSERTED
count
Database Rows Inserted
4.0
QOS_DB2_ROWS_SELECTED
count
Database Rows Selected
4.0
QOS_DB2_ROWS_UPDATED
count
Database Rows Updated
4.0
QOS_DB2_SEC_LOG_USED_TOP
Bytes
Database Secondary Logspace Top
4.0
QOS_DB2_SEC_LOGS_ALLOCATED
count
Database Secondary Logs
4.0
QOS_DB2_SELECT_SQL_STMTS
count
Database Select SQL
4.0
QOS_DB2_SINCE_LAST_BACKUP
hours
Hours Since Last Backup
4.0
QOS_DB2_SORT_HEAP_ALLOCATED
count
Sort Heap Allocated
4.0
QOS_DB2_SORT_OVERFLOWS
count
Database Sort Overflows
4.0
QOS_DB2_STATIC_SQL_STMTS
count
Database Static SQL
4.0
QOS_DB2_TOT_LOG_USED_TOP
Bytes
Database Total Logspace Top
4.0
QOS_DB2_TOTAL_CONS
count
Database Connects
4.0
QOS_DB2_TOTAL_HASH_JOINS
count
Database Hash Joins
4.0
QOS_DB2_TOTAL_HASH_LOOPS
count
Database Hash Loops
4.0
QOS_DB2_TOTAL_PAGES
count
Tablespace Total Pages
4.0
QOS_DB2_TOTAL_SEC_CONS
count
Database Secondary Connections
4.0
QOS_DB2_TOTAL_SORT_TIME
ms
Database Total Sort Time
4.0
QOS_DB2_TOTAL_SORTS
count
Database Total Sorts
4.0
QOS_DB2_TS_DATA_PARTITIONING
Data partitioning free percent
4.0
QOS_DB2_TS_STATUS
status
Tablespace Status
4.0
QOS_DB2_UID_SQL_STMTS
count
Database UID SQL
4.0
QOS_DB2_USABLE_PAGES
count
Tablespace Total Pages
4.0
QOS_DB2_USABLE_PAGES_PCT
Tablespace Pct. Usable Pages
4.0
QOS_DB2_USED_PAGES
count
Tablespace Used Pages
4.0
QOS_DB2_USED_PAGES_PCT
Tablespace Pct. Used Pages
4.0
QOS_DB2_X_LOCK_ESCALS
count
Database X-Lock Escalations
4.0
This section contains the QoS metric default settings for the db2 probe.
Alert Metric
Warning
Threshold
Warning
Severity
Error
Threshold
Error
Severity
Description
app_acc_curs_blk
500
Warning
Monitors the number of times that a request for an I/O block was
accepted
app_agents_stolen
500
Warning
Monitors the number of agents stolen from app. in interval
app_appl_idle_time
60
Warning
Monitors the number of seconds since an application has issued

any requests to the server
app_asoc_agents_top
500
Warning
Monitors the maximum number of subagents associated with this

application
app_avrg_direct_read_time
500
Warning
Monitors the average time for direct read in ms
app_avrg_direct_write_time
500
Warning
Monitors the average time for direct write in ms
app_avrg_sort_time
500
Warning
Monitors the average sort time in interval in ms
app_binds_precomplies
500
Warning
Monitors number of binds precompiles
app_cat_cache_heap_full
500
Warning
Monitors the number of overflows due to db heap full
app_cat_cache_hit_rho
75
Warning
Monitors percentage of time table descriptor was found in catalog

cache
app_cat_cache_inserts
500
Warning
Monitors the number of table descriptors inserted
app_cat_cache_lookups
500
Warning
Monitors the number of table descriptor lookups
app_cat_cache_overflows
500
Warning
Monitors the number of catalog cache overflows
app_commit_sql_stmts
500
Warning
Monitors number of commit SQL statements
app_ddl_sql_stmts
500
Warning
Monitors number of DDL SQL statements
app_deadlocks
Warning
Monitors number of deadlocks that have occurred
app_direct_read_reqs
500
Warning
Monitors direct read requests
app_direct_read_time
500
Warning
Monitors direct read time
app_direct_reads
500
Warning
Monitors direct reads
app_direct_write_reqs
500
Warning
Monitors direct write requests
app_direct_write_time
500
Warning
Monitors direct write time
app_direct_writes
500
Warning
Monitors direct writes
app_dynamic_sql_stmts
500
Warning
Monitors number of dynamic SQL statements
app_failed_sql_stmts
500
Warning
Monitors number of failed SQL statements
app_hash_join_overflows
500
Warning
Monitors the number of times hash join data exceeded available

space
app_hash_join_small_overflows
500
Warning
Monitors the number of times hash join data exceeded available

space by less than 10%
app_int_auto_rebinds
500
Warning
Monitors the number of automatic rebinds (or recompiles) that have

been attempted
app_int_commits
500
Warning
Monitors number of internal commits
app_int_deadlock_rollbacks
500
Warning
Monitors number of internal deadlock rollbacks
app_int_ rollbacks
500
Warning
Monitors number of internal rollbacks
app_int_rows_deleted
500
Warning
Monitors number of internal rows deleted
app_int_rows_inserted
500
Warning
Monitors the number of internal inserts
app_int_rows_updated
500
Warning
Monitors number of internal rows updated
app_lock_escals
Warning
Monitors number of times that locks have been escalated from

several row locks to a table lock
app_lock_timeouts
500
Warning
Monitors the number of timeouts
app_lock_wait_time
1000
Warning
Monitors total elapsed time waited for a lock in ms
app_lock_waits
90
Warning
Monitors number of times that application waited for locks
app_locklist_util
50
Warning
Monitors locklist utilization by application in percent
app_locks_held
100
Warning
Monitors number of locks currently held
app_num_agents
500
Warning
Monitors the number of concurrent agents currently executing a

statement or subsection
app_num_asoc_agents
500
Warning
Monitors the number of agents associated with the application
app_open_loc_curs
500
Warning
Monitors the number of local cursors currently open for this

application
app_open_loc_curs_blk
500
Warning
Monitors the number of local blocking cursors currently open for this
application
app_open_rem_curs
500
Warning
Monitors the number of remote cursors currently open for this

application
app_open_rem_curs_blk
500
Warning
Monitors the number of remote blocking cursors currently open for

this application
25
Warning
Monitors percentage of sort owerflows per interval
75
Warning
Monitors percentage of time package section was found in package

cache
app_pkg_cache_inserts
500
Warning
Monitors the number of sections inserted into cache
app_pkg_cache_lookups
500
Warning
Monitors the number of section lookups
app_pool_data_I_reads
500
Warning
Monitors number of logical read requests
app_pool_data_p_reads
500
Warning
Monitors number of reads, requiring physical I/O
app_pool_data_writes
500
Warning
Monitors number of times, data was physicaly written to disk
app_pool_hit_ratio
85
Warning
Monitors the percentage of time a page was found in buffer pool on

application request
app_pool_index_l_reads
500
Warning
Monitors number of logical read req. for index pages
app_pool_index_p_reads
500
Warning
Monitors number of req. for index page req. physical I/O
app_pool_index_writes
500
Warning
Monitors number of times, index page was written to disk
app_pool_read_time
500
Warning
Monitors total el.time for ph. read of data/ix. pages in ms
app_pool_write_time
500
Warning
Monitors total el.time for ph. read of data/ix. pages in ms
app_rej_curs_blk
500
Warning
Monitors the number of times that a request for an I/O block at

server was rejected
app_rollback_sql_stmts
500
Warning
Monitors number of rollback SQL statements
app_rows_deleted
500
Warning
Monitors number of rows deleted
app_rows_inserted
500
Warning
Monitors number of rows inserted
app_rows_read
500
Warning
Monitors number of rows read
app_rows_selected
500
Warning
Monitors number of rows selected
app_rows_updated
500
Warning
Monitors number of rows updated
app_rows_written
500
Warning
Monitors number of rows written
app_select_sql_stmts
500
Warning
Monitors number of select SQL statements
app_sort_overflows
50
Warning
Monitors the total number of sorts that ran out of sort heap
app_static_sql_stmts
500
Warning
Monitors number of static SQL statements
app_sys_cpu_time
500
Warning
Monitors the total system CPU time (in seconds) used by database
manager agent process
app_total_hash_joins
500
Warning
Monitors the number of hash joins executed in interval
app_total_hash_loops
500
Warning
Monitors the number of hash joins executed in interval
app_total_sort_time
50
Warning
Monitors the total elapsed time (in ms) for all sorts that have been
executed
app_total_sorts
Warning
Monitors the total number of sorts that have been executed
app_uid_sql_stmts
500
Warning
Monitors number of UID SQL statements
app_uow_elapsed_time
500
Warning
Monitors the elapsed execution time of the most recently completed

UOW
app_uow_lock_wait_time
500
Warning
Monitors the total amount of elapsed time this unit of work has spent
waiting for locks in ms
app_uow_log_space_used
500
Warning
Monitors the amount of log space (in bytes) used in the current
UOW
app_usr_cpu_time
500
Warning
Monitors the total user CPU time (in seconds) used by database
manager agent process
app_x_lock_escals
Warning
Monitors number of times that (x) locks have been escalated from
several row locks to one exclusive table lock
65
Warning
Monitors average time for direct read in ms in interval
65
Warning
Monitors average time for direct write in ms in interval
bp_direct_read_reqs
85
Warning
Monitors number of direct read requests
bp_direct_read_time
85
Warning
bp_direct_reads
85
Warning
Monitors number of direct reads
bp_direct_write_reqs
85
Warning
Monitors number of direct write requests
bp_direct_write_time
85
Warning
bp_direct_writes
85
Warning
Monitors number of direct writes
bp_files_closed
85
Warning
Monitors number of file close operations
bp_pool_async_data_read_reqs
85
Warning
Monitors number of asynchronous read requests
bp_pool_async_data_reads
85
Warning
Monitors number of pages read asynchronously into the bufferpool
bp_pool_async_data_writes
85
Warning
Monitors number of pages written asynchronously into the

bufferpool
bp_pool_async_index_reads
85
Warning
Monitors number of asynchronous index reads
bp_pool_async_index_writes
85
Warning
Monitors number of index pages written asynchronously into the

bufferpool
bp_pool_async_read_time
85
Warning
Monitors elapsed time spent reading by prefetcher
bp_pool_async_write_time
85
Warning
Monitors elapsed time spent asynchronously writing
15
Warning
Monitors average asynchronous read time in ms in interval
25
Warning
Monitors average asynchronous write time in ms in interval
65
Warning
bp_pool_data_from_estore
85
Warning
Monitors number of of data pages copied from extended sotrage
bp_pool_data_l_reads
100000
Warning
Monitors number of logical read requests in interval
bp_pool_data_p_reads
85
Warning
Monitors number of physical read requests in interval
bp_pool_data_to_estore
85
Warning
Monitors number of of data pages copied to extended sotrage
bp_pool_data_writes
85
Warning
Monitors number of physical write requests in interval
bp_pool_hit_ratio
85
Warning
Monitors percentage of time a page was found in buffer pool
bp_pool_index_from_estore
85
Warning
Monitors number of of index pages copied from extended sotrage
bp_pool_index_l_reads
85
Warning
Monitors number of logical read requests for index pages in interval
bp_pool_index_p_reads
85
Warning
Monitors number of physical read requests for index pages in

interval
bp_pool_index_to_estore
85
Warning
Monitors number of of index pages copied to extended sotrage
bp_pool_index_writes
85
Warning
Monitors number of write requests for index pages in interval
bp_pool_read_time
10
Warning
Monitors total elapsed time for physical read of data/ixdex pages
65
Warning
Monitors number of synchronous index page reads in interval
65
Warning
Monitors number of synchronous index page writes in interval
bp_pool_sync_reads
65
Warning
Monitors number of synchronous data reads in interval
65
Warning
Monitors synchronous write time in ms in interval
bp_pool_sync_writes
65
Warning
Monitors number of synchronous data writes in interval
bp_pool_write_time
85
Warning
Monitors elapsed time for physical write of data/index pages
db_active_sorts
800
Warning
Monitors # of sorts currently having heap allocated
db_agents_top
Warning
Monitors max # of agents associated at once with the database
db_appl_section_inserts
Warning
Monitors # of inserts due SQL section not found
db_appl_section_lookups
Warning
Monitors # of references to SQL work area
db_appls_cur_cons
25
Warning
Monitors number of applications currently connected
db_appls_in_db2
25
Warning
Monitors number of applications currently connected
15
Warning
Monitors average time for direct read in ms
25
Warning
Monitors average time for direct write in ms
db_avg_sort_heap
100
Warning
Monitors average number of pages allocated to sort heap in interval
db_avg_sort_time
10
Warning
Monitors average sort time in interval in sec
db_binds_precomplies
25
Warning
Monitors number of binds/precompiles
db_cat_cache_heap_full
25
Warning
Monitors number of of overflows due to databae heap full
50
Warning
Monitors percent of times, information was found in catalog cache
db_cat_cache_inserts
25
Warning
Monitors number of catalog cache inserts
db_cat_cache_lookups
25
Warning
Monitors number of catalog cache lookups
db_cat_cache_overflows
25
Warning
Monitors number of catalog cache overflows
db_commit_sql_stmts
25
Warning
Monitors number of commit SQL statements
db_connect_time
0.1
Warning
Monitors database connection time in seconds
db_connections_top
25
Warning
Monitors maximum number of connections
db_coord_agents_top
Warning
Monitors max # of coordinating agents
db_ddl_sql_stmts
25
Warning
Monitors number of DDL SQL statements
db_deadlocks
Warning
Monitors # of deadlocks occured in interval
db_direct_read_reqs
25
Warning
Monitors number of direct read requests
db_direct_read_time
25
Warning
db_direct_reads
25
Warning
Monitors number of direct reads
db_direct_write_reqs
25
Warning
Monitors number of direct write requests
db_direct_write_time
25
Warning
db_direct_writes
25
Warning
Monitors number of direct writes
db_dynamic_sql_stmts
25
Warning
db_failed_sql_stmts
25
Warning
Monitors number of failed SQL statements
db_files_closed
Warning
Monitors number of file-close operations
db_hash_join_overflows
Warning
Monitors # of times hash join data exceeded the available sort heap
space
db_hash_join_small_overflows
Warning
Monitors # of times hash join data exceeded the available sort heap
space by less than 10%
db_heap_top
100000
Warning
Monitors maximum database memory usage (in bytes)
db_int_auto_rebinds
25
Warning
Monitors number of auto rebinds
db_int_commits
25
Warning
Monitors number of internal commits
db_int_deadlock_rollbacks
25
Warning
Monitors number of rollbacks due to deadlock
db_int_rollbacks
25
Warning
Monitors number of internal rollbacks
db_int_rows_deleted
25
Warning
Monitors number of internal deletes
db_int_rows_inserted
25
Warning
Monitors number of internal inserts
db_int_rows_updated
25
Warning
Monitors number of internal updates
db_lock_escals
Warning
Monitors # of lock escalations (row->table)
db_lock_list_in_use
124000
Warning
Monitors total lock list memory in use (bytes)
db_lock_timeouts
Warning
Monitors # of timeouts in interval
db_lock_wait_time
Warning
Monitors total time dbase waited on locks in ms
db_lock_waits
Warning
Monitors # of times app. or connection waited for a lock
db_locks_held
80
Warning
Monitors # of locks currently held
db_locks_waiting
Warning
Monitors number of agents currently waiting on lock
db_logs_read
25
Warning
Monitors number of log pages read
db_log_util_rto
25
Warning
Monitors database log utilization
db_log_writes
25
Warning
Monitors number of log pages written
db_num_assoc_agents
Warning
Monitors current number of agents associated with the database
10
Warning
Monitors percentage of hash join small overflows
10
Warning
Monitors % of sort owerflows in interval
db_pkg_cache_inserts
25
Warning
Monitors number of sections inserted into cache
db_pkg_cache_lookups
25
Warning
Monitors number of package or section lookups
db_pool_async_data_read_reqs
100
Warning
Monitors number of asynchronous read requests
db_pool_async_data_reads
100
Warning
Monitors number of pages read asynchronously into the buffer pool
db_pool_async_data_writes
100
Warning
Monitors number of data pages asynchronously written to disk
db_pool_async_index_reads
Warning
Monitors number of times index was asynchronously read
db_pool_async_index_writes
100
Warning
Monitors number of index pages asynchronously written to disk
db_pool_async_read_time
100
Warning
Monitors total elapsed time spent reading by prefetcher
db_pool_async_write_time
100
Warning
Monitors total elapsed time spent asychronously writing
15
Warning
Monitors average asynchronous read time in ms in interval
25
Warning
25
Warning
Monitors average write time in ms in interval
db_pool_data_from_estore
100
Warning
Monitors number of data pages copied from extended sotrage
db_pool_data_l_reads
10
Warning
Monitors number of logical read requests
db_pool_data_p_reads
10
Warning
Monitors number of reads, requiring physical I/O
db_pool_data_to_estore
Warning
Monitors number of data pages copied to extended sotrage
db_pool_data_writes
10
Warning
Monitors number of times, data was physicaly written to disk
db_pool_drty_pg_steal_clns
100
Warning
Monitors number of times victim page cleaner was triggered
db_pool_drty_pg_thrsh_clns
100
Warning
Monitors number of times dirty page threshold reached
db_pool_hit_ratio
75
Warning
Monitors percentage of time a page was found in buffer pool
db_pool_index_from_estore
Warning
Monitors number of index pages copied from extended storage
db_pool_index_l_reads
10
Warning
Monitors number of logical read requests for index pages
db_pool_index_p_reads
10
Warning
Monitors number of index reads, page requiring physical I/O
db_pool_index_to_estore
Warning
Monitors number of index pages copied to extended sotrage
db_pool_index_writes
10
Warning
Monitors number of times, index page was written to disk
db_pool_lsn_gap_clns
100
Warning
Monitors number of times logging space used reached threshold
db_pool_read_time
10
Warning
Monitors total elapsed time for physical read of data/ixdex pages
10
Warning
Monitors number of synchronous index page reads per interval
10
Warning
Monitors number of synchronous index page writes per interval
db_pool_sync_reads
75
Warning
Monitors number of synchronous data reads per interval
db_pool_sync_idx_write_time
15
Warning
Monitors synchronous write time in ms in interval
db_pool_sync_writes
10
Warning
Monitors number of synchronous data writes per interval
db_pool_write_time
10
Warning
Monitors total elapsed time for physical write of data/ixdex pages
db_prefetch_wait_time
25
Warning
Monitors time waited for prefetch
db_rollback_sql_stmts
25
Warning
db_rows_deleted
25
Warning
Monitors number of rows deleted
db_rows_inserted
25
Warning
db_rows_selected
25
Warning
Monitors number of rows selected
db_rows_updated
25
Warning
db_sec_log_used_top
25
Warning
Monitors maximum secondary log space used (in bytes)
db_sec_logs_allocated
25
Warning
Monitors number of secondary logs allocated at the moment
db_select_sql_stmts
25
Warning
Monitors number of select SQL statements
db_since_last_backup
24
Warning
Monitors number of hours since last backup
db_sort_heap_allocated
Warning
Monitors current number of pages allocated to sort heap
db_sort_overflows
800
Warning
Monitors # of sort overflows to disk
db_static_sql_stmts
25
Warning
db_status
Warning
Monitors database status
db_tot_log_used_top
25
Warning
Monitors maximum total log space used (in bytes)
db_total_cons
25
Warning
Monitors number of connects
db_total_hash_joins
Warning
Monitors # of hash joins executed in interval
db_total_hash_loops
Warning
Monitors # of times single partition of hash join was larger than the
available sort heap space
db_total_sec_cons
25
Warning
Monitors max. number of secondary connections
db_total_sort_time
800
Warning
Monitors total elapsed time in ms
db_total_sorts
Warning
Monitors # of sorts executed
db_uid_sql_stmts
25
Warning
Monitors number of Update, Insert, Delete SQL statements
db_x_lock_escals
Warning
Monitors # of x-lock escalations (row->table)
i_agents_created_empty_pool
Warning
Monitors number of agents created because the agent pool was

empty
50
Warning
Monitors Agents Created Due to Empty Agent Pool by Agents

Assigned From Pool in %
i_agents_from_pool
20
Warning
Monitors number of agents assigned from pool
i_agents_registered
150
Warning
Monitors # of agents curr. registered in instance
i_agents_registered_top
150
Warning
Monitors max. # of agents ever registered since DB2 start
i_agents_stolen
Warning
Monitors # of agents stolen from applications in interval
i_agents_waiting_on_token
10
Warning
Monitors # of agents waiting for free token in instance
i_agents_waiting_top
10
Warning
Monitors max. # of agents ever waiting for token since DB2 start
i_agents_dbalive
Warning
Monitors connectivity to the db2 databases
i_comm_private_memory
1000000
Warning
Monitors amount of committed private memory
i_con_local_dbases
Warning
Monitors # of local databases having open connections
i_coord_agents_top
Warning
Monitors max. # of coordinating agents since DB2 start
i_gw_cons_wait_client
Warning
Monitors # if gateway connections waiting for client reply
i_gw_cons_wait_host
Warning
Monitors # of gateway connections waiting for host reply
i_gw_cur_cons
Warning
Monitors current number of gateway connections
i_gw_total_cons
Warning
Monitors number of gateway connection attempts
i_idle_agents
Warning
Monitors number of unassigned agents in pool
i_local_cons
Warning
Monitors curr. # of local connections to the instance
i_local_cons_in_exec
Warning
Monitors curr. # of local connections to the instance executing
i_max_agent_overflows
Warning
Monitors # of times MAXAGENT parameter was reached (for DB2

before v9.5)
Warning
Monitors percentage of active connections to total allowed

connections
i_piped_sorts_accepted
Warning
Monitors number of piped sort requests accepted
Warning
Monitors number of of piped sort requests rejected
i_piped_sorts_requested
Warning
Monitors number of of piped sort requests
i_post_threshold_hash_joins
Warning
Monitors # of hash joins started after sort heap threshold exceeded
i_post_threshold_sorts
10
Warning
Monitors number of of times sort heap threshold has been reached
i_rem_cons_in
Warning
Monitors curr. # of remote connections to the instance
i_rem_cons_in_exec
Warning
Monitors curr. # of remote connections to the instance executing
i_sort_heap_allocated
8000
Warning
Monitors number of pages allocated for sort-heap at the moment
ts_data_partitioning
15
Warning
Monitors the data partitioning feature that is enabled in DB2 servers
ts_free_pages
1000
Warning
Monitors number of free pages in DMS table space
ts_free_pages_pct
10
Warning
Monitors percent of free pages in DMS table space
ts_max_used_pages
10000
Warning
Monitors maximum of used pages reached in DMS table space
95
Warning
Monitors maximum of used pages in % reached in DMS table space
ts_status
2114060287
Major
Monitors status of the tablespace
ts_total_pages
3500
Warning
Monitors total number of pages in table space
ts_usable_pages
2500
Warning
Monitors number of usable pages in table space (exlc. overhead)
ts_usable_pages_pct
10
Warning
Monitors percent of usable pages in DMS table space (exlc.

overhead)
ts_used_pages
2500
Warning
Monitors number of used pages in table space
ts_used_pages_pct
85
Warning
Monitors percent of used pages in table space
dcim (Data Center Infrastructure Management Monitoring)
The DCIM probe collects energy and power data from data center devices and provides this information to the CA UIM message bus. The DCIM
probe UI is used to view the QoS monitors and to configure alarms.
Each DCIM probe monitors devices as configured in the DCIM Administrator (dcimadmin) monitoring portlet. DCIM Administrator determines the
data center devices to monitor and the specific device data to collect.
More information:
For complete instructions about deploying, accessing, and using the DCIM probe within the DCIM for UIM environment, go to CA DCIM
for Unified Infrastructure Management.
dirscan (File and Directory Scan)

The File and Directory Scan (dirscan) probe monitors files in specific directories. Alarms can be sent on the number, age, and space that is used
by files.
This probe monitors files and directories, as follows:
Existence of directories
Shared directories (Windows systems only)
Named files or file patterns in a directory (option to include subdirectories)
The probe is configured by defining one or more profiles. Each profile identifies a particular directory and the required files. You can configure
different parameters that can be checked. All the following parameters can generate alarm messages if the specified threshold is breached:
Number of files
The number of files that are found in the specified directory matching the specified pattern.
Age of file
The age of the files that are found in the specified directory matching the specified pattern.
Space that is used by files
The space that is used by all files that are found in the specified directory matching the specified pattern.
Size of files
The size of the files that are found in the specified directory matching the specified pattern.
Read response time
The time that is required to read the specified file.
Directory check
Directory age
The time that has passed from the previous change in the directory.
File integrity
Verifies if the files that are specified for file integrity monitoring have changed.
The probe also generates QoS data for the following parameters:
Age of oldest/newest matching file
Space that is used by matching files
File read response time
File integrity
More information:
dirscan (File and Directory Scan) Release Notes
v3.1 dirscan AC Configuration

This article describes the configuration concepts and procedures to set up the File and Directory Scan (dirscan) probe. The following diagram
outlines the process to configure the dirscan probe to monitor a directory.
Contents
Create and Configure File and Directory Monitoring Profiles
Create and Configure File Integrity Profiles
Add Files for Integrity Monitoring
Alarm Thresholds
information, see dirscan (File and Directory Scan) Release Notes.

This section describes the minimum configuration settings required to configure the dirscan probe for file and directory monitoring. This probe is
configured to monitor a file or directory for the following:
Directory existence
Particular files or file types that are located in the directory
Ensure that size and age of the files do not exceed an expected value
Follow these steps:
1. Click the Options (icon) next to the Profiles node.
2. Select Add Profile.
The Profile General Configuration window is displayed.
Note: You can also select and modify the sample profile available in the probe.
3. Specify a name and description for the profile.

4.
4. Click Submit.
A node with the specified profile name is created under the Profiles node.
5. Select Active to activate the profile in the Profile Name node.
6. Specify the directory with the files to be monitored.
You can also select a directory using the Browse button.
7. Specify the regular expression pattern of the files to be monitored.
Example: *.txt for all files with the txt extension. Refer Using Regular Expressions for Files section in the dirscan Regular
Expressions article for more information.
8. Select Recurse Into Subdirectories to include the files that are present in the subdirectories of the specified directory.
The Exclude Directories Pattern field is enabled.
9. Specify the regular expression pattern of the subdirectory names that will be excluded from monitoring.
Example: %B for all directories with the full name of a month. Refer Using Regular Expressions for Directories section in the dirscan
Regular Expressions article for more information.

This section describes the minimum configuration settings required to configure the dirscan probe for file integrity monitoring. The probe is
configured to monitor the integrity of files to notify you when the file or files are modified.
Follow these steps:
1. Click the Options (icon) next to the Integrity Profiles node.
The Integrity Profile Information window is displayed.
Note: You can also select and modify the sample integrity profile available in the probe.

4. Select Active to activate the profile immediately after creation.
5. Click Submit.
A node with the specified profile name is created under the Integrity Profiles node.
6. Configure the QOS_FILE_INTEGRITY monitor to set up the alarm thresholds.
7. Add the files to be monitored in the File Integrity section.
Refer Add Files for Integrity Monitoring for more information.
8. Activate the profile and save the configuration.
Add Files for Integrity Monitoring

You can either specify individual files or a regular expression pattern for all files in a directory to monitor for file integrity.
Add Individual Files

You can individually add each specific file to be monitored for integrity.
Follow these steps:
1. Click the New button in the File Integrity section of the integrity profile name node.
2. Click the Browse button to browse for the file to be monitored.
You can also specify the path of the file in the text box.
3. Click Actions > Recalculate Checksum to generate and save a checksum of the file at the current moment.
A message is displayed that the checksum has been recalculated. An error message is displayed if the file does not exist or is not
accessible by the credentials specified in the dirscan node.
Add Files in a Directory

You can add files to be monitored for integrity by specifying the directory and the regular expression for the files.
Follow these steps:
1. Click the New button in the Pattern Configuration section of the integrity profile name node.
2. Click the Browse button to browse for the directory to be monitored.
You can also specify the path in the text box.
4. Click Actions > Show Files to view a list of the files matching the regular expression in the specified directory.
These are the files that will be monitored by the probe.
Alarm Thresholds
allow the probe to:
v3.1 dirscan AC GUI Reference

This article describes the configuration GUI for the File and Directory Scan (dirscan) probe.
Contents
dirscan Node
Integrity Profiles Node
<Integrity Profile Name> Node
Profiles Node
<Profile Name> Node
dirscan Node
This node allows you to configure the general properties of the probe. You can also view the list of alarm messages and their properties.
Navigation: dirscan
dirscan > Probe Information
dirscan > General Configuration
This section allows you to configure the general properties of the probe.
Check Interval (seconds): specifies the time interval at which the directories are scanned. You can reduce this interval to generate alarms
faster (as next interval takes lesser time) but it increases the system load. You can also increase this interval to reduce the system load
but it generates alarms later (as next interval takes more time).
Default Message Level: specifies the level of the alarm message.
Default: 0-Fatal
Log Size (KB): specifies the size of the file to which the internal probe messages are stored.
User Name (including domain name): defines the user name to access the directory or the file. The user name must include the domain
name.
dirscan > Message Pool
This section allows you to view the list of alarm messages and their properties.
Identification Name: indicates the name of the alarm message.
Token: indicates the checkpoint that the probe sets.
Error Alarm Text: specifies the text of the alarm message.
Clear Alarm Text: specifies the text of the message that is issued after the erroneous values are back within the threshold limits.
Error Severity: indicates the severity of the alarm.
Subsystem string/ID: indicates the ID of the sub system which issues the alarm.
Integrity Profiles Node

This node allows you to create and configure an integrity profile.
Navigation: dirscan > Integrity Profiles
Integrity Profiles > Add Profile > Integrity Profile Information
This section allows you to create the integrity profile.
Profile Name: defines the name of the integrity profile.
Active: allows you to activate the integrity profile.
Description: specifies the profile description.
<Integrity Profile Name> Node

This node allows you to configure the properties of the integrity profile of the File and Directory Scan probe. You can also configure the QoS
properties of the integrity profile.
Note: The integrity profile is added as a child node under the Integrity Profiles node.
Navigation: dirscan > Integrity Profiles > integrity profile name

integrity profile name > Integrity Profile Information
This section allows you to configure the properties of the integrity profile. The fields in this section are as follows:
Profile Name: defines the name of the integrity profile.
Active: allows you to activate the integrity profile.
Description: specifies the profile description.
integrity profile name > Quality of Service message
This section allows you to configure the QoS message send by the probe.
Message ID: specifies the alarm message appearing on the detection of a change in the file.
Command: defines the action that is taken on the detection of a change in the file.
File Integrity: activates the monitoring of one or more specified files for detecting any change.
integrity profile name > File Integrity
This section allows you to add a file to the probe for monitoring.
File: specifies the directory path and name of the file to be monitored.
Actions > Recalculate Checksum

Generates and stores a checksum of the file at the current moment.
integrity profile name > Pattern Configuration
This section allows you to select multiple files for monitoring based on a pattern.
Path: specifies the directory path of the files to be monitored.
Pattern: defines the string that is matched in the files that are present in the directory. Those files that match with the pattern are
included.
Refer Using Regular Expressions for Files section in the dirscan Regular Expressions article for more information.
Actions > Show Files
Displays all files in the directory that match the specified pattern.
Profiles Node
This node allows you to create a monitoring profile for the File and Directory Scan probe.
Navigation: dirscan > Profiles
Profiles > Add Profile > Add
This section allows you to create and configure a monitoring profile for the File and Directory Scan probe.
Profile Name: Defines the name of the monitoring profile.
<Profile Name> Node

This node allows you to configure the properties of the monitoring profile. You can also configure the properties of the directory or the file that is
monitored.
Note: The integrity profile is added as a child node under the Profiles node.
Navigation: dirscan > Profiles > profile name

profile name > Profile General Configuration
This section allows you to configure the properties of the monitoring profile.
Active: activates the monitoring of files and directories.
Directory: defines the path of the directory that is scanned.
Pattern: defines the string that is matched in the files that are present in the directory. Those files that match with the pattern are
included.
Refer Using Regular Expressions for Files section in the dirscan Regular Expressions article for more information.
Recurse into subdirectories: includes the subdirectories of the directory that is scanned.
Exclude directories Pattern: defines the pattern that is matched with the files for determining the files that are excluded.
Refer Using Regular Expressions for Directories section in the dirscan Regular Expressions article for more information.
This section allows you to configure the performance counters for generating QoS.
Note: The performance counters are visible in a tabular form. You can select any one counter in the table and can configure its
properties.
profile name > Monitors > Directory Age

This performance counter verifies the age of a file in the directory. The file can be the newest file, the oldest file or, an individual file.
Operator: specifies the operator that is used to set the condition for comparing the measured value with the specified value.
Value: specifies the condition for comparing the measured value.
Unit: specifies the unit for comparing the measured value

Message: specifies the message that is issued when the specified condition is not met.
Command: defines the action that is performed when the specified condition is not met.
Age Of: specifies the age of file that matches the pattern. The file can be the newest file, the oldest file or, an individual file.
The QoS is generated for the newest file if Individual File is selected.
On Creation Time: specifies the creation time of the file which is used while defining threshold.
profile name > Monitors > Directory Exists
This performance counter verifies whether the specified directory exists or not.
Message: specifies the message that is issued when the directory is not found.
Command: defines the action that is performed when the directory is not found.
QoS Directory exists: issues the QoS message when the directory is not found.
Note: The current version of the File and Directory Scan probe does not monitor shared directories on a network.
profile name > Monitors > Directory Modification

This performance counter verifies if the directory has changed between each scan. This type of change occurs when a file is created or removed
from the directory.
profile name > Monitors > Directory Space Used
This performance counter configures the space used by all files found matching the specified pattern in the directory. You can also generate
alarms for any changes made to the file size.
Operator: specifies the space condition and unit.
Value: specifies the value for checking the specified file.
Unit: specifies the unit for comparing the measured value.
Message: specifies the alarm message that is generated when the file space breaches the specified condition.
Delta Operator: specifies the used space delta condition and unit.
Cycle: specifies the number of cycles over which the used space delta value is calculated.
Delta Message: specifies the alarm message that is generated when the file space breaches the threshold condition.
Command: specifies a command to be performed when the specified condition is not met.
profile name > Monitors > File Count
This performance counter allows you to scan the total number of files found in the specified directory matching the specified pattern.
Operator: specifies the operator that is used to set the condition for comparing the measured value with the specified value.
Value: specifies the condition for comparing the measured value.
profile name > Monitors > File Read Response Time
This performance counter allows you to configure the time taken to read the specified file.
Note: When specifying read response time, the response time is calculated from reading the first one Megabyte of the file. If no file
specified, the largest file in the directory is read for generating the QoS for the File Read Response Time. You can watch for the
shortest, longest, or and individual file in the directory.
profile name > Monitors > Size of File

This performance counter allows you to configure the size of the file found in the specified directory matching the specified pattern.
Operator: specifies the threshold operator for comparing the measured value with the specified value.
Value: specifies the threshold value for comparing the actual file size. This field accepts only an integer value.
Unit: specifies the unit for comparing the measured value.
Message: specifies the alarm message that is generated when the file size breaches the threshold condition.
Command: specifies the action to be performed when the specified condition is not met.
Size Of: specifies the size of file that can be configured to use the size of the newest file, the oldest file, or each individual file, when more
than one file match the pattern.

If you migrate the probe using threshold_migrator, the relational operators in the probe reverse in their logic. While alarms were initially generated
for files not meeting the relational criteria, now the alarms are generated for file meeting the reversed criteria.
Example: If the probe was configured to generate an alarm for a threshold value that was not less than or equal to the QoS value, it now
generates the alarm for the threshold value that is greater than the QoS value.
The operators before and after migration are listed as follows:
v3.1 dirscan IM Configuration

This article describes the configuration concepts and procedures for setting up the File and Directory Scan (dirscan) probe. The following diagram
outlines the process to configure the dirscan probe to monitor a directory.
Contents
Manage Patterns for File Integrity
Create Schedules
Example of Creating a Profile
information, see dirscan (File and Directory Scan) Release Notes.

This section describes the minimum configuration settings required to configure the dirscan probe for file and directory monitoring. This probe is
configured to monitor a file or directory for the following:
Directory existence
Particular files or file types that are located in the directory
Ensure that size and age of the files do not exceed an expected value
Follow these steps:
1. Click the Create a new Profile button.
The New Profile window opens. The dialog contains some general properties and three main tabs - Scan Directory, Alarm Messages,
Quality of Service messages.
4. Select the required schedule from the Schedule drop-down list.
This field contains the list of already configured schedules. Refer Create Schedules for more information.
Note: If a schedule is attached to at least one profile, the schedule cannot be deleted.
5. Specify the directory to be monitored in the Scan Directory tab > Directory field.
You can select a directory using the Browse button.
7. Select Recurse Into Subdirectories to include the files that are present in the subdirectories of the specified directory.
The Exclude Directories Pattern field is enabled.
8. Specify the regular expression pattern of the subdirectory names that are excluded from monitoring.
Example: %B for all directories with the full name of a month. Refer Using Regular Expressions for Directories section in the dirscan
Regular Expressions article for more information.
9. Configure the required alarms in the Alarm Messages tab.
You can also click Fetch current values to fetch the current values and start monitoring based on them.
10. Select the required Quality of Service (QoS) messages to be generated in the Quality of Service messages tab.

This functionality allows you to create a new integrity profile.
Follow these steps:
1. Click the Create a new Integrity Profile button.
1.
The New Profile window opens. The dialog contains some general properties and three main tabs - File Integrity, Alarm message,
Quality of Service message.
You can also schedule the profile. Refer Manage Schedules for more information.
4. Select the required schedule from the Schedule drop-down list.
This field contains the list of already configured schedules. Refer Create Schedules for more information.
Note: If a schedule is attached to at least one profile, it cannot be deleted.
5. Right-click in the File Integrity tab and select Insert File.

The Select File dialog opens.
Note: You can also add a pattern with a regular expression to monitor all matching files in the directory. Refer Manage
Patterns for File Integrity for more information.
6. Browse for the file, select it, and click OK to add it to be monitored.
7. Click << Recalculate checksum to generate and save a checksum of the file at the current moment.
accessible by the credentials that are specified in the Setup window.
8. Configure the file integrity alarm in the Alarm Messages tab.
9. Select the File Integrity Quality of Service (QoS) message to be generated in the Quality of Service messages tab.
Manage Patterns for File Integrity

You can add files that are based on regular expression patterns to an integrity profile.
Follow these steps:
1. Right-click in the File Integrity tab and select Add Pattern.
The Pattern [New] dialog opens.
2. Click Browse to select the directory with the files to be monitored.
4. Click Refresh to view a list of the files matching the regular expression in the specified directory.
The probe monitors the files.
5. Click << Recalculate checksum to generate and save a checksum of the files at the current moment.
Note: You can also recalculate the checksum of a file in an existing profile. You can then monitor the future integrity of the file
that is based on the current state.
accessible by the credentials that are specified in the Setup window.
6. Click OK to accept the pattern.
Note: You can right-click in the File Integrity tab and select Edit Pattern or Delete Pattern to edit or delete the pattern. If you edit a
pattern, the Pattern [strPattern] window is displayed with the pattern. Follow Step 2 - 6 of Manage Patterns for File Integrity to edit the
pattern.
Create Schedules
The Schedules tab enables you to specify the time duration when the probe generates alarms and QoS for the monitored process.
Follow these steps:
1. In the Setup window, click the Schedules tab.
2. Right-click and select Add.
The New Schedule dialog opens.
3. Specify a name for the schedule.
4. Specify the Start and End of the schedule in the Range section.
5. Specify the frequency of the schedule.
6. Specify whether to generate alarms or QoS only for a day or within a time frame on specific days.
7. Click OK.
The schedule is created.
Example of Creating a Profile

Assume that you want to define a profile for the dirscan probe to monitor the directory D:/. You also want to send an alert when the probe finds
files greater than 25 Kilobytes.
1. Double-click the dirscan probe in Infrastructure Manager to bring up the dirscan configuration dialog. You can use the default values in
the Setup tab:
Check interval is changed to 30seconds.
Message level is left at information.
Log Level is set to a middle value.
Log Size left at 100KB.
2. Click OK and right-click in the window and select New Profile.
3. When the New Profile dialog appears on the screen, specify the following:
A profile name (Example: History)
A short description of the profile
Click the Active option to enable the profile
Specify the directory with the files to monitor (D:\).
Select pattern (* means checking all files in the D:\ directory)
Select Recurse into subdirectories. The scanning process also includes files residing in subdirectories of the C:\history directory.
4. Open the Alarm messages > Space used by files tab
5. Specify the following details:
Watch
You can receive an alert when files greater than 25 Kilobytes years are found.
Alarm Message
Select the alarm message FileSpaceAlarm from the drop-down list.
Used space delta
If you expect a slight change in the file size up to a certain limit over a defined number of cycles, you can set the threshold value.
6. Click OK.
You return to the dirscan configuration dialog.
7. Ensure that the new watcher is checked and click the Apply button.
8. Click Yes when the confirmation message is displayed.
9. Click OK button in the dirscan configuration dialog.
You can now verify the profile works as follows:

Ensure that the directory D:\ exists and contains files greater than 25 Kilobytes. The probe generates the applicable alarm.
or
Ensure that the directory D:\ does not exist. The probe generates a directory not found alarm.
v3.1 dirscan IM GUI Reference

This article describes the configuration GUI for the dirscan probe.
Contents
Probe Interface
Tool Buttons
Profile List
Setup Window
General Tab
Schedule Tab
Profiles
Scan Directory Tab
Alarm Messages Tab
Quality of Service Messages Tab
Integrity Profiles
File Integrity Tab
Alarm Message Tab
The Quality of Service Message Tab
Message Properties Window
Probe Interface
The GUI consists of four tool buttons at the top and a list of profiles. All defined monitoring profiles appear in the list.
Tool Buttons
The configuration tool also contains four tool buttons:
General Setup
Opens the Setup window for the probe and allows you to modify the general probe parameters. Refer General Setup for details.
Create a New Profile
Creates a profile defining a destination folder and files to be monitored.
Create a New Integrity Profile
Creates a profile to verify the integrity of particular files. Profiles of this type appear in the profile list with a different icon.
This option allows you to customize the alarm text, and you can also create your own messages.
Profile List
The probe GUI contains a list of profiles. The default configuration contains two sample profiles. Right-clicking the window makes the following
menu options available:
New Profile
Creates a directory scan profile.
New Integrity Profile
Creates a file integrity profile.
Edit
Edits the currently selected profile.
Delete
Removes the currently selected profile.

Copy
Makes a copy of the selected profile when you want to create a profile with almost the same properties as an existing one.
Setup Window
Clicking the General Setup button opens the Setup window, allowing you to modify the general probe parameters. In this screen, you can also
find the Schedules tab in which you can schedule the profile execution according to your requirement.
General Tab
The General tab allows you to modify the general probe parameters.
The fields in the window are explained as follows:
Check interval (seconds)
Indicates the time interval at which the defined directories are scanned. You can reduce this interval to generate alarms faster (as next
interval takes lesser time) but it increases the system load. You can also increase this interval to reduce the system load but it generates
alarms later (as next interval takes more time).
Default message level
Indicates the default message level for alarm messages. This value can be overridden in each alarm condition.
Log Level
Sets the level of details written to the log file. Log as little as possible during normal operation to minimize disk consumption, and
Log Size
Sets the size of the probes log file to which probe-internal log messages are written. The default size is 100 KB. When this size is
reached, the contents of the file are cleared.
Run as user
Specifies a valid user name and password to allow access to required files and directories. Note that the user name also must include the
Windows domain name (<domain name>/<user name>).
Schedule Tab
The Schedules tab enables you to specify the time duration in which alarms and QoS for the monitored process should be generated.
New Schedule Window
Name
Specifies a name for the schedule.
Range
Specifies the time duration for which the alarms/QoS should be generated.
Notes:
To start alarm generation immediately, select option Start Now.
To start alarm generation at a specific date-time in future, select the option Start at and then select the required date-time.
To continue alarm generation indefinitely, select the option No End.
To stop the alarm generation after specific number of occurrences, select End after_ occurrences and enter the number of
occurrences. If the processes probe restarts, the count for number of occurrences is reset.
To stop the alarm generation at a specific date-time in future, select the option End by and then select the required date-time.
Pattern
Specifies the pattern in which the alarms/QoS are generated. Select a pattern (Secondly, Minutely, Hourly, Daily) and then specify the
value at which the pattern is repeated.
Restrict To
Specifies whether to generate alarms or QoS only for a day or within a time frame on specific days.
Note: The following points need to be taken into consideration while choosing the appropriate time range for the alarms/QoS:
If you select Start Now option and set Restrict To settings to a later day/time, the alarms/QoS are generated on the day/time
specified in Restrict To field.
If you set Restrict To option to, say 3:00 AM to 4:59 AM, and set Start at option to a later time (say 4:00 PM for same day),
then the alarms/QoS are generated from 4:00 PM.
If you select End at option at, say 11:00 AM and set Restrict To settings to an earlier time (say, 10:30 AM), then alarms/QoS
cannot be generated after 10:30 AM.
If you select End at option at, say 5:30 PM, and set Restrict To settings to a later time (say, 6:30 PM), then alarms/QoS
cannot be generated after 5:30 PM.
The shortest time frame, based on the combination of all the filters applied, are taken into consideration for generating alarms/QoS
messages.
Profiles
The New Profile window contains some general properties and the following tabs:
Scan Directory
Alarm messages
Quality of Service messages
When creating or editing a profile, the following values must be specified:
Name
Specifies the name of the profile.
Active
Determines whether the profile should be active or not.
Description
Specifies a short description of the profile.
Schedule
Selects the schedule of execution for the profile.
Scan Directory Tab
When creating or editing a profile, the following values must be specified:

Directory
Specifies the directory that is scanned. You must specify the value in the Directory field to proceed.
Note: You can also specify a directory name (or parts of a directory name) using special time-formatting primitives. Refer dirscan
Regular Expressions.
If the probe runs on a Windows system, remote shares can be monitored when the directory is specified with the format //<computer
name>/<share name> or //<computer name>/<share name>/<directory>. When this syntax is used, two additional fields appear: User and
Password. The user name is specified as <domain>\<user>. You can use the Fetch current values button in the Alarm messages tab to verify
that the specified combination of values is valid. If not specifying anything, the user and password specified under the Setup tab is used.
Notes:
Multiple directories can be specified separated with a ';' sign.
Remote shares should be placed first, to be able to specify user and password.
Browse
Opens the Select Directory window where you can select a directory or a file.
Notes:
The Browse function cannot work when more than one directory is specified.
Select a directory and press the OK button to fill in the Directory field for you.
Select a file and press OK to fill in both the Directory and Pattern fields.
Pattern
Specifies a pattern, which is matched with the files found in the specified directory. When verifying, only the files matching this pattern are
included. Refer dirscan Regular Expressions for more information.
Recurse into subdirectories
Determines if the scanning process also should include files residing in sub-directories of the specified directory.
Alarm Messages Tab
The individual alarm tabs are described as follows:

Number of files
Monitors the number of files found in the specified directory matching the specified pattern.
Age of file
Monitors the age of the files found in the specified directory matching the specified pattern. Here, if you select On creation time, then
creation time of the file is used while defining threshold.
Space used by files
Monitors the space used by all files found in the specified directory matching the specified pattern. You can also generate alarms for any
changes made to the file size.
Size of individual file
Monitors the size of the largest file found in the specified directory matching the specified pattern.
Read response time
Monitors the time taken to verify the specified file.
Note: When specifying read response time, the response time is calculated from reading the first one Megabyte of the file. If no file is
specified, the largest file in the directory is read for the quality of Service response time.
Directory check
Directory age
Verifies if the directory has changed between each scan. Such a change would happen if a file is created or removed from the directory.
Note: This option monitors only the specified directory even if the Recurse into subdirectories option is set.
Alarm Tabs
The following fields are common for all the alarm tabs:
Fetch current values
Verifies the current value of the monitored target. This might be helpful to do before defining the alarm threshold in the Watch field.
Watch
Specifies the condition you want the measured value to meet. If the specified condition is breached, the selected alarm message selected
is generated.
Note: The value can be a checkbox to be selected or a combination of an operator, a value, or the unit of measurement.
Alarm message
Selects an alarm message and a clear message from the drop-down list for each alarm. These messages are available in the message
pool, where you can also create your own messages or edit existing ones.
Automatic action > Command
Defines the action that is performed when the specified condition is not met.
You can specify the arguments of the command which can include the following variables:
$watcher: Returns the name of the monitoring profile.
$description: Returns the description of the monitoring profile.
$file: Returns the name of the file or the file name pattern, which the probe is monitoring in the monitoring profile. If there are more
than one file, it returns the array of file names and the probe executes the command for that number of times.
$size: Returns the size of the file or directory, which the probe is monitoring. If there are more than one file, it returns the array of file
size and the probe executes the command for that number of times.
$unit: Returns the unit of file size, which is configured in the monitoring profile of the probe. This variable also converts the size of the
file or directory in this unit. For example, you are monitoring the file greater than 100 bytes and the probe identifies a file of 1 KB. In
this case, the probe returns the file size as 1024 Bytes.
$limit: Returns the threshold limit of the file or directory size, which is configured in the monitoring profile.
$directory: Returns the complete path of the directory, which is configured in the monitoring profile of the probe.
Notes:
Age of file can be configured to use the age of the newest file, the oldest file or each individual file found when more than one
file match the pattern.
Size of file can be configured to use the smallest file, largest file or each individual file.
Read response time can be configured to use the shortest response time, longest response time, or each individual response
times.
Quality of Service Messages Tab
Enable the properties for which you want Quality of Service message to be generated.
The following values can be checked:
Directory exists
Age of newest matching files
Space used by matching files in KiloBytes
Read response time of largest file in Bytes per Second
Integrity Profiles
The New Integrity Profile and Integrity Profile: Profile Name windows contain some general properties and the following tabs:
File Integrity
Alarm message
Quality of Service message
When creating or editing a profile, the values must be specified as described in the Profiles section.
File Integrity Tab
This tab allows you to specify one or more files to be monitored, verifying if any changes have taken place. Right-clicking in the list opens a
browser enabling you to add or delete files to be monitored. If one of the files defined here is modified, an alarm message is sent. You can also
add, edit, or delete patterns.
Insert File...
Opens the Select File dialog to add a file to be monitored for integrity monitoring. You can also access a network directory by specifying
the user and password details.
Refer Scan Directory Tab section for more information.
Remove File
Removes the file from the list of files to be monitored for integrity monitoring.
Add Pattern
Opens the Pattern [New] window box to add all files matching a regular expression from a directory. Refer dirscan Regular
Expressions for more information.
Edit Pattern
Opens the Pattern [strPattern] window box to edit the regular expression to match files from a directory.
Remove Pattern
Removes the pattern from the list of patterns to be monitored.
The tab also contains the << Recalculate Checksum button.

<< Recalculate Checksum
Calculates and sets the Checksum of the file. This value is used when monitoring the file. If the Checksum of the file becomes different
from this value, an alarm message is sent.
Pattern Window
This window (displayed as Pattern [New] or Pattern [strPattern] windows) allows you to configure the patterns to select files for integrity
monitoring.
The fields in this window are described as follows:
Path
Displays the path of the files to be monitored for integrity.
Browse
Opens the Select Directory window to select the directory with the files to be monitored for integrity.
The path of the selected directory is displayed in the Path field.
Pattern
Specifies the regular expression pattern for the files to be monitored for integrity.
Refresh
Displays the list of files matching the pattern specified in the Pattern field.
<< Recalculate Checksum
Calculates and sets the Checksum of the file. This value is used when monitoring the file. If the Checksum of the file becomes different
from this value, an alarm message is sent.
Alarm Message Tab
The Alarm message tab allows you to specify the alarm message, in the Message ID field, and action, in the Command field, to be taken when a
file change is detected. The value in the Command field can be configured as described in the Profiles > Alarm Message Tab > Automatic
action > Command section.
The Quality of Service Message Tab
This tab allows you to select if a Quality of Service message should be sent on each check interval.

The Message Pool can be opened by clicking the Message Pool Manager button in the tool bar.
The Message Pool lists all the available alarm messages. When defining the alarm properties for the profiles, you can select one of the alarm
messages in this list to be issued when the defined threshold is breached. Using the three tool buttons located in the upper left corner of the
Message Pool window, or right-clicking in the list, you can select to add, edit or delete alarm messages.
Message Properties Window

Identification Name
Specifies the identification name of the alarm message. This name appears in the drop-down list when selecting an alarm message on
the Alarm Messages tab in the Profiles window.
Token
Selects the message token refers to the checkpoint. It is pre-set by the probe and is therefore not modifiable.
Error Alarm text
Specifies the text of the alarm message. Typing $ in this field lists all the valid variables.
Clear Alarm text (OK)
Specifies the text of the clear message. A Clear message is issued if Alarm messages on breached thresholds have previously been
issued, and the newly measured value is now within the threshold. Typing $ in this field lists all the valid variables.
Error Severity
Selects the severity of the alarm (clear, information, warning, minor, major or critical).
Subsystem string/id
The ID of the subsystem being the source of this alarm. This id is managed by the nas probe.
dirscan Metrics
The article describes the metrics that can be configured for the File and Directory Scan (dirscan) probe.
Contents
QoS Metrics
QoS Metrics
The following table describes the checkpoint metrics that can be configured using the dirscan probe.
Monitor Name
Units
Description
Version
QOS_DIR_AGE
Seconds
The duration that the file has existed in the monitored directory
3.1
QOS_DIR_EXISTS
Boolean
Directory exists or not
3.1
QOS_DIR_SPACE
Kilobytes
The total size of all files in the specified directory matching the specified pattern.
3.1
QOS_DIR_NUMBER
Number
The total number of files in the specified directory matching the specified pattern.
3.1
QOS_DIR_RESPONSE_TIME
Bytes/Second
The time taken to read the specified file.
3.1
The alarms for some QoS change after migration using threshold_migrator, when they use the standard static thresholds instead of probe specific
alarms. The old and new alarm messages are listed in the table below.
Monitor Name
Original Alarm
Migrated Alarm
QOS_DIR_AGE
Alarm message $watcher: $description file age $age $unit,

expected $operation $limit $unit ($file)
Alarm message $watcher: $description file age ${value}

$unit, expected ${operator} ${threshold} $unit ()
Clear message $watcher: $description file age $age $unit

($file): Clear
Clear message $watcher: $description file age ${value}

$unit (): Clear
Alarm message $watcher: $description $number files found

occupying $space $unit, expected $operation $limit $unit
Alarm message $watcher: $description files found

occupying ${value} $unit, expected ${operator} ${threshold}
$unit
QOS_DIR_SPA
CE
Clear message $watcher: $description $number files found

occupying $space $unit: Clear
QOS_DIR_RES
PONSE_TIME
QOS_DIR_NU
MBER
Clear message $watcher: $description files found

occupying ${value} $unit: Clear
Alarm message $watcher: $description read $file in $time

$unit, expected $operation $limit $unit
Alarm message $watcher: $description read in ${value}

$unit, expected ${operator} ${threshold} $unit
Clear message $watcher: $description read $file in $time

$unit: Clear
Clear message $watcher: $description read in ${value}

$unit: Clear
Alarm message $watcher: $description $number files,

expected $operation $limit
Alarm message $watcher: $description ${value} files,

expected ${operator} ${threshold}
Clear message $watcher: $description $number files: Clear
Clear message $watcher: $description ${value} files: Clear

This section contains the alert metric default settings for the dirscan probe.
Monitor Name
Warning
Threshold
Warning
Severity
Error
Threshold
Error
Severity
Description
FileSizeAlarm
None
None
None
Major
The size of the monitored file is outside of the specified threshold value.
FileNumberAlarm
None
None
None
Major
The number of monitored file(s) is outside of the specified threshold value.
FileSpaceAlarm
None
None
None
Major
The space occupied by monitored file(s) is outside of the specified threshold

value.
FileDeltaSpaceAlarm
None
None
None
Major
The change in the space occupied by monitored file(s) is outside of the

specified threshold value.
FileAgeAlarm
None
None
None
Major
The duration that the file(s) are present in the monitored directory is outside
of the specified threshold value.
ResponseTimeAlarm
None
None
None
Major
The response time of the monitor is outside of the specified threshold value.
FileIntegrityAlarm
None
None
None
Major
The file integrity check failed due to modification to the file.
DirectoryCheckAlarm
None
None
None
Major
The specified directory does not exist.
FileError
None
None
None
Major
The specified file(s) do not exist in the monitored directory.
DirAge
None
None
None
Major
The duration that the monitored directory is present is outside of the specified
threshold value.
dirscan Regular Expressions

The dirscan probe uses regular expressions to specify both files and directories to monitor. A regular expression (regex for short) is a special text
string for describing a search pattern. Constructing regular expression and pattern matching requires meta-characters.
Using Regular Expressions for Files

You can use regular expressions for files in both file and directory monitoring and file Integrity monitoring profiles. The probe matches the patterns
to select the applicable files in the specified directory for monitoring. The Pattern fields in Profile General Configuration section of profile name
node and Pattern Configuration section of integrity profile name node support regular expressions.
The patterns used for files are of the format filename.extension. The * and ? symbols are wild card operators and denote that all characters are
acceptable. The * represents multiple characters while the ? represents exactly one character.
The following table describes some examples of regex and pattern matching for files using the dirscan probe.
Regular
Expression
Type of Regular
Expression
Explanation
* or ?
Standard
Matches all files in the directory
*a
Custom
Matches all files with extensions that end with the letter a. For a file without an extension, the last
letter of the filename must be a.
*.txt
Standard
Matches all files in the directory with the txt extension.
*.t*
Custom
Matches all files in the directory with an extension that starts with a t.
?.*
Standard
Matches all files in the directory with a single character filename and of any extension.
NewFile?.*
Custom
Matches all files in the directory with a letter or number after NewFile and of any extension.
Examples: NewFile1, NewFilex etc.
[a]
Standard
Matches all files in the directory with the letter a in the filename or the extension.
?[a-c]section.*
Custom
Matches all files in the directory that start with the letters a, b, or c, followed by the word section in
the filename, and of any extension.
Example: bsection.xlsx
Using Regular Expressions for Directories

You can use regular expressions for directories in file and directory monitoring profiles. The probe matches the patterns to select the applicable
directories to exclude from monitoring. The Exclude directories Pattern field in Profile General Configuration section of profile name node
supports regular expressions.
The path may be constructed by a combination of text and special primitives used by the system-call strftime. The list of valid primitives are
described below:
%a - Abbreviated weekday name
%A - Full weekday name
%b - Abbreviated month name
%B - Full month name
%c - Date and time representation appropriate for locale
%d - Day of month as decimal number (01 31)
%H - Hour in 24-hour format (00 23)
%I - Hour in 12-hour format (01 12)
%j - Day of year as decimal number (001 366)
%m - Month as decimal number (01 12)
%M - Minute as decimal number (00 59)
%p - Current locales A.M./P.M. indicator for 12-hour clock
%S - Second as decimal number (00 59)
%U - Week of year as decimal number, with Sunday as first day of week (00 53)
%w - Weekday as decimal number (0 6; Sunday is 0)
%W - Week of year as decimal number, with Monday as first day of week (00 53)
%x - Date representation for current locale
%X - Time representation for current locale
%y - Year without century, as decimal number (00 99)
%Y - Year with century, as decimal number
%z, %Z - Time-zone name or abbreviation; no characters if time zone is unknown
%% - Percent sign
The following table describes some examples of regex and pattern matching for files using the dirscan probe.
Regular Expression
Type of Regular Expression
Explanation
%B
Standard
Matches all directories with the full name of a month.

Example: January
31%B
Custom
Matches all directories with the number 31 followed by the full name of a month.
Example: 31March
%B %Y
Standard
Matches all directories with the full name of a month followed by an year.
Example: January 2005.
%y/%m/%d
Custom
Matches all directories with names such as 05/10/22.
discovery_agent (Discovery Agent)

The discovery_agent probe scans the IT network, pinging and querying devices according to subnet masks/ranges, credential profiles, and
selected profiles. These scanning parameters are configured within the Discovery Wizard.
More Information:
discovery_server (Discovery Server)

In most installations, the discovery_server probe runs on the primary hub. The probe performs these major tasks:
Configures discovery agents and collects status from them.
Collects information about the UIM Server infrastructure: hubs, robots, probes, packages, monitored systems or devices, monitored
subsystems or items and monitored metrics.
Collects device data from probes that publish discovery information.
Applies correlation rules to associate new device records, where appropriate, with any already-existing master device records. One
example is to represent multi-homed devices (devices with multiple network interfaces) accurately.
The information that is collected by the discovery_server probe is stored in the UIM Server database and used by other UIM Server components.
The discovery_server probe also helps maintain the database by expiring inactive systems that dont have any associated QoS data.
Note: Even without any discovery_agent probes deployed, the discovery_server probe is still needed to generate the data required by
other components.
More Information:
diskstat (iSeries Disk Monitoring)

The iSeries Disk Monitoring (diskstat) probe monitors disks that are assigned to an Auxiliary Storage Pool (ASP) on IBM iSeries systems. The
probe identifies disks through disk properties such as ASP number, Disk Type and, Disk Unit Number. The probe enables you to monitor disk
performance and track disk activities such as disk usage, disk capacity, and the number of read and writes completed per second. The probe lets
you configure alarms and QoS for various disk operations and also generates alarms when a threshold is breached.
More information:
diskstat (iSeries Disk Monitoring) Release Notes
diskstat AC Configuration
This article describes the configuration concepts and procedures to set up the iSeries Disk Monitoring (diskstat) probe. The probe is configured by
creating profiles to monitor the disks on IBM iSeries systems. You can also configure the profiles to set the properties and conditions to generate
alarms and the QoS messages.
Contents
Set Up General Properties
Create a Profile
Configure Profile Properties
Configure Disk Monitors
Alarm Thresholds
Verify that required hardware and software is available before you configure the probe. For more information, see diskstat (iSeries Disk

You can set up the logging and interval details of the probe. If you do not specify these values, the default values are used.
Follow these steps:
1. Navigate to the diskstat node.
2. Update the following information under Setup Configuration section, as required:
Default: 0-Fatal
when debugging.
Log Size(KB): specifies a maximum size of the probe log file.

Default: 100 KB
Check Interval in seconds: specifies the interval in seconds after which the probe retrieves the disk data. Disk performance
calculations (busy, requests and data transfer) are calculated based on the changes between two measurements.
Default: 60 seconds
Note: Reduce this interval to generate alarms and QoS frequently. A shorter interval can also increase the system load.
3.
3. Click Save to save the logging information.
Create a Profile
You can create a profile from the list of currently available disks on the IBM iSeries system. Each profile represents a disk. Using this profile, you
can define the monitoring criteria of the disks which generate the alarms and QoS for the probe.
Follow these steps:
1. Click the Options (icon) next to the Profiles node in the navigation pane.
The Add Profile dialog appears.
Note: The profile is automatically populated with the disk details. See Configure Profile Properties for more information on how
to configure the profile properties to configure alarms for the disks.
3. Specify a name for the profile.

4. Select the Active checkbox to start monitoring the selected disk, on profile creation.
5. Click Submit to create the profile.
A profile for the selected disk is created under the Profiles node.

You can configure the properties of the profile to generate alarms for specified conditions.
Follow these steps:
1. Click the profile name node of the profile to be configured.
2. Set or modify the following information in the Disk Properties section:
Resource Name: identifies the unique resource name of the disk.
ASP Number: indicates the number of the Auxiliary Storage Pool (ASP) assigned to the disk.
Note: The probe monitors only the disks assigned to an ASP.
Disk Model: indicates the disk model specification.

Disk Type: indicates the disk specification type.
Disk Unit Number: indicates the disk unit number within the ASP.
Note: Mirrored disks have the same unit number. (Disk Mirroring stores the same data to two separate disks at once.)
Size (MB): indicates the disk size in MB.

Usage (%): indicates the disk usage in percentage.
Busy(%): indicates the percentage of elapsed time for which the disk is up and running.
Unit Control: indicates the disk status as follows:
"": identifies the disk status with no unit control value.
"active": identifies the disk status as active.
"failed": identifies the disk status as failed.
"other unit failed": identifies that some other disk unit in the disk subsystem has failed.
"hardware performance degrade": identifies a hardware failure within the disk subsystem that affects performance, but does not
affect the function of the disk unit.
"hardware problem": identifies a hardware failure within the disk subsystem that does not affect the function or performance of
the disk unit.
"rebuilding parity protection": identifies that the parity protection of the disk unit is being rebuilt.
"not ready": identifies the disk unit as not ready.
"write protected": identifies the disk unit as write protected.
"busy": identifies the disk unit as busy.
"not operational": identifies the disk unit as not operational.
"state not recognized": identifies that the disk unit has returned a status that is not recognizable by the system.
"not accessible": identifies the disk unit as not accessible.
"read+write protected": identifies the disk unit as read/write protected.
Read Requests: indicates the number of read requests per second.
Read KB/s: indicates the data read in KB per second.
Write Requests: indicates the number of write requests per second.
Write KB/s: indicates the data written in KB per second.
To specify these values, select either an existing pattern or a new pattern in the associated When matching field. You can use regular
expressions to specify the pattern. For more information, see Using Regular Expressions.

Monitors generate alarms and the QoS messages depending on the monitoring category. You can configure the following monitors using the
diskstat probe.
Disk Busy Monitor
Disk Usage Monitor
Disk Read Requests Monitor
Disk Read KB Monitor
Disk Write Requests Monitor
Disk Write KB Monitor
Disk IO Requests Monitor
Disk Total IO KB Monitor
Disk Unit Control Monitor
No Disk Found Monitor
Follow these steps:
1. Navigate to the profile name node.
2. Select the required monitor to configure its properties. For example, to configure the monitor Disk Total IO KB Monitor set up the alarm
conditions and QoS messages for this monitor.
Total IO KB(>=): specifies the maximum threshold value for total disk IO KB.
Message: specifies the alarm message when the sum of disk data read and disk data write reaches the specified limit.
Default: IOKb

requires meta characters. The probe supports Perl Compatible Regular Expressions (PCRE). You can use the wild card operator * in the probe to
filter the disks that are included in a profile. The probe matches the patterns to select the applicable disks for monitoring. The following fields in
the profile name node support regular expressions.
When matching (ASP Number)
When matching (Disk Type)
When matching (Disk Model)

When matching (Resource Name)
When matching (Disk Unit Number)
The probe monitors the disks that fulfill the criteria for all these fields.
Alarm Thresholds
allow the probe to:
diskstat IM Configuration
alarms and QoS.
Contents
Create a Profile
Configure Disk Properties
Configure Alarms
Configure QoS
Follow these steps:
1. Click the Setup tab.
2. Update the following information, as required:
Default: 0-Fatal
when debugging.

Default: 100 KB
Default: 60 seconds
3. Click OK to save the logging information.
Create a Profile
You can create a monitoring profile to define the monitoring criteria of the disks which generate the alarms and QoS for the probe.
Follow these steps:
1. Click the Profiles tab.
2. Right click in the tab and select New.
The Profile window appears.

5. Select the desired disk recognition parameters from the following: ASP Number, Disk Type, Disk Model, Resource Name, Disk Unit
Number.
To specify these values, select either an existing pattern or * in the associated When matching field. You can Use Regular Expressions t
o specify the pattern.
A profile for the selected disk is created under the Profiles tab.

You can configure the following properties of a profile:
Configure Alarms
Configure QoS

You can monitor the disks by adding disk properties such as Disk unit number, Disk type, and Disk model. To specify these values, select either
an existing pattern or create a new pattern in the associated When matching field. You can Use Regular Expressions to specify the pattern.
Follow these steps:
2. Double click a profile to open the Profile dialog.
3. Set or modify the following information under the Disk Properties tab:
a.


"hardware performance degrade": identifies a hardware failure within the disk subsystem that affects performance, but does
not affect the function of the disk unit.
the disk unit.
Configure Alarms
Follow these steps:

3. Click the Alarm tab and specify the alarms that are generated when a threshold is breached. For example, you can select the No disk
found option and specify the alarm message that is used when a disk matching the specified criteria is not found.
Configure QoS
You can select the disk properties for which Quality of Service messages can be sent by the probe.
Follow these steps:
3. Click the Quality of Service tab and select the desired disk properties on which the Quality of Service messages can be sent by the
probe. For example, if you select the Total IO requests in requests per second option, the probe reports the sum of read requests and
write requests as a Quality of Service message.

target string.
The diskstat probe uses regular expressions to search a substring for the selected disk parameter. For example, to search for a disk named DD,
enter /DD/ as the value for When matching field.
You can use regular expressions in the probe to filter the disks that are included in a profile. The probe matches the patterns to select the
applicable disks for monitoring. The following fields in the profile name node support regular expressions:
The following table describes some examples of regex and pattern matching for files using the diskstat probe.
Regular Expression
Explanation
* or ?
Standard
Matches all values
*a
Custom
Matches all values that end with the letter a
a?
Standard
Matches all two letter values that start with the letter a
*t*
Custom
Matches all values with the letter t in between
diskstat Metrics
This article describes the metrics that can be configured for the iSeries Disk Monitoring (diskstat) probe.
diskstat QoS Metrics

The following table describes the metrics that can be configured using the diskstat probe.
Monitor Name
Units
Description
Version
QOS_AS400_DISK_USAGE
Percent
Aggregated AS400 disk usage in percentage
1.0
QOS_AS400_DISK_BUSY
Percent
AS400 disk busy
1.0
QOS_AS400_DISK_UNIT_CONTROL
State
AS400 disk unit control state
1.0
QOS_AS400_DISK_READ_REQUESTS
Request/sec
AS400 disk read requests per second
1.0
QOS_AS400_DISK_READ_KB
KB/sec
AS400 disk read KB per second
1.0
QOS_AS400_DISK_WRITE_REQUESTS
Request/sec
AS400 disk write requests per second
1.0
QOS_AS400_DISK_WRITE_KB
KB/sec
AS400 disk write KB per second
1.0
QOS_AS400_DISK_TOTAL_REQUESTS
Request/sec
AS400 disk IO requests per second
1.0
QOS_AS400_DISK_TOTAL_KB
KB/sec
AS400 Disk IO KB per second
1.0
diskstat Alert Metrics Default Settings

This section contains the alert metric default settings for the iSeries Disk Monitoring probe.
QoS Metric
Warning Threshold
Warning Severity
Error Threshold
Error Severity
Description
Busy
None
None
None
Minor
Busy
Disk
None
None
None
Clear
Matching disk found
IOKb
None
None
None
Minor
Total IO requests in KB
IORequests
None
None
None
Minor
Incoming IO requests
NoDisk
None
None
None
Major
No disk found
ReadKb
None
None
None
Minor
Data to be read from the disk
ReadRequests
None
None
None
Minor
Read requests for the disk
Unit Control
None
None
None
Major
Unit control not matching
Usage
None
None
None
Minor
Usage greater than a specific amount
WriteKb
None
None
None
Minor
Data to be written on the disk
WriteRequests
None
None
None
Minor
Write requests for the disk
diskstat Version 1.0

This section contains documentation for versions 1.06 and earlier of the diskstat probe:
v1.0 diskstat AC Configuration

v1.0 diskstat IM Configuration
v1.0 diskstat AC Configuration

alarms and the QoS messages.
Contents
Create a Profile
Alarm Thresholds

Follow these steps:
1. Navigate to the diskstat node.
2. Update the following information under Setup Configuration section, as required:
Default: 0-Fatal
when debugging.

Default: 100 KB
Default: 60 seconds
3. Click Save to save the logging information.
Create a Profile
You can create a profile from the list of currently available disks on the IBM iSeries system. Each profile represents a disk. Using this profile, you
can define the monitoring criteria of the disks which generate the alarms and QoS for the probe.
Follow these steps:

A profile for the selected disk is created under the Profiles node.

Follow these steps:
1. Click the profile name node of the profile to be configured.
2. Set or modify the following information in the Disk Properties section:



the disk unit.
To specify these values, select either an existing pattern or a new pattern in the associated When matching field. You can use regular
expressions to specify the pattern. For more information, see Using Regular Expressions.

Monitors generate alarms and the QoS messages depending on the monitoring category. You can configure the following monitors using the
diskstat probe.
Disk Busy Monitor
Disk Usage Monitor
Disk Read Requests Monitor
Disk Read KB Monitor
Disk Write Requests Monitor
Disk Write KB Monitor
Disk IO Requests Monitor
Disk Total IO KB Monitor
Disk Unit Control Monitor
No Disk Found Monitor
Follow these steps:
1. Navigate to the profile name node.
2. Select the required monitor to configure its properties. For example, to configure the monitor Disk Total IO KB Monitor set up the alarm
conditions and QoS messages for this monitor.
Message: specifies the alarm message when the sum of disk data read and disk data write reaches the specified limit.
Default: IOKb
requires meta characters. The probe supports Perl Compatible Regular Expressions (PCRE). You can use the wild card operator * in the probe to
filter the disks that are included in a profile. The probe matches the patterns to select the applicable disks for monitoring. The following fields in
the profile name node support regular expressions.
Alarm Thresholds
allow the probe to:
v1.0 diskstat AC GUI Reference

This article describes the configuration GUI for the iSeries Disk Monitoring (diskstat) probe.
Contents
diskstat Node
Disks Node
Profiles Node
<Profile Name> Node
diskstat Node
The diskstat node lets you view the probe and alarm message details, and configure the log properties.
Navigation: diskstat
diskstat > Probe Information
diskstat > Setup Configuration
This section lets you configure the log properties and the log file size of the diskstat probe.
Default: 0 - Fatal
Default: 100 KB
Check Interval in seconds: specifies the time interval after which the probe fetches the disk data. Reduce this interval to generate
alarms faster, as the next interval takes lesser time but it can increase the system load. You can also increase this interval to generate
alarms later and reduce the system load.
Default: 60 seconds
diskstat > Alarm Messages

This section lets you view the alarm messages defined on the diskstat probe.
Name: indicates the alarm message name.
Text: indicates the alarm message text.
Level: indicates the alarm severity.
Subsystem: indicates the Subsystem_id.
Default: identifies the default message for each alarm situation (such as busy, disk, io_kb, and io_requests).
Disks Node
The Disks node contains a list of all disks which are available on the IBM iSeries system. The parameters that are used to recognize a specific
disk are as follows:
ASP Number: indicates the number of the Auxiliary Storage Pool (ASP) to which the disk is assigned.


"hardware problem": identifies a hardware failure within the disk subsystem that does not affect the function or performance of the
disk unit.
Read Requests: indicates the read requests as requests per second.
Write Requests: indicates the write requests as requests per second.
diskstat > Disks > Actions > Create Profile
Enables you to create a monitoring profile with information from the currently selected disk. The profile is available under the Profiles node.
Profiles Node
This node is used to create a monitoring profile. You can create multiple monitoring profiles with different criteria to monitor the disks. All
monitoring profiles are displayed under the Profiles node.
<Profile Name> Node
The profile name node lets you define the monitoring criteria of the disks which generate the alarms and QoS for the probe.
Note: The fields in this node are automatically populated if you create the profile using the Disks node.
Navigation: diskstat > Profiles > Profile Name

Profile Name > Edit Profile
This section enables you to edit the disk monitoring profile.
Active: enables you to configure the profile as active.
Profile Name: indicates the profile name.
Profile Name > Disk Properties
This section lets you monitor disks by adding one or more disk matching parameters such as ASP Number, Disk Type, Disk Model, and Resource
Name. The probe evaluates the matching criteria and selects all disks matching the specified criteria.
Note: Several options are selected when a profile is created from the Actions drop-down list. If you create a profile using the Add
Profile option, only the ASP Number field is selected.
Profile Name > Disk Busy Monitor

This section lets you configure the Disk Busy Monitor for generating QoS and alarms.
Busy(>=): specifies the maximum threshold value for disk busy.
Message: specifies the alarm message when the disk busy reach the specified limit.
Default: Busy
Profile Name > Disk Usage Monitor
This section lets you configure the Disk Usage Monitor for generating QoS and alarms.
Usage(>=): specifies the maximum threshold value for disk usage.
Default: 90
Message: specifies the alarm message when the disk usage reach the specified limit.
Default: Usage
Profile Name > Disk Read Requests Monitor
This section lets you configure the Disk Read Requests Monitor for generating QoS and alarms.
Read Requests(>=): specifies the maximum threshold value for disk read requests.
Message: specifies the alarm message when the disk read requests reach the specified limit.
Profile Name > Disk Read KB Monitor
This section lets you configure the Disk Read KB Monitor for generating QoS and alarms.
Read KB(>=): specifies the maximum threshold value for disk read KB.
Message: specifies the alarm message when the disk read KB reach the specified limit.
Default: ReadKb
Profile Name > Disk Write Requests Monitor
This section lets you configure the Disk Write Requests Monitor for generating QoS and alarms.
Write Requests(>=): specifies the maximum threshold value for disk write requests.
Message: specifies the alarm message when the disk write requests reach the specified limit.
Profile Name > Disk Write KB Monitor
This section lets you configure the Disk Write KB Monitor for generating QoS and alarms.
Write KB(>=): specifies the maximum threshold value for disk write KB.
Message: specifies the alarm message when the disk write KB reach the specified limit.
Default: WriteKb
Profile Name > Disk IO Requests Monitor
This section lets you configure the Disk IO Requests Monitor for generating QoS and alarms.
Total IO Requests(>=): specifies the maximum threshold value for total disk IO requests.
Message: specifies the alarm message when the disk IO requests reach the specified limit.
Profile Name > Disk Total IO KB Monitor
This section lets you configure the Disk Total IO KB Monitor for generating QoS and alarms.
Message: specifies the alarm message when the sum of disk data read and disk data write reach the specified limit.
Default: IOKb
Profile Name > Disk Unit Control Monitor
This section lets you configure the Disk Unit Control Monitor for generating QoS and alarms.
Unit Control Not Matching: specifies that an alarm is generated when the disk unit control (disk status) is not as specified.
Message: specifies the alarm message when the disk unit control does not match the specified status.
Default: UnitControl
Profile Name > No Disk Found
This section lets you configure the No Disk Monitor for generating QoS and alarms.
No Disk Found: specifies that an alarm is generated when no disk is found which matches the criteria specified in the Disk Properties se
ction.
v1.0 diskstat IM Configuration

alarms and QoS.
Contents
Create a Profile
Configure Alarms
Configure QoS

Follow these steps:
2. Update the following information, as required:
Default: 0-Fatal
when debugging.

Default: 100 KB
Default: 60 seconds
3. Click OK to save the logging information.
Create a Profile
You can create a monitoring profile to define the monitoring criteria of the disks which generate the alarms and QoS for the probe.
Follow these steps:

2. Right click in the tab and select New.
The Profile window appears.

5. Select the desired disk recognition parameters from the following: ASP Number, Disk Type, Disk Model, Resource Name, Disk Unit
Number.
To specify these values, select either an existing pattern or * in the associated When matching field. You can Use Regular Expressions t
o specify the pattern.
A profile for the selected disk is created under the Profiles tab.

Configure Alarms
Configure QoS
You can monitor the disks by adding disk properties such as Disk unit number, Disk type, and Disk model. To specify these values, select either
an existing pattern or create a new pattern in the associated When matching field. You can Use Regular Expressions to specify the pattern.
Follow these steps:
3. Set or modify the following information under the Disk Properties tab:
a.



"hardware performance degrade": identifies a hardware failure within the disk subsystem that affects performance, but does
not affect the function of the disk unit.
the disk unit.
Configure Alarms
Follow these steps:
3. Click the Alarm tab and specify the alarms that are generated when a threshold is breached. For example, you can select the No disk
found option and specify the alarm message that is used when a disk matching the specified criteria is not found.
Configure QoS
You can select the disk properties for which Quality of Service messages can be sent by the probe.
Follow these steps:
3. Click the Quality of Service tab and select the desired disk properties on which the Quality of Service messages can be sent by the
probe. For example, if you select the Total IO requests in requests per second option, the probe reports the sum of read requests and
write requests as a Quality of Service message.

target string.
The diskstat probe uses regular expressions to search a substring for the selected disk parameter. For example, to search for a disk named DD,
enter /DD/ as the value for When matching field.
You can use regular expressions in the probe to filter the disks that are included in a profile. The probe matches the patterns to select the
applicable disks for monitoring. The following fields in the profile name node support regular expressions:
The following table describes some examples of regex and pattern matching for files using the diskstat probe.
Regular Expression
Explanation
* or ?
Standard
Matches all values
*a
Custom
Matches all values that end with the letter a
a?
Standard
Matches all two letter values that start with the letter a
*t*
Custom
Matches all values with the letter t in between
v1.0 diskstat IM GUI Reference

This article describes the configuration GUI for the iSeries Disk Monitoring probe. The probe GUI consists of a window with three tabs.
Setup Tab
Profiles Tab
Profile Window
Disk Properties Tab
Alarm Tab
Quality of Service Tab
Disks Tab
Setup Tab
The Setup tab allows you to view the probe and alarm message details and configure the log properties.
Check interval
This section provides information about the check interval of the probe.
Perform check each ... seconds: specifies the time interval at which the disk data in the system is fetched and checked. Reduce
this interval to generate alarms faster, as the next interval takes lesser time but it can increase the system load. You can also
Default: 0-Fatal
Log Size: specifies a maximum size of the probe log file.

Default: 100 KB
Alarm messages
This section lets you view the alarm messages defined on the diskstat probe
Name: indicates the name of the alarm
Subsystem: indicates the subsystem_id.
Default: indicates the default message for each alarm situation (such as found_message, instances_message, and
not_found_message).
You can create, edit or delete alarm messages by right clicking this section and selecting the required option. You can use a $
symbol is in the alarm text to select a variable from the list of variables. The value of these variables are retrieved from the monitored
system.
Profiles Tab
This tab allows you to view, create, modify, or delete monitoring profiles. You can create multiple profiles with different criteria to monitor the
disks. You can also activate or deactivate profiles in this tab. You can right click in this tab to use the following options:
New: creates a new profile using the Profile window.
Edit: modifies an existing profile using the Profile window.
Delete: deletes the selected profile.
Profile Window
The Profile window allows you to configure a monitoring profile of the probe. This window lets you define the monitoring criteria of the disks which
generate the alarms and QoS for the probe. The fields in this window are automatically populated if you create the profile using a disk from the Di
sks tab.
Disk Properties Tab
This tab lets you monitor the disks by adding disk matching parameters such as Disk unit number, Disk type, and Disk model. The probe
evaluates the matching criteria and selects all disks matching the criteria specified in disk properties.
Note: All the disk parameters support regular expressions. For more information, see Using Regular Expressions.
ASP number: indicates the number of auxiliary storage pools(ASP) to which the disk is assigned. The probe monitors only those disks
that are assigned to an ASP.
Disk type: indicates the type of disk specification.
Disk model: indicates the disk model specification.
Resource Name: indicates the unique resource name of the disk.
Disk unit number: indicates the disk unit number within the ASP.
Note: Mirrored disks have the same unit number.
Alarm Tab
This tab enables you to send alarm message when an alarm condition arises.
No disk found
Specifies that an alarm message should be generated if no disk is found which matches the criteria specified in the Disk properties tab.
The Message field determines the alarm message to be used for this alarm situation.
Usage >=: specifies that an alarm message is generated if the disk usage reaches the specified limit.
Busy >=: specifies that an alarm message is generated if the disk busy reaches the specified limit. Disk busy is the percentage of
elapsed time for which the disk is up and running.
Unit control not matching: specifies that an alarm message is generated if the disk unit control (disk status) is not as specified.
The following are possible values:
"": There is no unit control value.
"active" (1): The disk unit is active.
"failed" (2): The disk unit has failed.
"other unit failed" (3): Some other disk unit in the disk subsystem has failed.
"hardware performance degrade" (4): There is a hardware failure within the disk subsystem that affects performance, but does not
"hardware problem" (5): There is a hardware failure within the disk subsystem that does not affect the function or performance of the
disk unit.
"rebuilding parity protection" (6): The disk unit's parity protection is being rebuilt.
"not ready" (7): The disk unit is not ready.
"write protected" (8): The disk unit is write protected.
"busy" (9): The disk unit is busy.
"not operational" (10): The disk unit is not operational.
"state not recognized" (11): The disk unit has returned a status that is not recognizable by the system.
"not accessible" (12): The disk unit cannot be accessed.
"read+write protected" (13): The disk unit is read/write protected.
Read requests>=: specifies that an alarm message is generated if disk read requests value reaches the specified limit.
Read KB>=: specifies that an alarm message is generated if the disk data read reaches the specified limit.
Write requests>=: specifies that an alarm message is generated if disk write requests reaches the specified limit.
Write KB>=: specifies that an alarm message is generated if disk data written reaches the specified limit.
Total IO requests>=: specifies that an alarm message is generated if the sum of disk read requests and disk write requests reaches the
specified limit.
Total IO KB>=: specifies that an alarm message is generated if the sum of disk data read and disk data writtten reaches the specified
limit.
Quality of Service Tab
This tab enables you to select the disk properties for which Quality of Service messages can be sent.
Disk usage in %: This checkbox indicates the probe that the disk usage is sent as a QoS message.
Disk busy in %:This checkbox indicates the probe that the disk busy is sent as a QoS message.
Unit control: This checkbox indicates the probe that the Unit control (disk state) is sent as a QoS message.
Read requests in requests per second: This checkbox indicates the probe that the disk read requests are sent as QoS message.
Data read in KB per second: This checkbox indicates the probe that the disk data read is sent as QoS message.
Write requests in requests per second: This checkbox indicates the probe that the disk write requests are sent as QoS message.
Data written in KB per second: This checkbox indicates the probe that the disk data written is sent as QoS message.
Total IO requests in requests per second: Reports the sum of read requests and write requests as a Quality of Service message.
Total data IO in KB per second: Report the sum of data read and data written as a Quality of Service message.
Disks Tab
The Disks tab contains a list of all disks assigned to an ASP currently in the system.
You can right click a disk in this tab to use the following options:
Refresh: retrieves a fresh list of disks from the monitored system.
Create Profile: enables you to create a monitoring profile for the selected disk. The profile is available in the Profiles tab.
distsrv (Monitor Distribution Server)

The Monitor Distribution Server (distsrv) is an important part of the UIM Monitor infrastructure that maintains distributable packages, licenses, and
alarm console maps. The distsrv probe is dedicated to transferring probe packages to, or from, UIM robots.
The distsrv probe administers and distributes probe packages from the central UIM probe archive.
You may initiate a distribution request by dragging a package from either the local or web Archive in Admin Console or Infrastructure Manager
and dropping it onto a specific robot node, or to many robots by dropping the package onto a hub node.
v5.3 distsrv AC GUI Reference

Contents
Advanced
Alarm Messages
Forwarding
Navigation: distsrv
Set or modify the following values that are based on your requirement. When finished, click Save to keep your changes, or Discard.
Probe Information
This section provides read-only information about the probe name, start time of the probe, probe version, and the vendor who created the
probe.
This section allows you to configure the log properties and timeout settings for the Package Distribution Server probe.
Log level: Specifies the level of details in the log file.
Default: 0 - Fatal
Note: Recommendation is to select a lower log level during the normal operation and minimize the disk consumption. You
can increase the log level while debugging.
Log Size (KB): The default size of the log file is 100 KB. This field allows you to change the size of the log file according your needs.
Archive Folder: Specifies the directory where the archive packages are stored. Directories are relative to the Nimsoft installation
directory. The default directory is archive.
Note: You can change this parameter if you are running out of space and want the packages to be stored on a different
disk. The packages in the archive are not automatically moved, you must move them manually to the new location.
Retry Attempts: Defines the number of times the server should attempt distribution.
Retry Timeout (seconds): Defines the time-out in seconds for distribution retries.
Advanced
This section allows you to fine-tune the use of the distsrv probe.
Navigation: distsrv > Advanced
Advanced
Log Finished Distribution: Check this box to log finished installations to files in subdirectories located in probes\service\distsrv\jobs.
This provides a history of your installations. Default is on.
Alarm on Finished Distribution: Check this box to send an alarm message when an installation is finished. Default is off. The alarm
message that is sent is hard-coded and will send one of the following messages:
information - if the forwarding operation completed successfully

minor - if update is specified and the package was not present on the target robot
major - if the distribution fails.
Days to Keep History: Specifies how long to keep information about finished installations. The default is 7 days.
CRC Error Retry Count: When individual files are transferred during distribution, their consistency (CRC) is checked. If this fails, the
file is transferred again. After the number of retries is exceeded, the installation fails. The package can be distributed again according
to what is specified in Retry under distsrv .
Block Size (Bytes, max: 32768): The largest amount of data to be transferred per transaction. The default upper limit set at 32768
bytes. Lowering this value will slow down the overall transfer but each block transfer is faster, which may allow you to avoid timeouts
due to slow network connections.
Use Remote distsrv Distribution: Check this box to enable the distsrv probe to transfer a package to a distsrv probe on another hub.
This is efficient when distributing a package to several robots residing under a hub on a different net/subnet, as the package will be
distributed to the remote hub only once.
Accept Remote Distribution: Check this box to allow other distsrv instances to use this distsrv probe for remote distribution.
Use Local Archive for Remote Distributions: When a distribution request is received from another distsrv, the package is
distributed from the local archive. If this option is not selected, the package will be requested from the originating distsrv.
Note: This option should be used in conjunction with the package-forwarding mechanism.
Alarm Messages
This section lists the default alarm messages issued when a distribution completes, and allows you to configure alarm attributes.
Navigation: distsrv > Alarm Messages
Click on the message you want to modify to select it, then update its properties in the fields located below. Click New to add a new message.
Click Delete to remove an existing message.
When finished, click Save to keep your changes, or Discard any changes.
Message Definitions
Message Name: The name of the alarm message
Message Text: The complete alarm message to be sent. This field allows the following variables:
$job_description - Set on distribution creation "Created by: ..." when created from Infrastructure Manager.
$job_id - set on distribution, creating normally "system" or "system-n" when the job is created from Infrastructure Manager.
$package_name
$package_version
$result - result string from the distribution.
$robot - target robot.
$status - return code from the installation, corresponds to the"Result code" under the "Installations" tab.
Alarm Level: The alarm severity level
Subsystem: The originating subsystem ID
Default Messages for Alarms:
Error indicates that the distribution failed
OK indicates that the distribution was successful
NoUpdate will be issued when you specify 'update' when creating the job, and the package has not been distributed to the Robot before.
The distribution will be aborted.
Forwarding
This screen allows you to configure when to forward updates and allow forwarding of licensing information either with the package or when a
change is detected.
Navigation: distsrv > Forwarding

Forwarding Configuration
Forwarding Active: Select this option if you want to turn on forwarding of license information to other distribution servers within the
same domain.
Forward interval (seconds): Define the interval when licenses can be forwarded and package versions are compared to determine if
packages are due for forwarding.
Forwarding License With Package: Select this option if you want the licenses always to be forwarded with the corresponding
packages.
Immediately Forward on Change: Select this option when you want to forward the license immediately when a package is added or
changed in the archive.
Note: Using this option does not change the forwarding on interval setting. This setting handles changes in the remote
archive(s).
Forwarding Profiles
Define profiles for distributing select groups of packages to destination hubs. Click New to add a profile. Click Delete to remove an
existing profile. When configuring a profile, you can configure these attributes:
Hub Destination: Select the destination hub from the drop-down list.
Profile Active: Select this box to make the profile active.
Profile Type: Choose the type of profile from the drop-down list:
Specific: Forward only those packages checked in the packages list
Update: Forward only those packages already present on the remote distribution server
All: Forward all packages
Licenses: Functions in much the same way as the other forwarding types. This forwarding type may only be needed when a
dashboard login is used, and where the licenses that are used that are not connected to a specific package. Package specific
licenses can more efficiently be forwarded together with the package.
All Versions: Allows you to forward all versions of the package(s) specified. (Otherwise only the most recent version will be
forwarded). Note that the removal of a version of a package will not be reflected on the destination distribution server.
v5.3 distsrv IM GUI Reference

Contents
The Setup Tab

Archive directory
Retry
Forwarding
Advanced settings
Messages
The Status Tab
Adding or Editing a Package
The Installations Tab
The Forwarding Tab
The distsrv probe is configured by double-clicking the icon representing the probe in Infrastructure Manager. The probe configuration GUI
appears.
The configuration user-interface shows the following tabs:
Setup
Status
Installations
Forwarding
The Setup Tab
The Setup Tab displays log file settings and sub-tabs:

Log level
Log level defines the level of details logged to the log file. Log as little as possible during normal operation to minimize disk consumption,
Log Size
The default size of the log file is 100 KB. This field allows you to change the size of the log file according your needs.
Archive directory
Retry
Forwarding
Advanced settings
Messages
Archive directory
This tab allows you to define the directory where the archive packages are stored. Directories are relative to the UIM installation directory. The
default directory is archive.
Note: You can change this parameter if you are running out of space and want the packages to be stored on a different disk. The
packages in the archive are not automatically moved, you must move them manually to the new location.
Retry
This tab allows you to set parameters to define what the distribution server should do when a distribution is not successfully completed.
Attempts: Defines the number of times the server should attempt distribution.
Delay: The minimum time (in minutes) between distribution attempts.
Forwarding
This tab allows you to configure when to forward updates and allow forwarding of licensing information either with the package or when a change
is detected.
Forwarding active: Select this option if you want to turn on forwarding of license information to other distribution servers within the same
domain.
Forward interval: Define the interval when licenses can be forwarded and package versions are compared to determine if packages are
due for forwarding.
Always forward license with package: Select this option if you want the licenses always to be forwarded with the corresponding
packages.
Immediately perform forwarding when a change is detected: Select this option when you want to forward the license immediately
when a package is added or changed in the archive.
Note: Using this option does not change the forwarding on interval setting. This setting handles changes in the remote
archive(s).
Advanced settings
This tab allows you to fine tune the use of the distsrv probe.
Log finished installations: Logs finished installations to files in sub-directories of probes\service\distsrv\jobs. This provides a history of
your installations.
Alarm on finished installations: Sends an alarm message when an installation is finished. The alarm message is hard-coded and will
send one of the following messages:
information - if the forwarding operation completed successfully.
minor - if update is specified and the package was not present on the target robot.
major - if the distribution fails.
Use remote distsrv on distribution: Enables the distsrv probe to transfer a package to a distsrv probe on another hub. This is
especially useful when distributing to several robots residing under a hub on a different net/subnet, as the package will be distributed to
the remote hub only once.
Accept remote distributions: Allows other distsrv instances to use this distsrv probe for remote distribution.
Use local archive for accepted remote distributions: When a distribution request is received from another distsrv, the package is
distributed from the local archive. If this option is not selected, the package will be requested from the originating distsrv.
Note: This option should be used in conjunction with the package forwarding mechanism.
Keep history: Specifies how long to keep information about finished installations. Default is 7 days.
CRC error retry count: When individual files are transferred during distribution, their consistency is checked. If this fails, the file is
transferred again. After the number of retries have been used unsuccessfully, the installation fails. The package might be distributed
again according to what is specified in the Retry tab.
Block size: The largest amount of data to be transferred per transaction. The upper limit is currently set at 32000 bytes. Lowering this
value will slow down the overall transfer but each block transfer would be faster.
Messages
This tab lists the default alarm messages issued when a distribution completes.
Right click in the message section to add a new message, update message properties or delete a message. The alarm message properties
screen appears.
The fields are:
Name: The name of the alarm message.
Text: The complete alarm message to be sent. This field allows the following variables:
$job_description - Set on distribution creation "Created by: ..." when created from Infrastructure Manager.
$job_id - set on distribution, creating normally "system" or "system-n" when the job is created from Infrastructure Manager.
$package_name
$package_version
$result - result string from the distribution.
$robot - target robot.
$status - return code from the installation, corresponds to the"Result code" under the "Installations" tab.
Level: The alarm severity level.
Subsystem: The originating subsystem ID.
Default for alarm situation:
Error indicates that the distribution failed.
OK indicates that the distribution was successful.
NoUpdate will be issued when you specify 'update' when creating the job, and the package has not been distributed to the Robot
before. The distribution will be aborted.
Click OK to save your changes.
The Status Tab

All packages available for distribution are listed on this tab.
Note: This is the same information that appears in the Archive node in Infrastructure Manager.
The following commands are available when you right click in the package list:
New Package
Starts the package editor to let you define a new distributable package, which is placed in the archive. Note that the package editor can
also be started directly from Infrastructure Manager.
Important! Package names cannot contain a dot "." in the filename. Use an underscore "_" or dash "-" instead.
Edit Package
Starts the package editor to let you modify an existing package. Note that the package editor can also be started directly from
Infrastructure Manager.
Remove Package
Removes the selected package. Note that this function is also available directly from Infrastructure Manager.
Copy package
A new package is created based on the selected package with the same contents. Note that if the package contains a probe, the probe is
not given the new name.
Rename package
A new name is given to the selected package. Note that if the package contains a probe, the probe is not given the new name.
Configure archived configuration
This option lets you modify the configuration files (.cfx files) distributed with the probe package.
Note: The configure archived configuration option was introduced in distsrv version 4.7.x, and the first probe package enabled to take
advantage of this feature is the logmon probe.The option is also available in the version of Infrastructure Manager delivered with
Nimsoft Server 3.60 or newer, where you right-click the probe package and select Configure archived configuration.
Select the cfx file you would like to configure.The probe GUI displays. Update the options and click Apply when you are finished. The cfx
file in teh probe package is now updated and the package can be distributed to the robots with the modified cfx file.
Convert old package to new format
If you had an earlier version of Nimsoft installed (version 1.5), this option allows you to convert a package created with the old version of
Nimsoft to the current package format. The old packages must be converted to the new format if you still want to be able to distribute
them.
Adding or Editing a Package

The package properties screen displays when you add or edit a package. When you are adding a new package several fields will be blank on
your screen. When you are editing an existing package the fields will be filled in with the appropriate information.
The fields are:
Name: The probe package name.
Important! Package names cannot contain a dot "." in the filename. Use an underscore "_" or dash "-" instead.
Description: Description of the package.

Copyright: Copyright date for the package.
Group: The category of the probe within Infrastructure Manager. Current values are: Gateway, Infrastructure, Network, Service, SLM and
System.
Author: Author of the package.
Date: Date the package was created.
Version: Version of the package.
Build: Build number of the package.
No direct install: If selected this package will not be a direct install.
License required: If selected this package requires a valid license.
OStype: Operating system type for probe package.
OS: Supported operating system for the probe package.
The Installations Tab

This screen displays the installation jobs that are in the queue for distribution. This tab is useful when distributing to a large number of robots, as
the distribution server only supports a limited number of concurrent installations, and jobs will be queued.
The Forwarding Tab

Packages and licenses can be automatically forwarded to other distribution servers in the same domain. The Forwarding tab lists all Forwarding
records defined. A Forwarding record defines which package(s) to be forwarded to which distribution server.
Important! Adding a forwarding record to the distsrv probe requires you to apply the changes, wait five minutes and then restart the
NAS probe on the remote hub.
Each of the Forwarding records can be individually turned on or off.

Right-clicking in the list lets you add, edit record properties, or remove a Forwarding record.
There are 4 forwarding types:
Specific: Forward only those packages checked in the packages list.
Update: Forward only those packages already present on the remote distribution server.
All: Forward all packages.
Licenses: Functions in much the same way as the other forwarding types. This forwarding type may only be needed when dashboard
login is used, where licenses are used that are not connected to a specific package. Package specific licenses can more efficiently be
forwarded with the package - see the Setup tab.
Package version and build number are used to determine if a package is due for forwarding.
The All versions option allows you to forward all versions of the package(s) specified.
Note: The removal of a version of a package will not be reflected on the destination distribution server.
Advanced features
The maximum number of packages to be forwarded simultaneously is set to 10, but can be changed by changing the /setup/max_inst option in
the probe configuration file (distsrv.cfg). You can modify this option using Raw Configure within Infrastructure Manager.
Note: The distribution server also stores the UIM licenses. These can be maintained, using Infrastructure Manager.
dns_response (DNS Response Monitoring)

Domain Name Servers translate standard language web addresses to their actual IP addresses for network access. The response time of dns
servers is monitored to identify if the dns infrastructure is accessible or a latency exists between the request and the response. The dns_response
(DNS Response Monitoring) probe queries your Domain Name Server (DNS) and monitors the response time from the server. The probe can also
query the DNS looking for A records (normal hostnames), mail exchanger (MX) records, and name server (NS) records.
The probe sends alarms if the query fails, or if the response times are above the defined thresholds. The probe sends QoS data on profiles where
the QoS option has been enabled. The probe uses the 'host' utility, which is shipped with the probe package.
More information:
dns_response (DNS Response Monitoring) Release Notes
v1.6 dns_response AC Configuration

This article describes the configuration details specific to the dns_response probe.
The following diagram outlines the process to configure the dns_response probe to monitor a domain name server.
How to Monitor DNS Response

Creating Profile(s)
Delete Profile
Alarm Thresholds

Follow these steps:
1. Open the dns_response probe configuration interface.
2. Specify the log and interval details for the probe.
3. Create a profile with the domain or host details for the probe and the new name server for the profile.
Refer Creating Profile(s) for more information.
4. Test the profile in the Profile-<Profile Name> node to verify the connection.
5. Configure the required monitors to generate alarms.
6. Activate the profile and save the configuration to start monitoring.
Creating Profile(s)
A monitoring profile is created to define the DNS server to be monitored by the probe. The monitoring profile defines the conditions and threshold
values for generating QoS and alarms. You can also edit the monitoring parameters, which are based on changing business requirements
respective to the changes in monitoring requirements.
Follow these steps:
1. Click the Options icon next to the dns_response node in the navigation pane.
3. Update the field information in the Add New Profile dialog and click Submit.
The profile is saved and you can configure the profile properties for monitoring the DNS server.
Delete Profile
You can delete the monitoring profile that is no longer in use. You can also deactivate your monitoring profile, so that when a requirement comes
again, you are not required to configure all the parameters again.
Follow these steps:
1. Click the Options icon next to the Profile-profile name node in the navigation pane.
3. Click Save.
The selected profile is removed from the dns_response node.
Alarm Thresholds
allow the probe to:
v1.6 dns_response AC GUI Reference

This article describes the dns_response probe GUI fields.
Contents
dns_response Node
Profile-<Profile Name> Node
<Profile Name> Node
Network Server Node
dns_response Node
The dns_response node displays the probe information and lets you configure the log properties of the probe. You can set the time interval for
checking the Domain Name Server (DNS). You can also view the list of alarm messages in the message pool.
Navigation: dns_response
dns_response > Probe Information
dns_response > General Configuration

This section is used to configure the log properties of the probe. These settings define the default properties for all the profiles that are created in
the probe.
Default: 3 - Info
Port: specifies the port number for performing the reverse lookup with the forward lookup from a single profile.
Default: 1
Protocol: specifies the protocol for performing the reverse lookup with the forward lookup from a single profile.
Default: TCP
Run Interval (Seconds): defines the time interval (in seconds) when the profiles are checked.
Default: 300
dns_response > Message Pool
The Message Pool section displays a list of currently configured alarm messages for the probe. These messages can be used in one or more
monitoring profiles in the probe.
Name: identifies the name of the message.
Token: identifies the token which is used for the internationalization.
Error: identifies the alarm message text that is issued on error alarm.
OK: identifies the alarm message text that is issued on alarm clear.
Subsystem: identifies the subsystem_ID of alarms that defines the source of the alarm.
Error Token: identifies the token value of the error message.
OK Token: identifies the token value of the clear message.

The Profile-profile name node is used to view and update the profile name and domain name that the profile is monitoring.
Note: This node is named as the Profile-profile name throughout this document as the profile name is user-configurable.
Navigation: dns_response > Profile-profile name

Profile-profile name > New Profile
This section is used for managing profile name and domain name that the profile is monitoring.
<Profile Name> Node
This node represents the new profile that is created to monitor the DNS response.
Note: This node is user-configurable. Hence, this node is referred to as the profile name node throughout this document.
Network Server Node
The Network Server node is used to configure the monitoring properties of the probe. You can specify various conditions to generate the QoS
and alarms.
Navigation: dns_response > Profile-profile name > profile name > Network Server
Network Server > General Profile Configuration
This section is used to configure the profile-specific monitoring parameters.
Description: defines a brief description of the profile. This description is for information only and is not used for any processing.
Host/Domain: defines a hostname or domain to be checked.
Reverse Lookup IP: defines an IP address for performing the reverse lookup with the forward lookup from a single profile.
Name Server: allows you to define the new name server for the current profile.
Port: specifies the port number for performing the reverse lookup with the forward lookup from a single profile.
Default: 1
Protocol: specifies the protocol for performing the reverse lookup with the forward lookup from a single profile.
Default: TCP
Server Lookup Type: specifies the server lookup type that the probe supports.
Default: Normal IP Address (A)
Server Lookup Class: specifies the server lookup class that the probe supports.
Number of Retries: specifies the retry attempts for resolving the host or domain name and Reverse Lookup IP. The separate retries are
attempted for the Host/Domain and the Reverse Lookup IP.
Timeout (Seconds): specifies the time limit for each request. If you have multiple retries, the cumulative timeout is multiplied by the
number of retries.
Network Server > Messages for Alarm Timeout Situations
This section displays a list of alarms for preconfigured timeout situations.
Network Server > Alarm and QoS for Forward Lookup
This section is used to configure alarms and QoS for Forward Lookup. If the threshold value is exceeded, an alarm is issued.
Enable Forward Lookup Alarm: allows you to start receiving the Forward Lookup alarms.
Forward Lookup alarm Threshold (Milliseconds): specifies the time limit before issuing the Forward Lookup alarm.
Enable Forward Lookup Warning: allows you to start receiving the Forward Lookup warnings.
Forward Lookup warning Threshold (Milliseconds): specifies the time limit before issuing the Forward Lookup warning.
Source used for QoS and Alarm messages (Allow source override): defines the source of alarm and QoS. If this field is blank, the QoS
source is the hostname and alarm source is the IP address of the system.
Network Server > Lookup Failed
This section allows you to generate alarms when the probe failed to perform the Lookup action.
Network Server > Alarm Time
This section allows you to generate alarms when the response time is greater than the alarm threshold limit.
Network Server > Warning Time
This section allows you to generate alarms when the response time is greater than the warning threshold limit.
Network Server > Parse Error
This section allows you to generate alarms when the probe is not able to read the response time.
Network Server > DNS Fail
This section allows you to generate alarms when the DNS Server fails to response the probe.
Network Server > Alarm and QoS for Reverse Lookup
This section is used to configure alarms and QoS for Reverse Lookup. If the threshold value is exceeded, an alarm is issued.
Enable Reverse Lookup Alarm: allows you to start receiving the Reverse Lookup alarms.
Reverse Lookup alarm Threshold (Milliseconds): specifies the time limit before issuing the Reverse Lookup alarm.
Enable Reverse Lookup Warning: allows you to start receiving the Reverse Lookup warnings.
Reverse Lookup warning Threshold (Milliseconds): specifies the time limit before issuing the Reverse Lookup warning.
Source used for QoS and Alarm messages (Allow source override): defines the source of alarm and QoS. If the field is blank, the QoS
source is the hostname and alarm source is the IP address of the system.
v1.6 dns_response IM Configuration

This article describes the configuration details specific to the dns_response probe.
The following diagram outlines the process to configure the dns_response probe to monitor a domain name server.

Set General Properties
Configure Profile(s)

Follow these steps:
1. Open the dns_response probe configuration interface.
2. Specify the log and interval details for the probe.
3. Specify a default name server for the probe.
Refer Set General Properties for more information.
Note: You can also specify a profile-specific name server while creating or configuring profile(s).
4. Create a profile with the domain or host details for the probe.
Refer Configure Profile(s) for more information.
5. Test the profile to verify the connection.

6. Configure the required alarms, QoS, and messages.
7.
Set General Properties

You can set the general properties of the probe, such as log settings and name of the default name server using this functionality.
Follow these steps:
1. Click the General Setup button.
2. Use the Setup dialog to configure the general elements of the probe, such as log settings and name of the default name server as
described below.
Log level
Indicates how much information should be written to the log file. The higher the log level, the more information is printed. On log level 0
(default) only critical errors are printed.
Logfile Size
Defines the maximum size of the probe log file in KBs. The probe takes the log file back-up, truncates the log file text, and continues
logging when the log file size reaches the maximum limit.
Default nameserver
Defines the name server that will be used by the profiles if no specific name server is chosen. You can test the connection to the name
server by pressing the Test button next to the input field.
Note: A value must be assigned to this field.
Port and Protocol

Defines the port number (default 53) and select protocol for performing reverse lookup along with forward lookup from a single profile.
Note: UDP will work on port 53 and TCP will work on any port.
Test (button)
This button is only available if the probe is running. This button executes a test of the name server listed through the probe. Use the Test
button to check a specified nameserver and not the system default nameserver.
Note the different icons:
The icon next to the Test button is initially a question mark.
If the test is successful, the icon changes to an OK sign.
If the icon turns red (error), you should check your nameserver entry.
Run interval (sec)
Specifies how often the profiles should be checked. The interval is counted in seconds
Configure Profile(s)
You can create a new profile and configure its properties to define the specific checks that the dns_response probe should run.
Follow these steps:
1. Click the Create A New Profile button to open the Profile dialog. You may also right-click in the left pane and select New Profile.
A "Profile" is a specific check that the probe should run.
Note: You can also right click an existing profile and select Copy to create a new copy of the old profile.
2. Each profile has the following configurable fields:

Profile
Defines the name of the profile must be unique.
Description
Provides a brief description of the profile. This is for information only; the probe does not use the information for any processing.
Host/Domain
Specifies what is to be checked. Normally it will be a hostname that you wish to look up, but it can also be a domain, if you are checking
that a name server or mail server is defined for that domain.
Reverse Lookup IP
Specifies IP address here. This supports performing reverse lookup along with forward lookup from a single profile.
Test button
Lets you test your profile to see if the dns_response probe can resolve the information.
The icon next to the Test button is initially a question mark.
If the test is successful, it will turn green.
Otherwise, it will turn red, and you should check your profile configuration.
v1.6 dns_response IM GUI Reference

The article describes the probe GUI fields.
Contents
General Tab
Advanced Tab
Messages Tab
General Tab
This tab contains the general information for the profile. It allows you to set up alarms and to override the default name server if you wish to use
another name server for this lookup.

Use default name server
The default name server, specified in the Setup Tab, will be used for this lookup.
Note: All the details, such as default name server, port, and protocol are fetched from Setup tab.
Use name server
Overrides the default name server and use the one specified instead.
Port
Defines the port number (default 1) to use for name server.
Protocol
Defines the protocol (default TCP) to be used for name server.
Alarms
There are two alarm thresholds available each for forward lookup and reverse lookup. You can select to control QoS Alarms for Forward
Lookup or Reverse Lookup or both. Refer the Messages tab for alarm messages. The thresholds are specified in milliseconds (ms). To
activate a threshold, you must select the check box and set a value for that threshold.
Alarm threshold
When this threshold is breached, the DNS lookup time alarm message is issued. The default threshold is 20 ms.
Warning threshold
When this threshold is breached, the DNS lookup time warning message is issued. The default threshold is 10 ms.
Note: The sending and forwarding of QoS alarms are controlled separately for the Host and Reverse Lookup IP.
Advanced Tab
In the Advanced tab, you can set the type of lookup to perform, the number of retries, and the timeout for the command, and turn on Quality of
Service messages.

Server Lookup Type
The dns_response probe supports four kinds of lookups:
A: Normal IP address lookup

MX: Mail server lookup (usually used when looking at a domain)
NS: Name server lookup (usually used when looking at a domain)
TXT: Text string (usually used in case of Chaos DNS lookup). When the Server lookup class is selected as Chaos (CH) and the Ser
ver lookup type as TXT, the user must specify the file name in the Host/Domain text box, for example version.bnd.
Server Lookup Class
The probe supports the following server lookup classes:
Internet (IN)
Chaos (CH)
Send Quality of Service
Allows you to send Quality of Service messages if this check box is selected.
Note: The QoS will be sent separately for the Host and the Reverse Lookup IP.
Allow source override
Overrides the source of Alarm and QoS by the text specified here. If you do not enter a value in this field, the QoS source will be
hostname of system where probe is deployed and alarm source will be IP address of the system where probe is deployed. You can use
the following variables in this field:
$host: If $host is specified in Allow source override field, then the $host is replaced by host of DNS server in source field of Alarms
and QoS.
$profile: If $profile is specified in Allow source override field, then $profile is replaced by profile of DNS server in source field of
Alarms and QoS.
Note: You can also override any text in Allow source override field with or without variables in both QoS and alarm variables.
Number of Retries
Specifies the number of retries (default 1) that will be made when attempting to resolve the host or domain name and Reverse Lookup IP,
specified in the profile.
Note: The separate retries are attempted for the Host and the Reverse Lookup IP.
Timeout (sec)
Specifies the timeout (in seconds) for the request, default is 1. The timeout is on a request basis, so if you have multiple retries. The
cumulative timeout is the timeout multiplied by the number of retries.
Note: Separate timeouts are applicable for the Host and the Reverse Lookup IP.
Messages Tab
The Messages tab lets you select an alarm message for the different alarm situations.
DNS lookup failure
DNS lookup time above alarm threshold
DNS lookup time above warning threshold
DNS does not respond to request.
Unable to read response time

Click the Message Pool Manager button in the tool bar to open the Message Pool dialog.
text as well as create your own messages. You can select one of these messages on the Messages tab in the drop-down menus in the Profile di
alog.
Note: When upgrading from probe versions prior to 1.23, the alarm messages must be manually cleared before upgrading. The probe
may not function properly if the messages are not cleared before upgrade.

Identification Name
Specifies the message a unique name. This identification name is what you will see when selecting the message in the drop-down menus
in the profile dialog.
Error Alarm Text / Clear Alarm Text
Defines the text of the alarm messages issued on error and clear. The variable expansion in the message text is supported. If typing a $
in the Alarm text field, a dialog pops up, offering a set of variables to be chosen. The set of variables available depends on what is
selected as "token".
Error Severity
Specifies the severity of the alarm (clear, information, warning, minor, major, or critical).
Message token
Refers to the checkpoint. It is preset by the probe and is therefore not modifiable.
Message subsystem
Specifies the ID of the subsystem being the source of this alarm. This ID is managed by the nas.
dns_response Troubleshooting
This section contains some troubleshooting points for the dns_response probe.
Unable to Lookup DNS on a Server with Type A

Symptom
The DNS query fails when the Server lookup type is set as Normal IP address (A).
Solution
Ensure that the passDnsTypeAasAny key is set to yes for a successful DNS query using the Server lookup type as A. If the key value is set to
no, the probe sends all the DNS query as Any.
Follow these steps:
1. Open the Raw Configure window of the probe.
2. Select the setup section.
3. Modify the value of the passDnsTypeAasAny key to yes.
dns_response Metrics
The section describes the metrics that can be configured for the DNS Response Monitoring (dns_response) probe.
Contents
QoS Metrics
QoS Metrics
The following table describes the checkpoint metrics that can be configured using the dns_response probe.
Monitor Name
Units
Description
Version
QOS_DNS_RESPONSE
Milliseconds
DNS Response
1.6
QOS_DNS_RESPONSE_REVERSE
Milliseconds
DNS Response
1.6

This section contains the alert metric default settings for the dns_response probe.
Metric
Error Threshold
Error Severity
Description
LookupFailure
None
Major
Alarms to be issued when DNS lookup of target failed on nameserver for profile.
TimeAlarm
None
Major
Alarms to be issued when DNS lookup time of the target server is breaching the alarm threshold.
TimeWarn
None
Warning
Alarms to be issued when DNS lookup time of the target server is breaching the warning threshold.
DNSFailure
None
Major
Alarms to be issued when DNS server for profile does not respond to requests.
ParseError
None
Major
Alarms to be issued when unable to read response time from nameserver for profile.
e2e_appmon (E2E Application Response Monitoring)

The E2E Application Response Monitoring (e2e_appmon) is a remote probe that runs the precompiled NimRecorder scripts for monitoring the
response time and other performance parameters. The probe also monitors the availability of the client applications. Each transaction runs for a
certain time limit and generates the QoS messages from the script. The probe also measures the total run time of each transaction.
More information
e2e_appmon (E2E Application Response Monitoring) Release Notes
e2e_appmon AC Configuration
The e2e_appmon probe is a remote probe, configured to monitor response time and availability of the client applications. Each monitoring profile
can execute multiple scripts. You can also define thresholds for generating alarms when the script execution time exceeds the specified limit. The
QoS messages are also configured for saving the response time of the application.
The following diagram outlines the process to configure the e2e_appmon probe to monitor applications.
Contents
Specify a Directory
Create a Profile
Alarm Thresholds
Create a Deployable Script Package
Verify that required hardware and software is available before you configure the probe. For more information, see E2E Application Response
Monitoring (e2e_appmon) Release Notes.
Specify a Directory
This section describes about how to enable the probe to run the compiled NimRecorder scripts on the target system.
Follow these steps:
1. Open the e2e_appmon probe.
2. Specify the username and password for the target system where the probe runs the NimRecorder script. The script has the same access
level as the user.
3. Specify the path of the directory with the TaskExec.exe. This TaskExec.exe file is used for executing the compiled scripts on both 32-bit
and 64-bit platforms.
You can also click Browse to navigate to the executable file.
4. Specify the path of the directory with the compiled script files.
Note: The default relative paths of the Command and .ROB File Directory fields do not work. Remove these default paths and
configure the absolute paths manually.
Create a Profile
A monitoring profile specifies the NimRecorder script and its execution properties, which the probe runs on the target remote system. You can
create more than one profile and can monitor multiple applications response.
Follow these steps:
2. Select the Add New Profile option.
3. Define the Profile Name and click Submit.
4. Update the sections mentioned below and click Save.
Run Properties
This section lets you specify the NimRecorder script and its execution properties.
1. Specify the compiled script file, which the profile runs.
2. Define the arguments for executing the scripts.
3. Define the maximum execution time of the script.
On Timeout
This section lets you configure the actions when the NimRecorder script execution time exceeds the limit.
1. Select Dump Screen on Timeout to capture the snapshot of the application when the script execution time exceeds the limit.
2. Select Kill Process on Timeout to terminate the script execution process.
On Error Return
This section lets you configure the alarm when the NimRecorder script generates an error after execution.
1. Select Expected Return Values=0 to set 0 as the return code of the script.
2. Select Dump Screen on Error to capture and save the snapshot of the application when the error occurs.
3. Select Alarm Message, which matches with the alarm text and severity.
Cleanup on Timeout or Error Return

This section lets you specify another NimRecorder script in the Run .Rob File field, which runs when the profile script times out or returns an
error.
Source Used for Quality of Service and Alarm Messages

This section lets you specify another NimRecorder script, which runs when the profile script times out or returns an error.
1. Select Override With to enable the Source field for specifying the custom QoS and Alarm source.
2. Enter the Source to define the custom QoS and Alarm source.
The probe starts executing the script on the target system for generating alarms and QoS messages.
Alarm Thresholds
allow the probe to:

As an application administrator, you are required to monitor application response on multiple systems using the same set of scripts. The
e2e_appmon probe lets you create a deployable script package. This script package can have more than one script with defined execution and
alarm properties. You can deploy this package on any other Robot and start monitoring.
Follow these steps:
1. Navigate to the Script node of the probe.
2. Define the Name of the script.
3. Specify a Version of the script package version.
4. Enter a short Description about the package functionality.
5. Select the scripts from the Available list to the Selected list.
6. Go to the Path/Dependent Files section and add the files, which you want to deploy on the target system with the script package.
Note: Leave the Path/Dependent Files section blank when there are no dependent files.
7. Select the Validate Package Name option from the Actions drop-down list.
This option prevents you from creating a duplicate package with the same name and version.
OR
8. Select the Publish to Archive option from the Actions drop-down list for creating a package.
The probe creates a deployable package in the Archive directory and displays a success message on the probe GUI.
e2e_appmon AC GUI Reference

This article describes the fields and features of the e2e_appmon probe.
Contents
e2e_appmon Node
<Profile Name> Node
Variables Node
Script Node
e2e_appmon Node
The e2e_appmon node lets you view the probe information and configure the properties which are applicable to all monitoring profiles of the
probe.
Navigation: e2e_appmon
e2e_appmon > Probe Information
This section provides information about the probe name, probe version, probe start time, and the probe vendor.
e2e_appmon > Log Level Configuration
This section is used to configure log properties of the probe.
Default: 0 - Normal
Log File Size (KB): defines the maximum size of the log file.
Default: 100
e2e_appmon > Run as User
This section is used for configuring the user details for providing necessary privileges to execute the NimRecorder script.
Name: defines the user name of the target system where the probe runs the NimRecorder script. The script has the same access level as
the user.
Default: administrator
Password: defines the password for authorizing the specified user name.
User Check to Prevent Script to be Run from the Wrong User: prevents the NimRecorder script execution by any other user, except the
one that is specified in the probe.
Reset Registry Settings Right After the User is Logged on: resets the registry settings after the user logs in successfully. Enabling this
option makes the target system less vulnerable to malicious attacks over a network. Also, when the remote desktop connection (RDP) is
used, a legal notice is displayed. However, ensure the presence of an automatic login to the system through the registry settings.
Note: This option aborts the login process on a slow processing system.
e2e_appmon > Run Properties

This section is used for configuring the execution properties of the NimRecorder script.
Default Run Interval (Seconds): defines the time interval between each NimRecorder script execution process.
Default: 33
Default Maximum Run Time (Seconds): defines the time limit for NimRecorder script execution. The probe can generate alarm when this
limit is breached.
Command: defines the path of the directory where the TaskExec.exe file is located. This TaskExec.exe file is used for executing the
compiled NimRecorder scripts on both 32-bit and 64-bit platforms.
Default: \program files (x86)\Nimsoft\e2e_scripting\bin
.ROB File Directory: defines the path of the directory where the compiled NimRecorder script files are stored.
Default: \program files (x86)\Nimsoft\e2e_scripting\scripts
Note: The default relative paths of the Command and ROB File Directory fields do not work. Remove these default paths and
e2e_appmon > Alarm on Start Error

This section is used to configure the alarm when the NimRecorder script fails to start on the target system.
Publish Alarm: enables the probe for generating alarms when the NimRecorder script fails to start on the target system.
Alarm on Start Error: specifies the alarm message name, which determines the alarm text and severity.
e2e_appmon > Alarm on Interval Breach
This section is used to configure an alarm when the start time of NimRecorder script breaches the threshold limit for the start time.
e2e_appmon > Alarm on Process Kill
This section is used to configure the alarm when the probe has to kill the NimRecorder script execution process. This probe kills the process
because the script is not completed within the time limit.
e2e_appmon > Alarm on Disable
This section is used to configure an alarm when the probe has to disable the NimRecorder script execution due to any reason. One such reason
can be a script causing some potential security risk on the target system.
Disable After: defines the time limit in seconds after which the probe disables the script execution.
e2e_appmon > Message Properties
This section displays a list of alarm messages that are defined in the probe. You can select and view the message details but cannot add or edit
messages to the list. These alarm messages are specified for various alarm conditions, for example, when the NimRecorder script fails to start.
e2e_appmon > Profile Properties
This section displays a list of monitoring profile with their execution status in a table. Select a monitoring profile from the table and view its details.
Name: identifies the monitoring profile name.
ROB File: identifies the compiled NimRecorder script file name, which the profile executes for monitoring.
Last Started: identifies the date and time value when the NimRecorder script was last executed.
Running: indicates the NimRecorder script status, whether the script is currently executing.
Times Used (Last Run in Seconds): identifies the time that is consumed during last NimRecorder script execution.
Return Code (Last Run): identifies the return code of the NimRecorder script after last execution.
Time Started: identifies the number of times the script is executed after the probe is activated last.
Time Killed: identifies the number of times the probe has killed the NimRecorder script.
Time Failed to Start: identifies the number of failed NimRecorder script executions.
Maximum Run Time: identifies the maximum run time of the NimRecorder script among all executions.
<Profile Name> Node

The profile name node represents the actual monitoring profile of the probe. This node lets you configure the profile-specific properties for
monitoring and displays all the monitoring profiles.
Navigation: e2e_appmon > Robot Name > Profiles > profile name
profile name > Profiles
This section lets you activate or deactivate the monitoring profile.
profile name > Run Properties
This section lets you configure the NimRecorder script and its execution properties.
Compiled Script (ROB File): specifies the compiled script file, which the profile runs. The path of the ROB Files Directory field in the Run
Properties section of the e2e_appmon node is used for fetching list of compiled scripts.
Arguments: defines the parameters for executing the scripts.
Maximum Run Time (Seconds): defines the maximum execution time of the script. The probe generates an alarm when the execution
time exceeds this limit.
profile name > On Timeout
Dump Screen on Timeout: captures the snapshot of the application when the timeout occurs.
Kill Process on Timeout: terminates the script execution process.
Default: Selected
profile name > On Error Return Alarm
This section lets you view the alarm details when the NimRecorder script generates an error after execution.
profile name > On Error Return
Expected Return Values=0: expects 0 as the return code of the script. The probe generates the alarm, otherwise.
Dump Screen on Error: captures and saves the snapshot of the application when the error occurs.
Alarm Message: specifies the alarm message name, which identifies the alarm text and severity.
profile name > Cleanup on Timeout or Error Return
This section lets you specify another NimRecorder script, which runs when the profile script times out or returns an error. This script is used to
delete erroneous actions for running other scripts.
profile name > Source Used for Quality of Service and Alarm Messages
This section lets you override the QoS and alarm source, which is configured in the script.
Override With: enables the Source field for specifying the custom QoS and Alarm source.
Source: defines the custom QoS and Alarm source.
profile name > Quality of Service Message
This section lets you activate the QoS on NimRecorder script execution time. You can also configure dynamic and static thresholds on this QoS.
profile name > Alarm on Start Error
This section lets you view the alarm details when the NimRecorder script fails to start on the target system.
profile name > Alarm on Interval Breach
This section lets you view the alarm details when the start time of the NimRecorder script breaches the maximum start time threshold limit.
profile name > Alarm on Process Kill
This section lets you view the alarm details when the probe has to kill the NimRecorder script execution process.
profile name > Alarm on Disable
This section lets you view the alarm details when the probe has to disable the NimRecorder script execution due to any reason.
Note: The Alarm on Start Error, Alarm on Interval Breach, Alarm on Process Kill, and Alarm on Disable are configurable through
the e2e_appmon node. You can only view the alarm details at profile level.
Profile > Options (icon) > Delete

This option allows you to delete a file profile
Variables Node
The Variables node lets you define variables, which are used in multiple NimRecorder scripts. For example, you can put a global user name and
password in the variable value which can be used in multiple scripts.
Navigation: e2e_appmon > Robot Name > Variables
Variables > Variables
This section lets you view the list of variables in the grid. Select any variable from the list and edit the variable value. You can also select the Dele
te option of the grid to remove the variable from the list.
Note: Use the Options icon next to the Variables node in the navigation pane to add variables.
Variables > Quality of Service Variables

This section is used to map the QoS name of the earlier wintask probe with the e2e_appmon probe QoS. Use this section while migrating from
the earlier wintask probe to the e2e_appmon probe.
Script Node
The Script node lets you create independent and deployable NimRecorder script packages. These packages can be deployed on the target robot
(similar to other probe packages) for monitoring. You can add multiple scripts and their dependent files to a deployable package.
Important! Refer to the e2e_appmon Script Considerations article, which provides information to create and deploy the script
packages.
Navigation: e2e_appmon > Robot Name > Script

Script > Scripts
This section lets you define the script package details.
Name: defines a unique script package name. This name must be unique.
Note: Use the Validate Package Name option from the Actions drop-down list and verify that the package name meets the
naming conventions.
Version: defines the script package version.
Default: 1.0
Description: defines a short description about the package functionality.
List of Scripts: lets you select and move a script from the Available list to the Selected list for creating the script package. The list is
available only when the probe is activated. You can add more than one script to the package file.
The script execution settings are inherited from the associated profile. If more than one profile is associated to a script, the script
execution settings are inherited from the first monitoring profile. If there is no monitoring profile, the default execution settings are used.
Script > Path/Dependent Files
This section lets you add the dependent files, which you want to deploy on the target system with the script package. For example, the script is
referring a .dll file during the execution. Use the New button for adding more than one file to the list.
Rob File: specifies the ROB file for which you can define a dependent file.
Path/Dependent Files: defines the dependent file name and path. Use the browse button for navigating to the correct path.
Note: Use the Save option from the Actions drop-down list for saving the dependent file details.
v2.2 e2e_appmon IM Configuration

v2.2 e2e_appmon IM GUI Reference
e2e_appmon IM Configuration
Specify a Directory
Create a Profile
Specify a Directory
Follow these steps:
1. Open the e2e_appmon probe configuration interface.
2. Specify the username and password for the target system where the probe runs the script. The script has the same access level as the
user.
You can also click the Browse (...) button to navigate to the executable file.
You can also click Browse (...) to navigate to the executable file.
Create a Profile
A monitoring profile specifies the NimRecorder script and its execution properties, which the probe runs on the target system. You can create
more than one profile and can monitor multiple applications response.
Follow these steps:
1. Navigate to the Status tab.
2. Right-click in the tab and select Add profile from the context menu.
3. Enter a Name of the profile.
4. Select Active to activate the profile.
Specify Run Properties

This section lets you define the NimRecorder script and its execution properties.
Follow these steps:
1. Select a script to run, from the Compiled script (.rob file) field.
2. Define the argument to run the script.
3. Specify the Max. run time value (in seconds) for which the script is allowed to run.
4. Select Expect return value = 0 to determine the return value from the scripts. The field also determines whether the script is executed
successfully.
The On error return tab, is enabled if Expect return value = 0 field is selected. The On error return, displays the error has occurred in the
script.
On Timeout
Follow these steps:
1. Select Dump screen on timeout to save a snapshot of the application when the script execution time exceeds the limit.
2. You can also select Kill processes on timeout to terminate the associated processes with the script on the timeout.
On Error Return Tab

This section lets you configure the alarm, when the NimRecorder script generates an error after execution.
Follow these steps:
1. Select Dump error on screen to save a snapshot of the application when the script does not return an expected result.
1.
Note: The On error return tab is enabled only if Expect return value = 0 field is selected.
2. Enable Alarm message to generate alarms when the script returns an error.
3. Select a specific alarm message to be generated when the script returns an error.
Cleanup on timeout or error return

Follow these steps:
1. Select a script in the Run.ROB file field, which runs when the script is timed out returns an error.
2. Schedule the script run time in the Scheduling tab.
3. Select Send QoS on total run time to generate QoS data for the script run time.
A profile is created to start executing the script on the target system for generating alarms and QoS.
e2e_appmon IM GUI Reference

Double-click the e2e_appmon probe in the Infrastructure Manager, the probe GUI with various tabs and fields for configuring the probe
appears. This article describes the fields and features of the e2e_appmon probe.
Contents
Setup Tab
Status Tab
Run Properties Tab
Scheduling Tab
Advanced Tab
Messages Tab
Variables Tab
Scripts Tab
Setup Tab
The Setup tab is used to configure general settings of the probe, which are common for all profiles.
The tab contains the following fields:
Run as user
Defines the login user name and password of the target computer where the probe runs the NimRecorder script.
User check to prevent scripts to be run from the wrong user
Prevents the NimRecorder script from being executed on the target system by unauthorized users.
Reset registry settings right after the user is logged on
Resets the registry settings after successful login of the user. Enable this option to make the target system less vulnerable to malicious
attacks over a network. Ensure the presence of the automatic logon settings in the registry.
Log Level
Sets the level of details that are written in the log file.
Note: Select a lower log level during the normal operation and minimize the disk consumption. You can increase the log level
while debugging.
Log Size
Defines the size of the log file for the probe for writing the log messages.
Default: 100 KB
Note: When the specified size is reached, the content of the file is cleared.
Run properties
Default run interval (seconds)
Defines the frequency at which the script runs.
Default max run time (seconds)
Defines the time duration the script is allowed to use on one run. This value can be overridden for each of the profiles that are defined
under the Status tab.
Command
Defines the path of the directory where the TaskExec.exe file is located. The default location of the TaskExec.exe file is \program
files (x86)\Nimsoft\e2e_scripting\bin. This TaskExec.exe file executes the compiled NimRecorder scripts on both 32-bit and 64-bit
platforms.
.ROB File Directory
Defines the path of the directory where the compiled NimRecorder script files are stored.
Note: The default relative paths of the Command and .ROB File Directory fields do not work. Remove these default paths
and configure the absolute paths manually.
Suspend
Suspends the execution of NimRecorder scripts. However, it is still possible to retrieve the last executed status and view the screenshots
of the script.
Status Tab
The Status tab is used to configure monitoring profiles for the e2e_appmon probe. This tab also displays a list of defined monitoring profiles and
allows you to edit and delete the profiles. Right-click in the window to add, edit, or delete the profiles. Right-click the profile under the Status tab
and select the View screendumps option, to view the screen dump for the profile.

Name
Displays the name of the profile.
ROB file
Displays the name of the NimRecorder script (a ROB file) run by the probe using different profiles.
Last started
Displays the last time that the probe was started.
Running
Displays the running state of the NimRecorder script. Yes means running and blank means not running.
Time used (last run)
Displays the time duration used in last execution of the NimRecorder script.
Return code (last run)
Displays the status code returned after last execution of the NimRecorder script.
Times started
Displays the number of times the NimRecorder script is executed after the e2e_appmon probe is activated last time.
Times killed
Displays the number of times the NimRecorder script is killed after the e2e_appmon probe is activated last time.
Times failed to start
Displays the number of times the NimRecorder script has failed to start after the e2e_appmon probe is activated last time.
Max. run time
Displays the maximum time for running a profile.
The Profile properties dialog appears on selecting the Add profile or Edit profile option. The Profile properties dialog contains the following
field:
Name
The Profile properties dialog contains the following sub tabs:
Run properties
Scheduling
Advanced
Run Properties Tab
The Run properties tab is used to specify the NimRecorder script for the profile. This tab is also used to configure the runtime environment for
the script for handling timeout and error situations.
The Run properties tab contains the following fields:
Compiled script (.rob file)
Specifies a NimRecorder script, a ROB file, from the drop-down list. You can select the files from the directory as specified in the ROB
file directory field of the Setup tab.
Arguments
Defines the parameter required to run the script.
Max. run time
Defines the maximum time for which the NimRecorder script is allowed to run.
Note: This value overrides the default value that is specified in the Setup tab.
Expected return value = 0

Checks the return value from the NimRecorder script and determine whether the script is executed successfully or not.
On timeout
Dump screen on timeout
Saves the snapshot of the application when the NimRecorder script execution time exceeds the limit. Right-click the profile under the
Status tab and select the View screendumps option to view the screen dump for the profile.
Kill processes on timeout
Terminates the other processes with the NimRecorder script on timeout.
On error return
Dump screen on error
Saves a snapshot when the script does not return an expected result. The snapshot for the profile is displayed by right-clicking the
profile under the Status tab and selecting the View screendumps option. This option is enabled after selecting the Expect return
value = 0 option.
Alarm message
Specifies the alarm message from the drop-down list when the NimRecorder script returns an error.
Specifies the ROB file (a compiled NimRecorder script) from the drop-down list, which runs when the script times out or returns an error.
This script is used to clean up all the previous actions to run other scripts.
Send QoS on total run time
Generates the QoS data that is related to the script run time.
Note: The NimRecorder script itself is configured to send QoS data using the developer version of the probe.
Scheduling Tab
The Scheduling tab is used to schedule the run time of the NimRecorder script. This tab also allows you to configure when the script can or
cannot run.
The Scheduling tab contains the following fields:
Run Interval
Specifies the interval between two consecutive executions of each profile. The interval can either be on every probe interval or be at a
specified time interval.
Only run on
Provides the following options for restricting the NimRecorder script execution:
In time ranges
Specifies a comma-separated list of time ranges. For example, 10:05-11:30, 12:34-16:00
Weekdays
Specifies a comma-separated list of weekdays or range of weekdays. For example, mon, thu-sat
Days of months
Specifies a comma-separated list of month dates. For example, 2-5,14-16,21
Do not run on
Defines a comma-separated list of dates (in day.month format) when the script does not run. For example, 5.1, 9.1
Advanced Tab
The Advanced tab allows you to select the source of the QoS and Alarm messages.
The Advanced tab contains the following fields:

Local machine
Specifies the machine name where the probe is hosted.
Note: This machine name appears as the source in QoS and alarm messages.
Override with
Defines a custom hostname, which appears as the source in QoS and alarm messages.
Messages Tab
The Messages tab is used to maintain a pool of alarm messages. These alarm messages are used across the monitoring profiles of the
e2e_appmon probe. By default, there are five alarm messages. You can add, edit, and delete messages to this message pool.
In the drop-down lists of the Alarm message setup grid, you can specify the alarm message to be issued for four different alarm conditions:
Alarm on start error
Alarm on interval breach
Alarm on process kill
Disable after (specific number of) errors and send a message
Alarm on unexpected returned value
The following options appear on right-clicking the message list:
Add message: This option enables you to define new alarm messages.
Message properties: This option enables you to edit one of the existing alarm messages.
Remove messages: This option enables you to delete alarm messages.
On selecting the Add message or Message properties option, the Message properties dialog appears.
The Message properties dialog contains the following fields:
Name
Defines a unique name of the message. This name is used to refer to the message from the profiles.
Default for
Specifies the alarm situations to be selected as the default alarm message for a specific type of alarm message.
Text
Defines the alarm message text. The following variables can be used:
$profile: profile name.
$failed: number of consecutive failures.
$sec: seconds delay on interval breach
$error: error message on start error.
$return - actual return code from last run
$expected_return - expected return code after successful run of the script.
Level
Specifies the severity level assigned to the alarm messages.
Subsystem
Defines the subsystem_ID of the alarms, the watcher generates. A string or the subsystem id is managed by the nas probe.
Variables Tab
The Variables tab lets you define variables that is used in the NimRecorder script. For example, if you are using a password in the script and
want to encrypt and protect the password being presented in the raw form. In such cases, define the password as a variable and select the Encry
pt option.
The Variables tab contains the following field:
Quality of Service Variables
The probe sends QoS messages on the NimRecorder script run time. The probe exports the QoS to the script also enables the script to
send QoS.
Three options Add variable, Variable properties, and Remove variable appear when you right-click the Variables list. On selecting the Add
variable or Variable properties option, the Variable properties dialog displays. The Variable properties dialog is used to add or modify the
variable properties.
The Variable properties dialog contains the following fields:
Variable name
Defines the variable name, which is unique for each variable.
Crypted
Encrypts the variable value and prevents the same being displayed in the human readable format.
Variable value
Defines a value to be assigned to the variable.
Scripts Tab
The Scripts tab allows you to create independent and deployable NimRecorder script packages. These packages can be deployed on the target
robot (similar to other probe packages) for monitoring. You can add more than one NimRecorder script and their dependent files to one
deployable package.
packages.
The Scripts tab contains the following fields:

Name
Defines the name of the script package to be made.
Version
Specifies the version number of the script package to be created.
Default: 1.0
Description
Defines a short description of the script package.
Scripts
Displays the list of scripts present in the path, which are specified in the ROB file directory field of the Setup tab. The list is available
only when the probe is activated. More than one script can be added to the package file.
The script execution settings are taken from the associated profile. If more than one profile is associated to a script, double-click the
script name and select the profile name.
The selected profile settings are used to execute the script. Double-click the profile name for editing the profile properties of the script
while selecting the profile.
If no profile is associated with a script, then such script displays in red color and default settings are used for its execution. You can
double-click the script name to define the script properties.
Path/Dependent Files
Allows you to browse the dependent files (for example, .bmp files) required to execute the script. You can select more than one file of the
same directory in one attempt. This field remembers the last navigation path.
Note: The script uses an absolute path of the dependent files.
Add Files
Allows you to add the path of dependent files in the Paths list-box.
Paths List Box
Displays the path list of dependent files to be included, while generating the package. You can right-click any of the dependent files and
can select the Delete to remove the selected file from the list.
Publish to Archive
Publishes the script package to the Archive directory of the primary hub.
e2e_appmon Script Considerations

The considerations of creating and deploying the script packages are as follows:
Script that is recorded on a particular OS can only be deployed on that OS. For example:
If recorded on Windows 7, the script does not work on Windows Server 2012 R2 or Windows 8.
If recorded on the 64-bit robot, the script can only be deployed on the 64-bit robot.
If recorded on OS with IE9, the script can only be deployed on OS with IE9.
If recorded on OS, where a dependent file is on the E:\ drive, the target host must also have an E:\ drive present.
If recorded with the NimRecorder 3.9, the target host must also have the NimRecorder 3.9.
The absolute path of dependent files is provided while recording the scripts.
To create a script package, a profile is created for the scripts that are included in the script package. If there is no profile, a default profile
is created with the ROB file name in the configuration file after deploying the package.
Note: As of now, you cannot edit the default settings.
A profile and a script cannot have the same name on the target robot, otherwise either the profile name, or the script name is overridden.
The robot does not display any warning message while deploying the probe.
The dependent files can only be added from the C:\ drive. This process is in line with how current script path is configured in the probe.
All the files are copied to the folders according to the robot on which script is recorded, after deploying the package.
The robots, on which script package is deployed, must be running the e2e_appmon probe. The Distribution Manager deploys the script
package without any validation.
You cannot deploy only one script from a package (in case the package contains more than one script) to the robot.
e2e_appmon API
The e2e_appmon developer edition allows the developer to include checkpoints within the NimRecorder script. This functionality enables the
probe to measure intermediate times of each process with the total runtime of the script.
The package contains the CA Nimsoft API to be used with the e2e_appmon probe. The API allows the NimRecorder to use the functions in the
script. The functions enable the programmer to access alarm and quality of service functions.The alarms and functions are acessed from the
Nimsoft API in their in-house developed scripts.
This API contains core Nimsoft functions (for sending Alarms and QoS) and other supporting functions to make scripting easier.
While using the e2e_appmon probe:
Your script must begin with Include Nimsoft-functions.src.
The Nimsoft-functions.src file must be in the same directory as the script.
The file nimmacro.dll must be in the same directory as Nimsoft-functions.src.
SDK_appmon offers advanced scripting by offering the following functionalities:
Gathering multiple QoS points to identify the bottlenecks
Pre and post run cleanup
Synchronization
Error handling
Tuning your script to minimize the resource usage
Hiding or encrypting the passwords
Working with Citrix
Contents
nimGetEnv
nimGetEnvEx
nimStartRun
nimProcessExist
nimWaitForWebContents
nimWaitForWebContentsEx
nimWaitForWindow
nimWaitForWindowText
nimAlarm
nimAlarmSimple
nimInit
nimEnd
nimSetVariable
nimQoSSendTimer
nimQoSSendNull
nimQoSSendValue
nimQoSSendValueStdev
nimQoSStart
nimQoSStop
nimQoSReset
nimQoSGetTimer
nimInitWithMax
nimSetCi
nimLogin
nimActivateTotRule
nimDeactivateTotRule
nimGetEnv
nimGetEnv$(var$,def$)
Parameters
String
var$
The environment variable to fetch.
String
def$
Default if the variable is not in the environment.
Returns
String environment value
Description
Returns the contents of the environment variable referred to in var$. If the variable is not in the environment, by default it returns the value of def$.
Example
home$=nimGetEnv("HOMEDRIVE", "C:")
Dialog that is used in nimGetEnvEx to allow user to enter a value/string:
begindialog dlgAsk 225,130,200,110

caption "Please enter value"
defpushbutton "&OK",btnOk,10,50,65,20
edittext txtAsk$, 10,10,170,24
enddialog
Dialog that is used in nimGetEnvEx to allow the user to enter a password:
begindialog dlgAskSec 225,130,200,110

caption "Please enter value"
defpushbutton "&OK",btnOk,10,50,65,20
edittext txtAsk$, 10,10,170,24,protected
enddialog
nimGetEnvEx
nimGetEnvEx$(var$,def$,ask,pass).
Parameters
String
var$
The environment variable to fetch.
String
def$
Default if the variable is not in the environment.
Number
ask
If set, the dialog asks the user to input the string.
Number
pass
If set, the dialog masks out the input string.
Returns
String value
Description
Returns the contents of the environment variable referred to in var$. If the variable is not in the environment, it defaults to def$. If ask is set to 1,
the dialog prompts you to input the string. If the pass is set to 1, the dialog masks out the input string.
Example
user$= nimGetEnvEx("Test-user","admin",1,0)
pass$= nimGetEnvEx("Test-pass","admin","",1,1)
nimStartRun
nimStartRun(cmd$)
Parameters
String
cmd$
The cmd$ to be executed from the Run entry on the Start menu.
Returns
0: OK.
1: Failed to get the Run window.
Description
Allows you to execute the cmd$ from the Run entry on the Start menu. The caller ensures that the command to be executed uses <doublequote>
and other special keys. This is to ensure that the command understandable to SendKeys.
nimProcessExist
nimProcessExist(procname$,killproc)
Parameters
String
procname$
Name of the process to be located and terminated.
Number
killproc
Terminates the specified process soft (if 1), and hard (if 2).
Returns
0: process not found.
1: process found.
Description
Locate named process (procname) and terminates the process if (killproc) is (1=soft,2=hard).
Note: The method is deprecated and in wintask 2.6a the function killapp() was added and does the same thing natively.
nimWaitForWebContents
nimWaitForWebContents(pageid$,contents$,load_timeout)
Parameters
String
pageid$
The web page to search for the contents specified.
String
contents$
The contents to search for in the web page specified.
Number
load_timeout
The number of seconds to wait for match before timeout.
Returns
0: timeout, no match.
1: match.
Description
Waits for matching contents of the web page for (load_timeout) seconds.
nimWaitForWebContentsEx
nimWaitForWebContentsEx(pageid$,contents$,content_fail$,load_timeout)
Parameters
String
pageid$
The web page to search for the contents specified.
String
contents$
The contents to search for in the web page specified.
String
content_fail$
The failure match to be applied as failure match when the content specified fails to match.
Number
load_timeout
Returns
0: timeout, no match.
1: match.
Description
Waits for matching contents of the web page for (load_timeout) seconds. Applies a failure match too when the content fails to match.
nimWaitForWindow
nimWaitForWindow(winid$,load_timeout)
Parameters
String
winid$
The identification of the window to wait for.
Number
load_timeout
The number of seconds to wait for the specified window to appear before timeout.
Returns
0: timeout, no match
1: match
Description
Waits for a window matching (winid$) to appear within (load_timeout) seconds.
nimWaitForWindowText
nimWaitForWindowText(winid$,textstr$,load_timeout)
Parameters
String
winid$
The identification of the window to wait for.
String
textstr$
The text string to search for in the window specified.
Number
load_timeout
Returns
0: timeout, no match
1: match
Description
Waits for a window matching (winid$) containing the text string (textstr$) to appear within (load_timeout) seconds.
nimAlarm
nimAlarm(severity,msg$,supp$,subsys$)
Parameters
Number
severity
The severity level of the alarm message.
String
msg$
The alarm message text.
String
supp$
Suppression ID.
String
subsys$
The id of the subsystem, identifying the module that the alarm is related to.
Returns
0 = OK
Description
Sends alarm message containing severity level, message text, checkpoint id, and subsystem id.
Example
nimAlarm(5,"critical alarm","script-name","E2E-appmon")
nimAlarmSimple
nimAlarmSimple(severity,msg$)
Parameters
Number
severity
The severity level of the alarm message.
String
msg$
The alarm message text.
Returns
0 = OK.
Description
Sends alarm message containing severity level and message text. The rest is provided by the global variables suppression_id$ and subsystem$.
Example
nimAlarm(5,"critical alarm")
nimInit
nimInit()
Parameters
None
Returns
0 = OK
Description
Initializes the Nimsoft SDK components. Must be run if using QoS.
nimEnd
nimEnd()
Parameters
None.
Returns
0 = OK
Description
Unloads the Nimsoft components and releases memory.
nimSetVariable
nimSetVariable(variable$, value$)
Parameters
None
Returns
0 = OK
Description
Sets the global variable named (variable$) to a new value. Allows you to override the suppression-id or subsystem.
Example
nimSetVariable("suppression-id","script")
nimQoSSendTimer
nimQoSSendTimer(target$)
Parameters
String
target$
Unique identifier for the QoS checkpoint.
Returns
0 = OK.
Description
Sends the recorded timer for the specified target.
Example
nimQoSSendTimer("citrix login")
nimQoSSendNull
nimQoSSendNull(target$)
Parameters
String
target$
Returns
0 = OK
Description
Sends a NULL (invalid data) for the specified target.
Example
nimQoSSendNull("citrix login")
nimQoSSendValue
nimQoSSendValue(target$,value)
Parameters
String
target$
Number
value
The value to send to the specified target.
Returns
0 = OK.
Description
Sends the recorded value (when not using timers) to the specified target.
Example
nimQoSSendValue("xxx",69)
nimQoSSendValueStdev
nimQoSSendValueStdev(target$,value$,stdev$)
Parameters
String
target$
String
value$
Number that is represented as a string,("12.45").
String
stdev$
Number that is represented as a string, ("12.45").
Returns
0 = OK.
Description
Sends the value and standard deviation (when not using timers).
nimQoSStart
nimQoSStart()
Parameters
None
Returns
Nothing
Description
Starts the QoS timer.
nimQoSStop
nimQoSStop()
Parameters
None
Returns
Nothing
Description
Stops the QoS timer.
nimQoSReset
nimQoSReset()
Parameters
None
Returns
Nothing
Description
Resets the QoS timer.
nimQoSGetTimer
nimQoSGetTimer()
Parameters
None
Returns
Timer in milliseconds
Description
Returns the stored (last) QoS Timer. If the nimQoSStop function has notbeencalled, then the time between nimQoSStart was called and the
current time is returned.
nimInitWithMax
nimInitWithMax(qos_name$, source$, description$, long_unit$, short_unit$, max_value)
Parameters
String
qos_name$
The qos name of the e2e_appmon probe.
String
source$
Source from where QOS is coming.
String
description$
e2e_appmon Script Run Time.
String
long_unit
Full unit ex. milliseconds.
String
short_unit
Abbr. ex ms.
Int
max_value
QOS max values.
Returns
0 = OK.
Description
This function allows you to set various QoS parameters.
Example
nimInitWithMax(QOS_E2E_EXECUTION, QOS_source1, description$, Milliseconds, ms, 100)
nimSetCi
nimSetCi(type$, name$, remotename$, Metric$)
This function is used to add an additional device and metric information to alarms or quality of service message sent afterwards.
Parameters
String
type$
The CI type Id
String
name$
The name of the object
String
remotename$
If the object is remote, the remotename is the hostname of the object owner. An empty string denotes the local host.
String
Metric$
The metric identifies the required property of the monitored object. For example, response time, usage or other
performance parameters of the application.
Example
nimSetCi("3.21", "e2eappmon", "", "3.21:1") nimInit()
This API is required to be called before nimInit().
Setting nimSetCi before nimInit ensures that same Device Id/Metric Id are generated for all alarms and QoS.
For modifying Metric Id of Alarm, call the above API with modified parameters before nimAlarmSimple API.
nimSetCi("3.21", "e2eappmon", "", "3.21:2")

nimAlarmSimple(3,qos$(rc) + " failed")
For modifying Metric Id of QoS, follow this sequence:
nimSetCi("3.21", "e2eappmon", "", "3.21:3")

nimInit()
nimQoSSendNull(qos$(1))
nimInit is used to reset Metric Id for a QoS. And, it also resets the Metric Id of alarms being generated after sending this QoS.
nimLogin
nimLogin()
Parameters
String
username$
Username of the primary hub
String
password$
Password of the primary hub
Returns
None
Description
This function allows you to login to the CA UIM where the probe is installed.
nimActivateTotRule
nimActivateTotRule(time$,windows$,autoClear$,clearTime$)
Parameters
Number
time$
The time duration, in seconds, when a metric must remain over threshold before an alarm is sent.
Number
windows$
The time duration, in seconds, in the sliding window in which metrics are monitored for threshold violations.
Number
autoClear$
The state that defines whether the auto-clear functionality is enabled. The value must be either 0 or 1.
String
clearTime$
The time, in seconds, used in the auto-clear timer. If no alarms are sent in the set time period, the alarm is
Returns
None
Description
This function activates the Time Over Threshold (TOT) rule in the probe from your script.
Example
nimActivateTotRule(120,600,0,0)
nimDeactivateTotRule
nimDeactivateTotRule(,time$,windows$,autoClear$,clearTime$)
Parameters
Number
time$
The time duration, in seconds, when a metric must remain over threshold before an alarm is sent.
Number
windows$
The time duration, in seconds, in the sliding window in which metrics are monitored for threshold violations.
Number
autoClear$
The state that defines whether the auto-clear functionality is enabled. The value must be either 0 or 1.
String
clearTime$
The time, in seconds, used in the auto-clear timer. If no alarms are sent in the set time period, the alarm is
Returns
None
Description
This function deactivates the TOT rule in the probe from your script.
Example
nimDeactivateTotRule(180,1200,0,0)
e2e_appmon Troubleshooting
This section contains some troubleshooting points for the e2e_appmon probe.
NimRecorder is not Deployed or Installed

Scripts not Working after Upgrade
Scripts not Working due to Synchronization
NimRecorder is not Deployed or Installed

Symptom:
I am using the e2e_appmon probe deployed on my robot. However, the NimRecorder is not getting deployed to record new script and to edit
existing scripts. The probe is deploying the script executor only.
Solution:
Instead of deploying the e2e_appmon probe, deploy the e2e_appmon_dev (1.91 or later) probe. The NimRecorder is deployed automatically.
OR
For the e2e_appmon probe (standard edition), install the NimRecorder manually.
Follow these steps:
1. Go to Start > All Programs > Nimsoft Monitoring > E2E Scripting and select the Uninstall NimRecorder.
The Script Executor is removed.
2. Go to [Nimsoft Installation drive] > Nimsoft > probes > Application > e2e_appmon > Install folder.
3. Double-click the nimrecorder.msi.
Note: The name of .msi installer file is based on the NimRecorder version. For example, it is nimrecorder51.msi fo
r installing the NimRecorder 5.1.
4. Follow the instructions and install the NimRecorder.

The help file of the NimRecorder is accessible at Start > All Programs > Nimsoft Monitoring > E2E Scripting > Helpafter installing the
NimRecorder.
Scripts not Working after Upgrade

Symptom
My existing scripts have stopped working after upgrading the probe.
Solution
Recompile your existing scripts with the new NimRecorder to make them compatible.
Drop an email to info@wintask.com for troubleshooting your script-related issues and support on NimRecorder 5.1.
Scripts not Working due to Synchronization

Symptom
My existing scripts have stopped or lose focus while running the script through NimRecorder because of synchronization of text.
Solution
The UsePage and Web functions are used for synchronization process. The Internet Explorer (IE) uses the window name instance for the bitmap
synchronization and it varies with each IE execution. Therefore, the wintask recommendation is to use the TopInstance function of NimRecorder
instead of providing a constant instance number.
For example:
Pause 10 secs until

Bitmap("test.bmp")
InWindow("IEXPLORE.EXE|Internet Explorer_Server|WinTask_x64 Help Internet Explorer|1",2)
InArea( 101, 172, 26, 41 )
For Topinstance, the constant instance number can be replaced with:
Pause 10 secs until

Bitmap("test.bmp")
InWindow("IEXPLORE.EXE|Internet Explorer_Server|WinTask_x64 Help Internet Explorer|1",Topinstance())
InArea( 101, 172, 26, 41 )
Drop an email to info@wintask.com for troubleshooting your script-related issues and support on NimRecorder 5.1.
e2e_appmon Metrics
The following section describes the metrics that can be configured for the E2E Application Response Monitoring (e2e_appmon) probe.
Contents
QoS Metrics
QoS Metrics
The following table describes the checkpoint metrics that can be configured using the E2E Application Response Monitoring (e2e_appmon) probe
.
Monitor Name
Units
Description
Version
QOS_E2E_EXECUTION
Milliseconds
Monitors the script execution time.
v1.0

This section contains the alert metric default settings for the E2E Application Response Monitoring (e2e_appmon) probe.
Alarm Name
Warning Threshold
Warning Severity
Error Threshold
Error Severity
Description
Disabled
None
None
None
Major
Profile is disabled by the probe.
Killed
None
None
None
Minor
Profile did not complete on time and had to be killed.
ReturnError
None
None
None
Minor
Script returned an unexpected value.
StartError
None
None
None
Minor
Profile is not able to start and execute the script.
TimeBreached
None
None
None
Warning
Profile does not start on time.
e2e_appmon Custom Metrics

This article describes how to generate custom metrics and TOT alarms in the e2e_appmon probe.
Contents
How to Create Custom Metrics

How to Generate TOT Alarms for Custom Metrics
How to Create Custom Metrics
This section describes the functions that must be added to your script file to generate custom metrics. Refer e2e_appmon API article for the
description.
1. nimLogin("username$","password$")
2. nimInit2()
Note: The nimInit2() function is used when generating custom QoS. Refer nimInit() function in the e2e_appmon API article for
the description.
3. nimQoSStart()
4. Start a web based application to monitor the execution time. For example, StartBrowser("IE", "about:blank",3)
5. nimQoSStop()
6. nimQoSSendTimer(qos$(step))
7. nimAlarm(severity$,qos$(step) + "user-defined message","user-defined script","e2e_appmon")
How to Generate TOT Alarms for Custom Metrics

This section describes the steps to generate TOT alarms for custom metrics in the probe from your script.
Follow these steps:
1. Create a monitoring profile in the probe.
2. Create a script that executes the NimBus-functions, nimSetCi, and nimActivateTotRule functions and put this file in the same location as
defined in the Setup section of the probe.
A sample of the script file is as follows:
include "NimBUS-functions"
nimSetCi("3.21","e2eappmon_test","","3.21:6")
nimActivateTotRule(120,600,0,0)
3. Link this script to the monitoring profile created above.

4. Run the script to activate TOT rule in the probe.
5. Deactivate the monitoring profile created above.
Note: This is a necessary step otherwise the TOT alarm interval will reset everytime the script is run.
6. In another script that generates custom QoS and alarms, ensure that the nimLogin() function is executed in the beginning. Refer the
attached ScriptA.
ScriptA.src
Important! Ensure that the parameters provided in the nimSetCi() function is same in both the scripts so that same metric ids
are generated for a custom metric.
7. From the probe GUI, create and set APPMON_RUN_TOT = 1 in the Variables section.
Note: If this variable is set to or edited to 0, the probe does not generate TOT alarms.
e2e_appmon Version 2.2

This section contains documentation for versions 2.23 and earlier of the e2e_appmon probe:
v2.2 e2e_appmon AC Configuration
v2.2 e2e_appmon AC Configuration
Contents
Specify a Directory
Create a Profile
Alarm Thresholds
Specify a Directory
Follow these steps:
1. Open the e2e_appmon probe.
2. Specify the username and password for the target system where the probe runs the NimRecorder script. The script has the same access
2.
level as the user.
Create a Profile
A monitoring profile specifies the NimRecorder script and its execution properties, which the probe runs on the target remote system. You can
create more than one profile and can monitor multiple applications response.
Follow these steps:
2. Select the Add New Profile option.
3. Define the Profile Name and click Submit.
4. Update the sections mentioned below and click Save.
Run Properties
This section lets you specify the NimRecorder script and its execution properties.
1. Specify the compiled script file, which the profile runs.
2. Define the arguments for executing the scripts.
3. Define the maximum execution time of the script.
On Timeout
1. Select Dump Screen on Timeout to capture the snapshot of the application when the script execution time exceeds the limit.
2. Select Kill Process on Timeout to terminate the script execution process.
On Error Return
1. Select Expected Return Values=0 to set 0 as the return code of the script.
2. Select Dump Screen on Error to capture and save the snapshot of the application when the error occurs.
3. Select Alarm Message, which matches with the alarm text and severity.
Cleanup on Timeout or Error Return
This section lets you specify another NimRecorder script in the Run .Rob File field, which runs when the profile script times out or returns an
error.
Source Used for Quality of Service and Alarm Messages
1. Select Override With to enable the Source field for specifying the custom QoS and Alarm source.
2. Enter the Source to define the custom QoS and Alarm source.
The probe starts executing the script on the target system for generating alarms and QoS messages.
Alarm Thresholds
allow the probe to:

As an application administrator, you are required to monitor application response on multiple systems using the same set of scripts. The
e2e_appmon probe lets you create a deployable script package. This script package can have more than one script with defined execution and
alarm properties. You can deploy this package on any other Robot and start monitoring.
Follow these steps:
1. Navigate to the Script node of the probe.
2. Define the Name of the script.
3. Specify a Version of the script package version.
4. Enter a short Description about the package functionality.
5. Select the scripts from the Available list to the Selected list.
6. Go to the Path/Dependent Files section and add the files, which you want to deploy on the target system with the script package.
Note: Leave the Path/Dependent Files section blank when there are no dependent files.
7. Select the Validate Package Name option from the Actions drop-down list.
This option prevents you from creating a duplicate package with the same name and version.
OR
8. Select the Publish to Archive option from the Actions drop-down list for creating a package.
The probe creates a deployable package in the Archive directory and displays a success message on the probe GUI.
v2.2 e2e_appmon AC GUI Reference

This article describes the fields and features of the e2e_appmon probe.
Contents
e2e_appmon Node
<Profile Name> Node
Variables Node
Script Node
e2e_appmon Node
The e2e_appmon node lets you view the probe information and configure the properties which are applicable to all monitoring profiles of the
probe.
Navigation: e2e_appmon
e2e_appmon > Probe Information
This section provides information about the probe name, probe version, probe start time, and the probe vendor.
e2e_appmon > Log Level Configuration

This section is used to configure log properties of the probe.
Default: 0 - Normal
Log File Size (KB): defines the maximum size of the log file.
Default: 100
e2e_appmon > Run as User
This section is used for configuring the user details for providing necessary privileges to execute the NimRecorder script.
Name: defines the user name of the target system where the probe runs the NimRecorder script. The script has the same access level as
the user.
Default: administrator
Password: defines the password for authorizing the specified user name.
User Check to Prevent Script to be Run from the Wrong User: prevents the NimRecorder script execution by any other user, except the
one that is specified in the probe.
Reset Registry Settings Right After the User is Logged on: resets the registry settings after the user logs in successfully. Enabling this
option makes the target system less vulnerable to malicious attacks over a network. Also, when the remote desktop connection (RDP) is
used, a legal notice is displayed. However, ensure the presence of an automatic login to the system through the registry settings.
e2e_appmon > Run Properties

This section is used for configuring the execution properties of the NimRecorder script.
Default Run Interval (Seconds): defines the time interval between each NimRecorder script execution process.
Default: 33
Default Maximum Run Time (Seconds): defines the time limit for NimRecorder script execution. The probe can generate alarm when this
limit is breached.
Command: defines the path of the directory where the TaskExec.exe file is located. This TaskExec.exe file is used for executing the
compiled NimRecorder scripts on both 32-bit and 64-bit platforms.
Default: \program files (x86)\Nimsoft\e2e_scripting\bin
.ROB File Directory: defines the path of the directory where the compiled NimRecorder script files are stored.
Note: The default relative paths of the Command and ROB File Directory fields do not work. Remove these default paths and
e2e_appmon > Alarm on Start Error

This section is used to configure the alarm when the NimRecorder script fails to start on the target system.
Publish Alarm: enables the probe for generating alarms when the NimRecorder script fails to start on the target system.
Alarm on Start Error: specifies the alarm message name, which determines the alarm text and severity.
e2e_appmon > Alarm on Interval Breach
This section is used to configure an alarm when the start time of NimRecorder script breaches the threshold limit for the start time.
e2e_appmon > Alarm on Process Kill
This section is used to configure the alarm when the probe has to kill the NimRecorder script execution process. This probe kills the process
because the script is not completed within the time limit.
e2e_appmon > Alarm on Disable
This section is used to configure an alarm when the probe has to disable the NimRecorder script execution due to any reason. One such reason
can be a script causing some potential security risk on the target system.
Disable After: defines the time limit in seconds after which the probe disables the script execution.
e2e_appmon > Message Properties

This section displays a list of alarm messages that are defined in the probe. You can select and view the message details but cannot add or edit
messages to the list. These alarm messages are specified for various alarm conditions, for example, when the NimRecorder script fails to start.
e2e_appmon > Profile Properties
This section displays a list of monitoring profile with their execution status in a table. Select a monitoring profile from the table and view its details.
Name: identifies the monitoring profile name.
ROB File: identifies the compiled NimRecorder script file name, which the profile executes for monitoring.
Last Started: identifies the date and time value when the NimRecorder script was last executed.
Running: indicates the NimRecorder script status, whether the script is currently executing.
Times Used (Last Run in Seconds): identifies the time that is consumed during last NimRecorder script execution.
Return Code (Last Run): identifies the return code of the NimRecorder script after last execution.
Time Started: identifies the number of times the script is executed after the probe is activated last.
Time Killed: identifies the number of times the probe has killed the NimRecorder script.
Time Failed to Start: identifies the number of failed NimRecorder script executions.
Maximum Run Time: identifies the maximum run time of the NimRecorder script among all executions.
<Profile Name> Node
The profile name node represents the actual monitoring profile of the probe. This node lets you configure the profile-specific properties for
monitoring and displays all the monitoring profiles.
Navigation: e2e_appmon > Robot Name > Profiles > profile name
profile name > Profiles
This section lets you activate or deactivate the monitoring profile.
profile name > Run Properties
This section lets you configure the NimRecorder script and its execution properties.
Compiled Script (ROB File): specifies the compiled script file, which the profile runs. The path of the ROB Files Directory field in the Run
Properties section of the e2e_appmon node is used for fetching list of compiled scripts.
Arguments: defines the parameters for executing the scripts.
Maximum Run Time (Seconds): defines the maximum execution time of the script. The probe generates an alarm when the execution
time exceeds this limit.
profile name > On Timeout
Dump Screen on Timeout: captures the snapshot of the application when the timeout occurs.
Kill Process on Timeout: terminates the script execution process.
Default: Selected
profile name > On Error Return Alarm
This section lets you view the alarm details when the NimRecorder script generates an error after execution.
profile name > On Error Return
Expected Return Values=0: expects 0 as the return code of the script. The probe generates the alarm, otherwise.
Dump Screen on Error: captures and saves the snapshot of the application when the error occurs.
Alarm Message: specifies the alarm message name, which identifies the alarm text and severity.
profile name > Cleanup on Timeout or Error Return
This section lets you specify another NimRecorder script, which runs when the profile script times out or returns an error. This script is used to
delete erroneous actions for running other scripts.

profile name > Source Used for Quality of Service and Alarm Messages
This section lets you override the QoS and alarm source, which is configured in the script.
Override With: enables the Source field for specifying the custom QoS and Alarm source.
Source: defines the custom QoS and Alarm source.
profile name > Quality of Service Message
This section lets you activate the QoS on NimRecorder script execution time. You can also configure dynamic and static thresholds on this QoS.
profile name > Alarm on Start Error
This section lets you view the alarm details when the NimRecorder script fails to start on the target system.
profile name > Alarm on Interval Breach
This section lets you view the alarm details when the start time of the NimRecorder script breaches the maximum start time threshold limit.
profile name > Alarm on Process Kill
This section lets you view the alarm details when the probe has to kill the NimRecorder script execution process.
profile name > Alarm on Disable
This section lets you view the alarm details when the probe has to disable the NimRecorder script execution due to any reason.
Note: The Alarm on Start Error, Alarm on Interval Breach, Alarm on Process Kill, and Alarm on Disable are configurable through
the e2e_appmon node. You can only view the alarm details at profile level.
Profile > Options (icon) > Delete

Variables Node
The Variables node lets you define variables, which are used in multiple NimRecorder scripts. For example, you can put a global user name and
password in the variable value which can be used in multiple scripts.
Navigation: e2e_appmon > Robot Name > Variables
Variables > Variables
This section lets you view the list of variables in the grid. Select any variable from the list and edit the variable value. You can also select the Dele
te option of the grid to remove the variable from the list.
Note: Use the Options icon next to the Variables node in the navigation pane to add variables.
Variables > Quality of Service Variables

This section is used to map the QoS name of the earlier wintask probe with the e2e_appmon probe QoS. Use this section while migrating from
the earlier wintask probe to the e2e_appmon probe.
Script Node
The Script node lets you create independent and deployable NimRecorder script packages. These packages can be deployed on the target robot
(similar to other probe packages) for monitoring. You can add multiple scripts and their dependent files to a deployable package.
packages.
Navigation: e2e_appmon > Robot Name > Script

Script > Scripts
This section lets you define the script package details.
Name: defines a unique script package name. This name must be unique.
Note: Use the Validate Package Name option from the Actions drop-down list and verify that the package name meets the
naming conventions.
Version: defines the script package version.
Default: 1.0
Description: defines a short description about the package functionality.
List of Scripts: lets you select and move a script from the Available list to the Selected list for creating the script package. The list is
available only when the probe is activated. You can add more than one script to the package file.
The script execution settings are inherited from the associated profile. If more than one profile is associated to a script, the script
execution settings are inherited from the first monitoring profile. If there is no monitoring profile, the default execution settings are used.
Script > Path/Dependent Files
This section lets you add the dependent files, which you want to deploy on the target system with the script package. For example, the script is
referring a .dll file during the execution. Use the New button for adding more than one file to the list.
Rob File: specifies the ROB file for which you can define a dependent file.
Path/Dependent Files: defines the dependent file name and path. Use the browse button for navigating to the correct path.
Note: Use the Save option from the Actions drop-down list for saving the dependent file details.


Specify a Directory
Create a Profile
Specify a Directory
Follow these steps:
1. Open the e2e_appmon probe configuration interface.
2. Specify the username and password for the target system where the probe runs the script. The script has the same access level as the
user.
You can also click the Browse (...) button to navigate to the executable file.
You can also click Browse (...) to navigate to the executable file.
Create a Profile
A monitoring profile specifies the NimRecorder script and its execution properties, which the probe runs on the target system. You can create
more than one profile and can monitor multiple applications response.
Follow these steps:
1. Navigate to the Status tab.
2. Right-click in the tab and select Add profile from the context menu.
3. Enter a Name of the profile.
Specify Run Properties
This section lets you define the NimRecorder script and its execution properties.
Follow these steps:
1. Select a script to run, from the Compiled script (.rob file) field.
2. Define the argument to run the script.
3. Specify the Max. run time value (in seconds) for which the script is allowed to run.
4. Select Expect return value = 0 to determine the return value from the scripts. The field also determines whether the script is executed
successfully.
The On error return tab, is enabled if Expect return value = 0 field is selected. The On error return, displays the error has occurred in the
script.
On Timeout
Follow these steps:
1. Select Dump screen on timeout to save a snapshot of the application when the script execution time exceeds the limit.
2. You can also select Kill processes on timeout to terminate the associated processes with the script on the timeout.
On Error Return Tab
This section lets you configure the alarm, when the NimRecorder script generates an error after execution.
Follow these steps:
1. Select Dump error on screen to save a snapshot of the application when the script does not return an expected result.
Note: The On error return tab is enabled only if Expect return value = 0 field is selected.
2. Enable Alarm message to generate alarms when the script returns an error.
3. Select a specific alarm message to be generated when the script returns an error.
Follow these steps:
1. Select a script in the Run.ROB file field, which runs when the script is timed out returns an error.
2. Schedule the script run time in the Scheduling tab.
3. Select Send QoS on total run time to generate QoS data for the script run time.
A profile is created to start executing the script on the target system for generating alarms and QoS.

Double-click the e2e_appmon probe in the Infrastructure Manager, the probe GUI with various tabs and fields for configuring the probe
appears. This article describes the fields and features of the e2e_appmon probe.
Contents
Setup Tab
Status Tab
Run Properties Tab
Scheduling Tab
Advanced Tab
Messages Tab
Variables Tab
Scripts Tab
Setup Tab
The Setup tab is used to configure general settings of the probe, which are common for all profiles.
Run as user
Defines the login user name and password of the target computer where the probe runs the NimRecorder script.
User check to prevent scripts to be run from the wrong user
Prevents the NimRecorder script from being executed on the target system by unauthorized users.
Reset registry settings right after the user is logged on
Resets the registry settings after successful login of the user. Enable this option to make the target system less vulnerable to malicious
attacks over a network. Ensure the presence of the automatic logon settings in the registry.
Log Level
Sets the level of details that are written in the log file.
Note: Select a lower log level during the normal operation and minimize the disk consumption. You can increase the log level
while debugging.
Log Size
Defines the size of the log file for the probe for writing the log messages.
Default: 100 KB
Note: When the specified size is reached, the content of the file is cleared.
Run properties
Default run interval (seconds)
Defines the frequency at which the script runs.
Default max run time (seconds)
Defines the time duration the script is allowed to use on one run. This value can be overridden for each of the profiles that are defined
under the Status tab.
Command
Defines the path of the directory where the TaskExec.exe file is located. The default location of the TaskExec.exe file is \program
files (x86)\Nimsoft\e2e_scripting\bin. This TaskExec.exe file executes the compiled NimRecorder scripts on both 32-bit and 64-bit
platforms.
.ROB File Directory
Defines the path of the directory where the compiled NimRecorder script files are stored.
Note: The default relative paths of the Command and .ROB File Directory fields do not work. Remove these default paths
and configure the absolute paths manually.
Suspend
Suspends the execution of NimRecorder scripts. However, it is still possible to retrieve the last executed status and view the screenshots
of the script.
Status Tab
The Status tab is used to configure monitoring profiles for the e2e_appmon probe. This tab also displays a list of defined monitoring profiles and
allows you to edit and delete the profiles. Right-click in the window to add, edit, or delete the profiles. Right-click the profile under the Status tab
and select the View screendumps option, to view the screen dump for the profile.
Name
ROB file
Displays the name of the NimRecorder script (a ROB file) run by the probe using different profiles.
Last started
Displays the last time that the probe was started.
Running
Displays the running state of the NimRecorder script. Yes means running and blank means not running.
Time used (last run)
Displays the time duration used in last execution of the NimRecorder script.
Return code (last run)
Displays the status code returned after last execution of the NimRecorder script.
Times started
Displays the number of times the NimRecorder script is executed after the e2e_appmon probe is activated last time.
Times killed
Displays the number of times the NimRecorder script is killed after the e2e_appmon probe is activated last time.
Times failed to start
Displays the number of times the NimRecorder script has failed to start after the e2e_appmon probe is activated last time.
Max. run time
Displays the maximum time for running a profile.
The Profile properties dialog appears on selecting the Add profile or Edit profile option. The Profile properties dialog contains the following
field:
Name
The Profile properties dialog contains the following sub tabs:
Run properties
Scheduling
Advanced
Run Properties Tab
The Run properties tab is used to specify the NimRecorder script for the profile. This tab is also used to configure the runtime environment for
the script for handling timeout and error situations.
The Run properties tab contains the following fields:
Compiled script (.rob file)
Specifies a NimRecorder script, a ROB file, from the drop-down list. You can select the files from the directory as specified in the ROB
file directory field of the Setup tab.
Arguments
Defines the parameter required to run the script.
Max. run time
Defines the maximum time for which the NimRecorder script is allowed to run.
Note: This value overrides the default value that is specified in the Setup tab.
Expected return value = 0

Checks the return value from the NimRecorder script and determine whether the script is executed successfully or not.
On timeout
Dump screen on timeout
Saves the snapshot of the application when the NimRecorder script execution time exceeds the limit. Right-click the profile under the
Status tab and select the View screendumps option to view the screen dump for the profile.
Kill processes on timeout
Terminates the other processes with the NimRecorder script on timeout.
On error return
Dump screen on error
Saves a snapshot when the script does not return an expected result. The snapshot for the profile is displayed by right-clicking the
profile under the Status tab and selecting the View screendumps option. This option is enabled after selecting the Expect return
value = 0 option.
Alarm message
Specifies the alarm message from the drop-down list when the NimRecorder script returns an error.
Specifies the ROB file (a compiled NimRecorder script) from the drop-down list, which runs when the script times out or returns an error.
This script is used to clean up all the previous actions to run other scripts.
Send QoS on total run time
Generates the QoS data that is related to the script run time.
Note: The NimRecorder script itself is configured to send QoS data using the developer version of the probe.
Scheduling Tab
The Scheduling tab is used to schedule the run time of the NimRecorder script. This tab also allows you to configure when the script can or
cannot run.
The Scheduling tab contains the following fields:
Run Interval
Specifies the interval between two consecutive executions of each profile. The interval can either be on every probe interval or be at a
specified time interval.
Only run on
Provides the following options for restricting the NimRecorder script execution:
In time ranges
Specifies a comma-separated list of time ranges. For example, 10:05-11:30, 12:34-16:00
Weekdays
Specifies a comma-separated list of weekdays or range of weekdays. For example, mon, thu-sat
Days of months
Specifies a comma-separated list of month dates. For example, 2-5,14-16,21
Do not run on
Defines a comma-separated list of dates (in day.month format) when the script does not run. For example, 5.1, 9.1
Advanced Tab
The Advanced tab allows you to select the source of the QoS and Alarm messages.
The Advanced tab contains the following fields:

Local machine
Specifies the machine name where the probe is hosted.
Note: This machine name appears as the source in QoS and alarm messages.
Override with
Defines a custom hostname, which appears as the source in QoS and alarm messages.
Messages Tab
The Messages tab is used to maintain a pool of alarm messages. These alarm messages are used across the monitoring profiles of the
e2e_appmon probe. By default, there are five alarm messages. You can add, edit, and delete messages to this message pool.
In the drop-down lists of the Alarm message setup grid, you can specify the alarm message to be issued for four different alarm conditions:
Alarm on start error
Alarm on interval breach
Alarm on process kill
Disable after (specific number of) errors and send a message
Alarm on unexpected returned value
The following options appear on right-clicking the message list:
Add message: This option enables you to define new alarm messages.
Message properties: This option enables you to edit one of the existing alarm messages.
Remove messages: This option enables you to delete alarm messages.
On selecting the Add message or Message properties option, the Message properties dialog appears.
The Message properties dialog contains the following fields:
Name
Defines a unique name of the message. This name is used to refer to the message from the profiles.
Default for
Specifies the alarm situations to be selected as the default alarm message for a specific type of alarm message.
Text
Defines the alarm message text. The following variables can be used:
$profile: profile name.
$failed: number of consecutive failures.
$sec: seconds delay on interval breach
$error: error message on start error.

$return - actual return code from last run
$expected_return - expected return code after successful run of the script.
Level
Specifies the severity level assigned to the alarm messages.
Subsystem
Defines the subsystem_ID of the alarms, the watcher generates. A string or the subsystem id is managed by the nas probe.
Variables Tab
The Variables tab lets you define variables that is used in the NimRecorder script. For example, if you are using a password in the script and
want to encrypt and protect the password being presented in the raw form. In such cases, define the password as a variable and select the Encry
pt option.
The Variables tab contains the following field:
Quality of Service Variables
The probe sends QoS messages on the NimRecorder script run time. The probe exports the QoS to the script also enables the script to
send QoS.
Three options Add variable, Variable properties, and Remove variable appear when you right-click the Variables list. On selecting the Add
variable or Variable properties option, the Variable properties dialog displays. The Variable properties dialog is used to add or modify the
variable properties.
The Variable properties dialog contains the following fields:
Variable name
Defines the variable name, which is unique for each variable.
Crypted
Encrypts the variable value and prevents the same being displayed in the human readable format.
Variable value
Defines a value to be assigned to the variable.
Scripts Tab
The Scripts tab allows you to create independent and deployable NimRecorder script packages. These packages can be deployed on the target
robot (similar to other probe packages) for monitoring. You can add more than one NimRecorder script and their dependent files to one
deployable package.
packages.
The Scripts tab contains the following fields:

Name
Defines the name of the script package to be made.
Version
Specifies the version number of the script package to be created.
Default: 1.0
Description
Defines a short description of the script package.
Scripts
Displays the list of scripts present in the path, which are specified in the ROB file directory field of the Setup tab. The list is available
only when the probe is activated. More than one script can be added to the package file.
The script execution settings are taken from the associated profile. If more than one profile is associated to a script, double-click the
script name and select the profile name.
The selected profile settings are used to execute the script. Double-click the profile name for editing the profile properties of the script
while selecting the profile.
If no profile is associated with a script, then such script displays in red color and default settings are used for its execution. You can
double-click the script name to define the script properties.
Path/Dependent Files
Allows you to browse the dependent files (for example, .bmp files) required to execute the script. You can select more than one file of the
same directory in one attempt. This field remembers the last navigation path.
Note: The script uses an absolute path of the dependent files.
Add Files
Allows you to add the path of dependent files in the Paths list-box.
Paths List Box
Displays the path list of dependent files to be included, while generating the package. You can right-click any of the dependent files and
can select the Delete to remove the selected file from the list.
Publish to Archive
Publishes the script package to the Archive directory of the primary hub.
ecometer_monitor (CA ecoMeter Monitoring)

The CA ecoMeter for UIM probe retrieves energy and power data from data center devices and provides the polling data to the CA UIM
messaging bus. The probe UI is used to view the QoS monitors and to configure alarms.
Each CA ecoMeter probe monitors devices as configured in the CA ecoMeter Administrator portlet. CA ecoMeter Administrator determines the
data center devices to monitor and the specific device data to collect.
More Information:
For complete instructions about deploying, accessing, and using the CA ecoMeter probe within the CA ecoMeter for UIM environment,
go to CA ecoMeter for UIM.
email_response (Email Response Monitoring)

The Email Response Monitoring probe tests Internet mail response by sending mail messages and reading a mailbox, using SMTP and
POP3/IMAP.
More information:
email_response (Email Response Monitoring) Release Notes
email_response Metrics
v1.4 email_response AC Configuration

The Email Response probe is configured by creating new monitoring profiles. You can configure the properties of performance object along with
its threshold values. You can also set the properties and conditions for generating alarms and the QoS messages.
Configure a Node
This procedure explains the process of configuring a particular section of a node. Each section within a node allows you to configure the
properties of the probe for monitoring the Internet mail response.
Follow these steps:
1. Select the appropriate navigation path.
2.
The specified section of the probe is configured. The probe is now ready to monitor the Internet mail response.
Alarm Thresholds
allow the probe to:
Manage Profiles
You can add a monitoring profile which is displayed as a child node under the Profiles node. You can then configure the profile to monitor the
Internet mail response.
Follow these steps:
1. Click the Options icon beside the Profiles node.
The profile is saved and you can configure the profile properties to monitor the Internet mail response.
v1.4 email_response AC GUI Reference
email_response Node
<Profile Name> Node
email_response Node
In the email_response node, you can view the details of the Email Response probe and can configure the log properties. You can also view the
details of the alarm messages that are defined on the Email Response probe and create a monitoring profile.
Navigation > email_response
Set or modify the following values based on your requirements:
email_response > Probe Information
This section allows you to view the name of the probe, probe version, start time of the probe and the vendor who created the probe.
email_response > Setup
This section allows you to configure the log properties of the probe.
Log Level: Specifies the depth of the details for which the log has to be maintained.
Default: 0-Fatal
Log Size (KB): Specifies the size of the file in which the internal log messages of the Email Response probe are saved.
Protocol debug information to log file: Provides the option to save the protocol debug information in the log file.
email_response > Messages
This section allows you to view the alarm messages that are defined on the Email Response probe. You can also view the properties of
the alarm messages.
Text: Identifies the content of the alarm message.
Level: Indicates the level of alarm which is raised.
Default for: Indicates the default message for the message name.
Subsystem: Identifies the subsystem id of the alarms generated by the Email Response probe.
i18nToken: Identifies the predefined alarms.
email_response > Options > Add new Profile
This section allows you to create and activate a monitoring profile.
Profile Name: Defines the name of the new profile.
Host Name: Defines the name of the mail server to which the test mail is directed.
Port: Specifies the port number that is used by the profile.
<Profile Name> Node

In the profile name node, you can configure the properties of the mail that is sent by the Email Response probe to the mail server. You can also
configure the time interval and alarm properties to monitor the mail server.
Note: This node is called profile name throughout this document as it is user-configurable.
Navigation: email_response > Profiles > profile name

profile name > Mailbox Definition
This section allows you to configure the properties of the mail server. You can also configure the security settings for communication
between the Email Response probe and the server.
Active: Triggers the activation of the profile.
Host Type: Specifies the type of host to be used by the Email Response probe while reading mails.
Default: imap
Host Name: Defines the name of the mail server to which the test mail is directed.
Username: Defines the user name of a valid mail account on the mail server.
Password: Defines the password of the valid mail account on the mail server.
Security: Specifies the options for communication between the Email Response probe and the mail server.
Default: Try Negotiate
Don't Validate Certificate: Indicates the validation of the certificate
profile name > Setup
This section allows you to configure the properties of the time interval of sending and receiving mail from the Email Response probe to
the mail server.
User name: Defines the user name of a valid mail account on the mail server.
Return email address: Defines the email address to which the lost mails are sent back.
Read Interval (Seconds): Specifies that after how much time the Email Response probe will receive the mail from the mail server.
Send Interval (Seconds): Specifies that after how much time the Email Response probe will send the test mail to the mail server.
Consider message as lost after a period (Seconds): Specifies the time within which the Email Response probe should receive the mail
from the mail server, otherwise the mail is considered as lost.
Bounce back emails: Triggers the Email Response probe to send the mails received from other mail probes back to them.
profile name > QoS for Mail Roundtrip
This section allows you to configure the QoS properties and set the conditions on mail round trip time interval for generating alarms.
Metric Type Id: Identifies a unique ID for the QoS.
Publish Data: Triggers the generation of QoS.
Default: Selected
Publish Alarms: Triggers the generation of alarms.
Default: Selected
Send alarm when mail roundtrip time exceeds: Specifies the round trip time exceeding which the alarm is raised.
Using Alarm Message: Specifies the message to be issued if the mail server exceeds the round trip time specified above.
Lost mail message: Specifies the alarm message which is issued if the mail server does not returns the mail.
profile name > QoS for Mail Send
This section allows you to configure the QoS properties for the mail which is sent to the mail server.
Metric Type Id: Identifies a unique ID for the QoS.

Default: Selected
Mail send error message: Specifies the message to be issued when the Email Response probe sends the mail to the mail server.
profile name > SMTP Setup
This section allows you to configure the properties of the SMTP mail server.
Send via SMTP server on: Defines the probe on which the mail is sent through the SMTP server.
Secure Send: Sends mail through SSL.
Don't Validate Certificate: Indicates the validation of the certificate.
Login to SMTP server with the following user and password: Activates the usage of the following user name and password.
Username: Defines the user name to login to the SMTP server.
Password: Defines the password to login to the SMTP server.
This node allows you to view and activate the details of the monitoring profile.
Navigation > email_response Node > Profile-profile name
Note: The profile appearing as a child node under the email_response node is user-configurable. Hence, the node is referred to as
Profile-profile name node throughout this document.
Profile-profile name > Profile Information
This section allows you to view and configure the profile information.
Profile Name: Defines the name of the monitoring profile.
Host Name: Defines the name of the host to which the test mail is directed.
v1.4 email_response IM GUI Reference

Using SMTP, the probe sends a mail-message to the mail-server. The probe retrieves the message back from the mail-server, using the POP3 or
IMAP protocols. It basically behaves like any mail client. A configurable polling-interval determines how often the active profiles are run. Each of
the profiles may be configured with an expected transaction time, and alarms are generated if these time-thresholds are exceeded.
The probe supports QoS (Quality of Service) messages based on its findings.
The probe is configured by double-clicking the line representing the probe in the Infrastructure Manager. This brings up the configuration tool for
the probe. The configuration user interface shows several tabs.
The Setup Tab

Log Level: Determines the detail level of messages being logged. This functionality is used for internal checking of the probe.
Log Size: Sets the size of the probes log file to which probe-internal log messages are written. By default, the size is 100 KB. When this
size is reached, the contents of the file are cleared.
Protocol debug information to log file: Saves the protocol debug information to the log file.
The Status Tab

All monitoring profiles configured are listed here. Normally you will have one entry for each mail user you want to send to. The selected profiles
suggests active profiles. You can easily enable/disable disable monitoring to a specific target by enabling/disabling the profile.
The following commands are available when you right click in the profile list:
Add profile
Creates a new profile and presents you with the Profile properties window described below.
Edit profile
Edits the selected profile.

Remove profile
Deletes the selected profile. You will be asked to confirm the deletion.
Profile Properties
This Profile properties dialog appears when you double-click a profile or by right-clicking in the profile list and selecting Add profile or Edit
profile.
Name: The name of the profile.
Active: Select the check box to activate the profile.
Mailbox definition
Host type: Either the imap or the pop3 (the probe uses one of these protocols when reading mails).
Host name: The name of the mail server to which the test mail will be directed.
User name: Login name with a valid mail account on the mail server.
Password: Password for a user with a valid mail account on the mail server.
Note: If the user logon name is different from an alias defined in Exchange General, you will be denied to log on.
Security: Provides you three choices for communication between the probe and the server:
Try negotiate: The probe asks what kind of encrypting services the server supports. If the server supports TLS, this will be used.
Otherwise no encryption will be used.
Force SSL: This option allows SSL communication between the probe and the server only. If SSL is not supported, the probe will
not communicate with the server at all.
No TLS: This option allows no TLS communication between the probe and the server, even if the server supports TLS.
Don't Validate Certificate: Select this check box if you do not want to validate the certificate.
There are four tabs, which are Setup, Alarm messages, Quality of Service messages, and SMTP setup.
Setup
The fields in the Setup tab are explained below:
Target User: The login users mail account on the mail server.
Return address (from field) on send: Specify the e-mail address of the sender of the test mail.
Mail Intervals: You must specify the interval for:
Read interval: How often the probe tries to read mail from the mail-server.
Send interval: How often the probe sends a mail to the mail-server.
Consider lost after: Maximum allowed roundtrip time before the mail (from it was sent until it was received again) is considered as
lost.
Bounce Messages: When this option is checked, the probe returns mail-messages send by other mail probes.
Alarm Messages
The fields in the Alarm Messages tab are explained below:

Send alarm when roundtrip time exceeds: With this option checked the alarm message specified in the Using alarm message field
(see below) will be issued if the mail roundtrip time exceeds the specified threshold.
Using alarm message: The alarm message to be used when the mail roundtrip time exceeds the threshold specified above.
Mail error message: The alarm message to be used when unable to send mail to the specified user.
Lost mail message: The alarm message to be used when the mail is not returned.
The fields in the Quality of Service Messages tab are explained below:
Mail send time: When this option is checked, a QoS message with the mail send time (ms) is generated each time a mail-message is
sent.
Mail roundtrip time: When this option is checked, a QoS message with the mail roundtrip time (ms) is generated on each mail sent.
SMTP Setup
The fields in the SMTP Setup tab are explained below:

Send via SMTP Server on: The probe posts mails via a SMTP server.
SMTP Server: Specify the name of the SMTP server.
SMTP Port: SMTP port to be used.
Secure send: Allows to use SSL when sending mail from the probe to the server.
User name: Valid SMTP user name.
Password: SMTP password.
Note: The SMTP User name and Password fields are activated when you select Login to SMTP using the following user name and
password check box.
The Messages Tab

Contains the list of alarm messages defined. The messages can be referred to in specific profiles.
The following commands are available when you right-click in the message list:
Add message
Creates a new message and presents you with the Message properties window described below.
Message properties
Edits the selected message.
Remove message
Deletes the selected message. You will be asked to confirm the deletion.
The fields in the above dialog box are explained below:
Name: Each message must be given a unique name. This name is used to refer to the message from the profiles.
Alarm situation: The message can be made the default message for a particular alarm situation. You must leave this field empty if
another message is to be the default.
Text: The alarm message text. Variable expansion is supported and the following variables are available:
profile
mail_to
used
threshold
diff
Level: The severity level assigned to any of the alarm messages.
Subsystem: The subsystem_ID of alarms generated by this watcher. A string or an id managed by the nas.
email_response Metrics
The following table describes the QoS metrics that can be configured using the Email Response Monitoring (email_response) probe.
Monitor Name
Units
Description
Version
QOS_NIM_INTERNET_MAIL_ROUNDTRIP
Milliseconds
Internet Mail Roundtrip Time
1.0
QOS_NIM_INTERNET_MAIL_SEND
Milliseconds
Internet Mail Send Time
1.0
emailgtw (Email Gateway Monitoring)

The Email Gateway Monitoring (emailgtw) probe allows you to receive email notifications when a problem in the system requires action. The
Email Gateway converts alarms into emails according to the configurations defined in the NAS server. The probe collects these emails at the
specified interval and sends them to the email addresses defined in the profiles. The emails are sent based on predefined criteria for alarms, such
as, severity, origin, and time.
Note: The emailgtw probe does not generate any QoS metrics. Therefore, there are no probe checkpoint metrics to be configured for
this probe.
More information
emailgtw (Email Gateway Monitoring) Release Notes
emailgtw AC Configuration
The Email Gateway Monitoring (emailgtw) probe converts alarms into emails according to the configurations defined in the Alarm Server (nas). At
the specified interval, the probe sends these emails to the recipients defined in the profiles.
The following diagram outlines the process to configure the probe to send emails for alarms.
Contents
Manage Server Credentials
Create a Profile
Set Outlook Data File for Online Mode
Verify that required hardware, and software information is available before you configure the probe. For more information, see emailgtw (Email
Gateway Monitoring) Release Notes.

You can configure the general properties of the probe to specify the log and report interval details, backup properties, and format of the email. The
probe uses these details to send emails when NAS generates alarms. You can also define the alarm settings when the email server
becomes inaccessible.
Follow these steps:
1. Navigate to the emailgtw > General Configuration section and specify the following field values:
Log level: specifies the level of information that is written in the log file.
Default: 0-Fatal
when debugging.
Log size (KB): specifies the maximum size of the probe log file in kilobytes. When this size is reached, new log file entries are added
and the older entries are deleted.
Default: 100
Report Interval: specifies the interval after which the probe checks whether an alarm report file exists. If a file is found and the Repor
t Recipient option is selected in the profile, it is sent to the recipients defined in the profile.
2. Go to the Email Message section and specify the following field values:
From Address: defines the email address from which the alarm notification is sent to the specified recipients.
Default: emailgtw@nimsoft.com
Subject: defines the subject of the alarm notification email. You can use only 100 characters in this field.
Note: To increase the subject length, you can add a subject_length parameter in the raw configure section of the probe.
The value must be an integer and the length can only be increased up to 998 characters. If the subject length exceeds 998
characters, then the message is rejected.
(Optional) Message Format: specifies the formatting option for the alarm notification email.
Default: HTML
Template: defines the format of the emails. The template is template.html if HTML is selected in the Message Format field. The
template changes to template.txt if Text is selected in the Message Format field. Both these template files are located in the <CA
UIM Installation Directory>/Probes/gateways/emailgtw directory.
Default: template.html
(Optional) Group Recipients: sends a single group email to all the recipients in the group. All the recipients appear in the To line in
the email.
Email on Assignment: converts assigned alarms into emails and sends to the email addresses defined in the profiles.
Note: For some reason, if the emailgtw probe is not available, it cannot receive and handle the assigned alarms. To avoid
missing these alarms during this duration, perform the following tasks on the hub probe:
a. Set up a queue under the Queues tab.
b. Type attach and enter the subject as EMAIL, alarm_assign.
If the emailgtw probe and the hub probe are on different robots, the attach queue must be created on the hub of the
primary robot.
Locale: converts Japanese or Simplified Chinese text present in emails into readable format. The emails with Japanese or Simplified
Chinese text display correctly only on the Microsoft Outlook client.
Default: None
3. (Optional) Go to the Alarm Settings section to configure the following settings for situations when the email server is inaccessible.
Send Alarm: sends an alarm if the probe fails to access the email server.
Default: Selected
Subsystem: defines the subsystem originating the alarm.
Default: 1.1.12, which translates to Mail in the Subsystems section of the nas probe.
Severity: defines the severity level of the alarm
Default: major
4. (Optional) Go to the Backup Email section to send a blind carbon copy (BCC) of all the alarm emails. Specify the following field values:
Send Backup Email: enables you to monitor the emails that are sent by the emailgtw probe. All the emails that are sent are copied
(BCC) to this email address.
Backup Email Address: defines the email address to which the emails are sent.
Default: Disabled

Configure the probe by providing the server details with the user name and password. The probe uses these credentials to access server and
send emails. The emailgtw probe supports SMTP and Exchange servers to send emails on a Windows robot. However, you can configure only
one server in the probe at a time. For robots on other operating systems, you can only use the SMTP server.
Configure SMTP Server

Use this procedure if you want to use an SMTP server to send emails.
Note: SMTP server selection does not support IPv6 format. You can create connection to the email server using the host name.
Follow these steps:

1. Navigate to the emailgtw > Mail Server node.
2. Select SMTP from the Server Type drop-down.
3. Specify the following email server details.
Primary Mail Server: defines the main SMTP server that is used to send emails. Append ":<portnumber>" after the hostname or
IP address if you want to specify a non-default port number for the SMTP server.
Example: smtp.yourserver.com:26
Username and Password: specifies the login credentials for the SMTP server authentication.
Secondary Mail Server: defines the secondary SMTP server to be used when the primary SMTP server fails.
4. (Optional) Select Ignore TLS if you do not want the probe to attempt a Transport Layer Security (TLS) connection with the primary and
secondary email server. This feature is required because some email servers announce TLS capability even if it is not present, due to a
missing certificate.
Note: The Linux robot where the probe is deployed must have OpenSSL certificate installed to use the TLS functionality to
connect to the SMTP server.
5. Click Actions > Test Server Settings to verify the email server response.
Configure Exchange Server
You can use an Exchange server on a Windows robot to send emails. You can create a MAPI profile to enable and run the probe using the
Exchange server. A test user must already exist in the Exchange server before you configure the probe. The data file must be in online mode in
the Outlook settings. For more information, see the Set Data File for Online Mode section.
You can use either of the following options:
Pre-configured profile: Use this option when you want to use the profile that is created with the Outlook configuration on your system.
User and server: Use this option when you want to use some other user credentials.
Follow these steps:
1. Navigate to emailgtw > Mail Server node.
2. Select Exchange from the Server Type drop-down.
3. Select either Pre-configured profile or User and server as the Config Type.
4. Specify the following details of the selected configuration:
Profile Name or Server name: specifies the pre-configured Outlook profile name when you select Pre-configured profile as the Con
fig Type.
The field changes to Server Name and requires the Exchange server name when you select User and server as the Config Type.
Domain Name: defines the domain name of the Exchange server.
Username: defines the username for the Exchange server authentication.
Password: defines the password for the Exchange server authentication.
5. Click Actions > Test Server Settings to verify the mailbox availability.
When the probe starts, the probe connects to the defined Exchange server with the given user credentials. These MAPI profiles are ALWAYS
removed when the probe stops or deactivates.
Create a Profile
Create one or more profiles to define the recipients. The probe sends the alarm converted emails to the email addresses defined in the profiles, at
the specified interval.
Follow these steps:
1. Navigate to the emailgtw > Profiles node.
The Add Profile dialog displays.
3. Specify the following field values:
Profile Name: name of the profile.
Email Address(es): defines the email address of the recipient. You can specify multiple recipients, separated with a comma, if the Gr
oup Recipients option is selected in the emailgtw > Email Message section. If there are multiple recipients in a profile, each email is
sent to all recipients in the To field.
Note: For Exchange server, the probe supports more than 1024 characters if Group Recipients check box is selected in
the Email Message section. However, for SMTP server, the probe supports up to 1024 characters.
Report Recipients: sends the alarm report as an email at regular intervals, as defined in the Report Interval field in emailgtw node.
Note: The auto-operator in the NAS sends a report email from the emailgtw probe containing all alarms when the following
conditions are met. The email is sent to the recipient defined in the profile at the specified Report interval.
The recipient field in the auto-operator in the NAS is blank.
The Report Recipient option is selected for the profile.
(Optional) Subject: specifies the subject of the emails. The subject defined here overrides the Subject defined in the emailgtw node.
(Optional) HTML Template: specifies the template file that defines the email format. The template defined here overrides the Templat
e defined in the emailgtw node.
Note: To delete a profile, click the Options (icon) on the Profile Name node and select Delete Profile, and Save the configuration.

To enable and run the probe using Exchange server, the data file must be in online mode in Outlook.
Follow these steps:
1. Open Microsoft Outlook.
2. Select Tool > Account Settings.
3. Click the E-mail tab and double-click the required email in the tab.
4. Clear the Use Cached Exchange Mode check box in the Change E-mail Account dialog.
The Data Files for the email is now set to online mode.
emailgtw IM Configuration
Contents
Create a Profile
Create or Edit a Template

Follow these steps:
1. Open the Properties dialog from the toolbar and specify the following field values.
Log-level: specifies the level of information that is written in the log file.
Default: Less
when debugging.
Log size: specifies the maximum size of the probe log file in kilobytes. When this size is reached, new log file entries are added and
the older entries are deleted.
Default: 100 Kb
Default: 300
primary robot.
(Optional) Use HTML Format: allows you to specify HTML format for the emails that are sent. If you do not select this option, the
emails are formatted in the .txt format.
Default: Selected
(Optional) Group Recipients: sends a single group email to all the recipients in the group.
2. Specify the following field values of the emails:
From: specifies the email address from where the probe sends the email.
Subject: specifies the subject of the alarm notification emails. You can only enter 100 characters in the subject.
Template: specifies the format in which the email messages are formatted - either the template.html file or the template.txt file.
These files are located in the <CA UIM Installation Directory>/Probes/gateways/emailgtw directory.
This template is the default template for all profiles unless another template is specified in the Profile properties dialog. You can
create a new template or edit the existing template. For more information, see the Create or Edit a Template section.
3. (Optional) Select Backup Email Settings to send a blind carbon copy (BCC) of all the alarm emails to the specified Backup Email
Address. This functionality enables you to monitor the emails that are sent by the probe.
4. (Optional) Select Alarm Settingsto configure the following settings for situations where the email server is inaccessible:
Severity: defines the severity level of the alarm.
Default: major
5. (Optional) Select the Locale value to convert Japanese or Simplified Chinese text present in emails into readable format. The emails with
Japanese or Simplified Chinese text display correctly only on the Microsoft Outlook client.
Default: None


Follow these steps:
1. Open the Properties dialog.
2. Select SMTP in the Server Selection box.
3. Navigate to the SMTP tab and specify the following email server details.
Test button: allows you to verify the email server response. A green indicator means OK and a red indicator indicates that the
server did not respond.
5. Click the Test button to verify the email server response.

the Outlook settings. For more information, see the Set Outlook Data File for Online Mode section. You can use either of the following options:
User and Server: Use this option when you want to use some other user credentials.
Follow these steps:
2. Select Exchange in the Server Selection box.
3. Navigate to the Exchange tab.
4. Select either Pre-configured profile or User and server option.
Profile Name or Server name:
Define the pre-configured Outlook profile name if you select Pre-configured profile.
Note: This profile must exist and configured in Outlook before using in the probe. To find the profile name, navigate to
the Control Panel > Mail dialog.
Define the name of the Exchange server if you select User and server.
Domain Name: name of the Exchange server domain
Name: a valid user name of the Exchange server.
Password: a valid password for the specified user.

6. Click the Test button to verify the email server response. A green indicator means OK and a red indicator indicates that the server did not
respond.
When the probe starts, the probe connects to the defined Exchange server with the provided user credentials. These MAPI profiles are ALWAYS
Create a Profile
Follow these steps:
1. Click the Add profile button in the toolbar.
Name: name of the profile.
Email: defines the email address of the recipient. You can specify multiple recipients, separated with a comma, if the Group
Recipients option is selected in the Properties > General tab. If there are multiple recipients in a profile, each email is sent to all
recipients in the To field.
Subject: specifies the subject of the emails. The subject defined here overrides the Subject defined in the Properties > General tab.
Report recipient: sends the alarm report as an email at regular intervals, as defined in the Report Interval field in emailgtw node.
HTML Template: specifies the template file that defines the email format. The template defined here overrides the Template defined
in the Properties > General tab.

You can define the email format and save it as a template on your local drive. The default location for the template is <CA UIM Installation
Directory>/Probes/Gateways/emailgtw. The template can either be created from the General tab in the Properties dialog or the Add Profiles dial
og.
Follow these steps:
2. Define a unique name in the Template field with either .html or .txt extension.
3. Click Edit.
A warning informs that the file does not exist.
4. Click OK.
An empty file launches in an editor.
5. Create the template and exit the editor.
Similarly, specify an existing template name in the Template field to edit it.
Variable Expansion
You can edit the default template.html or you can create specific templates for a profile. In the template editor or in the Subject field of the Prope
rties dialog, press the '$' key. A drop-down appears with a list of available variables. The following variables are available for use in the subject
and html templates:
$level: the severity level of the alarm.
$level_exp: the name of that severity level, for example, critical.
$level_col: the color code of that severity level, for example, critical = #FF0000.
$prevlevel: the previous severity level of the alarm.
$prevlevel_exp: the name of that severity level, for example, critical.
$prevlevel_col: the color code of that severity level, for example, critical = #FF0000.
$subsys: the alarm subsystem.
$message: the message text.
$nimid: the message ID.
$nimts: the message timestamp, when it was originally sent.
$nimts_exp: the readable form of $nimts.
$source: the IP address of the system that sent the alarm.
$hub: the Hub the robot belongs to.
$robot: the name of the Robot that sent the alarm.
$origin: the system name of the hub in which the robot is present.
$domain: the name of Domain the Robot is in.
$prid: the probe ID.
$hostname: the hostname of the system that sent the alarm.
$hostname_strip: the hostname of the system that sent the alarm without the domain portion (if present).
$sid: the subsystem ID in the NAS.
$supp_key: the suppression key (often contains the checkpoint).
$arrival: the timestamp when the NAS received the alarm.
$arrival_exp: the human readable form of $arrival.
$aots: the timestamp when the NAS AO last checked the alarm.
$aots_exp: the human readable form of $aots.
$supptime: the timestamp of the last suppression of this message.
$supptime_exp: the readable form of $supptime.
$suppcount: the number of times this alarm has been suppressed.
$exported_by: the address of the NAS which exported this message.
$exported_type: the type of export.
$assigned_at: the timestamp when the alarm was assigned to a user.
$assigned_at_exp: the readable form of $assigned_at.
$assigned_to: the user which the alarm was assigned to.
$assigned_by: the user that assigned the alarm.
$ao_argument: the arguments set by the NAS auto-operator profile.
$tz_offset: sending system timezone offset in seconds compared to UTC.
$nimts_tzexp: the readable form of $nimts offset for sending robots timezone giving the local time on the sending robot.
$arrival_tzexp: the readable form of $arrival offset for sending robots timezone giving the local time on the sending robot.
$aots_tzexp: the readable form of $aots offset for sending robots timezone giving the local time on the sending robot.
$supptime_tzexp: the readable form of $supptime offset for sending robots timezone giving the local time on the sending robot.
$assigned_at_tzexp: the readable form of $assigned_at offset for sending robots timezone giving the local time on the sending robot.
$user_tag1
$user_tag2: user-defined tags that are used to define identification properties for computers in CA UIM. The tags are defined under Setu
p > Misc in the configuration dialog of the controller probe.

Follow these steps:
emailgtw Version 2.7

This section contains documentation for versions 2.73 and earlier of the emailgtw probe:
v2.7 emailgtw AC Configuration
v2.7 emailgtw IM Configuration
v2.7 emailgtw AC Configuration

Contents
Create a Profile

Follow these steps:
1. Navigate to the emailgtw > General Configuration section and specify the following field values:
Log level: specifies the level of information that is written in the log file.
Default: 0-Fatal
when debugging.
Log size (KB): specifies the maximum size of the probe log file in kilobytes. When this size is reached, new log file entries are added
and the older entries are deleted.
Default: 100
2. Go to the Email Message section and specify the following field values:
From Address: defines the email address from which the alarm notification is sent to the specified recipients.
Subject: defines the subject of the alarm notification email. You can use only 100 characters in this field.
(Optional) Message Format: specifies the formatting option for the alarm notification email.
Default: HTML
Template: defines the format of the emails. The template is template.html if HTML is selected in the Message Format field. The
template changes to template.txt if Text is selected in the Message Format field. Both these template files are located in the <CA
UIM Installation Directory>/Probes/gateways/emailgtw directory.
Default: template.html
(Optional) Group Recipients: sends a single group email to all the recipients in the group. All the recipients appear in the To line in
the email.
primary robot.
Locale: converts Japanese or Simplified Chinese text present in emails into readable format. The emails with Japanese or Simplified
Chinese text display correctly only on the Microsoft Outlook client.
Default: None
3. (Optional) Go to the Alarm Settings section to configure the following settings for situations when the email server is inaccessible.
Send Alarm: sends an alarm if the probe fails to access the email server.
Default: Selected
Severity: defines the severity level of the alarm
Default: major
4. (Optional) Go to the Backup Email section to send a blind carbon copy (BCC) of all the alarm emails. Specify the following field values:
Send Backup Email: enables you to monitor the emails that are sent by the emailgtw probe. All the emails that are sent are copied
(BCC) to this email address.
Backup Email Address: defines the email address to which the emails are sent.
Default: Disabled

Note: SMTP server selection does not support IPv6 format. You can create connection to the email server using the host name.
Follow these steps:

1. Navigate to the emailgtw > Mail Server node.
2. Select SMTP from the Server Type drop-down.
3. Specify the following email server details.
5. Click Actions > Test Server Settings to verify the email server response.
the Outlook settings. For more information, see the Set Data File for Online Mode section.
You can use either of the following options:
User and server: Use this option when you want to use some other user credentials.
Follow these steps:
1. Navigate to emailgtw > Mail Server node.
2. Select Exchange from the Server Type drop-down.
3. Select either Pre-configured profile or User and server as the Config Type.
Profile Name or Server name: specifies the pre-configured Outlook profile name when you select Pre-configured profile as the Con
fig Type.
The field changes to Server Name and requires the Exchange server name when you select User and server as the Config Type.
Domain Name: defines the domain name of the Exchange server.
Username: defines the username for the Exchange server authentication.
Password: defines the password for the Exchange server authentication.
5. Click Actions > Test Server Settings to verify the mailbox availability.
When the probe starts, the probe connects to the defined Exchange server with the given user credentials. These MAPI profiles are ALWAYS
Create a Profile
Follow these steps:
1. Navigate to the emailgtw > Profiles node.
Profile Name: name of the profile.
Email Address(es): defines the email address of the recipient. You can specify multiple recipients, separated with a comma, if the Gr
oup Recipients option is selected in the emailgtw > Email Message section. If there are multiple recipients in a profile, each email is
sent to all recipients in the To field.
Report Recipients: sends the alarm report as an email at regular intervals, as defined in the Report Interval field in emailgtw node.

(Optional) Subject: specifies the subject of the emails. The subject defined here overrides the Subject defined in the emailgtw node.
(Optional) HTML Template: specifies the template file that defines the email format. The template defined here overrides the Templat
e defined in the emailgtw node.
Note: To delete a profile, click the Options (icon) on the Profile Name node and select Delete Profile, and Save the configuration.

Follow these steps:
v2.7 emailgtw IM Configuration
Contents
Create a Profile

Follow these steps:
1. Open the Properties dialog from the toolbar and specify the following field values.
Log-level: specifies the level of information that is written in the log file.
Default: Less
when debugging.
Log size: specifies the maximum size of the probe log file in kilobytes. When this size is reached, new log file entries are added and
the older entries are deleted.
Default: 100 Kb
Default: 300
primary robot.
(Optional) Use HTML Format: allows you to specify HTML format for the emails that are sent. If you do not select this option, the
emails are formatted in the .txt format.
Default: Selected
(Optional) Group Recipients: sends a single group email to all the recipients in the group.
2. Specify the following field values of the emails:
From: specifies the email address from where the probe sends the email.
Subject: specifies the subject of the alarm notification emails. You can only enter 100 characters in the subject.
Template: specifies the format in which the email messages are formatted - either the template.html file or the template.txt file.
These files are located in the <CA UIM Installation Directory>/Probes/gateways/emailgtw directory.
This template is the default template for all profiles unless another template is specified in the Profile properties dialog. You can
create a new template or edit the existing template. For more information, see the Create or Edit a Template section.
3. (Optional) Select Backup Email Settings to send a blind carbon copy (BCC) of all the alarm emails to the specified Backup Email
Address. This functionality enables you to monitor the emails that are sent by the probe.
4. (Optional) Select Alarm Settingsto configure the following settings for situations where the email server is inaccessible:
Severity: defines the severity level of the alarm.
Default: major
5. (Optional) Select the Locale value to convert Japanese or Simplified Chinese text present in emails into readable format. The emails with
Japanese or Simplified Chinese text display correctly only on the Microsoft Outlook client.
Default: None

Follow these steps:
2. Select SMTP in the Server Selection box.
3. Navigate to the SMTP tab and specify the following email server details.
Test button: allows you to verify the email server response. A green indicator means OK and a red indicator indicates that the
server did not respond.
5. Click the Test button to verify the email server response.

the Outlook settings. For more information, see the Set Outlook Data File for Online Mode section. You can use either of the following options:
User and Server: Use this option when you want to use some other user credentials.
Follow these steps:
2. Select Exchange in the Server Selection box.
3. Navigate to the Exchange tab.
4. Select either Pre-configured profile or User and server option.
Profile Name or Server name:
Define the pre-configured Outlook profile name if you select Pre-configured profile.
Note: This profile must exist and configured in Outlook before using in the probe. To find the profile name, navigate to
the Control Panel > Mail dialog.
Define the name of the Exchange server if you select User and server.
Domain Name: name of the Exchange server domain
Name: a valid user name of the Exchange server.
Password: a valid password for the specified user.
6. Click the Test button to verify the email server response. A green indicator means OK and a red indicator indicates that the server did not
respond.
When the probe starts, the probe connects to the defined Exchange server with the provided user credentials. These MAPI profiles are ALWAYS
Create a Profile
Follow these steps:
1. Click the Add profile button in the toolbar.
Name: name of the profile.
Email: defines the email address of the recipient. You can specify multiple recipients, separated with a comma, if the Group
Recipients option is selected in the Properties > General tab. If there are multiple recipients in a profile, each email is sent to all
recipients in the To field.
Subject: specifies the subject of the emails. The subject defined here overrides the Subject defined in the Properties > General tab.
Report recipient: sends the alarm report as an email at regular intervals, as defined in the Report Interval field in emailgtw node.
HTML Template: specifies the template file that defines the email format. The template defined here overrides the Template defined
in the Properties > General tab.

You can define the email format and save it as a template on your local drive. The default location for the template is <CA UIM Installation
Directory>/Probes/Gateways/emailgtw. The template can either be created from the General tab in the Properties dialog or the Add Profiles dial
og.
Follow these steps:
2. Define a unique name in the Template field with either .html or .txt extension.
3. Click Edit.
A warning informs that the file does not exist.
4. Click OK.
An empty file launches in an editor.
5. Create the template and exit the editor.
Similarly, specify an existing template name in the Template field to edit it.
Variable Expansion
You can edit the default template.html or you can create specific templates for a profile. In the template editor or in the Subject field of the Prope
rties dialog, press the '$' key. A drop-down appears with a list of available variables. The following variables are available for use in the subject
and html templates:
$level: the severity level of the alarm.

$level_exp: the name of that severity level, for example, critical.
$level_col: the color code of that severity level, for example, critical = #FF0000.
$prevlevel: the previous severity level of the alarm.
$prevlevel_exp: the name of that severity level, for example, critical.
$prevlevel_col: the color code of that severity level, for example, critical = #FF0000.
$subsys: the alarm subsystem.
$message: the message text.
$nimid: the message ID.
$nimts: the message timestamp, when it was originally sent.
$nimts_exp: the readable form of $nimts.
$source: the IP address of the system that sent the alarm.
$hub: the Hub the robot belongs to.
$robot: the name of the Robot that sent the alarm.
$origin: the system name of the hub in which the robot is present.
$domain: the name of Domain the Robot is in.
$prid: the probe ID.
$hostname: the hostname of the system that sent the alarm.
$hostname_strip: the hostname of the system that sent the alarm without the domain portion (if present).
$sid: the subsystem ID in the NAS.
$supp_key: the suppression key (often contains the checkpoint).
$arrival: the timestamp when the NAS received the alarm.
$arrival_exp: the human readable form of $arrival.
$aots: the timestamp when the NAS AO last checked the alarm.
$aots_exp: the human readable form of $aots.
$supptime: the timestamp of the last suppression of this message.
$supptime_exp: the readable form of $supptime.
$suppcount: the number of times this alarm has been suppressed.
$exported_by: the address of the NAS which exported this message.
$exported_type: the type of export.
$assigned_at: the timestamp when the alarm was assigned to a user.
$assigned_at_exp: the readable form of $assigned_at.
$assigned_to: the user which the alarm was assigned to.
$assigned_by: the user that assigned the alarm.
$ao_argument: the arguments set by the NAS auto-operator profile.
$tz_offset: sending system timezone offset in seconds compared to UTC.
$nimts_tzexp: the readable form of $nimts offset for sending robots timezone giving the local time on the sending robot.
$arrival_tzexp: the readable form of $arrival offset for sending robots timezone giving the local time on the sending robot.
$aots_tzexp: the readable form of $aots offset for sending robots timezone giving the local time on the sending robot.
$supptime_tzexp: the readable form of $supptime offset for sending robots timezone giving the local time on the sending robot.
$assigned_at_tzexp: the readable form of $assigned_at offset for sending robots timezone giving the local time on the sending robot.
$user_tag1
$user_tag2: user-defined tags that are used to define identification properties for computers in CA UIM. The tags are defined under Setu
p > Misc in the configuration dialog of the controller probe.

Follow these steps:

ews_response (Microsoft Exchange Server Response Monitoring)

The Microsoft Exchange Server Response Monitoring (ews_response) probe tests the performance of your Microsoft Exchange Server
connection by sending and receiving test emails using webmail. These test emails reflect the actual end-user experience of the Exchange Web
Server.
The probe can also return email from another instance of the probe for end-to-end monitoring of round-trip time of the email. The probe measures
email round-trip for internal and external email accounts and generates QoS. You can configure alarms when unknown emails are detected in the
mailbox and the threshold value of the email round-trip time is breached.
The probe supports Exchange Server 2010, 2010 SP1, 2010 SP2, 2010 SP3, and 2013 SP1.
Note: The probe only supports basic and NTLM (NT LAN Manager) authentication.
More Information:
ews_response (Microsoft Exchange Server Response Monitoring) Release Notes
v2.0 ews_response AC Configuration

This article describes the configuration concepts and procedures for setting up the Microsoft Exchange Server Response (ews_response) probe.
You can add profiles for each Exchange Server user. These monitoring profiles define how the test email is sent and returned. These profiles also
specify the alarm and QoS properties.
The following diagram outlines the process to configure the probe to monitor an Exchange Server.
Contents
Configure Global Values
Add Server Details
Create and Configure Profiles
Alarm Thresholds
information, see ews_response (Microsoft Exchange Server Response Monitoring) Release Notes.

You can configure the general properties of the probe to set up global values. You can use these global values across all user accounts
configured in the probe. The values (except Log Level) can be overridden for different user accounts. You can also use the default values
specified for these fields.
Follow these steps, as needed:
1. Click the ews_response node in the navigation pane.
2. Specify the level of details that are written to the log file in the Log Level field of the General Configuration section.
Default: 0 - Fatal
3. Specify the time interval between each instance when the probe checks the inbox in Check Every Second. You can reduce this interval
to generate alarms faster (as next interval takes lesser time) but it increases the load on the Exchange Server. You can also increase this
interval to reduce the load on the Exchange Server but it generates alarms later (as next interval takes more time).
Default: 15
Note: The probe deletes the email after scanning the inbox of the user to save the inbox storage space. Each test email is
deleted as soon it is found and the QoS value is calculated.
4. Select Bounce Nimsoft Test Mail from other sources back to Sender to enable the Exchange Client to return incoming test emails to
the sender. You can select this option if you want to monitor the round-trip time between two independent user accounts. This provides a
more realistic response time. The test email is sent from an inbox to itself to calculate the round-trip time.
Note: Test email messages can be received by a user account from another mailbox that is monitored by a separate instance
of the probe. These emails are sent back if this checkbox is selected.
5. Specify the number of messages which are scanned in Stop reading inbox when other than Nimsoft Test Mails Found before
stopping the probe to scan the inbox. An active user can receive many non-test emails. This setting allows you to stop the probe from
scanning the inbox if it does not find the actual test email, thus reducing server load.
Default: 30
6. Select Publish Alarms in the Send Alarm on Unexpected Mail section to generate alarms if emails from other sources appear. An
active user can have other email messages in the inbox. An active user can have other email messages in the inbox. The alarm notifies
you that the account has received a non-test email, if this option is selected.
Add Server Details

You must add the Exchange Server details and the user credentials to connect to the server. The user must have an account that can access the
server. These values can be modified later in the User Name node.
Follow these steps:
1. Click Options (icon) next to the ews_response node in the navigation pane.
2. Click Add New User.
The Add New User window appears and Active is selected by default.
3. Specify the User Name used to access the server.

4. Specify the Server Name to be monitored.
Note: Server name must ensure the following requirements:

Protocol of the exchange web service. For example, http://www.example.com/ or https://www.example.com/. If not
specified, by default it is https://.
Sub-directories must not be included. For example, the Server Name for the webmail address https://mail.example.com/o
wa is https://mail.example.com/. Sub-directories like owa must be removed.
5. Enter the Password for the user to access the server.

6. Select the version of the Exchange server from the Server Version drop-down list.
7. Select Use Global Settings in the applicable fields in the Advanced Inbox Settings section to use the settings that are specified in the
ews_response node.
You can also select Override to specify user-account specific values, as follows:
Specify the time interval between each instance when the probe checks the inbox in Inbox Check Time. You can reduce this interval
to generate alarms faster (as next interval takes lesser time) but it increases the load on the Exchange Server. You can also increase
this interval to reduce the load on the Exchange Server but it generates alarms later (as next interval takes more time).
Default: 15
Select Bounce Nimsoft Test Mail from other sources back to Sender to enable the Exchange Client to return incoming test emails
to the sender. You can select this option if you want to monitor the round-trip time between two independent user accounts. This
process provides a more realistic response time. The test email is sent from an inbox to itself to calculate the round-trip time.
Note: Test email messages can be received by a user account from another mailbox that is monitored by a separate
instance of the probe. These emails are sent back if this checkbox is selected.
Specify the number of messages which are scanned in Advanced Inbox Mails before stopping the probe to scan the inbox. An active
user can receive many non-test emails. This setting allows you to stop the probe from scanning the inbox if it does not find the actual
test email, thus reducing server load.
Default: 30
Select Inbox Send Alarm to generate alarms if emails from other sources appear. An active user can have other email messages in
the inbox. An active user can have other email messages in the inbox. The alarm notifies you that the account has received a non-test
email, if this option is selected.
8. Click Submit.
The user is created under the ews_response node.

You must create and configure monitoring profiles to monitor the Exchange Server. You can define how a test email message is sent using a
profile. You can also specify the alarm and QoS properties.
Follow these steps:
1. Click the Options (icon) next to the User Name node in the navigation pane.
The Add New Profile window appears and Active is selected by default.
4. Click Submit.
The new profile is created under the User Name node.
5.
5. Specify the target email address where the test email is sent in the Profile General Parameters section of the Profile Name node.
The profile is created and configured. You can configure the QoS Messages on mail sent and round-trip time monitors in the Profile
Name node.
Alarm Thresholds
allow the probe to:
v2.0 ews_response AC GUI Reference

The Microsoft Exchange Server Response Monitoring probe is configured to monitor the Microsoft Exchange Server response. This article
describes the configuration GUI for the ews_response probe.
Contents
ews_response Node
User-<User Name> Node
<Server Name> Node
<User Name> Node
<Profile Name> Node
ews_response Node
This section contains the configuration details specific to the ews_response probe. In this node, you can view the probe information and can set
up the global properties of the probe.
Navigation: ews_response
ews_response > Probe Information
ews_response > General Configuration
This section lets you configure the global properties of the probe.
Default: 0 - Fatal
Check Every Second: specifies the interval between each cycle when the inbox is read. The inbox is only read when there are
outstanding emails. You can reduce this interval to generate alarms faster (as next interval takes lesser time) but it increases the load on
the Exchange Server. You can also increase this interval to reduce the load on the Exchange Server but it generates alarms later (as
next interval takes more time).
Default: 15
Bounce Nimsoft Test Mail from other sources back to Sender: enables the Exchange client response to return the incoming test email to
Note: Test emails can be received by a user account from another mailbox that is monitored by a separate instance of the
probe. These emails are sent back if this checkbox is selected.
Stop reading inbox when other than Nimsoft Test Mails Found: specifies the number of emails which are scanned before stopping the
probe to scan the inbox. An active user can receive many non-test emails. This setting allows you to stop the probe from scanning the
inbox if it does not find the actual test email, thus reducing server load.
Default: 30
ews_response > Send Alarm on Unexpected Mail
This section lets you generate alarms if other emails are present in the mailbox. An active user can have other emails in the inbox. An active user
can have other emails in the inbox. The alarm notifies you that the account has received a non-test email, if this option is selected.
ews_response > Message Pool
This section lets you view a particular alarm message in detail.
Message Name: identifies the unique name of the message. This name is used to refer to the message from the profiles.
Text: identifies the alarm message text. Use following variables for including run-time information in the alarm message text:
profile
mail_to
used
threshold
diff
Level: identifies the alarm message severity.
Default for: identifies the default message name.
i18n Token: identifies the predefined alarms fetched from the database.
ews_response > Options (icon) > Add New User
This option opens the Add New User window. This window lets you add an Exchange Server user with a valid user name, password, and the
name of the Exchange Server to log in.
The fields in this window are as follows:
Active: activates or deactivates the Exchange Server user.
User Name: specifies the username of the user credentials to access the Exchange Server.
Server Name: specifies the name of the Exchange Server.

Sub-directories must not be included. For example, the Server Name for the webmail address https://mail.example.com/o
Password: specifies the password of the user credentials to access the Exchange Server
Exchange Version: specifies the version of the Exchange Server.

This node lets you view the Exchange Server user information.
Navigation: ews_response > User-User Name

The fields in this node are as follows:
User Info
This section lets you configure the Exchange Server user information. The fields in this section are the same as the Add New User
window accessible from ews_response > Options (icon) > Add New User.
Note: You cannot modify the user account in this section. A new user account with the specified changes is added to the probe
if changes are made in this node and the configuration is saved.
User-<User Name> > Options (icon) > Delete User

This section lets you delete an Exchange Server user from the probe.
<Server Name> Node

This node represents the server name of the profile that is used to monitor the performance of the Exchange Server. This node cannot be
configured.
<User Name> Node

This node lets you edit the user properties and configure the advanced inbox settings.
Navigation: ews_response > User-user name > server name > user name
user name > User Properties
This section lets you edit user properties such as the name, password, and Exchange Server to log into. The fields in this section are the same as
the Add New User window accessible from ews_response > Options (icon) > Add New User.
user name > Advanced Inbox Settings
This section lets you set the advanced inbox setting parameters such as inbox check time, inbox send alarm, and advanced inbox alarms. The
fields in this section are used to override the global values for these fields, if applicable, in the ews_response node.
Inbox Check Time: specifies how often the probe scans the inbox of the Exchange Server user.
Default: Use Global
Bounce Nimsoft Test Mail from other sources back to Sender: returns the incoming email to the sender.
Inbox Send Alarm: specifies the condition to generate an alarm.
Send Alarm on Unexpected Mail: generates alarm if other emails appear.
Advanced Inbox Mails: scans specified emails other than test emails.
Stop Reading Inbox when other than Nimsoft Mails Found: specifies the number of emails other than the test emails sent by the
ews_response probe.
Default: 30
user name > Options (icon) > Add New Profile
This section lets you add a monitoring profile, which is defined for an Exchange Server user.
<Profile Name> Node

You can configure the properties of profiles using this node. You can also specify the alarm and QoS properties.
Navigation: ews_response > User-user name > server name > user name > profile name
profile name > Profile General Parameters
Name: defines the name of the profile.
Active: activates or deactivates the profile.

Default: Selected
Mail to: defines the target email address where the email is directed.
Default: <self>
Note: The emails can be sent to:

Own mailbox <self>
To an Exchange Server user whose mailbox is monitored by another instance of the ews_response probe, with Bounce
Nimsoft Test Mail from other sources back to Sender enabled (on the ews_response or User Name nodes).
To an unknown Exchange Server user on a known email server for returning the email.
Send to an Exchange Server user for whom you have created another way of returning the emails to the mailbox being
monitored.
profile name > QoS Messages on Mail Sent Time

This section lets you configure the alarm and QoS when an email is sent.
Send mail every second: specifies the interval after which an email is sent.
Default: 300
Note: The Mail Send Time QoS value (in milliseconds) is the time taken to connect to the server and execute the send
command.
profile name > QoS Messages on Mail RTT

This section lets you configure the alarm and QoS on email round-trip time. round-trip time is the time taken by a test email to be received back by
an Exchange Server user mailbox that sent the email.
Send Alarm: generates alarm if email round-trip time exceeds the specified threshold.
Default: Selected
Roundtrip Time Threshold (Seconds): specifies the email round-trip time.
Default: 120
Note: If the email is received after Consider Mail lost after time, the QoS email for Mail round-trip time is null.
The round-trip time is calculated as (End Time timestamp minus Mail Send timestamp) divided by 1000, where:
End Time timestamp is when the sender receives the test email back from the receiver in Coordinated Universal Time (UT
C).
Mail Send timestamp is the sent time mentioned in the test mail in UTC.
The Mail send time QoS is in milliseconds and Mail round-trip time is in seconds. So, the value is divided by 1000 to convert
it into milliseconds.
Using Alarm Message: specifies the alarm email when the email round-trip time exceeds the threshold.
Default: MailTimeout
Mail Error Message: specifies the alarm email when the probe is unable to send email to the specified Exchange Server user.
Default: Mailerror
Consider Mail Lost after (Seconds): specifies the time before the email is considered as lost. The value is the sum of the interval and the
email lost threshold.
Default: 300
Note: The Mail Lost alarm is generated at the next check interval after the specified Consider Mail Lost after value.
Example: If the value of this field is 300 seconds, and the interval is set at 30 seconds, the alarm is generated at 300 plus the
remaining time for the next scan (0 to 30 seconds) or 300 to 330 seconds.
Lost Mail Message: specifies the alarm email used when the email is not delivered.
Default: MailLost
Accept undelivered Reply as OK: changes the status of undelivered emails as delivered.
Default: Selected
Profile Name > Options (icon) > Delete Profile
This section lets you delete a profile from an Exchange Server user account configured in the probe.
v2.0 ews_response IM Configuration

This article describes the procedures to deploy and configure the Microsoft Exchange Server Response Monitoring (ews_response) probe using
Infrastructure Manager. The following diagram outlines the process to configure the probe to monitor an exchange server.
Add Exchange Server Details
information, see ews_response (Microsoft Exchange Server Response Monitoring) Release Notes.

You can configure the general properties of the probe to set up global values. You can use these global values across all user accounts
configured in the probe. The values (except Log Level) can be overridden for different user accounts. You can also use the default values
specified for these fields.
Follow these steps, as needed:
1. Open the Setup tab.
2. Specify the level of details that are written to the log file in the Log Level field of the General Configuration section.
Default: 0 - Fatal
3. Specify the interval between each cycle when the inbox is read in Check Every Second. You can reduce this interval to generate alarms
faster (as next interval takes lesser time) but it increases the load on the Exchange Server. You can also increase this interval to reduce
the load on the Exchange Server but it generates alarms later (as next interval takes more time).
Default: 15
4. Select Bounce Nimsoft Test Mail from other sources back to Sender to enable the Exchange Client to return incoming test emails to
4.
Note: Test email messages can be received by a user account from another mailbox that is monitored by a separate instance
of the probe. These emails are sent back if this checkbox is selected.
5. Select Send Alarm on unexpected mail to generate alarms if emails from other sources appear. An active user can have other email
messages in the inbox. An active user can have other email messages in the inbox. The alarm notifies you that the account has received
a non-test email, if this option is selected.
Default: 30
6. Specify the number of messages which are scanned in Stop reading inbox when other than Nimsoft Test Mails Found before
stopping the probe to scan the inbox. An active user can receive many non-test emails. This setting allows you to stop the probe from
scanning the inbox if it does not find the actual test email, thus reducing server load.
Add Exchange Server Details

You must configure the probe by providing the Exchange Server details with the user name and password. The probe uses these credentials to
access server, send test emails, and monitor the server response time (performance) for generating alarms and QoS. The user must have access
to the server.
Follow these steps:
1. Right-click the Status tab and select New User.
Note: You can also select an existing user and click Copy User to create a New User with the same properties. You must give
a different profile name while copying a user.
The User properties dialog appears.

You can use the User properties dialog to create a user. The dialog contains details of the sender, receiver, and Microsoft Exchange
Server to monitor its performance. You can log in with the credentials of the sender at Exchange Server. The mail account of the receiver
is used to send and scan monitoring mails.
2. You can specify the value in the following fields, as needed:
Active: activate or deactivate the user. Deactivating a user deactivates all the profiles for the user.
Name: define a valid user name for the Exchange Server user that is preceded by domain name. For example, domain\username
Password: define the password for the user account.
Server name: define the name of Exchange Server to be used.

Sub-directories must not be included. For example, the Server Name for the webmail addresshttps://mail.example.com
/owa is https://mail.example.com/. Sub-directories like owa must be removed.
Exchange Version: select the Exchange Server to be used from the drop-down list.
3. Create a monitoring profile under the Profiles tab, where you can define details of user to whom test mail is sent for monitoring.
Refer Create Monitoring Profile for more information.
5. Select Use Global to use the use the settings from the Setup tab. You can also select Override to enter user-specific values.
6. Click OK to save the User properties.

You must create and configure monitoring profiles to monitor the Exchange Server.
Follow these steps:
1. Open the Profiles tab In the User Properties window.
2. Right-click and select New Profile.
The Profile Properties window opens and Active is selected by default.
4. Specify the target email address where the email is directed in Mail to.
5. Specify how often a mail is sent in Send mail every ... seconds.
6. Select the required QoS messages to be generated.
7. Select Accept 'undelivered' reply as ok to return the undelivered mails back to the sender.
8. Select Send alarm and specify the value in the when mail roundtrip time exceeds ... seconds to generate alarms.
Notes:
If the mail is received after Consider Mail Lost after Seconds, the QoS message for Roundtrip Time Threshold is null.
Round-trip time is the time taken by a test email to be received back by the user mailbox that sent the email.
Select the alarms as applicable:

Using alarm message: select the alarm message for sending the mail when the mail roundtrip time exceeds the specified threshold.
Mail error message: select the alarm message to be used when unable to send mail to the specified user.
Note: The Mail Lost alarm is generated at the next check interval after the specified value.
Example: If the value of this field is 300 seconds, and the check interval is set at 30 seconds, the alarm is generated at 300
plus the remaining time for the next check (0 to 30 seconds) or 300 to 330 seconds.
Consider Mail lost after: define the time (in seconds) before the mail is considered as lost.
Lost mail message: select the alarm message to be used when the mail is not returned.
9. Click Ok.
The profile is created and configured.
v2.0 ews_response IM GUI Reference

This article describes the configuration GUI for the ews_response probe.
The probe is configured by double-clicking the line representing the probe in the Infrastructure Manager. The configuration interface contains
different tabs to specify threshold values and the target Exchange Server that must be monitored.
Contents
Setup Tab
Status Tab
User Properties Window
Profile Properties Window
Message Pool Tab
Message Properties
Setup Tab
The Setup tab defines the general properties for the probe.
The fields that are displayed in the dialog are as explained:

Log properties
Log-Level
Default: 0 - Fatal
Inbox
Check every... seconds
Specifies the interval between each cycle when the inbox is read. The inbox is only read when there are outstanding emails. You can
reduce this interval to generate alarms faster (as next interval takes lesser time) but it increases the load on the Exchange Server.
You can also increase this interval to reduce the load on the Exchange Server but it generates alarms later (as next interval takes
more time).
Default: 15
Bounce Nimsoft test mail from other sources back to sender

Enables the Exchange client response to return the incoming test email to the sender. You can select this option if you want to
monitor the round-trip time between two independent user accounts. This provides a more realistic response time. The test email is
sent from an inbox to itself to calculate the round-trip time.
Note: Test emails can be received by a user account from another mailbox that is monitored by a separate instance of the
probe. These emails are sent back if this checkbox is selected.
Send alarm on unexpected mail

generate alarms if other emails are present in the mailbox. An active user can have other emails in the inbox. An active user can have
other emails in the inbox. The alarm notifies you that the account has received a non-test email, if this option is selected.
Advanced
Stop reading inbox when ... mails other than Nimsoft mails have been found
Specifies the number of emails which are scanned before stopping the probe to scan the inbox. An active user can receive many
non-test emails. This setting allows you to stop the probe from scanning the inbox if it does not find the actual test email, thus reducing
server load.
Default: 30
Note: If an active Exchange Server user gets email exceeding the specified number, the probe is unable to find its own last
message and consider it lost.
Status Tab
The Status tab lists all the monitoring hosts configured in the probe. You can have more than one entry for each email user you want to send
email with a valid user name, password, and the name of the Exchange Server to log in. For each of these Exchange Server users, one or more
monitoring profiles can be defined. These monitoring profiles define how the test email is sent and received and also specify the alarm and QoS
properties.
You can right-click in the Status tab to display the following options:
New User: creates a new user profile for an Exchange Server. You can click it to open the User Properties window for a new user.
Edit User: updates an existing user profile for an Exchange Server.
Delete: removes the selected user profile for an Exchange Server.
Copy User: copies the existing user profile for an Exchange Server to create a new user.
User Properties Window
The window has the following fields and a Profiles and an Advanced tab.
Active: activates or deactivates the Exchange Server user. Deactivating a user deactivates all the profiles for the user.
Name: defines a valid user name for the Exchange Server user that is preceded by domain name. For example, domain\username
Password: defines the password for the user account.
Server name: defines the name of Exchange Server to be used.

Sub-directories must not be included. For example, the Server Name for the webmail addresshttps://mail.example.com/o
Profiles Tab
The Profiles tab lists all monitoring profiles that are defined for the Exchange Server user. Right-clicking in the list lets you add, edit, or delete
profiles.
Note: The Active check box in User properties dialog must be enabled for the context menu to appear.
You can right-click in the Profiles tab to display the following options:
New Profile: creates a new monitoring profile for the Exchange Server user. Click it to open the Profile Properties window for a new
profile.
Edit Profile: updates an existing monitoring profile.
Delete profile: removes the selected monitoring profile.
Profile Properties Window
The profile properties describe to whom the test email must be sent, the interval between each test message and the alarm and QoS
properties. The email messages can be sent to:
Own mailbox <self>
To an Exchange Server user whose mailbox is monitored by another instance of the probe, with 'bounce' enabled (on the Setup tab).
To an unknown Exchange Server user on a known email server for returning the email.
Send to an Exchange Server user for whom you have created another way of returning the emails to the mailbox being monitored.
Name
Defines the name of the profile
Active
Activates and runs the profile.
Mail to
Defines the target email address for the test email. The default value is <self>, which means the Exchange Server user mailbox. The <se
lf> email address is constructed using the domain name and username in the Name field of User properties dialog (refer Create New
User). For example, domain\username becomes username@domain.com.
Send mail every
Specifies how often a test email is sent.
Quality of Service messages on
Mail send time
Lets you generate a QoS message on each email sent.
Note: The Mail Send Time QoS value (in milliseconds) is the time taken to connect to the server and execute the send
command.
Mail roundtrip time

Lets you generate a QoS message on each email sent.
The time interval from when the test email is sent until it is returned and read from the senders mailbox.
Note: If the email is received after Consider Mail lost after time, the QoS message for Mail roundtrip time is null.
The round trip time is calculated as (End Time timestamp minus Mail Send timestamp) divided by 1000, where:
End Time timestamp is when the sender receives the test email back from the receiver in UTC.
Mail Send timestamp is the sent time mentioned in the test mail in UTC.
The Mail send time QoS is in milliseconds and Mail roundtrip time is in seconds. So, the value is divided by 1000 to
convert it into milliseconds.
Accept "undelivered" reply as ok

Returns the undelivered emails back to the sender. If this option is enabled, such undelivered emails are treated as delivered email.
Alarm messages
Indicates the configurations of various alarm messages that the probe can generate.
Send alarm
Sends the alarm messages if email roundtrip time exceeds the specified threshold (seconds).
Using alarm message
Specifies the alarm message for sending the email when the email roundtrip time exceeds the specified threshold.
Mail error message
Specifies the alarm message to be used when unable to send email to the specified Exchange Server user.
Consider Mail lost after
Defines the time (in seconds) before the email is considered as lost. The value is the sum of the interval and the message lost
threshold.
Lost mail message
Specifies the alarm message to be used when the email is not returned.
Advanced Tab
The Setup tab of the probe GUI defines the global Inbox and Advanced settings for the probe. By default, these settings are for all
defined Exchange Server users. The Advanced tab on the User properties dialog allows you to override these settings for an Exchange
Server user.
Message Pool Tab

The Message Pool tab contains the list of defined alarm messages. The messages can be used in specific profile, while generating alarms and
QoS messages. This window contains the list of alarm messages defined. These messages can be selected to be sent on error conditions (when
defined thresholds are breached) in specific profiles.
Add message: creates a new message using the Message properties dialog.
Message properties: allows you to edit the selected message using the Message properties dialog.
Remove message: deletes the selected message. You will be asked to confirm the deletion.
Message Properties
The Message properties dialog lets you define new messages and modify existing message details.
Name
Indicates email from the profiles. Each message must be given a unique name. This field remains disabled, while editing the existing
message.
Alarm situation
Specifies the default message for a particular alarm situation. You must leave this field empty if another message is set as the default.
Text
Supports variable expansion for the following variables.

Profile
Defines the profile name for sending the test email.
Mail_to
Defines the recipient of the test email.
Used
Measures the email roundtrip time.
Threshold
Defines the alarm threshold for the profile.
Diff
Defines the difference between the alarm threshold and the email roundtrip time measured.
Note: All the variables are not available for each alarm. Only the supported variable type should be used as per the definition of
the alarm.
Level
Specifies the severity level assigned to alarm message.
Subsystem
Generates the subsystem_ID of alarms. A string or an Id is managed by the NAS (Alarm Server).
v1.1 ews_response AC Configuration
Verifying Prerequisites
Install Exchange Web Services (EWS) Java API
Configure a Node
Manage Users
Delete User
Manage Profiles
Delete Profile
Alarm Thresholds
Verifying Prerequisites
The ews_response probe requires access to the following prerequisites:
User account access to Microsoft Exchange Server Address to monitor connection and send test mails.
EWS Java API for activating the probe.

The CA UIM Administrator must install EWS Java API before running the probe. The EWS Java API adds communication support for the Java
client application with an Exchange Server.
Follow these steps:
1. Go to the following link and download the latest EWS Java API for the probe:
http://www.java2s.com/Open-Source/Java_Free_CodeDownload/e/EWS-Java-API-master.zip
2. Unzip the downloaded zip file and find the file with name EWSJavaAPI_1.2original.jar in the unzipped folder.
3. Copy the EWSJavaAPI_1.2original.jar file to the following path:
\probe\application\ews_response\lib
4. Rename the EWSJavaAPI_1.2original.jar file to EWSJavaAPI_1.2.jar.
EWS Java API is installed.
Notes:
The 1.11 and earlier versions of the probe require EWS Java API for monitoring Exchange Server.
Ensure the .jar file is accurate and its size is 905 kb.
Configure a Node
This procedure provides information to configure a particular section within a node. Each section within the node lets you configure the properties
of the probe for monitoring Microsoft Exchange Server performance.
Follow these steps:
3. The specified section of the probe is configured.
The probe is now ready to monitor the Microsoft Exchange Server.
Manage Users
The Server Administrator must add and manage users for monitoring the Exchange Server.
Follow these steps:
1. Click the Options icon next to the ews_response node in the navigation pane.
2. Click the Add New User option.
The user is created under the ews_response node.
Delete User
You can delete an existing user when you no longer want it.
Follow these steps:
1. Click the Options icon next to the User-user name node that you want to delete.
2. Click the Delete User option.
The user is deleted.
Manage Profiles
The Server Administrator must create and configure monitoring profiles for monitoring the Exchange Server.
Follow these steps:
1. Click the Options icon next to the ews_response node in the navigation pane.
The new profile is created under the user name node. Using the profile, you can define how the test mail message is sent and returned
and also specify the alarm and QoS properties.
Delete Profile
You can delete an existing profile when you no longer want it.
Follow these steps:
Alarm Thresholds
allow the probe to:
v1.1 ews_response AC GUI Reference
ews_response Node
<Server Name> Node
<User Name> Node
<Profile Name> Node
The Microsoft Exchange Server Response Monitoring probe is configured for monitoring the Exchange Server by defining one or more users. You
can add profiles for each user. These monitoring profiles define how the test mail message is sent and returned. These profiles also specify the
alarm and QoS properties.
ews_response Node
This section contains the configuration details specific to the Microsoft Exchange Server Response Monitoring probe. In this node, you can view
the probe information and can configure the setup properties.
Navigation: ews_response
ews_response > Probe Information
ews_response > General Configuration
This section lets you configure the properties of the Microsoft Exchange Server Response Monitoring.
Default: 0 - Fatal
Check Every Second: specifies how often the inbox is read. The inbox is only read when there are outstanding mail messages.
Default: 15
Note: The probe deletes the mail after scanning the inbox of the user to save inbox storage space.
Bounce Nimsoft Test Mail from other sources back to Sender: enables the Exchange client response to return incoming test mail to the
sender.
Stop reading inbox when other than Nimsoft Test Mails Found: specifies the number of messages, which are scanned.
Default: 30
ews_response > Send Alarm on Unexpected Mail
This section lets you generate alarms if other mail messages appear. If the test user is an active user, there are other mail messages in
the inbox.
ews_response > Message Pool

This section lets you generate alarm to view a particular alarm message detail.
Message Name: identifies the unique name of the message. This name is used to refer to the message from the profiles.
Text: identifies the alarm message text. Use following variables for including run-time information in the alarm message text:
profile
mail_to
used
threshold
diff
Level: identifies the alarm message severity.
Default for: identifies the default message name.
i18n Token: identifies the predefined alarms fetched from the database.
ews_response > Options Icon > Add New User
This section lets you add a user with a valid user name, password, and the name of the Exchange server to log in.
Active: activates or deactivates the user.
Exchange Version: specifies the version of the Exchange Server.

This node lets you configure the user information.
Note: The user name is user-configurable and is referred to as user-user name in this document.
Navigation: ews_response > User-user name
User Info
This section lets you configure the user information.
<Server Name> Node

This node represents the server name of the profile that is used to monitor the performance of the Exchange server.
Note: The server name is user-configurable and is referred to as server name in this document.
<User Name> Node

This node lets you edit the properties of the user and configure the advanced inbox settings.
Note: The user name is user-configurable and is referred to as user name in this document.
Navigation: ews_response > User-user name > server name > user name
user name > User Properties
This section lets you edit the properties of the user, such as the name, password, and exchange server to log in.
user name > Advanced Inbox Settings
This section lets you set the advanced inbox settings parameters, such as inbox check time, inbox send alarm, and advanced inbox alarms.
Inbox Check Time: specifies how often the probe checks the inbox of the user mail box is checked.
Default: Use Global

Check Every Second: specifies the number of times the probe checks the inbox in one second.
Default: 0
Bounce Nimsoft Test Mail from other sources back to Sender: returns the incoming mail to the sender.
Default: Selected
Inbox Send Alarm: specifies the condition to generate an alarm.
Send Alarm on Unexpected Mail: generates alarm if other mail messages appear.
Advanced Inbox Mails: scans specified mails other than Nimsoft mails.
Stop Reading Inbox when other than Nimsoft Mails Found: specifies the number of mails other than Nimsoft mails.
Default: 0
user name > Options Icon > Add New Profile
This section lets you add a monitoring profile, which is defined for a user.
<Profile Name> Node

You can configure the properties of profiles using this node. You can also specify the alarm and QoS properties.
Note: The profile name is user-configurable and is referred to as the profile name in this document.
Navigation: ews_response > User-user name > server name > user name > profile name
profile name > Profile General Parameters
Name: defines the name of the profile.
Active: activates or deactivates the profile.
Default: Selected
Mail to: defines the target email address where the email is directed.
Default: <self>
profile name > Quality of Service Messages on Mail Sent Time
This section lets you configure the alarm and QoS when an email is sent.
Send mail every second: specifies the interval after which an email is sent.
Default: 300
profile name > Quality of Service Messages on Mail RTT
This section lets you configure the alarm and QoS on email roundtrip time.
Send Alarm: generates alarm if mail roundtrip time exceeds the specified threshold.
Roundtrip Time Threshold (Seconds): specifies the mail roundtrip time.
Default: 120
Note: If the mail is received after Consider Mail Lost after Seconds, the QoS message for Roundtrip Time Threshold is null.
Using Alarm Message: specifies the alarm message when the mail roundtrip time exceeds the threshold.
Default: MailTimeout
Mail Error Message: specifies the alarm message when unable to send mail to the specified user.
Default: Mailerror
Consider Mail Lost after Seconds: specifies the time (in seconds) before the mail is considered as lost.
Default: 300
Lost Mail Message: specifies the alarm message to be used when the mail is not delivered.
Default: MailLost
Accept undelivered Reply as OK: changes the status of undelivered emails as delivered.
Default: Selected
v1.1 ews_response IM Configuration

This article describes the requirements for deploying and configuring the exchange_monitor probe using Infrastructure Manager.
Contents
Installation Notes
Prerequisites
Monitoring System Requirements
How to Enable and Run the Probe
Configure Users
Create New User
Copy Existing User
Installation Notes
When installing the probe, a wizard assists you through the initial probe configuration.
Note: While creating monitoring profiles, the probe assumes that the test mail sent comes to the test users' mailbox. This can be done
in several ways, for instance:
Send mail to the test user directly.
Send mail to a non-existing user on a mail server that issues an 'Unknown user' return mail.
Send mail to another test user whose mailbox is being monitored by another instance of this probe.
Prerequisites
The ews_response probe requires access to the following prerequisites:
User account access to Microsoft Exchange Server Address to monitor connection and send test mails.
EWS Java API for activating the probe.

The CA UIM Administrator must install EWS Java API before running the probe. The EWS Java API adds communication support for the Java
client application with an Exchange Server.
Follow these steps:
1. Go to the following link and download the latest EWS Java API for the probe:
http://www.java2s.com/Open-Source/Java_Free_CodeDownload/e/EWS-Java-API-master.zip
2. Unzip the downloaded zip file and find the file with name EWSJavaAPI_1.2original.jar in the unzipped folder.
3. Copy the EWSJavaAPI_1.2original.jar file to the following path:
\probe\application\ews_response\lib
4. Rename the EWSJavaAPI_1.2original.jar file to EWSJavaAPI_1.2.jar.
EWS Java API is installed.
Notes:
The 1.11 and earlier versions of the probe require EWS Java API for monitoring Exchange Server.
Ensure the .jar file is accurate and its size is 905 kb.
Monitoring System Requirements

The ews_response probe monitors the performance of your Microsoft Exchange Server Connection.
How to Enable and Run the Probe

Follow these steps:
1. Create a test user in Exchange.
2. If the messages bounce between instances of the probe, then ensure that test users are present in the address books of others.
3. Drop the package on the Robot.
4. On the Status tab, create user, password, and the name of the Exchange Server.
5. Create and enable at least one monitoring profile.
Configure Users
You can configure the ews_response probe by providing the Microsoft Exchange server details to be monitored with the user name and
password. The probe uses these credentials to access server, send test emails, and monitor the server response time (performance) for
generating alarms and QoS.
Create New User

You can use the User properties dialog to create a user. The dialog contains details of the sender, receiver, and Microsoft Exchange Server to
monitor the performance. You can log in with the credentials of the sender at Exchange Server. The mail account of receiver is used to send and
scan monitoring mails.
Follow these steps:
1. Select the New User option in the Users list.
The User properties dialog appears
Active
Lets you activate/deactivate the user. Deactivating a user deactivates all the profiles for the user.
User and Server
Specifies the user name, password, and exchange server to be used.
Name
Defines a valid user name for the Exchange Server user that is preceded by domain name. For example, domain\username
Password
Defines the password for the user account.
Server name
Defines the name of Exchange Server to be used.
Note: Server name must specify the protocol of the exchange web service. For example, http://www.example.com or https://
www.example.com. If not specified, by default it is https://.
Exchange Version
Specifies the Exchange Server to be used from the drop-down list.
2. Specify the user details under Profiles tab, where you can define details of user to whom test mail is sent for monitoring.
3. Click Advanced tab to override global settings that are defined under the Setup tab.
4. Click OK to save the User properties.
Note: Similarly, you can select the Edit User and Delete User options from the Users list to modify and remove the selected user
details.
Copy Existing User

You can use the User properties dialog to copy existing user details to create another user.
Follow these steps:
1. Select the Copy User option in the Users list.
The Copy Existing User dialog appears.
Refer Create New User section for description of the fields.
2. Modify User And Server details, as required and click OK.
Note: You must give a different profile name while copying a user.
v1.1 ews_response IM GUI Reference

This section describes the configuration GUI for the ews_response probe.
The probe is configured by double-clicking the line representing the probe in the Infrastructure Manager. The configuration interface contains
different tabs to specify threshold values and the target exchange server that must be monitored.
Contents
The Setup Tab

The Status Tab
The Profiles Tab
Profile Properties
The Advanced Tab
The Message Pool Tab
Message Properties
The Setup Tab

The Setup tab defines the general properties for the probe.

Log properties
Log-Level
Determines detail level of messages being logged. This functionality is used for internal checking of the probe.
Inbox
Check every... seconds
Specifies how often the probe reads the inbox. The value is 15 seconds. The inbox is read only when there are new mails.
Bounce Nimsoft test mail from other sources back to sender
Enables the probe to return incoming test mail to sender.
Send alarm on unexpected mail
Generates the alarm when other than Nimsoft mail is identified in the test user inbox. This option helps restricting the test user inbox
for any other purpose.
Advanced
Stop reading inbox when ... mails other than Nimsoft mails have been found
scans only specified number of mails. For example, the mailbox contains mails which are not probe specific for an active user but the
probe scans only its own sent mails. The default value is 30.
Note: If an active user gets mail exceeding the specified number, the probe is unable to find its own last message and
consider it lost.
The Status Tab

The Status tab lists all monitoring profiles configured. Normally you have one entry for each mail user you want to send email with a valid user
name, password and the name of the Exchange server to log in.
For each of these users, one or more monitoring profiles can be defined. These monitoring profiles define how the test mail is sent and received
and also specify the alarm and QoS properties.
Right-clicking in the Users, displays the following options:
New User: creates new monitoring profile for the user.
Edit User: updates existing monitoring profile.
Delete: removes the selected monitoring profile.
Copy User: copies the existing monitoring profile details to create a new profile.
The Profiles Tab
The Profiles tab lists all monitoring profiles that are defined for the user. Right-clicking in the list lets you add, edit, or delete profiles.
Note: The Active check box in User properties dialog must be enabled for the context menu to appear.
Follow these steps:

1. Select the New Profile option in the Profiles list.
The Profile properties dialog appears.
2. Specify email account for sending and scanning test mails.
Note: These monitoring profiles define how the test mail message is sent and returned and also specify the alarm and QoS properties.
3. Click OK.
Profile Properties
The profile properties describe to whom the test mail must be sent, the interval between each test message and the alarm and QoS properties.
The mail messages can be sent to:
Own mailbox <self>
To a user whose mailbox is monitored by another instance of the probe, with 'bounce' enabled (on the Setup tab).
To an unknown user on a known mail server ) for returning the mail.
Send to a user for whom you have created another way of returning the mails to the mailbox being monitored.
Name
Defines the name of the profile
Active
Activates and runs the profile.
Mail to
Defines the target mail address for the test mail. The default value is <self>, which means the user mailbox. The <self> mail address is
constructed using the domain name and username in the Name field of User properties dialog (refer Create New User). For example,
domain\username becomes username@domain.com.
Send mail every
Specifies how often a test mail is sent.
Quality of Service messages on
Mail send time
Lets you generate a QoS message on each mail sent.
The time taken to connect to the server and execute the send command.
Mail roundtrip time

Lets you generate a QoS message on each mail sent.
The time interval from when the test mail is sent until it is returned and read from the senders mailbox.
Note: If the mail is received after Consider Mail lost after time, the QoS message for Mail roundtrip time is null.
Accept "undelivered" reply as ok

Returns the undelivered mails back to the sender. If this option is enabled, such undelivered mails are treated as delivered mail.
Alarm messages
Send alarm
Sends the alarm messages if mail roundtrip time exceeds the specified threshold (seconds).
Using alarm message
Specifies the alarm message for sending the mail when the mail roundtrip time exceeds the specified threshold.
Mail error message
Specifies the alarm message to be used when unable to send mail to the specified user.
Consider Mail lost after
Defines the time (in seconds) before the mail is considered as lost.
Lost mail message
Specifies the alarm message to be used when the mail is not returned.
The Advanced Tab
The Setup tab of the probe GUI defines the global Inbox and Advanced settings for the probe. By default, these settings are for all defined
users. The Advanced tab on the User properties dialog allows you to override these settings for a user.

The Message Pool tab contains the list of defined alarm messages. The messages can be used in specific profile, while generating alarms and
QoS messages.
This tab contains the list of alarm messages defined. These messages can be selected to be sent on error conditions (when defined thresholds
are breached) in specific profiles.
Add message: Creates a new message using the Message properties dialog.
Message properties: Lets you edit the selected message using the Message properties dialog.
Remove message: Deletes the selected message. You will be asked to confirm the deletion.
Message Properties
The Message properties dialog lets you define new messages and modify existing message details.
Name
Indicates mail from the profiles. Each message must be given a unique name. This field remains disabled, while editing the existing
message.
Alarm situation
Specifies the default message for a particular alarm situation. You must leave this field empty if another message is to be the default.
Text
Supports variable expansion for the following variables.
Profile
Defines the profile name for sending the test mail.
Mail_to
Defines the recipient of the test mail.
Used
Measures the mail roundtrip time.
Threshold
Defines the alarm threshold for the profile.
Diff
Defines the difference between the alarm threshold and the mail roundtrip time measured.
Note: All the variables are not available for each alarm. Only the supported variable type should be used as per the definition of the
alarm.
Level
Specifies the severity level assigned to alarm message.
Subsystem
Generates the subsystem_ID of alarms. A string or an Id is managed by the NAS (Alarm Server).
ews_response Metrics
This section contains the QoS metrics for the Microsoft Exchange Server Response (ews_response) probe.
Monitor Name
Units
Description
Version
QOS_Exchange_Mail_Send
Milliseconds
Mail sent time in milliseconds.
v1.1
QOS_Exchange_Mail_Roundtrip
Seconds
Mail turnaround time in seconds.
v1.1
exchange_monitor_backend - no longer supported

Important
This probe is no longer supported as of October 1, 2014. This probe has been replaced by the ews_response probe.
The Exchange monitor solution consists of:

An exchange_monitor probe (see exchange_monitor) installed on your Exchange server.
One exchange_monitor_backend probe with a database connection. On installation of the probe, the database connection information
must be configured. An existing database is assumed. You can use the same database as used for QoS data.
Nimsoft Exchange Monitor Reports (see Exchange Monitor Reports) installed on your IIS.
This exchange_monitor_backend probe will collect report information from all the exchange_monitor probes in the Domain and store this
information in a SQL database.
On installation, the database connection information must be configured. An existing database is assumed. You can use the same database as
used for QoS data. Check the data_engine configuration, clicking the Test connection button.
The first time the probe is started it will run a set of sql scripts to create the database tables, stored procedures and database user needed for
storing the report information, and start the web interface to access the same information.
The probe then looks for exchange_monitor probes in the domain and adds configuration file entries for those found. These can be individually
disabled or enabled.
exchange_monitor_reports - no longer supported

Important
This probe is no longer supported as of October 1, 2014. It has been replaced by the ews_response probe.
This section describes the Exchange Monitor solution.

The solution consists of:
An exchange_monitor probe (see exchange_monitor) installed on your Exchange server.
One exchange_monitor_backend probe (see exchange_monitor_backend) with a database connection. On installation of the probe, the
database connection information must be configured. An existing database is assumed. You can use the same database as used for
QoS data.
An exchange_monitor_reports probe installed on your IIS.
exchange_monitor (Microsoft Exchange Monitoring)

The exchange_monitor probe looks at a set of parameters on your Exchange Server to check its health. Alarm messages can be generated
based on the values of the parameters being checked. Quality of service (QoS) messages are generated on a set of performance related
statistics.
More information:
exchange_monitor (Microsoft Exchange Monitoring) Release Notes
v5.2 exchange_monitor AC Configuration

The exchange_monitor probe checks the health of your Exchange Server. You can generate alarm messages based on the values of these
parameters. Quality of service (QoS) messages are generated on a set of performance-related statistics.
The probe detects the version of the server and activate the existing profiles accordingly. The probe retrieves and uses values that the following
probes that are installed on the robot monitor and activates the monitoring profiles. You can configure the following types of monitoring profiles
with the probe:
DAG: To monitor the DAG events.
Services: To monitor services running on a system.
Processes: To monitor processes running on a system.
Perfmon: To monitor the performance counters that are related to exchange.
NTevl: To monitor the events that are related to exchange.
Note: The DAG profiles are only visible for exchange server 2010 and 2013.
The following diagram outlines the process to configure the exchange_monitor probe:
Contents
Configure a Profile
Alarm Thresholds
Create File Monitoring Profile
View DAG Details
Monitor Mailbox Growth
Collect Reports
Verify that required hardware and software is available and pre-configuration requirements are met before you configure the probe. For more
information, see exchange_monitor (Microsoft Exchange Monitoring) Release Notes.
Configure a Profile
You can configure a profile to retrieve and use the values that the four probes monitor.
Follow these steps:
1. Click the Profile node.
Notes:
By default, monitoring is enabled for all types of profiles. You can deselect a monitoring type if you do not want to monitor it.
2. Click the required monitoring group node.

3. You can view the list of all monitors that are defined on the profile in the selected group. The monitors are categorized into different
logical groups, describing what kind of measurement the profile performs.
The monitoring groups are described as follows:
Event
Monitors from the ntevl probe
Perf
Monitors from the perfmon probe
Cluster
Disk
Information Store
Memory
Message Transfer
Network
Processor
SMTP
Process
Monitors from the processes probe
Service
Monitors from the services probe
4. Select Calculate Average based on to calculate the average of the QoS value for the number of sample specified.
5. Specify the value in the Samples field on which the average has to be calculated.
6. Select a Compare Type value for type of comparison of the threshold value.
7. Define the Alarm limit which is the threshold value to generate alarm.
8. Select an alarm message and a clear message in the Message on alarm and Message clear fields.
9. Click the Save button to save the configuration.
Alarm Thresholds
allow the probe to:
Create File Monitoring Profile

You can create and configure a profile to monitor the files (for example, logs) present on the local or on another network location. The node
monitors the file profiles that are based on patterns that are selected in the profile and sends configured alarms and QoS.
Follow these steps:

1. Click the Options (icon) next to the File Monitoring node in the navigation pane.
2. Click Create File Profile.
File Profile dialog opens.
3. Specify the following details:
The name of the monitoring profile
Additional information about the monitoring profile
The name of the directory where the files are scanned for monitoring profiles.
The pattern of files with which monitoring profiles are searched.
For more information on regular expressions, see the exchange_monitor Regular Expressions article.
4. Select Recurse into subdirectories: searches for files in the subdirectories.
5. Specify an exclude patterns for the files that are not monitored.
The field appears only when Recurse into subdirectories is selected. For more information on regular expressions, see the exchange_
monitor Regular Expressions article.
6. Click Submit.
<File Profile Name> node is created as a child node under the File Monitoring node.
7. Click the Save button to add monitors to the profile.
The File Monitors node is added for the profile.
8. Click the <File Monitors Name> node.
9. Specify the following details in the Number of Files section to define the alarm and QoS details.
The operator for the files.
The number of monitored files. Alarm is generated when this value (threshold) does not match with the number of files in the system.
The Message ID, which is populated in the drop-down from the Message Node.
The Message clear, which is populated in the drop-down from the Message Node.
The QoS for the number of profiles at the specified check interval.
The QoS for the space used by the profiles at the specified check interval.
10. Specify the following details in the Space and Size of File section to define the space and size used by files.
The expected operator for the file.
The expected space of file
The Message ID that is generated when the threshold is breached for file space.
The file space clear alarm message.
The expected operator for file size
The expected size of the file
The unit of the file size
The Message ID that is generated when the threshold is breached for file size.
The clear alarm message for file size.
The size of the file from the following options:
Smallest Files
Largest Files
Individual Files
View DAG Details

You can view the details of the entire DAG (Database Availability Group) setup by using the DAG node.
Note: The DAG profiles will only be visible for exchange server 2010.
When you click the DAG node, the details of all the DAGs present in the current domain is displayed. You can view the name of the DAG, server
names pertaining to DAG, and list of servers that are currently active.
You can click a particular DAG to view details of all servers that are present in the current domain. Details of Number of active databases, number
of passive databases, number of mounted database, number of non-mounted databases, and the status of the server (Up or Down) are
displayed.
You can click a server to view details of database copies residing on that server.
Click a particular database to view details of that database, such as server name, database name, database copy status, mailbox size, content
index state, copy queue length, replay queue length, and last inspected log.
You can view status of all the exchange servers of all DAGs in a domain.
Follow these steps:
1. Click the exchange_monitor node.
2. Select the DAG monitoring enabled checkbox to view DAG details.
Note: Deploy the exchange_monitor probe on every exchange node of DAG Set up.
3. Select the DAG check interval(Seconds) to specify the time interval at which you want to set DAG monitoring.
Note: For DAG Monitoring, check interval should be above 300 seconds depending upon the number of the nodes of DAG.
600 seconds is the default check interval for good performance of the probe for DAG monitoring.
4. Click the DAG node.
The details of all the DAGs present in the current domain are displayed. You can view the name of the DAG, server names pertaining to
DAG, and list of servers that are currently active.
5. Click the desired DAG to view details of all servers that are present in the current domain. Details of Number of active databases, number
displayed.
6. Click the desired server to view details of database copies residing on that server.
7. Click the database to view the details of the database, such as, server name, database name, database copy status, mailbox size,
content index state, copy queue length, replay queue length, and last inspected log.

You can configure the probe for monitoring the growth of mail boxes on the exchange server.
Note: For Exchange Server, Exchange cmd-let identification, HTTP identification, LDAP identification and WMI identification are
required for Mailbox Growth. The data collector for exchange mailbox server role requires Microsoft .NET Framework v2.0 and
Microsoft Powershell v1.0.
Follow these steps:

1. Click the Setup > Mail growth.
2. Enter the following field details in the Mail box size (KB) section:
Check Mail Growth: indicates that the mail box growth on the exchange server is checked.
Check Interval: indicates the time interval after which the probe checks the mail box growth on the exchange server.
Growth limit on each iteration: indicates the maximum limit for mail box growth.
Iterations of growth before size alarm is issued: indicates the number of times of the mail box growth exceeds the Check Interval valu
e. After the specified limit, mailbox size alarm is issued.
Check only mailboxes with size greater than: indicates a conditional value for checking the mail box size.
3. Similarly, enter the field details in the Mailbox items section.
Collect Reports
You can configure to collect reports on the data that is stored in database of the exchange server. Log in using HTTP and WMI on the exchange
server or LDAP on Active Directory server, for enabling this section,
Follow these steps:
1. Click the Setup > Report Information node.
2. Select the Gather report information check box.
3. Select the Database size from the drop-down options.
Note: Click the Force Update of Report Information option from the Actions drop-down list to update the report immediately.
Access Protocols
Login using any of the protocols (LDAP, HTTP, and WMI) to gather the data from the exchange server and also generate a report.
Follow these steps:
1. Click the Setup > Report Information > Protocol Name Information node.
2. Enter the field details like server name, base domain, username, password, and other protocol-specific details for the desired Protocol:
HTTP Information
LDAP Information
3. Click the Protocol Name Test option from the Actions drop-down list to test the probe connection to the selected protocol.
Note: You can create a new instance of LDAP Information by clicking the Options (icon) next to the node.
4. Click Save to save the connection details.
v5.2 exchange_monitor AC GUI Reference

Contents
exchange_monitor Node
<DAG> Node
File Monitoring Node
<File Profile Name> Node
Profile Node
<Profile Type> Node
Profile Group node
Setup Node
Report Information
Status Node
The exchange_monitor node allows you to view the probe information.
Navigation: exchange_monitor Node

exchange_monitor > Probe Information
exchange_monitor > General Setup
This section lets you configure the probe monitoring properties and enable the counters.
Default: 0-Fatal
Log Size(KB): specifies a maximum size of the log file.
Default: 100
Perfmon Samples: specifies the number of samples for Perfmon counters.
Default: 1
Performance monitoring enabled: enables the monitoring of the profiles that are based on data from the Perfmon probe.
Default: Selected
Performance check interval(Seconds): indicates the time interval (in seconds) between each profile monitoring process.
The check interval is fetched from the perfmon probe.
Default: 60
Process monitoring enabled: enables the monitoring of the profiles that are based on data from the Processes probe.
Default: Selected
Process check interval (Seconds): indicates the time interval between each profile monitoring process.
Default: 180
Service monitoring enabled: enables the monitoring of the profiles that are based on data from the NTServices probe.
Default: Selected
Service check interval (Seconds): indicates
Default: 180
the time interval between each profile monitoring process.
Event monitoring enabled: enables the monitoring of the profiles that are based on data from the NTevl probe.
Default: Selected
Event check interval (Seconds): indicates
Default: 60
the time interval between each profile monitoring process.
DAG monitoring enabled: enables the monitoring of the Database Availability Group (DAG) server. You must also enable the DAG
checkpoints.
Note: This feature is available only for Exchange server 2010 and higher.
DAG check interval (Seconds): indicates the time interval (in seconds) between each DAG monitoring
Default: 600
process.
Browse DAG Script File: defines the path of the CheckDatabaseRedundancy.ps1 script. The script is required for
DatabaseRedundancyCount checkpoint, which is only supported on Exchange Server 2010.
File/Dir Monitoring: enables the file or directory monitoring.
User Name: defines the user name for accessing the files if they are present on another network.
Password: defines the password for accessing the files if they are present on another network.
Check Interval (Seconds): specifies the time interval between each file monitoring process.
Default: 30
Mail box size (KB)
Check mail growth: Indicates that the mail box growth on the exchange server is checked.
Check Interval: Indicates the time interval after which the probe checks the mail box growth on the exchange server.
Growth Limit on each iteration: Indicates the maximum limit for mail box growth in an iteration.
Iterations of growth before size alarm: Indicates the number of iterations of the mail box growth exceeds the minimum mailbox size
value.
Check only mailboxes with size greater than: Indicates a conditional value for checking the mail box size.
Mailbox items
Growth Limit on each iteration: Indicates the maximum limit for mail box growth in an iteration.
Iterations of growth before size alarm: Indicates the number of iterations of the mail box growth exceeds the minimum mailbox size
value.
Check only mailboxes with size greater than: Indicates a conditional value for checking the mail box size.
Message > Message definitions
Message Text: identifies the alarm message text that is issued on the message alarm.
Severity: specifies the level of severity of the alarm.
Message Token: selects the alarm message that is issued if the specified threshold value is breached.
Subsystem: identifies the subsystem ID of the alarm that defines the source of the alarm.
<DAG> Node
Navigation: exchange_monitor > DAG
DAG stands for Database Availability Group. You can view the details of the entire DAG setup by using the DAG node.
When you click the DAG node, the details of all the DAGs present in the current domain are displayed. You can view the name of the DAG server
Mailbox Server Name: displays the name of the Mailbox Server being monitored.
Database Name: displays the name of the database on the server.
Database file path: displays the file path of the required database.
Mailbox database copy status: displays the status of Mailbox database.
Mailbox size: displays the size of the mailbox to be monitored on the server.
Content index state: displays the status of the content index.
Copy queue length: displays the length of the copy queue.
Replay Queue length: displays the length of the replay queue.
Last inspected log: displays the date and time when the log was last inspected.

The File Monitoring node consists of the profiles which monitor the files present on the local or on another network location. The node monitors
the profiles that are based on patterns selected in the profile and sends configured alarms and QoS.
Navigation: exchange_monitor > File Monitoring
File Monitoring > Options (icon) > Create File Profile
The option allows you to create a profile for the files present on the local or on a network location.

The File Profile name node lets you view and configure the monitoring profile of a file.
Navigation: exchange_monitor > File Monitoring > File Profile name
File Profile Name > File Profile
This section allows you to view and configure the profile properties.
The fields are as follows:
Name: defines name of the monitoring profile.
Description: gives a short description of the monitoring profile.

Active: activates the profile
Directory: Describes name of the directory where the files are scanned for monitoring profiles.
Note: You can click the Browse button to browse for a directory/location where the monitoring profile is scanned.
Pattern: shows pattern of files where monitoring profiles are searched.

Recurse into subdirectories: searches for profiles in the subdirectories.
Exclude directories Pattern: excludes patterns of files that are not monitored.
The field appears only when Recurse into subdirectories is selected.
User: displays the user name that is required for sharing a folder on network.
Password: displays the password required to access a shared folder on network
Note: The User and Password fields appears when \\IP Address is entered in Directory text box, where systems IP Address
is entered to access the shared folder.
File Profile Name > File Monitor> Number of files

This section lets you define the message and QoS details.
Expect this Value (operator): selects the operator for the files.
Expect this Value: selects the number of monitored files.
Message ID: selects the Message ID, which is populated in the drop-down from the Message Pool tab.
Message clear: selects the Message clear, which is populated in the drop-down from the Message Pool tab.
File Profile Name > File Monitor > Size of File
This section lets you define the space and size used by files:
Expect this value (operator): selects the operator for file size.
Expect this value: selects the size of monitored files.
File size unit: selects a unit for file size.
File size Message ID: selects a message ID for file size.
File size Message Clear: selects the Message clear, which is populated in the drop-down from the Message Pool tab.
Watch size of: selects the size of the file from the below options:
Smallest Files
Largest Files
Individual Files
File Profile Name > File Monitor > Space and Size of File
Expect this value (Operator): selects the operator for the file space.
Expect this value: selects the space used by monitored files.
Used Space Unit: selects the unit of space used by the file.
File space Message ID: selects a message ID for file size.
File space Message Clear: selects the Message clear, which is populated in the drop-down from the Message Pool tab.
File Profile Name > Options (icon) > Delete

This option allows you to delete a file profile.
Profile Node
Navigation: exchange_monitor Node > Profile Node
The profile node contains the child nodes for probe types for which the profiles are monitored. These profile types are those that are available in
the probe configuration file.
<Profile Type> Node

Navigation: Profile Node > profile Type Node
This node represents the profile type for a monitored probe.
You can use the following types of monitoring profiles with the exchange_monitor probe:
Processes: To monitor services running on a system.
Ntevl: To monitor the events that are related to exchange.
DAG: To monitor the status of DAG Events.
Profile Group node

Navigation: Profile > Profile Type > Profile Group
The monitors are grouped into different logical groups, describing what kind of measurement the profile performs (such as memory, disk, and
processor).
Profile Group node allows you to view the list of all monitors that are defined on the profile in the selected group. You can also configure the alarm
messages that are generated.
The groups are described as follows:
Perfmon
Consists of monitors from the perfmon probe.
Cluster
Disk
Information Store
Memory
Message Transfer
Network
Processor
SMTP
Service
Consists of monitors from the services probe.
Event
Consists of monitors from the ntevl probe.
Process
Consists of monitors from the processes probe.
Profile Group > Monitors
Note: The monitors are different for probes and the node is referred to as the probe-group name node in the document.
This section represents the monitors for profiles of ntevl, perfmon, processes, and ntservices probe. You can activate various monitors of the
profiles of each of these probes. You can view and configure the monitors of the profile.

Profile Group > <Monitor Name>
This section allows you to view and configure the QoS properties of the profile.
QoS Name: indicates the QoS name.
Description: indicates the name of the profile.
Metric Type: indicates a unique metric ID for Exchange Server Monitor profile.
Profile Name: defines the name of the profile.
Group: defines the logical group to which the monitor belongs.
Servers: defines the version of the exchange server.
Calculate Average based on: indicates the calculation of average value of the threshold values of the checkpoint.
Samples: specifies a measured value which is compared to the threshold value that is defined on the checkpoint.
Compare Type: defines the type of comparison of the threshold value.
Message on alarm: defines the message that is displayed when the alarm is issued.
Message clear: defines the message that is displayed when the alarm is cleared.
Setup Node
This node represents the monitoring properties such as, generating reports on the growth of your mail box and login to exchange server using
LDAP, HTTP, or WMI protocol.
Navigation: exchange_monitor Node > Setup Node
Report Information
This node lets you configure the probe for collecting the reports on the data that are stored in database of the exchange server. For enabling this
section, you must log in using HTTP, LDAP, or WMI protocol.
Navigation: exchange_monitor > Setup > Report Information
Gather report information: gives all the gathered information available for the exchange monitor reports.
Filter stores and database for other servers: enables the probe to locate and report only the monitored databases and stores on the
Exchange Server.
Database size: Select to display the database size of either/both EDB and SLV files.
Note: Click the Force Update of Report Information option from the Actions drop-down to generate the report
instantaneously.
LDAP Information:
Navigation: exchange_monitor > Setup > LDAP Information
AdServer: specifies the adserver.
User: defines the user name of adserver.
Password: specifies the password of the user.
Base Domain: defines the domain of the users.
Config DN: enter the distinguished name of the adserver.
Encrypted Connections (SSL): uses SSL encryption to connect to the LDAP server.
Non Standard Ldap Port: uses user-defined port to establish a connection to the adserver.
Normal Port: specifies the standard LDAP port (Default: 389) to connect to the adserver.
Secure Port: specifies the SSL secure port (Default: 636) being used for the probe to connect to the adserver.
LDAP TimeOut: indicates the LDAP desired timeout to attempt connection to the adserver.
Reuse LDAP Connections: uses the already established connection to the adserver.
Status Node
This node represents the status of all the monitors for all the active profiles.
Navigation: exchange_monitor > Status
This section displays the details of all the status of monitors in a tabular form.
You can set or modify the files as needed:
Name: indicates the monitor name.
Unit: indicates the unit of the measured value.
Group: indicates the logical group to which this monitor belongs. A logical group defines the measurement type.
Type: indicates the probe from which this monitor is retrieved. This can be perfmon, ntservices, processes, and ntevl.
Value: indicates the latest measured value.
At: indicates the time, day, and the month at which the value is measured.
Compare Type: defines the operator for measuring the value.
Message on Alarm: indicates the alarm message text.
v5.2 exchange_monitor IM Configuration

Install the exchange_monitor probe on each Exchange Server you want to monitor. The probe detects the version of the server and activates the
profiles accordingly. The probe retrieves and uses values that the following probes monitor and creates monitoring profiles. You can configure the
following types of monitoring profiles with the probe:
DAG: To monitor the (Data Availability Group) DAG events.
Processes: To monitor processes running on a system.
Notes:
The DAG profiles are only visible for exchange server 2010 and 2013.
Configuration values and profiles are stored in following locations - /setup, /perfmon, /processes, /services, and /ntevl sections.
If you are running the exchange server in a cluster, the sections are prefixed with /evs/server-<virtual_server_name>. For
example, a virtual server, named exch-grp-01 results in a /setup section that looks like /evs/server-exch-grp-01/setup. This
allows configuration settings to follow each virtual server as it moves around. This is applicable to the 5 sections mentioned
above, except for 2 keys in /setup, which is the log level key and the log file key that are always in the /setup section and never
move with the virtual server.
The following diagram outlines the process to configure the exchange_monitor probe:
Contents
Configure a Profile
Configure a Profile for File Monitoring
View DAG Details
Collect Reports
Access Protocols
Verify that required hardware and software is available and the pre-configuration requirements are met before you configure the probe. For more
information, see exchange_monitor (Microsoft Exchange Monitoring) Release Notes.
Configure a Profile
You can configure the monitoring profiles with the exchange_monitor probe to monitor the required exchange_server:
Follow these steps:
1. Right click on the Status tab and select Profile properties.
2. Enter the Profile Name.
4. Enter a short Description of the monitoring profile.
5. In the Value properties tab, select Calculate Average Based on to calculate the average of the QoS value for the number of sample
specified.
6. Enter the sample number on which the average has to be calculated.
7. Select a threshold operator for the alarm, which defines the value of the alarm limit.
8. Define the Alarm limit, which is the threshold value for generating an alarm.
If this value is breached, an alarm is generated.
9. Select a Message the probe generates when the threshold value is breached.
10. Select a Clear Message the probe generates if the threshold is not breached.
11. Click OK.
A monitoring profile is configured.

You can monitor files on a local or remote location. The probe monitors the files based on the settings you specify in the profile for the file. The file
monitoring profiles are created to monitor the logs of the DAG events and the Exchange Server.
Follow these steps:
1. In the File Monitoring tab, right-click and select New Profile.
2. Enter the Name of the profile.
4. Enter the Description of the monitoring profile.
A File Monitoring profile is created.
Update the following sections to specify the properties of the file monitoring profile:
Scan Directory
You can specify the details of the directory that the probe monitors:.
Follow these steps:
1. Enter the Name of the directory where the files are scanned.
2. Browse for a directory or a location where the monitoring profile is scanned.
3. Select a specific Pattern of files where monitoring profiles are searched.
4. Select Recurse into subdirectories to search for profiles in the subdirectories.
5. Select a Pattern where monitoring profiles are searched.
Note: The field appears only when Recurse into subdirectories is selected.
Alarm Message
You can specify the alarm message that is generated, if the defined threshold is breached when the probe is monitoring a file.
Number of files
Specify the following details in the Number of Files section to define the alarm and QoS details.
1. Selects the operator and enter the number of files to be monitored.
2. Select the Message ID, which is the alarm message the probe generates if the threshold is breached.
3. Select a clear message from the drop-down.
Size of file
Specify the following details to define the size of the monitored files.
1. Select the threshold operator for the number and size of files to be monitored.
2. Enter the number of files to be monitored.
3.
3. Select the message id which is generated when the threshold is breached.

4. Select the clear alarm message.
5. Select the size of the file to be monitored from the below options:
Smallest Files
Largest Files
Individual Files
Similarly, you can configure the fields for Space used by the files.

You can define a QoS messages that are generated when the specified threshold is matched in the directory scanned by the probe.
Follow these steps:
1. Select Number of matching files to send QoS for the number of matching profiles.
2. Select Space Used by matching files in Kilobytes to send QoS for the space used by profiles.
A profile for file monitoring is configured.
View DAG Details

You can view the details of the entire DAG setup by using the DAG node.
Note: The DAG profiles are only visible for Exchange Server 2010 and 2013.
Follow these steps:

1. Select DAG monitoring enabled in the General setup tab.
2. Click the DAG tab to view the DAG files.
Note: The details of all the DAGs present in the current domain are displayed. You can view the name and server names
pertaining to DAG. Also the list of servers that are currently active.
3. Click a required DAG to view details of all servers that are present in the current domain.
4. Click a required server to view details of database copies residing on that server.
5. Click a required database to view its details.
6. Click OK.
7. You can view the DAG files of the required server.

You can configure the probe to monitor the growth of mailboxes on the exchange server.
Follow these steps:
1. Click the Setup > Mail growth node.
2. Enter the following field details in the Mailbox size (KB) section:
Check Mail Growth: indicates that the mailbox growth on the exchange server is checked.
Growth limit on each iteration: indicates the maximum limit for mailbox growth.
2.
Iterations of growth before size alarm is issued: indicates the number of times of the mailbox growth exceeds the Check Interval valu
Check only mailboxes with size greater than: indicates a conditional value for checking the mailbox size.
Similarly, enter the field details in the Mailbox items section.
3. Click OK.
A mailbox is created.
Collect Reports
You can configure the probe to collect the reports on the data that is stored in database of the exchange server.
Follow these steps:
1. Click the Setup > Report Information section.
Note: Click the Force Update of Report Information to generate the report instantly.
4. Select Filter stores and database for other servers.

5. Select the database size.
Access Protocols
You can configure the probe to collect the reports on the data that is stored in database of the exchange server through access protocols.
Follow these steps:
1. Click the Setup > Report Information > Protocol Name Information .
2. Specify the details for the desired protocol:
The username of the account.
The domain for which the report has to be created.
The password for the account.
3. Click the test button to test their connection.
A report will be generated.
v5.2 exchange_monitor IM GUI Reference

This article describes the fields and features of the exchange_monitor probe.
Contents
Probe Configuration Interface Installation for exchange_monitor

The Setup Tab
The Status Tab
The Profile Setup Tab
The File Monitoring Tab
The DAG Tab
Deploy DAG
Exclude Instances
Exchange Logon User Description
Execute cmdlet on Exchange Server
The Infrastructure Manager automatically downloads and installs the configuration interface, when the probe is deployed on a robot.
The Setup Tab
The Setup tab contains three sub-tabs and specifies the general properties for the probe.
Note: Mailbox growth tab will only be enabled when Gather report information is selected in the Report Information tab.

General setup
Log level: sets the level of details that are written to the log file. To minimize disk consumption and increase the amount of detail when
debugging, keep the log level low during normal operation.
Logfile size: defines the maximum size of the log file in kilobytes.
Default: 100 KB.
Perfmon samples: the number of samples within the particular counter overwrite the number of samples in general Setup.
Note: Valid only for Perfmon counters.
Performance monitoring enabled: enables monitoring of exchange_monitor profiles available of the perfmon probe.
The Performance check interval value is read from the perfmon probe.
Process monitoring enabled: enables monitoring of exchange_monitor profiles available on the processes probe.
The Process check interval value can be specified in seconds.
Service monitoring enabled: enables monitoring of exchange_monitor profiles available on the services probe.
The Service check interval value can be specified in seconds.
Event monitoring enabled: enables monitoring of exchange_monitor profiles available on the ntevl probe.
The Event check interval value can be specified in seconds.
DAG monitoring enabled: enables monitoring of DAG.
Note: Enable DAG related counters as they would not be activated by default. This feature can only be enabled on Exchange
Servers 2010.
Browse DAG script file: specifies path of the CheckDatabaseRedundancy.ps1 script file. This script is required for
DatabaseRedundancyCount counter.
If this script is not present, you can download it from:
http://gallery.technet.microsoft.com/office/8833b4db-8016-47e5-b747-951d28faafe7
Note: The file is also available on the exchange 2013 servers by default. Check in the folder <installation
directory>\Microsoft\Exchange Server\V15\Scripts on the system, where the Exchange Server is installed.
File/Dir Monitoring: enables the file and directory monitoring for all profiles. Click this option to enable the user name, password, and
check interval fields.
User name: displays user name access folders that are shared on the network as well as locally. This user name overrides the user
name in the File Monitoring tab.
Password: displays the password to access folders that have been shared on the network as well as locally. This password overrides
the password in the File Monitoring tab.
Check interval (seconds): selects or specifies the interval (in seconds) between each time the probe checks the Exchange server for
file/directory monitoring.
Report information
For detailed log in information and its parameters defined in the tab, see the section.
Gather report information: instructs the probe to make all gathered information available for the exchange_monitor_reports product.
Default: Disabled.
Note: Specify HTTP, VMI, and LDAP identifications successfully (Test them by clicking the corresponding test buttons to get
green indicators, to enable this option).
Force update of report information: fetches the most current Exchange information.
Filter stores and databases for other servers: instructs the probe to find and report only the databases and stores on the Exchange
Server that is to be monitored. This ensures that databases and stores on other Exchange Servers, but on the same domain are
excluded.
Default: Selected
Database Size: the Exchange Server 2003 database consists of EDB file, SLV file, and Summary.
Reports the database size as a summary of these two files or the size of one of the two files.
Note: This field applies for Exchange Server 2003 only.
WMI Identification (2003 Server) Exchange cmd-let Identification (2007 Server): fetches the report information using WMI and Exchange
cmd-let on Exchange server 2007. The following login information must be specified:
User
Domain
Password
Click the Test button to test the WMI/Exchange cmd-let login parameters specified.
LDAP identification: the report information is gathered from Active Directory (AD) using LDAP. The LDAP log in information must be
specified:
AD Server
User
Note: Specify the username on the format <user name>@<domain name> or as the LDAP DN (Distinguished Name of the
user, for example: CN=Koert Struijk,OU=Users,OU=Nimsoft,DC=nimsoft,DC=no).
LDAP Test: tests the specified LDAP login parameters

If your mailbox users and distribution groups are spread around in multiple domains, specify one Active Directory domain controller for
each domain using the Manage AD Servers dialog
Manage AD Servers: specifies the LDAP login information for one AD Server.
Click this button to open the Manage AD Servers dialog. It enables you to manage several AD servers.
You can add servers and specify the LDAP login information (as described above) for each of them:
AD Server
User
Password
Base DN (LDAP BaseDN field)
Advanced (button): opens the LDAP connection properties dialog.
Connection type
Encrypts the communication between the probe and the Active Directory domain controller.
Non-standard LDAP port: allows you to change the LDAP port numbers if you do not want to use the standard ports.
LDAP search timeout: specifies the time limit (seconds) the probe is allowed to use on each LDAP search.
Default: 30 seconds.
HTTP identification: the report information is gathered from the Exchange server, using WebDAV.
Note: This field applies only for Exchange Server 2003.
The following HTTP login information must be specified:

Server
User
Password
Clicking the Test button tests the HTTP login parameters specified.
Server requires https (SSL): Select this option if you want to use SSL. In that case you also must specify the SSL port to be used
(see below).
SSL port: The SSL port to be used if the Server requires https (see above) is selected.
Mailbox growth
Check mailbox growth: select this option to make the probe check the growth of the mailboxes on the Exchange server.
Note: Select the Gather report information on the Report information tab to enable and the Mailbox tab.
Check interval: specifies the interval (in seconds) between each time the probe checks the Exchange server for mailbox growth.
Mailbox size in Kilobytes: this parameter requires that the Check mailbox growth option is selected.
Growth limit on each iteration: specifies the maximum allowed mailbox growth limit.
Only mailbox grows bigger than the specified number. These numbers are considered when counting the number of times the size
of a mailbox has increased. (see Iterations of growth before size alarm is issued).
Iterations of growth before size alarm is issued: the mailbox sizes are checked at the specified check interval.
If the size of a mailbox has increased iteratively the number of specified times here, a mailbox size alarm will be issued.
Check only mailboxes with size greater than: check only the mailboxes with size greater than specified size.
The Status Tab
This tab lists the status of all checkpoints for all active profiles.
Note: DAG counters are not displayed in the Status tab.
Name: the name of the checkpoint
Note: The colored icon displays the severity level of the current measured values for profiles with a defined alarm threshold.
Group: the checkpoints are segregated into different logical groups, describing the kind of measurement the profile performs (such as
memory, disk, processor).
Type: describes the type of checkpoint depending on which probe the checkpoint is retrieved:
Perf: checkpoints from the perfmon probe
Service: checkpoints from the services probe
Event: checkpoints from the ntevl probe
Process: checkpoints from the processes probe
Value: the most current value measured
Unit: the unit of the measured value, such as MB, %, and Mb/s
At: the time (<month> <day> <time>) the current value was measured.
Alarm limit: the defined threshold value for the profile. A breach of this value will result in an alarm message.
This tab contains the message pool, which is a list of predefined alarm messages. The messages can be referred to in specific profiles.
Right click for following commands in the message list:
Add Message: creates a new message and opens with the Message properties window.
Message properties: edits the selected Message.
Remove message: deletes the selected Message. You will be asked to confirm the deletion.
Message properties
Name: specifies the unique name of the message. This name is used to refer to the message from the profiles.
Alarm situation: the message can be made the default message for a particular alarm situation. Leave this field empty if there is another
default message.
Text: specifies the alarm message text. Supports variable expansion for the following variables:
Group
Profile
Value
Unit
Limit
Level: specifies the severity assigned level to any alarm message.
Subsystem: specifies the subsystem ID of generated alarms, a string or an ID is managed by NAS.
This tab lists all the monitoring profiles that are available in the probe configuration file. You can use the following types of monitoring profiles with
the exchange_monitor probe:
Service: To monitor the exchange services running on a system.
Process: To monitor exchange processes running on a system.
Perf: To monitor the performance counters that are related to exchange.
The File Monitoring tab consists of the profiles, which monitor the files present on the local or on a network location. This tab monitors the
profiles based on patterns selected in the profile and sends configured alarms and QoS.
Name: indicates the name of the monitoring profile.
Active: activates the profile.
Note: Active profiles appear in the profile list under the Profile Setup tab.
Description: describesr the monitoring profile.

Scan Directory
Directory: name of the directory where the files are scanned for monitoring profiles.
Note: This is an optional field.
Browse: browses for a directory/location where the monitoring profile is scanned.

Pattern: pattern of files where monitoring profiles are searched.
Recurse into subdirectories: searches for profiles in the subdirectories.
Pattern: pattern of files where monitoring profiles are searched.
User: the user required name for sharing a folder on network.
Note: This field appears when \\IP Address is entered in Directory text box, where systems IP Address is entered to access
the shared folder.
Password: the required password to access a shared folder on network.
the shared folder.
Alarm Messages: The fields in the Number of Files tab are described here:
Expect this value: Selects the operator and the number of files.
Message ID: Selects the Message ID, populated in the drop-down list from the Message Pool tab.
Message clear: Selects the Message clear, which is populated in the drop-down from the Message Pool tab.
The following fields in the Space used by Files tab:
Expect this Value: selects the operator, the size and number of files.
Message ID: selects the Message ID, populated in the drop-down list from the Message Pool tab.
Message clear: selects the Message, populated in the drop-down list from the Message Pool tab.
The following fields in the Size of File tab:
Watch Size of: selects the size of the file from the below options:
Smallest Files
Largest Files
Individual Files
Number of Matching Profiles: sends a QoS for the number of matching profiles.
Space Used by Matching Files in Kilobytes: sends a QoS for the number of matching profiles.
The DAG Tab
DAG stands for Data Availability Group. You can view the details of the entire DAG setup by using the DAG tab.
When you click the DAG tab, the details of all the DAGs present in the current domain is displayed. You can view the name of the DAG, server
A DAG displays the details of all servers present in the current domain. It also shows the details of number of active databases, number of
passive databases, number of mounted database, number of non-mounted databases, and the status of the server (Up or Down) are displayed.
To view details of database copies residing on a particular server, click on that server.
You can view the server name, database name, database copy status, mailbox size, content index state, copy queue length, replay queue length,
and last inspected log.
Click on the data base to view its details.
Note: For DAG Monitoring, check interval should be above 300 seconds depending upon the number of the Nodes of DAG. 600
seconds is the default check interval for optimal performance of the probe for DAG monitoring.
Deploy DAG
For configuration of DAG:

You have to deploy the exchange_monitor probe on every exchange node of DAG Set up.
You have to enable the DAG Monitoring by selecting the check box for DAG Monitoring in the General Setup tab as well as enabling the
DAG counters in Profile Setup tab.
For DAG Monitoring, cluster probe is not required to monitor.
Deploy exchange_monitor probe on each exchange server. Exchange_monitor probe will monitor exchange server on which it is deployed
as well and the database copies residing on the server. However, In DAG tab of the probe GUI, you will be able to view status of all the exchange
servers of all DAGs in current domain.
Exclude Instances
A monitoring profile can have multiple instances. If you do not want the probe to monitor an instance within a profile, you can exclude the
instance.
The Exclude Instances button appears in the Profile Properties dialog when the following conditions are met while the probe reads the instance
and object keys from the configuration file:
The object is for a perf profile.
The value of the profile instance key is instance = <all>.

Specify users for WMI, LDAP and HTTP in the Setup Tab. You can use 3 different users or the same user.
This section describes the requirements that have to be met to enable the probe to collect data. However that the setup may vary depending on
your forest setup and group policies.
LDAP
This user must be authorized to log into your Active Directory using the LDAP protocol.
This user requires read access to the configurationNamingContext and specifically the administrative group entry in your active directory, where
exchange servers store most information.
To add these access rights to a user, open the Exchange System Manager, right click on your administrative group, which contains the server(s)
you want to access, and choose Delegate control. Add your LDAP user to the Exchange View Only Administrator role.
User name syntaxes in Active Directory (AD).
Four known syntaxes are valid when authenticating against Active Directory using LDAP protocol, simple binds.
1. Full DN, e.g.
CN=Ben Talk,OU=West,OU=Users,DC=domain,DC=com
2. NT Account Name (e.g. NIMCLUS\e1john)
3. User Principal Name (UPN), in the userPrincipalName attribute of the user in Active Directory .
4. Plain username (e.g. user), in the display Name attribute in Active Directory
For option 2 and 3, see the image below.
Right-click the user in MMC snapin Active Directory Users and Computers, and click Properties and choose the Account tab.
For option 4, see the figure below.
For option 1, you need to use another tool, such as ADSIEDIT.MSC, LDP or any other LDAP browser tool. It is not possible to our knowledge, to
view the distinguishedName property of an object through the MMC snapin "Active Directory Users and Computers".
It is recommended to use the NT Account Name or UPN syntax.
Active Directory enforces/ensures that a users' sAMAccountName property is unique within a Active Directory forest. The domain NETBIOS name
is also enforced to be unique.
Note: UPN is not guaranteed to be unique in Active Directory forest. If two or more users have the same UPN, none of them will be
able to authenticate using the UPN name.
The same goes for plain username. It need to be unique within a forest.
WMI User
The probe will execute the "report collector" program as a background process, in the context of this user (i.e. "Run as"). This user context
will be used when connecting to the exchange shares and WMI queries.
You must be a domain user.
The UAC is on the Exchange Server, if the user is not using the domain administrative account,
You must be a member of the default domain group named Domain Users (or equivalent rights).
You must be member of the domain security group named "Exchange Servers".
You must be added to the "local administrators" group on the machine running the exchange server.
You must also be delegated control of the "Exchange View Only administrator" role.
Note: Run your exchange servers in a cluster. You must add the WMI monitoring account to the local administrators group of all those
nodes that can be owners of your virtual exchange servers.
You must Reboot your exchange server in order for this effect to take place.
HTTP (WebDav) user permissions.
Your permission will be required when contacting the exchange server to query for public folder information, with WebDAV (http) protocol
against the IIS (Outlook Web Access (OWA) also uses WebDAV).
You require at least these client permissions (Read permissions, List Contents and Read Property) on the folders in the folder hierarchy.
HTTP users will be used in the WebDAV protocol over http to talk to IIS, where the public folders is hosted and reachable. Data for the "public
folder owner" report is gathered here.
The actual list of public folders is retrieved through WMI.
WMI - the exchange_monitor probes starts a background process in the context of the WMI user (i.e. Run as command). The probe context is
used when accessing the WMI namespaces on the server running the exchange server.
In the WMI namespace root\MicrosoftExchangeV2, Exchange Server 2003 exposes several classes. The data collector retrieves instances of the
following wmi classes.
Exchange_PublicFolder - instances of public folders, and public folder replication information (to which stores are the folders replicated)
Exchange_Server - instance of the server
Exchange_Mailbox - instances of mailboxes (sizes, deleted items, item count)
Exchange_MessageTrackingEntry - message tracking entries
In the WMI namespace root\CIMV2, instances of the following classes are read:
Win32_NTLogEvent - whitespace information
LDAP - or Active Directory - will be queried to read additional information about the Exchange Server configuration. In
the configurationNamingContext - exchange server information and structure of storage groups, stores (both public and mailbox) and db
quotas.
One or more domains can be queried for distribution lists and its members.
Queries are made to retrieve users who belong to the storage groups we found in the configurationNamingContext.
Users mailboxes, mail addresses, delegates, memberOfs, account control, password last set.
It is then all tied together before it is stored and ready to be retrieved from the exchange_monitor_backend probe.
Note: The exchange_monitor_backend probe has reached its end of life and is no longer supported.
The report collector will also try to access the database files directly (the .edb files), and read the physical size of the files. The information about
where the physical files are stored, is part of the information retrieved from configurationNamingContext.
The reports have been divided into 10 sub reports, exchange_monitor point of view. The data collected is controlled and cannot be changed. The
reports are:
Traffic_summary, updated when data is older than 24 hours or at midnight.

Public_folders, updated when data is older than 24 hours or at midnight.
Domains, updated when data is older than 24 hours or at midnight.
Servers, updated when data is older than 24 hours or at midnight.
Mailboxes, updated when data is older than 10 minutes if you have enabled "monitor mailbox growth", otherwise it should be 60 minutes.
Display_names, updated when mailboxes are updated.
Partners, updated when data is older than 24 hours or at midnight.
Mailbox_activity, updated when data is older than 24 hours or at midnight.
Groups, updated when mailboxes are updated.
Databases, updated when data is older than 24 hours or at midnight.
The exchange_monitor_backend probe querries and checks the timestamps of all these reports. If the exchange_monitor probe being queried has
newer information on any of the reports, it will be collected by the backend and inserted into the SQL database. The exchange_monitor_backend
operates on the same aging policy as the exchange_monitor probe. It will not query that server again for 1 hour, if it has all the data it needs from
1 server, before the mailbox data is considered old. This means that if the exchange_monitor cant for some reason read e.g. the message
tracking logs, the backend will not get an accurate timestamp and will keep querying the exchange_monitor probe until it provides new data, once
the exchange_monitor_backends data for the reports regarding traffic is older than 24 hours.
It is important to set up the report collection and ensure that all the reports receive data, otherwise your probes will be using more network
bandwidth than necessary.

To execute the cmdlet on the Exchange server, you should have Exchange View-Only Administrators rights. In addition to this, you need to
add Exchange View-Only Administrators group to Allow log in locally policy of the Exchange server.
To achieve this, go to Security Settings and click User Rights Assignment. All the policies will be listed in the right pane. Double-click on Allow
log in locally and add 'Exchange View-Only Administrators group.
You also need to give read/write access permissions to the probe folder so that the data collector can write the data to the cfg file and the log file.
v5.1 exchange_monitor AC Configuration

The Exchange Server Monitor probe looks at a set of parameters on your Exchange Server to check its health. Alarm messages can be
generated based on the values of the parameters being checked. Quality of service (QoS) messages are generated on a set of
performance-related statistics.
The following diagram shows the tasks that you must complete to configure the exchange_monitor probe:
Contents
Configure Exchange Server Path
Configure Profile
Alarm Thresholds
Create File Profile
View DAG Details
Collect Reports
Verify that required hardware and software is available before you configure the probe. For more information, see exchange_monitor (Microsoft
Exchange Monitoring) Release Notes.
The following probes must be installed on the exchange server:
Note: The four probes must be deployed on either the exchange server or the local Hub Archive. These probes are automatically
installed from the archive, else the exchange monitor asks to install them manually.

The probe accesses the Microsoft Exchange Server installation path for collecting values of certain monitoring parameters. If the path is not
configured correctly, the probe does not send any QoS for DAG. The probe lets you configure a separate path for both Microsoft Exchange Server
2010 and 2013.
Follow these steps:
1. Open the Raw Configure GUI of the probe and navigate to the DAG section.
2. Define the Microsoft Exchange Server 2010 installation directory path as the exchange_2010_path key value.
Note: Similarly, define the Microsoft Exchange Server 2013 installation directory path as the exchange_2013_path key value.

4. Restart the probe for applying the configuration changes.
Important: The installation path must end with a forward slash (/).
Configure Profile
Install the probe on each Exchange Server to be monitored. The probe detects the version of the server and activates the profiles accordingly.
The probe retrieves and uses values that the following probes monitor and creates monitoring profiles. You can use the following types of
monitoring profiles with the probe:
NTServices
Processes
Perfmon
NTevl
Note: For Exchange Server, Exchange cmd-let identification, HTTP identification, LDAP identification and WMI identification are
required Mailbox Growth and exchange_backend probe. The data collector for exchange mailbox server role requires Microsoft .NET
Framework v2.0 and Microsoft Powershell v1.0.
Important! CA does not support exchange_backend probe anymore.
Follow these steps to configure profiles:

Note: Monitoring is enabled for all kinds of profiles by default. Deselect the desired monitoring type if you do not want to
monitor it.
2. Set the check interval to indicate the time interval (in seconds) between each profile monitoring process.
3.
3. Click the required monitoring group node (navigation Profile > Profile Type > Profile Group).
You can view the list of all monitors that are defined on the profile in the selected group. The monitors are grouped into different logical
groups, describing what kind of measurement the profile performs. You can also configure the alarm messages that are generated.
The monitoring groups are described as follows:
Event
Monitors from the ntevl probe
Perf
Monitors from the perfmon probe
Cluster
Disk
Information Store
Memory
Message Transfer
Network
Processor
SMTP
Process
Monitors from the processes probe
Service
Monitors from the services probe
4. Select Publish Data and Publish Alarm to generate a QoS when the specified parameter of the profile is breached.
5. Select Calculate Average based on field to calculate the average of the QoS value for the number of sample specified
6. Specify a measured value in the Samples field on which the average has to be calculated.
7. Select a Compare Type value for type of comparison of the threshold value.
8. Define the Alarm limit, which is the threshold value for generating alarm.
9. Select an alarm message and alarm clear message in the Message on alarm and Message clear fields.
10. Click the Save button to save the configuration.
Alarm Thresholds
allow the probe to:
Create File Profile

You can create and configure a profile to monitor the files (for example, logs) present on the local or on another network location. The node
monitors the file profiles that are based on patterns that are selected in the profile and sends configured alarms and QoS.
Follow these steps:
1. Click the Options (icon) next to the File Monitoring node in the navigation pane.
2. Click the Create File Profile option. File Profile dialog opens.
3. Enter the details in the following fields:
Name: defines name of the monitoring profile
3.
Description: describes the monitoring profile

Active: activates the profile
Directory: describes name of the directory where the files are scanned for monitoring profiles.
Note: Click the Browse button to browse for a directory/location where the monitoring profile is scanned.
Pattern: describes pattern of files where monitoring profiles are searched. Refer exchange_monitor Regular Expressions article for
regex details.
Recurse into subdirectories: searches for files in the subdirectories.
Exclude directories Pattern: excludes patterns of files that are not monitored. The field appears only when Recurse into
subdirectories is selected. Refer exchange_monitor Regular Expressions article for regex details.
User: displays the user name that is required for sharing a folder on network.
Password: displays the password required to access a shared folder on network
Note: The User and Password fields appear when \\IP Address is entered in Directory text box, where systems IP Address
4. Click the Submit button.

<File Profile Name> node is created as a child node under the File Monitoring node. You can configure the profile if needed.
5. Click the <File Profile Name> node.
6. Update the details in the File Profile section if needed.
7. Enter the following field information in the Number of Files section to define the message and QoS details.
Expect this Value: selects the number of monitored files. Alarm is generated when this value (threshold) does not match with the
number of files in the system.
Message ID: selects the Message ID, which is populated in the drop-down from the Message Node. .
Message clear: selects the Message clear, which is populated in the drop-down from the Message Node.
QoS Number of matching files: sends a QoS when the number of matching profiles is matched with the value in Expect this value fiel
d.
QoS Space used by matching files in Kilobytes: sends a QoS when the space used by matching profiles is matched with the value in
Expect this value field.
8. Enter the following field information in the Space and Size of File section to define the space and size used by files.
Used Space Operator: selects the operator for the file
Used Space Value: selects the space of file
File space Message ID: selects the Message ID that is generated when the threshold is breached for file space. The messages are
populated in the drop-down from the Message Node.
File space Message Clear: selects the file space clear alarm message, which is populated in the drop-down from the Message Node.
File Size Operator: selects operator for file size
File Size Value: selects the size of the file
File Size Unit: selects the unit of the file size
File size Message ID: selects the Message ID that is generated when the threshold is breached for file size.
File size Message Clear: selects clear alarm message for file size.
Watch Size of: selects the size of the file from the following options:
Smallest Files
Largest Files
Individual Files
View DAG Details

You can view the details of the entire DAG (Database Availability Group) setup by using the DAG node.
When you click the DAG node, the details of all the DAGs present in the current domain is displayed. You can view the name of the DAG, server
Follow these steps to view DAG details:
2. Select the DAG monitoring enabled checkbox to view DAG details.
Note: Deploy the exchange_monitor probe on every exchange node of DAG Set up.
3. Select the DAG check interval(Seconds) to specify the time interval at which you want to set DAG monitoring.
Note: For DAG Monitoring, check interval should be above 300 seconds depending upon the number of the nodes of DAG.
600 seconds is the default check interval for good performance of the probe for DAG monitoring.
4. Click the DAG node.
The details of all the DAGs present in the current domain are displayed. You can view the name of the DAG, server names pertaining to
DAG, and list of servers that are currently active.
5. Click a desired DAG to view details of all servers that are present in the current domain. Details of Number of active databases, number
displayed.
6. Click a desired server to view details of database copies residing on that server.
7. Click a database to view the details of the database, such as, server name, database name, database copy status, mailbox size, content

You can configure the probe for monitoring the growth of mail boxes on the exchange server.
Follow these steps:
1. Click the Setup > Mail growth.
2. Enter the following field details in the Mail box size (KB) section:
Growth limit on each iteration: indicates the maximum limit for mail box growth.
Iterations of growth before size alarm is issued: indicates the number of times of the mail box growth exceeds the Check Interval valu
3. Similarly, enter the field details in the Mailbox items section.
Collect Reports
You can configure the probe for collecting the reports on the data that are stored in database of the exchange server. For enabling this
section, log in using HTTP and WMI on the exchange server or LDAP on Active Directory server.
Follow these steps:
1.
1. Click the Setup > Report Information node.

Note: Click the Force Update of Report Information option from the Actions drop-down list to update the report immediately.
Access Protocols
Log-in using any of the protocols (LDAP, HTTP, and WMI) to gather the data from the exchange server and also generate a report.
Follow these steps to access a protocol:
1. Click the Setup > Report Information > Protocol Name Information node.
2. Enter the field details like server name, base domain, username, password, and other protocol-specific details for the desired Protocol:
HTTP Information
LDAP Information
WMI Information
3. Click the Protocol Name Test option from the Actions drop-down list to test the probe connection to the selected protocol.
Note: You can create a new instance of LDAP Information by clicking the Options (icon) next to the node.
4. Click Save to save the connection details.
v5.1 exchange_monitor AC GUI Reference

Contents
<DAG> Node
Message Node
Profile Node
<Profile Type> Node
Profile Group node
Setup Node
Mail Growth
Report Information
Protocol Name Node
Status Node
The exchange_monitor node allows you to view the probe information.
Navigation: exchange_monitor Node
exchange_monitor > Probe Information
exchange_monitor > General Setup
This section lets you configure the probe monitoring properties and enable the performance counters.
Default: 0-Fatal
Log Size(KB)
Default: 100
Perfmon Samples: specifies the number of samples for Perfmon counters.
Default: 1
Performance monitoring enabled: enables the monitoring of the profiles that are based on data from the Perfmon probe.
Default: Selected
Performance check interval (Seconds): indicates the time interval (in seconds) between each profile monitoring process.
Default: 60
Process monitoring enabled: enables the monitoring of the profiles that are based on data from the Processes probe.
Process check interval(Seconds)
Default: 180
Service monitoring enabled: enables the monitoring of the profiles that are based on data from the NTServices probe.
Service check interval(Seconds)
Default: 180
Event monitoring enabled: enables the monitoring of the profiles that are based on data from the NTevl probe.
Event check interval(Seconds)
Default: 60
DAG monitoring enabled: enables the monitoring of the Database Availability Group (DAG) server. You must also enable the DAG
checkpoints.
Note: This feature is available only for Exchange server 2010 and higher.
DAG check interval(Seconds)

Default: 600
Browse DAG Script File: defines the path of the CheckDatabaseRedundancy.ps1 script.
File/Dir Monitoring: enables the file or directory monitoring.
User Name: defines the user name for accessing the files if they are present on another network.
Password: defines the password for accessing the files if they are present on another network.
Check Interval (Seconds): specifies the time interval between each file monitoring process.
Default: 30
<DAG> Node
Navigation: exchange_monitor > DAG
DAG stands for Database Availability Group. You can view the details of the entire DAG setup by using the DAG node.
When you click the DAG node, the details of all the DAGs present in the current domain are displayed. You can view the name of the DAG,
server names pertaining to DAG, and list of servers that are currently active.
You can click a particular DAG to view details of all servers that are present in the current domain. Details of Number of active databases, number
displayed.
You can click a server to view details of database copies residing on that server.
Click a particular database to view details of that database, such as server name, database name, database copy status, mailbox size, content
Deploy the exchange_monitor probe on every exchange node of DAG Set up.
Enable the DAG Monitoring by selecting the DAG monitoring enabled check box.
Cluster probe is not required for DAG monitoring.
Deploy exchange_monitor probe on each exchange server. Exchange_monitor probe monitors exchange server on which it is deployed as well as
database copies residing on the server. You can view status of all the exchange servers of all DAGs in a domain. The following diagram
represents DAG architecture:

The File Monitoring node consists of the profiles, which monitor the files present on the local or on another network location. The node monitors
the profiles that are based on patterns selected in the profile and sends configured alarms and QoS.
Navigation: exchange_monitor > File Monitoring
File Monitoring > Options (icon) > Create File Profile
The option allows you to create a profile for the files present on the local or on a network location.

The File Profile name node lets you view and configure the monitoring profile of a file.
Navigation: exchange_monitor > File Monitoring > File Profile name
File Profile Name > File Profile
This section allows you to view and configure the profile properties.
The fields are as follows:
Name
Defines name of the monitoring profile.
Description
Describes the monitoring profile.
Active
Activates the profile
Directory
Describes name of the directory where the files are scanned for monitoring profiles.
Note: You can click the Browse... button to browse for a directory/location where the monitoring profile is scanned.
Pattern
Shows pattern of files where monitoring profiles are searched.
Searches for profiles in the subdirectories.
Exclude directories Pattern
Excludes patterns of files that are not monitored. The field appears only when Recurse into subdirectories is selected.
User
Describes the user name that is required for sharing a folder on network.
Password
Displays the password required to access a shared folder on network
Note: The User and Password fields appears when \\IP Address is entered in Directory text box, where systems IP Address
File Profile Name > Number of files

This section lets you define the message and QoS details.
Expect this Value: selects the number of monitored files.
Message ID: selects the Message ID, which is populated in the drop-down from the Message Pool tab.
Message clear: selects the Message clear, which is populated in the drop-down from the Message Pool tab.
QoS Number of matching files: sends a QoS when the number of matching profiles is matched with the value in Expect this value field
.
QoS Space used by matching files in Kilobytes: sends a QoS when the space used by matching profiles is matched with the value in
Expect this value field.
File Profile Name > Space and Size of File
Used Space Operator: selects the operator for the file
Used Space Value: selects the space of fileFile space Message ID: Selects the Message ID, which is populated in the drop-down from
the Message Pool tab.
File space Message Clear: selects the Message clear, which is populated in the drop-down from the Message Pool tab.
File Size Operator: selects the operator for file size
File Size Value: selects the value for file size
File Size Unit: selects a unit for file size
File size Message ID: selects a message ID for file size
File size Message Clear: selects a clear alarm message for file size
Watch Size of: selects the size of the file from the below options:
Smallest Files
Largest Files
Individual Files
File Profile Name > Options (icon) > Delete
Message Node
This node lets you view the list of alarm message that is available on the Exchange Server Monitor probe.
Navigation: exchange_monitor Node > Message Node
Message > Message definitions
This section allows you to view the details of alarm messages of the Exchange Server Monitor probe.
Message Text: Identifies the alarm message text that is issued on the message alarm.
Severity: specifies the level of severity of the alarm.
Message Token: selects the alarm message that is issued if the specified threshold value is breached.
Subsystem: identifies the subsystem ID of the alarm that defines the source of the alarm.
Profile Node
Navigation: exchange_monitor Node > Profile Node
The profile node contains the child nodes for probe types for which the profiles are monitored. These profile types are those that are available in
the probe configuration file.
<Profile Type> Node

Navigation: Profile Node > profile Type Node
This node represents the profile type for a monitored probe.
You can use the following types of monitoring profiles with the exchange_monitor probe:
Service
Process
Perf
Ntevl
Profile Group node

Navigation: Profile > Profile Type > Profile Group
The monitors are grouped into different logical groups, describing what kind of measurement the profile performs (such as memory, disk, and
processor).
Profile Group node allows you to view the list of all monitors that are defined on the profile in the selected group. You can also configure the alarm
messages that are generated.
The groups are described as follows:
Perf
Consists of monitors from the perfmon probe
Cluster
Disk
Information Store
Memory
Message Transfer
Network
Processor
SMTP
Service
Consists of monitors from the services probe.
Event
Consists of monitors from the ntevl probe.
Process
Consists of monitors from the processes probe.
Profile Group > Monitors
Note: The monitors are different for probes and the node is referred to as the probe-group name node in the document.
This section represents the monitors for profiles of ntevl, perfmon, processes, and ntservices probe. You can activate various monitors of the
profiles of each of these probes. You can view and configure the monitors of the profile.
Profile Group > <Monitor Name>
This section allows you to view and configure the QoS properties of the profile.
QoS Name: indicates the QoS name.

Description: indicates the name of the profile.
Metric Type: indicates a unique metric ID for Exchange Server Monitor profile.
Profile Name: defines the name of the profile.
Group: defines the logical group to which the monitor belongs.
Servers: defines the version of the exchange server.
Calculate Average based on: indicates the calculation of average value of the threshold values of the checkpoint.
Samples: specifies a measured value which is compared to the threshold value that is defined on the checkpoint.
Compare Type: defines the type of comparison of the threshold value.
Message on alarm: defines the message that is displayed when the alarm is issued.
Message clear: defines the message that is displayed when the alarm is cleared.
Setup Node
This node represents the monitoring properties such as, generating reports on the growth of your mail box and login to exchange server using
LDAP, HTTP, or WMI protocol.
Navigation: exchange_monitor Node > Setup Node
Mail Growth
This node represents the properties of the probe for monitoring the growth of mail boxes on the exchange server.
Note: The fields in this node are disabled as this functionality depends on group policies and user privileges.
Navigation: exchange_monitor > Setup > Mail Growth

Mail Growth > Mail box size (KB)
This section represents the threshold values that are set for monitoring the growth of mail box size.
Default: Selected
Default: 600
Growth limit on each iteration: indicates the maximum limit for mail box growth in an iteration.
Default: 500
Iterations of growth before size alarm is issued: indicates the number of iterations of the mail box growth exceeds the min. mailbox size v
alue. After the specified limit, mailbox size alarm is issued.
Default: 3
Default: 500
Note: Similar field description applies to the Mailbox Items section.
Report Information
This node lets you configure the probe for collecting the reports on the data that are stored in database of the exchange server. For enabling this
section, you must log in using HTTP, LDAP, or WMI protocol.
Navigation: exchange_monitor > Setup > Report Information
Report Information > Report Information Config

This section lets you define the properties for collecting exchange server reports.
Note: Click the Force Update of Report Information option from the Actions drop-down to generate the report instantaneously.
Protocol Name Node

Navigation: exchange_monitor > Setup > Report Information > Protocol Name
The Protocol Name node represents the different protocols to gather the data from the exchange server for report generation. The protocols can
be LDAP, HTTP, and WMI.
This section lets you enter your login credentials of any of these protocols to access the exchange server database. You can test the login attempt
through Actions drop-down option.
Note: This node is referred to as the protocol name node as it represents 3 different protocols.
Status Node
This node represents the status of all the monitors for all the active profiles.
Navigation: exchange_monitor > Status
Status > Status Viewer
This section displays the details of all the status of monitors in a tabular form.
Name: indicates the monitor name.
Unit: indicates the unit of the measured value.
Group: indicates the logical group to which this monitor belongs. A logical group defines the measurement type.
Type: indicates the probe from which this monitor is retrieved. This can be perfmon, ntservices, processes, and ntevl.
Value: indicates the latest measured value.
At: indicates the time, day, and the month at which the value is measured.
Compare Type: defines the operator for measuring the value.
Message on Alarm: indicates the alarm message text.
v5.1 exchange_monitor IM Configuration

Install the exchange_monitor probe on each Exchange Server you want to monitor. The probe detects the version of the server and activates the
profiles accordingly.
Note: Configuration values and profiles are stored in following locations - /setup, /perfmon, /processes, /services, and /ntevl sections. If
you are running the exchange server in a cluster, the sections are prefixed with /evs/server-<virtual_server_name>. For example, a
virtual server, named exch-grp-01 results in a /setup section that looks like /evs/server-exch-grp-01/setup. This allows configuration
settings to follow each virtual server as it moves around. This is applicable to the 5 sections mentioned above, except for 2 keys in
/setup, which is the log level key and the log file key that are always in the /setup section and never move with the virtual server.
The following diagram shows the steps to configure the exchange monitor probe:
Contents
Configure a Profile
View DAG Details
Collect Reports
Access Protocols
Verify that required hardware and software is available before you configure the probe. For more information, see exchange_monitor (Microsoft
Exchange Monitoring) Release Notes.

The probe accesses the Microsoft Exchange Server installation path to collect values of certain monitoring parameters. If the exchange server
path is not configured correctly. the probe does not send any QoS for DAG. You can configure a separate path for both Microsoft Exchange
Server 2010 and 2013.
Follow these steps:
1. Open the Raw Configure GUI of the probe and navigate to the dag section.
2. Define the Microsoft Exchange Server installation directory path:
2.
Important: The installation path must end with a forward slash (/).

4. Restart the probe to apply the configuration changes.
Configure a Profile
You can use the following types of monitoring profiles with the exchange_monitor probe to monitor the required exchange_server:
Service: To monitor services running on a system.
Process: To monitor services running on a system.
Follow these steps:
1. Right click on the Status tab and select Profile properties.
2. Enter the Profile Name.
4. Enter a short Description of the monitoring profile.
5. In the Value properties tab, select Calculate Average Based on to calculate the average of the QoS value for the number of sample
specified.
6. Enter the sample number on which the average has to be calculated.
7. Select a threshold operator for the alarm, which defines the value of the alarm limit.
8. Define the Alarm limit, which is the threshold value for generating alarm.
If this value is breached, an alarm is generated.
9. Select a Message the probe generates when the threshold value is breached.
10. Select a Clear Message the probe generates if the threshold is not breached.
11. Click OK.

You can monitor files on a local or remote location. The probe monitors the files based on the settings you specify in the profile for the file.
Follow these steps:
1. In the File Monitoring tab, right-click and select New Profile.
4. Enter the Description of the monitoring profile.
Scan Directory
You can specify the details of the directory to be monitored by the probe.
Follow these steps:
1. Enter the Name of the directory where the files are scanned.
2. Browse for a directory or a location where the monitoring profile is scanned.
3. Select a specific Pattern of files where monitoring profiles are searched.
3.
Refer exchange_monitor Regular Expressions article for regex details.
4. Select Recurse into subdirectories to search for profiles in the subdirectories.
5. Select a Pattern where monitoring profiles are searched.
Refer exchange_monitor Regular Expressions article for regex details.
Note: The field appears only when Recurse into subdirectories is selected.
Alarm Message
You can specify the alarm message that is generated, if the defined threshold is breached when the probe is monitoring a file.
Number of files:
1. Selects the operator and enter the number of files to be monitored.
2. Select the Message ID, which is the alarm message the probe generates if the threshold is breached.
3. Select a clear message from the drop-down.
Space used by files
3. Select the message ID which is generated when the threshold is breached.
Size of file
3. Select the message ID which is generated when the threshold is breached.
5. Selects the size of the file to be monitored from the below options:
Smallest Files
Largest Files
Individual Files

You can define a QoS messages that are generated when the specified threshold is matched in the directory scanned by the probe.
Follow these steps:
1. Select Number of matching files to send QoS when the number of matching profiles matches with the specified value Expect this
value field.
2. Select Space Used by matching files in Kilobytes to send QoS when the space used by profiles matches with the value in Expect this
value field.
A profile for file monitoring is configured.
View DAG Details

You can view the details of the entire DAG (Data Availability Group) setup by using the DAG node.
Follow these steps:
1. Select DAG monitoring enabled in the General setup tab.
2. Click the DAG tab to view the DAG files.
2.
Note: The details of all the DAGs present in the current domain are displayed. You can view the name and server names
pertaining to DAG. Also the list of servers that are currently active.
3. Click a required DAG to view details of all servers that are present in the current domain.
4. Click a required server to view details of database copies residing on that server.
5. Click a required database to view its details.
6. Click OK.
7. You can view the DAG files of the required server.

You can configure the probe to monitor the growth of mailboxes on the exchange server.
Follow these steps:
1. Click the Setup > Mail growth node.
2. Enter the following field details in the Mailbox size (KB) section:
Check Mail Growth: indicates that the mailbox growth on the exchange server is checked.
Growth limit on each iteration: indicates the maximum limit for mailbox growth.
Iterations of growth before size alarm is issued: indicates the number of times of the mailbox growth exceeds the Check Interval valu
Check only mailboxes with size greater than: indicates a conditional value for checking the mailbox size.
Similarly, enter the field details in the Mailbox items section.
3. Click OK.
A mailbox is created.
Collect Reports
You can configure the probe to collect the reports on the data that is stored in database of the exchange server.
Follow these steps:
1. Click the Setup > Report Information section.
Note: Click the Force Update of Report Information to generate the report instantly.
4. Select Filter stores and database for other servers.

5. Select the database size.
Access Protocols
You can configure the probe to collect the reports on the data that is stored in database of the exchange server through Access Protocols.
Follow these steps:
1. Click the Setup > Report Information > Protocol Name Information .
2. Enter the field details for the desired Protocol:
HTTP Information
2.
User: Enter the username of the account.
Domain: Enter the domain for which the report has to be created.
Password: Enter the password for the account.
Similarly you can configure details for LDAP Identification and HTTP identification - for public folders
3. Click the test button to test their connection.
A report will be generated.
v5.1 exchange_monitor IM GUI Reference

This article describes the fields and features of the exchange_monitor probe.
Contents

The Setup Tab
The Status Tab
The DAG Tab
Deploy DAG
Exclude Instances

The Infrastructure Manager automatically downloads and installs the configuration interface, when the probe is deployed on a robot.
The Setup Tab
The Setup tab contains three sub-tabs and specifies the general properties for the probe.
Note: Two tabs Report information and Mailbox growth do not apply and are deactivated in this version.

General setup
Log level
Sets the level of details that are written to the log file. To minimize disk consumption and increase the amount of detail when debugging,
keep the log level low during normal operation.
Logfile size
Defines the maximum size of the log file in kilobytes.
Default: 100 KB.
Perfmon samples
The number of samples within the particular counter overwrite the number of samples in general Setup.
Note: Valid only for Perfmon counters.
Performance monitoring enabled

Enables monitoring of all profiles available of the perfmon probe.
The Performance check interval value is read from the perfmon probe.
Process monitoring enabled
Enables monitoring of all profiles available on the processes probe.
The Process check interval value can be specified in seconds.
Service monitoring enabled
Enables monitoring of all profiles available on the services probe.
The Service check interval value can be specified in seconds.
Event monitoring enabled
Enables monitoring of all profiles available on the ntevl probe.
The Event check interval value can be specified in seconds.
DAG monitoring enabled
Enables monitoring of DAG.
Note: Enable DAG related counters as they would not be activated by default. This feature can only be enabled on Exchange
Servers 2010.
Browse DAG script file
Specifies path of the CheckDatabaseRedundancy.ps1 script file. This script is required for DatabaseRedundancyCount counter.
If this script is not present, you can download it from:
http://gallery.technet.microsoft.com/office/8833b4db-8016-47e5-b747-951d28faafe7
Note: The file is also available on the exchange 2013 servers by default. Check in the folder <installation
directory>\Microsoft\Exchange Server\V15\Scripts on the system, where the Exchange Server is installed.
File/Dir Monitoring
Enables the file and directory monitoring for all profiles. Click this option to enable the user name, password, and check interval fields.
User name
Displays user name access folders that are shared on the network as well as locally. This user name overrides the user name in the File
Monitoring tab.
Password
Displays the password to access folders that have been shared on the network as well as locally. This password overrides the password
in the File Monitoring tab.
Check interval (seconds)
Selects or specifies the interval (in seconds) between each time the probe checks the Exchange server for file/directory monitoring.
Report information
For detailed log in information and its parameters defined in the tab, see the section.
Gather report information

Instructs the probe to make all gathered information available for the exchange_monitor_reports product.
Default: Disabled.
Note: Specify HTTP, VMI, and LDAP identifications successfully (Test them by clicking the corresponding test buttons to get
green indicators, to enable this option).
Force update of report information

Fetches the most current Exchange information.
Filter stores and databases for other servers
Instructs the probe to find and report only the databases and stores on the Exchange Server that is to be monitored. This ensures that
databases and stores on other Exchange Servers, but on the same domain are excluded.
Default: Selected
Database Size
The Exchange Server 2003 database consists of EDB file, SLV file, and Summary.
Reports the database size as a summary of these two files or the size of one of the two files.
Note: This field applies for Exchange Server 2003 only.
WMI Identification (2003 Server) Exchange cmd-let Identification (2007 Server)

Fetches the report information using WMI and Exchange cmd-let on Exchange server 2007. The following login information must be specified:
User
Domain
Password
Click the Test button to test the WMI/Exchange cmd-let login parameters specified.
LDAP identification
The report information is gathered from Active Directory (AD) using LDAP. The LDAP log in information must be specified:
AD Server
User
Note: Specify the username on the format <user name>@<domain name> or as the LDAP DN (Distinguished Name of the
user, for example: CN=Koert Struijk,OU=Users,OU=Nimsoft,DC=nimsoft,DC=no).
LDAP Test
Tests the specified LDAP login parameters
If your mailbox users and distribution groups are spread around in multiple domains, specify one Active Directory domain controller for
each domain using the Manage AD Servers dialog
Manage AD Servers
Specifies the LDAP login information for one AD Server.
Click this button to open the Manage AD Servers dialog. It enables you to manage several AD servers.
You can add servers and specify the LDAP login information (as described above) for each of them:
AD Server
User
Password
Base DN (LDAP BaseDN field)
Advanced (button)
Opens the LDAP connection properties dialog.
Connection type
Encrypts the communication between the probe and the Active Directory domain controller.
Non-standard LDAP port
Allows you to change the LDAP port numbers if you do not want to use the standard ports.
LDAP search timeout
Specifies the maximum number of seconds the probe is allowed to use on each LDAP search.
HTTP identification
The report information is gathered from the Exchange server, using WebDAV.
Note: This field applies only for Exchange Server 2003.
The following HTTP login information must be specified:

Server
User
Password
Clicking the Test button tests the HTTP login parameters specified.
Server requires https (SSL): Select this option if you want to use SSL. In that case you also must specify the SSL port to be used
(see below).
SSL port: The SSL port to be used if the Server requires https (see above) is selected.
Mailbox growth
Check mailbox growth
Select this option to make the probe check the growth of the mailboxes on the Exchange server.
Note: Select the Gather report information on the Report information tab to enable and the Mailbox tab.
Check interval
Specifies the interval (in seconds) between each time the probe checks the Exchange server for mailbox growth.
Mailbox size in Kilobytes
This parameter requires that the Check mailbox growth option is selected.
Growth limit on each iteration
Specifies the maximum allowed mailbox growth limit.
Only mailbox grows bigger than the specified number. These numbers are considered when counting the number of times the size
of a mailbox has increased. (see Iterations of growth before size alarm is issued).
Iterations of growth before size alarm is issued
The mailbox sizes are checked at the specified check interval.
If the size of a mailbox has increased iteratively the number of specified times here, a mailbox size alarm will be issued.
Check only mailboxes with size greater than
Check only the mailboxes with size greater than specified size.
The Status Tab
This tab lists the status of all checkpoints for all active profiles.
Note: DAG counters are not displayed in the Status tab.
Name
The name of the checkpoint
Note: The colored icon displays the severity level of the current measured values for profiles with a defined alarm threshold.
Group
The checkpoints are segregated into different logical groups, describing the kind of measurement the profile performs (such as memory,
disk, processor).
Type
Describes the type of checkpoint depending on which probe the checkpoint is retrieved:
Perf
Checkpoints from the perfmon probe
Service
Checkpoints from the services probe
Event
Checkpoints from the ntevl probe
Process
Checkpoints from the processes probe
Value
The most current value measured
Unit
The unit of the measured value, such as MB, %, and Mb/s
At
The time (<month> <day> <time>) the current value was measured.
Alarm limit
The defined threshold value for the profile. A breach of this value will result in an alarm message.
This tab contains the message pool, which is a list of predefined alarm messages. The messages can be referred to in specific profiles.
Right click for following commands in the message list:
Add Message
Creates a new message and opens with the Message properties window.
Message properties
Edit the selected Message.
Remove message
Delete the selected Message. You will be asked to confirm the deletion.
Message properties
Name
Specifies the unique name of the message. This name is used to refer to the message from the profiles.
Alarm situation
The message can be made the default message for a particular alarm situation. Leave this field empty if there is another default
message.
Text
Specifies the alarm message text. Supports variable expansion for the following variables:
Group
Profile
Value
Unit
Limit
Level
The severity assigned level to any alarm message.
Subsystem
The subsystem ID of generated alarms, a string or an ID is managed by NAS.
This tab lists all the monitoring profiles that are available in the probe configuration file. You can use the following types of monitoring profiles with
the exchange_monitor probe:
Service: To monitor services running on a system.
Process: To monitor services running on a system.
The File Monitoring tab consists of the profiles, which monitor the files present on the local or on a network location. This tab monitors the
profiles based on patterns selected in the profile and sends configured alarms and QoS.

Name
Indicates the name of the monitoring profile.
Active
Activates the profile.
Note: Active profiles appear in the profile list under the Profile Setup tab.
Description
Description for the monitoring profile.
Scan Directory
Directory
Name of the directory where the files are scanned for monitoring profiles.
Note: This is an optional field.
Browse
Browses for a directory/location where the monitoring profile is scanned.
Pattern
Pattern of files where monitoring profiles are searched.
Searches for profiles in the subdirectories.
Pattern
Pattern of files where monitoring profiles are searched.
User
The user required name for sharing a folder on network.
the shared folder.
Password
The required password to access a shared folder on network.
the shared folder.
Alarm Messages
The fields in the Number of Files tab are described here:
Expect this value: Selects the operator and the number of files.
Message clear: Selects the Message clear, which is populated in the drop-down from the Message Pool tab.
The following fields in the Space used by Files tab:
Expect this Value: Selects the operator, the size and number of files.
Message clear: Selects the Message, populated in the drop-down list from the Message Pool tab.
The following fields in the Size of File tab:
Watch Size of: Selects the size of the file from the below options:
Smallest Files
Largest Files
Individual Files
Number of Matching Profiles
Sends a QoS when the number of matching profiles is matched with the value specified in Expect this Value field.
Space Used by Matching Files in Kilobytes

Sends a QoS when the number of matching profiles is matched with the value in Expect this Value field.
The DAG Tab
DAG stands for Data Availability Group. You can view the details of the entire DAG setup by using the DAG tab.
When you click the DAG tab, the details of all the DAGs present in the current domain is displayed. You can view the name of the DAG, server
A DAG displays the details of all servers present in the current domain. It also shows the details of number of active databases, number of
passive databases, number of mounted database, number of non-mounted databases, and the status of the server (Up or Down) are displayed.
To view details of database copies residing on a particular server, click on that server.
You can view the server name, database name, database copy status, mailbox size, content index state, copy queue length, replay queue length,
and last inspected log.
Click on the data base to view its details.
Deploy DAG

You have to deploy the exchange_monitor probe on every exchange node of DAG Set up.
You have to enable the DAG Monitoring by selecting the check box for DAG Monitoring in the General Setup tab as well as enabling the
DAG counters in Profile Setup tab.
For DAG Monitoring, cluster probe is not required to monitor.
Deploy exchange_monitor probe on each exchange server. Exchange_monitor probe will monitor exchange server on which it is deployed
as well and the database copies residing on the server. However, In DAG tab of the probe GUI, you will be able to view status of all the exchange
servers of all DAGs in current domain.
Exclude Instances
A monitoring profile can have multiple instances. If you do not want the probe to monitor an instance within a profile, you can exclude the
instance.
The Exclude Instances button appears in the Profile Properties dialog when the following conditions are met while the probe reads the instance
and object keys from the configuration file:
The object is for a perf profile.
The value of the profile instance key is instance = <all>.

Specify users for WMI, LDAP and HTTP in the Setup Tab. You can use 3 different users or the same user.
This section describes the requirements that have to be met to enable the probe to collect data. However that the setup may vary depending on
your forest setup and group policies.
LDAP
This user must be authorized to log into your Active Directory using the LDAP protocol.
This user requires read access to the configurationNamingContext and specifically the administrative group entry in your active directory, where
exchange servers store most information.
To add these access rights to a user, open the Exchange System Manager, right click on your administrative group, which contains the server(s)
you want to access, and choose Delegate control. Add your LDAP user to the Exchange View Only Administrator role.
User name syntaxes in Active Directory (AD).
Four known syntaxes are valid when authenticating against Active Directory using LDAP protocol, simple binds.
1. Full DN, e.g.
CN=Ben Talk,OU=West,OU=Users,DC=domain,DC=com
2. NT Account Name (e.g. NIMCLUS\e1john)
3. User Principal Name (UPN), in the userPrincipalName attribute of the user in Active Directory .
4. Plain username (e.g. user), in the display Name attribute in Active Directory
For option 2 and 3, see the image below.
Right-click the user in MMC snapin Active Directory Users and Computers, and click Properties and choose the Account tab.
For option 4, see the figure below.
For option 1, you need to use another tool, such as ADSIEDIT.MSC, LDP or any other LDAP browser tool. It is not possible to our knowledge, to
view the distinguishedName property of an object through the MMC snapin "Active Directory Users and Computers".
It is recommended to use the NT Account Name or UPN syntax.
Active Directory enforces/ensures that a users' sAMAccountName property is unique within a Active Directory forest. The domain NETBIOS name
is also enforced to be unique.
Note: UPN is not guaranteed to be unique in Active Directory forest. If two or more users have the same UPN, none of them will be
able to authenticate using the UPN name.
The same goes for plain username. It need to be unique within a forest.
WMI User
The probe will execute the "report collector" program as a background process, in the context of this user (i.e. "Run as"). This user context
will be used when connecting to the exchange shares and WMI queries.
You must be member of the domain security group named "Exchange Servers".
You must be added to the "local administrators" group on the machine running the exchange server.
You must also be delegated control of the "Exchange View Only administrator" role.
Note: Run your exchange servers in a cluster. You must add the WMI monitoring account to the local administrators group of all those
nodes that can be owners of your virtual exchange servers.
You must Reboot your exchange server in order for this effect to take place.
HTTP (WebDav) user permissions.
Your permission will be required when contacting the exchange server to query for public folder information, with WebDAV (http) protocol
against the IIS (Outlook Web Access (OWA) also uses WebDAV).
You require at least these client permissions (Read permissions, List Contents and Read Property) on the folders in the folder hierarchy.
HTTP users will be used in the WebDAV protocol over http to talk to IIS, where the public folders is hosted and reachable. Data for the "public
folder owner" report is gathered here.
The actual list of public folders is retrieved through WMI.
WMI - the exchange_monitor probes starts a background process in the context of the WMI user (i.e. Run as command). The probe context is
used when accessing the WMI namespaces on the server running the exchange server.
In the WMI namespace root\MicrosoftExchangeV2, Exchange Server 2003 exposes several classes. The data collector retrieves instances of the
following wmi classes.
Exchange_PublicFolder - instances of public folders, and public folder replication information (to which stores are the folders replicated)
Exchange_Server - instance of the server
Exchange_Mailbox - instances of mailboxes (sizes, deleted items, item count)
Exchange_MessageTrackingEntry - message tracking entries
In the WMI namespace root\CIMV2, instances of the following classes are read:
Win32_NTLogEvent - whitespace information
LDAP - or Active Directory - will be queried to read additional information about the Exchange Server configuration. In
the configurationNamingContext - exchange server information and structure of storage groups, stores (both public and mailbox) and db
quotas.
One or more domains can be queried for distribution lists and its members.
Queries are made to retrieve users who belong to the storage groups we found in the configurationNamingContext.
Users mailboxes, mail addresses, delegates, memberOfs, account control, password last set.
It is then all tied together before it is stored and ready to be retrieved from the exchange_monitor_backend probe.
The report collector will also try to access the database files directly (the .edb files), and read the physical size of the files. The information about
where the physical files are stored, is part of the information retrieved from configurationNamingContext.
The reports have been divided into 10 sub reports, exchange_monitor point of view. The data collected is controlled and cannot be changed.
They are:
Traffic_summary, updated when data is older than 24 hours or at midnight.
Public_folders, updated when data is older than 24 hours or at midnight.
Domains, updated when data is older than 24 hours or at midnight.
Servers, updated when data is older than 24 hours or at midnight.
Mailboxes, updated when data is older than 10 minutes if you have enabled "monitor mailbox growth", otherwise it should be 60 minutes.
Display_names, updated when mailboxes are updated.
Partners, updated when data is older than 24 hours or at midnight.
Mailbox_activity, updated when data is older than 24 hours or at midnight.
Groups, updated when mailboxes are updated.
Databases, updated when data is older than 24 hours or at midnight.
The exchange_monitor_backend probe querries and checks the timestamps of all these reports. If the exchange_monitor probe being queried has
newer information on any of the reports, it will be collected by the backend and inserted into the SQL database. The exchange_monitor_backend
operates on the same aging policy as the exchange_monitor probe. It will not query that server again for 1 hour, if it has all the data it needs from
1 server, before the mailbox data is considered old. This means that if the exchange_monitor cant for some reason read e.g. the message
tracking logs, the backend will not get an accurate timestamp and will keep querying the exchange_monitor probe until it provides new data, once
the exchange_monitor_backends data for the reports regarding traffic is older than 24 hours.
It is important to set up the report collection and ensure that all the reports receive data, otherwise your probes will be using more network
bandwidth than necessary.

To execute the cmdlet on the Exchange server, you should have Exchange View-Only Administrators rights. In addition to this, you need to
add Exchange View-Only Administrators group to Allow log in locally policy of the Exchange server.
To achieve this, go to Security Settings and click User Rights Assignment. All the policies will be listed in the right pane. Double-click on Allow
log in locally and add 'Exchange View-Only Administrators group.
You also need to give read/write access permissions to the probe folder so that the data collector can write the data to the cfg file and the log file.
exchange_monitor Supported Counters

This article describes the counters that are supported with the probe.
Notes:
From exchange_monitor 5.0 version onwards, only server specific counters will be loaded in the Profile setup tab.
Exchange Server 2003 is not supported with the probe version 5.2 or later.
Contents:
DAG Counters
Performance Counters - Support for Exchange Server Versions
Services Counters - Support for Exchange Server Versions
DAG Counters
The following table describes the DAG counters, which are supported on DAG Exchange Server 2010 and DAG Exchange Server 2013:
Counter Name
Description
DAG
Exchange
Server
2010
DAG
Exchange
Server
2013
Number of active Database copies
Number of active database copies on current exchange server.
Yes
Yes
Number of passive database copies on current Mailbox server.
Yes
Yes
Number of mounted database copies on current Mailbox server.
Yes
Yes
Number of Non Mounted Database

copies
Number of database copies whose state is not "mounted" on current Mailbox server
Yes
Yes
CopyQueueLength-DAG
Shows the number of transaction log files waiting to be copied to the passive copy log
file folder. A copy isn't considered complete until it has been checked for corruption.
Yes
Yes
Shows the number of transaction log files waiting to be replayed into the passive copy.
Yes
Yes
Database copies status-Failed
The mailbox database copy is in a Failed state because it isn't suspended, and it isn't
able to copy or replay log files. While in a Failed state and not suspended, the system
will periodically check whether the problem that caused the copy status to change to
Failed has been resolved. After the system has detected that the problem is resolved,
and barring no other issues, the copy status will automatically change to Healthy.
Yes
Yes
Database copies status-Seeding
The mailbox database copy is being seeded, the content index for the mailbox
database copy is being seeded, or both are being seeded. Upon successful completion
of seeding, the copy status should change to Initializing.
Yes
Yes
Database copies status-SeedingSource
The mailbox database copy is being used as a source for a database copy seeding
operation.
Yes
Yes
Database copies status-Suspended
The mailbox database copy is in a Suspended state as a result of an administrator

manually suspending the database copy by running the
Suspend-MailboxDatabaseCopy cmdlet.
Yes
Yes
Database copies status-Healthy
The mailbox database copy is successfully copying and replaying log files, or it has
successfully copied and replayed all available log files.
Yes
Yes
Database copies status-ServiceDown
The Microsoft Exchange Replication service isn't available or running on the server that
hosts the mailbox database copy.
Yes
Yes
Database copies status-Initializing
The mailbox database copy will be in an Initializing state when a database copy has
been created, when the Microsoft Exchange Replication service is starting or has just
been started, and during transitions from Suspended, ServiceDown, Failed, Seeding,
SinglePageRestore, LostWrite, or Disconnected to another state. While in this state, the
system is verifying that the database and log stream are in a consistent state.
In most cases, the copy status will remain in the Initializing state for about 15 seconds,
but in all cases, it should generally not be in this state for longer than 30 seconds.
Yes
Yes
Database copies status-Resynchronizing
The mailbox database copy and its log files are being compared with the active copy of
the database to check for any divergence between the two copies. The copy status
will remain in this state until any divergence is detected and resolved.
Yes
Yes
Database copies status-Mounted
The active copy is online and accepting client connections. Only the active copy of the
mailbox database copy can have a copy status of Mounted.
Yes
Yes
Database copies status-Dismounted
The active copy is offline and not accepting client connections. Only the active copy of
the mailbox database copy can have a copy status of Dismounted.
Yes
Yes
Database copies status-Mounting
The active copy is coming online and not yet accepting client connections. Only the
active copy of the mailbox database copy can have a copy status of Mounting.
Yes
Yes
Database copies status-Dismounting
The active copy is going offline and terminating client connections. Only the active copy
of the mailbox database copy can have a copy status of Dismounting.
Yes
Yes
Database copies
status-DisconnectedAndHealthy
The mailbox database copy is no longer connected to the active database copy, and it
was in the Healthy state when the loss of connection occurred. This state represents
the database copy with respect to connectivity to its source database copy. It may be
reported during DAG network failures between the source copy and the target database
copy.
Yes
Yes
Database copies
status-DisconnectedAndResynchronizing
The mailbox database copy is no longer connected to the active database copy, and it
was in the Resynchronizing state when the loss of connection occurred. This state
represents the database copy with respect to connectivity to its source database copy.
It may be reported during DAG network failures between the source copy and the target
database copy.
Yes
Yes
Database copies
status-FailedAndSuspended
The Failed and Suspended states have been set simultaneously by the system
because a failure was detected, and because resolution of the failure explicitly requires
administrator intervention. An example is if the system detects unrecoverable
divergence between the active mailbox database and a database copy. Unlike the
Failed state, the system won't periodically check whether the problem has been
resolved, and automatically recover. Instead, an administrator must intervene to resolve
the underlying cause of the failure before the database copy can be transitioned to a
healthy state.
Yes
Yes
Database copies
status-SinglePageRestore
This state indicates that a single page restore operation is occurring on the mailbox
database copy.
Yes
Yes
Last Inspected Log Time
The modification time of the last log that was successfully validated by the Mailbox
server hosting the database copy.
Yes
Yes
ContentIndexState
Indicates the current state of the content index for a database copy.
Yes
Yes
ActivationSuspended
Indicates whether activation of mailbox database copy is suspended.
Yes
Yes
DatabaseSize
Size of Database copy.
Yes
Yes
Count of redundancy of replicated mailbox databases. Both active and passive copies
are counted when determining redundancy.
Yes
No
clusterservice
Verifies that the Cluster service is running and reachable on the local exchange server.
Yes
Yes
ReplayService
Verifies that the Replay service is running and reachable on the local exchange server.
Yes
Yes
ActiveManager
Verifies that the instance of Active Manager running on the local Exchange server is in
a valid role (primary, secondary, or stand-alone).
Yes
Yes
TasksRpcListener
Verifies that the tasks remote procedure call (RPC) server is running and reachable on
the local Exchange server.
Yes
Yes
TcpListener
Verifies that the TCP log copy listener is running and reachable on the local Exchange
server.
Yes
Yes
DagMembersUp
Verifies that all DAG members are available, running, and reachable.
Yes
Yes
ClusterNetwork
Verifies that all cluster-managed networks on the local Exchange server are available.
Yes
Yes
QuorumGroup
Verifies that the default cluster group (quorum group) is in a healthy and online state.
Yes
Yes
FileShareQuorum
Verifies that the witness server and witness directory and share configured for the DAG
are reachable.
Yes
Yes
DBLogCopyKeepingUp
Verifies that log copying and inspection by the passive copies of databases on the local
exchange server are able to keep up with log generation activity on the active copy.
Yes
Yes
DBLogReplayKeepingUp
Verifies that replay activity for the passive copies of databases on the local exchange
server is able to keep up with log copying and inspection activity.
Yes
Yes
stale security information -Quorum

Group
The database availability group is experiencing problems that may cause it to fail due to
stale security information.
Yes
Yes
DAG Network Down
One or more networks supporting the database availability group are not operating
properly on this server.
Yes
Yes
Note: You have to activate the DAG counters by enabling them individually from Profile Setup tab. All the DAG counters are supported
on DAG Exchange Server 2010 and DAG Exchange Server 2013, except DatabaseRedundancyCountcounter is not supported on
DAG Exchange Server 2013.
Performance Counters - Support for Exchange Server Versions

The following table describes the performance counters, which are supported on Exchange Server 2003, Exchange Server 2007, Exchange
Server 2010, and Exchange Server 2013:
Counter Name
Exchange Server
2003
Exchange Server
2007
Exchange Server
2010
Exchange Server
2013
Work Queue Length
Yes
No
No
No
Messages Per Second
Yes
No
No
No
Connection Queue Length
Yes
No
No
No
Average Queue Time
Yes
No
No
No
User Count
Yes
No
Yes
No
Folder Opens Per Second - Public Folders
Yes
Yes
No
No
Folder Opens Per Second - PF
Yes
Yes
No
No
Message Opens Per Second - Public Folders
Yes
Yes
No
No
Message Opens Per Second - PF
Yes
Yes
No
No
Send Queue Size - Public Folders
Yes
No
No
No
Send Queue Size - PF
Yes
No
No
No
Receive Queue Size - Public Folders
Yes
Yes
No
No
Receive Queue Size - PF
Yes
Yes
No
No
Folder Options per second - Mailboxes
Yes
Yes
No
No
Folder Options per Second - MBX
Yes
Yes
No
No
Message Opens per Second - MBX
Yes
Yes
No
No
Send Queue Size - Mailboxes
Yes
No
No
No
Send Queue Size - MBX
Yes
No
No
No
Receive Queue Size - Mailboxes
Yes
Yes
No
No
Receive Queue Size - MBX
Yes
Yes
No
No
Local Queue Length
Yes
No
No
No
Remote Queue Length
Yes
No
No
No
Messages Delivered per Second
Yes
No
No
No
Messages Received per Second
Yes
No
No
No
Available Megabytes
Yes
Yes
No
No
Pages Per Second
Yes
Yes
Yes
Yes
Pool Nonpaged Megabytes
Yes
Yes
Yes
Yes
Page Faults Per Second
Yes
Yes
No
No
Virtual Megabytes used by Information Store
Yes
No
No
No
VM Largest Block Size - Information Store
Yes
No
No
No
Paging File Usage
Yes
Yes
No
No
Processor Time - mad
Yes
Yes
No
No
Elapsed Time - mad
Yes
Yes
No
No
Processor Time - store
Yes
Yes
No
No
Elapsed Time - store
Yes
Yes
No
No
Processor Time - emsmta
Yes
No
No
No
Elapsed Time - emsmta
Yes
No
No
No
Processor Time - system
Yes
Yes
No
No
Processor Time - inetinfo
Yes
Yes
No
No
Processor Time - lsass
Yes
Yes
No
No
Processor Time
Yes
Yes
Yes
Yes
Percent Disk Time
Yes
Yes
No
No
Average Disk Queue Length
Yes
Yes
No
No
Average Disk Read Queue Length
Yes
Yes
No
No
Average Disk Write Queue Length
Yes
Yes
No
No
Average Disk Bytes per Transfer
Yes
Yes
No
No
Average Disk seconds per Read
Yes
Yes
No
No
Average Disk Seconds per Write
Yes
Yes
Yes
Yes
Kilobytes Total Per second
Yes
Yes
Yes
Yes
Kliobytes sent Per second
Yes
Yes
No
No
Kilobytes Received Per second
Yes
Yes
No
No
Current Bandwidth
Yes
Yes
No
No
Kilobytes Total per second - Redirector
Yes
Yes
No
No
Errors Per second
Yes
Yes
No
No
VM Total 16MB Free Blocks
Yes
No
No
No
VM total Large Free Block Megabytes
Yes
No
No
No
Open connections to Global Catalogs
No
Yes
No
No
Connections on IP Allow List Providers per second
No
Yes
No
No
Connections on the IP Allow List per second
No
Yes
No
No
Connections on IP Block List Providers per second
No
Yes
No
No
Connections on IP Block List per second
No
Yes
No
No
Messages with Originating IP on IP Allow List Providers per

second
No
Yes
No
No
Messages with Originating IP on IP Allow List per second
No
Yes
No
No
Messages with Originating IP on IP Block List Providers per

second
No
Yes
No
No
Messages with Originating IP on IP Block List per second
No
Yes
No
No
Messages Scanned per second (content filter agent)
No
Yes
No
No
Average agent processing time in seconds per event
No
Yes
No
No
Recipients Rejected by block list per second
No
Yes
No
No
Recipients Rejected by Recipient Validation per second
No
Yes
No
No
Messages Evaluated By Sender Filter Per Second
No
Yes
No
No
Messages Filtered By Sender Filter Per Second
No
Yes
No
No
Messages Missing Originating IP per second (Agent_ID)
No
Yes
No
No
Messages Validated per second
No
Yes
No
No
Messages with no PRA per second
No
Yes
No
No
DNS Queries per second
No
Yes
No
No
Dumpster delete per second
No
Yes
Yes
No
Dumpster insert per second
No
Yes
Yes
No
Dumpster item count
No
Yes
Yes
No
Dumpster size
No
Yes
Yes
No
Active Mailbox Delivery Queue length
No
Yes
No
No
Active non-smtp Delivery Queue Length
No
Yes
No
No
Active Remote Delivery Queue Length
No
Yes
No
No
Aggregate Delivery Queue Length (All Queues)
No
Yes
No
No
Items Queued for Delivery
No
Yes
No
No
Messages queued for Delivery
No
Yes
No
No
Messages queued for delivery per second
No
Yes
Yes
No
Messages submitted per second
No
Yes
Yes
No
Poison Queue Length
No
Yes
No
No
Retry Mailbox Delivery Queue Length
No
Yes
No
No
Unreachable Queue Length
No
Yes
No
No
Connections Current (inbound)
No
Yes
No
No
Connections Current (outbound)
No
Yes
No
No
Messages Received per second (inbound)
No
Yes
No
No
Messages Sent per second (outbound)
No
Yes
No
No
Edge Servers total
No
Yes
No
No
Exchange Servers Total
No
Yes
No
No
Hub transport Servers Total
No
Yes
No
No
Average Delivery Time
No
Yes
No
No
Categorization Count
No
Yes
No
No
Logon Operations per second
No
Yes
No
No
Message Recipients Delivered per second
No
Yes
No
No
Messages queued for submission
No
Yes
No
No
Messages sent per sec
No
Yes
No
No
Average Request Time (ActiveSync)
No
Yes
No
No
Requests per sec (ActiveSync)
No
Yes
Yes
Yes
Sync commands per second (ActiveSync)
No
Yes
Yes
Yes
Active Conversions
No
Yes
No
No
Current User Count
No
Yes
No
No
Requests per second failed
No
Yes
No
No
Proxy User Requests per second
No
Yes
No
No
Queued Conversion Requests
No
Yes
No
No
Requests per sec
No
Yes
No
No
Current Connections (IMAP4)
No
Yes
No
No
Current Connections (POP3)
No
Yes
No
No
Average Response Time (WS)
No
Yes
No
No
Requests per second (WS)
No
Yes
Yes
Yes
Average Response Time (OWA)
No
Yes
No
No
User Time
No
No
Yes
Yes
Privileged time
No
No
Yes
Yes
Processor Time Instance
No
No
Yes
Yes
No
No
Yes
Yes
Available Mbytes
No
No
Yes
Yes
Pool Paged Bytes
No
No
Yes
Yes
Cache Bytes
No
No
Yes
Yes
Committed Bytes
No
No
Yes
Yes
Committed Bytes in Use
No
No
Yes
Yes
Transition Pages Repurposed per second
No
No
Yes
Yes
Page Reads per Second
No
No
Yes
Yes
Pages Input per Second
No
No
Yes
Yes
Pages Output per Second
No
No
Yes
Yes
Private Bytes
No
No
Yes
Yes
Virtual bytes
No
No
Yes
Yes
Working Set
No
No
Yes
Yes
Handle Count
No
No
Yes
Yes
DOTNET - Time in GC
No
No
Yes
Yes
DOTNET - Exception Thrown per sec
No
No
Yes
Yes
DOTNET - Bytes in All Heaps
No
No
Yes
Yes
Packets Outbound Errors
No
No
Yes
Yes
TCPv4 Connection Established
No
No
Yes
Yes
TCPv6 Connection Failures
No
No
Yes
Yes
TCPv4 Connections Reset
No
No
Yes
Yes
No
No
Yes
Yes
LDAP Searches Per Second
No
No
Yes
Yes
LDAP Read Time Controllers
No
No
Yes
Yes
LDAP Search Time Controllers
No
No
Yes
Yes
LDAP Read Time Processes
No
No
Yes
Yes
LDAP Search Time Processes
No
No
Yes
Yes
LDAP Searches Timed Out Per Minute
No
No
Yes
Yes
Long Running LDAP Operations Per Minute
No
No
Yes
Yes
Database Reads (Attached) Average Latency
No
No
Yes
Yes
Database Writes (Attached) Average Latency
No
No
Yes
Yes
Database Page Fault Stalls Per Sec
No
No
Yes
Yes
Log Writes Average Latency
No
No
Yes
Yes
Log Record Stalls Per second
No
No
Yes
Yes
Log Threads Waiting
No
No
Yes
Yes
Database Reads (Recovery) Average Latency
No
No
Yes
Yes
Database Writes (Recovery) Average Latency
No
No
Yes
Yes
Log Reads Average Latency
No
No
Yes
Yes
RPC Requests - Mailbox
No
No
Yes
No
RPC Average Latency
No
No
Yes
No
RPC Average Latency - Mailbox
No
No
Yes
No
RPC Average Latency - Client
No
No
Yes
No
Client Reported Failed RPCs for Server too busy Error per
second
No
No
Yes
No
Client Reported Failed RPCs for Server too Busy Error
No
No
Yes
No
Messages Queued for Submission Mailbox
No
No
Yes
No
Messages Queued for Submission Public
No
No
Yes
No
Log Generation checkpoint Depth
No
No
Yes
Yes
Database Page Fault Stalls Per Sec - Information Store
No
No
Yes
Yes
Log Record Stalls per second - Information Store
No
No
Yes
Yes
Log Threads Waiting - Information Store
No
No
Yes
Yes
Version buckets allocated - Information Store
No
No
Yes
Yes
Database Reads Average Latency
No
No
Yes
Yes
Database Writes Average Latency
No
No
Yes
Yes
Database Cache Size - Information Store
No
No
Yes
Yes
Database Cache Percentage hit
No
No
Yes
Yes
Log Bytes Write Per sec
No
No
Yes
Yes
Slow FindRow Rate
No
No
Yes
No
Search Task Rate
No
No
Yes
No
Slow QP Threads
No
No
Yes
No
Slow Search Threads
No
No
Yes
No
Processor Time- MS Exchange Search Service
No
No
Yes
No
Processor Time - Msmtefd Process
No
No
Yes
No
Recent Average Latency of RPCs Used to Obtain Content
No
No
Yes
No
Average Document Indexing Time
No
No
Yes
No
Full Crawl Mode Status
No
No
Yes
No
Processor Time - Mailbox Assistants
No
No
Yes
Yes
Events in Queue
No
No
Yes
Yes
Average Event Processing time In Seconds
No
No
Yes
Yes
Average Resource Booking Processing Time
No
No
Yes
Yes
Requests Failed - Resource Booking
No
No
Yes
Yes
Average Calendar Attendant Processing Time
No
No
Yes
Yes
Requests Failed - Calendar Attendant
No
No
Yes
Yes
RPC Latency Average - Store Interface
No
No
Yes
Yes
ROP Requests Outstanding
No
No
Yes
Yes
RPC Requests Outstanding
No
No
Yes
Yes
RPC Requests Outstanding Instance
No
No
Yes
Yes
RPC Requests Sent Per Sec
No
No
Yes
Yes
RPC Slow Requests Latency Average
No
No
Yes
Yes
RPC Slow Requests Failed Percentage
No
No
Yes
Yes
RPC Slow Requests Percentage
No
No
Yes
Yes
Successful Submissions Per Second
No
No
Yes
No
Hub Servers in Retry
No
No
Yes
No
Failed Submissions Per Sec
No
No
Yes
No
Temporary Failures Submission per second
No
No
Yes
No
CopyQueueLength
No
No
Yes
Yes
Replay Queue Length
No
No
Yes
Yes
Seeding Finished Percentage
No
No
Yes
No
RPC Operations Per Sec
No
No
Yes
No
RPC Client Backoff Per Sec
No
No
Yes
No
Failed Client RPCs for Server Too Busy Per Sec
No
No
Yes
No
Failed Client RPCs for Server Too busy
No
No
Yes
No
RPC Operations Per Sec - MSExchangeIS Client
No
No
Yes
No
JET Log Records Per Sec
No
No
Yes
No
JET Pages Read Per Sec
No
No
Yes
No
Directory Access LDAP Reads Per Sec
No
No
Yes
No
Directory Access LDAP Searches Per Sec
No
No
Yes
No
Messages Delivered Per Sec - Mailbox
No
No
Yes
No
Messages Sent Per Sec - Total
No
No
Yes
No
Messages Submitted Per Sec
No
No
Yes
No
Replication Receive Queue Size
No
No
Yes
No
Mailboxes Processed Per Sec
No
No
Yes
Yes
Events Polled Per Sec
No
No
Yes
Yes
Average Search Time
No
No
Yes
Yes
Application Restarts
No
No
Yes
Yes
Worker Process Restarts
No
No
Yes
Yes
Request Wait Time
No
No
Yes
Yes
Requests in Application Queue
No
No
Yes
Yes
Average Time to Process A Free Busy Request
No
No
Yes
Yes
Sync Commands Pending
No
No
Yes
Yes
Requests Queued
No
No
Yes
No
Number of Failed Back-End Connection Attempts Per

Second
No
No
Yes
No
Current Number of Incoming RPC over HTTP Connections
No
No
Yes
Yes
Current Number of Unique Users
No
No
Yes
Yes
RPC - HTTP Requests Per Sec
No
No
Yes
Yes
RPC Averaged Latency - RpcClientAccess
No
No
Yes
Yes
RPC Operations Per Sec - RpcClientAccess
No
No
Yes
Yes
RPC Requests - RpcClientAccess
No
No
Yes
Yes
NSPI RPC Browse Requests Average Latency
No
No
Yes
Yes
NSPI RPC Requests Average Latency
No
No
Yes
Yes
Referral RPC Requests Average Latency
No
No
Yes
Yes
Outbound Proxy Requests for Average Response Time
No
No
Yes
Yes
Requests Average Response Time
No
No
Yes
Yes
Download Task Queued
No
No
Yes
No
Download Tasks Completed
No
No
Yes
No
Ping Commands Pending
No
No
Yes
Yes
Availability Requests in Seconds
No
No
Yes
Yes
Current Unique Users
No
No
Yes
Yes
Autodiscover Service Requests Per Sec
No
No
Yes
Yes
Current Connections
No
No
Yes
Yes
Connection Attempts Per Sec
No
No
Yes
Yes
ISAPI Extension Requests Per Sec
No
No
Yes
Yes
Other Request Methods Per Sec
No
No
Yes
Yes
Average Disk Seconds Per Read-Transport
No
No
Yes
Yes
Average Disk Seconds Per Write-Transport
No
No
Yes
Yes
Submission Queue Length
No
No
Yes
Yes
Retry Non-Smtp Delivery Queue Length
No
No
Yes
Yes
Retry Remote Delivery Queue Length
No
No
Yes
No
Largest Delivery Queue Length
No
No
Yes
No
Poison Queue Length - Transport
No
No
Yes
Yes
Input-Output Log Writes Per Sec
No
No
Yes
Yes
Input-Output Log Reads Per Sec
No
No
Yes
Yes
Log Generation Checkpoint Depth-Transport
No
No
Yes
Yes
Version Buckets Allocated
No
No
Yes
Yes
Input-Output Database Reads Per Sec
No
No
Yes
Yes
Input-Output Database Writes Per Sec
No
No
Yes
Yes
Log Record Stalls Per Sec-Transport
No
No
Yes
Yes
Log Threads Waiting - Transport
No
No
Yes
Yes
Total Agent Invocations
No
No
Yes
Messages Completed Delivery Per Sec
No
No
Yes
Yes
Inbound LocalDeliveryCallsPerSecond
No
No
Yes
No
Outbound Submitted Mail Items Per Second
No
No
Yes
No
Average Bytes Per Message
No
No
Yes
No
Messages Received Per Sec-Transport
No
No
Yes
No
Messages Sent Per Sec - Transport
No
No
Yes
No
Inbound MessageDeliveryAttemptsPerSecond
No
No
Yes
No
Inbound Recipients Delivered Per Second
No
No
Yes
No
Average Agent Processing Time In Seconds
No
No
Yes
No
Active Mailbox Delivery Queue Length - Transport
No
No
Yes
Yes
Active Remote Delivery Queue Length - Transport
No
No
Yes
No
Aggregate Delivery Queue Length (All Queues) - Transport
No
No
Yes
No
Active Non-Smtp Delivery Queue Length - Transport
No
No
Yes
Yes
Retry Mailbox Delivery Queue Length - Transport
No
No
Yes
Yes
Unreachable Queue Length - Transport
No
No
Yes
Yes
Input-Output Log Read Average Latency
No
No
Yes
No
Database Mounted
No
No
Yes
Yes
Age of the Last Notification Indexed
No
No
Yes
No
Input-Output Log Writes Average Latency
No
No
Yes
Yes
Time Since Last Notification Was Indexed
No
No
Yes
No
Exchange search zero result query
No
No
Yes
No
Logical Disk Percentage Free Space
No
No
Yes
Yes
Inbound: LocalDeliveryCallsPerSecond-2013
No
No
No
Yes
Inbound: MessageDeliveryAttemptsPerSecond-2013
No
No
No
Yes
Inbound: Recipients Delivered Per Second-2013
No
No
No
Yes
Outbound: Submitted Mail Items Per Second-2013
No
No
No
Yes
Messages Submitted Per Second - Information Store
No
No
No
Yes
Messages Delivered Per Sec - Store
No
No
No
Yes
Number Of Failed Back-End Connection Attempts Per

Second-2013
No
No
Yes
No
OAB Request Handling Average Time
No
No
No
Yes
Anti-Malware Agent Messages Scanned
No
No
No
Yes
Anti-Malware Agent Messages Scanned Per Second
No
No
No
Yes
Anti-Malware Agent Messages Containing Malware
No
No
No
Yes
Anti-Malware Agent Messages Blocked
No
No
No
Yes
Mailbox Searches Per Sec - Store
No
No
No
Yes
Anti-Malware Agent Recovery Written to Recovery Store
No
No
No
Yes
RPC - HTTP Requests Per Second
No
No
Yes
Yes
Log Bytes Write Per Sec
No
No
Yes
Yes
RPC Requests Failed Percentage
No
No
Yes
Yes
DatabaseMounted
No
No
Yes
Yes
TCPv4 Connections Established
No
No
Yes
Yes
Messages Completed Delivery Per Second
No
No
Yes
Yes
Failure DNS Total
No
No
No
Yes
Alertable failure DSNs within the last hour
No
No
No
Yes
Hub Selection Resolver Failures
No
No
No
Yes
No
No
No
Yes
No
No
No
Yes
Percent Availability
No
No
No
Yes
Percent Failures Due To MaxInboundConnectionLimit
No
No
No
Yes
Percent Failures Due To WLID Down
No
No
No
Yes
Percent Failures Due To Back Pressure
No
No
No
Yes
No
No
No
Yes
Connections Created per second
No
No
No
Yes
Messages Received per second
No
No
No
Yes
No
No
No
Yes
Messages Sent per second
No
No
No
Yes
No
No
No
Yes
DNS Errors
No
No
No
Yes
Connection Failures
No
No
No
Yes
Protocol Errors
No
No
No
Yes
Inbound_LocalDeliveryCallsPerSecond
No
No
No
Yes
Inbound_MessageDeliveryAttemptsPerSecond
No
No
No
Yes
Inbound_Recipients_Delivered_Per_Second
No
No
No
Yes
MessagesFailedToRoute
No
No
No
Yes
No
No
No
Yes
No
No
No
Yes
No
No
No
Yes
Percentage Proxy Setup Failures
No
No
No
Yes
Total Proxy User Lookup Failures
No
No
No
Yes
Total Proxy Dns Lookup Failures
No
No
No
Yes
Total Proxy Connection Failures
No
No
No
Yes
Total Bytes Proxied
No
No
No
Yes
No
No
No
Yes
Percent Failures Due To MaxInboundConnectionLimit
No
No
No
Yes
Percent Failures Due To Active Directory Down
No
No
No
Yes
Connections Created/sec
No
No
No
Yes
Connections Created per second for inbound proxy

messages
No
No
No
Yes
Inbound Messages Received/sec
No
No
No
Yes
Inbound Message Bytes Received/sec
No
No
No
Yes
No
No
No
Yes
Message Bytes Sent/sec
No
No
No
Yes
Recipients sent
No
No
No
Yes
DNS Errors
No
No
No
Yes
Connection Failures
No
No
No
Yes
Average Agent Processing Time (sec)
No
No
No
Yes
Services Counters - Support for Exchange Server Versions

The following table describes the services counters, which are supported on Exchange Server 2003, Exchange Server 2007, Exchange Server
2010, and Exchange Server 2013:
Counter Name
Exchange Server
2003
Exchange Server
2007
Exchange Server
2010
Exchange Server
2013
HTTP SSL
No
Yes
No
No
IIS Admin Service
No
Yes
No
No
Microsoft Exchange Active Directory Topology Service
No
Yes
Yes
Yes
Microsoft Exchange ADAM
No
Yes
Yes
No
Microsoft Exchange Address Book
No
No
Yes
No
Microsoft Exchange Anti-spam Update
No
Yes
Yes
Yes
Microsoft Exchange Credential Service
No
Yes
Yes
No
Microsoft Exchange Diagnostics
No
No
No
Yes
Microsoft Exchange EdgeSync
No
Yes
Yes
Yes
Microsoft Exchange File Distribution
No
Yes
Yes
No
Microsoft Exchange Forms-Based Authentication
No
No
Yes
No
Microsoft Exchange Frontend Transport
No
No
No
Yes
Microsoft Exchange IMAP4
Yes
Yes
Yes
No
Microsoft Exchange IMAP4 Backend
No
No
No
Yes
Microsoft Exchange IMAP4-2013
No
No
No
Yes
Microsoft Exchange Information Store
Yes
Yes
Yes
Yes
Microsoft Exchange Mail Submission
No
Yes
Yes
No
Microsoft Exchange Mailbox Assistants
No
Yes
Yes
Yes
Microsoft Exchange Mailbox Replication Service
No
No
Yes
Yes
Microsoft Exchange Mailbox Transport Submission
No
No
No
Yes
No
Yes
Yes
Yes
Microsoft Exchange MTA Stacks
Yes
No
No
No
Microsoft Exchange POP3
Yes
Yes
Yes
No
Microsoft Exchange POP3 Backend
No
No
No
Yes
Microsoft Exchange POP3-2013
No
No
No
Yes
Microsoft Exchange Protected Service Host
No
No
Yes
No
Microsoft Exchange Replication Service
No
Yes
Yes
Yes
Microsoft Exchange Routing Engine
Yes
No
No
No
Microsoft Exchange RPC Client Access
No
No
Yes
Yes
Microsoft Exchange Search
No
No
No
Yes
Microsoft Exchange Search Host Controller
No
No
No
Yes
Microsoft Exchange Search Indexer
No
Yes
Yes
No
Microsoft Exchange Server Extension for Windows Server

Backup
No
No
Yes
Yes
Microsoft Exchange Service Host
No
Yes
Yes
Yes
Microsoft Exchange System Attendant
Yes
Yes
Yes
No
Microsoft Exchange Throttling
No
No
Yes
Yes
Microsoft Exchange Transport
No
Yes
Yes
Yes
Microsoft Exchange Transport Log Search
No
Yes
Yes
Yes
Microsoft Exchange Unified Messaging
No
No
No
Yes
Microsoft Exchange Unified Messaging Call Router
No
No
No
Yes
Microsoft Search (Exchange)
No
Yes
Yes
No
SMTP
Yes
No
No
No
World Wide Web Publishing Service
No
Yes
No
No
exchange_monitor Troubleshooting
This article contains troubleshooting information for the exchange_monitor probe.
Profile Setup Tab not displaying all the metrics
Symptom
On some of the exchange 2K13 machines, the client access role checkpoint is not displayed by the probe.
Solution
Do the following:
1. Go to the Raw Configure section of the exchange_monitor probe.
2. From the left pane, select register.
3. Under 2013, paths, 2k13_path_cas, set the value of the path key from Software\Microsoft\ExchangeServer\v15\ClientAccessRole to
Software\Microsoft\ExchangeServer\v15\FrontendTransportRole
You are now able to see all the metrics under the Profile Setup Tab.
exchange_monitor Metrics
The following table describes the checkpoint metrics that can be configured using the Microsoft Exchange Monitoring (exchange_monitor) probe.
Contents
QoS Metrics
QoS Metrics
The following table describes the checkpoint metrics that can be configured using the Microsoft Exchange Monitoring probe.
Monitor Name
Units
Description
QOS_EXCHANGE_MEMORY_AVAILABLE_MBYTES
MB
Available MBytes
QOS_EXCHANGE_MEMORY_POOL_PAGED_BYTES
MB
Pool Paged bytes
QOS_EXCHANGE_MEMORY_CACHE_BYTES
MB
Cache Bytes
QOS_EXCHANGE_MEMORY_COMMITED_BYTES
MB
Committed Bytes
QOS_EXCHANGE_MEMORY_COMMITED_BYTES_IN_USE
Pct
QOS_EXCHANGE_MEMORY_TRANSITION_PAGES_REPURPOSED_PER_SECOND
Count
Transition Pages Repurposed
QOS_EXCHANGE_MEMORY_PAGE_READS_PER_SECOND
Count
Page Reads Per Second
QOS_EXCHANGE_MEMORY_PAGES_INPUT_PER_SECOND
Count
Pages Input Per Second
QOS_EXCHANGE_MEMORY_PAGES_OUTPUT_PER_SECOND
Count
Pages Output Per Second
QOS_EXCHANGE_MEMORY_PRIVATE_BYTES
MB
Private Bytes
QOS_EXCHANGE_MEMORY_VIRTUAL_BYTES
MB
Virtual Bytes
QOS_EXCHANGE_MEMORY_WORKING_SET
MB
Working Set
QOS_EXCHANGE_MEMORY_HANDLE_COUNT
Count
Handle Count
QOS_EXCHANGE_MEMORY_DOTNET-TIME_IN_GC
Pct
DOTNET-Time In GC
QOS_EXCHANGE_MEMORY_DOTNET-EXCEPTION_THROWN_PER_SEC
Count
DOTNET-Exception Thrown P
QOS_EXCHANGE_MEMORY_DOTNET-BYTES_IN_ALL_HEAPS
MB
DOTNET-Bytes In All Heaps
QOS_EXCHANGE_PROCESSOR_USER_TIME
Pct
User Time
QOS_EXCHANGE_PROCESSOR_PRIVILEGED_TIME
Pct
Privileged Time
QOS_EXCHANGE_PROCESSOR_PROCESSOR_TIME_INSTANCE
Pct
Processor Time Instance
QOS_EXCHANGE_PROCESSOR_PROCESSOR_QUEUE_LENGTH
Count
QOS_EXCHANGE_NETWORK_PACKETS_OUTBOUND_ERRORS
Count
Packets Outbound Errors
QOS_EXCHANGE_NETWORK_TCPV4_CONNECTIONS_ESTABLISHED
Count
TCPv4 Connections Establishe
QOS_EXCHANGE_NETWORK_TCPV6_CONNECTION_FAILURES
Count
TCPv6 Connection Failures
QOS_EXCHANGE_NETWORK_TCPV4_CONNECTIONS_RESET
Count
QOS_EXCHANGE_NETWORK_TCPV6_CONNECTION_RESET
Count
QOS_EXCHANGE_TRANS_ROLE_AVERAGE_DISK_SECONDS_PER_READ-TRANSPORT
ms
Average Disk Seconds Per Re
QOS_EXCHANGE_TRANS_ROLE_AVERAGE_DISK_SECONDS_PER_WRITE-TRANSPORT
ms
Average Disk Seconds Per Wr
QOS_EXCHANGE_TRANS_ROLE_SUBMISSION_QUEUE_LENGTH
msgs
Submission Queue Length
QOS_EXCHANGE_TRANS_ROLE_RETRY_NON-SMTP_DELIVERY_QUEUE_LENGTH
msgs
Retry Non-Smtp Delivery Queu
QOS_EXCHANGE_TRANS_ROLE_RETRY_REMOTE_DELIVERY_QUEUE_LENGTH
msgs
Retry Remote Delivery Queue
QOS_EXCHANGE_TRANS_ROLE_LARGEST_DELIVERY_QUEUE_LENGTH
msgs
Largest Delivery Queue Lengt
QOS_EXCHANGE_TRANS_ROLE_POISON_QUEUE_LENGTH-TRANSPORT
msgs
Poison Queue Length-Transpo
QOS_EXCHANGE_TRANS_ROLE_INPUT-OUTPUT_LOG_WRITES_PER_SEC
logs/sec
Input-Output Log Writes Per S
QOS_EXCHANGE_TRANS_ROLE_INPUT-OUTPUT_LOG_READS_PER_SEC
logs/sec
Input-Output Log Reads Per S
QOS_EXCHANGE_TRANS_ROLE_LOG_GENERATION_CHECKPOINT_DEPTH-TRANSPORT
cnt
Log Generation Checkpoint De
QOS_EXCHANGE_TRANS_ROLE_VERSION_BUCKETS_ALLOCATED
versions
Version Buckets Allocated
QOS_EXCHANGE_TRANS_ROLE_INPUT-OUTPUT_DATABASE_READS_PER_SEC
rds/sec
Input-Output Database Reads
QOS_EXCHANGE_TRANS_ROLE_INPUT-OUTPUT_DATABASE_WRITES_PER_SEC
wrts/sec
Input-Output Database Writes
QOS_EXCHANGE_TRANS_ROLE_LOG_RECORD_STALLS_PER_SEC-TRANSPORT
logs/sec
Log Record Stalls Per Sec-Tra
QOS_EXCHANGE_TRANS_ROLE_LOG_THREADS_WAITING-TRANSPORT
thrds
Log Threads Waiting-Transpor
QOS_EXCHANGE_TRANS_ROLE_TOTAL_AGENT_INVOCATIONS
invocations
Total Agent Invocations
QOS_EXCHANGE_TRANS_ROLE_MESSAGES_COMPLETED_DELIVERY_PER_SECOND
msgs/sec
Messages Completed Delivery
QOS_EXCHANGE_TRANS_ROLE_INBOUND:_LOCALDELIVERYCALLSPERSECOND
atmpts/sec
Inbound: LocalDeliveryCallsPe
QOS_EXCHANGE_TRANS_ROLE_OUTBOUND:_SUBMITTED_MAIL_ITEMS_PER_SECOND
Items/sec
Outbound: Submitted Mail Item
QOS_EXCHANGE_TRANS_ROLE_AVERAGE_BYTES_PER_MESSAGE
byts/msg
Average Bytes Per Message
QOS_EXCHANGE_TRANS_ROLE_MESSAGES_RECEIVED_PER_SEC-TRANSPORT
msgs/sec
Messages Received Per Sec-T
QOS_EXCHANGE_TRANS_ROLE_MESSAGES_SENT_PER_SEC-TRANSPORT
msgs/sec
Messages Sent Per Sec-Trans
QOS_EXCHANGE_TRANS_ROLE_INBOUND:_MESSAGEDELIVERYATTEMPTSPERSECOND
atmpts/sec
Inbound: MessageDeliveryAtte
QOS_EXCHANGE_TRANS_ROLE_INBOUND:_RECIPIENTS_DELIVERED_PER_SECOND
recipts/sec
Inbound: Recipients Delivered
QOS_EXCHANGE_TRANS_ROLE_AVERAGE_AGENT_PROCESSING_TIME_IN_SECONDS
msg/s
Average Agent Processing Tim
QOS_EXCHANGE_TRANS_ROLE_ACTIVE_MAILBOX_DELIVERY_QUEUE_LENGTH-TRANSPORT
items
Active Mailbox Delivery Queue
QOS_EXCHANGE_TRANS_ROLE_ACTIVE_REMOTE_DELIVERY_QUEUE_LENGTH-TRANSPORT
items
Active Remote Delivery Queue
QOS_EXCHANGE_TRANS_ROLE_AGGREGATE_DELIVERY_QUEUE_LENGTH_(ALL_QUEUES)-TRANSPORT
items
Aggregate Delivery Queue Len
QOS_EXCHANGE_TRANS_ROLE_ACTIVE_NON-SMTP_DELIVERY_QUEUE_LENGTH-TRANSPORT
items
Active Non-Smtp Delivery Que
QOS_EXCHANGE_TRANS_ROLE_RETRY_MAILBOX_DELIVERY_QUEUE_LENGTH-TRANSPORT
msgs
Retry Mailbox Delivery Queue
QOS_EXCHANGE_TRANS_ROLE_UNREACHABLE_QUEUE_LENGTH-TRANSPORT
msgs
Unreachable Queue Length-Tr
QOS_EXCHANGE_MAILBOX_ROLE_DATABASE_READS_(ATTACHED)_AVERAGE_LATENCY
ms
Database Reads (Attached) A
QOS_EXCHANGE_MAILBOX_ROLE_DATABASE_WRITES_(ATTACHED)_AVERAGE_LATENCY
ms
Database Writes (Attached) Av
QOS_EXCHANGE_MAILBOX_ROLE_DATABASE_PAGE_FAULT_STALLS_PER_SEC
psg/s
Database Page Fault Stalls Pe
QOS_EXCHANGE_MAILBOX_ROLE_LOG_WRITES_AVERAGE_LATENCY
ms
Log Writes Average Latency
QOS_EXCHANGE_MAILBOX_ROLE_LOG_RECORD_STALLS_PER_SEC
rcrds/s
Log Record Stalls Per Sec
QOS_EXCHANGE_MAILBOX_ROLE_LOG_THREADS_WAITING
thrds
Log Threads Waiting
QOS_EXCHANGE_MAILBOX_ROLE_DATABASE_READS_(RECOVERY)_AVERAGE_LATENCY
ms
Database Reads (Recovery) A
QOS_EXCHANGE_MAILBOX_ROLE_DATABASE_WRITES_(RECOVERY)_AVERAGE_LATENCY
ms
Database Writes (Recovery) A
QOS_EXCHANGE_MAILBOX_ROLE_LOG_READS_AVERAGE_LATENCY
ms
Log Reads Average Latency
QOS_EXCHANGE_MAILBOX_ROLE_RPC_REQUESTS_-_MAILBOX
reqs
RPC Requests - Mailbox
QOS_EXCHANGE_MAILBOX_ROLE_RPC_AVERAGED_LATENCY
ms
RPC Averaged Latency
QOS_EXCHANGE_MAILBOX_ROLE_RPC_AVERAGE_LATENCY_-_MAILBOX
ms
RPC Average Latency - Mailbo
QOS_EXCHANGE_MAILBOX_ROLE_RPC_AVERAGE_LATENCY_-_CLIENT
ms
RPC Average Latency - Client
QOS_EXCHANGE_MAILBOX_ROLE_CLIENT_REPORTED_FAILED_RPCS_FOR_SERVER_TOO_BUSY_ERROR_PER_SEC
errs/s
Client Reported Failed RPCs F

Per Sec
QOS_EXCHANGE_MAILBOX_ROLE_CLIENT_REPORTED_FAILED_RPCS_FOR_SERVER_TOO_BUSY_ERROR
errs
Client Reported Failed RPCs F
QOS_EXCHANGE_MAILBOX_ROLE_MESSAGES_QUEUED_FOR_SUBMISSION_MAILBOX
msgs
Messages Queued For Submi
QOS_EXCHANGE_MAILBOX_ROLE_MESSAGES_QUEUED_FOR_SUBMISSION_PUBLIC
msgs
Messages Queued For Submi
QOS_EXCHANGE_MAILBOX_ROLE_LOG_GENERATION_CHECKPOINT_DEPTH
cnt
Log Generation Checkpoint De
QOS_EXCHANGE_MAILBOX_ROLE_DATABASE_PAGE_FAULT_STALLS_PER_SEC_-_INFORMATION_STORE
pgs/s
Database Page Fault Stalls Pe
QOS_EXCHANGE_MAILBOX_ROLE_LOG_RECORD_STALLS_PER_SEC_-_INFORMATION_STORE
rcrds/s
Log Record Stalls Per Sec - In
QOS_EXCHANGE_MAILBOX_ROLE_LOG_THREADS_WAITING_-_INFORMATION_STORE
thrds
Log Threads Waiting - Informa
QOS_EXCHANGE_MAILBOX_ROLE_VERSION_BUCKETS_ALLOCATED_-_INFORMATION_STORE
bukts
Version Buckets Allocated - In
QOS_EXCHANGE_MAILBOX_ROLE_DATABASE_READS_AVERAGE_LATENCY
ms
Database Reads Average Late
QOS_EXCHANGE_MAILBOX_ROLE_DATABASE_WRITES_AVERAGE_LATENCY
ms
Database Writes Average Late
QOS_EXCHANGE_MAILBOX_ROLE_DATABASE_CACHE_SIZE_-_INFORMATION_STORE
MB
Database Cache Size - Inform
QOS_EXCHANGE_MAILBOX_ROLE_DATABASE_CACHE_PERCENTAGE_HIT
Database Cache Percentage H
QOS_EXCHANGE_MAILBOX_ROLE_LOG_BYTES_WRITE_PER_SEC
bytes/s
Log Bytes Write Per Sec
QOS_EXCHANGE_MAILBOX_ROLE_SLOW_FINDROW_RATE
rate
Slow FindRow Rate
QOS_EXCHANGE_MAILBOX_ROLE_SEARCH_TASK_RATE
tasks/s
Search Task Rate
QOS_EXCHANGE_MAILBOX_ROLE_SLOW_QP_THREADS
thrds
Slow QP Threads
QOS_EXCHANGE_MAILBOX_ROLE_SLOW_SEARCH_THREADS
thrds
Slow Search Threads
QOS_EXCHANGE_MAILBOX_ROLE_PROCESSOR_TIME_-_MS_EXCHANGE_SEARCH_SERVICE
Processor Time - MS Exchang
QOS_EXCHANGE_MAILBOX_ROLE_PROCESSOR_TIME_-_ MSFTEFD_PROCESS
Processor Time - Msftefd Proc
QOS_EXCHANGE_MAILBOX_ROLE_RECENT_AVERAGE_LATENCY_OF_RPCS_USED_TO_OBTAIN_CONTENT
ms
Recent Average Latency of RP
QOS_EXCHANGE_MAILBOX_ROLE_AVERAGE_DOCUMENT_INDEXING_TIME
ms
Average Document Indexing T
QOS_EXCHANGE_MAILBOX_ROLE_FULL_CRAWL_MODE_STATUS
crawl
Full Crawl Mode Status
QOS_EXCHANGE_MAILBOX_ROLE_PROCESSOR_TIME_ - _MAILBOXASSISTANTS
Processor Time - MailboxAssis
QOS_EXCHANGE_MAILBOX_ROLE_EVENTS_IN_QUEUE
evnts
Events In Queue
QOS_EXCHANGE_MAILBOX_ROLE_AVERAGE_EVENT_PROCESSING_TIME_IN_SECONDS
Average Event Processing Tim
QOS_EXCHANGE_MAILBOX_ROLE_AVERAGE_RESOURCE_BOOKING_PROCESSING_TIME
Average Resource Booking Pr
QOS_EXCHANGE_MAILBOX_ROLE_REQUESTS_FAILED_-__RESOURCE_BOOKING
reqs
Requests Failed - Resource B
QOS_EXCHANGE_MAILBOX_ROLE_AVERAGE_CALENDAR_ATTENDANT_PROCESSING_TIME
Average Calendar Attendant P
QOS_EXCHANGE_MAILBOX_ROLE_REQUESTS_FAILED_-_CALENDAR_ATTENDANT
reqs
Requests Failed - Calendar At
QOS_EXCHANGE_MAILBOX_ROLE_RPC_LATENCY_AVERAGE_-_STORE_INTERFACE
ms
RPC Latency Average - Store
QOS_EXCHANGE_MAILBOX_ROLE_ROP_REQUESTS_OUTSTANDING
reqs
ROP Requests Outstanding
QOS_EXCHANGE_MAILBOX_ROLE_RPC_REQUESTS_OUTSTANDING
reqs
RPC Requests Outstanding
QOS_EXCHANGE_MAILBOX_ROLE_RPC_REQUESTS_OUTSTANDING_INSTANCE
reqs
RPC Requests Outstanding In
QOS_EXCHANGE_MAILBOX_ROLE_RPC_REQUESTS_SENT_PER_SEC
reqs/s
RPC Requests Sent Per Sec
QOS_EXCHANGE_MAILBOX_ROLE_RPC_SLOW_REQUESTS_LATENCY_AVERAGE
ms
RPC Slow Requests Latency A
QOS_EXCHANGE_MAILBOX_ROLE_RPC_REQUESTS_FAILED_PERCENTAGE
RPC Requests Failed Percent
QOS_EXCHANGE_MAILBOX_ROLE_RPC_SLOW_REQUESTS_PERCENTAGE
RPC Slow Requests Percenta
QOS_EXCHANGE_MAILBOX_ROLE_SUCCESSFUL_SUBMISSIONS_PER_SECOND
sbms/s
Successful Submissions Per S
QOS_EXCHANGE_MAILBOX_ROLE_HUB_SERVERS_IN_RETRY
srvrs
Hub Servers In Retry
QOS_EXCHANGE_MAILBOX_ROLE_FAILED_SUBMISSIONS_PER_SECOND
sbms/s
Failed Submissions Per Secon
QOS_EXCHANGE_MAILBOX_ROLE_TEMPORARY_SUBMISSION_FAILURES_PER_SEC
sbms/s
Temporary Submission Failure
QOS_EXCHANGE_MAILBOX_ROLE_COPYQUEUELENGTH
files
CopyQueueLength
QOS_EXCHANGE_MAILBOX_ROLE_REPLAYQUEUELENGTH
files
ReplayQueueLength
QOS_EXCHANGE_MAILBOX_ROLE_SEEDING_FINISHED_PERCENTAGE
Seeding Finished Percentage
QOS_EXCHANGE_MAILBOX_ROLE_RPC_OPERATIONS_PER_SEC
oper/s
RPC Operations Per Sec
QOS_EXCHANGE_MAILBOX_ROLE_RPC_CLIENT_BACKOFF_PER_SEC
oper/s
RPC Client Backoff Per Sec
QOS_EXCHANGE_MAILBOX_ROLE_FAILED_CLIENT_RPCS_FOR_SERVER_TOO_BUSY_PER_SEC
errs/s
Failed Client RPCs For Server
QOS_EXCHANGE_MAILBOX_ROLE_FAILED_CLIENT_RPCS_FOR_SERVER_TOO_BUSY
errs
Failed Client RPCs For Server
QOS_EXCHANGE_MAILBOX_ROLE_RPC_OPERATIONS_PER_SEC_-_MSEXCHANGEIS_CLIENT
oper/s
RPC Operations Per Sec - MS
QOS_EXCHANGE_MAILBOX_ROLE_JET_LOG_RECORDS_PER_SEC
recs/s
JET Log Records Per Sec
QOS_EXCHANGE_MAILBOX_ROLE_JET_PAGES_READ_PER_SEC
pgs/s
JET Pages Read Per Sec
QOS_EXCHANGE_MAILBOX_ROLE_DIRECTORY_ACCESS_LDAP_READS_PER_SEC
rd/s
Directory Access LDAP Reads
QOS_EXCHANGE_MAILBOX_ROLE_DIRECTORY_ACCESS_LDAP_SEARCHES_PER_SEC
srch/s
Directory Access LDAP Searc
QOS_EXCHANGE_MAILBOX_ROLE_MESSAGES_DELIVERED_PER_SEC_ - _MAILBOX
msg/s
Messages Delivered Per Sec -
QOS_EXCHANGE_MAILBOX_ROLE_MESSAGES_SENT_PER_SEC_ - _TOTAL
msg/s
Messages Sent Per Sec - Tota
QOS_EXCHANGE_MAILBOX_ROLE_MESSAGES_SUBMITTED_PER_SEC
msg/s
Messages Submitted Per Sec
QOS_EXCHANGE_MAILBOX_ROLE_REPLICATION_RECEIVE_QUEUE_SIZE
msg/s
Replication Receive Queue Si
QOS_EXCHANGE_MAILBOX_ROLE_MAILBOXES_PROCESSED_PER_SEC
mlbox/s
Mailboxes Processed Per Sec
QOS_EXCHANGE_MAILBOX_ROLE_EVENTS_POLLED_PER_SEC
evnts/s
Events Polled Per Sec
QOS_EXCHANGE_CAS_ROLE_AVERAGE_SEARCH_TIME
ms
Average Search Time
QOS_EXCHANGE_CAS_ROLE_APPLICATION_RESTARTS
count
Application Restarts
QOS_EXCHANGE_CAS_ROLE_WORKER_PROCESS_RESTARTS
count
Worker Process Restarts
QOS_EXCHANGE_CAS_ROLE_REQUEST_WAIT_TIME
count
Request Wait Time
QOS_EXCHANGE_CAS_ROLE_REQUESTS_IN_APPLICATION_QUEUE
requests
Requests In Application Queue
QOS_EXCHANGE_CAS_ROLE_AVERAGE_TIME_TO_PROCESS_A_FREE_BUSY_REQUEST
sec
Average Time To Process A F
QOS_EXCHANGE_CAS_ROLE_SYNC_COMMANDS_PENDING
commands
Sync Commands Pending
QOS_EXCHANGE_CAS_ROLE_REQUESTS_QUEUED
requests
Requests Queued
QOS_EXCHANGE_CAS_ROLE_NUMBER_OF_FAILED_BACK-END_CONNECTION_ATTEMPTS_PER_SECOND
conn/sec
Number Of Failed Back-End C

Second
QOS_EXCHANGE_CAS_ROLE_CURRENT_NUMBER_OF_INCOMING_RPC_OVER_HTTP_CONNECTIONS
RPC
Current Number Of Incoming R

Connections
QOS_EXCHANGE_CAS_ROLE_CURRENT_NUMBER_OF_UNIQUE_USERS
users
Current Number Of Unique Us
QOS_EXCHANGE_CAS_ROLE_RPC_-_HTTP_REQUESTS_PER_SECOND
req/sec
RPC - HTTP Requests Per Se
QOS_EXCHANGE_CAS_ROLE_RPC_AVERAGED_LATENCY_-_RPCCLIENTACCESS
ms
RPC Averaged Latency - RpcC
QOS_EXCHANGE_CAS_ROLE_RPC_OPERATIONS_PER_SEC_-_RPCCLIENTACCESS
/sec
RPC Operations Per Sec - Rp
QOS_EXCHANGE_CAS_ROLE_RPC_REQUESTS_-_RPCCLIENTACCESS
requests
RPC Requests - RpcClientAcc
QOS_EXCHANGE_CAS_ROLE_NSPI_RPC_BROWSE_REQUESTS_AVERAGE_LATENCY
ms
NSPI RPC Browse Requests A
QOS_EXCHANGE_CAS_ROLE_NSPI_RPC_REQUESTS_AVERAGE_LATENCY
ms
NSPI RPC Requests Average
QOS_EXCHANGE_CAS_ROLE_REFERRAL_RPC_REQUESTS_AVERAGE_LATENCY
ms
Referral RPC Requests Avera
QOS_EXCHANGE_CAS_ROLE_OUTBOUND_PROXY_REQUESTS_FOR_AVERAGE_RESPONSE_TIME
ms
Outbound Proxy Requests For
QOS_EXCHANGE_CAS_ROLE_REQUESTS_AVERAGE_RESPONSE_TIME
ms
Requests Average Response
QOS_EXCHANGE_CAS_ROLE_DOWNLOAD_TASK_QUEUED
tasks
Download Task Queued
QOS_EXCHANGE_CAS_ROLE_DOWNLOAD_TASKS_COMPLETED
tasks
Download Tasks Completed
QOS_EXCHANGE_CAS_ROLE_PING_COMMANDS_PENDING
commands
Ping Commands Pending
QOS_EXCHANGE_CAS_ROLE_AVAILABILITY_REQUESTS_IN_SECONDS
reqs/sec
Availability Requests In Secon
QOS_EXCHANGE_CAS_ROLE_CURRENT_UNIQUE_USERS
users
Current Unique Users
QOS_EXCHANGE_CAS_ROLE_AUTODISCOVER_SERVICE_REQUESTS_PER_SEC
reqs/sec
Autodiscover Service Request
QOS_EXCHANGE_CAS_ROLE_CURRENT_CONNECTIONS
conn
Current Connections
QOS_EXCHANGE_CAS_ROLE_CONNECTION_ATTEMPTS_PER_SEC
conn/sec
Connection Attempts Per Sec
QOS_EXCHANGE_CAS_ROLE_ISAPI_EXTENSION_REQUESTS_PER_SEC
reqs/sec
ISAPI Extension Requests Per
QOS_EXCHANGE_CAS_ROLE_OTHER_REQUEST_METHODS_PER_SEC
reqs/sec
Other Request Methods Per S
QOS_EXCHANGE_MSEXCHANGE_LDAP_SEARCHES_PER_SECOND
count
LDAP Searches Per Second
QOS_EXCHANGE_MSEXCHANGE_LDAP_READ_TIME_CONTROLLERS
ms
LDAP Read Time Controllers
QOS_EXCHANGE_MSEXCHANGE_LDAP_SEARCH_TIME_CONTROLLERS
ms
LDAP Search Time Controllers
QOS_EXCHANGE_MSEXCHANGE_LDAP_READ_TIME_PROCESSES
ms
QOS_EXCHANGE_MSEXCHANGE_LDAP_SEARCH_TIME_PROCESSES
ms
QOS_EXCHANGE_MSEXCHANGE_LDAP_SEARCHES_TIMED_OUT_PER_MINUTE
count
LDAP Searches Timed Out Pe
QOS_EXCHANGE_MSEXCHANGE_LONG_RUNNING_LDAP_OPERATIONS_PER_MINUTE
count
Long Running LDAP Operation
QOS_EXCHANGE_DAG_NUM_ACTIVE_DB
db
Number of active database co

server.
QOS_EXCHANGE_DAG_NUM_PASSIVE_DB
db
Number of passive database c

server.
QOS_EXCHANGE_DAG_NUM_MOUNTED_DB
db
Number of mounted database

server.
QOS_EXCHANGE_DAG_NUM_NON_MOUNTED_DB
db
Number of database copies wh

on current Mailbox server
QOS_EXCHANGE_DAG_DB_COPY_QUEUE_LENGTH
files
Shows the number of transact

copied to the passive copy log
considered complete until it ha
corruption.
QOS_EXCHANGE_DAG_DB_REPLAY_QUEUE_LENGTH
files
Shows the number of transact

replayed into the passive copy
QOS_EXCHANGE_DAG_DB_COPY_STATUS_FAILED
bool
The mailbox database copy is

isn't suspended, and it isn't ab
While in a Failed state and not
periodically check whether the
copy status to change to Faile
the system has detected that t
barring no other issues, the co
change to Healthy.
QOS_EXCHANGE_DAG_DB_COPY_STATUS_SEEDING
bool

index for the mailbox database
both are being seeded. Upon s
seeding, the copy status shoul
QOS_EXCHANGE_DAG_DB_COPY_STATUS_SEEDING_SOURCE
bool

a database copy seeding oper
QOS_EXCHANGE_DAG_DB_COPY_STATUS_SUSPENDED
bool

result of an administrator manu
database copy by running the
Suspend-MailboxDatabaseCo
QOS_EXCHANGE_DAG_DB_COPY_STATUS_HEALTHY
bool

replaying log files, or it has suc
replayed all available log files.
QOS_EXCHANGE_DAG_DB_COPY_STATUS_SERVICE_DOWN
bool
The Microsoft Exchange Repli

or running on the server that h
copy.
QOS_EXCHANGE_DAG_DB_COPY_STATUS_INITIALIZING
bool
The mailbox database copy wi

when a database copy has be
Microsoft Exchange Replicatio
just been started, and during tr
ServiceDown, Failed, Seeding
LostWrite, or Disconnected to
state, the system is verifying th
stream are in a consistent stat
status will remain in the Initializ
seconds, but in all cases, it sh
state for longer than 30 second
QOS_EXCHANGE_DAG_DB_COPY_STATUS_RESYNCHRONIZING
bool
The mailbox database copy an

compared with the active copy
any divergence between the tw
will remain in this state until an
and resolved.
QOS_EXCHANGE_DAG_DB_COPY_STATUS_MOUNTED
bool
The active copy is online and a

Only the active copy of the ma
have a copy status of Mounted
QOS_EXCHANGE_DAG_DB_COPY_STATUS_DISMOUNTED
bool
The active copy is offline and n

connections. Only the active c
copy can have a copy status o
QOS_EXCHANGE_DAG_DB_COPY_STATUS_MOUNTING
bool
The active copy is coming onli

client connections. Only the ac
database copy can have a cop
QOS_EXCHANGE_DAG_DB_COPY_STATUS_DISMOUNTING
bool
The active copy is going offline

connections. Only the active c
copy can have a copy status o
QOS_EXCHANGE_DAG_DB_COPY_STATUS_DISCONNECTED_AND_HEALTHY
bool

active database copy, and it w
the loss of connection occurre
database copy with respect to
database copy. It may be repo
failures between the source co
copy.
QOS_EXCHANGE_DAG_DB_COPY_STATUS_DISCONNECTED_AND_RESYNCHRONIZING
bool

active database copy, and it w
state when the loss of connect
represents the database copy
to its source database copy. It
DAG network failures between
target database copy.
QOS_EXCHANGE_DAG_DB_COPY_STATUS_FAILED_AND_SUSPENDED
bool
The Failed and Suspended sta

simultaneously by the system
detected, and because resolut
requires administrator interven
system detects unrecoverable
active mailbox database and a
Failed state, the system won't
the problem has been resolved
Instead, an administrator must
underlying cause of the failure
can be transitioned to a health
QOS_EXCHANGE_DAG_DB_COPY_STATUS_SINGLE_PAGE_RESTORE
bool
This state indicates that a sing

occurring on the mailbox datab
QOS_EXCHANGE_DAG_DB_LAST_INSPECTED_LOG_TIME
timestamp
The modification time of the la

validated by the Mailbox serve
QOS_EXCHANGE_DAG_DB_CONTENT_INDEX_STATE
state
Indicates the current state of th

database copy.
Note: For
QOS_EXCHANGE_DAG_DB_
there are different states which
CONTENT_INDEX_STATE_F
CONTENT_INDEX_STATE_H
CONTENT_INDEX_STATE_C
CONTENT_INDEX_STATE_O
be sent accordingly.
QOS_EXCHANGE_DAG_DB_ACTIVATION_SUSPENDED
bool
Indicates whether activation of

suspended.
QOS_EXCHANGE_DAG_DB_COPY_SIZE
GB
QOS_EXCHANGE_DAG_DB_REDUNDANCY_COUNT
Db
Count of redundancy of replica

Both active and passive copies
determining redundancy.
QOS_EXCHANGE_DAG_CLUSTER_SERVICE_HEALTH_STATUS
state
Verifies that the Cluster servic

on the local exchange server.
QOS_EXCHANGE_DAG_REPLAY_SERVICE_HEALTH_STATUS
state
Verifies that the Replay service

on the local exchange server.
QOS_EXCHANGE_DAG_ACTIVE_MANAGER_HEALTH_STATUS
state
Verifies that the instance of Ac

local Exchange server is in a v
secondary, or stand-alone).
QOS_EXCHANGE_DAG_TASKS_RPC_LISTENER_HEALTH_STATUS
state
Verifies that the tasks remote p

is running and reachable on th
QOS_EXCHANGE_DAG_TASKS_RPC_LISTENER_HEALTH_STATUS
state
Verifies that the TCP log copy

reachable on the local Exchan
QOS_EXCHANGE_DAG_DAG_MEMBERS_UP_HEALTH_STATUS
state
Verifies that all DAG members

reachable.
QOS_EXCHANGE_DAG_CLUSTER_NETWORK_HEALTH_STATUS
state
Verifies that all cluster-manage

Exchange server are available
QOS_EXCHANGE_DAG_QUORUM_GROUP_HEALTH_STATUS
state
Verifies that the default cluster

a healthy and online state.
QOS_EXCHANGE_DAG_FILE_SHARE_QUORUM_HEALTH_STATUS
state
Verifies that the witness serve

share configured for the DAG
QOS_EXCHANGE_DAG_DB_LOG_COPY_KEEPING_UP_HEALTH_STATUS
state
Verifies that log copying and in

copies of databases on the loc
to keep up with log generation
QOS_EXCHANGE_DAG_DB_LOG_REPLAY_KEEPING_UP_HEALTH_STATUS
state
Verifies that replay activity for

databases on the local exchan
with log copying and inspectio
QOS_EXCHANGE_MAILBOX_ROLE_INPUT-OUTPUT_LOG_READ_AVERAGE_LATENCY
ms
Indicates the average time, in

file. Specific to log replay and
operations.
QOS_EXCHANGE_MAILBOX_ROLE_DATABASEMOUNTED
bool
Indicates whether database co

server.
QOS_EXCHANGE_MAILBOX_ROLE_AGE_OF_THE_LAST_NOTIFICATION_INDEXED
sec
Indicates content indexing bac
QOS_EXCHANGE_MAILBOX_ROLE_INPUT_OUTPUT_LOG_WRITES_AVERAGE_LATENCY
ms
Indicates the average time, in

the active log file.
QOS_EXCHANGE_MAILBOX_ROLE_TIME_SINCE_LAST_NOTIFICATION_WAS_INDEXED
sec
Indicates the time in seconds s

indexed for content indexing in
QOS_EXCHANGE_MAILBOX_ROLE_EXCHANGE_SEARCH_ZERO_RESULT_QUERY
bool
Indicates that more than one h

returned zero results. This ma
or other problem affects the co
QOS_EXCHANGE_MAILBOX_ROLE_LOGICAL_DISK_PERCENTAGE_FREE_SPACE
percentage
Indicates the free space of log
QOS_EXCHANGE_TRANS_ROLE_INBOUND_LOCALDELIVERYCALLSPERSECOND2013
atmpts/sec
Shows the number of attempts

items per second. Determines
values to historical baselines.
QOS_EXCHANGE_TRANS_ROLE_INBOUND_MESSAGEDELIVERYATTEMPTSPERSECOND-2013
recipts/sec
Shows the number of inbound

second. Determines current lo
historical baselines.
QOS_EXCHANGE_MAILBOX_ROLE_MESSAGES_DELIVERED_PER_SEC_-_STORE
msg/s
Shows the rate that messages

recipients. Indicates current m
store.
QOS_EXCHANGE_MAILBOX_ROLE_MAILBOX_SEARCHES_PER_SEC_._STORE
msg/s
Number of search queries/sec
QOS_EXCHANGE_CAS_ROLE_NUMBER_OF_FAILED_BACK-END_CONNECTION_ATTEMPTS_PER_SECOND-2013
conn/sec
Shows the rate at which the R

occurring but failing to establis
back-end server.
QOS_EXCHANGE_ANTI_MALWARE_ANTI-MALWARE_AGENT_MESSAGES_SCANNED
messages
Messages Scanned is the num

in the past minute.
QOS_EXCHANGE_ANTI_MALWARE_ANTI-MALWARE_AGENT_MESSAGES_SCANNED_PER_SECOND
messages
Messages Scanned per Secon

messages scanned each seco
minute.
QOS_EXCHANGE_ANTI_MALWARE_ANTI-MALWARE_AGENT_MESSAGES_CONTAINING_MALWARE
messages
Messages Containing Malware

in the past minute that contain
QOS_EXCHANGE_ANTI_MALWARE_ANTI-MALWARE_AGENT_MESSAGE_BLOCKED
messages
Messages Blocked is the num

minute that contained malware
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_ALERATABLE_FAILURE_DSNS_WITHIN_THE_LAST_HOUR
messages
Hub Selection Resolver Failure

messages that encountered re
Hub selection.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_HUB_SELECTION_RESOLVER_FAILURES
messages
Hub Selection Organization M

of messages that encountered
lookup errors in Hub selection.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_HUB_SELECTION_ORGANIZATION_MAILBOX_FAILURES
messages
Hub Selection Routing Failure

that failed to be routed.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_HUB_SELECTION_ROUTING_FAILURES
messages

is the number of messages tha
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_PERCENT_AVAILABILITY
percent
The ratio of successful connec

in the sliding window.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_PERCENT_FAILURES_DUE_TO_MAXINBOUNDCONNECTIONLIMIT
percent
Failure percentage of legitimat

window due to MaxInboundCo
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_PERCENT_FAILURES_DUE_TO_WLID_DOWN
percent

window due to WLID down.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_PERCENT_FAILURES_DUE_TO_BACK_PRESSURE
percent

window due to back pressure.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_FAILURES_DUE_TO_MAXIMUM_LOCAL_LOOP_COUNT
messages
Total number of message deliv

maximum local loop count.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_CONNECTIONS_CREATED_PER_SECOND
connections
per second
Connections Created per seco

connections to the SMTP serv
second.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_MESSAGES_RECEIVED_PER_SECOND
Messages
Per Second
Messages Received per secon

messages received by the SM
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_MESSAGES_BYTES_RECEIVED_PER_SECOND
Messages
Per Second
Number of bytes received in m
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_MESSAGES_BYTES_RECEIVED_PER_SECOND
Messages
Per Second
Number of bytes sent per seco
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_CONNECTIONS_CREATED_PER_SECOND
Connections
Per Second
Connections Created per seco

outbound connections establis
SMTPSend connector.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_MESSAGES_SENT_PER_SECOND
Messages
Per Second
Messages Sent per second is

sent by the SMTPSend conne
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_MESSAGE_BYTES_SENT_PER_SECOND
messages
per second
Number of bytes sent per seco
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_DNS_ERRORS
DNS
DNS Errors is the number of D

the SMTPSend connector.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_CONNECTION_FAILURES
messages
The total number of connection

time window) while trying to se
QOS_EXCHANGE_TRANS_ROLE_MESSAGESFAILEDTOROUTE
messages
Total number of messages fail
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_HUB_SELECTION_ RESOLVER_FAILURES
messages
Hub Selection Resolver Failure

messages that encountered re
Hub selection.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_HUB_SELECTION_ORGANIZATION_
MAILBOX_RESOLVER_FAILURES
messages
Hub Selection Organization M

of messages that encountered
lookup errors in Hub selection.
QOS_EXCHANGE_DELIVERY_HEALTH_MONITOR_HUB_SELECTION_ROUTING_FAILURES
messages

that failed to be routed.
QOS_EXCHANGE_TRANS_ROLE_PERCENTAGE_PROXY_SETUP_FAILURES
percent
The percentage of sessions (d

window) that could not be prox
QOS_EXCHANGE_TRANS_ROLE_TOTAL_PROXY_USER_LOOKUP_FAILURES
messages
The total number of user looku

QOS_EXCHANGE_TRANS_ROLE_TOTAL_PROXY_DNS_LOOKUP_FAILURES
messages
The total number of dns lookup

QOS_EXCHANGE_TRANS_ROLE_TOTAL_PROXY_CONNECTION_FAILURES
messages
The total number of connection

QOS_EXCHANGE_TRANS_ROLE_TOTAL_BYTES_ PROXIED
messages
Total number of bytes proxied

up.
QOS_EXCHANGE_TRANS_ROLE_ CONNECTIONS_CREATED_PER_SECOND
connections
per second
Connections Created/sec is th
connections to the SMTP serv
established.
QOS_EXCHANGE_TRANS_ROLE_RECIPIENTS_SENT
messages
Recipients sent is the number

SMTPSend Connector.

This section contains the QoS metric default settings for the exchange_monitor probe.
Alarm Metric
Monitoring
Profiles
Type
Error
Threshold
Error
Severity
Description
Available Mbytes
Performance
100
Major
Available Mbytes shows the amount of physical memory, in

megabytes (MB), immediately available for allocation to a process or
for system use. It's equal to the sum of memory assigned to the
standby (cached), free, and zero page lists. For a full explanation of
the memory manager, refer to Microsoft Developer Network (MSDN)
or "System Performance and Troubleshooting Guide" in the
Windows Server 2003 Resource Kit.
Available Megabytes
Performance
10
Major
Available Megabytes is the amount of physical memory immediately

available for allocation to a process or for system use.
Average agent processing time in seconds per

event
Performance
----
Major
Average agent processing time in seconds per event.
Average Delivery Time
Performance
----
Major
Average Delivery Time is the average time in milliseconds between

the submission of a message to the mailbox store and the delivery
to all local recipients (recipients on the same server) for the last 10
messages.
Average Disk Bytes per Transfer
Performance
15000
Major
Average Disk Bytes per Transfer is the average number of bytes

transferred to or from the disk during write or read operations.
Average Disk Queue Length
Performance
Major
Average Dis Queue Length is the average number of both read and
write requests that were queued for the selected disk during the
sample interval.
Average Disk Read Queue Length
Performance
Major
Average Disk Read Queue Length is the average number of read

requests that were queued for the selected disk during the sample
interval. One instance of this profile will monitor each Physical Disk.
Average Disk Seconds per Read
Performance
0.05
Major
Average Disk Seconds per Read is the average time of a read of

data from the disk.
Average Disk Seconds per Write
Performance
0.05
Major
Average Disk Seconds per Write is the average time of a write of

data to the disk.
Average Disk Write Queue Length
Performance
Major
Average Disk Write Queue Length is the average number of write

requests that were queued for the selected disk during the sample
interval. One instance of this profile will monitor each Physical Disk.
Average Queue Time
Performance
----
Major
This is the average queue time calculated from the Work Queue
Length and Messages per Second.
Average Request Time (ActiveSync)
Performance
----
Major
Average Request Time is the average time elapsed waiting for a

request to complete.
Average Response Time (OWA)
Performance
----
Major
Average Response Time is the average time (in milliseconds) that

elapsed between the beginning and end of an OEH or ASPX
request.
Average Response Time (WS)
Performance
----
Major
Average Response Time is the average time (in milliseconds) that

has elapsed between the beginning and end of requests.
Cache Bytes
Performance
----
Major
Cache bytes is the current size, in bytes, of the file system cache.
By default, the cache uses up to 50% of available physical memory.
The counter value is the sum of Memory\System Cache Resident
Bytes, Memory\System Driver Resident Bytes, Memory\System
Code Resident Bytes, and Memory\Pool Paged Resident Bytes.
Categorization Count
Performance
----
Major
Categorization Count is the number of categorizations that exist in

the mailbox store. Categorizations are created when a user creates
a filtered view or performs a search. When the information store
must maintain an excessive number of categorizations, performance
can be affected.
Committed Bytes
Performance
----
Major
Committed Bytes is the amount of committed virtual memory, in

bytes. Committed memory is the physical memory that has space
reserved on the disk paging files. There can be one or more paging
files on each physical drive. This counter displays the last observed
value only; it isn't an average.
Performance
----
Major
Committed Bytes in Use is the ratio of Memory\Committed Bytes to

the Memory\Commit Limit. Committed memory is the physical
memory in use for which space has been reserved in the paging file
should it need to be written to disk. The commit limit is determined
by the size of the paging file. If the paging file is enlarged, the
commit limit increases, and the ratio is reduced. This counter
displays the current percentage value only; it isn't an average.
Connection Queue Length
Performance
----
Major
This counter takes the MTA Work Queue Length counter to a lower
level and breaks it out into all the different work queues within the
MTA. If a large queue is building in the MTA this will pinpoint the
exact connection that is responsible.Informational for drill down. One
instance of this profile will monitor each Message Transfer Agent
Connection.
Connections Current (inbound)
Performance
----
Major
Connections Current is the number of inbound connections to the

SMTP server.
Connections Current (outbound)
Performance
----
Major
Connections Current is the number of outbound connections from

the SMTPSend connector.
Connections on IP Allow List Providers per

second
Performance
----
Major
Connections on IP Allow List Providers per second is the number of

connections on the IP Allow List providers per second.
Connections on IP Block List per second
Performance
----
Major
Connections on IP Block List per second is the number of

connections on the IP Block List per second.
Connections on IP Block List Providers per

second
Performance
----
Major
Connections on IP Block List Providers per second is the number of

connections on the IP Block List providers per second.
Connections on the IP Allow List per second
Performance
----
Major
Connections on the IP Allow List per second is the number of

connections on the IP Allow List per second.
Current Bandwidth
Performance
----
Major
Shows an estimate of the current bandwidth of the network interface

in bits per second (bps). For interfaces that do not vary in
bandwidth, or for those where no accurate estimation can be made,
this value is the nominal bandwidth. One instance of this profile will
monitor each Network Interface.
Current Connections (IMAP4)
Performance
----
Major
Current Connections is the number of connections that are currently

open on the IMAP service.
Current Connections (POP3)
Performance
----
Major
Current Connections is the number of connections that are currently

open on the POP service.
Current User Count
Performance
----
Major
Current User Count is the number of users who are currently logged
on to Outlook Web Access. This value monitors the number of
active user sessions, so that users are only removed from this count
after they log off or their session times out.
DNS Queries per second
Performance
----
Major
DNS Queries per second is the number of DNS queries per second
performed by the Sender Id agent.
DOTNET - Bytes In All Heaps
Performance
----
Major
Bytes in all Heaps is the sum of four other counters: Gen 0 Heap
Size, Gen 1 Heap Size, Gen 2 Heap Size, and Large Object Heap
Size. This counter indicates the current memory allocated in bytes
on the GC Heaps.
DOTNET - Exception Thrown Per Sec
Performance
----
Major
Exception Thrown per sec is the number of exceptions thrown per

second. These include both .NET Framework exceptions and
unmanaged exceptions that get converted into .NET Framework
exceptions. For example, the null pointer reference exception in
unmanaged code would get thrown again in managed code as a
.NET Framework System.NullReferenceException. This counter
includes both handled and un-handled exceptions.
DOTNET - Time In GC
Performance
----
Major
Time in GC shows when garbage collection has occurred. When the

counter exceeds the threshold, it indicates that CPU is cleaning up
and isn't being used efficiently for load. Adding memory to the server
would improve this situation.
Dumpster delete per sec
Performance
----
Major
Delete Rate is the rate at which items are deleted from the
Transport Dumpster on this server.
Dumpster insert per sec
Performance
----
Major
Insert Rate is the rate at which items are inserted into the Transport
Dumpster on this server.
Dumpster Item Count
Performance
----
Major
Item Count is the total number of mail items that are currently in the
Transport Dumpster on this server.
Dumpster size
Performance
----
Major
Item Size is the total size (in bytes) of mail items that are currently in
the Transport Dumpster on this server.
Edge Servers total
Performance
----
Major
Edge Servers total is the total number of Edge Transport servers

found by EdgeSync.
Elapsed Time - emsmta
Performance
----
Major
The total elapsed time that this process has been running.
Elapsed Time - mad
Performance
----
Major
Elapsed Time - store
Performance
----
Major
Errors per Second
Performance
----
Major
Network Errors per Second is the rate at which serious unexpected

errors are occurring. Such errors generally indicate that the
Redirector and one or more Servers are having serious
communication difficulties.
Exchange Servers total
Performance
----
Major
Exchange Servers total is the total number of Exchange Servers

found by EdgeSync.
Folder Opens per Second - Mailboxes
Performance
----
Major
Indicates user activity.
Folder Opens per Second - MBX
Performance
----
Major
Indicates user activity. One instance of this profile will monitor each
Mailbox Store.
Folder Opens per Second - PF
Performance
----
Major
Indicates user activity. One instance of this profile will monitor each
Public Folder Store.
Folder Opens per Second - Public Folders
Performance
----
Major
Indicates user activity.
Hub Transport Servers total
Performance
----
Major
Hub Transport Servers total is the total number of Hub Transport

servers found by EdgeSync.
Items queued for delivery
Performance
----
Major
Items queued for delivery per second.
Kilobytes Received per Second
Performance
----
Major
Shows the rate, in incidents per second, at which bytes were

received over each network adapter. The counted bytes include
framing characters. Bytes Received/sec is a subset of Bytes
Total/sec. One instance of this profile will monitor each Network
Interface.
Kilobytes Sent per Second
Performance
----
Major
Shows the rate, in incidents per second, at which bytes were sent
over each network adapter. The counted bytes include framing
characters. Bytes Sent/sec is a subset of Bytes Total/sec. One
instance of this profile will monitor each Network Interface.
Kilobytes Total per Second
Performance
----
Major
Shows the rate, in incidents per second, at which bytes were sent
and received on the network interface, including framing characters.
Bytes Total/sec is the sum of the values of Bytes Received/sec and
Bytes Sent/sec. One instance of this profile will monitor each
Network Interface.
Kilobytes Total per Second - Redirector
Performance
----
Major
Kilobytes Total per Second is the rate the Redirector is processing

data. This includes all application and file data in addition to protocol
information such as packet headers.
Local Queue Length
Performance
Major
The number of messages in the local SMTP queue.
Logon Operations per sec
Performance
----
Major
Logon Operations/sec is the rate of Logon requests in the mailbox

store.
Message Opens per Second - Mailboxes
Performance
----
Major
This will show how often your users are opening messages. Peak
load may show this coinciding with other system behavior.
Message Opens per Second - MBX
Performance
----
Major
load may show this coinciding with other system behavior. One
instance of this profile will monitor each Mailbox Store.
Message Opens per Second - PF
Performance
----
Major
load may show this coinciding with other system behavior. One
instance of this profile will monitor each Public Folder Store.
Message Opens per Second - Public Folders
Performance
----
Major
load may show this coinciding with other system behavior.
Message Recipients Delivered per sec
Performance
----
Major
Messages Delivered/sec is the rate that messages are delivered to

all recipients.
Messages Delivered per Second
Performance
----
Major
The rate that messages are delivered to local mailboxes.
Messages Evaluated by Sender Filter per

second
Performance
----
Major
Messages Evaluated by Sender Filter per second is the number of

messages evaluated by the Sender Filter agent per second.
Messages Filtered by Sender Filter per

second
Performance
----
Major
Messages Filtered by Sender Filter per second is the number of

messages filtered by the Sender Filter agent per second.
Messages Missing Originating IP per second

(Agent_ID)
Performance
----
Major
Messages Missing Originating IP per second is the number of

messages per second for which the originating IP could not be
determined.
Messages per Second
Performance
----
Major
This is the count of messages per second that the MTA is

processing inbound and outbound. Using this counter with the Work
Queue Length counter will give an indication of how long on average
messages are queued before delivery. Divide the average Work
Queue Length amount by the average Messages/Sec amount to
calculate how long a message can expect to remain in the queue
before being delivered.Informational for drill down.
Messages Queued For Delivery
Performance
----
Major
Messages Queued For Delivery is the number of messages

currently queued in one or more queues.
Messages queued for delivery per second
Performance
----
Major
Messages queued for delivery per second.
Messages Queued For Submission
Performance
----
Major
Messages Queued For Submission is the current number of

submitted messages which are not yet processed by transport.
Messages Received per Second
Performance
----
Major
The rate that inbound messages are being received.
Messages Received per second (inbound)
Performance
----
Major
Messages Received per second is the number of messages

received by the SMTP server each second.
Messages Scanned per second (content filter

agent)
Performance
----
Major
The number of messages scanned per second
Messages Sent per second (outbound)
Performance
----
Major
Messages Sent per second is the number of messages sent by the

SMTPSend connector each second.
Messages Sent per sec
Performance
----
Major
Messages Sent/sec is the rate that messages are sent to the

transport.
Messages Submitted Per Second
Performance
----
Major
Messages Submitted Per Second is the number of messages

enqueued in the submission queue per second.
Messages Validated per second
Performance
----
Major
Messages Validated per second is the number of messages

validated per second.
Messages With No PRA per second
Performance
----
Major
Messages With No PRA per second is the number of messages per

second that do not have a valid PRA.
Messages with Originating IP on IP Allow List

per second
Performance
----
Major
Messages with Originating IP on IP Allow List per second is the

number of messages with originating IP on the IP Allow List per
second.
Messages with Originating IP on IP Allow List

Providers per second
Performance
----
Major
Messages with Originating IP on IP Allow List Providers per second

is the number of messages with originating IP on the IP Allow List
providers per second.
Messages with Originating IP on IP Block List

per second
Performance
----
Major
Messages with Originating IP on IP Block List per second is the

number of messages with originating IP on the IP Block List per
second.
Open connections to Global Catalogs
Performance
----
Major
Open connections to Global Catalogs in this process
Page Faults per Second
Performance
----
Major
The page faults/sec counter should not show a consistently high

single figure amount. If Page faults/sec is high and if Memorypages/second counter is less than 10, it is not a concern.
Pages per Second
Performance
50
Major
Pages per Second is the rate at which pages are read from or
written to disk to resolve hard page faults. This counter is a primary
indicator of the kinds of faults that cause system-wide delays.
Paging File Usage
Performance
----
Major
The amount of the Page File instance in use in percent.
Percent Disk Time
Performance
60
Major
% Disk Time is the percentage of elapsed time that the selected disk
drive was busy servicing read or write requests.
Poison Queue Length
Performance
----
Major
Poison Queue Length is the number of items in the poison queue.
Pool Nonpaged Megabytes
Performance
100
Major
Pool Nonpaged Megabytes is the size of the nonpaged pool, an

area of system memory for objects that cannot be written to disk, but
must be in physical memory as long as they are allocated.
Processor Time
Performance
80
Major
% Processor Time is the percentage of elapsed time that the

processor spends to execute a non-idle thread.
Processor Time - emsmta
Performance
75
Major

processor spends to execute a non-idle thread of the process.
Processor Time - inetinfo
Performance
75
Major

Processor Time - lsass
Performance
75
Major

Processor Time - mad
Performance
75
Major

Processor Time - store
Performance
75
Major

Processor Time - System
Performance
75
Major

Proxy User Requests per sec
Performance
----
Major
Proxy User Requests/sec is the number of proxy requests made per

second.
Queued Conversion Requests
Performance
----
Major
Queued Conversion Requests is the number of requests for

conversion that are currently waiting to be processed.
Receive Queue Size - Mailboxes
Performance
Major
This is the queue of all messages destined inbound for the IS. As
with the Send Queue this should also stay at non-zero during
normal operating conditions.
Receive Queue Size - MBX
Performance
Major
normal operating conditions. One instance of this profile will monitor
each Mailbox Store.
Receive Queue Size - PF
Performance
Major
normal operating conditions. One instance of this profile will monitor
each Public Folder Store.
Receive Queue Size - Public Folders
Performance
Major
normal operating conditions.
Recipients Rejected by Block List per second
Performance
----
Major
Recipients Rejected by Block List per second is the number of

recipients rejected by block list per second.
Recipients Rejected by Recipient Validation

per second
Performance
----
Major
Recipients Rejected by Recipient Validation per second is the

number of recipients rejected by recipient validation per second.
Remote Queue Length
Performance
1000
Major
The number of messages in the remote SMTP queue.
Requests per sec
Performance
----
Major
Requests/sec is the number of requests handled by Outlook Web

Access per second.
Requests per sec (ActiveSync)
Performance
----
Major
Requests/sec is the number of HTTP requests that are received

from the client via ASP.NET per second.
Requests per sec Failed
Performance
----
Major
Requests/sec Failed is the number of Outlook Web Access requests

that failed, per second.
Requests per second (WS)
Performance
----
Major
Requests per second is the number of requests processed each

second.
Retry Mailbox Delivery Queue Length
Performance
----
Major
Retry Mailbox Delivery Queue Length is the number of items in retry

in the retry mailbox queues.
Send Queue Size - Mailboxes
Performance
Major
This counter displays the queue of messages outbound from the IS

to the MTA. In the case where the MTA is down or reduced in
performance there will be a non-zero value for this queue. In normal
operating conditions this queue should rarely stay at a non-zero
value for any significant duration.
Send Queue Size - MBX
Performance
Major

value for any significant duration. One instance of this profile will
monitor each Mailbox Store.
Send Queue Size - PF
Performance
Major

value for any significant duration. One instance of this profile will
monitor each Public Folder Store.
Send Queue Size - Public Folders
Performance
Major

value for any significant duration.
Sync Commands per sec (ActiveSync)
Performance
----
Major
Sync Commands/sec is the number of Sync commands that are

processed per second. Clients use this command to synchronize
items within a folder.
Unreachable Queue Length
Performance
----
Major
Unreachable Queue Length is the number of items in the

unreachable queues.
User Count
Performance
----
Major
This is the actual count of people (Not connections) that are

currently using the IS.
Virtual Megabytes used by Information Store
Performance
----
Major
Virtual Megabytes is the current size of the virtual address space the
Information Store is using. Use of virtual address space does not
necessarily imply corresponding use of either disk or main memory
pages. Virtual space is finite, and the process can limit its ability to
load libraries.
VM Largest Block Size - Information Store
Performance
150
Major
Size of the larges free virtual memory block.
VM Total 16MB Free Blocks
Performance
Major
Less than 3 indicates a problem.
VM Total Large Free Block Megabytes
Performance
32
Major
Less then 32 MB. Suggest restart Node on Cluster. Failover first.
Work Queue Length
Performance
Major
This is the most important counter because it gives the total of all
queues. This single counter can tell an administrator at a glance the
overall MTA health. This is the queue length for the whole of the
MTA. It covers both inbound and outbound messages for the
Information Store, the Directory and any connectors that route
through the MTA. If this counter is above zero for a sustained
amount of time it may indicate a communications problem with one
of the Exchange components, a connector or a remote Exchange
MTA.
Input-Output Log Read Average Latency
Performance
200
Major
Indicates the average time, in ms, to read data from a log file.
Specific to log replay and database recovery operations.
Note: This counter will work for DAG also.
DatabaseMounted
Performance
Major
Indicates whether database copy is mounted on local server.

Age of the Last Notification Indexed
Performance
172800
Major
Indicates content indexing backlog in seconds.

Input-Output Log Writes Average Latency
Performance
10
Major
Indicates the average time, in ms, to write a log buffer to the active
log file.
Time Since Last Notification Was Indexed
Performance
3600
Major
Indicates the time in seconds since last notification was indexed for
content indexing in passive Database.
Exchange search zero result query
Performance
Major
Indicates that more than one hundred search queries have returned
zero results. This may indicate that a corruption or other problem
affects the content indexing catalog.
Logical Disk Percentage Free Space
Performance
35
Major
Indicates the free space of logical disk in Percentage.

Anti-Malware Agent Messages Blocked
Performance
----
Major
Messages Blocked is the number of messages in the past minute

that contained malware and were blocked.
Anti-Malware Agent Messages Containing

Malware
Performance
-----
Major
Messages Containing Malware is the number of messages in the

past minute that contained malware.
Anti-Malware Agent Messages Scanned Per

Second
Performance
-----
Major
Messages Scanned per Second is the average numbero of

messages scanned each second, calculated over the past minute.
Anti-Malware Agent Messages Scanned
Performance
-----
Major
Messages Scanned is the number of messages scanned in the past

minute.
OAB Request Handling Average Time
Performance
-----
Major
Average Time(in seconds) of handling a file download request

during the sampling period.
Messages Delivered Per Sec - Store
Performance
-----
Major
Shows the rate that messages are delivered to all recipients.

Indicates current message delivery rate to the store.
Messages Submitted Per Second Information Store
Performance
-----
Major
Messages Submitted Per Second is the number of messages

enqueued in the submission queue per second.
Inbound: Recipients Delivered Per

Second-2013
Performance
------
Major
Shows the number of inbound recipients delivered per second.

Determines current load. Compare values to historical baselines.
Inbound:
MessageDeliveryAttemptsPerSecond-2013
Performance
-------
Major
Shows the number of attempts for delivering transport mail items per
second. Determines current load. Compare values to historical
baselines.
Inbound: LocalDeliveryCallsPerSecond-2013
Performance
------
Major
Shows the number of local delivery attempts per second.

Determines current load. Compare values to historical baselines.
EdgeSync
Process
----
Major
Belongs to Microsoft Exchange EdgeSync Service.
EdgeTransport
Process
----
Major
Child process of the Microsoft Exchange Transport Service.
File Distribution
Process
----
Major
Belongs to Microsoft Exchange File Distribution Service.
Inetinfo
Process
----
Major
Belongs to Microsoft Internet Information Services (IIS).
Information Store
Process
----
Major
Process of the Microsoft Exchange Information Store.
Lsass
Process
----
Major
Process of the Local Security Authority Subsystem Service.
Mail Submission
Process
----
Major
Belongs to Microsoft Exchange Mail Submission Service.
Mailbox Assistants
Process
----
Major
Belongs to Microsoft Exchange Mailbox Assistants Service.
Message Transfer Agent
Process
----
Major
Process of the Microsoft Exchange Message Transfer Agent.
Replication
Process
----
Major
Belongs to Microsoft Exchange Replication Service.
Search Indexer
Process
----
Major
Belongs to Microsoft Search Indexer service.
Service Host
Process
----
Major
Belongs to Microsoft Exchange Service Host Service.
System Attendant
Process
----
Major
Process of the Microsoft Exchange System Attendant.
LDAP Searches timed out per minute
Process
10
Major
LDAP Searches timed out per minute shows the number of LDAP
searches that returned LDAP_Timeout during the last minute.
Process
50
Major
LDAP Read Time shows the time (in ms) to send an LDAP read
request to the specified domain controller and receive a response.
Process
50
Major
LDAP Search Time shows the time (in ms) to send an LDAP search
request and receive a response.
Long Running LDAP Operations Per Minute
Process
50
Major
Long running LDAP operations/Min shows the number of LDAP

operations on this domain controller that took longer than the
specified threshold per minute. (Default threshold is 15 seconds.)
Average Search Time
Process
----
Major
Shows the average time that elapsed while waiting for a search to
complete.
NSPI RPC Requests Average Latency
Process
1000
Major
Shows the average time, in ms, that NSPI requests took to complete
during the sampling period.
NSPI RPC Browse Requests Average Latency
Process
1000
Major
Shows the average time, in ms, that Name Service Provider

Interface (NSPI) browse requests took to complete during the
sampling period.
Unreachable Queue Length - Transport
Process
100
Major
Unreachable Queue Length is the number of items in the

unreachable queues.
Mailbox Searches Per Sec - Store
Process
10
Major
Number of search queries/second received per database.
Transport
Process
----
Major
Belongs to Microsoft Exchange Transport Service.
Transport Log Search
Process
----
Major
Belongs to Microsoft Exchange Transport Log Search Service.
HTTP SSL
Service
----
Major
This service implements the secure hypertext transfer protocol

(HTTPS) for the HTTP service, using the Secure Socket Layer
(SSL). If this service is disabled, any services that explicitly depend
on it will fail to start.
IIS Admin Service
Service
----
Major
Enables this server to administer Web and FTP services. If this

service is stopped, the server will be unable to run Web, FTP,
NNTP, or SMTP sites or configure IIS. If this service is disabled, any
services that explicitly depend on it will fail to start.
Microsoft Exchange Active Directory Topology

Service
Service
----
Major
Provides Active Directory topology information to Exchange

services.
Microsoft Exchange ADAM
Service
----
Major
Microsoft Exchange ADAM (Active Directory Application Mode).
Microsoft Exchange Address Book
Service
----
Major
Manages client address book connections. This service is

dependent upon the Microsoft Exchange Active Directory Topology
service.
Microsoft Exchange Anti-spam Update
Service
----
Major
The Microsoft Forefront Security for Exchange Server anti-spam

update service.
Microsoft Exchange Credential Service
Service
----
Major
The Microsoft Exchange Credential Service.
Microsoft Exchange EdgeSync
Service
----
Major
The Microsoft EdgeSync service.
Microsoft Exchange File Distribution
Service
----
Major
The Microsoft File Distribution service.
Microsoft Exchange Forms-Based

Authentication
Service
----
Major
Provides forms-based authentication to Microsoft Office Outlook

Web App and the Exchange Control Panel. If this service is stopped,
Outlook Web App and the Exchange Control Panel won't
authenticate users.
Microsoft Exchange IMAP4
Service
----
Major
Provides Internet Message Access Protocol (IMAP4) Services to

clients.
Microsoft Exchange Information Store
Service
----
Major
Manages the Microsoft Exchange Information Store. This includes

mailbox stores and public folder stores.
Microsoft Exchange Mail Submission
Service
----
Major
Submits messages from the Mailbox server to the Hub Transport

servers.
Microsoft Exchange Mailbox Assistants
Service
----
Major
Performs background processing of mailboxes in the Exchange

store.
Microsoft Exchange Mailbox Replication

Service
Service
----
Major
Processes mailbox moves and move requests. This service is

dependent upon the Microsoft Exchange Active Directory Topology
and Net.Tcp Port Sharing service.
Service
----
Major
Allows applications to call the Exchange diagnostic cmdlets.
Microsoft Exchange MTA Stacks
Service
----
Major
The Microsoft Exchange Exchange MTA Stacks service.
Microsoft Exchange POP3
Service
----
Major
Provides Post Office Protocol version 3 (POP3) Services to clients.
Microsoft Exchange Protected Service Host
Service
----
Major
Provides a host for several Exchange services that must be

protected from other services. This service is dependent upon the
Microsoft Exchange Active Directory Topology service.
Microsoft Exchange Replication Service
Service
----
Major
The Microsoft Exchange Replication Service provides replication

functionality for Mailbox server role databases and is used by local
continuous replication and cluster continuous replication.
Microsoft Exchange Routing Engine
Service
----
Major
The Microsoft Exchange Routing Engine service.
Microsoft Exchange RPC Client Access
Service
----
Major
Manages client RPC connections for Exchange.
Microsoft Exchange Search Indexer
Service
----
Major
The Microsoft Exchange Replication Service provides replication

functionality for Mailbox server role databases and is used by local
continuous replication and cluster continuous replication.
Microsoft Exchange Server Extension for

Windows Server Backup
Service
----
Major
Enables Windows Server Backup users to back up and recover

application data for Microsoft Exchange Server.
Microsoft Exchange Service Host
Service
----
Major
Provides a host for several Microsoft Exchange services.
Microsoft Exchange System Attendant
Service
----
Major
Provides monitoring, maintenance, and Active Directory lookup

services, for example, monitors services and connectors,
defragments the Exchange store, and forwards Active Directory
lookups to a Global Catalog server.
Microsoft Exchange Throttling
Service
----
Major
Limits the rate of user operations.
Microsoft Exchange Transport
Service
----
Major
The Microsoft Exchange Transport Service.
Microsoft Exchange Transport Log Search
Service
----
Major
Provides remote search capability for Microsoft Exchange Transport

log files.
Microsoft Search (Exchange)
Service
----
Major
Quickly creates full-text indexes on content and properties of

structured and semi-structured data to allow fast linguistic searches
on this data.
SMTP
Service
----
Major
The Exchange Simple Mail Transfer Protocol server
World Wide Web Publishing Service
Service
----
Major
Provides Web connectivity and administration through the Internet

Information Services Manager.
MSExchange event
NT Event
Log
----
From
Event
Event log messages with source containing 'MSExchange'.
Number of Active Database copies
Database
Availability
Group
----
----
Number of active database copies on current exchange server.
Database
Availability
Group
----
----
Number of passive database copies on current Mailbox server.
Database
Availability
Group
-----
----
Number of mounted database copies on current Mailbox server.
Number of Non Mounted Database copies
Database
Availability
Group
----
-----
Number of database copies whose state is not "mounted" on current

Mailbox server
CopyQueueLength-DAG
Database
Availability
Group
Minor
Shows the number of transaction log files waiting to be copied to the

passive copy log file folder. A copy isn't considered complete until it
has been checked for corruption.
Database
Availability
Group
Minor
Shows the number of transaction log files waiting to be replayed into

the passive copy.
Database copies status-Failed
Database
Availability
Group
Minor
The mailbox database copy is in a Failed state because it isn't

suspended, and it isn't able to copy or replay log files. While in a
Failed state and not suspended, the system will periodically check
whether the problem that caused the copy status to change to
Failed has been resolved. After the system has detected that the
problem is resolved, and barring no other issues, the copy status will
automatically change to Healthy.
Database copies status-Seeding
Database
Availability
Group
Minor
The mailbox database copy is being seeded, the content index for
the mailbox database copy is being seeded, or both are being
seeded. Upon successful completion of seeding, the copy status
should change to Initializing.
Database copies status-SeedingSource
Database
Availability
Group
Minor
The mailbox database copy is being used as a source for a

database copy seeding operation.
Database copies status-Suspended
Database
Availability
Group
Minor
The mailbox database copy is in a Suspended state as a result of an

administrator manually suspending the database copy by running
the Suspend-MailboxDatabaseCopy cmdlet.
Database copies status-Healthy
Database
Availability
Group
Minor
The mailbox database copy is successfully copying and replaying

log files, or it has successfully copied and replayed all available log
files.
Database copies status-ServiceDown
Database
Availability
Group
Minor
The Microsoft Exchange Replication service isn't available or

running on the server that hosts the mailbox database copy.
Database copies status-Initializing
Database
Availability
Group
Minor
The mailbox database copy will be in an Initializing state when a

database copy has been created, when the Microsoft Exchange
Replication service is starting or has just been started, and during
transitions from Suspended, ServiceDown, Failed, Seeding,
SinglePageRestore, LostWrite, or Disconnected to another state.
While in this state, the system is verifying that the database and log
stream are in a consistent state. In most cases, the copy status will
remain in the Initializing state for about 15 seconds, but in all cases,
it should generally not be in this state for longer than 30 seconds.
Database copies status-Resynchronizing
Database
Availability
Group
Minor
The mailbox database copy and its log files are being compared
with the active copy of the database to check for any divergence
between the two copies. The copy status will remain in this state
until any divergence is detected and resolved.
Database copies status-Mounted
Database
Availability
Group
Minor
The active copy is online and accepting client connections. Only the
active copy of the mailbox database copy can have a copy status of
Mounted.
Database copies status-Dismounted
Database
Availability
Group
Minor
The active copy is offline and not accepting client connections. Only
the active copy of the mailbox database copy can have a copy
status of Dismounted.
Database copies status-Mounting
Database
Availability
Group
Minor
The active copy is coming online and not yet accepting client
connections. Only the active copy of the mailbox database copy can
have a copy status of Mounting.
Database copies status-Dismounting
Database
Availability
Group
Minor
The active copy is going offline and terminating client connections.

Only the active copy of the mailbox database copy can have a copy
status of Dismounting.
Database copies
status-DisconnectedAndHealthy
Database
Availability
Group
Minor
The mailbox database copy is no longer connected to the active

database copy, and it was in the Healthy state when the loss of
connection occurred. This state represents the database copy with
respect to connectivity to its source database copy. It may be
reported during DAG network failures between the source copy and
the target database copy.
Database copies
status-DisconnectedAndResynchronizing
Database
Availability
Group
Minor
The mailbox database copy is no longer connected to the active

database copy, and it was in the Resynchronizing state when the
loss of connection occurred. This state represents the database
copy with respect to connectivity to its source database copy. It may
be reported during DAG network failures between the source copy
and the target database copy.
Database copies status-FailedAndSuspended
Database
Availability
Group
Minor
Failed and Suspended states have been set simultaneously by the

system because a failure was detected, and because resolution of
the failure explicitly requires administrator intervention. An example
is if the system detects unrecoverable divergence between the
active mailbox database and a database copy. Unlike the Failed
state, the system won't periodically check whether the problem has
been resolved, and automatically recover. Instead, an administrator
must intervene to resolve the underlying cause of the failure before
the database copy can be transitioned to a healthy state.
Database copies status-SinglePageRestore
Database
Availability
Group
Minor
This state indicates that a single page restore operation is occurring

on the mailbox database copy.
Last Inspected Log Time
Database
Availability
Group
30
Minor
The modification time of the last log that was successfully validated
by the Mailbox server hosting the database copy.
ContentIndexState
Database
Availability
Group
failed
Minor
Indicates the current state of the content index for a database copy.
ActivationSuspended
Database
Availability
Group
Minor
Indicates whether activation of mailbox database copy is

suspended.
DatabaseSize
Database
Availability
Group
10
Minor
Database
Availability
Group
Minor
Count of redundancy of replicated mailbox databases. Both active

and passive copies are counted when determining redundancy.
Clusterservice
Database
Availability
Group
failed
Critical
Verifies that the Cluster service is running and reachable on the

local exchange server.
ReplayService
Database
Availability
Group
failed
Critical
Verifies that the Replay service is running and reachable on the

local exchange server.
ActiveManager
Database
Availability
Group
failed
Critical
Verifies that the instance of Active Manager running on the local

Exchange server is in a valid role (primary, secondary, or
stand-alone).
TasksRpcListener
Database
Availability
Group
failed
Critical
Verifies that the tasks remote procedure call (RPC) server is running
and reachable on the local Exchange server.
TcpListener
Database
Availability
Group
failed
Critical
Verifies that the TCP log copy listener is running and reachable on
the local Exchange server.
DagMembersUp
Database
Availability
Group
failed
Critical
Verifies that all DAG members are available, running, and

reachable.
Cluster Network
Database
Availability
Group
failed
Critical
Verifies that all cluster-managed networks on the local Exchange

server are available.
QuorumGroup
Database
Availability
Group
failed
Critical
Verifies that the default cluster group (quorum group) is in a healthy

and online state.
FileShareQuorum
Database
Availability
Group
failed
Critical
Verifies that the witness server and witness directory and share
configured for the DAG are reachable.
DBLogCopyKeepingUp
Database
Availability
Group
failed
Critical
Verifies that log copying and inspection by the passive copies of

databases on the local exchange server are able to keep up with log
generation activity on the active copy.
DBLogReplayKeepingUp
Database
Availability
Group
failed
Critical
Verifies that replay activity for the passive copies of databases on

the local exchange server is able to keep up with log copying and
inspection activity.
Stale security information -Quorum Group
Database
Availability
Group
------
------
The database availability group is experiencing problems that may

cause it to fail due to stale security information.
Stale security information -Cluster File Share

Witness
Database
Availability
Group
------
------
The database availability group is experiencing problems that may

cause it to eventually fail due to stale security information.
DAG Network Down
Database
Availability
Group
------
------
One or more networks supporting the database availability group

are not operating properly on this server.
Alertable failure DSNs within the last hour
Database
Availability
Group
Major
Alertable failure DSNs within the last hour is the number of alertable
failure delivery status notifications (DSNs) that have been generated
within the last hour. Some DSNs, such as Recipient Not Found, are
filtered out because they are expected to occur. Thus, we do not
want to generate an alert.
Database
Availability
Group
Major
Hub Selection Resolver Failures is the number of messages that

encountered recipient AD lookup errors in Hub selection.
Database
Availability
Group
Major
Hub Selection Organization Mailbox Failures is the number of

messages that encountered organization mailbox lookup errors in
Hub selection.
Database
Availability
Group
Major
Hub Selection Routing Failures is the number of messages that

failed to be routed.
Database
Availability
Group
Major
The ratio of successful connections to total legitimate ones in the

sliding window.
Percent Failures Due To

MaxInboundConnectionLimit
Database
Availability
Group
Major
Failure percentage of legitimate connections in the sliding window

due to MaxInboundConnectionLimit.
Percent Failures Due To WLID Down
Database
Availability
Group
Major

due to WLID down.
Percent Failures Due to back pressure
Database
Availability
Group
Major

due to back pressure.
Database
Availability
Group
Major
Total number of message delivery failures due to reaching

maximum local loop count.
Connections Created per second
Database
Availability
Group
Major
Connections Created per second is the number of new connections

to the SMTP server that are established each second.
Database
Availability
Group
Major
Number of bytes received in messages per second.
Connection created per second
Database
Availability
Group
Major

Database
Availability
Group
Major
Number of bytes received in messages per second.
Database
Availability
Group
Major
Number of bytes sent per second.
DNS Errors
Database
Availability
Group
Major
DNS Errors is the number of DNS errors encountered by the

SMTPSend connector.
Connection Failures
Database
Availability
Group
Major
Connection Failures is the number of connection failures

encountered by the SMTPSend connector.
Protocol Errors
Database
Availability
Group
Major
Protocol Errors is the number of protocol errors encountered by the

SMTPSend connector.
Inbound_LocalDeliveryCallsPerSecond
Database
Availability
Group
Major
Inbound: LocalDeliveryCallsPerSecond is the number of local

delivery calls per second.
Inbound_MessageDeliveryAttemptsPerSecond
Database
Availability
Group
Major
Inbound: MessageDeliveryAttemptsPerSecond is the number of

attempts that are made per second to deliver a message.
Inbound_Recipients_Delivered_Per_Second
Database
Availability
Group
Major
Inbound: Recipients Delivered Per Second is the number of

recipients to whom the message was delivered per second.
MessagesFailedToRoute
Database
Availability
Group
Major
Total number of messages failed to be routed.
Database
Availability
Group
Major
Hub Selection Resolver Failures is the number of messages that

encountered recipient AD lookup errors in Hub selection.
Database
Availability
Group
Major
Hub Selection Organization Mailbox Failures is the number of

messages that encountered organization mailbox lookup errors in
Hub selection.
Percentage Proxy Setup Failures
Database
Availability
Group
Major
The percentage of sessions (during the sliding time window) that

could not be proxied due to failures.
Total Proxy User Lookup Failures
Database
Availability
Group
Major
The total number of user lookup failures (during the sliding time
window) while trying to set up a proxy session.
Total Proxy Dns Lookup Failures
Database
Availability
Group
Major
The total number of dns lookup failures (during the sliding time
Total Proxy Connection Failures
Database
Availability
Group
Major
The total number of connection failures (during the sliding time

Total Bytes Proxied
Database
Availability
Group
Major
Total number of bytes proxied (after proxy session is set up.
Percentage Availability
Database
Availability
Group
Major
The ratio of successful connections to total legitimate ones in the

sliding window.
Database
Availability
Group
Major

Message Bytes Sent/sec
Database
Availability
Group
Major
Number of bytes sent per second.
Connection Failures
Database
Availability
Group
Major
Connection Failures is the number of connection failures

encountered by the SMTPSend connector.
For Microsoft Exchange Defaults, refer the following attachment:

ExchangeDefaults2010and2013.xlsx
exchange_monitor Regular Expressions

A regular expression (regex for short) is a special text string for describing a search pattern. The exchange_monitor probe uses regular
expressions to specify patterns. The defined patterns are used to match files or directories to monitor. Constructing regular expression and
pattern matching requires meta characters.
Using Regular Expressions for Files

You can use regular expressions for files monitoring. The probe matches the patterns to select the applicable files in the specified directory for
monitoring. The Pattern fields in Scan specification section of File Monitoring node in the Admin Console and File Monitoring tab in the
Infrastructure Manager support regular expressions. The patterns that are used for files are of the format filename.extension.
The * and ? symbols are wild-card operators and denote that all characters are acceptable. The * represents multiple characters while the ?
represents exactly one character.
The following table describes some examples of regex and pattern matching for files using the exchange_monitor probe.
Regular
Expression
Type of Regular
Expression
Explanation
* or ?
Standard
Matches all files in the directory
*a
Custom
Matches all files with extensions that end with the letter a. For a file without an extension, the last
letter of the filename must be a.
*.txt
Standard
Matches all files in the directory with the txt extension.
*.t*
Custom
Matches all files in the directory with an extension that starts with a t.
?.*
Standard
Matches all files in the directory with a single character filename and of any extension.
NewFile?.*
Custom
Matches all files in the directory with a letter or number after NewFile and of any extension.
Examples: NewFile1, NewFilex etc.
[a]
Standard
Matches all files in the directory with the letter a in the filename or the extension.
?[a-c]section.*
Custom
Matches all files in the directory that start with the letters a, b, or c, followed by the word section in
the filename, and of any extension.
Example: bsection.xlsx
Using Regular Expressions for Directories

You can use regular expressions for directories in file and directory monitoring profiles. The probe matches the patterns to select the applicable
directories to exclude from monitoring. The Exclude directories matching Pattern field in Scan Directory section of File Monitoring node in
the Admin Console and File Monitoring tab in the Infrastructure Manager supports regular expressions.
The path can be constructed by a combination of text and special primitives used by the system-call strftime. The list of valid primitives are
described as follows:
%a - Abbreviated weekday name
%A - Full weekday name
%b - Abbreviated month name
%B - Full month name
%c - Date and time representation appropriate for locale
%d - Day of month as decimal number (01 31)
%H - Hour in 24-hour format (00 23)
%I - Hour in 12-hour format (01 12)
%j - Day of year as decimal number (001 366)
%m - Month as decimal number (01 12)
%M - Minute as decimal number (00 59)
%p - Current locales A.M. or P.M. indicator for 12-hour clock
%S - Second as decimal number (00 59)
%U - Week of year as decimal number, with Sunday as first day of week (00 53)
%w - Weekday as decimal number (0 6; Sunday is 0)
%W - Week of year as decimal number, with Monday as first day of week (00 53)
%x - Date representation for current locale

%X - Time representation for current locale
%y - Year without century, as decimal number (00 99)
%Y - Year with century, as decimal number
%z, %Z - Time-zone name or abbreviation; no characters if time zone is unknown
%% - Percent sign
The following table describes some examples of regex and pattern matching for files using the exchange_monitor probe.
Regular Expression
Explanation
%B
Standard
Matches all directories with the full name of a month

Example: January
31%B
Custom
Matches all directories with the number 31 followed by the full name of a month
Example: 31March
%B %Y
Standard
Matches all directories with the full name of a month followed by a year
Example: January 2005.
%y/%m/%d
Custom
Matches all directories with names such as 05/10/22
fetchmsg (Fetch System Messages on iSeries)

The Fetch System Messages on iSeries (fetchmsg) probe monitors message queues on IBM iSeries systems. The probe sets up a message
space and retrieves messages from specified queues to monitor them. The probe can generate alarms when the specified threshold conditions
are breached. For example, you can generate alarm messages when specific messages appear. You can also check messages which require an
answer for missing responses.
Note: The probe does not generate any QoS messages.
More Information:
fetchmsg (Fetch System Messages on iSeries) Release Notes
v1.5 fetchmsg AC Configuration

The Fetch System Messages on iSeries (fetchmsg) probe is configured by creating monitoring profiles. You can monitor message queues on IBM
iSeries systems using these profiles and also set the properties and conditions for generating alarms. This article describes the configuration
concepts and procedures to set up the probe.
The following diagram outlines the process to configure the probe to monitor queue messages in an IBM iSeries system.
Contents
Modify Queues In Predefined Set
Create Monitoring Profile for Messages
Alarm Thresholds
Create and Configure an Exclude Profile
Verify that required hardware and software is available before you configure the probe. For more information, see fetchmsg (Fetch System
Messages on iSeries) Release Notes.

You can set up the logging, interval, and IBM iSeries message inclusion properties of the probe.
Follow these steps:
1. Click the fetchmsg node.
2. Specify the level of details that are written to the log file in the Log Level field. Log as little as possible during normal operation to
minimize disk consumption, and increase the amount of detail when debugging.
Default: 0-Fatal
3. Specify the maximum size of the probe log file, in kilobytes. When this size is reached, new log file entries are added and the older
entries are deleted.
Default: 100 KB
4. Specify the monitoring interval, in seconds, at which the probe retrieves messages from the IBM iSeries message queues. Reduce this
interval to increase the frequency of alarms.
Default: 60
Note: A shorter interval can also increase the system load.
5. Specify the initial size of the user space where the retrieved messages are temporarily stored. The size automatically increases to contain
the requested messages.
Default: 204800
6. Specify the number of messages retrieved in one read operation in Messages To Read. The probe repeats the retrieve operation after
scanning messages at the next interval, as needed. The value must be larger than the maximum amount of messages you expect during
one check interval.
Default: 10000
7. Specify the minimum severity level of the messages that are retrieved for monitoring. The value must be between 0 to 99, where 99 is the
most severe. You can also override this setting during profile configuration.
Default: 0
8. Select Include Messages Without Message ID (Impromptu Messages) to select messages without a message ID. Both users and
applications can create messages without message ID.
9. Select the message queues that are monitored from the Message Queues To Read drop-down list.
Note: If you select Predefined Set, the queues specified in Raw Configure are monitored. For more information, see the Modif
y Queues in Predefined Set section.
10. Specify the queue to retrieve the messages in Messages From Queue if Predefined Set is selected.
11. Click Save to save the probe configuration.

By default, the Predefined Set of queues allows you to monitor qSysMsg or qSysOpr, or both. You can add more queues for monitoring from the
Raw Configure interface.
Follow these Steps:
1. Open the Raw Configure interface of the probe.
2. Navigate to the setup > queues node in the left pane.
3. Click the Add Section button from the toolbar.
4. Specify the queue name for the section.
5. Click Add.
The section is created as a child node under the queues node.
6. Select the created node.
7. Add the following two keys to the node and specify their values:
name
lib
8. Click Apply to save the changes to the Predefined Set.

You can create a profile from the list of messages in the All Messages node. The probe creates the profile and automatically populates details of
the message.
Messages from temporary queues are not always present in the All Messages node. You can also create profiles for these messages and the
probe generates the necessary alarms only when the specified message is found.
Note: Until the monitored system creates the specified queue with the message, an active profile generates an alarm indicating that the
message is not found. When the specified message is found, the profile generates the configured alarms, as applicable.
Follow these steps:

1. Click the Options (icon) next to the Profiles node.
A profile is created under the Profiles node.
5. Click Save.
The created profile is saved.

Name and activation status of the profile
Properties of the message in a profile to monitor multiple messages using regular expressions. For more information, see the Using
Regular Expressions section.
Alarms that the profile generates
Follow these steps:
1. Click the Profile Name node of the profile to be configured.
3. In the Send Alarm section, select the alarm message to use in Use Alarm Message.
4. Set or modify the following values for the messages in the Alarm Message section:
Using The Following Reply: define the text which is sent as a reply to the unanswered messages.
Answer Limit: specify the maximum number of answer messages that can be sent. The Send Alarm on Answer Limit Breach Using
Alarm Message field is enabled.
Send Alarm on Answer Limit Breach Using Alarm Message: select to send an alarm when the answer limit is breached. The
Answer Message field is enabled.
Answer Message: specify the text of the answer message.
5. Set or modify the following values for the messages in the Alarm Parameter section:
Suppression Key: specify the suppression key to send only one instance of a repeated alarm.
Default: $profile/$key
Time Frame: specify the time frame of the message, which prevents the generation of multiple alarms for duplicate messages. You
can select an existing time frame from the list or specify a new time frame. The format for the time frame is <duration><unit>.
Example: 15min
Message Count Operator: select a logical operator to be used with the Message Count Value field. The operator allows you to
define conditions for the threshold to generate alarms. For example, select <= to specify the maximum value.
Message Count Value: define the threshold value of the number of messages. The profile generates an alarm if the message count
within the specified time frame breaches the specified message count condition.
6. Set or modify the following values for the messages in the Message Recognition section:
Id: indicate the seven-character message identifier which identifies the message in the associated When Matching field.
When Matching: specify a message identifier if Id is selected. You can use regular expressions to specify the value. For more
information, see the Using Regular Expressions section.
Severity: select to specify the minimum severity level of the messages that are retrieved for monitoring in the associated When (>=) fi
eld.
When (>=): specify the minimum numeric severity of the message that is retrieved if Severity is selected. The value can be between
0 to 99, where 99 is the most severe.
Type: select to specify the type of message in the associated When Matching field. You can select the type of message from the
drop-down list.
When Matching: specify the message type if Type is selected. You can select an existing message type from the list of types or
specify a new type. You can use regular expressions to specify the new value. For more information, see the Using Regular
Expressions section.
Text: select to specify the message text in the associated When Matching field.
Help Text (Description): select to specify additional information about the message queue and is specified in the associated When
Matching field.
When Matching: specify the message text and description depending on the associated field. You can use regular expressions to
specify the value. For more information, see the Using Regular Expressions section.
Is Unanswered: select this checkbox to generate an alarm if a message is not answered.
Job Name: select to specify the job name of the generated message in the associated When Matching field.
User Profile Name: select to specify the job owner of the generated message in the associated When Matching field.
When Matching: specify the job name and the user profile name depending on the associated field. You can use regular expressions
to specify the value. For more information, see the Using Regular Expressions section.
Only If Not Matched By Other Profile: select to indicate the probe to use a message only if the message does not match in any
other profile.
Look In Queue: select the message queue from the drop-down list for monitoring. This field is only available if Predefined Set is
selected in the fetchmsg node.
7. Click Save to save the configuration and start monitoring.

target string. The * and ? symbols are wild card operators and denote that all characters are acceptable. The * represents multiple characters
while the ? represents exactly one character.
The probe matches the patterns to select the applicable messages for monitoring.
Profile Name
The following fields in the Profile Name node support regular expressions:
When matching (Type)
When matching (Text)
When matching (Help Text)
When matching (Job Name)
When matching (User Profile Name)
The probe monitors the messages that fulfill the criteria for all these fields.
Exclude Profile Name
The following fields in the Exclude Profile Name node support regular expressions:
When matching (Id)
The probe excludes the messages that fulfill the criteria for all these fields from monitoring.
Sample Regular Expressions

The following table lists some examples of regex and pattern matching for the probe.
Regular expression
Explanation
[A-Z]
Standard (PCRE)
Standard (PCRE)
\d*
Custom
Alarm Thresholds
allow the probe to:

This section describes the process to exclude required messages from monitoring using exclude profiles.
Follow these steps:
1. Click the Options (icon) next to the Excludes node.
2. Select Add Exclude.
The Add Exclude dialog appears.
3. Set or modify the following values to create an exclude profile:
Active: activate the profile, when selected.
User Profile Name: define the name of the exclude profile.
Severity: indicate the maximum numeric severity of the message that is excluded in the associated When (<=) field.
When (<=): specify the maximum numeric severity of the message that is excluded if Severity is selected. The value can be between
0 to 99, where 99 is the most severe.
Type: indicate the type of message in the associated When Matching field. You can select the type of message from the drop-down
list.
Text: indicate the message text, inserted in the associated When Matching field.
Help Text (Description): indicate additional information about the message queue and is specified in the associated When Matching
field.
Job Name: indicate the job name of the generated message in the associated When Matching field.
User Profile Name: indicate the job owner of the generated message in the associated When Matching field.
When Matching: specify the message type, message text, description, job name, and user profile name depending on the associated
field. You can use regular expressions to specify the value. For more information, see the Using Regular Expressions section.
Queue Name: select the message queue that is monitored from the drop-down list. The options are only available if Predefined Set i
s selected in the fetchmsg node.
4.

An exclude profile is created under the Excludes node.
5. Click Save.
The created exclude profile is saved.
v1.5 fetchmsg AC GUI Reference

This article describes the Admin Console interface and fields to configure the Fetch System Messages on iSeries (fetchmsg) probe.
Contents
fetchmsg Node
All Messages Node
Excludes Node
<Exclude Profile Name> Node
Profiles Node
<Profile Name>Node
fetchmsg Node
The fetchmsg node allows you to view the probe and alarm message details, and also configure the log properties. You can also select the
message queues that you want to monitor.
Navigation: fetchmsg
fetchmsg > Probe Information
fetchmsg > General
This section allows you to configure the general setup properties of the probe. You can configure the log properties and control which messages
to fetch.
Default: 0 - Fatal
Log Size: specifies the size of the log file to which the internal log messages of the probe are written, in kilobytes. When this size is
Default: 100 KB
Check Interval In Seconds (Perform Check Each): specifies the time interval at which the probe retrieves messages from the IBM
iSeries message queues. Reduce this interval to increase the frequency of alarms.
Default: 60
User space size: specifies the initial size of the user space where the retrieved messages are temporarily stored. The size automatically
increases to contain the requested messages.
Default: 204800
Messages to read: specifies the number of messages retrieved in one operation. The probe repeats the retrieve operation after scanning
messages at the next interval, as needed. The value must be larger than the maximum amount of messages you expect during one
check interval.
Default: 10000
Only messages with severity >=: specifies the minimum severity level of the messages that are retrieved for monitoring. The value
must be between 0 to 99, where 99 is the most severe. You can also override this setting during profile configuration.
Default: 0
Include Messages Without Message ID (Impromptu Messages): enables you to select messages without message ID. Both users and
Message Queues To Read: specifies the message queues that are monitored.
The available options are as follows:
qSysOpr Only: Only the qSysOpr queue is monitored. This is the default selection.
Predefined Set: The queues specified in Raw Configuration are monitored. For more information, see the Modify Queues in
Predefined Set section in the v1.5 fetchmsg AC Configuration article.
Messages From Queue: specifies the queue to retrieve the messages if Predefined Set is selected in Message Queues To Read.
Default: qSysOpr and qSysMsg
fetchmsg > Alarm Messages
This section allows you to view the alarm messages.
Name: indicates the name of the alarm message.
Default: indicates the default message for each alarm situation (such as default, error, and answer_limit).
All Messages Node

The All Messages node contains a list of all the messages in the monitored message queue. The information in this node appears according to
specified values in the Message Queues To Read and Messages From Queue fields in the fetchmsg node.
Navigation: fetchmsg > All Messages
The parameters that are used to recognize a specific message are as follows:
Id: indicates the seven-character message identifier which identifies the message.
Severity: indicates a number from 0 to 99, where 99 is most severe.
Text: indicates the message text.
Help Text: indicates the additional information about the message.
Type: indicates the type of message.
Time Generated: indicates the time while generating the message.
Job Name: indicates the job name of the generated message.
User Profile Name: indicates the job owner of the generated message.
Job Number: indicates the job number of the generating message.
The Create Profile option under the Actions drop-down enables you to create a monitoring profile. The probe creates the profile and
automatically populates details of the message.
Excludes Node
The Excludes node is used to create a profile to exclude a message from monitoring by the probe.
Navigation: fetchmsg > Excludes
Excludes > Options (icon) > Add Exclude
This section lets you specify the profiles for messages that the probe excludes from monitoring.
Add Exclude Window
This window allows you to specify the parameters to create an exclude profile. The fields in the window are as follow:
Active: activates the profile, when selected.
User Profile Name: defines the name of the exclude profile.
Id: indicates the seven-character message identifier which identifies the message in the associated When Matching field.
When Matching: specifies a message identifier if Id is selected. You can use regular expressions to specify the value. For more
information, see the Using Regular Expressions section in the v1.5 fetchmsg AC Configuration article.
Severity: indicates the maximum numeric severity of the message that is excluded in the associated When (<=) field.
When (<=): specifies the maximum numeric severity of the message that is excluded if Severity is selected. The value can be between 0
to 99, where 99 is the most severe.
Type: indicates the type of message in the associated When Matching field. You can select the type of message from the drop-down
list.
Text: indicates the message text in the associated When Matching field.
Help Text (Description): indicates additional information about the message queue and is specified in the associated When Matching fi
eld.
Job Name: indicates the job name of the generated message in the associated When Matching field.
User Profile Name: indicates the job owner of the generated message in the associated When Matching field.
When Matching: specifies the message type, message text, description, job name, and user profile name depending on the associated
field. You can use regular expressions to specify the value. For more information, see the Using Regular Expressions section in the v1
.5 fetchmsg AC Configuration article.
Queue Name: selects the message queue that is monitored from the drop-down list. The options are only available if Predefined Set is
<Exclude Profile Name> Node

This node is used to configure the message parameters to filter required messages and remove them from monitoring.
Navigation: fetchmsg > Excludes > Exclude Profile Name Node
Note: The fields in this node are the same as the fields in the Add Exclude window of the Excludes node.
Excludes > Exclude Profile Name > Options (icon) > Delete
This option allows you to delete the exclude profile.
Profiles Node
This node is used to create a monitoring profile. You can create multiple monitoring profiles with different criteria to monitor the messages. All
monitoring profiles are displayed under this node.
Profiles > Options (icon) > Add Profile
This section allows you to create profiles in the fetchmsg probe.
Add Profile Window
This window allows you to specify a name and create a monitoring profile.
<Profile Name>Node
The Profile Name node is used to define the monitoring criteria of the messages and generate alarms. The monitoring profile sets up the
requirements and alerts the user when something unexpected occurs.
Navigation: fetchmsg > Profiles > Profile Name
Profile Name > Edit Profile
This section enables you to edit the monitoring profile.
User Profile Name: indicates the profile name.
Profile Name > Send Alarm
This section enables you to send alarm message when an alarm condition arises.
Use Alarm Message: allows you to select the alarm message when an alarm condition arises. The default message is used if an alarm
message is not specified.
Profile Name > Answer Message
This section enables you to send a reply to unanswered messages.
Using the Following Reply: defines the text which is sent as a reply to the unanswered messages.
Answer Limit: specifies the maximum number of answer messages that can be sent.
Send Alarm on Answer Limit Breach Using Alarm Message: enables you to configure the alarm when the answer limit is breached.
Answer Message: specifies the text of the answer message.
Profile Name > Alarm Parameter
This section lets you define the suppression key which is used for alarms that are sent by this profile.
Suppression Key: specifies the suppression key to send only one instance of a repeated alarm.
Time Frame: specifies the time frame of the message, which prevents the generation of multiple alarms for duplicate messages. You can
select an existing time frame from the list or specify a new time frame.
Message Count Operator: allows you to select a logical operator to be used with the Message Count Value field. The operator allows
you to define conditions for the threshold to generate alarms. For example, select <= to specify the maximum value.
Message Count Value: specifies the threshold value of the number of messages. The profile generates an alarm if the message count
within the specified time frame breaches the specified message count condition.
Profile Name > Message Recognition
This section lets you set the criteria that the profile uses to retrieve messages.
Id: indicates the seven-character message identifier which identifies the message in the associated When matching field.
When matching: specifies a message identifier if Id is selected. You can use regular expressions to specify the value. For more
information, see the Using Regular Expressions section in the v1.5 fetchmsg AC Configuration article.
Severity: indicates the minimum severity level of the messages that are retrieved for monitoring in the associated When (>=) field.
When (>=): specifies the minimum numeric severity of the alarm if Severity is selected. The value can be between 0 to 99, where 99 is
the most severe.
Type: indicates the type of message in the associated When Matching field. You can select the type of message from the drop-down
list.
When Matching: specifies the message type if Type is selected. You can select an existing message type from the list of types or
Expressions section in the v1.5 fetchmsg AC Configuration article.
Text: indicates the message text in the associated When Matching field.
Help Text (Description): indicates additional information about the message queue and is specified in the associated When Matching fi
eld.
When Matching: specifies the message text and description depending on the associated field. You can use regular expressions to
specify the value. For more information, see the Using Regular Expressions section in the v1.5 fetchmsg AC Configuration article.
Job Name: indicates the job name of the generated message in the associated When Matching field.
User Profile Name: indicates the job owner of the generated message in the associated When Matching field.
When Matching: specifies the job name and the user profile name depending on the associated field. You can use regular expressions
to specify the value. For more information, see the Using Regular Expressions section in the v1.5 fetchmsg AC Configuration article.
Only If Not Matched By Other Profile: enables you to select a message only if the message does not match in any other profile.
Look In Queue: selects the message queue from the drop-down list for monitoring. This field is only available if Predefined Set is
v1.5 fetchmsg IM Configuration

The Fetch System Messages on iSeries (fetchmsg) probe is configured by creating monitoring profiles. You can monitor message queues on IBM
iSeries systems using these profiles and also set the properties and conditions for generating alarms. This article describes the configuration
concepts and procedures to set up the probe.
The following diagram outlines the process to configure the probe to monitor queue messages in an IBM iSeries system.
Contents
Setup General Properties
Verify that required hardware and software is available before you configure the probe. For more information, see fetchmsg (Fetch System
Messages on iSeries) Release Notes.
Setup General Properties

You can set up the logging, interval, and IBM iSeries message inclusion properties of the probe.
Follow these steps:
1. Open the Setup tab.
2. In the General tab, Check interval field, specify the monitoring interval, in seconds, at which the probe retrieves messages from the IBM
iSeries message queues. Reduce this interval to increase the frequency of alarms.
Default: 60
3. Specify the initial size of the user space where the retrieved messages are temporarily stored. The size automatically increases to contain
the requested messages.
Default: 204800
4. Specify the number of messages retrieved in one operation in Messages to read. The probe repeats the retrieve operation after
scanning messages at the next interval, as needed. The value must be larger than the maximum amount of messages you expect during
one check interval.
Default: 10000
5. Specify the minimum severity level of the messages that are retrieved for monitoring. The value must be between 0 to 99, where 99 is the
5.
most severe. You can also override this setting during profile configuration.
Default: 0
6. Select Include messages without message ID (impromptu messages) to select messages without a message ID. Both users and
7. Select the level of details that are written to the log file in the Log Level field. Log as little as possible during normal operation to minimize
Default: 0-Fatal
8. Specify the maximum size of the probe log file, in kilobytes. When this size is reached, new log file entries are added and the older
entries are deleted.
Default: 100 KB
9. Select the message queues that are monitored from the Message queues to read drop-down list.
Note: If you select Predefined Set, the queues specified in Raw Configuration are monitored. For more information, see the M
odify Queues in Predefined Set section.

By default, the Predefined Set of queues allows you to monitor qSysMsg or qSysOpr, or both. You can add more queues for monitoring from the
Raw Configuration interface.
Follow these Steps:
1. Open the Raw Configuration interface of the probe.
2. Navigate to setup > queues in the left pane.
3. Click New Section.
4. Specify the queue name for the section.
5. Click OK.
The section is created as a child node under the queues node.
6. Select the created section.
7. Add the following two keys to the node and specify their values:
name
lib
8. Click Apply to save the changes to the Predefined Set.

You can create a profile from the list of messages in the All Messages tab. The probe creates the profile and automatically populates details of
the message.
Messages from temporary queues are not always present in the All Messages node. You can also create profiles for these messages and the
probe generates the necessary alarms only when the specified message is found.
Note: Until the monitored system creates the specified queue with the message, an active profile generates an alarm indicating that the
message is not found. When the specified message is found, the profile generates the configured alarms, as applicable.
Follow these steps:

1. Right-click in the Profiles tab.
2. Select New.

A profile is created in the Profiles tab.
5. Click Apply.
The created profile is saved.

Name and activation status of the profile
Properties of the message in a profile to monitor multiple messages using regular expressions. For more information, see the Using
Regular Expressions section.
Alarms that the profile generates
Follow these steps:
1. Double-click the profile to be configured. You can also right-click and select Edit.
3. Set or modify the following values for the messages in the Message recognition tab:
Severity: select to specify the minimum severity level of the messages that are retrieved for monitoring in the associated When (>=) fi
eld.
When (>=): specify the the minimum numeric severity of the message that is retrieved if Severity is selected. The value can be
between 0 to 99, where 99 is the most severe.
Type: select to specify the type of message in the associated When Matching field. You can select the type of message from the
drop-down list.
When Matching: specify the message type if Type is selected. You can select an existing message type from the list of types or
Expressions section.
Text: select to specify the message text in the associated When Matching field.
Help Text (Description): select to specify additional information about the message queue and is specified in the associated When
Matching field.
When Matching: specify the message text and description depending on the associated field. You can use regular expressions to
specify the value. For more information, see the Using Regular Expressions section.
Job Name: select to specify the job name of the generated message in the associated When Matching field.
User Profile Name: select to specify the job owner of the generated message in the associated When Matching field.
When Matching: specify the job name and the user profile name depending on the associated field. You can use regular expressions
to specify the value. For more information, see the Using Regular Expressions section.
Only If Not Matched By Other Profile: select to indicate the probe to use a message only if the message does not match in any
other profile.
Look In Queue: select the message queue from the drop-down list for monitoring. This field is only available if Predefined Set is
selected in the Setup tab.
4. Open the Actions tab.
5. In the Send Alarm section, select Send alarm to enable alarms.
6. Select the alarm message to use in Use Alarm Message.
7. Set or modify the following values for the messages in the Alarm message section:
Answer Message: select to enable answers to messages.
7.
Using the following reply: define the text which is sent as a reply to the unanswered messages.
Answer limit: specify the maximum number of answer messages that can be sent. The Send alarm on answer limit breach using
alarm message field is enabled.
Send alarm on answer limit breach using alarm message: select to send an alarm when the answer limit is breached. Select the
alarm from the drop-down list.
8. Set or modify the following values for the messages in the Alarm parameter section:
Suppression key: specify the suppression key to send only one instance of a repeated alarm.
Time frame: specify the time frame of the message, which prevents the generation of multiple alarms for duplicate messages. You
can select an existing time frame from the list or specify a new time frame. The format for the time frame is <duration><unit>.
Example: 15min
Message count: select a logical operator and define the threshold value of the number of messages. The profile generates an alarm
if the message count within the specified time frame breaches the specified message count condition. For example, select <= to
specify the maximum value.
9. Click Save to save the configuration and start monitoring.

This section describes the process to create an exclude profile in the fetchmsg probe. An exclude profile allows you to exclude required
messages from monitoring.
Follow these steps:
1. Open the Excludes tab.
2. Right-click and select New.
The Exclude Message dialog appears.
3. Set or modify the following values to create an exclude profile:
Name: define the name of the exclude profile.
Active: activate the profile, when selected.
Severity: indicate the maximum numeric severity of the message that is excluded in the associated When (<=) field.
When (<=): specify the the maximum numeric severity of the message that is excluded if Severity is selected. The value can be
between 0 to 99, where 99 is the most severe.
Type: indicate the type of message in the associated When Matching field. You can select the type of message from the drop-down
list.
Text: indicate the message text in the associated When Matching field.
Help Text (Description): indicate additional information about the message queue and is specified in the associated When Matching
field.
Job Name: indicate the job name of the generated message in the associated When Matching field.
User Profile Name: indicate the job owner of the generated message in the associated When Matching field.
When Matching: specify the message type, message text, description, job name, and user profile name depending on the associated
field. You can use regular expressions to specify the value. For more information, see the Using Regular Expressions section.
Queue Name: select the excluded message queue from the drop-down list. This field is only available if Predefined Set is selected in
the Setup tab.
An exclude profile is created under the Excludes node.
5. Click Apply.
The created exclude profile is saved.

target string. The * and ? symbols are wild card operators and denote that all characters are acceptable. The * represents multiple characters
while the ? represents exactly one character.
The probe matches the patterns to select the applicable messages for monitoring.
Profile Window
The following fields in the Profile window support regular expressions:
The probe monitors the messages that fulfill the criteria for all these fields.
Exclude Message Window
The following fields in the Exclude Message support regular expressions:
When matching (Id)
The probe excludes the messages that fulfill the criteria for all these fields from monitoring.
Sample Regular Expressions
The following table lists some examples of regex and pattern matching for the probe.
Regular expression
Explanation
[A-Z]
Standard (PCRE)
Standard (PCRE)
\d*
Custom
v1.5 fetchmsg IM GUI Reference

This article describes the Infrastructure Manager interface and fields to configure the Fetch System Messages on iSeries (fetchmsg) probe.
Contents
Setup Tab
General Tab
Messages Tab
Profiles Tab
Profile Window
All Messages Tab

Exclude Tab
Setup Tab
The Setup tab allows you to view the probe and alarm message details, and also configure the log properties.
General Tab
The General tab allows you to configure the general setup properties of the probe. You can configure the log properties and control which
messages to retrieve. The fields in this tab are as follows:
Check Interval: specifies the time interval at which the probe retrieves messages from the IBM iSeries message queues. Reduce this
interval to increase the frequency of alarms.
Default: 60
Default: 0 - Fatal
Default: 100 KB
User space size: specifies the initial size of the user space where the retrieved messages are temporarily stored. The size automatically
increases to contain the requested messages.
Default: 204800
Messages to read: specifies the number of messages retrieved in one operation. The probe repeats the retrieve operation after scanning
messages at the next interval, as needed. The value must be larger than the maximum amount of messages you expect during one
check interval.
Default: 10000
Only messages with severity >=: specifies the minimum severity level of the messages that are retrieved for monitoring. The value
must be between 0 to 99, where 99 is the most severe. You can also override this setting during profile configuration.
Default: 0
Include Messages Without Message ID (Impromptu Messages): enables you to select messages without message ID. Both users and
Message Queues To Read: specifies the message queues that are monitored.
The available options are as follows:
qSysOpr Only: Only the qSysOpr queue is monitored. This is the default selection.
Predefined Set: The queues specified in Raw Configuration are monitored. For more information, see the Modify Queues in
Predefined Set section in the v1.5 fetchmsg AC Configuration article.
Messages Tab
The Messages tab allows you to view, modify, or delete alarm messages.
Messages in this tab have the following details:
Name: indicates the name of the alarm message.
Default: indicates the default message for each alarm situation (such as default, error, and answer_limit).
Variable Expansion in Messages
You can use the following variable in messages using the $ symbol:
$profile
$id
$key
$text
$description
$job_name
$user_profile_name
$job_number
$type
$severity
$date
$time
$error
$answer
$answer_limit
$queue
Note: One of the alarm messages can be designated as the default message and is used for profiles in which no alarm message is
specified. You can also specify a message tagged as error which is the default message for error situations.
Profiles Tab
The Profiles tab allows you to create monitoring profiles. You can create multiple monitoring profiles with different criteria to monitor the
messages. All monitoring profiles are displayed in this tab.
Profile Window
The Profile window is used to define or modify the monitoring criteria of the messages and generate alarms. The monitoring profile sets up the
requirements and alerts the user when something unexpected occurs.
The fields in this window are as follows:
Name: indicates the profile name.
The Profile window has the following tabs:
Message recognition
Actions
Message recognition Tab
This tab allows you to set the criteria that the profile uses to retrieve messages. The fields in the tab are as follows:
information, see the Using Regular Expressions section in the v1.5 fetchmsg IM Configuration article.
Severity: indicates the minimum severity level of the messages that are retrieved for monitoring in the associated When (>=) field.
When (>=): specifies minimum numeric severity of the message that is retrieved if Severity is selected. The value can be between 0 to
99, where 99 is the most severe.
Type: indicates the type of message in the associated When matching field. You can select the type of message from the drop-down
list.
When matching: specifies the message type if Type is selected. You can select an existing message type from the list of types or
Expressions section in the v1.5 fetchmsg IM Configuration article.
Text: indicates the message text in the associated When matching field.
Help text (description):indicates additional information about the message queue and is specified in the associated When matching fiel
d.
When matching: specifies the message text and description depending on the associated field. You can use regular expressions to
specify the value. For more information, see the Using Regular Expressions section in the v1.5 fetchmsg IM Configuration article.
Is unanswered: select this checkbox to generate an alarm if a message is not answered.
Job name: indicates the job name of the generated message in the associated When matching field.
User profile name: indicates the job owner of the generated message in the associated When matching field.
When matching: specifies the job name and the user profile name depending on the associated field. You can use regular expressions
to specify the value. For more information, see the Using Regular Expressions section in the v1.5 fetchmsg IM Configuration article.
Only if not matched by other profile: enables you to select a message only if the message does not match in any other profile.
Look in queue: selects the message queue from the drop-down list for monitoring. This field is only available if Predefined Set is
selected in the Setup tab.
Actions Tab
This tab enables you to configure alarm message when an alarm condition arises. The fields in this tab are as follows:
Send alarm: enables alarms for the profile.
Use Alarm Message: allows you to select the alarm message when an alarm condition arises. The default message is used if an
alarm message is not specified.
Answer message: enables answers to messages.
Using the following reply: defines the text which is sent as a reply to the unanswered messages.
Answer limit: specifies the maximum number of answer messages that can be sent. The Send alarm on answer limit breach using
alarm message field is enabled.
Send alarm on answer limit breach using alarm message: enables you to configure the alarm when the answer limit is
breached. Select the alarm from the drop-down list.
Alarm parameter
This section allows you to set up thresholds for the alarms.
Suppression key: specifies the suppression key to send only one instance of a repeated alarm.
Time frame: specifies the time frame of the message, which prevents the generation of multiple alarms for duplicate messages. You
can select an existing time frame from the list or specify a new time frame.
Message count: selects a logical operator and defines the threshold value of the number of messages. The profile generates an
alarm if the message count within the specified time frame breaches the specified message count condition. For example, select <= to
specify the maximum value.
All Messages Tab

The All Messages tab contains a list of all the messages in the monitored message queue. The information in this node appears according to
value specified in the Message queues to read field in the Setup tab.
The tab has the following field:
Messages from queue: specify the queue to retrieve the messages if Predefined Set is selected in Message queues to read.
The parameters that are used for recognizing a specific message are:
Id: indicates the seven-character message identifier which identifies the message.
Severity: indicates a number from 0 to 99, where 99 is most severe.
Help Text: indicates the additional information about the message.
Type: indicates the type of message.
Time Generated: indicates the time while generating the message.
Answered: indicates whether a response for the message was sent or not.
Job Name: indicates the job name of the generated message.
User Profile Name: indicates the job owner of the generated message.
Job Number: indicates the job number of the generating message.
The Create profile option when you right-click a message enables you to create a monitoring profile. The probe creates the profile and
automatically populates details of the message.
Exclude Tab
The Exclude tab is used to create a profile to exclude a message from monitoring by the probe.
This window allows you to specify the parameters to create an exclude profile. The fields in the window are as follow:
Name: defines the name of the exclude profile.
information, see the Using Regular Expressions section in the v1.5 fetchmsg IM Configuration article.
Severity: indicates the maximum numeric severity of the message that is excluded in the associated When (<=) field.
When (<=): specifies maximum numeric severity of the message that is excluded if Severity is selected. The value can be between 0 to
99, where 99 is the most severe.
Type: indicates the type of message in the associated When matching field. You can select the type of message from the drop-down
list.
Text: indicates the message text in the associated When matching field.
Help text (description): indicates additional information about the message queue and is specified in the associated When matching fie
ld.
Job name: indicates the job name of the generated message in the associated When matching field.
User profile name: indicates the job owner of the generated message in the associated When matching field.
When matching: specifies the message type, message text, description, job name, and user profile name depending on the associated
field. You can use regular expressions to specify the value. For more information, see the Using Regular Expressions section in the v1.
5 fetchmsg IM Configuration article.
Queue name: selects the excluded message queue from the drop-down list. This field is only available if Predefined Set is selected in
the Setup tab.
fetchmsg Metrics
The Fetch System Messages on iSeries (fetchmsg) probe includes a set of alarm messages that can be generated for different situations.

The following table describes the default settings for queue messages on IBM iSeries systems.
Alarm Metric
Error Severity
Description
MsgAlarm
Major
The message text as an alarm
MsgError
Major
The probe was unable to answer a message
MsgLimit
Major
The probe did not answer messages as it breached the answer limit
file_adapter (File Adapter)

The File Adapter probe monitors the third-party applications to integrate Quality of Service (QoS) data to the CA Unified Infrastructure
Management monitoring Server. The applications export the QoS data to files. The File Adapter probe reads the files that match the search
criteria and generates one QoS message per file row. The files are deleted once QoS data is generated.
More information:
file_adapter Release Notes
v1.4 file_adapter AC Configuration
Configure A Node
Manage Profiles
Delete Profile
Alarm Thresholds
Configure A Node
This node provides the information to configure a section within a node.
Each section within the node enables you to configure the properties of the File Adapter probe.
Manage Profiles
You can add a monitoring profile which is displayed as a child node under the file_adapter node.
Follow these steps:
1. Click Options beside the Profiles node.
2. Click Add Profile.
3. Specify profile details in the Add Profile dialog and click Submit.
Refer to the General Configuration section of the profile name node for field descriptions.
The profile details are saved.
Delete Profile
If you no longer want the probe to monitor the log messages, you can delete the profile.
Follow these steps:
1. Click Options beside the profile name node.
2. Click Delete.
Alarm Thresholds
allow the probe to:
v1.4 file_adapter AC GUI Reference
Datetime format
Data File Format
file_adapter Node
<profile name> Node
Profiles Node
The File Adapter probe is configured to generate QoS data from third party applications and generate alarms when errors are found. You can
create profiles and groups to search for files. The profiles are configured to set the search criteria for files.
Datetime format
The File Adapter probe uses Datetime format for searching specific files in the directory. The Datetime format is used in one of the columns of the
file.
The following formatting codes are available:
%a: indicates the Abbreviated weekday name.
%A: indicates the Full weekday name.
%b: indicates the Abbreviated month name.
%B: indicates the Full month name.
%d: indicates the Day of the month as the decimal number (01 - 31).
%H: indicates the Hour in 24-hour format (00 - 23).
%I: indicates the Hour in 12-hour format (01 - 12).
%j: indicates the Day of the year as the decimal number (001 - 366).
%m: indicates the Month as the decimal number (01 - 12).
%M: indicates the Minute as the decimal number (00 - 59).
%p: indicates the Current time zone as A.M./P.M. indicator for 12-hour clock.
%S: indicates the Second as the decimal number (00 - 59).
%w: indicates the Weekday as the decimal number (0 - 6; Sunday is 0).
%y: indicates Year without century, as decimal number (00 - 99).
%Y: indicates the Year with century, as decimal number.
%%: indicates the Percent sign.
For Example, "%Y/%m/%d %H:%M:%S" translates to "2005/11/30 15:40:14".
Note: "%I" indicates the hour, and am/pm setting (%p) must be placed after %I in the date format.
Data File Format

The data files to be imported must have a "column-separator". The probe is can distinguish the different sample values to extract from each line of
the file.
The following sample values are available for extraction from each line:
Datetime value (mandatory, Datetime format must be configured).
Quality of Service value (mandatory, must be a numeric value).
Standard Deviation value (optional, must be a numeric value).
file_adapter Node
This node lets you view the probe information and configure the log properties.
Navigation: file_adapter
file_adapter > Probe Information
file_adapter > General Configuration
This section lets you configure the log properties of File Adapter probe.
Log Level: Defines the detail level of the log file.
<profile name> Node

This section lets you configure the profile properties. You can set the file processing criteria, date and time format, pattern matching criteria and
alarm properties.
Note: This node is referred to as profile name node in the document as it is user-configurable.
Navigation: file_adapter > Profiles > profile name

profile name > General Configuration
This section lets you configure profile properties and set the date and time criteria for file processing.
Active: Activates the profile.
Day (s): Defines the days on which the File Adapter probe checks the file.
Time: Defines the time on the specified days at which the File Adapter probe checks the file.
Frequency: Specifies the number of times the file is checked.
Interval: Checks the file immediately.
Daily: Checks at the specified time every day.
Weekly: Checks at the specified day and time every week.
Monthly: Checks at the specified date and time every month.
profile name > Input
This section lets you configure the pattern matching criteria of the profile.
Network Drive: Indicates that the file is imported from the network drive.
Import Directory: Defines the file location. The File Adapter probe uses pattern matching to locate the file.
New Filename or Pattern: Defines the filename. The File Adapter probe supports pattern matching on files.
Skip Input Line When First Character is a Comment Symbol: The probe skips input lines beginning with comments.
User Name: Defines the user name for the Network Drive.
profile name > Columns
This section lets you configure the formatting codes to locate the file on the drive. The fields match the columns in the file.
Datetime Format: Specifies the existing or customized date and time format.
DateTime: Specifies the Datetime column of the file and is a mandatory field unless the Datetime Format is set as Current.
QoS: Defines the QoS column of the file and is a mandatory field.
StDev: Indicates the standard deviation value of the file.
Seperator: Indicates the character to be used as a separator in the rows of the file.
profile name > Output
This section lets you configure the output criteria of the file.
Move/Reject File: Specifies whether the file is moved to a directory or is deleted after the probe has processed it.
Destination Directory after Successful Import: Defines the directory where the file is stored after the probe has successfully processed
it.
Keep History and Process File for Days: Defines the number of days for storing the file in the specified directory.
profile name > Alarms
This section lets you configure the alarm properties of the File Adapter probe. Alarms are generated when threshold values are breached.
Enable Alarm if the File is Missing or Rejected: Indicates that alarm is issued if the probe does not find the file in the directory after
trying for a specified number of times.
Default: Selected
Retry File Import: Specifies the number of times the probe searches the file in the directory as per the input criteria.
Before Sending Alarm With Severity: Specifies the alarm severity level.
Send Alarm With Severity: Specifies the message issued with the specified severity when the processing time exceeds the input
value.
Subsystem ID: Defines the subsystem ID issued with alarm messages.
Default: 1.1.5
Reject File if the Number of Valid Samples are below: Specifies the threshold for valid samples in the file. The file is rejected when the
threshold is breached.
profile name > QoS
This section lets you view and configure the QoS properties of the File Adapter probe.
QoS Name: Indicates the QoS name.
Default: Selected
Allow Asynchronous at Start of New File: Indicates that the data in the file is not recorded at regular intervals.
profile name > Script
This section lets you configure the script to check the file.
Command: Defines the command script the probe uses to check the file.
Abort FIle Import When Preprocess Terminates With One of These Return Codes: Defines the return codes for predefined process
script. If these return codes are issued, the file is not processed.
Profiles Node
This node lets you create profiles to collect data and export it to files. The File Adapter probe processes the files for QoS data based on the
criteria that the profile defines. The new profiles are displayed as child nodes.
Note: This node does not contain any sections or fields.
v1.2 file_adapter IM GUI Reference

Open the configuration tool for the probe by double-clicking the line representing the probe in the Infrastructure Manager.
The application window

The window consists of two panes.
The left pane
The left-pane shows the various groups and all agents belonging to a group. Selecting an agent, all variables for that host are listed in the right
pane.
In addition, the QoS definitions are listed here.

Right-clicking in the pane opens a pop-up menu, giving you the following possibilities:
New Profile
Opens the profile properties dialog, enabling you to define a new profile.
New Group
Creates a new group. Give the new group a name of your own choice.
Edit
Available only when a profile is selected.
Opens the properties dialog for the selected profile, enabling you to modify the properties for the selected profile.
Delete
Lets you delete the selected group, profile or QoS definition. Note that you are not allowed to delete the group named Default Group, but
this group will disappear if you remove all profiles from the group.
Deleting a group will also delete profiles belonging to the group. You will be asked to confirm that you really want to delete the group with
its profile definitions.
Rename
Lets you rename the selected group or profile.
New
Available only when the QoS node or a QoS definition is selected.
Opens the QoS properties dialog enabling you to add a new QoS definition.
Note: It is possible to move profiles between groups, using drag-and-drop. Initially the probe comes with a group named Default Group. You are
not allowed to delete this group, but if you delete all profiles in the group, the group will disappear the next time you open the file_adapter GUI.
The right pane
The right-pane is multi-functional and shows:
Profiles when a group is selected in the left-pane.
Files found. When a profile is selected in the left-pane, the window lists files found and processed by the profile.
It can show maximum 500 files. If the number of files processed exceeds 500, the newest 500 files will be shown.
Right-clicking in the pane gives you the possibilities to view the selected file.
The tool buttons
The General Setup button.

The New Group Folder button.
The Add new Agent button.
Set the General Properties

Clicking the General Setup button opens the setup dialog for the probe. This dialog contains a General tab where you set the level of details
written to the log file. Log as little as possible during normal operation to minimize disk consumption, and increase the amount of detail when
debugging.
New Group
If you want to create a new group for your profiles, you can do so by right-clicking in the left pane and selecting New, or you can click the New
group button in the Toolbar. The group will appear as a new node in the left pane, and will by default be named "New Group". Right-click the
group and select Rename to give it a name of your own choice.
Adding a QoS definition

You can add new QoS definitions by right-clicking the QoS node in the left window pane, selecting New, or by selecting <Add New QoS
Definition> from the QoS tab of the profile properties dialog.
QoS
Definitions
tab
The properties for a QoS definition are described below:
Name
The name of the new QoS. In the form QOS_xxx..
Group
The name of the logical group that the new QoS will belong to. In the form QOS_xxx.
Description
A short description of the new QoS.
Unit
The unit of the QoS data (e.g. Milliseconds, Kilobytes).
Unit
abbreviation
An abbreviation of the unit (e.g. MS, KB).
Flag
A flag to be contained in the QoS message:

None:
No flag defined.
Has Max:
The sample value has a defined maximum value. For example disk size, memory usage etc.
A maximum value must be defined in all profiles using this QoS definition.
Is Boolean
The data type is Boolean, where 0 means false (or OFF) and the value 1 (or above) means true (or ON).
QoS Data is
asynchronous
Check this option if the data type is asynchronous (the data in the file is NOT recorded at regular intervals).
Do NOT tick this option if the data type is synchronous. That means that the data in the file is recorded at regular interval as
specified by the Sample Interval parameter on the QoS tab on the profile dialog (sample interval is the expected interval in
seconds between the samples in the data series).
Configure profiles
Clicking the Create A New Profile button opens the Profile dialog.
You can also right-click in the left pane and select New Profile.
The Profile Properties dialog pops up, enabling you to define a new monitoring profile. The dialog contains a field for general parameters and six
tabs:
Input, describing the criteria for the data file to be monitored.
Column, describing the format of the file to be monitored
Output, describing how to handle the file when processed.
Alarms, describing the conditions that will trigger an alarm
QoS, defining the QoS messages to be sent.
Script, allowing you to run a script checking the file before the file is processed by the probe.
Field
Description
Profiles
Here you can create profiles defining the files to be monitored, the QoS messages to be sent on each of the
rows in the file when the file is found, and the Alarms to be sent on error conditions.
The parameters below marked with an asterisk (*) will be contained in the QoS message.
Active
The profile is activated when this option is checked. Note that new profiles by default are activated.
Profile Name
Group
Here you can select in which group to place the profile.
Profile description
Add an optional short description of the profile here.
Frequency
Specifies how often the probe checks the specified file.

Interval:
Checks immediately, and then at the interval specified in the Time field (see below).
If 1 : 00 : 00 is specified in the Time field, the file will be checked every hour.
Daily:
Checks every day at the time specified in the Time field (see below).
If 8 : 00 : 00 is specified in the Time field, the file will be checked at 8 oclock every day.
Weekly:
Checks at the time specified in the Time field (see below) at the days specified in the Day(s) field.
Specify days as weekdays in the range 0-6, where 0=Sunday, 1= Monday etc.
Days can be specified as a range (for example 0-2) and/or comma separated (for example 1,2,5).
If 6 : 00 : 00 is specified in the Time field and 0-2,5 is specified in the Day(s) field, the file will be checked at 6
oclock every Sunday, Monday, Tuesday and Friday.
Monthly:
Checks at the time specified in the Time field (see below) at the days specified in the Day(s) field.
Days are here specified as day of month in the range 1-31.
Specify days as a range (for example 0-5) and/or comma separated (for example 9,14,25).
If 6 : 00 : 00 is specified in the Time field and 1,14 is specified in the Day(s) field, the file will be checked at 6
oclock the 1st and the 14th every month.
Time
The time the probe checks the specified file (see also Frequency above and Day(s) below).
Day(s)
The day(s) the probe checks the specified file at the time specified.
Examples
Clicking the Examples button helps you set the correct format (as an example). Use an example and edit the
specifications in the fields to match your needs.
Input tab
This tab defines the file to be monitored.
Import directory
The directory where the file should be located. The probe supports pattern matching on directories
File name or pattern
The name of the file, for example log.txt or *.log. The formatting codes described in the section can be used.
The probe supports pattern matching on files.
User identification for network

drives
Insert a user name and a password if necessary when a network drive is specified as the import directory.
This field is normally deactivated (greyed out), but will be activated as soon as you type \\x in the Import
directory field.
Skip input line if first char is a

comment symbol
Selecting this option, the probe skips input lines beginning with a comment symbol (e.g. #).
Column tab
This tab defines the format of the file to be monitored.
Datetime format
The format of the date and time specification. Select from the drop-down menu or type your own value (see
the section ).
Datetime in a format as specified here is expected to be found in one of the columns in the file (see Column
definitions below).
Column definitions
This section describes how the columns in the file are expected to be. See also the section .
Datetime:
The column containing the Datetime entry. This column is mandatory unless "current" has been selected as
Datetime format. Then the Datetime field is set to 0.
QoS:
The column containing the QoS. This column is mandatory.
Stdev (Standard deviation):
The column containing the Stdev. This parameter is optional.
Separator:
The separator dividing the rows in the file into two or more columns (e.g. comma, semicolon etc). Select the
character to be used as a separator between the columns in the file.
Select columns (button):
Clicking this button, you will be able to preview the columns and rows of the file monitored by the profile,
provided that a file is present in the specified directory.
Output tab
After a file has been processed, it will be deleted or moved to a specific directory. The destination directory is
specified here.
Move files after processing
If this option is checked, the file will be moved to one of the directories specified below, depending on the
result of the import.
If the option is NOT checked, the file will be automatically deleted.
Destination directory after

successful import
After the probe has processed the file, the file is stored in this directory if the import was successful (the file
contained the expected columns) or another criteria was met (e.g. <x samples).
Destination directory if rejected

during import
After the probe has processed the file, the file is stored in this directory if the import failed (the file did NOT
contain the expected columns).
Keep history and processed

files for days
The files will be kept in the directories specified above for the number of days specified here.
Specifying 90 days means that history (displayed in the main window of the probe GUI) will be kept for 90
days, and that any files older than 90 days will be deleted.
Alarms tab
This tab defines alarm properties for the probe.

An alarm will be issued if the thresholds defined here are exceeded.
Enable alarms if file is missing

or rejected
The probe attempts to find the file specified under the Input tab. If not found at first attempt, the probe tries
again. When the number of attempts exceeds the maximum the number of times specified in the Retry file
import field, an alarm message will be issued.
Retry file import
The maximum number of attempts to find the file before sending an alarm message.
Before sending alarm with

severity
If the file is still not found after the maximum number of attempts, an alarm message with the selected
severity level.
When sample value exceeds
This field lets you select an alarm message with the selected severity to be sent if the input value specified is
exceeded.
Subsystem ID
The Subsystem ID string to be included in the alarm messages. Default is 1.1.5.
Reject file and all QoS data if

any QoS values are invalid
The file will be rejected if at least one of the lines contains QoS columns with invalid format.
Reject file if number of valid

samples is below
Rejects the file if the number of valid samples found in the file is below the specified number.
QoS tab
QoS
The name of the QoS on the form (QoS_xxx) to be sent on each row in a file when the file is found. Using the
pull-down menu lets you select one of the QoS definitions created on the general tab. Otherwise you can type
the name of a QoS of your own choice.
Sample Interval
The expected interval in seconds between the samples in the data series. Note that this field is greyed out if
the selected QoS type is defined to be of asynchronous type.
Maximum Value
Set the maximum sample value. Note that this field will be greyed out unless the selected QoS type is defined
to have a maximum value.
Allow asynchronous at start of

new file
With this option selected, the probe allows the first row of a new file to be asynchronous.
Asynchronous means that data in the file is NOT recorded at regular intervals.
Script tab
Command
Here you can (optionally) insert a command script for checking the file before the file is processed by the
probe.
Abort file import when

preprocess terminates with
one of these return codes
Here you can enter one return code or a list of comma-separated return codes. If the preprocess script
returns with one of these codes, the input file will not be processed.
Datetime format
The New Probe probe uses Datetime format for searching specific files in the directory. The Datetime format is used in one of the columns of the
file.
The following formatting codes are available:
%a: indicates the Abbreviated weekday name.
%A: indicates the Full weekday name.
%b: indicates the Abbreviated month name.
%B: indicates the Full month name.
%d: indicates the Day of the month as the decimal number (01 - 31).
%H: indicates the Hour in 24-hour format (00 - 23).
%I: indicates the Hour in 12-hour format (01 - 12).
%j: indicates the Day of the year as the decimal number (001 - 366).
%m: indicates the Month as the decimal number (01 - 12).

%M: indicates the Minute as the decimal number (00 - 59).
%p: indicates the Current time zone as A.M./P.M. indicator for 12-hour clock.
%S: indicates the Second as the decimal number (00 - 59).
%w: indicates the Weekday as the decimal number (0 - 6; Sunday is 0).
%y: indicates Year without century, as decimal number (00 - 99).
%Y: indicates the Year with century, as decimal number.
%%: indicates the Percent sign.
For Example, "%Y/%m/%d %H:%M:%S" translates to "2005/11/30 15:40:14".
Note: "%I" indicates the hour, and am/pm setting (%p) must be placed after %I in the date format.
Data File Format

The data files to be imported must have a "column-separator". The probe is can distinguish the different sample values to extract from each line of
the file.
The following sample values are available for extraction from each line:
Datetime value (mandatory, Datetime format must be configured).
Quality of Service value (mandatory, must be a numeric value).
Standard Deviation value (optional, must be a numeric value).
file_adapter Metrics
The following table describes the checkpoint metrics that can be configured using the File Adapter (file_adapter) probe.
Monitor Name
Units
Description
Version
QOS_CSV_TEST
qos
CSV File
v1.0
QOS_FILEADAPTER
Value
Fileadapter variable
v1.0
QOS_FTP_RESPONSE
Seconds
FTP Response time to download site
v1.0
QOS_GO_CPU
Percent
Goindstry CPU Apollo
v1.0
QOS_TEST
TS
Test
v1.0
fsmounts (File Systems Mount Monitoring)

The File Systems Mounts Monitoring probe checks which file systems are mounted. The probe raises alarms if there is a mismatch between
currently mounted data and configured data on the system.
More information:
fsmounts (File Systems Mount Monitoring) Release Notes
v1.2 fsmounts AC Configuration

This article describes the configuration concepts and procedures for setting up the fsmounts probe.
This probe allows you to do the following:

View the probe information
Configure the general properties of the probe
Select mount points that the fsmounts probe ignores.
View the file systems that the fsmounts probe discovers.
The following diagram outlines the process to configure the fsmounts probe.
How to monitor file systems

This section describes the minimum configuration settings required to configure the fsmounts probe.
Follow these steps:
1. Open the fsmounts probe configuration interface.
2. Specify the logging and interval details for the probe.
3. Select or enter the mount points in the system to be ignored by the probe.
4. Select or enter the devices of the system to be ignored by the probe.
5. Select or enter the types of file systems to be ignored by the probe.
6. Save the configuration to start monitoring the system.
v1.2 fsmounts AC GUI Reference

This section describes the configuration concepts and procedures for setting up the Filesystem Mounts Monitoring probe.
fsmounts Node
The fsmounts node contains configuration details specific to the Filesystem Mounts Monitoring probe. This node lets you:
Navigation: fsmounts
fsmounts > Probe Information
fsmounts > General Configuration

This section lets you define general parameters, such as check interval and logging properties of the Filesystem Mounts Monitoring probe.
Check Interval (sec): Specifies the Interval at which the probe checks the computer hosting the probe for file systems changes.
Default: 60 seconds
Log Level: Specifies the detail level of the log file.
Default: 0 - Normal
Log Size (KB): Specifies the maximum size of the log file.
Default: 100
fsmounts > Ignore
This section lets you enter or select mount points, devices, and file system types by the Filesystem Mounts Monitoring probe.
Ignore Mount Points Matching: Lets you enter or select the mount points that the probe ignores.
Ignore Devices Matching: Lets you enter or select devices to that the Filesystem Mounts Monitoring probe ignores.
Ignore fstypes Matching: Lets you enter or select the types of file system that the Filesystem Mounts Monitoring probe ignores.
fsmounts > Message
This section lets you view a list of messages available in the Filesystem Mounts Monitoring probe.
Text: Identifies the text of the alarm message.
Level: Identifies the severity level of the alarm.
Subsystem: Identifies the ID of the sub system that is the source of the alarm.
Note: The CA Unified Infrastructure Management Alarm Server probe manages the sub system ID.
fsmounts > Status

This section lets you view the list of file systems the probe discovers. This list also displays the current status for the file systems found.
Mountpt: Identifies the name of the mount point.
Filesys: Identifies the name of the file system.
Fstype: Identifies the file system type.
Required: Indicates that the file system is mounted at boot time.
Allowed: Indicates that the file system can be mounted.
Ignored: Identifies if it is an ignored mount point.
Mounted: Indicates that the file system is mounted.
Alarm: Identifies if the alarm message issued is based on the condition of the file system.
v1.2 fsmounts IM Configuration

This article describes the configuration concepts and procedures for setting up the fsmounts probe.
This probe allows you to do the following:
The following diagram outlines the process to configure the fsmounts probe.
How to monitor File Systems

This section describes the minimum configuration settings required to configure the fsmounts probe.
Follow these steps:
1. Open the fsmounts probe configuration interface.
2. Specify the logging and interval details for the probe in Setup > General tab.
3. Select or enter the mount points, devices, and file system types to be ignored by the probe in the Ignore tab.
4. You can edit the messages that will be sent by the probe in the Messages tab. Refer Editing Messages for more information.
4.
5. Save the configuration to start monitoring the system.
Editing Messages
You can modify alarm messages.
Follow these steps:
1. Right click in Setup > Messages tab and select Edit.
The Alarm Message window is displayed.
2. Specify the message for the corresponding alarm.

You can use variables.
3. Specify the message level and Subsystem ID.
4. Click OK to save the message.
v1.2 fsmounts IM GUI Reference

This article describes the fsmounts probe GUI.
Contents
The Setup Tab

General Tab
Ignore Tab
Messages Tab
Alarm Message Window
The Status Tab
The Setup Tab

The probe is configured by double-clicking the probe in the Infrastructure Manager, which brings up the GUI (configuration tool).
The Setup tab has three tabs listed below:

General tab
Ignore tab
Messages tab
General Tab
Defines the general setup parameters, like check interval and logging properties.
Check Interval
Interval at which the probe checks the computer hosting the probe for file systems changes. The default value is 60 seconds.
Log Level
Sets the level of details written to the probes log file. We recommend logging as little as possible during normal operation, to minimize
disk consumption.
Log size
Sets the size of the probes log file to which probe-internal log messages are written. The default size is 100 KB.
When this size is reached, the contents of the file are cleared.
Ignore Tab
Defines the mount points, devices, and file system types to be ignored by the probe.
Ignore mount points matching
Allows you to type or select mount points to be ignored by the probe.

Regexp may be used in this field.
Mount points, such as / , /etc/mnttab ; /etc/scv/volatile ; /var/run on Solaris 10 Zone can be Ignored by using following regular expression in
the drop-down list (drop-down list allows text to be added).
\/etc\/mnttab$|\/var\/run$|\/etc\/svc\/volatile$|^\/$
OR
^/(etc/mnttab|var/run|etc/svc/volatile)?$
Ignore devices matching
Allows you type or select devices to be ignored by the probe.
Regexp may be used in this field. If you want to ignore devices /dev/pts and /dev/shm then you can use -> \/dev\/pts$|\/dev\/shm$.
For example: /etc/fstab has below entries for Linux rhel system:
/dev/VolGroup00/LogVol00
ext3
defaults
LABEL=/boot
/boot
ext3
defaults
tmpfs
/dev/shm tmpfs
defaults
devpts
/dev/pts
devpts
gid=5,mode=620
sysfs
/sys
sysfs
defaults
proc
/proc
proc
defaults
swap
swap
defaults
Ignore fstypes matching

Allows you to type or select file system types to be ignored by the probe.
Regexp may be used in this field. If you want to ignore filesystems tmpfs and sysfs then you can use -> tmpfs | sysfs
For example: /etc/fstab has below entries for Linux rhel system:
ext3
defaults
LABEL=/boot
/boot
ext3
defaults
tmpfs
/dev/shm tmpfs
defaults
devpts
/dev/pts
devpts
gid=5,mode=620
sysfs
/sys
sysfs
defaults
proc
/proc
proc
defaults
swap
swap
defaults
Messages Tab
Lists out the error messages to be issued at the different error situations that may occur. You can modify the messages as well.
Alarm Message Window
The Alarm message properties dialog enables you to modify a message. Variables may be used.
The fields in the Alarm message dialog box are explained below:
Name
Identification name of the alarm message.
Text
This is the text of the alarm message.
Note: Variables can be used in the message.
Level
The severity of the alarm (clear, information, warning, minor, major or critical).
Subsystem
The ID of the subsystem being the source of this alarm. The subsystem id is managed by the nas.
The Status Tab

This tab lists the file systems found by the probe. The list shows the current status for the file systems found. Right-clicking in the list and then
selecting F5, refreshes the list to display the current status.
The fields in the Status tab are explained below:

Mount point
The name of the mount point.
File system
The name of the file system.
Type
The file system type.
Required
The file system is mounted at boot time and should always be mounted.
Allowed
The file system is listed in the systems setup and can be mounted anytime.
Ignored
Indicates if the file system is ignored, based on the settings on the Setup > Ignore tab.
Mounted
Indicates if the file system is mounted or not.
Alarm
Any alarm message issued based on the condition of the file system.
google_apps (Google Apps)

Google Apps is a set of applications that Google provides and maintains, such as, Google Drive and Google Mail. You can own a Google Apps
domain where you can create many user accounts. A Google Apps domain comprises of a set of end-user accounts, features, applications
available to the end-users, per-user pricing, and resource quotas. Google Apps currently offers three types of domains or editions- free,
educational, and premier.
For more information, refer to http://www.google.com/apps/intl/en/business/index.html
The google_apps probe gathers status information about the general Google applications from http://www.google.com/appsstatus and raises
alarms when any application service is unavailable.
The google_apps probe also monitors the Google Apps domain reports. The probe generates QoS data that describes all the metrics like the daily
performance of the domain-specific services and the operations that are performed on each user account.
Note: Ensure that you have valid credentials of your Google Apps domain account for letting the google_apps probe access the
domain.
Important! The Google Apps Monitoring probe is now available through Admin Console GUI only and not through the Infrastructure
Manager GUI. Upgrade from previous version to version 2.00 is not supported.
More information:
google_apps (Google Apps Monitoring) Release Notes
v2.0 google_apps AC Configuration

This section describes how to configure the Google Apps Monitoring (google_apps) probe.
Contents
Configure a Node
Alarm Thresholds
Add New Profile
Delete Profile
Configure a Node
Each section within the node lets you configure the properties of the probe for connecting to the Google cloud and monitoring various Google
applications.
Follow these steps:
Alarm Thresholds
allow the probe to:
Add New Profile

The following procedure enables you to add a profile for monitoring the Google applications or your Google Apps domain.
Follow these steps:
1. Click Options next to the google_apps node in the navigation pane.
The new monitoring profile is visible under the google_apps node in the navigation pane.
Delete Profile
You can delete a profile if you do not want the probe to collect the Google applications or domain statistics.
Follow these steps:
1. Click the Options icon next to the domain name node that you want to delete.
3. Click Save.
v2.0 google_apps AC GUI Reference

This section describes the configuration GUI details for the Google Apps (google_apps) probe.
Contents
google_apps Node
Google Apps Service Status Node
App Status
<Domain Name> Node
Daily Statistics Node
Contact Operations
Document Operations
Test Mail
google_apps Node
This node lets you view the probe information and configure the log file settings. You can also add a monitoring profile so that the probe can
connect to the Google Cloud and can collect the domain statistics.
Navigation: google_apps
google_apps > Probe Information

google_apps > Probe Setup
This section lets you configure the log file properties of the probe.
Log Level: specifies the severity level of the log file.
Default: 3-info
google_apps > Proxy Settings
This section lets you connect to the Google cloud through a proxy server on the network. You need proxy server settings when your
network is not an open network.
Enable Proxy: lets you use a proxy server for connecting to the Google cloud.
google_apps > Add New Profile
This section lets you add a monitoring profile for your Google Apps domain. QoS data is generated according to the status of the domain
report.
Domain Name: defines a unique name for your domain monitoring profile. This value refers to the same name that you have used to
register your domain with Google Apps.
Domain User Name: defines the user name of your Google Apps domain.
Domain Password: defines the password of your Google Apps domain.
Active: activates the profile for monitoring your domain.
Interval (secs): specifies the time interval (in seconds) after which the probe collects the data from the Google cloud for the specific
profile.
Default: 600
Alarm Message: specifies the alarm message severity level when the probe is not able to fetch the domain data from Google cloud.
Google Apps Service Status Node

This node lets you set the time interval for the probe to fetch the Google Apps status report.
Navigation: google_apps > Google Apps Service Status

Google Apps Service Status > App Monitor
This section lets you set the time interval for the collection of the status of all the Google Apps.
Interval (minutes): specifies the time interval for which the probe waits before collecting the Google Apps status data.
Default: 1 minute
App Status
This node lets you view the status of all the Google Apps. The probe fetches the application statistics and lists them in a tabular form. You can
configure the probe for generating QoS data for any specific application.
The status information is represented through the following codes:
0: App Normal
1: App Information Available
2: App Service Disruption
3: App Service Outage
4: App Status Unknown
Navigation: google_apps > Google Apps Service Status > App Status
App Status > App status
This section consists of a table that lists all the Google Applications. You can select any application and can configure its properties that
are listed below the table.
QoS Name: indicates the name of the Google application.

Publish Data: generates the QoS data for the selected application.
Note: When you select the Publish Data check box, the value of the Data column in the table changes from Off to On.
Refer to the How to Configure Alarm Thresholds topic for configuring the static and dynamic thresholds.
<Domain Name> Node

This node represents the profile which is created for monitoring the Google Apps domain. You can change the field values and can test whether
the probe is able to connect to the Google cloud.
Note: This node is referred to as domain name node in the document and it represents the domain monitoring profile.
Navigation: google_apps > domain name

Refer to the Add New Profile section of the google_apps node for field description. The Test Login option in the Actions drop-down lets you
test whether the probe is able to fetch the data from Google cloud.
Daily Statistics Node

This node lets you view the list of monitors available for monitoring the performance of all the user accounts of the Google Apps domain. You can
let the probe to generate the QoS data for any of the available monitors. The google_apps probe fetches the domain data from the Google cloud
only once a day.s
Navigation: google_apps > domain name > Daily Statistics
Daily Statistics > Monitors
This section lets you configure the Daily Statistics monitors for generating QoS.
Note: The monitors of the Google App domain profile are visible in a tabular form. You can select any one monitor in the table
Contact Operations
This node lets you view the list of monitors available for monitoring the operations that you perform on the contacts of your Google account. You
can let the probe to generate the QoS data for any of the available monitors.
Navigation: google_apps > domain name > Contact Operations
Contact Operations > Monitors
This section lets you configure the monitors of operations that are performed on the contacts of the Google App domain for generating
QoS.
Note: The monitors of the user operations are visible in a tabular form. You can select any one monitor in the table and can
Document Operations
This node lets you view the list of monitors available for monitoring the operations that you perform on the documents of your Google account.
You can let the probe to generate the QoS data for any of the available monitors.
Navigation: google_apps > domain name > Document Operations
Document Operations > Monitors
This section lets you configure the monitors of operations that are performed on the documents of the Google App domain for generating
QoS.
Note: The monitors of the user operations are visible in a tabular form. You can select any one monitor in the table and can
Test Mail
This node lets you configure the probe to monitor the time it takes for the probe to send an email using the Google SMTP server.
Navigation: google_apps > domain name > Test Mail
Test Mail > Mail Configuration
This section lets you configure the email settings for sending a test email over the SMTP server.
Active: activates the mail configurations of the probe.
SMTP Host: defines the domain name or an IP address of a Google SMTP server.
SMTP Port: defines the SMTP port number which used when the probe sends an email through SSL.
Mail Recipient: defines any valid email address to which the probe can send a test email.
Mail Subject: defines the subject of the test email that the probe sends to the specified email recipient.
Note: The Test Email option in the Actions drop-down sends the configured test email.
Test Mail > Monitors

This section lets you configure the Test Email monitors for generating QoS.
Note: The monitors of the Google App domain profile are visible in a tabular form. You can select any one monitor in the table
google_apps Metrics
The following table describes the metrics that can be configured using the Google Apps (google_apps) probe.
QoS Metrics
Monitor Name
Metric Name
Units
Description
Version
QOS_GOOGLE_APPS_APP_STATUS
App Status
Status
Monitors the status of the general

Google Applications.
2.0
QOS_GOOGLE_APPS_DOMAIN_AVG_STORAGE_BYTES_PER_ACCOUNT
Average Bytes
Per Account
Bytes
Monitors the number of bytes that

one user account of a Google
App domain uses.
2.0
QOS_GOOGLE_APPS_ACTIVE_ACCOUNTS
Number of
Active
Accounts
Count
Monitors the number of active

user accounts of a Google App
domain.
2.0
QOS_GOOGLE_APPS_ACTIVE_ACCOUNTS_ON_GIVEN_DAY
Number of
Active
Accounts on a
given day
Count
Monitors the number of active

user accounts of a Google App
domain on a specific day.
2.0
QOS_GOOGLE_APPS_EMAIL_ACCOUNTS_ACCESSED
Number of
Accounts
Accessed on a
day
Count
Monitors the number of user

accounts of a Google App
domain that have been accessed
in one day.
2.0
QOS_GOOGLE_APPS_EMAIL_ACCOUNTS_ACCESSED_VIA_POP
Number of
Accounts
Accessed on a
day using POP
Count

in one day using Post Office
Protocol (POP).
2.0
QOS_GOOGLE_APPS_EMAIL_ACCOUNTS_ACCESSED_VIA_WEB
Number of
Accounts
Accessed on a
day using web
Count

in one day using the web.
2.0
QOS_GOOGLE_APPS_IDLE_ACCOUNTS_OVER_30DAYS
Number of Idle
Accounts
Count
Monitors the number of idle user

in one day.
2.0
QOS_GOOGLE_APPS_LARGE_MAIL_BOXES
Number of
Large
Mailboxes
Count
Returns the number of mail

boxes that have a size greater
than 5 GB.
2.0
QOS_GOOGLE_APPS_MEDIUM_MAIL_BOXES
Number of
Medium
Mailboxes
Count

boxes that have a size between 1
GB and 5 GB.
2.0
QOS_GOOGLE_APPS_SMALL_MAIL_BOXES
Number of
Small
Mailboxes
Count

boxes that have a size between 0
GB and 1 GB.
2.0
QOS_GOOGLE_APPS_USED_STORAGE_BYTES
Total Bytes
Used
Bytes
Monitors the total number of

bytes used by a Google App
domain.
2.0
QOS_GOOGLE_APPS_USED_STORAGE_PERCENT_QUOTA
Quota Used
Percent
Monitors the percentage of

storage quota used by a Google
App domain.
2.0
QOS_GOOGLE_APPS_CONTACT_CREATE_LATENCY
Contact Create
Latency
Milliseconds
Monitors the time used in

creating a contact in a user
account of a Google App domain.
2.0
QOS_GOOGLE_APPS_CONTACT_DELETE_LATENCY
Contact Delete
Latency
Milliseconds

deleting a contact in a user
2.0
QOS_GOOGLE_APPS_CONTACT_FIND_LATENCY
Contact Find
Latency
Milliseconds
Monitors the time used in finding

a contact in a user account of a
Google App domain.
2.0
QOS_GOOGLE_APPS_DOCUMENT_CREATE_LATENCY
Document
Create Latency
Milliseconds

creating a document in a user
2.0
QOS_GOOGLE_APPS_DOCUMENT_DELETE_LATENCY
Document
Delete Latency
Milliseconds

deleting a document in a user
2.0
QOS_GOOGLE_APPS_DOCUMENT_UPDATE_LATENCY
Document
Update Latency
Milliseconds

updating a document in a user
2.0
QOS_GOOGLE_APPS_MAIL_SEND_LATENCY
Message Send
Latency
Milliseconds
Monitors the time used to send

an email using the Google SMTP
server.
2.0
ha (High Availability)
Continual operation of your UIM monitoring infrastructure requires minimal downtime for the primary hub. One way to achieve this is to install UIM
Server on a Microsoft cluster, which provides a true high-availability solution. Another solution is to configure a secondary hub to take over if the
primary hub goes down. This solution, which is based on the High Availability (HA) probe, ensures the essential functions of the primary hub
continue. One limitation, however, is that UMP is unavailable during failover.
HA Capabilities
The primary hub performs the following essential functions:
Routes all QoS data to the database through the use of the data_engine probe.
Sends alarm messages via the NAS probe.
Hosts the Admin Console web application, made available through the service_host probe and admin_console package.
Enables UMPs dashboard_engine to locate key UIM components, such as data_engine and NAS.
Routes discovery data to the database through the use of the discovery_server and nis_server
During failover, all functions of the primary hub can be temporarily assumed by an HA hub, EXCEPT for communication with UMP, which initiates
communication with the primary hub. In most deployments, this limitation is acceptable because:
Restoring the primary hub is a top priority, and access to UMP is not needed for this task.
The QoS message flow to the database and alarm notification via email continue without interruption.
If Admin Console is configured on the HA hub and Infrastructure Manager is installed on another system, administrators can continue to
manage the UIM infrastructure during failover.
The best way to ensure that UMP can always access the data is to install UIM Server on a Microsoft cluster. If the clusters active node fails, the
secondary node takes over and primary hub functionality continues with very limited interruption. Data flow, alarms, component management, and
data viewing all continue as normal. For more information, see the article Installing in an Active/Passive Microsoft Cluster on the CA UIM
Documentation Space.
Data Flow during Normal Operation

The following diagram illustrates the data flow during normal operation:
In this configuration:
The HA probe monitors the primary hubs state (active or non-active) from the HA hub.
Secondary hubs and robots that have the primary hub as their parent send data to the primary hub.
Tunnels and queues are configured from the remote secondary hub to the primary hub and to the HA hub. The queue to the secondary
hub (shown with a dashed line) is inactive.
On the primary hub:
The data_engine probe sends QoS data to the database.
The NAS probe has auto-operator and nis_bridge enabled, allowing the probe to email alarm notifications and send alarm data to the
database.
Remote monitoring probes (such as RSP) collect data.
The data_engine on the primary hub provides a database connection string to UMP components, which allows UMP to connect to the
database.
Admin Console is hosted on the primary hub. On Windows systems, Infrastructure Manager is also installed on the primary hub.
Data Flow during Failover

The following diagram illustrates the data flow during failover:
In this configuration:
The HA probe lost contact with the primary hub and initiated a failover. The probe will initiate a failback when contact with the primary hub
is reestablished.
All connections to the primary hub are unavailable. Any remote monitoring done from the primary hub (such as through the RSP probe)
ceases.
On the HA secondary hub, the HA probe activates:
The data_engine probe, which now sends QoS data to the database.
Queues for remote hubs.
The NAS probe. If the HA probes NAS AO option is enabled, the auto-operator allows the secondary NAS to email notifications when
thresholds are met. However, the messages are not stored in the database. They are stored locally with the secondary NAS.
The service_host probe, which runs the Admin Console web app.
Remote monitoring probes (such as RSP). This ensures that the secondary hub can continue the remote monitoring that was being
done by the primary hub.
Robots that were managed by the primary hub and local secondary hubs now send data to the HA hub.
The UMP server cannot send requests to the HA hub, and thus receives no data.
The database does NOT have current alarm information. The information is stored locally stored by the secondary NAS, which will send
the replicated information to the primary NAS when failback occurs.
The database does NOT have current alarm information because the nis-bridge on the secondary NAS is disabled. The information is not
lost; it is stored locally stored by the secondary NAS, which will send the replicated information to the primary NAS when failback occurs.
Admin Console is available if service_host and admin_console are deployed on the HA hub. It can be accessed at http://<HA_hub_IP_a
ddress>:<adminconsole_port>/adminconsole.
More information:
ha (High Availability) Release Notes
v1.4 ha AC Configuration
The Admin Console ha configuration GUI lets you configure the ha probe to provide high availability for the primary hub. This article covers the
following topics:
Change the Heartbeat Interval
Change the Failover and Failback Wait Times

Configure Probes and Queues on the Secondary Hub
Enable Probes on the Secondary Hub
Disable Probes on the Secondary Hub
Enable Queues on the Secondary Hub
Disable Queues on the Secondary Hub
Change the Probe and Queue Enablement/Disablement Order
Set nas Auto-Operator on Failover
Change the Logging Parameters
High-Availability Configuration Scenarios
Simple Setup for Probe Enablement on Failover
Secondary nas with Replication
To open the ha configuration GUI:
1. In the Admin Console navigation tree, click the down arrow next to the hub, then the robot the ha probe resides on.
2. Click the down arrow next to the HA probe, select Configure.
Change the Heartbeat Interval

The ha probe sends heartbeat requests to the primary hub. If the ha probe does not receive a response in a user-designated length of time, the
secondary hub takes over.
The default heartbeat interval is 10 seconds, which is suitable for most environments. If you are running on a network with slow response times,
you can increase the heartbeat interval.
Follow these Steps:
1. In the ha probe configuration menu, click the Advanced folder.
2. Change the Heartbeat Check Interval field to desired interval in seconds.
Change the Failover and Failback Wait Times

The failover wait time determines how long the ha probe waits for a response from the primary hub before it instructs the secondary hub to take
over. The failback wait time determines how long the ha probe waits after communication with the primary hub has been reestablished before it
begins failback. This allows time for all probes, tunnels, and queues that are configured on the primary hub to be ready.
The default wait time for failover and failback is 30 seconds, which is suitable for most environments. If you are running on a network with slow
response times, you can increase the wait times.
Follow these Steps:
2. Change the Failover Wait Time field to the desired interval in seconds.
3. Change the Failback Wait Time field to the desired interval in seconds.
Configure Probes and Queues on the Secondary Hub

You can select which probes and queues are activated or deactivated on the secondary hub after primary hub failover.
Important! You cannot change the order that probes or queues are enabled/disabled on the secondary hub in the ha probe Admin
Console GUI. If a specific order is required on failover, it must be configured using the Raw Configuration menu. For more information,
see Change the Probe and Queue Enablement/Disablement.
Enable Probes on the Secondary Hub
You can select the probes that will be activated on the secondary hub after failover. Any probes that are activated on the secondary hub must be
configured on the system hosting the ha and the secondary hub.
Follow these steps:
1. Click the Probes to Enable folder.
2. Select the Probe that you want to enable from the Probe Name drop-down list.
3. Click the Actions button, select Add Probe.
Disable Probes on the Secondary Hub

You can set probes on the secondary hub to deactivate at failover. Any probes that are activated on the secondary hub must be configured on the
system hosting the ha and the secondary hub.
Follow these steps:
1. Click the Probes to Disable folder.
2. Select the Probe that you want to disable from the Probe Name drop-down list.
3. Click the Actions button, select Add Probe.
Enable Queues on the Secondary Hub

You can select the queues that will be activated on the secondary hub after failover. The queues that are activated on the secondary hub must
exist on the system hosting the ha and the secondary hub.
Follow these steps:
1. Click the Queues to Enable folder.
2. Select the queue that you want to enable from the Queue Name drop-down list.
3. Click the Actions button, select Add Queue.
Disable Queues on the Secondary Hub

You can select the queues that will be deactivated on the secondary hub after failover. The queues that are deactivated on the secondary hub
must exist on the system hosting the ha and the secondary hub.
Follow these steps:
1. Click the Queues to Disable folder.
2. Select the queue that you want to disable from the Queue Name drop-down list.
3. Click the Actions button, select Add Queue.
Change the Probe and Queue Enablement/Disablement Order

If your configuration requires a specific enablement/disablement order, use the Raw Configuration menu to ensure that the order is correct. You
cannot set the order using the ha probe GUI.
Follow these steps:
1. In the Admin Console menu, click the down arrow next to the ha probe, select Raw Configure.
The Raw Configuration menu for the ha probe appears.
2. Click the probes_up folder.
A list of keys and values appears.
3. Verify that the probes are listed in the correct order in the Raw Configure window. If the probes are out of order, you will have to edit the
keys.
4. Click the probe value that needs changed and enter the correct probe name.
5. Click Apply.
The key list is updated.
6. Continue updating keys until the probes are listed in the correct order.
7. If necessary, repeat steps 1 through 6 for the following folders in the Raw Configuration menu:
7.
probes_down folder- Contains the probes to disable on the secondary hub.
queues_up folder- Contains the queues to enable on the secondary hub.
queues_down folder- Contains the queues to disable on the secondary hub.
Example: Change the order that the data_engine and service host probes activate on failover
This example switches the service host and data_engine probe deployment order. The data_engine probe should be deployed before the service
host probe to avoid logging invalid errors. If the probes appear out of order in the Raw Configure menu:
You will have to edit the value keys.

Follow these steps:
1. Click the service_host key value for probe_0, enter data_engine.
2. Click the data_engine key value for probe_1, enter service_host.
3. Click Apply.
The probes will now deploy in the correct order.
Set nas Auto-Operator on Failover

The Auto-Operator (AO) feature is meant to aid the administrator in managing the alarm database. You can define various profiles, based on
matching rules (such as severity level, alarm message text, subsystem ID) to:
Close/acknowledge certain alarms.
Automatically assign an alarm to a person/group.
Send an e-mail or a GSM/SMS message whenever a specific rule is met.
By default, Auto-Operator is enabled on the nas probe running on the secondary hub on failover. This means that the auto-operator setting in the
nas configuration is modified and the nas probe is restarted on the secondary hub. If you do not want the nas probe to restart, clear this option.
Follow these Steps:
2. Click the Reset NAS auto-operator on failover checkbox.
Change the Logging Parameters

You can change both the level of detail that is written to the log file, and the total log size.
Follow these steps:
1. In the Probe Configuration menu, click ha.
2. Click the Log level drop-down list, and select the new level of logging detail.
3. Click the Log size field and enter the new log size in KB. You can also use the up and down arrows to the right of the field to increase or
decrease the value.
4. Click the Save Button.
4.
The new log values are saved.
High-Availability Configuration Scenarios

The ha probe can be configured in a various number of ways. The follow scenarios are typical configurations:
Secondary NAS with Replication
Important: Always configure the data_engine so that it is off on the secondary hub prior to faillover.

You can use the ha probe to enable probes and queues and provide a data_engine for those probes on the secondary hub. Some examples of
probes to deploy are:
nas for alarm access and processing
distsrv for access to the archive
emailgtw for the ability to email alarms
sla_engine for the ability to continue calculating your SLAs
Note: Secondary hub queues configured as get queues require creation of a substitute queue to attach to a target address in place of a queue on
the primary hub. For more information, see the hub configuration guide.
Example Procedure for Setting up Probe Enablement on Failover
Follow these steps:
1. Enable the nas probe as a local probe.
2. Deploy and configure the probes and queues on the secondary hub.
3. Disable replication on the nas probe.
4. Optionally, disable the NIS-bridge on the nas probe.
Note: If the NIS-bridge is enabled, the nas log contains database constraint violation errors. These errors do not cause
database issues, but result in error messages until the secondary nas can successfully import data into the NIS database.

In order to keep alarms, event messages and count identifiers in-sync, most customers enable and configure NAS replication.
In situations where the nas probe must continue to collect information after a failover, you can configure a high-availability configuration where the
nas probe is activated on the secondary hub and stores data locally until failback. After the primary hub comes back online, the primary nas sends
the replicated information to the NIS database.
Example Procedure for Setting up NAS replication
Follow these steps:
1. Deploy a nas probe on the secondary hub.
Important! Do not include the nas probe and associated queues in the HA probe configuration for probes and queues to
enable. The secondary nas is always on.
2. Enable replication on the nas probe on the primary and secondary hubs.
3. Enable Auto-operator on the primary nas.
4. Enable NIS-bridge on the primary nas.
The secondary nas communicates with the primary nas and its information is synchronized with the primary through the replication
4.
mechanism. The primary nas sends the information to the NIS database.
v1.4 ha AC GUI Reference

This section describes the configuration information and options available through the Admin Console configuration GUI. The navigation pane
organizes ha configuration into the following nodes:
HA
Advanced
Probes to Disable
Probes to Enable
Queues to Disable
Queues to Enable
To access the ha configuration interface, select the hub robot in the Admin Console navigation pane. In the Probes list, click the arrow to the left
of the ha probe and select Configure.
HA
Navigation: HA
This section lets you view probe information and change the general configuration options.
Probe Information
This section displays the probe name, start time, version, and vendor.
This section lets you modify the log file settings and change the Primary Hub Address.
Log level
The level of detail that is written to the log.
Log size (KB)
The maximum size of the log file before it rolls over.
Primary Hub Address
The address of the monitored primary hub.
Alarm Messages
This section displays the following read-only information about each message received by the HA probe.
Message ID
The identification name of the alarm message.
Message Text
The text of the alarm message. Variables are used in the message.
Severity
The severity of the alarm (clear, information, warning, minor, major, or critical).
Message Token
The token value of the message.
Subsystem
The ID of the subsystem where the alarms originated. The value is always 1.2.3.8.
il8n Token
The token value for internationalization.
Advanced
Navigation: HA > Advanced

This section allows you set heartbeat intervals and wait times for the primary hub in case of failover.
Heartbeat Check Interval (in secs)

The interval at which the HA probe checks that the primary hub is available and operative.
Default: 10 seconds
Failover Wait Time (in secs)
How long the HA probe waits for a response from the primary hub before switching to the secondary hub.
Default: 30 seconds
Failback Wait Time (in secs)
How long the HA probe waits after communication with the primary hub has been reestablished before it begins failback. Failback wait
time allows time for all probes, tunnels, and queues that are configured on the primary hub to be ready for failback.
Default: 30 seconds
Reset nas auto-operator on failover
Enables Auto-Operator on the nas probe running on secondary hub on failover. If selected, the auto-operator setting in the nas
configuration is modified and the nas probe is restarted.
Default: Enabled
Probes to Disable
Navigation: ha>Probes to Disable

This section lets you add probes to the Probes to Disable table. Probes that are listed in the table will be deactivated on the secondary hub after
failover.
Actions Button
Add or removes probes from the Probes to Disable Table.
Probes to Disable Table
Lists the probes that will be disabled on the secondary hub after failover.
Probes to Enable
Navigation: ha > Probes to Enable

This section lets you add probes to the Probes to Enable table. Probes that are listed in the table are activated on the secondary hub at failover.
Actions Button
Add or remove probes from the Probes to Enable Table.
Probes to Enable Table
Lists the probes that will be enabled on the secondary hub after failover.
Queues to Disable
Navigation: ha > Queues to Disable

This section lets you add queues to the Queues to Disable table. Queues that are listed in the table are deactivated on the secondary hub at
failover.
Actions Button
Add or remove queues from the Queues to Disable Table.
Probes to Queues Table
Lists the queues that will be disabled on the secondary hub after failover.
Queues to Enable
Navigation: ha > Queues to Enable

This section lets you add queues to the Queues to Enable table. Queues that are listed in the table are activated on the secondary hub at failover.
Actions Button
Add or remove probes from the Queues to Enable Table.
Queues to Enable Table
Lists the queues that will be enabled on the secondary hub after failover.
v1.4 ha IM Configuration
Contents
The GUI
The Setup tab
The Configure tab
The Options tab
The Messages tab
The Status tab
The GUI
The ha probe is configured by double-clicking the probe in Infrastructure Manager, which brings up the GUI (configuration tool).
The GUI consists of five tabs:

Setup
Defines the general properties for the probe.
Configure
Defines the name of the primary hub, and the probes and queues to enable/disable on the primary Hub at failover.
Options
Defines probe properties, such as polling interval and the wait time (without response from the primary hub) before the ha probe instructs
the secondary hub to take over.
Messages
Defines the alarm messages that will be issued at the different error situations that may occur. These messages may be modified.
Status
Displays the status of the failover configuration.
The Setup tab

The Setup tab defines the general properties for the ha probe.
Log level
Select the level of detail to be written to the probes log file. We recommend logging as little as possible during normal operation to
minimize disk consumption.
Log size
Enter the size of the probes log file where probe-internal log messages are written. The default size is 100 KB.
When this size is reached, the contents of the file are saved to a log backup file, the log file is cleared and new log entries are added to
the log file. The backup file is overwritten each time the log file reaches the maximum size.
The Configure tab

The Configure tab defines the name of the primary hub, and the probes and queues to enable/disable on the secondary hub at failover.
This screen is separated into five sections:
Primary hub
The ha probe uses a secondary Hub to monitor the primary hub. If the primary hub becomes unavailable, the secondary hub will
automatically take over.
The drop-down menu lets you select the name of the primary hub (the hub to be monitored).
Queues to enable
Select the queues to be enabled at failover. These queues must exist on the computer hosting the ha probe and the secondary hub.
Queues to disable
Select the queues to be disabled at failover. These queues must exist on the computer hosting the ha probe and the secondary hub.
Probes to enable
Select the probes to be enabled (activated) at failover. These probes must be configured on the computer hosting the ha probe and the
secondary hub.
Note: You should verify the probes are properly configured and activate successfully prior to failover. If the probes are not
properly configured they may not start when failover occurs.
Probes to disable
Select the probes to be disabled (deactivated) at failover. These probes must be configured on the computer hosting the ha probe and
the secondary hub.
The Options tab

The Options tab defines probe properties, such as polling interval and the wait time (without response from the primary hub) before the ha probe
instructs the secondary hub to take over.
Heartbeat interval
The interval at which the ha probe checks that the primary hub is available and operative. The default value is 10 seconds.
Failover Wait time
How long the ha probe waits for a response from the primary hub before it instructs the secondary hub to take over. The default wait time
is 30 seconds.
Failback Wait time
How long the ha probe waits after communication with the primary hub has been re-established before it begins failback, allowing time for
all probes, tunnels, and queues configured on the primary hub to be ready. The default wait time is 30 seconds.
Reset nas Auto Operator on failover
Select this option to enable Auto-Operator on the nas probe running on secondary hub on failover. If selected, the auto-operator setting in
the nas configuration is modified and the nas probe is restarted.
The Messages tab
The Messages tab displays the alarm messages that will be issued for the different error situations that occur.
These messages may be modified by right-clicking the message in the list and select Edit. The Alarm message properties dialog will pop up,
enabling you to modify the message. Variables may be used.
Name
The identification name of the alarm message.
Text
The text of the alarm message. Variables can be used in the message.
Level
The severity of the alarm (clear, information, warning, minor, major or critical).
Subsystem
The ID of the subsystem where the alarm originated. The subsystem ID is managed by the nas. This should be '1.2.3.8' for all messages
from this probe.
The Status tab

The Status tab displays the status of the failover configuration.
Green indicator
This means the ha probe is running and successfully connected (communicating) with the primary hub. The ha probe is not in failover
state.
Red indicator
This means the ha probe is in failover state because the connection to the primary hub has been lost.
Black indicator
This means that the ha probe is not running. In this state, should the primary hub go down the ha probe would not know about it and
therefore would not enable/disable probes and queues on the secondary hub accordingly.
ha Troubleshooting
Unable to read configuration...
Symptom:
I see Error: Unable to read configuration when I try to open the hub configuration GUI. I receive the error code MONS-021.
Solution:
Do the following:
Deploy the PPM probe to the hub. The PPM probe is required for GUI operation.
Viewing the Log File...
Advanced users may find it helpful to view the log file. Click the icon next to the hub probe and select
log file settings so that it retains more data for troubleshooting.
View Log. You also can modify the
ha Scenarios
The ha probe can be configured in a various number of ways. This article describes several different configuration scenarios.
Contents
Common Configuration
Important: The secondary data_engine cannot perform maintenance operations, which are relegated to the primary data_engine.
Always configure the data_engine so that it is off on the secondary hub prior to faillover.
Common Configuration
A common configuration is for the nas probe on both the primary hub and secondary hub (hub where the ha probe is running) to be running with
replication enabled. In this type of configuration, the primary nas would have both auto-operator and nis-bridge enabled. When the primary hub
goes down and failover is initiated, then the auto-operator is enabled on secondary nas probe based upon whether the 'NAS AO' checkbox is
enabled in the 'Options' tab of the ha probe configuration. Enabling auto-operator allows the secondary nas to send notifications when thresholds
are met, but because the nis-bridge on the secondary nas remains disabled the information is not stored in the NIS database. The information will
be stored locally with the secondary nas.
After the primary hub (and thus the primary nas) comes back online the information will be synchronized with the primary nas and will then be
stored in the NIS database by the primary nas probe. Additionally, after the primary hub comes back online, auto-operator on the secondary nas
will be automatically disabled if it had been enabled during failover.
During the time the primary hub is down, the NIS database will be out of date from the current alarm information. The information is not lost, it is
just being locally stored by the secondary nas until the primary hub comes back online and the primary nas can then send the replicated
information to the NIS database.

You can use the ha probe to enable probes and queues and provide a data_engine for those probes on the secondary hub. Some examples of
probes to deploy are:
nas for alarm access and processing
distsrv for access to the archive
emailgtw for the ability to email alarms
sla_engine for the ability to continue calculating your SLAs
Note: Secondary hub queues configured as get queues require creation of a substitute queue to attach to a target address in place of a queue on
the primary hub. For more information, see the hub configuration guide.
Example Procedure for Setting up Probe Enablement on Failover
Follow these steps:
1. Enable the nas probe as a local probe.
2. Deploy and configure the probes and queues on the secondary hub.
3. Disable replication on the nas probe.
4. Optionally, disable the NIS-bridge on the nas probe.
Note: If the NIS-bridge is enabled, the nas log contains database constraint violation errors. These errors do not cause
database issues, but result in error messages until the secondary NAS can successfully import data into the NIS database.
In order to keep alarms, event messages and count identifiers in-sync, most customers enable and configure nas replication.
In situations where the nas probe must continue to collect information after a failover, you can configure a high-availability configuration where the
nas probe is activated on the secondary hub and stores data locally until failback. After the primary hub comes back online, the primary nas sends
the replicated information to the NIS database.
Example Procedure for Setting up nas replication
Follow these steps:
1. Deploy a nas probe on the secondary hub.
Important! Do not include the nas probe and associated queues in the HA probe configuration for probes and queues to
enable. The secondary nas is always on.
2. Enable replication on the nas probe on the primary and secondary hubs.
3. Enable Auto-operator on the primary nas.
4. Enable NIS-bridge on the primary nas.
The secondary nas communicates with the primary nas and its information is synchronized with the primary through the replication
mechanism. The primary nas sends the information to the NIS database.
hadoop_monitor (Hadoop Monitoring)

Hadoop is a software framework that facilitates distributed processing of large data sets. The Hadoop Monitoring probe handles all the common
monitoring and data collection tasks (collecting QoS measurements and topology information) on a Hadoop cluster through a namenode, and
gathers reports about all nodes in the cluster. The probe collects and stores data and information from the monitored system at customizable
intervals. The probe generates alarms when the specified thresholds are breached.
More information:
hadoop_monitor (Hadoop Monitoring) Release Notes
hadoop_monitor AC Configuration
Contents
Configuring Probe Setup
Configuring Monitoring
Alarm Thresholds
At a high level, configuring the probe consists of the following actions:
1. Configuring the probe setup.
2. Adding monitors to the appropriate system components and configuring monitor data, to include alarm thresholds.
Configuring Probe Setup
After you install the probe, you must complete the Probe Setup configuration settings. If these settings are incomplete, the probe will not publish
the Hadoop network topology. You only need to configure the settings on the probe that is running the Hadoop NameNode process. In a Hadoop
HA Cluster environment, the NameNode process must be active. See hadoop_monitor AC GUI Reference for information about configuring the
probe setup using the probe GUI.
Configuring Monitoring
You can add and configure monitors to the components and processes shown in the navigation pane. Click a node in the navigation pane to see
any associated monitors for that component. You can configure the QoS measurements you want to collect data for, and any alarms or events
you want by modifying the appropriate fields.
Add/Configure a Monitor
Follow these steps:
1. Go to hadoop_monitor > profile name > resource name in the navigation pane.
2. Click on a component name. The available monitors appear in a table on the right side of the screen. It might be necessary to expand the
node in the navigation pane to view the monitors and Qos metrics.
3. Select the monitor you want to modify in the table.
4. Configure the monitor settings in the fields below the table.
5. Click Save at the top of the screen.
When the new configuration is loaded, a Success dialog appears.
6. Click OK.
The navigation pane is updated with the new configuration.

Alarm Thresholds
allow the probe to:
Important! Alarm threshold settings are dependent on the baseline_engine probe. If you do not have the correct version of
baseline_engine configured, you will not see the additional threshold options.
hadoop_monitor AC GUI Reference

Contents

hadoop_monitor Node
No BDIM Integration
BDIM Integration in place
Profile Node
Hostname Node
Cluster Node
System Node
The basic Hadoop Monitoring probe GUI is divided into two panes. The left navigation pane contains a hierarchical representation of the probe
inventory which can include monitoring targets and configurable elements. The right details pane contains information based on your selection in
the navigation pane.
For more information about the basic Hadoop Monitoring GUI properties, see Admin Console Probe GUI.

The components of the Hadoop system on which the Hadoop Monitoring probe is installed are displayed in the navigation pane. Click a node in
the navigation pane to see the alarms, events, or monitors available for component.
hadoop_monitor Node
After installing the probe, you must configure the probe setup. Setup must be configured only on the probe which is running the Hadoop
NameNode process. For a Hadoop HA Cluster, you must configure the probe on the currently Active NameNode process. If this step is not
performed, the probe will not publish the network.
Navigation: hadoop_monitor probe
hadoop_monitor > Probe Information
hadoop_monitor > Probe Setup
Probe setup may differ based upon whether or not BDIM Integration is in place.
No BDIM Integration
For this setup, the only required field is the Cluster name. This cluster name must match the cluster name configured in your Cloudera or
Hortonworks systems. If you are an Apache Hadoop customer, you may set the cluster name to any value.
Fields to know:
Log Level
(Optional) Specifies the amount of log information you would like to collect for this probe.
Default: 3 - Info (Recommended)
Cluster name
Specifies the name of the Hadoop cluster you wish to monitor.
(Optional) Specifies whether to collect system metrics.
HDFS poll interval in seconds
(Optional) Specifies how often to poll the Hadoop Distributed File System (HDFS) for data.
BDIM Integration in place
If BDIM Integration is in place, the only required fields are the BDIM Account ID, and option to Publish Messages to BDIM.
Fields to know:
Log Level
(Optional) Specifies the amount of log information you would like to collect for this probe.
Default: 3 - Info (Recommended)
BDIM Account ID
Specifies the account ID used to access BDIM.
Cluster name
(Optional) Specifies the name of the Hadoop cluster you wish to monitor.
(Optional) Specifies whether to collect system metrics.
Publish Messages to BDIM
Specifies whether to publish alarm messages to BDIM.
HDFS poll interval in seconds
(Optional) Specifies how often to poll the Hadoop Distributed File System (HDFS) for data.
Profile Node
The Hadoop Monitoring probe includes a local resource profile. You can modify or some settings for this resource profile and verify the resource
information.
Navigation: hadoop_monitor > profile name
profile name > Actions > Verify Information
Use this option to validate the resource profile information
Fields to know:
Identifier
The identifier for the local resource profile
Active
Interval (secs)
Alarm Message
Hostname Node
The hostname node is a container for the probe inventory that can be configured for monitoring. This typically will include the cluster node and
the system node. Because this node is only a container, no configuration information is displayed in the details pane for this node.
Navigation: hadoop_monitor > profile > hostname
Cluster Node
The cluster node contains all of the Hadoop system services that are discovered by the Hadoop Monitoring probe when the probe configuration is
setup. The services that are discovered may vary depending upon the configuration of your Hadoop system. The Hadoop Monitoring probe is
capable of discovering the following services:
HDFS
Hadoop Distributed File Ssytem
Roles - an empty node used to organize the following HDFS services:
namenode
keeps the directory tree of all files in the file system, and tracks where data is stored within the file system.
datanode
stores data in the HDFS.
secondarynamenode
performs periodic checkpoints of the namespace and helps minimize the size of the log containing changes to the HDFS stored at the
namenode.
YARN
Resource management platform responsible for managing cluster resources and using them to schedule applications.
Container
provides processing capacity for YARN resources.
Roles - an empty node used to organize the following YARN services:
resourcemanager
manages applications and schedules resources for the applications.
nodemanager
monitors container resource usage.
apphistoryserver
stores and retrieves historic information for applications.
MAPREDUCE
Distributes work around the cluster
Roles - an empty node used to organize the following MAPREDUCE services:
jobhistoryserver
stores and retrieves historic information about jobs executed by MAPREDUCE.
HBase
Hadoop storage manager.
Roles - an empty node used to organize the following HBase services:
hbasemaster
coordinates the HBase cluster and is responsible for administrative operations.
regionserver
responsible for handling a subset of an HBase table's data.
thrift
cross platform development framework and API used by HBase.
REST
REST server bundled with HBase.
OOZIE
Workflow scheduler system to manage Hadoop jobs
HIVE
Data warehouse that facilitates querying and managing large datasets residing in distributed storage.
Roles - an empty node used to organize the following HIVE services:
hiveserver2
server interface that enables remote clients to execute queries against Hive and retrieve the results.
metastore
stores the metadata for Hive tables and partitions and provides clients access to the data.
Navigation: hadoop_monitor > profile > hostname > cluster
Click the cluster node to add/configure monitors to the cluster. To add/configure monitors for services on the cluster, expand the cluster node,
and navigate through the hierarchy as needed. Select each node you wish to monitor. In the details pane, select the monitors you wish to
configure and add to that node, and modify settings as appropriate.
Fields to know:
QoS Name
Description
Units
Metric Type Id
Publish Data
Publish Alarms
Value Definition
Current Value -- The most current value measured will be used.
Delta Value (Current - Previous) -- The delta value calculated from the current and the previous measured sample will be used.
Delta Per Second -- The delta value calculated from the samples measured within a second will be used.
Number of Samples
Operator
The operator to be used when setting the high or low alarm threshold for the measured value. You must select Publish Alarms to enable
this setting.
Example:
Threshold
The high or low alarm threshold value. An alarm message will be sent if this threshold is exceeded.
Message Name
Configure dynamic alarm thresholds following the instructions found in Hadoop Monitoring (hadoop_monitor) Configuration v1.0.
System Node
In addition to clusters, you can add monitors to the Hadoop system components and services. The Hadoop Monitoring probe can monitor the
following system components and services:
CPU
Memory
Network - this node is a container node for the following network services:
eth0
Io
TCP
StorageVolumes - this node is a container node for system directories:
/
/boot
/home
Navigation: hadoop_monitor > profile > hostname > System
Click the system node to add/configure monitors to the cluster. To add/configure monitors for components or services on the system, expand the
systemnode, and navigate through the hierarchy as needed. Select each node you wish to monitor. In the details pane, select the monitors you
wish to configure and add to that node, and modify settings as appropriate.
Fields to know:
QoS Name
Description
Units
Metric Type Id
Publish Data
Publish Alarms
Value Definition
Number of Samples
Operator
The operator to be used when setting the high or low alarm threshold for the measured value. You must select Publish Alarms to enable
this setting.
Example:
Threshold
Message Name
Configure dynamic alarm thresholds following the instructions found in Hadoop Monitoring (hadoop_monitor) Configuration v1.0.
hadoop_monitor Metrics
The following tables list the metrics you can collect with the Hadoop Monitoring (hadoop_monitor) probe.
Contents
Cluster Level
Node Level
Process Level Metrics
Hadoop Service Level Metrics
Job Level Metrics
Job and Task Level Metrics
Cluster Level
The metrics in this table are configured in the Cluster node in the Hadoop Monitoring probe GUI
Metric
Units
Description
QOS_HADOOP_CLUSTER_VERSION
Float
Version of Hadoop
Node Level
The metrics in these tables are configured in the System nodes in the Hadoop Monitoring probe GUI.
Network Metrics - Interfaces

Metric
Units
Description
QOS_HADOOP_SYS_NET_IF_SPEED
Bytes/Second
Network Interface speed
QOS_HADOOP_SYS_NET_RX_BYTES
Bytes
Number of bytes received
QOS_HADOOP_SYS_NET_TX_BYTES
Bytes
Number of bytes transmitted
QOS_HADOOP_SYS_NET_RX_PACKETS
Count
Number of packets received
QOS_HADOOP_SYS_NET_RX_DROPPED
Bytes
Number of received packets dropped due to error
QOS_HADOOP_SYS_NET_RX_OVERRUNS
Count
Number of received packets that experienced data overrun errors
QOS_HADOOP_SYS_NET_RX_ERRORS
Count
Number of packets received with errors
QOS_HADOOP_SYS_NET_RX_FRAMES
Count
Number of packets received with frame errors
QOS_HADOOP_SYS_NET_TX_COLLISIONS
Count
Number of transmitted packets that experienced collisions
QOS_HADOOP_SYS_NET_TX_PACKETS
Count
Number of packets transmitted
QOS_HADOOP_SYS_NET_TX_DROPPED
Count
Number of transmitted packets dropped due to error
QOS_HADOOP_SYS_NET_TX_ERRORS
Count
Number of transmitted packets that experienced error
QOS_HADOOP_NET_TX_CARRIER
Bytes
Number of transmitted packets that experienced loss of carrier errors
QOS_HADOOP_SYS_NET_TX_OVERRUNS
Bytes
Number of transmitted packets that experienced data overrun errors
QOS_HADOOP_SYS_TCP_ACTIVE_OPENS
Count
Number of TCP connections initiated by the server
Network Metrics - TCP

Metric
Units
Description
QOS_HADOOP_SYS_TCP_ACTIVE_OPENS
Count
Number of TCP connections initiated by the server
QOS_HADOOP_SYS_TCP_ESTAB_RESETS
Count
Number of TCP connections that were reset
QOS_HADOOP_SYS_TCP_CURR_ESTAB
Count
Number of currently established TCP connections
QOS_HADOOP_SYS_TCP_ATTEMPT_FAILS
Count
Number of failed TCP connection attempts
QOS_HADOOP_SYS_TCP_PASSIVE_OPENS
Count
Number of new TCP connections to a server
QOS_HADOOP_SYS_TCP_OUT_RSTS
Count
Number of TCP resets that have been sent outbound
QOS_HADOOP_SYS_TCP_RETRANS_SEGS
Count
Number of retransmitted TCP segments
QOS_HADOOP_SYS_TCP_IN_SEGS
Count
Number of TCP segments that have been received
QOS_HADOOP_SYS_TCP_IN_ERRS
Count
Number of incoming TCP segments that had errors
QOS_HADOOP_SYS_TCP_OUT_SEGS
Count
Number of TCP segments that have been sent
Memory Metrics
Metric
Units
Description
QOS_HADOOP_SYS_MEM_FREE
Bytes
Total free system memory (e.g. Linux plus cached)
QOS_HADOOP_SYS_MEM_USED
Bytes
Total used system memory
QOS_HADOOP_SYS_MEM_USED_PERCENT
Percent
Percent total used system memory
QOS_HADOOP_SYS_MEM_SWAP_FREE
Bytes
Total free system swap
QOS_HADOOP_SYS_MEM_SWAP_USED
Bytes
Total used system swap
QOS_HADOOP_SYS_MEM_SWAP_USED_SWAP_PERCENT
Percent
Percent total used system swap
I/O Metrics
Metric
Units
Description
QOS_HADOOP_SYS_IO_DISK_READ_BYTES
Bytes
QOS_HADOOP_SYS_IO_DISK_READS
Count
QOS_HADOOP_SYS_IO_DISK_SERVICE_TIME
Milliseconds
The average service time for I/O requests that were issued
QOS_HADOOP_SYS_IO_USE_PERCENT
Percent
Percent of disk used
QOS_HADOOP_SYS_IO_DISK_WRITE_BYTES
Bytes
Number of physical bytes written
QOS_HADOOP_SYS_IO_DISK_WRITES
Count
Number of physical disk writes
QOS_HADOOP_SYS_IO_TOTAL
Kilobytes
Total capacity of filesystem in Kilobytes
QOS_HADOOP_SYS_IO_FREE
Kilobytes
Total free Kilobytes on the filesystem
QOS_HADOOP_SYS_IO_USED
Kilobytes
Total used Kilobytes on filesystem
CPU Metrics
Metric
Units
Description
QOS_HADOOP_SYS_CPU_IDLE
Percent
Percentage CPU was idle
QOS_HADOOP_SYS_CPU_WAIT
Percent
Percentage of CPU was idle due to waiting for an I/O request
QOS_HADOOP_SYS_CPU_IRQ
Percent
Percentage CPU was handling interrupts
QOS_HADOOP_SYS_CPU_NICE
Percent
Percentage of CPU used in user level with nice priority
QOS_HADOOP_SYS_CPU_SOFT_IRQ
Percent
Percentage CPU was handling soft irqs
QOS_HADOOP_SYS_CPU_STOLEN
Percent
Percentage CPU was stolen by other virtualized environments
QOS_HADOOP_SYS_CPU_SYS
Percent
Percentage of CPU used in system level
QOS_HADOOP_SYS_CPU_USER
Percent
Percentage of CPU used in user level
Process Level Metrics

The metrics in this table are collected for every hadoop process - namenode, datanode, jobtracker, etc. They can be configured in the respective
nodes in the Hadoop Monitoring probe GUI
Process Native Metrics - Memory

Metric
Units
Description
QOS_HADOOP_PROC_SYS_MEM_MAJOR_FAULTS
Count
Number of page faults that caused disk i/o
QOS_HADOOP_PROC_MEM_MINOR_FAULTS
Count
Number of page faults that did not cause disk i/o
QOS_HADOOP_PROC_MEM_PAGE_FAULTS
Count
Total number of page faults for the process
QOS_HADOOP_PROC_MEM_SIZE
Bytes
Amount of memory the process thinks it has
QOS_HADOOP_PROC_MEM_RESIDENT
Bytes
Amount of memory the process actually has
QOS_HADOOP_PROC_MEM_SHARE
Bytes
Amount of shared memory the process has
Process Native Metrics - I/O

Metric
Units
Description
QOS_HADOOP_PROC_IO_FD
Count
Total number of file descriptors opened by the process
Process Native Metrics - CPU

Metric
Units
Description
QOS_HADOOP_PROC_CPU_SYS
Milliseconds
Process CPU kernel time
QOS_HADOOP_PROC_CPU_SYS_PERCENT
Percent
Process CPU kernel time percent
QOS_HADOOP_PROC_CPU_TOTAL
Milliseconds
Total process CPU time (sum or user and sys)
QOS_HADOOP_PROC_CPU_PERCENT
Percent
Process CPU usage in percentage
QOS_HADOOP_PROC_CPU_USER
Milliseconds
Process CPU user time
QOS_HADOOP_PROC_CPU_USER_PERCENT
Percent
Process CPU user time percent
Process ID Metrics
Metric
Units
Description
QOS_HADOOP_PROC_ID
Integer
PID of Hadoop role running on this node
Java Virtual Machine Metrics

Metric
Units
Description
QOS_HADOOP_JVM_GC_COUNT
Count
Number of times JVM garbage collection had to be run
QOS_HADOOP_JVM_GC_TIME
Milliseconds
Total time taken for all garbage collections
QOS_HADOOP_JVM_HEAP_CMTD
Megabytes
Heap memory committed by JVM
QOS_HADOOP_JVM_MEMHEAP_USED
Megabytes
JVM Heap memory used by the process
QOS_HADOOP_JVM_MEMMAX_M
Megabytes
Max Memory allocated to JVM
QOS_HADOOP_JVM_MEMNONHEAP_CMTD
Megabytes
Non JVM heap memory committed to the process
QOS_HADOOP_JVM_MEMNONHEAP_USED
Megabytes
Non JVM heap memory used by the process
QOS_HADOOP_JVM_MEMHEAP_USED_PERCENT
Percent
Percent of JVM heap memory used
QOS_HADOOP_JVM_THREADSTIME_WTNG
Count
Number of threads currently waiting based on a timeout for lockout to

be released in JVM
QOS_HADOOP_JVM_THREADS_BLCKD
Count
Number of threads in a BLOCKED state, which means they are waiting

for a lock
QOS_HADOOP_JVM_THREADS_NEW
Count
Number of threads in a NEW state, which means they have not been
started
QOS_HADOOP_JVM_THREADS_RNBLE
Count
Number of threads in a RUNNABLE state that are executing in the JVM

but may be waiting for system resources, such as CPU
QOS_HADOOP_JVM_THREADS_TERMINATED
Count
Number of threads in a TERMINATED state, which means they finished

executing. This value should be around zero since the metric only
collects information over live threads
QOS_HADOOP_JVM_THREADS_WTNG
Count
Number of threads in a WAITING state, which means they are waiting

for another thread to perform an action
Hadoop Service Level Metrics

The metrics in these tables are collected for specific Hadoop services.
Namenode Metrics
The metrics in this table are configured in the Cluster node in the Hadoop Monitoring probe GUI.
Metric
Units
Description
QOS_HADOOP_CLUSTER_LIVE_NODES
Count
Number of live datanodes
QOS_HADOOP_CLUSTER_DEAD_NODES
Count
Number of dead datanodes
QOS_HADOOP_CLUSTER_DECOM_NODES
Count
Number of decommissioned datanodes
HDFS Metrics - FSNameSystem

The metrics in this table are configured in the HDFS node in the Hadoop Monitoring probe GUI.
Metric
Units
Description
QOS_HADOOP_HDFS_CAPACITY_TOTAL
Bytes
Total HDFS capacity configured for this

cluster/node
QOS_HADOOP_HDFS_SENDDATAPACKETTRANSFERNANOS
Float
Average time for

SendDataPacketTransferNanos operation
QOS_HADOOP_HDFS_SNAPSHOTTABLEDIRECTORIES
Count
Number of directories that are

snapshottable
QOS_HADOOP_HDFS_SNAPSHOTS
Count
Number of HDFS snapshots that are taken
QOS_HADOOP_HDFS_BLOCKSTOTAL
Count
Total number of blocks in a cluster
QOS_HADOOP_HDFS_PENDINGREPLICATIONBLOCKS
Count
Number of blocks that are waiting for

replication. Datanodes that are back
online after being down reduces the
number of blocks waiting for replication
QOS_HADOOP_HDFS_UNDERREPLICATEDBLOCKS
Count
Number of under replicated blocks in a

cluster. Datanodes being down or a
sudden increased load on the cluster can
cause under replicated blocks
QOS_HADOOP_HDFS_CORRUPTBLOCKS
Count
Number off corrupt blocks in a cluster.

Corrupt blocks can be caused by one or
more datanodes being down. This value
should be zero or below an accepted
threshold
QOS_HADOOP_HDFS_PENDINGDELETIONBLOCKS
Count
Number of blocks that are waiting for

deletion. Datanodes that are back online
after being down reduces the number of
blocks waiting for deletion
QOS_HADOOP_HDFS_EXCESSBLOCKS
Count
Number of excess blocks in a cluster.

Excess blocks can be caused by a
namenode losing one or more heartbeats
from one or more datanodes, and this
causes the scheduling of extra replicas
QOS_HADOOP_HDFS_CAPACITYUSED
Bytes
Total HDFS capacity currently used
QOS_HADOOP_HDFS_POSTPONEDMISREPLICATEDBLOCKS
Count
Number of postponed block

mis-replications
QOS_HADOOP_HDFS_PENDINGDATANODEMESSAGECOUNT
Count
Count of pending datanode messages
QOS_HADOOP_HDFS_MILLISSINCELASTLOADEDEDITS
Milliseconds
Milliseconds since last loaded edit
QOS_HADOOP_HDFS_BLOCKCAPACITY
Bytes
Block capacity
QOS_HADOOP_HDFS_SENDDATAPACKETBLOCKEDONNETWORKNANOSAVGTIME
Float
Average time for

SendDataPacketBlockedOnNetworkNanos
operation
QOS_HADOOP_HDFS_STALEDATANODES
Count
Number of stale datanodes
QOS_HADOOP_HDFS_CREATEFILEOPS
Count
Number of created file operations

occurring in a cluster
QOS_HADOOP_HDFS_FILESCREATED
Count
Number of files created in a cluster
QOS_HADOOP_HDFS_FILESAPPENDED
Count
Number of files appended in a cluster
QOS_HADOOP_HDFS_FILESRENAMED
Count
Number of files renamed in a cluster
QOS_HADOOP_HDFS_CAPACITYREMAINING
Bytes
Total HDFS capacity remaining
QOS_HADOOP_HDFS_GETLISTINGOPS
Count
Number of HDFS listing operations

QOS_HADOOP_HDFS_DELETEFILEOPS
Count
Number of delete file operations occurring

in a cluster
QOS_HADOOP_HDFS_FILESDELETED
Count
Number of files deleted in a cluster
QOS_HADOOP_HDFS_FILESINFOOPS
Count
Number of file info operations occurring in

a cluster
QOS_HADOOP_HDFS_FILESINGETLISTINGOPS
Count
Number of files returned as part of HDFS

listing operations
QOS_HADOOP_HDFS_CREATESNAPSHOTOPS
Count
Number of create snapshot operations

QOS_HADOOP_HDFS_DELETESNAPSHOTOPS
Count
Number of delete snapshot operations

QOS_HADOOP_HDFS_RENAMESNAPSHOTOPS
Count
Number of rename shapshot operations

QOS_HADOOP_HDFS_LISTSNAPSHOTTABLEDIROPS
Count
Number of list snapshottable directory

operations occurring in a cluster
QOS_HADOOP_HDFS_TRANSACTIONSNUMOPS
Count
Number of transaction operations

QOS_HADOOP_HDFS_CAPACITYUSED_PERCENT
Percent
Total HDFS capacity currently used in

percentage
QOS_HADOOP_HDFS_TRANSACTIONSAVGTIME
Float
Average time for a transaction
QOS_HADOOP_HDFS_SYNCSNUMOPS
Count
Number of synchronize operations
QOS_HADOOP_HDFS_SYNCSAVGTIME
Float
Average time for synchronize operation
QOS_HADOOP_HDFS_BLOCKREPORTNUMOPS
Count
Number of block report operations
QOS_HADOOP_HDFS_BLOCKREPORTAVGTIME
Float
Average time for block report operation
QOS_HADOOP_HDFS_BYTESWRITTEN
Bytes
Number of bytes written to HDFS
QOS_HADOOP_HDFS_BYTESREAD
Bytes
Number of bytes read from HDFS
QOS_HADOOP_HDFS_BLOCKSWRITTEN
Count
Number of blocks written
QOS_HADOOP_HDFS_BLOCKSREAD
Count
Number of blocks read
QOS_HADOOP_HDFS_BLOCKSREPLICATED
Count
Number of blocks replicated
QOS_HADOOP_HDFS_CAPACITYUSEDNONDFS
Bytes
Non HDFS capacity used
QOS_HADOOP_HDFS_BLOCKSREMOVED
Count
Number of blocks removed
QOS_HADOOP_HDFS_BLOCKSVERIFIED
Count
Number of blocks verified
QOS_HADOOP_HDFS_BLOCKVERIFICATIONFAILURES
Count
Number of block verification failures
QOS_HADOOP_HDFS_READSFROMLOCALCLIENT
Count
Number of reads from local client
QOS_HADOOP_HDFS_READSFROMREMOTECLIENT
Count
Number of reads from remote client
QOS_HADOOP_HDFS_WRITESFROMLOCALCLIENT
Count
Number of writes from local client
QOS_HADOOP_HDFS_WRITESFROMREMOTECLIENT
Count
Number of writes from remote client
QOS_HADOOP_HDFS_BLOCKSGETLOCALPATHINFO
Count
Number of blocks that get local path info
QOS_HADOOP_HDFS_FSYNCCOUNT
Count
Number of fsync operations
QOS_HADOOP_HDFS_READBLOCKOPNUMOPS
Count
Number of read block ops
QOS_HADOOP_HDFS_TotalLoad
Count
Total number of transceivers (readers and

writers) reported by all the datanodes
QOS_HADOOP_HDFS_READBLOCKOPAVGTIME
Float
Average time for read block operations
QOS_HADOOP_HDFS_WRITEBLOCKOPNUMOPS
Count
Number of write block operations
QOS_HADOOP_HDFS_WRITEBLOCKOPAVGTIME
Float
Average time for write block operations
QOS_HADOOP_HDFS_BLOCKCHECKSUMOPNUMOPS
Count
Number of BlockChecksum operations
QOS_HADOOP_HDFS_BLOCKCHECKSUMOPAVGTIME
Float
Average time for BlockChecksum

operations
QOS_HADOOP_HDFS_COPYBLOCKOPNUMOPS
Count
Number of CopyBlockNum operations
QOS_HADOOP_HDFS_COPYBLOCKOPAVGTIME
Float
Average time for CopyBlock operations
QOS_HADOOP_HDFS_REPLACEBLOCKOPNUMOPS
Count
Number of ReplaceBlock operations
QOS_HADOOP_HDFS_REPLACEBLOCKOPAVGTIME
Count
Average time for ReplaceBlock operations
QOS_HADOOP_HDFS_HEARTBEATSNUMOPS
Count
Number of Heartbeat operations
QOS_HADOOP_HDFS_NUMFAILEDVOLUMES
Count
Number of failed volumes
QOS_HADOOP_HDFS_HEARTBEATSAVGTIME
Float
Average time for heartbeats
QOS_HADOOP_HDFS_BLOCKREPORTSNUMOPS
Count
Number of BlockReports operations
QOS_HADOOP_HDFS_BLOCKREPORTSAVGTIME
Float
Average time for BlockReports operation
QOS_HADOOP_HDFS_PACKETACKROUNDTRIPTIMENANOSNUMOPS
Count
Number of
PacketAckRoundTripTimeNanos
operations
QOS_HADOOP_HDFS_PACKETACKROUNDTRIPTIMENANOSAVGTIME
Float
Average time for

PacketAckRoungTripTimeNanos
operation
QOS_HADOOP_HDFS_FLUSHNANOSNUMOPS
Count
Number of disk flush operations
QOS_HADOOP_HDFS_FLUSHNANOSAVGTIME
Float
Average time for disk flush operations
QOS_HADOOP_HDFS_FSYNCNANOSNUMOPS
Integer
Number of Disk Fsyncs operations
QOS_HADOOP_HDFS_FSYNCNANOSAVGTIME
Float
Average time for Disk Fsyncs operations
QOS_HADOOP_HDFS_SENDDATAPACKETBLOCKEDONNETWORKNANOSNUMOPS
Count
Number of
SendDataPacketBlockedOnNetworkNanos
operations
QOS_HADOOP_HDFS_TOTALFILES
Count
Total number of files and directories in the

HDFS
QOS_HADOOP_HDFS_SENDDATAPACKETTRANSFERNANOSNUMOPS
Count
Number of
SendDataPacketTransferNanos Operation
HBASE Metrics
The metrics in this table are configured on the HBASE Node in the Hadoop Monitoring probe GUI.
Metric
Units
Description
QOS_HADOOP_HBASE_CLUSTERREQUESTS
Count
Total number of requests from all region servers to a

cluster
QOS_HADOOP_HBASE_AVERAGELOAD
Float
Average number of regions served by each region server
QOS_HADOOP_HBASE_NUMREGIONSERVERS
Count
Total number of region servers
QOS_HADOOP_HBASE_NUMDEADREGIONSERVERS
Count
Number of dead region servers
QOS_HADOOP_HBASE_BULKASSIGN_NUM_OPS
Count
Number of bulk assignment operations
QOS_HADOOP_HBASE_BULKASSIGN_MIN
Bytes
Minimum bulk assignment operation size
QOS_HADOOP_HBASE_BULKASSIGN_MAX
Bytes
Maximum bulk assignment operation size
QOS_HADOOP_HBASE_BULKASSIGN_MEAN
Float
Average bulk assignment operation size
QOS_HADOOP_HBASE_BULKASSIGN_MEDIAN
Float
Median bulk assignment operation size
QOS_HADOOP_HBASE_ASSIGN_NUM_OPS
Count
Number of assignment operations
QOS_HADOOP_HBASE_ASSIGN_MIN
Bytes
Minimum assignment operation size
QOS_HADOOP_HBASE_ASSIGN_MAX
Bytes
Maximum assignment operation size
QOS_HADOOP_HBASE_ASSIGN_MEAN
Float
Average assignment operation size
QOS_HADOOP_HBASE_ASSIGN_MEDIAN
Float
Median assignment operation size
QOS_HADOOP_HBASE_HLOGSPLITTIME_NUMOPS
Count
Time to split write-ahead log files
QOS_HADOOP_HBASE_HLOGSPLITTIME_MIN
Milliseconds
Minimum time to split the total size of a write-ahead log

file
QOS_HADOOP_HBASE_HLOGSPLITTIME_MAX
Milliseconds
Maximum time to split the write-ahead log file after a

restart
QOS_HADOOP_HBASE_HLOGSPLITTIME_MEAN
Float
Average time to split the total size of a write-ahead log file
QOS_HADOOP_HBASE_HLOGSPLITTIME_MEDIAN
Float
Median time to split the total size of a write-ahead log file
QOS_HADOOP_HBASE_METAHLOGSPLITTIME_NUM_OPS
Count
Time to split MetaHLogs
QOS_HADOOP_HBASE_METAHLOGSPLITTIME_MIN
Milliseconds
Minimum time to split the total size of a MetaHLog
QOS_HADOOP_HBASE_METAHLOGSPLITTIME_MAX
Milliseconds
Maximum time to split a MetaHLog after a restart
QOS_HADOOP_HBASE_METAHLOGSPLITTIME_MEAN
Float
Average time to split the total size of a MetaHLog
QOS_HADOOP_HBASE_METAHLOGSPLITTIME_MEDIAN
Float
Median time to split the total size of a MetaHLog
QOS_HADOOP_HBASE_METAHLOGSPLITSIZE_NUM_OPS
Count
Number of MetaHLogsize operations
QOS_HADOOP_HBASE_METAHLOGSPLITSIZE_MIN
Bytes
Minimum size of MetaHlog files being split
QOS_HADOOP_HBASE_METAHLOGSPLITSIZE_MAX
Bytes
Maximum size of MetaHlog files being split
QOS_HADOOP_HBASE_METAHLOGSPLITSIZE_MEAN
Float
Average size of MetaHlog files being split
QOS_HADOOP_HBASE_METAHLOGSPLITSIZE_MEDIAN
Float
Median size of MetaHlog files being split
QOS_HADOOP_HBASE_HLOGSPLITSIZE_NUM_OPS
Count
Number of HlogSplitSize operations
QOS_HADOOP_HBASE_HLOGSPLITSIZE_MIN
Bytes
Minimum size of write-ahead log files being split
QOS_HADOOP_HBASE_HLOGSPLITSIZE_MAX
Bytes
Maximum size of write-ahead log files being split
QOS_HADOOP_HBASE_HLOGSPLITSIZE_MEAN
Float
Average size of write-ahead log files being split
QOS_HADOOP_HBASE_HLOGSPLITSIZE_MEDIAN
Float
Median size of write-ahead log files being split
QOS_HADOOP_REGION_REGIONCOUNT
Count
Number of regions served by a region server
QOS_HADOOP_REGION_STORECOUNT
Count
Number of stores served by all region servers
QOS_HADOOP_REGION_READREQUESTCOUNT
Count
Number of read requests this region server has answered
QOS_HADOOP_REGION_WRITEREQUESTCOUNT
Count
Number of mutation requests this region server has

answered
QOS_HADOOP_REGION_TOTALREQUESTCOUNT
Count
Total number of requests this region server has answered
QOS_HADOOP_REGION_SLOWDELETECOUNT
Count
Number of Deletes that took over 1000 ms to complete
QOS_HADOOP_REGION_SLOWINCREMENTCOUNT
Count
Number of Increments that took over 1000 ms to

complete
QOS_HADOOP_REGION_SLOWGETCOUNT
Count
Number of Gets that took over 1000 ms to complete
QOS_HADOOP_REGION_SLOWAPPENDCOUNT
Count
Number of Appends that took over 1000 ms to complete
QOS_HADOOP_REGION_SLOWPUTCOUNT
Count
Number of Puts that took over 1000 ms to complete
QOS_HADOOP_REGION_CHECKMUTATEFAILEDCOUNT
Count
Number of Check and Mutate calls that failed the checks
QOS_HADOOP_REGION_CHECKMUTATEPASSEDCOUNT
Count
Number of Check and Mutate calls that passed the

checks
QOS_HADOOP_REGION_STOREFILEINDEXSIZE
Kilobytes
Size of indexes in storefiles on disk
QOS_HADOOP_REGION_STATICINDEXSIZE
Kilobytes
Uncompressed size of the static indexes
QOS_HADOOP_REGION_STATICBLOOMSIZE
Kilobytes
Uncompressed size of the static bloom filters
QOS_HADOOP_REGION_PERCENTFILESLOCAL
Percent
Percent of HFiles that are stored on the local HDFS

datanode
QOS_HADOOP_REGION_COMPACTIONQUEUELENGTH
Count
Length of the queue for compactions
QOS_HADOOP_REGION_FLUSHQUEUELENGTH
Count
Length of the flush queue
QOS_HADOOP_REGION_HLOGFILECOUNT
Count
Number of write-ahead log files
QOS_HADOOP_REGION_HLOGFILESIZE
Kilobytes
Size of all write-ahead log files
QOS_HADOOP_REGION_STOREFILECOUNT
Count
Number of storefiles in all stores and regions
QOS_HADOOP_REGION_MEMSTORESIZE
Kilobytes
Size of the memstore
QOS_HADOOP_REGION_STOREFILESIZE
Kilobytes
Size of storefiles being served
QOS_HADOOP_REGION_BLOCKCACHEFREESIZE
Bytes
Size of the block cache that is not occupied
QOS_HADOOP_REGION_BLOCKCACHECOUNT
Count
Number of storefiles cached in the block cache
QOS_HADOOP_REGION_BLOCKCACHESIZE
Kilobytes
Number of bytes used by cached blocks
QOS_HADOOP_REGION_BLOCKCACHEHITCOUNT
Count
Total number of block cache hits for requests, regardless

of caching setting
QOS_HADOOP_REGION_BLOCKCACHEMISSCOUNT
Count
Total number of block cache misses for requests,

regardless of caching setting
QOS_HADOOP_REGION_BLOCKCACEEVICTIONCOUNT
Count
Number of blocks evicted from the block cache
QOS_HADOOP_REGION_BLOCKCOUNTHITPERCENT
Percent
Percent of block cache requests that are hits regardless

of the caching setting
QOS_HADOOP_REGION_BLOCKCACHEEXPRESSHITPERCENT
Percent
Percent of the time that requests with the cache turned on

hit the cache
QOS_HADOOP_REGION_APPEND_NUM_OPS
Count
Number of Append operations
QOS_HADOOP_REGION_APPEND_MIN
Milliseconds
Minimum time taken for Append requests
QOS_HADOOP_REGION_APPEND_MAX
Milliseconds
Maximum time taken for Append requests
QOS_HADOOP_REGION_APPEND_MEAN
Float
Average time taken for Append requests
QOS_HADOOP_REGION_APPEND_MEDIAN
Float
Median time taken for Append requests
QOS_HADOOP_REGION_DELETE_NUM_OPS
Count
Number of Delete operations
QOS_HADOOP_REGION_DELETE_MIN
Milliseconds
Minimum time taken for Delete requests
QOS_HADOOP_REGION_DELETE_MAX
Milliseconds
Maximum time taken for Delete requests
QOS_HADOOP_REGION_DELETE_MEAN
Float
Average time taken for Delete requests
QOS_HADOOP_REGION_DELETE_MEDIAN
Float
Median time taken for Delete requests
QOS_HADOOP_REGION_MUTATE_NUM_OPS
Count
Number of Mutate operations
QOS_HADOOP_REGION_MUTATE_MIN
Milliseconds
Minimum time taken for Mutate requests
QOS_HADOOP_REGION_MUTATE_MAX
Milliseconds
Maximum time taken for Mutate requests
QOS_HADOOP_REGION_MUTATE_MEAN
Float
Average time taken for Mutate requests
QOS_HADOOP_REGION_MUTATE_MEDIAN
Float
Median time taken for Mutate requests
QOS_HADOOP_REGION_GET_NUM_OPS
Count
Number of Get operations
QOS_HADOOP_REGION_GET_MIN
Milliseconds
Minimum time taken for Get requests
QOS_HADOOP_REGION_GET_MAX
Milliseconds
Maximum time taken for Get requests
QOS_HADOOP_REGION_GET_MEAN
Float
Average time taken for Get requests
QOS_HADOOP_REGION_GET_MEDIAN
Float
Median time taken for Get requests
QOS_HADOOP_REGION_REPLAY_NUM_OPS
Count
Number of Replay operations
QOS_HADOOP_REGION_REPLAY_MIN
Milliseconds
Minimum time taken for Replay requests
QOS_HADOOP_REGION_REPLAY_MAX
Milliseconds
Maximum time taken for Replay requests
QOS_HADOOP_REGION_REPLAY_MEAN
Float
Average time taken for Replay requests
QOS_HADOOP_REGION_REPLAY_MEDIAN
Float
Median time taken for Replay requests
QOS_HADOOP_REGION_INCREMENT_NUM_OPS
Count
Number of Increment operations
QOS_HADOOP_REGION_INCREMENT_MIN
Milliseconds
Minimum time taken for Increment requests
QOS_HADOOP_REGION_INCREMENT_MAX
Milliseconds
Maximum time taken for Increment requests
QOS_HADOOP_REGION_INCREMENT_MEAN
Float
Average time taken for Increment requests
QOS_HADOOP_REGION_INCREMENT_MEDIAN
Float
Median time taken for Increment requests
YARN Metrics (yarn only) - Queues

The metrics in this table are configured on the Applications Node in the Hadoop Monitoring probe GUI.
Metric
Units
Description
QOS_HADOOP_YARN_RUNNING_GREATER_THAN_60
Count
Number of jobs running for more than 1 hour
Count
Number of jobs running for more than 5 hours
Count
Number of jobs running for more than 24 hours
QOS_HADOOP_YARN_FAIRSHAREMB
Megabytes
Total fair share allocation of memory across all queues
QOS_HADOOP_YARN_FAIRSHAREVCORES
Count
Fair share CPU in virtual cores across all queues
QOS_HADOOP_YARN_MINSHAREMB
Megabytes
Minimum share of memory across all queues
QOS_HADOOP_YARN_MINSHAREVCORES
Count
Minimum share of CPu in virtual cores across all queues
QOS_HADOOP_YARN_MAXSHAREMB
Megabytes
Maximum share of memory across all queues
QOS_HADOOP_YARN_MAXSHAREVCORES
Count
Maximum share of CPU in virtual cores across all queues
QOS_HADOOP_YARN_APPSSUBMITTED
Count
Number of submitted applications
QOS_HADOOP_YARN_CURRENLY_RUNNING
Count
Number of applications running
QOS_HADOOP_YARN_APPSPENDING
Count
Number of applications pending across all queues
QOS_HADOOP_YARN_APPSCOMPLETED
Count
Number of applications completed across all queues
QOS_HADOOP_YARN_APPSKILLED
Count
Number of applications killed across all queues
QOS_HADOOP_YARN_APPSFAILED
Count
Number of applications failed across all queues
QOS_HADOOP_YARN_ALLOCATEDMB
Megabytes
Amount of allocated memory across all queues
QOS_HADOOP_YARN_ALLOCATEDVCORES
Count
Allocated CPU in virtual cores across all queues
QOS_HADOOP_YARN_ALLOCATEDCONTAINERS
Count
Number of allocated containers across all queues
QOS_HADOOP_YARN_AGGREGATECONTAINERSALLOCATED
Count
Aggregate number of allocated containers across all

queues
QOS_HADOOP_YARN_AGGREGATECONTAINERSRELEASED
Count
Aggregate number of containers released
QOS_HADOOP_YARN_AVAILABLEMB
Megabytes
Amount of available memory across all queues
QOS_HADOOP_YARN_AVAILABLEVCORES
Count
Available CPU in virtual cores across all queues
QOS_HADOOP_YARN_PENDINGMB
Megabytes
Amount of pending memory allocation across all queues
QOS_HADOOP_YARN_PENDINGVCORES
Count
Pending CPU allocation in virtual cores across all queues
QOS_HADOOP_YARN_PENDINGCONTAINERS
Count
Number of pending containers across all queues
QOS_HADOOP_YARN_RESERVEDMB
Megabytes
Amount of reserved memory allocated across all queues
QOS_HADOOP_YARN_RESERVEDVCORES
Count
Reserved CPU allocation in virtual cores across all queues
QOS_HADOOP_YARN_RESERVEDCONTAINERS
Count
Number of reserved containers across all queues
QOS_HADOOP_YARN_ACTIVEUSERS
Count
Number of active users across all queues
YARN Metrics (yarn only) - Containers

These metrics are published for every Hadoop node. Container metrics can be configured on the YARN node in the Hadoop Monitoring probe
GUI.
Metric
Units
Description
QOS_HADOOP_YARN_ALLOCATEDCONTAINERS
Count
Number of allocated containers
QOS_HADOOP_YARN_CONTAINERSCOMPLETED
Count
Number of completed containers
QOS_HADOOP_YARN_CONTAINERSFAILED
Count
Number of failed containers
QOS_HADOOP_YARN_CONTAINERSINITING
Count
Number of initializing
QOS_HADOOP_YARN_CONTAINERSKILLED
Count
Number of killed containers
QOS_HADOOP_YARN_CONTAINERSLAUNCHED
Count
Number of containers launched
QOS_HADOOP_YARN_CONTAINERSRUNNING
Count
Number of containers currently running
QOS_HADOOP_YARN_ALLOCATEDGB
Gigabytes
Amount of memory allocated
QOS_HADOOP_YARN_AVAILABLEGB
Gigabytes
Amount of memory currently available
Job Level Metrics

The metrics collected in as described in these tables are aggregate metrics. This means that if the same job runs 10 times, the metrics published
are averaged across the 10 runs. Job Level Metrics can only be collected at job completion time. They cannot be collected as the job is running.
This means that only the final totals are captured, not running counts over time.
Job Counters (yarn only)

Metric
Units
Description
QOS_HADOOP_JOB_TOTAL_LAUNCHED_MAPS
Count
Number of launched map tasks, averaged across all runs
QOS_HADOOP_JOB_TOTAL_LAUNCHED_REDUCES
Count
Number of launched reduce tasks, averaged across all runs
QOS_HADOOP_JOB_TOTAL_DATA_LOCAL_MAPS
Count
Number of data-local map tasks, averaged across all runs
QOS_HADOOP_JOB_SLOTS_MILLIS_MAPS
Milliseconds
Total time spent by all maps in occupied slots, averaged across all
runs
QOS_HADOOP_JOB_SLOTS_MILLIS_REDUCES
Milliseconds
Total time spent by all reduces in occupied slots, averaged across all
runs
QOS_HADOOP_JOB_MILLS_MAPS
Milliseconds
Total time spent by all map task,s averaged across all runs
QOS_HADOOP_JOB_MILLIS_REDUCES
Milliseconds
Total time spent by all reduce tasks, averaged across all runs
QOS_HADOOP_JOB_VCORES_MILLIS_MAPS
Milliseconds
Total virtual core seconds taken by all map tasks, averaged across all
runs
QOS_HADOOP_JOB_VCORES_MILLIS_REDUCES
Milliseconds
Total virtual core seconds taken by reduce tasks, averaged across all
runs
QOS_HADOOP_JOB_MB_MILLIS_MAPS
Milliseconds
Total megabyte seconds taken by all map tasks, averaged across all
runs
QOS_HADOOP_JOB_MB_MILLIS_REDUCES
Milliseconds
Total megabyte seconds taken by all reduce tasks, averaged across

all runs
Job and Task Level Metrics

The metrics in these tables are collected for the entire job instance as well as for each separate map and reduce task that made up the job
instance. As with job level, the metrics can only be collected at job completion time. They cannot be collected as the job is running. This means
that only the final totals are captured, not running counts over time.
File System Counters (yarn only)

Metric
Units
Description
QOS_HADOOP_JOB_FILE_BYTES_READ
Bytes
Number of non-HDFS bytes read from the filesystem, averaged across all runs
QOS_HADOOP_JOB_FILE_BYTES_WRITTEN
Bytes
Number of non-HDFS bytes written to the filesystem, averaged across all runs
QOS_HADOOP_JOB_HDFS_BYTES_READ
Bytes
Number of HDFS bytes read from the filesystem, averaged across all runs
QOS_HADOOP_JOB_HDFS_BYTES_WRITTEN
Bytes
Number of HDFS bytes written to the filesystem, averaged across all runs
File System Counters (yarn only)

Metric
Units
Description
QOS_HADOOP_JOB_FILE_READ_OPS
Count
Number of non-HDFS read operations, averaged across all runs
QOS_HADOOP_JOB_FILE_LARGE_READ_OPS
Count
Number of non-HDFS large read operations, averaged across all runs
QOS_HADOOP_JOB_FILE_WRITE_OPS
Count
Number of non-HDFS write operations, averaged across all runs
QOS_HADOOP_JOB_HDFS_READ_OPS
Count
Number of HDFS read operations, averaged across all runs
QOS_HADOOP_JOB_HDFS_LARGE_READ_OPS
Count
Number of HDFS large read operations, averaged across all runs
QOS_HADOOP_JOB_HDFS_WRITE_OPS
Count
Number of HDFS write operations, averaged across all runs
MapReduce Framework (yarn only)

Metric
Units
Description
QOS_HADOOP_JOB_MAP_INPUT_RECORDS
Count
Number of map input records, averaged across all runs
QOS_HADOOP_JOB_MAP_OUTPUT_RECORDS
Count
Number of map output records, averaged across all runs
QOS_HADOOP_JOB_MAP_OUTPUT_BYTES
Bytes
Number of map outputs bytes, averaged across all runs
QOS_HADOOP_JOB_MAP_OUTPUT_MATERIALIZED_BYTES
Bytes
Number of map output materialized bytes, averaged across

all runs
QOS_HADOOP_JOB_SPLIT_RAW_BYTES
Bytes
Number of input bytes split,averaged across all runs
QOS_HADOOP_JOB_COMBINE_INPUT_RECORDS
Count
Number of combined input records, averaged across all runs
QOS_HADOOP_JOB_COMBINE_OUTPUT_RECORDS
Count
Number of combined output records, averaged across all

runs
QOS_HADOOP_JOB_REDUCE_INPUT_GROUPS
Count
Number of reduce input groups, averaged across all runs
QOS_HADOOP_JOB_REDUCE_SHUFFLE_BYTES
Bytes
Number of reduce shuffle bytes, averaged across all runs
QOS_HADOOP_JOB_REDUCE_INPUT_RECORDS
Count
Number of reduce input records, averaged across all runs
QOS_HADOOP_JOB_REDUCE_OUTPUT_RECORDS
Count
Number of reduce output records, averaged across all runs
QOS_HADOOP_JOB_SPILLED_RECORDS
Count
Number of spilled records, averaged across all runs
QOS_HADOOP_JOB_CPU_MILLISECONDS
Milliseconds
Amount of CPU time spent, averaged across all runs
QOS_HADOOP_JOB_PHYSICAL_MEMORY_BYTES
Bytes
Amount of physical memory used, averaged across all runs
QOS_HADOOP_JOB_VIRTUAL_MEMORY_BYTES
Bytes
Amount of virtual memory used, averaged across all runs
QOS_HADOOP_JOB_COMMITTED_HEAP_BYTES
Bytes
Amount of committed heap used, averaged across all runs
MapReduce Framework (yarn only)

Metric
Units
Description
QOS_HADOOP_JOB_SHUFFLED_MAPS
Count
Number of shuffled maps, averaged across all runs
QOS_HADOOP_JOB_FAILED_SHUFFLE
Counts
Number of failed shuffles, averaged across all runs
QOS_HADOOP_JOB_MERGED_MAP_OUTPUTS
Count
Average number of merged map outputs, averaged across all runs
QOS_HADOOP_JOB_GC_TIME_MILLIS
Milliseconds
Average time spent in garbage collection elapsed, averaged across all

runs
File Input and Output Format Counters (yarn only)

Metric
Units
Description
QOS_HADOOP_JOB_BYTES_READ
Bytes
Number of Bytes read, averaged across all runs
QOS_HADOOP_JOB_BYTES_WRITTEN
Bytes
Number of Bytes written, averaged across all runs
Shuffle Errors (yarn only)

Metric
Units
Definition
QOS_HADOOP_JOB_SHUFFLE_ERRORS_BAD_ID
Count
Number of Shuffle bad ID errors, averaged across all runs
QOS_HADOOP_JOB_SHUFFLE_ERRORS_CONNECTION
Count
Number of Shuffle connection errors, averaged across all runs
QOS_HADOOP_JOB_SHUFFLE_ERRORS_IO_ERROR
Count
Number of Shuffle IO errors, averaged across all runs
QOS_HADOOP_JOB_SHUFFLE_ERRORS_WRONG_LENGTH
Count
Number of Shuffles with wrong length errors, averaged across all

runs
QOS_HADOOP_JOB_SHUFFLE_ERRORS_WRONG_MAP
Count
Number of Map Shuffles with wrong errors, averaged across all

runs
QOS_HADOOP_JOB_SHUFFLE_ERRORS_WRONG_REDUCE
Count
Number of Reduce Shuffle with wrong errors, averaged across all

runs
hdb
The hdb probe provides a simple database service for managed probes. The robot uses the
and data trending. Collected data survives power outages.
hdb probe to store data for threshold monitoring
Hdb is included in the robot installer and update packages, and deploys during robot installation or upgrade.
Hdb does not require configuration, and does not have a configuration UI.
health_index
Collecting information about the health of your system over time provides comparison data that will help you detect a change in system behavior.
The health_index probe, which is deployed to the primary hub, collects alarms generated by monitoring probes from the UIM message bus. The
health index calculator uses these alarms to calculate a health score for computer systems and configuration items (CI Type IDs). Health index
information is displayed in CA Unified Service Manager or Infrastructure Manager.
More Information:
health_index Release Notes
View Health Scores in CA Unified Service Manager

This article explains how to view health index information in CA Unified Service Manager. As long as the health_index probe is installed and
running on the primary hub, and you have created a policy to enable the Health Index feature for monitoring probes, you can view a health index
chart in CA Unified Service Manager for all monitor metrics that have the Publish Alarms check box selected in the probe's GUI.
Note: Two data points are needed to display a health index chart in the Metrics tab of Unified Service Manager. By default, it can take
up to two hours (or double the health index calculation interval setting) to display the chart.
View the Computer System Health Score

In CA Unified Service Manager, you can view a health score graph for all monitored QoS metrics with health index enabled from the Metrics tab.
An overall health score is published for the computer system. You can then drill down and see the individual health scores generated for
associated configuration items (CI Type ID).
Follow these steps:
1. Open CA Unified Management Portal (UMP) in a web browser.
2. In CA Unified Service Manager, expand Groups (for example Operating Systems, then Windows) until the desired device is visible.
3. Click a device name.
4. Click the Metrics tab.
5. Expand Health and click Health Index.
6. Mouse over the chart to see health details.
The following illustration shows a sample health index graph for a device named pewindemo.dev.fco.
The health details displayed in the pop-up include:

Computer system name.
Time and date the health score was calculated.
Value shows the calculated overall health score for a computer system.
Max and Min shows the values for the interval, if the value falls above or below the trend.
Trend provides the linear trend-line value for the health scores generated over a period of time.
Alarm generated for the interval if the health score breached a user-defined threshold.
QoS message generated for the interval. Also note the name of the policy applied to the selected computer system is displayed for
reference purposes.
View the CI Type ID Health Scores

For each overall health score published for a computer system, you can then drill down and see the individual health scores generated for
associated configuration items (CI Type ID).
Follow these steps:
1. Open CA Unified Management Portal (UMP) in a web browser.
2. In CA Unified Service Manager, expand Groups (for example Operating Systems, then Windows) until the desired device is visible.
3. Click a device name.
4. Click the Metrics tab.
5. Expand a metric name and continue to expand displayed metrics to view a health score for a particular configuration item.
6. Click a configuration item (for example, the configuration item Total Memory which is a component of the CDM Memory metric).
7. Mouse over the chart to see health details.
The following illustration shows a sample health index chart for the CDM Memory CI Type ID 1.6, which is Total.
The health details displayed in the pop-up include:

CI Type ID/Metric name.
Time and date the health score was calculated.
Value shows the calculated health score for a CI Type ID.
Max and Min shows the values for the interval, if the value falls above or below the trend.
Trend provides the linear trend-line value for the health scores generated over a period of time.
For more information:
See Enable Health Index for details about creating a policy.
health_index Metrics
This article describes the QoS messages generated by the health_index probe.
QoS Metrics
The following QoS messages are generated when health scores breach user-configured health index alarm thresholds.
QoS Name
Units
Description
Version
QOS_HEALTH_INDEX
Health
number
from 1 to
100
Indicates the health score of a computer system. For example, the composite health score of disks,
memory, and CPU on a device. The QoS details for this type of message always contains 13:1.
1.0
QOS_HEALTH_INDEX
Health
number
from 1 to
100
Indicates the health score of a specific configuration item (CI). The QoS details for this type of message
contains ':0' appended to the metric type ID, for example 1.5:0 for the CPU Total Memory metric
configurable for the CDM probe.
1.0
history (iSeries QHST Data Monitoring)

The history (iSeries QHST Data Monitoring) probe monitors history messages from the QHST logs. The logs are present on the same iSeries
servers that host the probe. The probe only reads the QHST log files, and automatically detects new logs and new messages as they are written
to the log files. The log contains the system operated messages and history of the system activities. For example, status of the system, jobs
running on the system.
Note: The history probe does not generate any QoS metrics. Therefore, there are no probe checkpoint metrics to be configured for this
probe.
More information:
history (iSeries QHST Data Monitoring) Release Notes
v1.0 history AC Configuration

This article contains configuration details specific to the history (iseries QHST Data Monitoring) probe. Configure the probe to match the message
s specified in the profile, with the messages in QHST (history log message queue). If a match is found in the logs, the probe generates an alarm.
The following diagram outlines the process to configure the probe to monitor history logs.
Create a Monitoring Profile
Alarm Thresholds
Verify that required hardware and software is available before you configure the probe. For more information, see history (iSeries QHST Data

This section enables you to set up the logging details of the probe. You can specify the interval at which the running commands are updated or
deleted. You can also define the alarm settings when the probe finds a job match in the history logs.
Follow these steps:
1. Click the history node.
2. In the Setup Configuration section, provide the following field values:
log level: specify the level of details that are written to the log file in the Log Level field.
Default: Log-level-0
when debugging.
log size: specify the maximum size of the probe log file.
Default: 100 KB
3. Specify the time interval at which the jobs in the history log is scanned for messages. Reduce this interval to generate alarms frequently.
3.

4. Select Command on interval to monitor if a command is updated or deleted in the retrieved log file, at the specified interval. The probe
monitors properties like Data and Type, Type, Job ID, Job Name, and Sender Program of the updated command.
Enter the command in the Update Command field, to match whether the command is updated.
Enter the command in Cleanup command field, to match whether the command is deleted.
6. If you want to create an alarm message, specify the message name that is used to refer to the profile message.
7. Specify the alarm message text, for example, $profile: ($type / $severity) $text (at $time)
8. Define the severity level of the alarm message.
9. Specify subsystem id (SID) of alarms that the probe generates.
10. Specify if the message is a default message for this alarm situation.

You can create a profile to match the specified command or the regex in the QHST (history log message queue) messages. The probe reads the
messages from the QHST message files. Multiple profiles can match the same message. The system messages are located in QHST, related to
system failure, warning messages, security issues. You can create a profile from either the Profiles section or the Messages section. You can only
configure the fields in the profile that is created through Profiles section.
Note: The alarm messages and suppression key are configured for every profile.
Follow these steps:

1. Click the Options (icon) next to the Profiles node and select Add Profile.
2. Go to the Profiles section and provide the following field values:
Name of the profile.
Additional information to identify the objects that the profile monitors.
3. Click Submit.
4. In the General Configuration section, select Active to activate the profile.
5. In the Alarm Message section, specify a Name of the alarm that is generated when a message is recognized in the history log by the
probe.
6. Define the suppression key to avoid generating the same alarm multiple time, for the same situation.
7. In the Message properties section, enable the following values to specify the search criteria in the history log. If these values are not
enabled, the probe fetches the default value.
The job ID
The job name
The receiving program (RecvProg)
The sending program (SendProg)
The job sending the log messages (SendUser)
The alarm message text
The alarm message type
8. When matching: specify the job ID, job name, receiving program, sending program, job sending the log messages, alarm message text,
and alarm type. The probe matches the specified value in the history log. If the specified value is recognized, the probe raises an alarm.
The values can be new or you can select from the existing IDs. You can use regular expressions to specify the value. For more
9. Enable the alarm severity to indicate the severity code.
10. Specify the severity code. The probe raises an alarm when the specified severity is breached.

A regular expression (regex for short) is a special text string for describing a search pattern. You can use regular expressions in the probe to filter
the queues that are included in a profile. The probe matches the patterns to select the applicable job queues for monitoring.
The probe adds monitors in the queues that fulfill the criteria for all these fields. The * and ? symbols are wild card operators and denote that all
characters are acceptable. The * represents multiple characters while the ? represents exactly one character.
You can specify the regex in the Message Properties tab. The probes searches for this expression in the history log and if a match is found, it
generates an alarm. When the first term is found, the probe continues to search through the next lines for the second term. For example, to
search for all SYS Queue in the log file, you must specify it as *SYS*.
The following table describes some examples of regex and pattern matching for files using the history probe.
* or ?
Standard
Match all values
*a
Custom
Match all values that end with the letter a
a?
Standard
Match all two letter values that start with the letter a
*t*
Custom
Match all values with the
Alarm Thresholds
allow the probe to:
v1.0 history AC GUI Reference

This article describes the fields and features of the iSeries history (QHST Data Monitoring) probe.
History Node
Profiles Node
<Profile Name> Node
Messages Node
History Node
The history node allows you to view the probe and alarm message details and configure the log properties.
Navigation: history
history > Probe Information
history > Setup Configuration
This section lets you configure the log properties and the log file size of the history probe.
Default: 0-Fatal
Log Size (KB): specifies a maximum size of the probe log file.
Default: 100
Check Interval (Perform check each): specifies the time interval at which the job queue in the system is accessed.
Default: 600
Command on Interval: enables monitoring of the updated or deleted the commands in the retrieved history log file
Update Command: specifies the command the probe will match in the retrieved history log file to indicate if the command has been
updated.
Cleanup Command: specifies the command the probe will match in the retrieved history log file to indicate if the command has been
deleted.
history > Alarm Messages
This section lets you view the alarm messages and their properties.
Name: indicates the message name which is used to refer to the alarm message.
Subsystem: indicates the subsystem ID that the probe generates.
Default: indicates whether the message is the default message for this alarm situation.
Profiles Node
This node is used to create a monitoring profile. You can create multiple monitoring profiles, each with a different criteria to monitor the log files.
The new profiles are displayed as child nodes.
<Profile Name> Node

This node lets you configure the properties of the monitoring profile. A monitoring profile scans the log file and matches its criteria with the
messages. If a history message is found, an alarm is generated.
Navigation: history > Profiles > profile name
Set or modify the following values required:
profile name > General Configuration
This section enables you to edit the monitoring profile.
Description: defines a description of the profile.
profile name > Alarm Message
This section allows you to specify the alarm message and the message ID for the profile:
Use alarm message: specifies the alarm message.
Suppression key: defines the message ID for the alarm messages that are generated in same alarm situation.
profile name > Message Properties
This section lets you set the criteria that the profile uses to scan the messages in the log files. Only the enabled fields are included in the criteria.
For more information, see the Message Node section.
profile name > Alarm Configuration
This section lets you view the alarm properties for the configured profile.
Level: defines the alarm severity level.
Subsystem: indicates the subsystem_id that the probe generates.
Token: indicates whether the message is a default message.
Messages Node
This node displays a list of scanned messages from the latest log file.
Navigation: history > Message

Messages > Output Queue Details
This section lets you view the latest detected messages. The message properties are used to match the profiles to messages.
Date and time: indicates the arrival date and time of the job.
ID: indicates the ID of the message processing the job.
Job Name: indicates the name of the job that the probe will fetch in the history log.
Job Number: indicates the job number in the message.
Receiver Program: indicates the program receiving the job.
SendProg: indicates the program sending the job.
SendUser: indicates the user sending the job.
Severity: indicates the severity code associated with the message.
Type: indicates the message type, for example,
Completion
Diagnostic
Information
Inquiry
Copy
Escape (exception not handled at time of RCVMSG)
v1.0 history IM Configuration

This article contains configuration details specific to the history (iSeries QHST Data Monitoring) probe. You can configure this probe by creating
monitoring profiles. These profiles monitor the history of the log content for messages that are located in QHST (history log message queue).
The following diagram outlines the process to configure the history probe.
Configure the General Properties
Verify that required hardware and software is available before you configure the probe. For more information, see history (iSeries QHST Data
Configure the General Properties

This section enables you to set up the logging details of the probe. You can specify the interval at which the messages in the log file are updated
or deleted. You can also define the alarm settings when the probe finds a job match in the history logs.
Follow these steps:
2. Specify the time interval at which the queue in the history log is scanned for messages in the Check Interval in seconds field. Reduce
this interval to generate alarms frequently.

3. Select Command on interval to monitor if a command is updated or deleted in the retrieved log file, at the specified interval. The probe
monitors properties like Data and Type, Type, Job ID, Job Name, and Sender Program of the updated command.
Enter the command in the Update Command field, to match whether the command is updated.
Enter the command in Cleanup command field, to match whether the command is deleted.
4. In the Setup Configuration section, provide the following field values:
log level: specify the level of details that are written to the log file in the Log Level field.
Default: Log-level -0
when debugging.
log size: specify the maximum size of the probe log file.
Default: 100 KB
5. Specify the maximum size of the probe log file.
Default: 100 KB
6. In the Alarm messages section, right-click if you want to create a new message.
7. Enter the following details, to configure the properties of the alarm:
The alarm message name
The Alarm Message text, for example, $profile: ($type / $severity) $text (at $time)
The severity level of the alarm
The subsystem ID (SID) of alarms that the probe generates.
The default message for a particular alarm situation
If you want to set another message as default, leave this field empty.
8. Click OK.

You can create a profile and define the criteria to match it against QHST messages that are read from the QHST message files. When a match is
found, an alarm message is sent. You can create a profile from either the Profiles tab or the Messages tab. When you use the Messages tab to
create a profile, the fields are auto-populated and are editable. But when you create a profile using the Profiles tab, the fields are left blank.
The following commands are available when you right-click in the profile tab:
New
Create a profile, and configure the profile properties
Edit
Edit the existing profile properties.
Delete
Delete the existing profile.
A confirmation message is displayed to confirm this operation.
Follow these steps:

1. Click the Profiles tab, right-click, and select New.
3. Enter additional information to identify the objects that the profile monitors in Description field.
4. In the Message properties tab, enable the following values to specify the search criteria in the history log. If these values are not
enabled, the probe fetches the default value.
The job ID
The job name
The receiving program (RecvProg)
The sending program (SendProg)
The job sending the log messages (SendUser)
The alarm message text
The alarm message type
When Matching: specify the job ID, job name, receiving program, sending program, job sending the log messages, alarm message
text, and alarm type. The probe matches the specified value in the history log. If the specified value is recognized, the probe raises an
alarm. The values can be new or you can select from the existing IDs. You can use regular expressions to specify the value. For more
Important! These values are checked against all QHST messages to determine if a match is found in the logs. All the
selected fields must match for the profile to send an alarm. Regular expressions can be used in all fields except Severity.
5. Enable the alarm severity to indicate the Severity code.

6. Specify the severity code. The probe raises an alarm when the specified severity is breached.
7. In the Alarm tab, specify the Use message to determine the alarm message that must be used when the alarm condition arises.
If nothing is selected, the default message is used.
8. Define the Suppression key that is used by NAS to define the suppression key to avoid generating an alarm multiple time for the same
situation.
Leave this field empty if you want the NAS to send alarms with default suppression key.
9. Click OK.
Note: To create a profile through the Messages tab, right click and select Create Profile.

A regular expression (regex for short) is a special text string for describing a search pattern. You can use regular expressions in the probe to filter
the queues that are included in a profile. The probe matches the patterns to select the applicable job queues for monitoring.
The probe adds monitors in the queues that fulfill the criteria for all these fields. The * and ? symbols are wild card operators and denote that all
characters are acceptable. The * represents multiple characters while the ? represents exactly one character.
You can specify the regex in the Message Properties tab. The probes searches for this expression in the history log and if a match is found, it
generates an alarm. When the first term is found, the probe continues to search through the next lines for the second term. For example, to
search for all SYS Queue in the log file, you must specify it as *SYS*.
The following fields in the Message Properties tab support regular expressions:
When matching (Queue Name)

When matching (Queue Library)
When matching (Active Status)
When matching (Subsystem)
When matching (Subsystem Library)
The following table describes some examples of regex and pattern matching for files using the history probe.
* or ?
Standard
Match all values
*a
Custom
Match all values that end with the letter a
a?
Standard
Match all two letter values that start with the letter a
*t*
Custom
Match all values with the letter t in between
v1.0 history IM GUI Reference

The history probe is configured by double-clicking the line representing the probe in the Infrastructure Manager. This brings up the configuration
tool for the probe. The configuration tool for the probe displays, the Setup tab, the Profiles tab and the Messages tab. This article describes the
fields and features of the history probe.
The Setup Tab

The Profiles Tab
Message properties
The Messages tab
The Setup Tab

Perform check each: Specifies the time interval at which the logs are scanned for new messages.
The optional Command on interval runs before the scan and will typically be a DSPLOG command to force current messages in
QHST (history log message queue) to be written to the log files.
Command on interval: Updates or deletes the existing messages or commands in the history log at the specified check interval.
Update Command: specifies the command that the probe updates in the QHST at the specified interval.
Cleanup Command: specifies the cleanup command that the probe runs to delete or update the messages from the history log at the
specified interval.
Log level: Specifies the level of detail written to the probe log file.
Default: 0-Fatal
debugging.
Log size: Specifies the size of the probe log file to which the internal log messages of the probe are written. When this size is reached,
new log file entries are added and the older entries are deleted.
Default: 100 KB.
Alarm messages
Specifies the message, which is generated when a threshold is breached. You can create your own messages with the message text and
severity level you desire. The following options are available in the right-click menu for the message list.
New Alarm Window
You can create a new alarm message. The following variables are available for the alarm message:
Name
Specifies a name for the job.
Text
Specifies the Alarm Message text.
Variable expansion is supported for this field. The following variables are available in the message text:
profile
time
severity
text
type
Level
Specifies the severity level of the alarm.
Subsystem
The subsystem ID (SID) of alarms generated by this probe. The string or the id managed by NAS.
Default Alarm Situation
The message can be made the default message for a particular alarm situation.
You must leave this field empty if another message is to be the default.
Edit: modifies fields of an existing alarm message.
Delete: removes the selected alarm message.
The Profiles Tab

The Profiles Tab displays all the configured monitoring profiles. Each profile is matched against QHST (history log message queue) messages,
which are read from the QHST message files. The properties dialog of a profile defines the criteria for when a message matches and an alarm
message is sent.
New Profile Window
The profile properties are as follows:

Name: specifies the name of the profile.
Description: defines additional information to identify what objects are monitored by the profile.
You can configure the message selection criteria using the Message properties tab and alarm properties using the Alarm tab.
Message properties
These values are checked against all QHST messages read to determine if the profile matches the message. All checked fields must match for
the profile to match and an alarm to be sent.
Regular expressions can be used in all fields except Severity.
ID: enables the job ID.
Job: enables the job name.
RecvProg (Receiving program name): specifies the receiving program in the history log.
SendProg (Sending program name): specifies the sending program in the history log.
Severity: specifies the alarm severity code.
Text Message text: specifies the Message type.
Alarm Tab
Use message: specifies the alarm message that is used when a threshold is breached. The default message will be used, if no alarm
message is selected.
Suppression key: specifies the suppression key is used by NAS to determine which messages describe the same alarm situation.
Leave this field empty if you want the nas to just use the alarm message text.
The Messages tab

The Messages tab of the probe GUI displays the messages from the log currently being scanned, which will be the newest log.
The following fields are displayed:

Date and time: specifies the date and time,when the job was generated.
ID: specifies the ID of the message processing the job.
Job name: specifies the name of job name.
Job number: specifies the job number.
Receiver program: specifies the name of the program receiving the job.
Sender program: specifies the name of the program sending the job.
Send user: specifies the user sending the job
Severity: specifies the severity code, between 00 and 99
Text: specifies the alarm message text.
Type: specifies the message type, which can be one of the following:
Completion
Diagnostic
Information
Inquiry
Escape (exception not handled at time of RCVMSG)
You may create profiles to match to the messages as they are read from the logs.
hitachi (Hitachi Storage Monitoring)

The hitachi probe handles all common monitoring and data collection tasks for the following storage arrays:
Hitachi USP_V
Hitachi USP_VM
Hitachi Adaptable Modular Storage (AMS)
Hitachi Unified Storage (HUS)
Hitachi Virtual Storage Platform (VSP)
Hitachi USP_V and USP_VM Series are disk storage solutions for small and large enterprises.
Hitachi AMS is a family of block storage systems for targeting the mid-tier enterprise market. A single system can manage as much as 1,417
Terabytes (TB) of storage.
Hitachi replaces its mid-range AMS storage array with the Hitachi Unified Storage (HUS) family of systems. These devices allow you to manage
block, file, and object data in a highly scalable and cost-efficient manner. A single system can manage almost 3 Petabytes (PB) of storage.
The hitachi probe uses an SMI-S interface to communicate with the Hitachi storage system arrays. You must install the SMI-S provider to enable
communication between the probe and the storage system.
Storage Array
Storage Pools
Thin Provisioning Pools
Array Groups
Components
Logical Volumes
Disks
More information:
hitachi (Hitachi Storage Monitoring) Release Notes
v2.0 hitachi AC Configuration

The hitachi probe is configured to enable and configure the monitoring checkpoints of Hitachi storage systems. The probe must establish a
communication link between the probe and the storage system to configure the system's resource.
The following diagram outlines the process to configure the hitachi probe.
Add Profile
Define an Array for Monitoring
Add a Monitor
Add Monitors Manually
Alarm Thresholds
information, see hitachi (Hitachi Storage Monitoring) Release Notes.
Add Profile
You can add a monitoring profile to connect to the SMI-S server. The hitachi probe also collects and stores data and information from the
monitored components.
Follow these steps:
2. Click the Options (icon) next to the hitachi node in the navigation pane.
4.
4. Specify the Hostname or the IP address of the Hitachi storage system.

5. Specify the Username and Password to access the SMI-S provider.
6. Define the Port on which the SMI-S provider is listening. and the time interval for checking the value of the monitors.
7. Click Submit.
The IP address of the resource is displayed under the hitachi node. The state of the resource (pending, successful or failure) is displayed
under the node.
Note: The profile goes into pending state to retrieve the data for the specified host.
8. Click the <profileName> node.

9. Click Verify Selection from the Actions drop-down.
A connection is established and the authentication details are verified.
10. Click Save.
Define an Array for Monitoring

1. Click the <profileName> node.
A list of available disk arrays for the hitachi server is displayed as checkboxes.
2. Select the required array(s) to be monitored.
3. Click Save.
The profile saves the monitoring categories of the array display as sub-nodes.
4. Configure the monitors for the required nodes. For more details, refer to Add a Monitor section.
Add a Monitor
You can manually add monitors to the templates for the probe to retrieve the required alarms and QoS data.

You can manually add a monitor to be measured by the probe by selecting it from the defined list.
Follow these steps:
1. Select a resource in the left pane.
2. Click the check box for the monitor that you want to add.
3. Click Enable Monitoring in the Monitor Properties dialog.
4. Edit the monitor properties, and click OK.
Refer Edit Monitor Properties for more information.
5. Click Apply to configure the settings.
6. Click OK to restart the probe when prompted.
The Monitor Properties dialog lets you define the thresholds for generating alarms. You can also configure the QoS messages.
Follow these steps:
1. Click the array component in the left pane.
The list of monitors is displayed in the right pane.
2. Double-click the required monitor.
You can also right-click the monitor and select Edit from the menu.
3. Enter the following information in the Monitor Properties dialog:
Monitor name.
3.
The type and property of the component.
A description about the monitor.
The type of value to be compared with the threshold value for generating alarms. This value type is also used in the QoS messages.
Number of samples to use for the average value option in the Value Definition field.
The maximum number of samples is 4.
4. Select the checkbox to activate the fields for configuring Alarms and QoS.
5. Enable the Operator, Threshold, Unit, and Message ID fields for configuring the alarms. You can configure both high and low thresholds.
The low threshold generates a warning alarm and the high threshold generates an error alarm.
Note: By default, the high threshold is set to a default value or the current value and the low threshold is disabled.
6. Enable the QoS Name drop-down list, which specifies the QoS message that the monitor can generate.
7. Click OK and Apply to configure the settings.
The configuration properties of the monitor are saved for the probe to generate alarms and QoS messages.
Alarm Thresholds
allow the probe to:
v2.0 hitachi AC GUI Reference

This article describes the Admin Console interface and fields to configure the hitachi (Hitachi Storage Monitoring) probe.
hitachi Node
<Resource IP Address> Node
<IP Address> Node
Arrays Node
<Array Name> Node
hitachi Node
The hitachi node displays the probe information and enables you to configure the log settings of the probe.
Navigation: hitachi
hitachi > Probe Information
hitachi > Probe Setup
This section enables you to configure the default log level for the probe.
Default: 3 - Info
debugging.

The Resource IP Address node enables you to view and update the resource connection properties. The resource properties are the resource IP
address, port, and user authentication details.
Navigation: hitachi > Resource IP Address
IP Address > Resource Setup
This section enables you to edit the resource properties, which are configured while creating a profile.
Hostname: defines the host name or the IP address of the Hitachi storage system.
Port: defines the port number on which the SMI-S provider is listening.
Default: 443
Interval (secs): specifies the time interval after which the probe checks the values of the monitors.
Default: 600
Username: defines the user account for accessing the SMI-S provider.
Password: defines the password for the specified username.
Alarm Message: specifies the alarm message that is generated when the probe is unable to connect with the Hitachi storage system.
Use SSL: allows the probe to use HTTPS to connect to the Hitachi storage system.
NameSpace: identifies the namespace that is supported by the Device Manager and the SMI-S version.
<IP Address> Node

The IP Address node is used to configure the monitors of the Hitachi storage system. The monitors generate alarm and QoS messages for the
required monitoring category. The monitors enable the probe to retrieve data about the monitored storage system which is classified as follows:
Discovery Data: retrieves information about the connection between the probe and the storage system.
Configuration Data: retrieves information about the storage system classification. For example, the number of arrays and other
components.
Statistical Data: retrieves statistical information about all components of the storage system. For example, total IO operations, and
number of arrays with low disk space.
You can configure the following monitors from this node.
AdapterType
Build
Caption
CimomVersion
Configuration
Dedicated
Discovery
ElementName
EnabledDefault
GatherStatisticalData
InstallDate
OperationalStatus
PortNumber
ProtocolType
SecurePortNumber
Started
StartMode
Statistics
Status
Version
Navigation: hitachi > Resource IP Address > IP Address
IP Address > AdapterType
This section configures the AdapterType monitor of the Hitachi storage system.
Units: identifies a unit of the monitor. For example, % and Mbytes
Metric Type ID: identifies the unique identification number of the monitor.
Value Definition: specifies the value type that is compared with the threshold value and generates alarms. The specified value type is
also used in the QoS messages.
Select from the following values:
Current Value
Average Value Last Samples
Delta Value (Current - Previous)
Delta Per Second
Number of Samples: defines the number of samples to calculate the average value. This field appears only for those monitors where
the Value Definition field is enabled.
High Operator: specifies the operator to validate the alarm threshold value. For example, >= 90 means the monitor generates an alarm if
the measured value is more than 90.
High Threshold: defines the threshold value for comparing the actual value.
HighMessage Name: specifies the alarm message that is generated when the threshold value breaches.
Notes:
Similarly you can configure Low Operator, Low Threshold, and Low Message Name.
Typically, the low threshold generates a warning alarm and the high threshold generates an error alarm.
Arrays Node
The Arrays node is used to classify the list of arrays that are available in the Hitachi storage system.
Navigation: hitachi > Resource IP Address > IP Address > Arrays>
<Array Name> Node

The Array Name node represents the actual name of the array which is available in the Hitachi storage system. This node contains list of
monitors that can be configured. Select any monitor and configure its properties as mentioned in the IP Address node.
Navigation: hitachi > Resource IP Address > IP Address > Arrays> Array Name
The Array Name node also contains the following sub nodes that represent array elements:
Array Groups
Components
Disks
Dynamic Provisioning Pool
External Storage
Hosts
Logical Units
Service Processors
Storage Pools
Unconfigured Logical Units

These array element nodes further contain sub nodes to configure monitors of different sections of an element. All the element nodes and their
corresponding sub nodes contain only the Monitors section.
v2.0 hitachi IM Configuration

This section describes the configuration concepts and procedures for setting up the hitachi probe. The probe configuration lets you:
Define the Hitachi storage resource for monitoring.
Configure the monitors to retrieve the required alarms and data.
tampered.
The following diagram outlines the process to configure the hitachi probe to collect QoS data for Hitachi storage systems.
Create or Edit Resources
Define an array to be monitored
Add a Monitor
Use Templates
information, see hitachi (Hitachi Storage Monitoring) Release Notes.
Create or Edit Resources

The probe uses resources to connect to the SMI-S server. The hitachi probe also collects and stores data and information from the monitored
components. You require to create or edit a resource if you add or modify SMI-S servers.
Follow these steps:

1. To create or edit a resource, perform one of the following steps:
Click the Create New Resource icon on the toolbar.
Right-click the All Resources node in the left pane and select New Resource from the menu.
To edit the properties for an existing resource, right-click it in the left pane, then select Edit from the menu.
2. Enter or edit the following information in the Register Resource dialog:
Hostname or IP address for accessing the Hitachi storage system.
The port on which the SMI-S provider is listening.
The default port is 433 for HTTP, and 5989 for HTTPS.
Activate the resource.
The user account for accessing the SMI-S provider and the command-line interface.
The password for the user account.
The alarm message to be issued when the probe is not able to connect with the resource.
The time interval for the probe for retrieving the updated value of the monitors.
The root/current as the namespace for the Hitachi storage system.
Enable the probe to connect with the resource over a secured protocol.
3. Click the Test button to verify connectivity to the SMI-S provider. A dialogue box is displayed, if the connection is successful.
The probe also displays a list of connected Hitachi storage system arrays in the Connected Arrays field.
Define an array to be monitored

You can select the array that you want to monitor. Only the selected arrays are displayed in the in the probe user interface.
1. Click the Test button.
The probe discovers and displays all the Hitachi systems that are connected to the server.
The systems are presented in the Connected Arrays list.
2. Select the array to be monitored.
The probe adds the hitachi resource under the Resources node of the probe and lets you monitor the selected arrays of that resource.
Add a Monitor
You can add monitors to the templates, to retrieve the required alarms and data. There are three ways to add monitors:
Add manually - Select monitors from the defined list
Use templates - Define reusable sets of monitors to use with auto configurations
Use Auto Configurations - Apply monitor templates to all components of a resource

You can manually add a monitor to be measured by the probe, by selecting it from a list.
Follow these steps:
1. Select a resource in the left pane.
2. Click the check box next to the monitor you want to add.
3. Click Enable Monitoring in the Monitor Properties dialog.
Note: The Monitor Properties dialog lets you define the thresholds for generating alarms. You can also configure the QoS
messages by editing the monitor properties.
4.
4. Edit the monitor properties, and click OK.

Refer Edit Monitor Properties for more information.
Edit a Monitor
You can edit an existing monitor to be measured by the probe.
Follow these steps:
1. Click the component in the left pane.
The list of monitors is displayed in the right pane.
2. Double-click the required monitor.
Note: You can also right-click the monitor and select Edit from the menu.
3. Enter the following information in the Monitor Properties dialog:

The name of the monitor.
The type and property of the array component.
A short description about the monitor.
The type of value for comparing it with the threshold value and generate alarms. This value type is also used in the QoS messages.
Number of samples to use for the average value last option in the Value Definition field.
The maximum number of samples is 4.
4. Activate the fields for configuring Alarms and QoS.
5. Enable the Operator, Threshold, Unit, and Message ID fields for configuring the alarms. You can configure both high and low thresholds.
The low threshold generates a warning alarm and the high threshold generates an error alarm.
Note: Initially the high threshold is set to a default value or the current value and the low threshold is not enabled.
6. Select the s checkbox to enable the QoS Name drop-down list, which specifies the QoS message that the monitor can generate.
The configuration properties of the monitor take effect to enable the probe for generating alarms and QoS accordingly.
Use Templates
Templates are reusable sets of monitors with pre-configured monitoring properties. You can create templates and can apply its monitors to auto
configurations by dragging-and-dropping them on the Auto Configurations node. The probe applies the template monitors to all relevant
components of a resource. The probe also displays all the monitors, where the template is applied in the Auto Monitor node.
You can create a new template or can edit the settings for an existing template. Template defines the monitors and their monitoring parameters,
which is applied to the resource.
Follow these steps:
1. Do one of the following actions:
Click the Create New Template icon in the toolbar.
Right-click the Templates node in the left pane, then select New Template from the menu.
To edit an existing template, right-click a template under the Templates node in the left pane, then select Edit from the menu.
2. Enter a name and description in the Template Properties dialog and click OK.
3. Add the monitors (checkpoints) by doing one of the following actions:
Drag-and-drop the monitors from the right pane onto the template node in the left pane.
3.
Right-click on a monitor, then select Add to Template from the menu.
4. Edit the monitor properties, as required. Refer Edit Monitor Properties for more information.
Click the Active and Enable Monitoring check boxes in the Monitor Properties dialog, to monitor the collected data.
5. Drag-and-drop the template monitor on the Auto Configurations node for applying the monitor to the resource.

The auto configurations feature automatically applies monitors to all components of a resource. Add monitors and templates to the Auto
Configurations node of a resource for applying them to the resource. To view the monitors or templates added to the Auto Configurations node,
click the Auto Configurations node in the left pane. To edit the properties for the templates or monitors, right-click in the list and choose Edit fro
m the menu. Refer Edit Monitor Properties for more information. To delete a template or monitor from the list, right-click in the list and choose Del
ete from the menu.
Important! Do not add multiple monitors or templates to the Auto Configurations node. This can overburden the system.
The auto configurations feature is implemented through two sub nodes of the All Resources node in the left pane:
Auto Configurations Node: Lists the applied template monitors and individual monitors for the resource. The probe searches through the
resources and applies relevant monitors to its components.
Auto Monitors Node: Lists the auto monitors for the resource. The properties of these monitors are inherited from the applied template
monitors of the Auto Configurations node.
Add a Template Monitor to Auto Configurations
You can add a template monitor to the Auto Configurations node of a resource. This process applies the monitor with preconfigured monitoring
properties to all components of the resource.
Follow these steps:
1. Click the Templates node in the left pane.
The list of templates is displayed in the right pane.
2. Select the template you want to monitor from the right pane.
3. Drag-and-drop the selected template monitor from the right pane onto the Auto Configurations node.
4. Click the Auto Configurations node and verify that the template monitor is listed in the right pane.
5. Click Apply.
The template monitor is applied to all components of the resource.
Add a Monitor to Auto Configurations
You can add a single monitor to the Auto Configurations node of a resource to apply the monitor to all components of a resource.
Follow these steps:
1. Expand the All Resources node in the left pane and click on a component for listing the available monitors.
2. Drag-and-drop the monitor from right pane onto the Auto Configurations node.
3. Click the Auto Configurations node and verify that the monitor is listed.
4. Configure the monitor properties. Refer Edit Monitor Properties for more information.
5. Click Apply.
v2.0 hitachi IM GUI Reference

This article describes the fields and features of the Infrastructure Manager of the hitachi probe. The probe GUI consists of a toolbar and a window
with two panes. In addition, a status bar displays version information and last start time of the probe.
Contents
The Left Pane

Resources Node
Templates Node
The Right Pane
The Tool Buttons
General Setup
New Resource
Template Properties
The Left Pane

The left side pane displays the list of resources and templates, which are added to the probe for monitoring. The resources and templates
consists of:
Resources: List of all devices, auto configurations, and monitors.
Templates: List of sample templates.
You can select a node to view details in the content pane. The left pane also displays the context menu for performing certain tasks on the
selected node.
Resources Node
The Resources node displays a list of Hitachi resources which are configured in the probe for monitoring. Each resource is an SMI-S provider that
discovers the Hitachi storage systems and provides a connection to them. The resource lets the probe to collect and store data for the monitored
components. The Resources node also displays the connection status for each resource:
= Connection to the host is available.
= System is not available.
= System is trying to connect.
Resource IP Address
The System node for the Hitachi storage system has the following nodes:
Auto Configurations: configures the unmonitored devices automatically. You can add one or more checkpoints (or templates) to this
node using drag-and-drop feature.
Auto Monitors: lists the auto monitors created for previously unmonitored devices that are based on the contents of the Auto
All Monitors: lists all monitors either defined by an auto configuration or by an auto monitor.
Arrays: displays the array equipment hierarchy of a Hitachi storage system. You can view directors, disks, device pools, devices, and
other physical elements of the Hitachi storage system.
Templates Node
The Templates node displays a list of monitoring templates, which contain a list of monitors with their corresponding monitoring properties. You
can drag-and-drop a template monitor on a resource for applying the monitor properties and start monitoring the resource.
The probe contains the following default templates:

Logical Volume Monitors
Status Monitors
Disk Monitors
Port Monitors
Array Group Monitors
Pool Monitors
Array Monitors
Default Auto Configuration
The Right Pane

The content of the right pane depends on the current selection in the navigation pane:
If you select a resource in the navigation pane, the content pane lists its monitors. The following icons can appear in the content pane:
= A monitor where no value has yet been measured.
Black = The monitor is NOT activated for monitoring. This icon also means that the Enable Monitoring option is not selected in
the Monitor Properties dialog for the monitor. Refer Edit Monitor Properties in v2.0 hitachi IM Configuration.
Green = The monitor is activated for monitoring, and the threshold value that is defined in the properties dialog for the monitor is
not exceeded.
Alarm Severity Colors = The monitor is activated for monitoring, and the threshold value that is defined in the properties dialog for
the monitor is exceeded. The color reflects the Message ID selected in the Monitor Properties dialog for the monitor.
If you select the Templates node in the navigation pane, the content pane lists Template definitions.
Right-click the content pane and it opens a context menu. The menu items are self-explanatory (New, Edit, Activate, and Rename) for managing
the selected object.
Note: When a monitor is selected, the Refresh menu item refreshes the display only and not the updated values. The new values are
retrieved after the poll interval of the selected resource.
The Tool Buttons

The probe GUI contains a toolbar with following tool buttons:
General Setup
New Resource
Create New Template
General Setup
Clicking the General Setup button opens the Probe Settings dialog, which contains the following items:
Log-level
This sets the level of details written to the log file. Log as little as possible during normal operation to minimize disk consumption.
0= Fatal
1= Error
2= Warn
3= Info
4= Debug
5= Trace
New Resource
You can click on the New Resource tab and update the following fields to add a new resource to the resource list.
Hostname or IP address: defines the host name or the IP address of the Hitachi storage system.
Port: defines the port number on which the SMI-S provider is listening.
Default: 443
Username: defines the user account for accessing the SMI-S provider.
Password: defines the password for the given username.
Alarm Message: specifies the alarm message to issue when the probe is unable to connect with the Hitachi storage system.
Check Interval: specifies the time interval before the next log scans for new messages.
Default: 10
Namespace: identifies the namespace that is supported by the Device Manager and the SMI-S version.
Use SSL: allows the probe to use HTTPS for connecting the Hitachi storage system.
Organizations: allows you to select all arrays that are to be monitored. Select test to update.
You can open the Pool Manager by clicking the Message Pool Manager button in the Tool bar. You can view the list of alarm messages that are
available for the hitachi probe.
Message ID: identifies the alarm message.
Message Text Error: specifies the message content.
Message Text Ok: specifies the clear alarm message text.
The alarm messages for each alarm situation are stored in the Message Manager. Right-clicking in the list allows you to customize an alarm text,
and to create and remove messages.
Template Properties
You can create a new template by clicking on the Create New Template tab in the tool bar. The new template will be displayed under the
Templates node:
Name: defines a name of the template.
Description: gives a short description of the template.
hitachi Metrics
This section contains the QoS metrics for the Hitachi Storage Monitoring (hitachi) probe.
QoS Monitor
Unit
Description
Version
QOS_STORAGE_ARRAYGROUP_BLOCK_SIZE
Bytes
Array Group Block Size
v1.0
QOS_STORAGE_ARRAYGROUP_CAPACITY
Gigabytes
Array Group Total Capacity in Gigabytes
v1.0
QOS_STORAGE_ARRAYGROUP_CAPACITY_FREE_PERCENT
Percent
Array Group Percent Used Capacity
v1.0
QOS_STORAGE_ARRAYGROUP_CAPACITY_USED_PERCENT
Percent
Array Group Percent Free Capacity
v1.0
QOS_STORAGE_ARRAYGROUP_CONSUMABLE_BLOCKS
Blocks
Array Group Consumable Capacity in Blocks
v1.0
QOS_STORAGE_ARRAYGROUP_CONSUMABLE_CAPACITY
Gigabytes
Array Group Consumable Capacity in Capacity
v1.0
QOS_STORAGE_ARRAYGROUP_NUMBER_OF_BLOCKS
Blocks
Array Group Total Capacity in Blocks
v1.0
Array Group Status [Unknown(0), Other(1), OK(2),

Degraded(3), Stressed(4), Predictive Failure(5), Error(6),
Non-Recoverable Error(7), Starting(8), Stopping(9),
Stopped(10), In Service(11), No Contact(12), Lost
Communication(13), Aborted(14), Dormant(15),
Supporting Entity in Error(16), Completed(17)]
v1.0
QOS_STORAGE_ARRAYGROUP_OPERATIONAL_STATUS
QOS_STORAGE_ARRAYGROUP_REMAINING_MANAGED_SPACE
Gigabytes
Array Group Free Capacity
v1.0
QOS_STORAGE_ARRAYGROUP_TOTAL_MANAGED_SPACE
Gigabytes
Array Group Total Capacity
v1.0
QOS_STORAGE_ARRAYGROUP__EXTENT_STRIPE_LENGTH
Count
Array Group Extent Stripe Length
v1.0
QOS_STORAGE_ARRAY_BLOCK_SIZE
Bytes
Array Cache Block Size
v1.0
QOS_STORAGE_ARRAY_CAPACITY_FREE_PERCENT
Percent
Array Percent Free Capacity
v1.0
QOS_STORAGE_ARRAY_CONSUMABLE_BLOCKS
Blocks
Array Cache Consumable Capacity in Blocks
v1.0
QOS_STORAGE_ARRAY_KBYTES_TRANSFERRED
KB
Array Kbytes Transferred in the sample period
v1.0
QOS_STORAGE_ARRAY_KBYTES_TRANSFERRED_RATE
KB/Sec
Array Kbytes Transferred Rate in the sample period
v1.0
QOS_STORAGE_ARRAY_NUMBER_OF_BLOCKS
Blocks
Array Cache Total Capacity in Blocks
v1.0
Array Status [Unknown(0), Other(1), OK(2),

v1.0
QOS_STORAGE_ARRAY_OPERATIONAL_STATUS
QOS_STORAGE_ARRAY_READ_HIT_IOS
Count
Array Read Hit IOs in the sample period
v1.0
QOS_STORAGE_ARRAY_READ_IOS
Count
Array Read IOs in the sample period
v1.0
QOS_STORAGE_ARRAY_READ_IOS_RATE
Count/Sec
Array Read IOs Rate in the sample period
v1.0
QOS_STORAGE_ARRAY_REMAINING_MANAGED_SPACE
Gigabytes
Array Remaining Managed Space
v1.0
QOS_STORAGE_ARRAY_TOTAL_IOS
Count
Array Total IOs in the sample period
v1.0
QOS_STORAGE_ARRAY_TOTAL_IOS_RATE
Count/Sec
Array Total IOs Rate in the sample period
v1.0
QOS_STORAGE_ARRAY_TOTAL_MANAGED_SPACE
Gigabytes
Array Total Managed Space
v1.0
QOS_STORAGE_ARRAY_WRITE_HIT_IOS
Count
Array Write Hit IOs in the sample period
v1.0
QOS_STORAGE_ARRAY_WRITE_IOS
Count
Array Write IOs in the sample period
v1.0
QOS_STORAGE_ARRAY_WRITE_IOS_RATE
Count/Sec
Array Write IOs Rate in the sample period
v1.0
QOS_STORAGE_ARRAY__PERCENT_USED_CAPACITY
Percent
Array Percent Used Capacity
v1.0
QOS_STORAGE_ARRAY__SAMPLE_INTERVAL
Seconds
Array Sample interval for performance data
v1.0
Component Status [Unknown(0), Other(1), OK(2),

v1.0
QOS_STORAGE_COMPONENT_OPERATIONAL_STATUS
QOS_STORAGE_DISK_BLOCK_SIZE
Bytes
Disk Block Size
v1.0
Gigabytes
Disk Total Capacity in Gigabytes
v1.0
QOS_STORAGE_DISK_CONSUMABLE_BLOCKS
Blocks
Disk Consumable Capacity in Blocks
v1.0
QOS_STORAGE_DISK_CONSUMABLE_CAPACITY
Gigabytes
Disk Consumable Capacity in Capacity
v1.0
QOS_STORAGE_DISK_NUMBER_OF_BLOCKS
Blocks
Disk Total Capacity in Blocks
v1.0
Disk Status [Unknown(0), Other(1), OK(2), Degraded(3),

Stressed(4), Predictive Failure(5), Error(6),
v1.0
QOS_STORAGE_DISK_OPERATIONAL_STATUS
QOS_STORAGE_EXTVOL__CAPACITY
Gigabytes
External Volume Total Capacity in Gigabytes
v1.0
QOS_STORAGE_EXTVOL__CONSUMABLE_CAPACITY
Gigabytes
External Volume Consumable Capacity in Gigabytes
v1.0
QOS_STORAGE_LU__A_F_S_P_SPACE_CONSUMED
Gigabytes
LUN AFSP Space Consumed
v1.0
QOS_STORAGE_LU__REMAINING_MANAGED_SPACE
Gigabytes
LUN Remaining Managed Space
v1.0
QOS_STORAGE_LU__SAMPLE_INTERVAL
Seconds
LUN Sample interval for performance data
v1.0
LUN SS Extent Stripe Length
v1.0
QOS_STORAGE_LU__S_S_EXTENT_STRIPE_LENGTH
QOS_STORAGE_LU__S_S_USER_DATA_STRIPE_DEPTH
LUN SS User Data Stripe Depth
v1.0
QOS_STORAGE_LU__S_V_BLOCK_SIZE
Bytes
LUN SV Block Size
v1.0
QOS_STORAGE_LU__S_V_CONSUMABLE_BLOCKS
Blocks
LUN SV Consumable Blocks
v1.0
QOS_STORAGE_LU__S_V_NUMBER_OF_BLOCKS
Blocks
LUN SV Number Of Blocks
v1.0
QOS_STORAGE_POOL_CAPACITY_FREE_PERCENT
Percent
Storage Pool Percent Free Capacity
v1.0
QOS_STORAGE_POOL_CAPACITY_USED_PERCENT
Percent
Storage Pool Percent Used Capacity
v1.0
Storage Pool Status [Unknown(0), Other(1), OK(2),

v1.0
QOS_STORAGE_POOL_OPERATIONAL_STATUS
QOS_STORAGE_POOL_REMAINING_MANAGED_SPACE
Gigabytes
Storage Pool Free Capacity
v1.0
QOS_STORAGE_POOL_TOTAL_MANAGED_SPACE
Gigabytes
Storage Pool Total Capacity
v1.0
QOS_STORAGE_PORT_KBYTES_TRANSFERRED
KB
Port Kbytes Transferred in the sample period
v1.0
QOS_STORAGE_PORT_MAX_SPEED
Hz
Port Maximum Speed
v1.0
QOS_STORAGE_PORT_OPERATIONAL_STATUS
Port Status [Unknown(0), Other(1), OK(2), Degraded(3),

v1.0
QOS_STORAGE_PORT_PORT_NUMBER
Port Number
v1.0
QOS_STORAGE_PORT_PORT_TYPE
Port Type
v1.0
QOS_STORAGE_PORT_SPEED
Hz
Port Speed
v1.0
QOS_STORAGE_PORT_TOTAL_IOS
Count
Port Total IOs in the sample period
v1.0
QOS_STORAGE_PORT__SAMPLE_INTERVAL
Seconds
Port Sample interval for performance data
v1.0
QOS_STORAGE_RES_CONFIGURATION_EXECUTION_TIME
Seconds
Time to Execute Configuration Command Group
v1.0
QOS_STORAGE_RES_DISCOVERY_EXECUTION_TIME
Seconds
Time to Execute Discovery Command Group
v1.0
QOS_STORAGE_RES_STATS_EXECUTION_TIME
Seconds
Time to Execute Statistics Command Group
v1.0
Controller Status [Unknown(0), Other(1), OK(2),

v1.0
QOS_STORAGE_SP_OPERATIONAL_STATUS
QOS_STORAGE_THINPOOL__A_F_S_P_SPACE_CONSUMED
Gigabytes
Thin Storage Pool AFSP Space Consumed
v1.0
QOS_STORAGE_THINPOOL__PERCENT_FREE_CAPACITY
Percent
Thin Storage Pool Percent Free Capacity
v1.0
QOS_STORAGE_THINPOOL__PERCENT_SUBSCRIBED
Percent
Thin Storage Pool Percent Subscribed
v1.0
QOS_STORAGE_THINPOOL__PERCENT_USED_CAPACITY
Percent
Thin Storage Pool Percent Used Capacity
v1.0
QOS_STORAGE_THINPOOL__REMAINING_MANAGED_SPACE
Gigabytes
Thin Storage Pool Free Capacity
v1.0
QOS_STORAGE_THINPOOL__SPACE_LIMIT
Gigabytes
Thin Storage Pool Space Limit
v1.0
QOS_STORAGE_THINPOOL__SUBSCRIBED_CAPACITY
Gigabytes
Thin Storage Pool Subscribed Capacity
v1.0
Thin Storage Pool SS Changeable Type
v1.0
QOS_STORAGE_THINPOOL__S_S_CHANGEABLE_TYPE
QOS_STORAGE_THINPOOL__S_V_BLOCK_SIZE
Bytes
Thin Storage Pool Block Size
v1.0
QOS_STORAGE_THINPOOL__S_V_CONSUMABLE_BLOCKS
Blocks
Based on Underlying redundancy
v1.0
QOS_STORAGE_THINPOOL__S_V_NUMBER_OF_BLOCKS
Blocks
Thin Storage Pool Number of Blocks
v1.0
QOS_STORAGE_THINPOOL__S_V_USAGE
Gigabytes
Thin Storage Pool SV Usage
v1.0
QOS_STORAGE_THINPOOL__THIN_PROVISION_META_DATA_SPACE
Gigabytes
Thin Storage Pool MetaDataSpace
v1.0
QOS_STORAGE_THINPOOL__TOTAL_MANAGED_SPACE
Gigabytes
Thin Storage Pool Total Capacity
v1.0
QOS_STORAGE_VOL_BLOCK_SIZE
Bytes
LUN Block Size
v1.0
QOS_STORAGE_VOL_CAPACITY
Gigabytes
LUN Total Capacity in Gigabytes
v1.0
QOS_STORAGE_VOL_CONSUMABLE_BLOCKS
Blocks
LUN Consumable Blocks
v1.0
QOS_STORAGE_VOL_CONSUMABLE_CAPACITY
Gigabytes
LUN Consumable Capacity in Gigabytes
v1.0
QOS_STORAGE_VOL_CONSUMED_CAPACITY
Gigabytes
LUN Consumed Capacity in Gigabytes
v1.0
QOS_STORAGE_VOL_KBYTES_TRANSFERRED
KB
LUN Kbytes Transferred in the sample period
v1.0
QOS_STORAGE_VOL_KBYTES_WRITTEN
KB
LUN Kbytes Written in the sample period
v1.0
QOS_STORAGE_VOL_NUMBER_OF_BLOCKS
Blocks
LUN Total Blocks
v1.0
LUN Status [Unknown(0), Other(1), OK(2), Degraded(3),

v1.0
QOS_STORAGE_VOL_OPERATIONAL_STATUS
QOS_STORAGE_VOL_READ_HIT_IOS
Count
LUN Read Hit IOs in the sample period
v1.0
QOS_STORAGE_VOL_READ_IOS
Count
LUN Read IOs in the sample period
v1.0
QOS_STORAGE_VOL_TOTAL_IOS
Count
LUN Total IOs in the sample period
v1.0
QOS_STORAGE_VOL_WRITE_HIT_IOS
Count
LUN Write Hit IOs in the sample period
v1.0
QOS_STORAGE_VOL_WRITE_IOS
Count
LUN Write IOs in the sample period
v1.0
hitachi Troubleshooting
This article describes how to verify your configuration and communications, and how to examine the log file for detailed information.
To verify your setup, perform the following steps:
1. Verify the probe configuration.
2. Verify network communication.
Verify the Probe Configuration

If you enter an incorrect value when defining a resource, the system generates an error message when you click the Test button in the Register
Resource (SMIS) dialog. If you receive an error message, verify that you correctly defined the following fields in the Register Resource (SMIS) d
ialog:
Resource Name - Enter a valid DNS name or IP address for the SMI-S server.
Server - Enter a valid IP for the device hosting the SMI-S provider.
Port - Enter the correct port (5988 for HTTP, 5989 for HTTPS) on the device hosting the SMI-S provider.
Namespace - Select the correct namespace for the resource, typically root/smis/current.
User Name - Enter a valid user name. If no user was set up, use cimuser as the default user.
Password - Enter the correct password. If no user was set up, use password as the default user.
Note: If you are unable to collect performance data, make sure the firmware version of the Hitachi system is 7.0 or higher; upgrade the
firmware if necessary.
Verify Network Communication

Ensure there is network communication between the probe and SMI-S provider. For HTTP communications, port 5988 must be available; HTTPS
uses port 5989. Check to see if a firewall is blocking the necessary port, or if some other network problem is preventing communications:
1. Log in to the server where the SMI-S provider is installed and ping the probe server. Verify that the ping is successful.
2. Log in to the server where the probe is installed and run the following tests:
a. Ping the SMI-S server. Verify that the ping is successful
b. Telnet into the SMI-S server and verify a successful response. For example:
telnet 69.80.220.10 5988
If any of these tests fail, you may need to resolve a network communication problem. Once that is done, go back to the Register Resource (SMI
S) dialog and click Test button. The Hitachi storage device should be listed.
Error Messages
You can view error messages in the log dialog by right clicking the probe icon and selecting View Log.
You can increase the level of logging from the Probe Setup section in the probe AC version or the General Setup in the probe IM version.
Note: If, after these steps, you still have difficulties, you may want to use a third-party tool such as CimNavigator (not affiliated with or
endorsed by CA) to view and manipulate the CIM objects on the SMI-S server. A tool of this kind may help you identify configuration
issues.
hp_3par (HP 3PAR Storage Monitoring)

The HP 3PAR Storage Monitoring (hp_3par) probe enables you to monitor the performance and usage of HP 3PAR StoreServ Storage systems.
The probe allows you to obtain performance and storage utilization statistics on the following storage objects:
Physical Disks: A physical disk is a hard drive divided into chunklets. A chunklet is the most basic element of data storage of the HP
3PAR StoreServ.
Logical Disks: A logical disk is a collection of physical disk chunklets arranged as rows of RAID sets.
Controller Nodes: Controller Nodes are the high-performance data movement engines of the HP 3PAR StoreServ Architecture.
Common Provisioning Groups(CPGs): There are virtual pools of logical disk space.
Virtual Volumes: Virtual Volumes use storage space provided by CPGs and are exported as logical unit numbers (LUNs) to hosts.
Ports: System controller nodes use different ports such as Gigabit Ethernet to connect the HP 3PAR storage system to your system.
The probe retrieves data about the complete storage system, which is classified as follows:
Performance and Scalability: Enables you to get information about the total number of storage transactions being processed every
second and the latency of the storage system.
Statistical Data: Enables you to get statistical information about all objects of the storage system as a whole. For example, the
configured used and free space information for the storage system.
Data Collection Protocols

The hp_3par probe collects data through a combination of standard SMI-S CIM API and 3PAR command line (CLI) option. The probe uses
the CLI option only when data is not available through the SMI-S provider. You must start the Common Information Model (CIM) server on your
system to enable communication between the probe and the HP 3PAR storage system using the SMI-S provider. For running the CLI commands,
the probe makes ssh connection with the 3PAR system. Storage Management Initiative Specification (SMI-S) is an industry standard supported
by multiple storage vendors and uses an object-oriented model based on the Common Information Model (CIM) to define objects and services
which comprise a Storage Area Network (SAN). CIM API uses HTTP or HTTPS protocol with dedicated TCP ports (5988/5989 by default).
More Information:
hp_3par (HP 3PAR Storage Monitoring) Release Notes
v1.1 hp_3par AC Configuration

This article describes the configuration concepts and procedures for setting up the HP 3PAR Storage Monitoring (hp_3par) probe. This probe is
configured to monitor the performance and usage of HP 3PAR StoreServ Storage systems. The following diagram outlines the process to
configure the probe to obtain performance and storage utilization statistics on the storage objects.
Contents
Naming Convention For Storage Objects
Alarm Thresholds
Verify that required hardware and software is available and preconfiguration requirements are met before you configure the probe. For more
information, see hp_3par (HP 3PAR Storage Monitoring) Release Notes.
How to Monitor HP 3PAR StoreServ Storage Server

This section describes how to configure the hp_3par probe to monitor storage objects.
Follow these steps:
2. Click the Options (icon) next to the hp_3par node in the navigation pane.
4. Specify the Hostname or IP address of HP 3PAR storage system.
5. Specify the Port number on which the SMI-S provider is listening.
6.
6. Define the Username and Password of the user account to access the HP 3PAR system.
7. Select Active to activate the profile for monitoring. By default, the profile is active.
You can skip this step if you do not want the profile to start monitoring on creation.
8. Specify the time interval in seconds after which the probe collects the data from the HP 3PAR system for the specific profile. Reduce this
interval to generate alarms faster, as the next interval takes lesser time but it can increase the system load. You can also increase this
interval to generate alarms later and reduce the system load.
Default: 600
9. Specify the Alarm Message to be generated when the profile is unable to retrieve monitoring data. For example, the profile does not
respond if there is a connection failure or inventory update failure.
10. Select Use SSL to allow the probe to use HTTPS for connecting to the HP 3PAR system.
11. Click Submit.
The new monitoring profile is created and displayed under the hp_3par node. The monitoring categories for the storage objects are
displayed as nodes below the Profile Name node.
13. Verify the connection between the probe and the storage server through the Test Connection button under the Actions drop down.
A connection successful message is displayed if the connection is verified.
Naming Convention For Storage Objects

Storage objects in the probe use the following naming conventions:
The naming convention for the Physical Disks indicates the Disk Position in the HP 3PAR storage. For example, the disk name 0:1:2
suggests that 0 is the Cage, 1 is the Magazine and 2 is the Disk. Together, these three combine to form the disk position in the HP 3PAR
storage.
Similarly, the naming convention for port indicates the Port Position in the HP 3PAR storage. For example, the port name 0:1:2 suggests
that 0 is the Node, 1 is the Slot and 2 is the Port. Together, these three combine to form the port position in the HP 3PAR storage.
Alarm Thresholds
allow the probe to:
v1.1 hp_3par AC GUI Reference

This article describes the fields and features of the HP 3PAR Storage Monitoring (hp_3par) probe.
Contents
Template Editor
hp_3par Node
<Profile Name> Node
<Storage Object Name> Node
Template Editor
templates that can be applicable across multiple profiles. For more information, see hp_3par Apply Monitoring with Templates.
hp_3par Node
The hp_3par node contains configuration details specific to the probe. This node enables you to view the probe information and configure the log
properties of the probe.
Navigation: hp_3par
hp_3par > Configuring hp_3par Monitoring
This section displays the minimum configuration settings required to monitor a storage object using the hp_3par probe.
hp_3par > Probe Information
hp_3par > Probe Setup
This section enables you to configure the default log level and log size for the probe.
Default: 3-Info
Default: 1000
hp_3par > Options (icon) > Add New Profile
<Profile Name> Node

This node lets you configure a profile for the storage object you want to monitor. The hp_3par probe uses each profile as a connection to the
storage system through which the probe collects and stores data from the monitored components.
The Profile Name node displays the resource connection properties and enables you to update the properties. The resource properties include IP
address of the resource, port, and user authentication details.
Navigation: hp_3par > Profile Name
Profile Name > Options (icon) > Delete Profile
Profile Name > Actions > Test Connection
This button allows you to check the connection between the probe and the storage server.
Profile > Resource Setup
Hostname: specifies the host name or IP address of hp_3par storage system.
Port: specifies the port number on which the SMI-S provider is listening.
Default: 5988
Username: defines the user account for accessing the hp_3par system.
Password: defines the password for the given password.
Interval (secs): specifies the time interval (in seconds) after which the probe collects the data from the hp_3par system for the specific
profile.
Default: 600
Alarm Message: specifies the alarm message to be generated when the profile is not responding. For example, the profile does not
respond if there is a connection failure with the HP_3PAR storage system or inventory update failure.
Use SSL: allows the probe to use HTTPS for connecting to the hp_3par storage system.
NameSpace: identifies the namespace that is supported by the Device Manager and the SMI-S version. This field is read-only.

The Resource Name node contains monitors that you can configure to generate alarm and QoS messages for the HP 3PAR storage system.
The monitors are visible in a tabular form. You can select any monitor from the table to configure its properties.
Navigation: hp_3par > Profile Name > Resource Name > Monitors
Value Definition
Specifies the value type for calculating the QoS metric. The following options are available:
Current Value: The most current value measured is used.
Average Value Last n Samples: The average value of the last n samples, that is, (sum of values of last n samples) / n is used.
Delta Value (Current-Previous): The delta value calculated from the current and the previous measured sample is used.
Delta Per Second: The delta value calculated from the samples measured within a second is used.

The Storage Object Name node represents the actual name of the storage object which is available in the HP 3Par storage system. This node
contains only the Monitors section. Select any monitor and configure its properties. The fields are the same as in the Resource Name node.
v1.0 hp_3par AC Configuration

This article describes the configuration concepts and procedures for setting up the hp_3par probe. This probe is configured to monitor the
performance and usage of HP 3PAR StoreServ Storage systems. The following diagram outlines the process to configure the probe to obtain
performance and storage utilization statistics on the storage objects.
Contents
Prerequisites
How to Monitor the HP 3PAR StoreServ
Alarm Thresholds
Prerequisites
Verify that required hardware, software, and information is available before you configure the probe. For more information, see hp_3par (HP
3PAR Storage Monitoring) Release Notes.
The following are the preconfiguration requirements for the HP 3PAR Storage Monitoring probe.
The CIM server is required as a data collector for interfacing with the HP 3PAR storage system using the SMI-S provider. You must start
the CIM server on your system to enable communication between the probe and the HP 3PAR storage system using the SMI-S provider.
Enabling and Disabling the CIM Server for HP 3PAR
To enable the CIM Server via the CLI, use startcim command:
# startcim
To disable the CIM Server via the CLI, use stopcim command:
# stopcim
To display the overall CIM Server status, use the showcim command:
# showcim
How to Monitor the HP 3PAR StoreServ
This section describes the minimum configuration settings required to configure the hp_3par probe to monitor the storage objects.
Follow these steps:
2. Click the Options (icon) next to the hp_3par node in the navigation pane.
4. Set or modify the following values in the Add New Profile window:
Hostname: specifies the host name or IP address of HP 3PAR storage system.
Username: defines the user account for accessing the HP 3PAR system.
Password: defines the password for the given username.
Interval (secs): specifies the time interval in seconds after which the probe collects the data from the HP 3PAR system for the specific
profile.
Default: 600
Alarm Message: specifies the alarm to be generated when the profile is not responding. For example, the profile does not respond if
there is a connection failure or inventory update failure.
Use SSL: allows the probe to use HTTPS for connecting to the HP 3PAR system.
5. Click Submit and click Save to save the configuration.
The new monitoring profile is created and displayed under the hp_3par node. The monitoring categories for the storage objects are
displayed as nodes below the Resource IP Address node.
6. Verify the connection between the probe and the storage server through the Test Connection button under the Actions drop down.
7. Configure the alarms and thresholds in the monitors for the desired storage object. For example, to configure the alarms and thresholds
in the monitors for the Physical Disks node:
a. Navigate to hp_3par > Resource IP Address > IP Address > Physical Disks > Disk Name > Monitors
b. The monitors are visible in a tabular form. Select any one monitor from the table, and configure its properties.
Alarm Thresholds
allow the probe to:
v1.0 hp_3par AC GUI Reference

This article describes the fields and features of the hp_3par probe.
Contents
Template Editor
hp_3par Node
<IP Address> Node
Template Editor
templates that can be applicable across multiple profiles. For more information, see hp_3par Apply Monitoring with Templates.
hp_3par Node
The hp_3par node contains configuration details specific to the HP 3PAR Storage Monitoring probe. This node enables you to view the probe
information and configure the log properties of the probe.
Navigation: hp_3par
hp_3par > Configuring hp_3par Monitoring
This section describes the minimum configuration settings required to monitor a storage object using the hp_3par probe.
hp_3par > Probe Information
hp_3par > Probe Setup
This section enables you to configure the default log level and log size for the probe.
Default: 3-Info
Log Size: specifies the size of the log file in kilobytes.
Default: 1000
hp_3par > Options (icon) > Add New Profile

This node lets you configure a profile for the storage object you want to monitor. The hp_3par probe uses each profile as a connection to the
StoreServ system through which the probe collects and stores data from the monitored components. You can check the connection between the
probe and the storage server through the Test Connection button under the Actions drop down.
The Resource IP Address node displays the resource connection properties and enables you to update the properties. The resource properties
include IP address of the resource, port, and user authentication details.
Navigation: hp_3par > Resource IP Address
IP Address > Options (icon) > Delete Profile
IP Address > Resource Setup
Hostname: specifies the host name or IP address of hp_3par storage system.
Default: 5988
Username: defines the user account for accessing the hp_3par system.
Password: defines the password for the given username..
Interval (secs): specifies the time interval (in seconds) after which the probe collects the data from the hp_3par system for the specific
profile.
Default: 600
Alarm Message: specifies the alarm message to be generated when the profile is not responding. For example, the profile does not
respond if there is a connection failure with the HP_3PAR storage system or inventory update failure.
Use SSL: allows the probe to use HTTPS for connecting to the hp_3par storage system.
<IP Address> Node

The IP Address node is used for configuring monitors of the HP 3PAR storage system. The monitors generate alarm and QoS messages
depending on the monitoring category. The monitors enable the probe to retrieve data about the complete storage system, which is classified as
follows:
Performance and Scalability: Enables you to get information about the total number of storage transactions being processed by the
StoreServ system every second and the latency of the StoreServ system.
Statistical Data: Enables you to get statistical information about all objects of the storage system as a whole. For example, the
configured, used and free space information for the StoreServ system.
The IP Address node allows you to configure the following monitors:
IOPs
Latency
Raw Free Capacity
Raw Used Capacity
Raw Total Capacity
Raw Free Capacity Percent
The monitors are visible in a tabular form. You can select any one monitor from the table and configure its properties.
Navigation: hp_3par > Resource IP Address > IP Address > Monitors
Value Definition: specifies the value type for calculating the QoS metric. The following options are available:
Current Value: The most current value measured is used.
Average Value Last n Samples: The average value of the last n samples, that is, (sum of values of last n samples) / n is used.
Delta Value (Current-Previous): The delta value calculated from the current and the previous measured sample is used.
Delta Per Second: The delta value calculated from the samples measured within a second is used.

The Storage Object Name node represents the actual name of the storage object which is available in the HP 3Par storage system. This node
contains only the Monitors section. Select any of the monitors and configure its properties which are the same as configured in the IP Address no
de.
The probe can monitor the following storage objects.
Controller Nodes
CPG
Logical Disks
Physical Disks
Ports
Virtual Volumes
Notes:
The naming convention for the Physical Disks indicates the Disk Position in the HP 3PAr StoreServ. For example, the disk
name 0:1:2 suggests that 0 is the Cage, 1 is the Magazine and 2 is the Disk. Together, these three combine to form the disk
position in the HP 3PAR StoreServ.
Similarly, the naming convention for port indicates the Port Position in the HP 3PAr StoreServ. For example, the port name
0:1:2 suggests that 0 is the Node, 1 is the Slot and 2 is the Port. Together, these three combine to form the port position in the
HP 3PAR StoreServ.
hp_3par Apply Monitoring with Templates

The Template Editor interface allows you to create and apply monitoring templates. Templates reduce the time that you need to manually
configure monitors. Templates also provide consistent monitoring across the devices in your network. You can configure monitoring on many
targets with a well-defined template.
This article describes how to apply monitoring with templates for the hp_3par probe.
Contents

Create Template
Template Precedence Rules
Creating Filter Rules
(Optional) Copy Templates to Another Robot

The default templates contain settings for a recommended monitor configuration. You can use, or modify these default configurations to quickly
start collecting data for your environment. Both existing and new profiles can be configured using templates. The default template has the
monitors that are configured for the default monitors in the USM dashboard.
Follow these steps to apply a default template:
The Template Editor page is displayed
3. Click the hp3_par FactoryTemplate node.
4. Enter a precedence value for the template.
For more information, see the Template Precedence Rules section.
5.
5. Select the Active checkbox to activate the template.

6. Click Submit and then click Save.
Create Template
You can create a new template to configure multiple existing profiles with the same monitor configuration.
Follow these steps:
3. The Template Editor page is displayed.
4. Click the Options (icon) next to the hp_3par probe node.
6. Specify a name and description for the template.
7. Enter the precedence value if you want to modify the default precedence setting.
For more information, see the Template Precedence Rules section.
The <templateName> node is displayed followed by all the profile nodes of the probe.
9. (Optional) Click the <templateName> node to view the monitors and configure and include them in the template.
10. (Optional) Click the Options (icon) next to nodes representing multiple possible values (such as Physical Disks) to create filters.
For more information, see the Creating Filter Rules section.
13. Select Save.
The template is created and applied to the probe at the next probe interval.
Note: All probe settings that are configured using templates are not available for individual configuration. You must clear the Active che
ckbox to deactivate the template to unlock the required setting for modifications.
Template Precedence Rules

Precedence controls the order of template application. The probe applies a template with a precedence of one before a template with a
precedence of two. If there are any overlapping configurations between the two templates, then the settings in the template with a precedence of
one overrides the settings in the other template. If the precedence numbers are equal, then the templates are applied in alphabetical order.
Use the following rules to set precedence:
Precedence is set with a numeric value.
When precedence is applied to multiple templates:
When the precedence is different for the templates: The precedence of a template decreases as the value increases.
Example: 1 has higher precedence than 2, and so on. The probe applies the template with lowest numeric value of precedence.
When filters are applied on templates: The precedence works according to the applied filters. If no filter is applied, the precedence
is applied on all applicable profiles.
Creating Filter Rules

Filters let you control how the probe applies monitors based on attributes of the target device. Filters also let you control which profiles or devices
are associated with a particular template. You can create filter rules for nodes that represent multiple possible values (such as IP Address). You
can add rules to a device filter to create divisions within a group of systems. Similarly, you can also reduce the set of devices that the probe is to
monitor. For example, you can add a rule to apply a monitoring configuration to all storage profiles monitoring storage systems in the set of IPs
available in 10.112.33.x.
Follow these steps:
3. Specify the condition that the probe uses to match against the label.
Default: Equals
All the conditions are described as follows:
Equals: indicates that the label is the same as the specified value.
Regex: indicates that the label matches the specified regular expression.
For more information, see .
StartsWith: indicates that the label ends with the specified value.
5. Enter a precedence value for the filter.
Note: The rules for setting the precedence value for filters are same as setting precedence for templates.


(Optional) Copy Templates to Another Robot

After you configure a template, you can use the existing templates on other instances of the probe. This allows you to apply consistent monitoring
across probe instances.
Templates are stored on the robot system in the <CA UIM Installation Directory>\probes\<categoryName>\<probeName>\bulk_config\raw_t
emplates directory. The templates are stored with hexadecimal names and gzip extension. For example, fd1660f2-f7f1-4f95-92be-4c09b0674587
.gzip.
Follow these steps:
1. On the robot with the probe template, navigate to the raw_templates directory.
2. Copy the .gzip files from the source directory to the corresponding raw_templates directory of the target robot.
3. Repeat Step 2 for each instance of target probe.

4. Restart the target probes.
The templates are now available for application on the required probe instances.
Note: Copy all the gzip files from the directory. You can apply the required template from the template editor interface of the target
probe instance.

A regular expression (regex for short) is a special text string for describing a search pattern. You can specify regular expressions in filter rules if
you select Regex from the filter conditions list. Constructing regular expression and pattern matching requires meta characters. The probe
supports Perl Compatible Regular Expressions (PCRE) which are enclosed within forward slash (/). For example, the expression /[0-9A-C]/ match
es any character in the range 0 to 9 in the target string.
target string.
The following table describes some examples of regex and pattern matching for the hp_3par probe.
Regular expression
Explanation
[A-Z]
Standard (PCRE)
Standard (PCRE)
Standard (PCRE)
\d*
Custom
hp_3par Metrics
This article describes the metrics that can be configured using the HP 3PAR Storage Monitoring (hp_3par) probe.
Physical Disks Metrics

Logical Disks Metrics
CPG Metrics
Virtual Volumes Metrics
Ports Metrics
Controller Nodes Metrics
The following table lists the Device metrics you can collect with the hp_3par probe. This table also lists the CIM element if the data collection
method is SMI-S or the CLI command if the data collection method is CLI.
Resource
Entity
Device
Monitor
Name
API
CIM
Element/Command
QoS Monitor
Unit
Description
Version
IOPS
CLI
statpd
QOS_HP_3PAR_IOPS
Count
Total Number of Input/Output Operatio

ns per Second of the StoreServ
System.
1.0
Latency
CLI
statpd
QOS_HP_3PAR_LATENCY
ms
Total Time Required by the StoreServ

System to Process a Single Storage
Transaction or Data Request.
1.0
Total
Capacity
CLI
showsys
QOS_HP_3PAR_RAW_TOTAL_CAPACITY
GB
Total Raw Space Information for the St

oreServ System.
1.0
Used
Capacity
CLI
showsys
QOS_HP_3PAR_RAW_USED_CAPACITY
GB
Total Raw Used Capacity of the Store

Serv System.
1.0
Free
Capacity
CLI
showsys
QOS_HP_3PAR_RAW_FREE_CAPACITY
GB
Total Raw Free Capacity of the StoreS

erv System.
1.0
Free
Capacity
Percent
CLI
showsys
QOS_HP_3PAR_RAW_FREE_CAPACITY_PERCENT percent Total Raw Free Capacity of the StoreS

erv System in Percent.
1.0
Physical Disks Metrics

The following table lists the Physical Disks metrics you can collect with the hp_3par probe. This table also lists the CIM element if the data
collection method is SMI-S or the CLI command if the data collection method is CLI.
Resource
Entity
Physical
Disks
Monitor
Name
API
CIM
Element/Command
QoS Monitor
Unit
Description
Version
Availability
SMI-S CIM_DiskDrive
QOS_PHYSICAL_DISK_AVAILABILITY
State
Availability of the Physical Disks. [Unknown(0),

Other(1), OK(2), Degraded(3), Stressed(4),
Predictive Failure(5), Error(6), Non-Recoverable
Error(7), Starting(8), Stopping(9), Stopped(10), In
Service(11), No Contact(12), Lost
1.0
Total
Capacity
SMI-S CIM_DiskDrive
QOS_PHYSICAL_DISK_CAPACITY
GB
Physical Disk Total Capacity in Gigabytes.
1.0
Latency
CLI
QOS_PHYSICAL_DISK_LATENCY
ms
Latency of the Physical Disk in Milliseconds.
1.0
IOPS
SMI-S TPD_DiskStatisticalData QOS_PHYSICAL_DISK_IOPS_RATE
Count
Total Number of Input/Output Operations per

second of the Physical Disk.
1.0
Physical Disk Kilobytes Read and Written per

Second.
1.0
statpd
Throughput SMI-S TPD_DiskStatisticalData QOS_PHYSICAL_DISK_THROUGHPUT KB\s
Utilization
SMI-S CIM_DiskDrive
QOS_PHYSICAL_DISK_UTILIZATION
Percent Total Percentage of Used Capacity of the Physical

Disk.
1.0
Logical Disks Metrics

The following table lists the Logical Disks metrics you can collect with the hp_3par probe. This table also lists the CIM element if the data
Resource
Entity
Monitor
Name
Logical Disks
(Raid Group)
Availability
API
CLI
CIM
Element/Command
showld
QoS Monitor
QOS_LOGICAL_DISK_AVAILABILITY
Unit
State
Description
Availability of the Logical Disks. The values are:

0(normal): The logical disk has started and is
available for use.
Version
1.0
1(preserved): Some disks used by the logical

disk are missing. Data belonging to the logical
disk is saved on the preserved logical disk.
2(stopping): The logical disk is being stopped;
normally flushes any in-flight data to disk.
3(removing): The logical disk is being deleted.
4(stopped): The logical disk is stopped, and its
data is not available.
5(orphan): Both the primary owner and backup
owner nodes are down, and the data of the
logical disk is not available.
Total
Capacity
CLI
showld
QOS_LOGICAL_DISK_CAPACITY
GB
Logical Disk Total Capacity in Gigabytes.
1.0
Latency
CLI
showld
QOS_LOGICAL_DISK_LATENCY
ms
Latency of the Logical Disk in Milliseconds
1.0
IOPS
CLI
statld
QOS_LOGICAL_DISK_IOPS_RATE
Count
Total number of Input/Output operations per second

of the Logical Disk.
1.0
Throughput CLI
statld
QOS_LOGICAL_DISK_THROUGHPUT KB\s
Logical Disk Kilobytes Read and Written per Second.
1.0
Utilization
statld
QOS_LOGICAL_DISK_UTILIZATION
CLI
Percent Total Percentage of Used Capacity of the Logical

Disk.
1.0
CPG Metrics
The following table lists the CPG metrics you can collect with the hp_3par probe. This table also lists the CIM element if the data collection
Resource
Entity
CPG (Pool)
Monitor
Name
API
CIM
Element/Command
QoS Monitor
Unit
Description
Version
Availability SMI-S TPD_DynamicStoragePool QOS_CPG_AVAILABILITY State
Availability of Common Provisioning Groups. [Unknown(0),

1.0
Other(1), OK(2), Degraded(3), Stressed(4), Predictive Failure(5),
Error(6), Non-Recoverable Error(7), Starting(8), Stopping(9),
Communication(13), Aborted(14), Dormant(15), Supporting
Entity in Error(16), Completed(17)]
Total
Capacity
SMI-S TPD_DynamicStoragePool QOS_CPG_CAPACITY
GB
Common Provisioning Group's Total Capacity in Gigabytes.
Utilization
SMI-S TPD_DynamicStoragePool QOS_CPG_UTILIZATION
Percent Percentage of CPG Capacity Currently in Use.
1.0
1.0
Virtual Volumes Metrics

The following table lists the Virtual Volumes metrics you can collect with the hp_3par probe. This table also lists the CIM element if the data
Resource
Entity
Virtual
Volumes
(LUN)
Monitor
Name
API
CIM Element/Command
QoS Monitor
Unit
Description
Version
Availability
SMI-S SNIA_StorageVolume
QOS_VIRTUAL_VOLUME_AVAILABILITY
State
Availability of The Virtual Volumes.

[Unknown(0), Other(1), OK(2), Degraded(3),
Non-Recoverable Error(7), Starting(8),
Stopping(9), Stopped(10), In Service(11), No
Contact(12), Lost Communication(13),
Aborted(14), Dormant(15), Supporting Entity
in Error(16), Completed(17)]
1.0
Total
Capacity
SMI-S SNIA_StorageVolume
QOS_VIRTUAL_VOLUME_CAPACITY
GB
Virtual Volume Total Capacity in Gigabytes.
1.0
Latency
CLI
QOS_VIRTUAL_VOLUME_LATENCY
ms
Latency of the Virtual Volumes in

Milliseconds.
1.0
IOPS
SMI-S TPD_VolumeStatisticalData QOS_VIRTUAL_VOLUME_IOPS_RATE
Count
Total number of Input/Output operations per

second of the Virtual Volumes.
1.0
Virtual Volume Kilobytes Read and Written

per Second.
1.0
statvv
Throughput SMI-S TPD_VolumeStatisticalData QOS_VIRTUAL_VOLUME_THROUGHPUT KB/s

Utilization
CLI
showvv -s
QOS_VIRTUAL_VOLUME_UTILIZATION
Percent Total Percentage of Used Capacity of the

Virtual Volume.
1.0
Ports Metrics
The following table lists the Ports metrics you can collect with the hp_3par probe. This table also lists the CIM element if the data collection
Resource
Entity
Ports
Monitor
Name
API
CIM
Element/Command
Availability SMI-S CIM_NetworkPort
QoS Monitor
Unit
QOS_PORT_AVAILABILITY State
Description
Version
Availability of StoreServ System Port. [Unknown(0), Other(1), OK(2),

Non-Recoverable Error(7), Starting(8), Stopping(9), Stopped(10), In
Service(11), No Contact(12), Lost Communication(13), Aborted(14),
Dormant(15), Supporting Entity in Error(16), Completed(17)]
1.0
Controller Nodes Metrics

The following table lists the Controller Nodes metrics you can collect with the hp_3par probe. This table also lists the CIM element if the data
Resource
Entity
Monitor
Name
API
CIM
Element/Command
QoS Monitor
Unit
Description
Version
Controller
CPU Utilization
CLI
statcpu -t
QOS_CONTROLLER_CPU_UTILIZATION Percent Total CPU Utilization of the Controller

Node
1.0
hpsmgtw (HP Service Manager Gateway)

The HP Service Manager Gateway probe generates an incident in the HP Service Manager (HPSM) application from the CA Unified Infrastructure
Management Server Alarms. The incident is generated when an alarm is assigned to the designated UIM user. The incident helps the Service
Manager user to take corrective actions for resolving the issue. The probe also tracks the incident status and acknowledges the alarm.
The HP Service Manager Gateway probe supports the following functionalities:
Generate the incident in HPSM when an alarm is assigned to the designated CA Unified Infrastructure Management user.
Updates the incident information when the alarm information is updated.
Updates the incident status when the alarm is acknowledged.
Clears the alarm when the corresponding incident is closed in HPSM.
Note: The HP Service Manager Gateway probe supports only one WSDL URL for all functionalities.
You can configure the Auto-Operator functionality of the Alarm Server (NAS) for automatically assigning the alarm to the designated CA Unified
Infrastructure Management user. You can also assign the alarm manually from the IM to generate a new incident.
Note: The HP Service Manager Gateway probe initiates a new incident request when an alarm is assigned to the CA Unified
Infrastructure Management user. This username is configured in the HP Service Manager Gateway probe.
More information:
hpsmgtw (HP Service Manager Gateway) Release Notes
hpsmgtw Prerequisites
The prerequisites for the hpsmgtw probe are as follows:
The user credentials to access the HPSM application for working with incidents.
The UIM user to assign alarms and trigger creating an incident in the HPSM.
Note: You are recommended to create a separate user in Infrastructure Manager for assigning the alarms.
v1.0 hpsmgtw AC Configuration
Configure a Node
Configure the Offline Management Mode
Configure a Node
This procedure provides the information to configure a particular section within a node.
Each section within the node lets you configure the probe properties. These properties are used for generating incident in the HPSM application
for the CA Unified Infrastructure Management Probes alarm.
Follow these steps:
The probe is now ready for generating incidents in the HPSM application.

The field mapping details are added for saving necessary information from the alarm in the HPSM incident. This information helps the HPSM user
for resolving the incident.
Follow these steps:
1. Click the Options icon next to the Field Mapping node.
2. Select the Field Mapping option.
3. Specify the Service Desk Field in the Field Mapping dialog.
Note: The Service Desk field list appears only if valid credentials are provided in the Server Configuration section of the hps
mgtw node.
4. Specify the Alarm Field or define the Default Value for the selected Service Desk Field.
5. Click Submit.
The mapping details are saved and displayed in the Mapping table of the Field Mapping node.
Note: You can map a field (an Alarm field or a Service Desk field) again for updating the field mapping details.

The field mapping details are removed or deleted when there is no need of displaying information in the incident.
Follow these steps:
1. Click the Field Mapping node.
2. Select the appropriate row in the Mapping table of the Field Mapping section.
3. Click the Delete button of the Mapping table.
4. Click Save.
The selected field mapping detail is removed.
Configure the Offline Management Mode

The Offline Management mode lets you save alarm details that are assigned to the CA Unified Infrastructure Management user while the HPSM
application is down. Therefore, no incident is generated for the corresponding alarm.
The HP Service Manager Gateway probe pings the HPSM application at regular intervals and receives an alert when the HPSM application is
down. When the HPSM application is up again, the probe restarts. The Offline Management mode checks for the alarms that are assigned to the
CA Unified Infrastructure Management user in NAS when the HPSM application is down. Then the probe initiates a request for generating
incidents for those alarms.
Follow these steps:
1. Open the raw configuration GUI of the probe.
2. Go to the disable_offline_management key under the setup section.
3.

1: Set the key value to 1 to turn off the Offline Management mode. 1 is the default value.
0: Set the key value to 0 to turn on the Offline Management mode.
4. Click Apply.
5. Close the raw configuration GUI.
The Offline Management mode is configured.

The subscribe_alarm_closure key is configured to update the incident status to Resolved or Closed when the corresponding alarm is
acknowledged.
Follow these steps:
2. Go to the subscribe_alarm_closure key under the setup section.
0 - The probe does not update the incident status.1 - The probe updates the incident status. By default, the value is 1.
4. Click Apply.
The subscribe_alarm_closure key is configured.

The subscribe_alarm_updates key is configured to update the incident information when the corresponding alarm information, such as the
alarm description and severity changes.
The key initiates an update request when the value of the mapped alarm field is updated in the CA Unified Infrastructure Management server. For
example, the subsystem Id of an alarm is updated, but this subsystem Id field is not mapped with any of the incident fields. In this case, the probe
does not initiate an update request.
Important! The subscribe_alarm_updates key does not update the incident status to Close or Resolve when the alarm is
acknowledged in the CA Unified Infrastructure Management server.
Follow these steps:

2. Go to the subscribe_alarm_updates key under the setup section.
0 - The probe does not update the incident information.1 - The probe updates the incident information. By default, the value is
1.
4. Click Apply.
The subscribe_alarm_updates key is configured.
v1.0 hpsmgtw AC GUI Configuration
hpsmgtw Node
<IP Address> Node
Field Mapping Node
Alarm Severity Mapping
HPSM Mandatory Fields Default Configuration
The HP Service Manager Gateway probe is configured for automatically or manually creating the incidents from the CA Unified Infrastructure
Management alarms. The probe enables the bi-directional synchronization of alarms and incidents status.
The HP Service Manager Gateway probe creates an incident in the HPSM application when alarms are assigned to the CA Unified Infrastructure
Management user. The probe automatically acknowledges the corresponding alarms once these incidents are closed in the HPSM application.
hpsmgtw Node
The hpsmgtw node is used for establishing a connection between the probe and the HPSM application.
This section contains configuration details specific to the HP Service Manager Gateway probe.
Navigation: hpsmgtw
hpsmgtw > Probe Information
hpsmgtw > Server Configuration
This section lets you configure the URL of the HPSM application and user credentials for authorization.
Server URL: Defines the WSDL URL of the HPSM application for retrieving the Web Service description. This Web Service exposes
methods for performing necessary operations on the HPSM application.
Username: Defines the user name for logging in to the HPSM application. The username is case-sensitive.
Password: Defines the password for the HPSM user.
Note: Use the Test option from the Actions drop-down list for verifying the connectivity between the probe and the HPSM
application.
<IP Address> Node

The IP address node is displayed after configuring the HPSM application server details in the hpsmgtw node. The IP address node contains
sections for enabling the communication between the probe and the HPSM application.
Note: The IP address node displays the actual IP of the HPSM application server.
Navigation: hpsmgtw > IP address

IP address > General Configuration
This section lets you configure the compatibility and connection settings between the probe and the HPSM application.
Log Level: Sets the detail level to be included in the log file.
Default: 0 - Fatal
Check Interval (Minutes): Defines the time interval (in minutes) for getting a list of closed incidents from the HPSM application and
clearing the corresponding alarms. The recommended value is 5 minutes.
Every time the probe checks the HPSM server for closed incidents, the probe stores the time-stamp value. The probe reads this
time-stamp value in the successive request for retrieving the list of closed incidents between the two requests. The probe subtracts
the sweeptime_before_lastrun key value from the time-stamp value before requesting the HPSM server for retrieving the list of
closed incidents.
This sweeptime_before_lastrun key stores an integer value which denotes the time in minutes. The default value of the sweeptime_
before_lastrun key is 10 minutes and this key is configured by using the Raw Configure option under the setup section.
Default: 30
NAS Address: Defines the address of the local Nimsoft Alarm Server (NAS) in the /<Domain>/<Hub>/<Robot>/nas format where the
probe is deployed. The address is case-sensitive.
Date Format: Defines the date format that matches the date format of the HPSM platform. The closed incident retrieval timer uses this
format to build queries. The configuration file can use the following date formats:
MM/dd/yyyy HH:mm:ss
dd/MM/yyyy HH:mm:ss
Timezone: Specifies the time zone code for storing the time value.
Important! The time zone must be same as configured in the HPSM application against the Username.
Incident Id Custom Field: Specifies the custom field of the alarm (custom_1 to custom_5) to save the incident id of the corresponding
incident.
On Cleared Alarm: Specifies the incident status when the alarm is acknowledged.
IP address > Connection Warning Alarm
This section lets you view the warning alarm properties when the probe is not able to connect with the HPSM application.
IP address > New Incident Warning Alarm
This section lets you view the warning alarm properties when the probe is not able to generate incidents on the HPSM platform.
Field Mapping Node

The Field Mapping node lets you map the HPSM fields with one of the following values:
CA Unified Infrastructure Management Alarm Field: Maps value of the corresponding field of the alarm.
Default Value: Maps a fixed value.
Navigation: hpsmgtw > IP address > Field Mapping
Field Mapping > Field Mapping
This section contains a Mapping table for displaying the list of the mapped fields and its associated value. Select a table row and view
the mapping details. These mapping details are read-only.
Alarm Severity Mapping

The Field Mapping option does not map the alarm severity to any of the fields in the HPSM incident. The alarm severity is mapped with the Impa
ct and Urgency fields of the HPSM incident and saves appropriate value in these fields.
The following table defines the default values of the Impact and Urgency fields for the alarm severity:
Alarm Severity
Impact
Urgency
Critical
1 - Enterprise
1 - Critical
Major
2 - Site/Dept
2 - High
Minor
3 - Multiple Users
3 - Average
Warning
3 - Multiple Users
3 - Average
Information
4 - User
4 - Low
You can use the Raw Configure option and update following key values under the urgency section:
critical
major
minor
warning
information
Important! Do not change mapping of the alarm severity field with the Impact and Urgency fields.
HPSM Mandatory Fields Default Configuration

At time of generating a new incident, updating an existing incident, or closing an incident on the HPSM platform some of the fields are mandatory.
These fields are mapped in the configuration file of the HP Service Manager Gateway probe with some default values. When the probe generates
a request for creating, updating, and closing the incident; it looks for the values of mandatory fields that user has mapped. If any of the mandatory
field value is not mapped, the probe selects the default value of missing mandatory fields from the configuration file. This process ensures that the
HPSM platform caters to every request from the probe without any failure.
The following table gives the detailed list of mandatory fields and their respective default values:
Request Type
Field Name
Default Value
Create Incident
Assignment Group
Hardware
Service
Applications
Description
Created from CA Unified Infrastructure Management
Area
hardware
Sub Area
missing or stolen
Impact
Severity
Urgency
Severity
Update Incident
Journal Updates
Update from CA Unified Infrastructure Management
Close Incident
Closure Code
Automatically Closed
Solution
Fixed
Important! Do not change value of the Mandatory Fields key under the Setup section. Any change in this key that is not supported on
the HPSM platform crashes the probe.
hpsmgtw Metrics
This section contains the alert metric default settings for the HP Service Manager Gateway (hpsmgtw) probe.
Alert Metric
Warning
Threshold
Warning
Severity
Error
Threshold
Error
Severity
Description
Version
GTWConnectionWarning
Major
Monitors the connection between the probe and the HPSM

platform.
v1.0
GTWNewIncidentWarning
Major
Monitors the HPSM status to determine whether it is ready to

generate the new incident.
v1.0
Note: Use the Raw Configure option for updating values of the Name, Severity, Token, msg_err, subsystem, suppression_id, and
msg_ok fields of the given messages.
hub
A CA UIM hub serves as the communication center for a group of robots. A hub binds robots into a logical group with the hub as the central
connection point. Hubs are typically set up based on location (such as a lab or building) or by service (such as development). A hub can connect
other hubs into a hierarchy of hubs.

Architecturally, a hub is a robot that gains management capabilities through the presence of the hub probe. Configure this probe to modify how
the hub handles the following CA UIM services:
Message distribution - Messages from robots are routed through the hub. Messages are routed to other hubs, or dispatched to local
subscribers (users and probes).
Name service - The hub translates /domain/hub/robot/probe addresses into an IP address and port. The service
registers TCP/IP addresses at start-up. Registration allows applications to connect to the service using TCP/IP.
Authorization - The hub handles logins to the domain.
Authentication - The hub authenticates requests and user access rights to probes and the infrastructure (hub, robot, and spooler).
Tunneling - Hub-to-hub tunnels enable a secure communication from one site to another site, much like a VPN.
Notes:
We recommend that you install at least two hubs in the domain. Two hubs ensure that you have a backup of the bus user and
the security data.
Do not install a hub on a DHCP client.
A hub can be configured with either Admin Console or Infrastructure Manager.
The hub probe does not generate any QoS data, and has no metrics.
More information:
CA Unified Infrastructure Management wiki for installation and upgrade instructions
Hub Release Notes
LDAP Requirements
UIM Server currently works with the following LDAP versions:
Novell eDirectory (TM) 8.8 SP1 (20114.57) and a Novell KDC (Key
Distribution Center) server
SUN Java Directory Server v5.2
Windows 2008 and Windows 2012 Active Directory
v7.8 Hub AC Configuration

You can use Admin Console to configure the hub.
Configure hub-to-hub communication
Verify traffic statistics for the hub, and monitor the hub message flow
Perform advanced configuration and tune hub performance
Access the Hub Configuration UI

Set up Hub-to-Hub Tunnels
Create Tunnel Access Lists
Create a Static Route to a Hub
Create Hub-to-Hub Queues
Set the Hub Communication Mode
Control Hub Connectivity Behavior
Verify the Status of Other Hubs
Log File Settings
Migrate User Tags from the Robot to the Hub
Note: If you have secondary hubs in your deployment, create queues between them and the primary hub. If secondary hubs are
separated from the primary hub by a firewall:
1. Create a static route to the hub.
2. Create tunnels and queues to connect the secondary hubs to the primary hub.
3. Delete the static route.
Access the Hub Configuration UI

To open the hub configuration UI:
1. In Admin Console, expand the hub in the left navigation tree, and select the hub robot.
2. Select the hub probe in the right pane, and click the green icon to expand the drop-down list.
3. Select Configure to open the hub Probe Configuration page.
When you click Save, all modifications are written to the configuration file and the hub probe uses the new configuration. The hub
process does not restart.
To restart a primary hub, Restart the primary hub robot.
To restart a non-primary hub, Deactivate and then Activate the non-primary hub probe.

Follow these steps to set up a tunnel between two hubs:
1. Specify the Ports Assigned to Tunnels (Optional)
2. Create a Tunnel Server
3. Create a Tunnel Server Certificate Authority
4. Create a Tunnel Client Certificate
5. Create a Tunnel Client
6. Delete Static Routes (Optional)
Specify the Ports Assigned to Tunnels (Optional)

Important! Specify the ports that are assigned to tunnels when you use a firewall.
The hub typically assigns ports that are based on the configuration of the controller probe. For a tunnel server with multiple tunnel
clients, you can assign the beginning port in the range. To assign the port, take the following steps before you create client certificates.
Ensure that both hubs appear in the Admin Console navigation pane. If they do not, create a static route to a missing hub.
1. In Admin Console, expand the tunnel server hub, and select the hub robot.
4. In the left pane, select Advanced, Tunnel Settings to open the Tunnel Settings pane.
5. Select the Ignore Controller First Probe Port checkbox.
6. Enter the first port number to use in First Tunnel Port. The hub skips ports that are used by the controller and probes.
7. Click Save.
How port assignment works
For each additional tunnel, the tunnel server increments the port number, and assigns the port to the tunnel client.
The client keeps the port as long as the hub is running.
The server does not track disconnected clients. If a tunnel client is connected to the server, the number increments. If a
previously used port becomes available, it is ignored.
When there are no active clients, the counter resets.
If you plan to configure more than one tunnel, we recommend that you specify the first port. The hub skips ports that are used
by the controller and probes.
If the First Tunnel Port field is blank, the operating system assigns random ports.
Create a Tunnel Server on the Server Hub

Note: For a primary hub with several remote hubs attached, make the remote hubs the tunnel servers. This configuration ensures that
each remote hub only adds a small amount of overhead to the primary hub.
4. In the left pane, select Tunnel to open the Tunnel Activation pane.
5. Select the Tunnel Active checkbox, and click Save.
6. Click OK to acknowledge the configuration change.
Create a Tunnel Server Certificate Authority on the Server Hub

Configure the tunnel server as a Certificate Authority (CA). A CA certificate is created, and the hub can create client certificates to secure the
tunnel.
4. In the left pane, select 1 - Tunnel Server to open the Certificate Authority Initialization page.
5. Provide the following information to initialize the CA Certificate:
Organization Name - The name of your company
Organization Unit Name - The name of your business unit within the company
Email Address - the email address of the CA Certificate administrator within the company
Country Name - The country where the company resides
State or Province Name - The district where the company resides within the country
Locality Name - The city or town where the company resides
Common Name - an automatically generated name that is based on the hub name of the tunnel server
Password - Supply a password for the CA Certificate. You supply this password during creation of client certificates
Expiration Days - the number of days the CA Certificate remains valid
6. Click Actions, Perform Certificate Authority Initialization.
7. Click Reload.
8. Two CA Certificates are generated:
One with the Common Name based on the hub name of the tunnel server
One with the Common Name equal to the IP address of the tunnel server
9. Modify the Tunnel Server Settings (Optional)
10. Set the Server Port to an available port. Default, 48003
11. In Security Settings, select the cipher strength. You can provide a custom cipher.
12. Continue with the steps in the following section to create a tunnel client certificate.
Create a Tunnel Client Certificate on the Server Hub

1. Scroll down to Client Certificate Configuration
2. If necessary, modify the organization information
3. In the Common Name field, enter the IPv4 address, IPv6 address, or the DNS-resolvable host name of the tunnel client hub. Use regular
expressions to specify multiple tunnel client hubs, and create multiple client certificates.
4. Enter a password for the tunnel client certificate
5. In Expiration Days, specify the number of days the tunnel client certificate is valid
6. Click Actions, and select Create Client Certificate
7. Click Reload to refresh the page
8. Scroll down to the Certificate field below the Client Certificate List
9. Select all the text in the Certificate field, including BEGIN CERTIFICATE and END CERTIFICATE, and copy the client certificate to the
clipboard. If you do not plan to configure the tunnel client immediately, save the certificate to a plain text file.
Create a Tunnel Client on the Client Hub

1. In Admin Console, expand the tunnel client hub, and select the hub robot.
4. In the left pane, select Advanced, Tunnel to open the Tunnel Activation pane.
5. Select the Tunnel Active checkbox, and click Save.
6. Click OK to acknowledge the configuration change.
7. In the left pane, select 2 - Tunnel Client to open the Client Certificate Configuration page.
8. Under Client Certificate Configuration, click New, and supply the following information:
Certificate ID - leave blank
Active - Select
Server - The IP address of the Tunnel Server
Server Port - The Tunnel Server Port you specified in Create a Tunnel Server Certificate Authority. Default, 48003
Check Server Common Name Value
Disabled - For a NAT environment
Enabled - The tunnel server verifies that the tunnel client is identified by the common name that is specified in the certificate
Description (Optional) - A description of the tunnel client connection
Password - Supply a password for the tunnel server
Keep Alive (Optional) - The default is 300 seconds
9. Certificate - Paste the client certificate that you saved in Create the Tunnel Client Certificate
11. Click OK to refresh the configuration.
Delete Static Routes

Important! Delete static routes to ensure that all data uses the secure tunnel, and not an unsecured static route.
If you have a static route to a hub that is connected by a tunnel, delete the unsecured static route.
1. Expand the hub with the static route, and select the hub robot.
4. Select Name Services and delete the static route.

By default, all CA UIM requests and messages can be routed over a tunnel and dispatched on the other side. The routing is transparent.
A tunnel Access List lets you restrict the access privileges for CA UIM users, addresses, and commands. The Access List is created on the
tunnel client hub.
Note: Use Infrastructure Manager to create access lists. Tunnel access lists created with the Admin Console hub configuration UI can
have issues. Refer to Set Up Access List Rules in the hub IM Configuration article for details.

If a hub does not appear in Admin Console, you can create a temporary static route to it. Follow these steps.
1. In Admin Console, expand the primary hub, then open its hub probe in the configuration UI.
2. Select Name Services
3. In the Static Hub List Entry:
Select the Active and Synchronize options
For Hostname/IP, enter the IP address of the secondary hub
4. Select Actions, Create Static Hub
5. Close the configuration UI page.
6. Verify that the secondary hub appears in the navigation pane
Note: We recommend that you connect the hub with a secure tunnel, and remove the unsecured static route.

CA UIM components use queues to pass messages. Messages are placed into queues that are based on their Subject ID. Subject IDs classify
every CA UIM message.
Queues are created automatically during:
Installation, when the hub-to-robot communication is set up
Deployment, when some probes create the queues they require
Hub-to-hub queues must be created manually. If you have secondary hubs in your deployment, create queues so that the hubs can communicate
with the primary hub.
You can create three types of queues:
An attach queue collects messages that are based on subject for forwarding to a get queue. You can create one attach queue to collect
all messages, or create separate queues for different messages.
A get queue retrieves messages collected by an attach queue on another hub.
A post queue sends a stream of messages that are based on subject directly to a destination hub.
The subject attribute of an attach or a post queue determines which messages are directed to the queue:
The wildcard (*) subject collects all messages in one queue.
Queues can collect messages for more than one subject. You can add subjects that are separated by commas (for example, alarms,
alarms2).
Some subjects are reserved for use by CA UIM components. They are listed in Reserved UIM Subject IDs.
Queues are first-in-first-out lists, which means that messages in a wildcard queue are not prioritized by subject. If a hub transfers thousands of
messages each second, a critical alarm message might wait behind less urgent QoS messages.
Note: In a high-volume environment, create separate queues for important subjects, such as alarm, or for subjects that create many
messages. Create one multiple-subject queue for all subjects that are not critical.
To create a hub-to-hub queue, follow these steps:

1. Open the hub probe configuration on the robot and go to Queue List.
2. In the Queue List Configuration table, click New.

3. In the fields below the table, specify the required information. Some fields are specific to the type of queue being created.
Queue Name - Enter a unique and descriptive name. For usability, use a name similar or identical to the subject.
Active - Select if you want the queue to be active immediately.
Type - Select attach, get, or post
Note: The remaining fields in this section are active if they are required for the selected type.
Hub Address (get queues) - Address of the hub that has the corresponding attach queue
Subject (attach or post queues) - Select the subject:
If the subject is asterisk (*), the queue holds all subjects.
If the desired subject is not listed, enter it in the Queue List Entry Subject to Add field, then select Actions, Add Subject to List.
Remote Queue Name (get queues) - the corresponding attach queue
Bulk Size - specify the number of messages to transfer simultaneously. Change the value from default if the queue grows and
never shrinks to zero (see Subscribers Queues on the Status tab). The hub is unable to deliver messages to the target hub fast
enough. Possible reasons are:
The number of QoS messages that are delivered to the hub has increased (See Statistics button on the General tab)
The latency is too high and slows down the deliveries (See Response Check, right-click a hub in the hubs list)
To see an example of how queues can be set up for discovery, see Example Queue.
Reserved CA UIM Subject IDs

The following table contains:
The subjects that are used by CA UIM components
The types of messages that use the subjects
All messages with the same subject have identical data structures.
Subject
Used by
alarm
Alarm messages
alarm2
Enriched alarm messages
alarm_new
Alarm message whose footprint is not previously recorded.
alarm_update
Alarm message whose footprint already exists.
alarm_close
Message that is sent when a client closes (acknowledges) an alarm and removes it from the currently active alarms
alarm_assign
Message that is sent when a client closes (acknowledges) an alarm and removes it from the currently active alarms
alarm_stats
Generated by the NAS probe, statistical event messages that contain the severity level summary information for all open
alarms
audit
Audit messages: probe package distributions and activations
probe_discovery
Device information
QOS_BASELINE
Messages containing baseline data points for QoS metrics
QOS_DEFINITION
Message that specifies a QoS definition
QOS_MESSAGE
All QoS messages
Example Queue
The following example shows how to configure an attach and a get queue pair with the subject probe_discovery. The example demonstrates how
automated discovery data flows up from secondary hubs to the discovery server on the primary hub.

The hub SSL mode specifies the communication mode that is used by hub-managed components. Hub SSL mode is used for robot-to-hub
communication. When hubs are not connected by tunnels, hub SSL mode also controls hub-to-hub communication.
Important! We recommend that server hubs and robots reside behind a firewall, with secondary hubs connected by secure tunnels. In
this configuration, the secondary hubs and robots can use SSL compatibility mode or SSL Only mode.
At startup, the controller creates the UIM_HOME/robot/robot.pem file, which enables SSL communication. The file contains the key
that decodes the encrypted CA UIM messages.
Important! v7.70 of the CA UIM hub and robot have improved the robustness of SSL communication. Before, in a nontunneled domain,
hubs that are configured for unencrypted communication could decode and respond to encrypted messages. In a multiple hub domain,
upgrading to v7.70 breaks this type of communication. See Impact of Hub SSL Mode When Upgrading Nontunneled Hubs in the Hub
Release Notes.
The tunnels that are set up between hubs remain after you upgrade, and communication continues. We strongly recommend that you
connect all hubs with tunnels to ensure the security of communications.
To set the communication mode:

1. Open the hub probe configuration UI on the robot and navigate to Advanced, SSL.
2. Select the mode. UIM hubs have three communication mode options:
Normal (SSL mode 0) No encryption
The OpenSSL transport layer is not used.
Compatibility mode (SSL mode 1) With or without encryption
Enable the hub and robot to communicate without encryption or with OpenSSL encryption. Components first attempt to
communicate through SSL. If a request is not acknowledged, the component sends the request to the target unencrypted.
SSL Only (SSL mode 2) OpenSSL encryption only
Note: We recommend that you use mode 1, compatibility mode. Mode 1 enables secure communication between all components that
support SSL. Communication is still allowed with components that do not support SSL.
v7.80 supports the TLS protocol using TLS cipher suites for the tunnels between hubs and from hub-to-robots.
To only use the TLS cipher suite for Tunnel Server to Tunnel Clients, upgrade all hubs to version 7.80. For communication to
work, specify a cipher suite that resolves to TLS.
To use TLS cipher suites for hub-to-robot SSL settings, specify a cipher suite that resolves to both TLS and SSLv3.
v7.70 and earlier:
To use TLS cipher suites for tunnels, specify a cipher suite that resolves to both TLS and SSLv3.
If you change the tunnel server cipher, restart the tunnel server and tunnel clients to use the new cipher suite.
If you revert the tunnel server to an earlier release, and the clients are using TLS, restart the client hubs.
Control Hub Connectivity Behavior

Default connection values are used when you install a new hub. The defaults are sufficient for most hubs. To adjust the hub connectivity settings
to meet the needs of your deployment or to improve performance:
Hub Settings - control the hub request timeout, update interval, and login mode
Broadcast Configuration - settings that specify whether and where the hub lets other hubs know it is active
Lockout Configuration - settings that avoid leaving the system vulnerable to brute-force password guessing
Robot Settings - specify the alarm that is sent for events that occur on robots that are connected to the hub
Queue Settings - control the behavior and size of queues
To modify the connectivity behavior:
1. Open the hub probe configuration UI on the robot and navigate to Advanced.
2. Modify the settings as needed. Refer to Advanced for details on the settings.
Verify the Status of Other Hubs

To verify the status of another hub within your domain, follow these steps:
1. Open the hub probe configuration UI for any hub in the domain
2. Navigate to Hub List
3. Select the hub to verify in the table showing the domain hub status and other information
4.
4. Click Actions, and click the desired command

Alive Check - to view the status of the selected hub
Response Check - to view the response time (connect, reconnect, and no transfer) between the hub and the one selected in the list
Transfer Check - to transfer data from the hub to the selected hub and view the transfer rate
Log File Settings

All CA UIM probes maintain log files. By default, the log file only records:
Messages that are classified as 0 - Fatal - retains a minimal amount of data
Up to 1024 KB of data.
To increase the logging level, and the maximum size of the log file:
1. Open the hub probe configuration UI on the robot and navigate to the hub node.
2. In General Configuration, set the log level and file size.
3. To activate the changes, click Save at the top of the page.
Migrate User Tags from the Robot to the Hub

To upgrade from a version of the hub before v7.80, hub v7.80 automatically copies user tags from
n:
robot.cfg to hub.cfg on restart whe
No user tags exist in hub.cfg
os_user_retrieve_from_robot is set to true. Default, true

Once the user tags are copied, the option os_user_retrieve_from_robot is set to false in the
hub.cfg file. When the
option is false, the user tags are not copied again. The user can unset the user tags in the hub intentionally, and the tags are not rewritten.
Note: The os_user_retrieve_from_robot option is only configurable using raw configure.
After upgrading to v7.80, existing user tags in robot.cfg continue to propagate automatically. The user tags do not need to be manually
configured in hub.cfg.
Changes to User Tags for Robot Alarms Sent by the Hub

In v7.80, for the special case of alarms that the hub sends about the hub robots:
The default behavior for user tags reverts to the behavior of hub v7.63
The user tags are set to the tags of the robot representing the alarm
The behavior does not apply to other alarms and messages
In v7.80, the output information ensures that the user tags from the source of the alarm are included:
The robot user tags are in the user_tag_1 and user_tag_2 fields
The hub user tags, named context user tags, provide information about the source of the alarm
A new configuration option, named os_user_robot_alarms_use_hub_tags can be set in
The option is missing or is set to 0:
The message reverts to the behavior of hub v7.63 for user_tag_1 and user_tag_2
The option is set to 1:
The message reverts to the behavior of hub v7.70
hub.cfg. When:
Note: The os_user_robot_alarms_use_hub_tags option is only configurable with raw configure.

The configuration change has no effect on robot alarms which come directly from the robot.
Hub-generated robot alarms are the only alarms affected:
robot up
robot down
probe up
probe down
The following table compares the user tag behavior for hub v7.63, v7.70, and v7.80 for the robot alarms.
Consider a hub with user tags hub1 and hub2, and a robot with user tags rob1 and rob2. The robot can be local or remote.
User tags in robot alarms sent by the hub:
Option
Option
OFF
ON
7.63
7.70
7.80
7.80
user_tag_1
rob1
hub1 rob1
hub1
user_tag_2
rob2
hub2 rob2
hub2
context_user_tag_1
N/A
N/A
hub1
rob1
context_user_tag_2
N/A
N/A
hub2
rob2
User tags in other hub alarms and messages processed by the hub spooler (no changes since 7.70):
7.70, 7.80
user_tag_1
hub1
user_tag_2
hub2
v7.8 Hub AC UI Reference

This article describes the configuration information and options available through the Admin Console hub configuration UI. The navigation pane
organizes hub configuration into the following nodes:
Hub
Advanced
SSL
Tunnel Settings
Hub List
Name Services
Queue List
Robot List
Tunnel
1 - Tunnel Server
2 - Tunnel Client
3 - Tunnel Access List
Note: To access the hub configuration interface, select the hub robot in the Admin Console navigation pane. In the Probes list, click the
checkmark for the hub probe, and select Configure.
Hub
To view information about the hub, and adjust log file settings, use the hub node.
Probe Information contains the probe name, the start time, the installed version, and the vendor
Hub Information contains the hub name, domain, IP address, hub address, /domain/hub_name/robot_name/hub, and the length of the
up time
General Configuration is where to modify user tags and log file settings:
Identification property User Tag 1 and Identification property User Tag 2 (Optional)
User tags are optional values that can be attached to probe-generated messages to control access to the data in USM.
On a robot system, user tags are specified in robot.cfg.
As of hub v7.70, user tags on a hub system are specified in hub.cfg. User tags that are defined in robot.cfg are
ignored.
Before hub v7.70, user tags on a hub system are read from robot.cfg.
Default: blank
Log Level specifies the level of alarm information that is saved in the log file.
0 - Fatal (default) logs the least information
5 - Trace logs all alarms
During normal operation, log at a low level to reduce disk usage
Increase the logging level during debugging
Log Size specifies the amount of data that is retained in the log file. Default, 1024 KB
Large log files can cause performance issues and can deplete disk space.
License Information is where to modify the license information for the hub
License contains the current license string.
An invalid license
Messages stop flowing from the hub to the subscribers, typically service probes
The robot spooler does not upload messages
Expire Date contains the date that the license expires. The field is populated automatically.
Licenses Available indicates how many robot licenses are available.
Licenses Total indicates the total number of robot licenses.
Advanced
Use the Advanced node to control the hub connectivity.
Hub Settings controls how the hub communicates
Hub Request Timeout specifies how long the hub waits for a response from other hubs. Default, 30 seconds
Hub Update Interval specifies how often the hub sends messages to other hubs. Default, 600 seconds
Origin identifies the sender for data that is sent from the probes.
The origin is used during report generation.
The origin is obtained from the controller probe configuration.
If the origin is not specified in the controller, the field is blank, and the hub name is used.
Disable IP Validation turns off the hub IP address validation for servers sending requests to probes. Use IP address validation in a
Network Address Translation (NAT) environment.
Login Mode options
Normal (default) permits login from any robot that is connected to the hub
Local Machine Only permits a login only from the server which is hosting the hub
No Login disables login to the hub
Broadcast Configuration controls how the hub lets other hubs know it is active:
Broadcast On (default) enables the hub to broadcast status.
Broadcast Address is the hub broadcast IP address. Default, 255.255.255.255 (the default broadcast address for a local
network).
Lockout Configuration controls the settings for the hub to avoid brute-force password guessing.
Login Failure Count specifies the number of failed attempts which are allowed from a single IP address.
Lockout Time specifies the number of seconds that must pass before a user can attempt to log in after a failure.
Robot Settings controls the alarm settings for events that occur on the robots that are connected to the hub:
Inactive Robot Alarm Severity specifies the alarm level that is sent when a robot fails to respond.
Audit Settings for Robots enable or disable auditing for the hub robots. Each robot can be configured to use custom settings.
Auditing records important events, such as starting and stopping the robot.
Audit Once per User
Queue Settings specifies the behavior and the size of queues.
Reconnect Interval the number of seconds between attempts to reconnect a disconnected hub. Default, 180 seconds.
Disconnect Passive Queues specifies how long a queue can be passive, that is, receive no messages, before disconnection.
Default, 180 seconds
Post Reply Timeout specifies how long a hub waits for a reply to a message.
Alarm Queue Size the size of the queue file on the hub. If the queue exceeds the threshold, an alarm is sent. Default, 10 MB
SSL
Use the Advanced, SSL node to specify the communication mode of hub-managed components.
SSL mode is used for robot-to-hub communication.
When the hubs are not connected with tunnels, the SSL mode is used for hub-to-hub communication.
The hub for a CA UIM component controls the SSL mode that is used by the component.
The hub propagates SSL settings to the robots, and robots propagate the SSL settings to the probes.
SSL settings are specific to each hub.
Set the SSL mode on each hub that requires SSL communications.
Mode
Normal SSL mode 0 No encryption
The OpenSSL transport layer is not used.
Compatibility mode SSL mode 1 the hub and robot can communicate without encryption or can communicate with OpenSSL e
ncryption.
Components attempt to communicate with SSL. If the request is not acknowledged, the communication is unencrypted.
SSLOnly SSL mode 2 OpenSSL encryption
Cypher Type specifies the cipher suite
Note:
Hub v7.80 supports the TLS protocol and TLS cipher suites for hub-to-hub tunnels, and hub-to-robot SSL settings.
To use TLS cipher suites between tunnel servers and tunnel clients:
Upgrade the hubs to v7.80
Select a cipher suite that resolves to the TLS protocol
Hub v7.71 and before, support cipher suites that resolve to both TLS and SSLv3. TLS-only cipher suites are not supported.
If the tunnel server cipher is changed, restart the tunnel server and tunnel clients.
Tunnel Settings
Use the Advanced, Tunnel Settings node to control the behavior of the hub tunnels.
Tunnel Advanced Settings control how tunnels connect
Ignore Controller First Probe Port controls how tunnel ports are assigned.
Enabled the hub uses the First Tunnel Port setting. If the hub has more than one tunnel server, use this setting.
Disabled the tunnel uses the First Probe Port in the controller probe configuration.
First Tunnel Port specifies the port that is used by the first tunnel that you set up. The tunnel server increments the port number for
each additional tunnel, and assigns that port to the tunnel client. The client keeps that port as long as the hub is running.
The server does not manage disconnected clients. If a tunnel client is connected to the server, the number increments. If a
previously used port is available, it is ignored. If there are no active clients, the counter is reset.
If the field is blank, the operating system assigns random ports.
Hang Timeout specifies the interval between attempts to restart the tunnel. The tunnel server continuously monitors the status of the
tunnels. If a tunnel does not respond, the hub continues to attempt a tunnel restart until the tunnel is active. Default, 120 seconds
Tunnel SSL Session Cache controls SSL caching
Use Client Cache / Use Server Cache SSL sessions are cached, and previous session credentials are used. Enable both options to
reduce the server-client connection time.
Server Cache Timeout specifies how long the cached sessions are valid for reuse by the client. Default, 7200 seconds (two hours)
Server Cache Size Default, 1024 KB
Hub List
The Hub List node lists the hubs in a CA UIM domain, displays the hub information, and monitors the hub status.
Hub List provides the following information about each hub:
Domain
Name
Status
Version of the hub probe
Last Updated date and time when the hub probe was last restarted
IP address
Port
To monitor the status of other hubs:
Actions, Alive Check monitor the status of the selected hub.
Actions, Response Check monitor the response time, connect - reconnect and no transfer, between the current hub and the
selected hub.
Actions, Transfer Check transfers data from the current hub to the selected hub, and monitors the transfer rate.
Name Services
Use the Name Services node to connect hubs that are separated by firewalls, routers, or that are in a NAT environment.
Static Hub List Entry enter information about the static route:
Active the route is active
Synchronize the hub sends status information to the static hub
Hostname/IP the address of the static hub
Actions, Create Static Hub sets up the static route
Static Hub List displays the hubs to which there is a static route from the hub being configured:
Active indicates that the route is active.
Synchronize indicates that the hub is sending status information to the static hub
Name, IP, Domain, and Robot Name identify the static hub
Actions, Remove Static Hub removes the selected static hub
Network Aliases specifies the return address for requests from remote hubs in a NAT environment
From Address is the address from which the remote hub sends requests
To Address is the address to which the responses are sent
Queue List
Use the Queue List node to create hub-to-hub queues.
Queue List Entry add a new queue subject
Subject To Add specify the new subject. Some subjects are reserved for use by CA UIM probes. See Reserved UIM Subject IDs.
Actions, Add Subject To List add a queue subject immediately so that it can be used in a new queue
Queue List Configuration enter information for new queues, or view the configuration of the existing queues. Some fields are specific to
the type of queue.
New and Delete add and delete queues
Queue Name the name of the new queue
Active the queue status
Type the type of queue, attach,
Hub Address
(get
post, or get.
queues) the CA UIM address of the attach queue hub
Subject (attach or post queues) the types of the messages to collect in the queue
Remote Queue Name
Remote Queue List
(get
(get
queues) the name of the corresponding attach queue
queues) the list of attach queues that are found in the domain
Bulk Size the number of messages that are transferred in one package
Robot List
The Robot List node lists the hub-controlled robots.
Robot List displays the following information about each robot:
Name
Status
IP address
Version
OS
Robot commands
Actions, Alive Check monitor the status of the selected robot
Actions, Restart restart the selected robot
Tunnel
Use the Tunnel node to enable tunneling on a tunnel server or a tunnel client.
Select Tunnel Active, and click Save to enable tunneling.
1 - Tunnel Server
Use the Tunnel, 1 - Tunnel Server node to configure a hub as a tunnel server.
Certificate Authority (CA) Initialization designate a hub as a certificate authority
Note: Designating a certificate authority is a one-time task. When a certificate authority is specified, Tunnel Server CA Is
Initialized is displayed.
Server Settings the tunnel server status

Active the tunnel is running
Tunnel Server Status whether the tunnel is running or is stopped. Change the status with the Actions command.
Common Name the IP address of the tunnel server
Expiration Days the date the tunnel expires
Server Port the port the tunnel server uses to transfer data. Default, 48003
Security Setting the encryption level for tunneled packets
NONE No encryption, but uses authentication. Fast, and not secure
LOW Fast, but not secure encryption and authentication
MEDIUM Slow but secure encryption and authentication
HIGH Slow but secure encryption and authentication

CUSTOM Slowest but secure encryption and authentication
Custom Cipher * available when the security setting is Custom
CA Certificates create the CA certificates. The hub has the authority to issue client certificates
Organization Name, Organization Unit Name, and Email Address identify the issuing entity
Country Name, State or Province Name, and Locality Name the location of the receiving entity
Common Name the IPV4 or IPV6 address, in hexadecimal format, of the tunnel server hub
Beginning Date and Ending Date when the certificate is valid
Client Certificate Configuration create the client certificates which are required on every tunnel client that connects with the tunnel
server
Organization Name, Organization Unit Name, and Email Address identify the receiving entity
Country Name, State or Province Name, and Locality Name the location of the receiving entity
Common Name the IPV4 or IPV6 address in hexadecimal format, of the tunnel client hub The tunnel client hub must be active when
the certificate is created.
Password specify the password for the tunnel client hub to access the tunnel server
Beginning Date and Ending Date when the certificate is valid
Certificate * the client certificate text. Copy the text to the tunnel client hub configuration.
Actions, Create Tunnel Server Client Certificate create the certificate
Client Certificate List client certificates
New and Delete add and delete certificates
Rows in the table display information about the certificates
Fields below the table display the details for the selected certificate
Certificate * displays the certificate text. Copy and paste the certificate text into the tunnel client hub configuration.
2 - Tunnel Client
Use the Tunnel, 2 - Tunnel Client node to configure a hub to be a tunnel client.
Client Certificate Configuration lets you add, delete, and view tunnel client certificate:
New and Delete add and delete tunnel client certificates.
Certificate ID the number that is assigned to the certificate
Active the certificate status
Server * specifies the IP address of the tunnel server hub
Server Port * the port to use for tunneled data
Check Server 'Common Name' Value the tunnel server verifies that the tunnel comes from the IP address in the client certificate.
Disable the setting in NAT environments. We recommend enabling the setting in other environments.
Description describes the tunnel
Password * the password of the tunnel client certificate
Keep Alive the interval in seconds at which small data packets are sent
Certificate * paste the client certificate text from the tunnel server hub
Use the Tunnel, 3 - Tunnel Access List node to restrict the access privileges for CA UIM users, addresses, and commands.
Use Infrastructure Manager to configure tunnel access lists.
Tunnel Access List create tunnel access lists

New and Delete create or delete an access list
Source IP * the IP address of the tunnel server, or the wildcard character (*).
Destination Address * the address of the target hub, robot, or probe
Probe Command the specific command to allow or deny. To find the command set, click the checkmark next to the hub probe, and
select Probe Utility.
User * allow or deny access (a regular expression is allowed)

Mode * settings specify the access mode:
ACCEPT access for the specified user, command, or probe
DENY access for the specified user, command, or probe
LOG all requests through the tunnel with information recorded when the access list is processed.
Note: Log is typically used for testing commands against targets. The result is recorded in the hub log file.
v7.8 Hub IM Configuration
This article explains how to use Infrastructure Manager (IM) to configure a hub. For an overview of the hub, see hub.

Reserved UIM Subject IDs
Example Queue
Set up the Tunnel Server
Create the Client Certificate
Set up Access List Rules (Optional)
Install the Client Certificate
Set up a Tunnel in a NAT Environment
Check Traffic Statistics
Monitor the Message Flow
Advanced Configuration for Alarms, LDAP, and Passive Robots
Alarm Configuration
LDAP Configuration
Passive Robot Configuration

Hubs discover other hubs by sending out broadcast (UDP) messages. Nonprimary hubs that are separated from the primary hub by routers or
firewalls cannot discover other hubs over UDP. Configure a static route between the hubs. Static routes are used to:
Connect two hubs that are in the same environment, that reside on different network subnets.
Connect to a hub outside a firewall so that you can create a secure tunnel to the hub.
Important! Do not connect a hub with both a tunnel and a static route.
In some situations, data can be transmitted over the insecure static route rather than over the secure tunnel.
Delete static routes that are used to configure a tunnel. Do not retain static routes when tunnels exist.
Follow these steps to create a static route to a hub.

1. Open the hub IM configuration GUI on the local hub.
2. Click the Name Services tab.
3. In the Static Hubs section, click New.
In the New Static Hub dialog:
Enable Active.
3.
Disable Synchronize on slow networks. Disabling synchronization reduces the network traffic. Disable this option on both hubs.
Enter the IP address of the static hub. The system fills in the Hub Information fields (hub name, domain, and robot name) with the
information retrieved from the remote hub.
4. Click OK. The static route is created and the hub appears in the list of static hubs.
To delete a static route, select it and click Delete.

CA UIM components use queues to pass messages. Messages are placed into queues that are based on a Subject ID. Subject IDs classify every
CA UIM message.
Many queues are created automatically:
During installation, when the hub-to-robot communication is set up
During deployment, when some probes create required queues
Manually create hub-to-hub queues. Create queues to enable the communication between primary and nonprimary hubs.
Three types of queues:
An attach queue collects messages that are based on subject. The messages are forwarded to a get queue on another hub. You can:
Create one attach queue that collects all messages
Create separate attach queues for messages with different subjects
A get queue retrieves the messages collected by an attach queue on another hub.
A post queue sends a stream of messages that are based on subject directly to a destination hub
The subject of an attach or a post queue determines which messages are directed to a queue:
The wildcard (*) subject collects all messages in one queue
Queues can collect messages for more than one subject. Add subjects by separating them with commas, for example, alarms, alarms2.
Some subjects are reserved for CA UIM components. See, Reserved UIM Subject IDs.
Queues are first-in-first-out lists. Messages in a wildcard queue are not prioritized by subject. If a hub transfers thousands of messages per
second, a critical alarm message can wait behind a minor QoS message. In a high-volume environment, create separate queues for important
subjects, such as alarm. Create one multiple-subject queue for subjects that are not critical.
Follow these steps to set up a hub-to-hub queue.
Note: The type of queue you select determines which fields are active in the New Queue dialog.
To create attach and get queues:

1. On the attach queue hub:
a. Navigate to the hub and double-click the hub probe to open the hub configuration GUI.
b. Click the Queues tab.
c. Click New, and specify:
Active - enabled
Name - name of the queue (the name must match the name of the get queue)
Type - attach
Subject - select a subject or wildcard (*)
2. On a get queue hub:
c. Click New, and specify:
Active - enabled
c.
Name - name of the queue

Type - get
Address - select the address of the hub with the attach queue
Queue - name of the attach queue
Bulk size - specify the number of messages to be sent together (optional; if you expect the queue to carry a significant number of
messages, sending them in bulk can improve performance)
To create a post queue:
1. Navigate to the hub and double-click the hub probe to open the hub configuration GUI.
2. Click the Queues tab.
3. Click New, and specify:
Active - enabled
Type - post
Address - select the address of the hub to receive the messages
Bulk size - specify the number of messages to send together (optional; if you expect the queue to carry a significant number of
To see an example of how queues can be set up for discovery, refer to Example Queue.

The following table shows the subjects that are used by CA UIM components, and the types of the consuming messages. Messages with the
same subject have identical data structures.
Subject
Used by
alarm
Alarm messages
alarm2
alarm_new
Alarm message whose footprint is not previously recorded.
alarm_update
Alarm message whose footprint already exists.
alarm_close
Message that are sent when a client closes (acknowledges) an alarm, and removes it from the currently active alarms.
alarm_assign
Message that are sent when a client closes (acknowledges) an alarm, and removes it from the currently active alarms.
alarm_stats
NAS probe Statistical event messages. The messages contain the severity level summary information for open alarms.
audit
Audit messages: probe package distributions, activations, and other audit messages.
probe_discovery
Device information
QOS_BASELINE
QOS_DEFINITION
QOS_MESSAGE
All QoS messages
Example Queue
The following example shows how to configure an attach and a get queue pair with the subject probe_discovery. Automated discovery data flows
from the nonprimary hubs to the discovery server on the primary hub.

Many environments include one or more firewalls. Firewalls provide protection between internal networks, and external protection from the
Internet beyond a DMZ.
To monitor an entire network, create a secure shell (SSH) tunnel between two hubs that are separated by a firewall. The tunnel uses a Virtual
Private Network (VPN) connection between the two hubs. Requests and messages are routed through the tunnel, and are dispatched on the
other side. The routing is transparent to the users.
Tunnels can be created during hub installation, or afterward by configuring the hubs.
To set up a tunnel between two hubs that are already installed:

1. Determine the tunnel server hub. A central hub can be the primary hub, or a nonprimary hub that is directly connected to other hubs. If a
central hub is attached to remote hubs, make the remote hubs the tunnel servers. This configuration minimizes the overhead on the
central hub.
The Tunnel Server is the hub that initiates the setup of the tunnel.
The Tunnel Client accepts the setup the tunnel.
2. Ensure that both hubs appear in the navigation tree. Hubs discover each other by sending out broadcast (UDP) messages. Configure a
static route to hubs that do not appear in the CA UIM navigation tree.
3. Set up the tunnel server as a certificate authority (CA) to create a server certificate. The CA can generate client certificates.
4. Create the certificate for the tunnel client on the tunnel server.
5. Install the certificate on the tunnel client.
6. If a static route exists between the tunnel server and the tunnel client, delete it.
7. Create queues between the hubs.
8. Optional: On the tunnel client, set up access list rules to restrict access to specific CA UIM addresses, commands, or users.
Note: Network Address Translation (NAT) networks affect how a tunnel is configured. For examples, see Setting up a Tunnel in a NAT
Environment.
Set up the Tunnel Server

On the tunnel server hub:
1. In Infrastructure Manager, navigate to the tunnel server hub. Open the hub probe in the configuration GUI.
2. On the General tab, select Enable Tunneling.
3. Click the Tunnels tab, and click Server Configuration.
4. Select Active.
5. In Certificate Authority Setup, enter your organization information:
Who (optional) - Company name, Organization unit, and e-mail address of your administrator
Where (optional) - Country, State and Community of your organization
Authentication (required):
Common Name - Host name of the tunnel server hub
Password - Password for the certificate
Expire days - How long the CA is valid
6. Click OK. The hub is now a CA and the server certificate is generated. The tunnel server generates client certificates. The server
certificate is the basis for all the client certificates.
7. Select a security setting - None, Low, Medium, High, or Custom. Use Custom to define your own security setting. See, www.oenssl.org/d
ocs/apps/ciphers.html
8. Click Apply to activate the tunnel server.

When the tunnel server hub is configured to be a CA, you can create client certificates. To create client certificates on the tunnel server hub:
1. In Infrastructure Manager, locate the tunnel server hub. Open the hub probe in the configuration GUI.
2. On the Tunnels tab, navigate to Server Configuration. Click New.
3. In the Client Certificate Setup, enter your information:
Who (optional) - Company name, organizational unit, and administrator email address
Where (optional) - Company location
Authentication (required) - Enter the following information:
Common name - IP address of the tunnel client hub
Password - Create a password to be entered when you install the certificate on the tunnel client hub
Expire days - Number of days the certificate is valid
4. Click OK.
5.
5. In the Issued Certificates field, click View to display the certificate information.
6. Click Copy. Open a text editor, such as Notepad, and paste the certificate into a new file. Save the file to a location where the tunnel
client can access it. Exit Certificate Information.
7. Click Apply, and click Yes to restart the probe.
Set up Access List Rules (Optional)

Use the Access List to define rules to restrict access to specific CA UIM addresses, commands, or users. The Access List is defined on the tunnel
client hub.
Three types of rules:
Accept rules allow access. Create rules to grant access to a probe, a robot, or a hub, or to execute commands for specific users.
Deny rules disallow access to the specified addresses, commands, or users.
Log rules log requests through the tunnel. Use log rules for testing accept or deny rules. The results are logged in the hub log file,
log.
For high restrictions, start with the accept rules, then create a deny rule to deny access to all others.
For low restrictions, start with the deny rules, then create an accept rule to grant access to all others.
Rules can contain regular expressions.
To add a rule:
1. Open the Access List tab.
2. In Edit Rule, enter:
Source IP - IP address of the source hub, robot, or probe
Destination Address - IP address of the target hub, robot, or probe
Probe Command - the specific command to allow or deny. Use the Probe Utility to view the probe command set.
User - the user to allow or to deny access
3. Select the mode - Accept, Deny, or Log
4. Click Add. The rule is added to the rule table.
In the rule table, use Move Up and Move Down to change the rule priority.
5. Click Apply to activate the rule list.

Follow these steps:
1. In Infrastructure Manager, navigate to the tunnel client hub. Open the hub probe in the configuration GUI.
3. Click the Tunnels tab, and click Client Configuration.
4. Click New. In the New Tunnel Connection dialog:
Select Active Tunnel and Check Server Common Name
Enter the IP address of the tunnel server hub
Enter the password that you provided when you created the certificate
Paste the certificate text from the file you saved it to, into the Certificate field.
Enter the server port. When this field is blank, the system assigns the port.
(Optional) Specify a keep-alive interval.
Click OK to close the dialog.
5. Click Apply to activate the tunnel client.
hub.
Networks that use Network Address Translation (NAT) affect how a tunnel is configured.
The following scenarios describe three possible configurations.
Important! When a tunnel is configured, the tunnel replaces the static hub and NAT setup in the hub configuration.
Client address in NAT environment
The client certificate must be issued to the common name that is visible to the server. In this case, that is
10.2.1.111, and not 193.71.
55.111.
Server address in NAT environment
Clear Check Server Common Name in Tunnel Client Setup to disable server common name checking. The client sees 202.1.1.1, but the
server certificate contains the common name 10.1.1.1. If server common name checking is enabled, the communication fails.
Server and Client addresses in NAT environment
Combine the two previous methods:

The client certificate must be issued to the common name that is visible to the server.
Clear Check Server Common Name in Tunnel Client Setup to disable server common name checking.

Hub-managed components use the hub SSL mode. The hub SSL mode is primarily used for robot-to-hub communication. When hubs are not con
nected by tunnels, the hub SSL mode is also used for hub-to-hub communication.
SSL communication is enabled through the UIM_HOME/robot/robot.pem certificate file. The controller creates this file during
startup. The file contains the key to decode encrypted CA UIM messages.
Important: The robustness of SSL communication is improved in v7.70.
Before, in a nontunneled domain, hubs that are configured for unencrypted communication can decode encrypted messages.
In a multiple hub domain, upgrading to v7.70 does not allow this scenario. See, Impact of Hub SSL Mode When Upgrading
Nontunneled Hubs in the Hub (hub) Release Notes.
Note: Any tunnels set up between hubs remain after you upgrade, and communication will continue.
We strongly recommend that you connect all hubs with tunnels.

1. In Infrastructure Manager, expand the hub robot, and open the hub probe in the configuration GUI. Select the General tab, and click Setti
ngs in the lower right corner.
2. Select the SSL tab.
Normal SSL mode 0 Unencrypted The OpenSSL transport layer is not used
Compatibility mode SSL mode 1 The hub and robot to communicate without encryption or with OpenSSL encryption.
Components first attempt to use SSL. If a request is not acknowledged, the component sends unencrypted requests.
SSL Only SSL mode 2 OpenSSL encryption only
Wherever possible, we recommend that you use mode 1, compatibility mode. Compatibility mode enables secure communication between the
components that support SSL, and unsecure communication for any other components.
Note: Hub v7.80 supports the TLS protocol by using TLS cipher suites for tunnels between hubs, and hub-to-robot SSL settings.
To restrict tunnel communication to TLS cipher suites, upgrade the hubs to v7.80. Select a cipher suite that resolves to TLS.
To use TLS with hubs that are at v7.71 and earlier, use a cipher suite resolving to TLS and SSLv3.
To use a TLS cipher suite for hub-to-robot SSL settings, use a cipher suite resolving to TLS and SSLv3.
Restart the tunnel server and tunnel clients when:
The tunnel server cipher suite is changed
The tunnel server hub is reverted to a prior release and the tunnel clients are using a TLS cipher suite

View traffic statistics to avoid bottlenecks, and to tune the CA UIM system. Statistics are available for the previous 30 days.
To view traffic statistics:
1. Click Statistics in the lower right corner of the configuration GUI.
2. View the total hub managed traffic:
Messages that are sent per minute
Messages that are received per minute
Requests per minute
3. To view the data for a specific period, change the dates and click Get.

To study the message flow through the hub:
1. Click Monitor in the lower right corner of the hub GUI.
2. In the Monitor window, click Traffic, Sniffer, or Tunnel to view the traffic.
Traffic graphs the number of messages that are sent, received, and requested per second. Two traffic lists are available:
Subscribers shows the permanent queues that are defined on the Queues tab.
Subjects shows all subjects that are defined for the queues.
Sniffer lets you filter the information by subject, probe, or robot:
a. Enter your filter criteria.
b. Click Start. All messages matching your filter criteria are listed, with the most recent message first.
c. Select a message in the list to open a callout containing information about the message. The information can include:
QoS name
QoS source
QoS target
Time of the sample
The sample value
Tunnel allows you to view the active tunnel commands. Click Start to view the following information for each command:
IP address and port number of the client that executed the command
Start and stop time for the transfer
Total time of the request through the tunnel (both directions)
UIM address where the command was sent

Last command that is issued during the message transfer
Number of bytes sent and received during the session

Advanced configuration through the Raw Configure utility lets you add keys to the hub configuration to tune hub performance.
1. In Infrastructure Manager, select the hub probe.
2. Ctrl+right-click the hub probe, and select Raw Configure.
3. Select the hub section, and use New Key, Edit Key, and Delete Key to modify the keys.
4. Close the utility when you are finished.
See the following sections:
Alarm configuration
LDAP configuration
Passive Robot configuration
Alarm Configuration
Advanced alarm configuration lets you trigger alarms in certain situations. Add alarm keys to the hub section.
You can trigger alarms to:
Send an alarm when there are a significant number of subscriptions or queues (which can decrease hub performance). Specify:
subscriber_max_threshold - the number of subscribers that triggers an alarm
subscriber_max_severity - alarm severity
Send an alarm when a queue reaches a certain size. Specify:
queue_growth_size - queue size that triggers an alarm
queue_growth_severity - alarm severity
queue_connect_severity - severity of queue connect failures

Force the hub to restart if a tunnel is hanging and is not being able to reconnect. Specify:
tunnel_hang_timeout - hang time that triggers an alarm
tunnel_hang_retries - number of times the tunnel tries to reconnect before the hub is restarted
The hyper-text transfer protocol daemon probe (httpd), is a simple http server. Use httpd to share information across the intranet.
LDAP Configuration
You can add two keys in the
/LDAP/server section of hub.cfg to affect how the hub communicates with the LDAP protocol.
Timeout specifies the number of seconds to spend on each LDAP operation, such as searching or binding (authentication) operations.
Default, 15 seconds
codepage is used to translate characters from UTF-8 encoding to ANSI. When text comes from the LDAP library as UTF-8, the
codepage translates the characters into ANSI.
Windows - Specify a valid codepage. The hub LDAP library uses the MultibyteToWideChar and WideCharToMul
tiByte
functions to translate between ANSI and UTF-8. The functions take a codepage as a parameter. Default,
Unix - Use iconv functions. See, http://www.gnu.org/software/libiconv. Default,
28591
ISO-8859-1
Note: The codepage key is not shipped with the hub configuration file. The default codepage is ISO
8859-1 Latin
1; Western European (ISO).

Advanced configuration lets you control how a hub communicates with passive robots. Add any or all the following keys to the hub section:
Key
Description
Default
passive_robot_threads
The hub communicates with a robot through worker threads from a thread pool. We recommend
setting the pool to 50 percent of the number of passive robots.
10
passive_robot_interval
The number of seconds between trying to retrieve messages from a passive robot
15
seconds
passive_robot_messages
The number of messages the hub accepts from a passive robot in a single retrieval interval
1000
passive_robot_comms_timeout
The amount of time the comms API blocks a call to a robot that is not responding.
15
seconds
passive_robot_max_interval
The interval between retrying an unresponsive passive robot doubles every 10 minutes up to
this value.
passive_robot_restart_wait
Number of seconds the hub waits for passive robot management threads to stop before killing
the threads.
Important! To avoid monitoring delays, seek the advice of Support before modifying
the key.
v7.8 Hub IM GUI Reference

To access the Infrastructure Manager hub configuration GUI, select the hub then either:
60
seconds
Right-click the hub and select Configure.

Expand the robot, and double-click the hub probe.
This article describes the tabs, fields, and options available in the Infrastructure Manager hub configuration GUI.
General Tab
Hub Advanced Settings
General Advanced Settings
SSL Advanced Settings
LDAP Advanced Settings
Hubs Tab
Robots Tab
Name Services Tab
Queues Tab
Tunnels Tab
Server Configuration
Client Configuration
Access List
Advanced
Status Tab
General Tab
The General tab contains basic hub information:
Hub information
Hub name
Domain - to which the hub belongs
Hub IP address
Hub address - UIM format:/domain/hub_name/robot_name/hub
Version - number and distribution date of the hub probe
Uptime - length of time from the last restart
Modify - open Edit Hub Address. Edit the hub name and the domain name. If these parameters are modified, the hub controller
probe restarts.
License information - A hub maintains the licenses for all the connected robots.
When the license is invalid:
The message flow from the hub to the service probes and other subscribers stops
The messages from the robot spoolers stop
The license key contains the following fields:
Licenses in use - the number of robots that are connected to the hub, and the number of robots the license allows.
Expire date - when the license expires. An asterisk (*) indicates an unlimited license.
Owner - The owner of the license
Modify open Edit License. License keys are provided by CA and must be entered exactly.
Log in Settings for this hub
Normal (login allowed) - allow users to log in to the hub from any robot.
Local machine only - allow normal logins from the hub server. Attempts to log in from remote robots are refused
No login - disable local or remote login to the hub.
Log Level - specify the level of detail that is written to the log file. To reduce the disk usage, log at a low level. Increase the logging level
for debugging.
Log Size - the size of the log file. Default, 1024 KB
Advanced - view and configure advanced options for the hub
Enable tunneling - activate the Tunnel configuration tab. To disable tunnels, clear the option, and click Apply.
Disable IP validation - use this option with Network Address Translation (NAT). See, Setting up a Tunnel in a NAT Environment.
Statistics - display the traffic statistics for the hub for the previous 12 hours
The graph shows the number of messages that are sent and received per minute, and the number of requests. Specify a time period
in the Period section. Click Get to update the values.
See, Checking Traffic Statistics.
Monitor - display the current hub traffic. See, Monitoring the Message Flow.
View Log - display the contents of the hub log file. Use the log settings to set the level of detail. The Log Viewer window contains:
File - save or print the file
Edit - copy the contents and search in the log file
Actions - limit the output in the window, and highlight text or dates within the log file
Start and Stop - start and stop the log file updates
Settings - open Hub Advanced Settings See, Hub Advanced Settings.
General, Settings
The Hub Advanced Settings dialog contains three sections:
General
SSL
LDAP
The General tab

Broadcast On - Hubs use a UDP broadcast to tell other hubs that they are alive. Use the option to turn the broadcast on and off. You
can specify the hub broadcast address. Default, 255.255.255.255
Hub Settings
Hub Request Timeout - the timeout value for hub communication requests. Default, 30 seconds
Hub Update Interval - the interval at which the hub sends status information to the other hubs. Default, 600 seconds
Queue Settings
Reconnect Interval - the interval at which a disconnected queue is reconnected. Default, 180 seconds
Disconnect passive queues - the interval at which passive queues (no messages) are disconnected. Default, 180 seconds
Post Reply Timeout - the length of time a hub waits for a reply to a message. If no response is received within this interval, a timeout
occurs.
Alarm on queue size - the size of the queue file (in MB) on the hub. If the queue exceeds this threshold, an alarm is sent. Default, 10
MB
Lock Out Time
The hub implements extra security measures to avoid leaving the system vulnerable to brute-force password guessing.
If the number of consecutive login failures from a user or an IP address reaches the Lock After Fails value, login is blocked
until the Lock
Out Time expires.
Important! These changes are not persistent. The changes do not survive a hub restart.
Origin - where a message comes from. QoS messages from probes are tagged with a name to identify the origin of the data. By default,
the origin is the name of the parent hub of the probe.
To override the origin value:
Change the value. The new value is used for hub-managed QoS messages.
Set the origin at the robot level. Use Setup, Advanced in the controller configuration GUI.
Audit Settings for Robots - specify the recording of important events, such as starting and stopping the robot. The setting is used for all
hub robots. Select one of the following options:
Override: audit off
Override: audit on
Use audit settings from robot
Hub, Settings, SSL

Use the SSL tab to configure the hub SSL mode. The SSL mode specifies the communication mode for hub-managed components. The SSL
mode is primarily used for robot-to-hub communication. When hubs are not connected by tunnels, the SSL mode controls hub-to-hub
communications.
The hub controls SSL settings for UIM components. The hub propagates SSL settings to the robots. The robots propagate SSL settings to the
probes. SSL settings are specific to each hub. Set the SSL mode on each hub.
Note: Hub v7.80 supports the TLS protocol by using TLS cipher suites for tunnels between hubs, and hub-to-robot SSL settings.
To restrict tunnel communication to TLS cipher suites, upgrade the hubs to v7.80. Select a cipher suite that resolves to TLS.
To use TLS with hubs that are at v7.71 and earlier, use a cipher suite resolving to TLS and SSLv3.
To use a TLS cipher suite for hub-to-robot SSL settings, use a cipher suite resolving to TLS and SSLv3.
Restart the tunnel server and tunnel clients when:
The tunnel server cipher suite is changed
The tunnel server hub is reverted to a prior release and the tunnel clients are using a TLS cipher suite
Mode provides three options:

Normal SSL mode 0 Unencrypted The OpenSSL transport layer is not used
Compatibility mode SSL mode 1 The hub and robot to communicate without encryption or with OpenSSL encryption.
Components first attempt to use SSL. If a request is not acknowledged, the component sends unencrypted requests.
SSL Only SSL mode 2 OpenSSL encryption only
Cipher Type specifies the Cipher Suite that is used by the OpenSSL library.
Configuration options for LDAP:

Direct LDAP
Configure the hub to forward login requests to an LDAP server. Users log in to the UIM console with LDAP credentials. Users belonging
to different groups in LDAP can be assigned to different UIM Access Control Lists (ACLs).
Note: Due to the limited availability of the LDAP library, Direct LDAP is only available on Linux and Windows hubs. Native
LDAP is not supported on Solaris.
LDAP authentication includes:

Server Name - Configure the hub to point to a specific LDAP server, using IP address or host name. Use Lookup to test the
communication. If you use a nonstandard port for the hub, use hostname:port to specify the LDAP server.
Note: You can specify multiple LDAP servers in this field. Separate each server with a space. The first entry is the primary
LDAP server. More entries are secondary servers, which are used when the primary server is unavailable. If a nonprimary
server is used, logins can take more time.
Server Type - two LDAP server types are supported: Active
Directory and eDirectory
Authentication Sequence - the hub authentication sequence If you select Nimsoft, LDAP, the user is verified against Nimsoft user
credentials first. If verification fails, the hub attempts to verify using the LDAP server.
Use SSL - use SSL for LDAP communication. Most LDAP servers are configured to use SSL.
User and Password - the user name and password that is needed for querying the LDAP server
Active Directory - the user is specified as an ordinary user name
eDirectory - the user is specified as a path to the user in the format CN=yyy,O=xxx. CN is the user name, and O is the
organization.
Group Container (DN) - a group container in LDAP which defines where, in the LDAP hierarchy, to search for groups. Click Test to
verify that the container is valid.
User Container (DN) - a user container in LDAP which defines more specifically where to search for users in the LDAP structure.
Nimsoft Proxy Hub - The hub can be configured to specify a UIM probe address for login.
Proxy Hub - The drop-down list is empty by default. Click Refresh next to the drop-down list to perform a gethubs probe request
on the hub. The drop-down list is populated with a list of known hubs.
Proxy Retries - the number of retries to perform when there are communication errors.
Authentication Sequence - if you select Nimsoft, LDAP, the user is verified against Nimsoft user credentials first. If the
authentication fails, the hub tries to verify the credentials using LDAP server credentials.
Proxy Timeout - the time (in seconds) before the proxy is timed out.
Hubs Tab
The hubs tab lists all the known hubs, and displays information in different colors.
Blue - The hub is in the same domain as the hub you are currently logged in to.
Black - The hub is outside the current domain.
Red - The hub status is unknown. Typically, red is displayed when the hub is not running.
The hub list contains the following information about each hub:
Status indicator:
Green - running
Red - not running
Yellow - status unknown
Domain
Hub name
Updated: shows when the hub was last updated
IP address for the hub
Port number for the hub
Right-clicking in the window displays four options:
Alive Check rechecks the status of the selected hub.
Response Check checks the response time (connect - reconnect, no transfer) between your hub and the one selected in the list.
Transfer Check transfers data from your hub to the selected hub, then checks the transfer rate.
Remove removes the selected hub from the hubs address list. If the hub is running, it can appear later.
Robots Tab
The Robot tab lets you set the alarm level for robots and displays robot information.
Inactive Robot Setup - If one of the robots that are listed is unavailable, set the severity level of the alarm that is issued.
Registered Robots displays the following information for each robot:
Name
Type - regular or passive
IP address
Version of the robot software
Created - when the robot was installed
Last Update - when the software was last updated
Operating system of the robot host system
Right-click in the window to open a menu with the following options:

Restart - reread the configuration file for the selected robot
The robot is not restarted. If you change the robot configuration, restart the robot.
Check - checks the communication with the selected robot
Remove - the selected active or passive robot is removed from the list An active robot can show up later because active robots
periodically request that the hub add them to the Registered Robots list.
Add Passive Robot - open the dialog to add a passive robot
Name Services Tab

A hub knows the IP address and port number of the probes started by the robots that it controls. The robots are responsible for reporting
configuration changes and probe state to the hub. When a client sends a request to a probe, it asks the local hub for the address. If the target
probe is on another hub, the request is forwarded to that hub. If the name lookup succeeds, the client sends the request to the probe.
Static Hubs
The hubs discover each other by sending out broadcast (UDP) messages. Hubs that are separated by routers and firewalls are typically
unable to discover other hubs with UDP. In this situation, you can configure a static route to the hubs.
Note the Synchronize option in the New Static Hub dialog. If the synchronize option is selected, the parent hub sends status information
to the static hub. The parent hub receives status information from the static hub, unless you also disable the Synchronize option on the
static hub. You can disable the synchronize option to reduce network traffic.
Important! Do not connect hubs with both a tunnel and a static route. In some situations, data is transmitted over the insecure
static route rather than over the secure tunnel. If you create a tunnel between two hubs, delete any existing static routes.
Network Alias - the return address of a remote NAT hub
On hub A, set up the From address and the To address for
On hub
When hub
B, set up the From address and the To address for hub A.

B sends a request to hub A, the request contains the hub B From address. Hub A uses the hub B To address to
B.
return a request to hub
Queues Tab
hub B.
The Queues tab lists the defined message queues.

Queues that are automatically created
Queues that you manually create
For example, to send alarms from a nonprimary hub to the primary hub, create an attach queue,
alarms.
nas, with the subject alarm to forward
To edit a message queue, double-click the message queue, or select the message queue and click Edit.
To define a new queue, click New.
A queue is a holding area for messages passing through the hub. Queues are temporary or permanent:
Permanent queue - content survives a hub restart
Permanent queues are used by service probes to receive all messages. If the service probe is not running, the messages are held in
the queue. When the probe starts, the messages are delivered.
Temporary queue - content is cleared during restarts
Temporary queues are typically used for events that are sent to management consoles.
All queues that are defined on the Queues tab are permanent queues. Permanent queues have a name that is related to their purpose. The
permanent queue, NAS, is attached to the Nimsoft Alarm Server (NAS).
You can create a permanent queue between two hubs. Define the queue as a post type queue. Use the full UIM address of the other hub.
A Post queue sends a directed stream of messages to the destination hub.
An Attach queue creates a permanent queue for a client Get queue to attach to.
A Get queue receives messages from a permanent Attach queue on another hub.
For example, the following queue, named get-hub-4, is defined as a Get queue.
get-hub-4 receives messages from the Attach queue xprone-attach
xprone-attach is defined on the remote hub /HubTest/wm-hub-4/vm-hub-4/hub.
The New Queue dialog contains the following fields:

Active - Select this option to activate the queue. The active state is reflected in the queue list under the Queues tab. You can activate
and deactivate queues using the queue list.
Name (Required) - a unique and descriptive identifier for the queue.
Type (Required)
Post - send a directed stream of messages to the destination hub
Attach - a permanent queue that a remote get queue attaches to
Get - receives messages from a remote attach queue
Address - the UIM address of the source or target hub
Get and post queues only
Select the UIM address from the drop-down list
Queue (Applies to get queues) - specify the remote attach queue to receive messages from
Subject (Applies to attach or post queues) - specify the message subjects to send to the queue
Use an asterisk (*) as the subject to send all the messages
All UIM messages contain a Subject ID that classifies the message on the message bus. Components use Subject IDs to subscribe to
some messages and ignore others. All messages with the same Subject ID have the same data structure.
Tunnels Tab
Select the Enable Tunneling option on the hub, General tab to enable the Tunnels tab.
Authorization and Authentication

Tunnels use certificates to provide authorization and authentication. The client and the server require valid certificates from the same
Certificate Authority (CA). The tunnel server is the CA, and only accepts certificates it issues.
Security Settings
Use security settings to specify the level of encryption for a tunnel. The encryption settings range from None to Custom. When None is
selected, the traffic is authenticated, and is not encrypted. No encryption is safe for tunnels within LANs and WANs. Higher encryption
levels require greater resources.
Important! Delete existing static hubs in Name Services when you are using tunnels.
The tunnels tab contains four sections:

Access List
Advanced
Use the server configuration tab to configure the listening side of a tunnel.
Active - activate the tunnel server
When Active is selected, the Certificate Authority Setup dialog opens. See, Setting up a Tunnel.
Common name - the IP address of the tunnel server hub
Expire date - the date the server certificate expires
Port - the port that the tunnel server is listening on Open this port in your router or firewall for incoming connections.
Security settings - select None, Low, Medium, High, or Custom. Use the Custom setting to define the security protocol. See, http://ww
w.openssl.org/docs/apps/ciphers.html
Start and Stop - start and stop the tunnel server
Server - display the server details and the server certificate
CA - display the CA details and CA certificate
New - open the Client Certificate Setup dialog. You can create certificates for the clients you open for access. Supply a certificate
password. The client requires the password, the certificate (encrypted text), and the server port number.
Delete - delete the selected client certificate

View - display the selected client certificate
Use the client configuration tab to configure the connecting side of a tunnel.
Server - tunnel server IP address or hostname
Port - tunnel server port number
Heartbeat - Keep-alive message interval
Description - description of the tunnel connection
New - Open New Tunnel Connection You can create a new tunnel connection to the server that has generated the certificate.
Active Tunnel - Activate the tunnel connection
Check Server CommonName - Clear this option to disable the Server IP address verification (see, Setting up a Tunnel in a NAT
Environment).
Description - description of the tunnel connection
Server - IP address of the tunnel server
Password - the password that you received with the server certificate
Server Port - the server communication port Default, 48003
Keep-alive interval - small data packets are sent at the specified interval
Certificate - paste the client certificate in this field See, Creating Client Certificates for more information.
Edit - edit the selected server connection
Delete - delete the selected server connection
Certificate - display the selected client certificate
Access List
By default, all requests and messages are routed through the tunnel. The routing is transparent to CA UIM users.
Use the Access List to set access rules for tunnels. Define the rules to restrict the access privileges for UIM addresses, commands, and users.
Access Lists are defined on the tunnel client hub.
Access list rules:
Accept rules enable access. Set up rules to grant access to probes, robots, and hubs, and to execute specific commands for users.
Deny rules disallow access for the specified addresses, commands, or users.
Log rules log all requests through the tunnel. Use log rules for testing. View the results in the hub log file.
Use Edit Rule to add, modify, or delete access rules. Access rules consist of four criteria. When all four criteria are met, the rule is
triggered.
Source IP is the name of the source hub, robot, or probe.
Destination Address is the address of the target hub, robot, or probe.
Probe Command is the specific command to allow or deny. The command set varies by probe. To view a command set, open the
Probe Utility.
User is the user to allow or deny access.
Note: Regular expressions are allowed.
The rules table displays the rules that you have created. The order of the rules is important. The first rule in the list is processed first.
Processing stops on the first rule that matches all four criteria.
Use the Move Up and Move Down buttons to change the order of the rules in the list.
Advanced
Use the advanced tab to assign the first tunnel port, establish the hang timeout, and configure the SSL session cache.
Ignore first probe port settings from controller
The first tunnel is automatically assigned the port number in First Probe Port Number on the Setup, Advanced tab in the controller co
nfiguration.
If more than one tunnel is defined, select this option to enable the First Tunnel Port field.
First Tunnel Port
For more than one tunnel, you can specify the first port in the range of ports to be used.
When this field is blank, the operating system assigns random ports.
Clients are assigned ports from the configured port range, and keep the port as long as the hub is running.
Servers assign ports from the configured port number and increase for each new client connection. If there are no active
clients, the hub resets the counter.
Tunnel is Hanging Timeout
The hub continuously checks if one or more of the active tunnels are hanging. No new connections can be established through tunnels
that are hanging.
If a tunnel is hanging, the hub attempts to restart the tunnel. If the restart fails, the hub performs a restart after the specified number of
seconds.
SSL Session Cache
Use Server Cache enables caching of SSL sessions, and reuse of session credentials. If Use Client Cache is enabled on the client,
Use Server Cache speeds up the connection time.
Server Cache Timeout defines how long the cached sessions are valid for reuse by the client.
Server Cache Size defines how many sessions can be stored in the cache. When the cache is full, the oldest sessions are deleted as
new connections are established.
Use Client Cache enables caching of SSL sessions on the client hub.
Status Tab
This tab contains four subsections that provide status information about the queues, subjects, and tunnels you have defined.
Subscribers/Queues displays a list with status information about all subscribers and queues on the hub. You can view the messages
that the hub forwards. Use the status to assist with debugging and load monitoring for the hub. The fields in the list are:
Name of the queue
Type of subscriber
Queued shows the number of messages waiting to be transferred. If you do not use spooling, this number is typically 0, for as long as
the subscriber is alive.
Sent shows the number of sent messages
Bulk Size is the maximum number of messages that are sent at once
Subject/Queue is the name of the queue or subject that the subscriber subscribes to
ID for the connected probe or program
Established shows when the hub connected to the subscriber
Address of the subscriber
Connection is the address of the subscriber network connection
Subjects a count of messages by subject from the last restart
Tunnel Status displays two windows. The upper window, which shows all tunnels that the hub is running, provides this information:
Peer Hub is the IP address or hostname of the tunnel peer
Started shows the initial tunnel connection time
Last shows the time of the last connection through the tunnel
Connection stats (ms) are the statistics for the time that is taken to set up the tunnel connection
A low minimum value can indicate a low bandwidth
A high minimum value and a high average value can indicate packet loss
Connections shows the number of connections made
Traffic in/out shows the amount of data that is received and sent through the tunnel
When you select a tunnel in the upper window, the connections appear in the lower window:
State of the connection (idle or active)
Start time of the connection
Last transfer time
In and Out show the amount of data that is received or sent
Address is the hostname of the target of the request

Command specifies the command that is executed on the target of the connection
Tunnel Statistics has statistics on SSL and on various events (such as server start time and when the last connection was received).
Use the drop-down list to select the server or client to view.

This article explains how to use Admin Console to:
Configure hub-to-hub communication. If you have any secondary hubs in your deployment, you must create queues between them and
the primary hub. If they are separated from the primary hub by a firewall, you will also need to create a static route to the hub, then create
tunnels and queues to connect them to the primary hub.
Check traffic statistics for the hub and monitor its message flow.
Perform advanced configuration to tune hub performance.
See the following sections for details.
Access the GUI

Control the Ports Assigned to Tunnels
About UIM Queues
Example Queue
Set the Hub's Communication Mode
Control the Hub's Connectivity Behavior
Check the Status of Other Hubs
Modify the Log File Settings
Access the GUI

To open the hub configuration GUI:
1. In the Admin Console navigation tree, expand a hub and select its robot.
2. Click the arrow next to the hub probe and select Configure.
Note the following:
To restart the process, Deactivate and then Activate the hub probe.

Follow these steps to set up a tunnel between two hubs. Fields marked with an asterisk are required.
Important: If your tunnel server will have multiple tunnel clients, you can control the port assignments instead of letting the hub assign
them based on the configuration for the controller probe. To control them, follow the steps in Controlling the Ports Assigned to Tunnels
before you create client certificates.
1. Ensure that both hubs appear in the Admin Console navigation pane. If either does not, create a static route to the hub.
2. Determine which hub will be the tunnel server.
Recommendation: Because the tunnel server uses a fair amount of computing power, designate the system with the lower load as the
tunnel server. If a central hub will have several remote hubs attached to it, make the remote hubs the tunnel servers so that each remote
hub only adds a small amount of overhead to the central hub.
3. Activate tunneling on the tunnel server:

a. In Admin Console, expand the hub that will be the tunnel server, then open its hub probe in the configuration GUI.
b. Select the Tunnel node. Check Tunnel Active and click Save.
4. Set up the tunnel server as a Certificate Authority. This creates a Certificate Authority certificate and enables the hub to create client
certificates.
a. Navigate to 1 - Tunnel Server.
b. In Tunnel Server CA Initialization, enter information about your organization.
c. Select Actions > Perform Tunnel Server CA Initialization. The CA certificate appears in the tunnel client certificate list.
d. Modify Tunnel Server Settings (optional):
Set Server Port to any available port (default is 48003).
Increase the Security Setting as desired.
5. Create the tunnel client certificate:
a. Under Client Certificate Configuration, specify the following:
Organization name, administrator email address, location (optional).
Common Name - enter the IP address of the tunnel client hub.
Note: Use regular expression to specify multiple tunnel client hubs and create multiple certificates.
Password - Create a password to be used to establish trust between the tunnel server and client. You will enter this password
when you install the certificate on the client.
Expiration days - Specify how long the certificate will be active.
b. Select Actions > Create Client Certificate. The certificate appears in the tunnel client certificate list
c. Copy all of the text in the Certificate field (below the Tunnel Client Certificate List) and close the GUI.
Note: Save the certificate to a file if you are not going to set up the tunnel client now.
6. Set up the tunnel client:
a. In Admin Console, expand the hub that will be the tunnel client and open its hub probe.
b. Navigate to Tunnel, check Tunnel Active, and click Save.
c. Navigate to 2 - Tunnel Client.
d. Under Client Certificates Configuration, click New. In the fields that appear:
Leave Certificate ID blank.
Server is the tunnel server's IP address.
If your environment uses NAT (network address translation), disable Check Server 'Common Name' Value.
Note: When this option is enabled, the tunnel server must verify that the tunnel is coming from the IP address specified in the
certificate. IP address mapping requires that this be disabled in NAT-ed environments. However, CA recommends you leave this
option enabled in all other cases.
Optional: Enter a Description.
Enter the Password you created for the tunnel server.
Optional: modify the Keep Alive setting.
In the Certificate field, paste the text you copied from the tunnel server.
e. Click Save at the top of the page.
7. If you created a static route to a hub that is now connected to the message bus by a tunnel, you must delete the static route:
a. Expand the hub from which you configured the static route, then open its hub probe in the configuration GUI.
b. Navigate to Name Services and remove the static route.
Important! This must be done to ensure that all UIM data flows through the secure tunnel and not through the static route.
The tunnel is now active.
Control the Ports Assigned to Tunnels

If your tunnel server will have more than one tunnel client and you want to control the port assignments, perform the following steps on the tunnel
server before you create client certificates.
Important: This configuration is recommended for advanced users only. Contact Support if you need assistance.
1.
1. In Admin Console, expand the hub that will be the tunnel server. Open its hub probe in the configuration GUI and navigate to Advanced
> Tunnel Settings.
2. In Tunnel Advanced Settings:
Enable Ignore Controller First Probe Port.
Specify the First Tunnel Port, the port to be used by the first tunnel you set up. For each additional tunnel, the tunnel server
increments the number and assigns that port to the tunnel client. The client keeps that port as long as the hub is running. Note the
following:
The server does not keep track of disconnected clients. If a tunnel client is connected to the server, this number increments, even if
a previously used port becomes available. However, if there are no active clients, the counter resets.
If you plan to configure more than one tunnel, we recommend you specify the first port. Make sure you do NOT use the port range
that the controller probe uses.
If this field is blank, the operating system assigns random ports.
Make sure you do NOT use the port range that the controller probe uses.
3. Click Save.

By default, all UIM requests and messages can be routed over the tunnel and dispatched on the other side. This routing is transparent.
A tunnel Access List lets you restrict the access privileges for UIM users, addresses and commands. The Access List is created on the tunnel
client hub.
Recommendation: Use Infrastructure Manager to create these lists. Tunnel access lists created with the Admin Console hub
configuration GUI may have issues. Refer to Access List in the Infrastructure Manager hub configuration guide for details.

If a hub does not appear in the Admin Console navigation pane, you can create a static route to it. Follow these steps.
1. In Admin Console, expand the primary hub, then open its hub probe in the configuration GUI.
2. Navigate to Name Services.
3. In Static Hub List Entry:
Leave Active and Synchronize checked.
For Hostname/IP, enter the IP address of the secondary hub.
4. Select Actions > Create Static Hub.
5. Close the configuration GUI.
6. Verify that the secondary hub appears in the navigation pane.
Note: CA recommends that after you create the static route, you connect the hub with a tunnel, then remove the static route.

If you have any secondary hubs in your deployment, you must create queues so that messages from those hubs can reach the primary hub. You
will create:
Attach queues on all secondary hubs. These queues collect messages.
Corresponding get queues on any intermediary secondary hubs and on the primary hub. These queues get the messages from the attach
queues.
You can either create one attach queue with the wildcard (*) subject to collect all messages, or create separate queues for different messages or
groups of messages. To learn more, refer to About UIM Queues.
Follow these steps:

1. In Admin Console, expand the hub, open the hub probe configuration GUI, and navigate to Queue List.
Queue Name: Enter a unique and descriptive name.
Recommendation: for usability, use a name similar or identical to the subject.
Active: Leave checked if you want to queue to be active immediately.
Type: Select attach, get, or post.
Note: The remaining fields in this area are active if they are required for the selected type.
Hub Address (get queues): Address for the hub that has the corresponding attach queue.
Subject (attach or post queues): Select the subject. Note that:
If the desired subject is not listed, enter it in the Queue List Entry Subject to Add field, then select Actions > Add Subject to List.
Remote Queue Name (get queues), which is the corresponding attach queue.
If desired, enter a Bulk Size, which specifies how many messages can be transferred simultaneously (in one bulk). The only time you
need to change this value from '<default>' is when you see that the queue grows and never shrinks to zero (see Subscribers Queues
on the Status tab). This indicates that the hub has problems delivering the messages to the target hub fast enough. The reason for
this behavior could be that the number of QoS messages delivered to the hub from the robots has increased a lot (See Statistics
button on the General tab) or that the latency is too high and slows down the deliveries (See Response Check, right-clicking a hub in
the hubs list).
About UIM Queues

UIM components use queues to pass messages. Messages are placed into queues based on their Subject ID, which classifies every UIM
message. Most queues are created automatically during installation (when hub-to-robot communication is set up) or deployment (during which
some probes create the queues they require).
Hub-to-hub queues must be created manually. If you have any secondary hubs in your deployment, you must create queues so that those hubs
can communicate with the primary hub.
An attach queue collects messages (based on subject) for forwarding to a get queue on another hub. You can either create one attach
queue that collects all messages, or create separate queues for different messages.
A post queue sends a stream of messages (based on subject) directly to a destination hub.
An attach or post queue's subject attribute determines which messages are directed to the queue:
Queues can collect messages for more than one subject. Add a new subject with all desired subjects separated by commas (for example,
alarms, alarms2).
A number of subjects are reserved for use by UIM components. They are listed in Reserved UIM Subject IDs.
Keep in mind that queues are first-in-first-out lists, which means messages in a wildcard queue are not prioritized based on subject. If a hub
transfers thousands of messages each second, a critical alarm message might have to wait behind less urgent QoS messages.
Recommendation: In a high-volume environment, create separate queues for important subjects, such as alarm, or for subjects that will create
many messages. Create one multiple-subject queue for all subjects that are not critical.

The following table shows the subjects used by UIM components, the types of messages that use them, and the component that generates them.
All messages with the same subject should also have identical data structures.
Subject
Used by
alarm
Alarm messages
alarm2
alarm_new
Alarm message whose footprint is not previously recorded
alarm_update
Alarm message whose footprint already exists
alarm_close
Message sent when a client closes (acknowledges) an alarm and removes it from the currently active alarms
alarm_assign
alarm_stats
statistical event messages generated by the NAS probe that contain severity level summary information for all open
alarms
audit
Audit messages: probe package distributions, activations, etc.
probe_discovery
device information
QOS_BASELINE
messages containing baseline data points for QoS metrics
QOS_DEFINITION
message that specifies a QoS definition
QOS_MESSAGE
All QoS messages
Example Queue
The following example shows how to configure an attach and get queue pair with the subject probe_discovery. This allows automated discovery
data to flow up from secondary hubs to the discovery server on the primary hub.

The hubs SSL mode specifies the communication mode used by components managed by the hub. It is primarily used for robot-to-hub
communication. When hubs are not connected with tunnels, hub-to-hub communication is also controlled by each hubs SSL mode.
SSL communication is enabled through the <Nimsoft>/robot/robot.pem certificate, which is created by the controller upon startup. This file
contains the key that decodes encrypted UIM messages.
Important: The 7.70 release of the UIM hub and robot have improved the robustness of SSL communication. Prior to this version, in a
non-tunneled domain, hubs that were configured to communicate unencrypted were able to decode and respond to encrypted
messages. In a multi-hub domain, upgrading to v7.70 will break this type of communication. For details, see Impact of Hub SSL Mode
When Upgrading Non-tunneled Hubs in the Hub (hub) Release Notes.
Note: Any tunnels set up between hubs will remain after you upgrade, and communication will continue. CA strongly recommends that
you connect all UIM hubs with tunnels to help ensure communication integrity.

1. In Admin Console, expand the hub robot. Open the hub probe in the configuration GUI and navigate to Advanced > SSL.
Normal (SSL mode 0) No encryption. The OpenSSL transport layer is not used.
Compatibility mode (SSL mode 1) Enables the hub and robot to communicate either without encryption or with OpenSSL
encryption. Components first attempt to communicate via SSL. If a request is not acknowledged, the component sends its requests to
the target unencrypted.
SSL Only (SSL mode 2) OpenSSL encryption only.
Recommendation: Wherever possible, CA recommends you use mode 1, compatibility mode. This enables secure communication
between all components that support SSL, while sill allowing communication with those that do not support SSL.
Control the Hub's Connectivity Behavior

When you install a hub, the way it connects with other hubs is determined by default values that are sufficient for most hubs. However, you may
want to adjust a hub's connectivity settings to meet the needs of your deployment or to improve performance. For example:
Hub Settings control the hub's request timeout, update interval and login mode.
Robot Settings specify the alarm sent for events that occur on robots connected to the hub.
Queue Settings control the behavior and size of queues.
Broadcast Configuration settings specify whether and where the hub lets other hubs know it is active.
Lockout Configuration settings let you avoid leaving the system vulnerable to brute-force password guessing.

1. In Admin Console, open the hub probe in the configuration GUI and navigate to Advanced.
Check the Status of Other Hubs

To check the status of another hub within your domain, follow these steps:
1. In Admin Console, open the hub configuration GUI for any hub in the domain.
2. Navigate to Hub List.
3. In the table that shows the status and other information for all hubs in the domain, select the hub you want to check.
4. Click Actions and choose the desired command:
Alive Check to view the status of the selected hub.
Response Check to view the response time (connect - reconnect, no transfer) between your hub and the one selected in the list.
Transfer Check to transfer data from your hub to the selected hub and view the transfer rate.
Modify the Log File Settings

All UIM probes maintain log files. By default, the log file records:
Only messages classified as 0 - Fatal. This keeps a minimal amount of data.
If you are troubleshooting or debugging, you may want to view the hub's activity in more detail or keep more data in the log file. To do this:
1. In Admin Console, open the hub probe in the configuration GUI and navigate to the hub node.
2. In General Configuration, set the log level and file size as desired.
3. Activate the changes. Either:
Click Actions > Set In-Memory Log Level. This applies the changes without restarting the probe, but does not retain the changes
when the probe is restarted. This lets you view the hub's current activity in more detail.
Click Save at the top of the page. This restarts the hub and retains new settings.
v7.7 Hub AC GUI Reference

This section describes the configuration information and options available through the Admin Console hub configuration GUI. The navigation pane
hub
Advanced
SSL
Tunnel Settings
Hub List
Name Services
Queue List
Robot List
Tunnel
1 - Tunnel Server
2 - Tunnel Client
To access the hub configuration interface, select the hub's robot in the Admin Console navigation pane. In the Probes list, click the
arrow to the left of the hub probe and select Configure.
hub
The hub node lets you view information about the hub and adjust log file settings.
Probe Information displays the probe name, start time, version and vendor.
Hub Information displays the hub name, domain, IP address, hub address (/domain/hub_name/robot_name/hub), and uptime data.
License Information displays details about the license used for the hub's robot is displayed; the total number of licenses and the number
available is also shown. An invalid license stops the message flow from the hub to its subscribers (mostly service probes) and prevents
the robot spoolers from uploading their messages.
General Configuration lets you modify log file settings:
Log Level specifies the level of alarm information saved in the log file. 0 - Fatal (default) logs the least; 5 - Trace logs all alarms.
Recommendation: Log as little as possible during normal operation to reduce disk consumption. Increase the level when debugging.
Log Size controls the amount of data retained in the log file (in KB, default is 1024). Large log files can cause performance issues,
therefore use caution when changing this size.
Actions > Set In-Memory Log Level writes the changes to the log file immediately without restarting the hub, which lets you view
more detail about the hub's current activity. The settings are retained until the hub restarts.
Advanced
The Advanced node allows you to control the hub's connectivity behavior.
Hub Settings controls how the hub communicates:
Hub Request Timeout specifies how long the hub waits for a response from other hubs. Default: 30 seconds.
Hub Update Interval specifies how often the hub sends its messages to the other hubs. Default: 600 seconds.
Origin identifies the sender for data sent by the probes. It is used when reports are generated. This field obtains the origin from the co
ntroller probe configuration. This field is blank if the origin is not specified in the controller, and the hub name is used. The origin is
specified in the Controller probe configuration.
Disable IP Validation turns off the IP address validation the hub does for all computers sending requests to its probes. It is typically
used when using NAT (Network Address Translation).
Login Mode provides three options:
Normal (default) allows logins from any robot connected to the hub.
Local Machine Only allows logins only from the computer hosting the hub. Attempts from any other robot connected to the hub
are refused.
No Login disables all logins to the hub.
Broadcast Configuration controls whether and where the hub lets other hubs know it is active:
Broadcast On (default) enables the hub to broadcast its status.
Broadcast Address is the IP address on which the hub broadcasts. Default is 255.255.255.255 (the default broadcast address for
any local network).
Lockout Configuration controls the lockout settings for the hub to avoid leaving the system vulnerable to brute-force password
guessing:
Login Failure Count specifies the number of attempts from a single IP address.
Robot Settings controls the alarm settings for events that occur on all robots connected to the hub:
Inactive Robot Alarm Severity specifies the level or warning sent when a robot fails to respond.
Audit Settings for Robots lets you turn auditing on or off for all of the hub's robots, or allow each robot to use its own settings.
Note: Auditing records important events, such as starting and stopping the robot.
Audit Once per User
Queue Settings controls the behavior and size of queues:
Reconnect Interval is the number of seconds between a disconnected hub's attempts to reconnect (default is 180).
Disconnect Passive Queues specifies how long a queue can be passive (receive no messages) before being disconnected (default
is 180).
Post Reply Timeout specifies how long a hub waits for a reply to a message. A timeout occurs if no response is received within this
interval.
Alarm Queue Size is the size of the queue file on the hub. An alarm is sent if the queue exceeds this threshold (default is 10 MB)
SSL
The Advanced > SSL node lets you configure the hubs SSL mode, which specifies the communication mode for components managed by the
hub. It is primarily used for robot-to-hub communication. However, when hubs are not connected with tunnels, hub-to-hub communication is also
controlled by each hubs SSL mode.
SSL settings for UIM components are controlled each component's hub. The hub propagates SSL settings to the robots; each robot then
propagate the settings to its probes. SSL settings are specific to each hub. Set them on each hub that requires SSL.
Cypher Type specifies the Cypher Suite used by the OpenSSL library.
Tunnel Settings
The Advanced > Tunnel Settings node lets you control the behavior of the hub's tunnels.
Tunnel Advanced Settings control how tunnels connect:
Enabled: the hub uses the First Tunnel Port setting (recommended if the hub will have more than one tunnel server).
Disabled: the tunnel is assigned the port number specified as First Probe Port in the controller probe configuration.
First Tunnel Port specifies the port to be used by the first tunnel you set up. For each additional tunnel, the tunnel server increments
the number and assigns that port to the tunnel client. The client keeps that port as long as the hub is running. Note the following:
Hang Timeout (in seconds, default is 120) specifies the interval between automatic tunnel restart attempts. The tunnel server
continuously checks the status of its tunnels. If a tunnel does not respond, the hub attempts to restart it. If it does not respond within
the time specified, it attempts another restart, and will continue to do so until the tunnel is active.
Tunnel SSL Session Cache controls SSL caching:
Use Client Cache / Use Server Cache enables caching of SSL sessions, which allows previous session credentials to be used.
Enabling both options significantly speeds up the server/client connection time.
Server Cache Timeout (in seconds) specifies how long the cached sessions are valid for reuse by the client. Default is 7200 (2
hours).
Server Cache Size specifies how much data is stored in the cache. Default is 1024 KB.
Hub List
The Hub List node lists all the hubs within a UIM domain, displays information about them, and lets you check their status.
Hub List provides the following information about each hub:
Domain
Name
Status
Last Updated, date and time when the hub probe was last restarted
IP address
Port
Three commands let you check the status of other hubs:
Actions > Alive Check checks the status of the selected hub.
Actions > Response Check checks the response time (connect - reconnect, no transfer) between your hub and the one selected in
the list.
Actions > Transfer Check transfers data from your hub to the one selected in the list and checks the transfer rate.
Name Services
The Name Services node lets you ensure hubs separated by firewalls or routers can discover each other and that hubs in a NAT environment
can return requests.
Static Hub List Entry lets you enter information for the static route:
Active: enable to ensure the route is active upon creation.
Synchronize: enable to ensure the hub sends status information to the static hub.
Hostname/IP of the static hub.
Actions > Create Static Hub sets up the static route.
Static Hub List displays the hubs to which there is a static route from the hub being configured:
Active indicates the route is active.
Synchronize indicates the hub is sending status information to the static hub.
Name, IP, Domain, and Robot Name identify the static hub.
Actions > Remove Static Hub removes the selected static hub.
Network Aliases let the hub know the appropriate return address for requests from remote hubs in a NAT environment:
From Address is the address from which the remote hub sends requests.
To Address is the address to which the responses should be sent.
Queue List
Navigation: hub > Queue List
The Queue List node lets you create hub-to-hub queues.
Queue List Entry lets you add a new queue subject.
Subject To Add lets you specify the new subject.
Note: Some subjects are reserved for use by UIM probes. See Reserved UIM Subject IDs.
Actions > Add Subject To List adds a queue subject immediately so it can be used in a new queue.
Queue List Configuration lets you enter information for new queues or view the configuration of existing queues. Some fields are
specific to the type of queue being created.
New and Delete let you add and delete queues.
Queue Name is the name of the queue being created.
Active shows the queue status.
Type specifies the type of queue being created: attach, post or get.
Hub Address (get queues) is the UIM address of the hub that has the corresponding attach queue.
Subject (attach or post queues) specifies the type(s) of messages to collect in the queue.
Remote Queue Name (get queues) is the name of the corresponding attach queue.
Remote Queue List (get queues) displays available attach queues found in the domain.
Bulk Size specifies the number of messages to be transferred in one package.
Robot List
The Robot List node lists all the robots controlled by the hub, displays information about them, and lets you restart them.
Robot List displays the following information about each robot:
Name
Status
IP address
Version of the robot probes
OS version and information
Two commands are available.
Actions > Alive Check checks the status of the selected robot.
Actions > Restart restarts the selected robot.
Tunnel
Navigation: hub > Tunnel
The Tunnel node enables tunneling on a tunnel server or tunnel client. This must be done once on each hub that will have a tunnel:
Tunnel Active: Check this option and then click Save to enable tunneling.
1 - Tunnel Server
The Tunnel > 1 - Tunnel Server section lets you configure a hub to be a tunnel server.
Certificate Authority (CA) Initialization lets you designate a hub as a Certificate Authority.
Note: This is a one-time task. After it has been done, this section will display Tunnel Server CA Is Initialized.
Server Settings shows the tunnel server's status:

Active indicates the tunnel is running.
Tunnel Server Status shows whether the tunnel is running or stopped (change the status with the Actions commands).
Common Name is the IP address of the tunnel server.
Expiration Days shows the date the tunnel expires.
Server Port is the port the tunnel server will use to transfer data (default is 48003).
Security Setting specifies the encryption level used for tunneled packets:
NONE: No encryption but uses authentication. Fast but not very secure.
LOW: Fast but not very secure encryption and authentication.
MEDIUM: Slow but secure encryption and authentication.
HIGH: Slow but very secure encryption and authentication.
CUSTOM: Slowest but most secure encryption and authentication.
Custom Cipher * is specified when the Security Setting is Custom.
CA Certificates lets you create the CA certificates, which give the hub the authority to issue client certificates:
Organization Name, Organization Unit Name, and Email Address identify the issuing entity.
Country Name, State or Province Name, and Locality Name are the location of the receiving entity.
Common Name is the IPV4 or IPV6 address (hexadecimal format) for the tunnel server hub.
Beginning Date and Ending Date specify when the certificate is valid.
Client Certificate Configuration lets you create client certificates, which are required on every tunnel client that will connect with the
tunnel server:
Organization Name, Organization Unit Name, and Email Address identify the receiving entity.
Common Name is the IPV4 or IPV6 address (hexadecimal format) for the tunnel client hub, which must be active when the certificate
is created.
Password lets you specify the password that will allow the tunnel client hub to access the tunnel server.
Beginning Date and Ending Date show when the certificate is valid.
Certificate * displays the client certificate text, which must be copied to the tunnel client hub configuration.
Actions > Create Tunnel Server Client Certificate creates the certificate.
Client Certificate List shows your client certificates:
New and Delete let you add and delete certificates.
Rows in the table display information about the certificates.
Fields below the table display details for the selected certificate.
Certificate * displays the certificate text, which must be copied and pasted into the tunnel client hub configuration.
2 - Tunnel Client
The Tunnel > 2 - Tunnel Client node lets you configure a hub to be a tunnel client.
Client Certificate Configuration lets you add, delete and view tunnel client certificate:
Certificate ID is the number assigned to the certificate.
Active shows the certificate status.
Server * specifies the IP address of the tunnel server hub.
Server Port * specifies the port to be used for tunneled data.
Check Server 'Common Name' Value makes the tunnel server verify that the tunnel is coming from the IP address specified in the
client certificate. IP address mapping requires that this be disabled in NAT environments. However, CA recommends you leave this
Description lets you describe the tunnel.
Password * is the password that was defined when the tunnel client certificate was created.
Keep Alive (in seconds) specifies the interval at which small data packets are sent. This is to allow for firewall connection disruption
on idle connections.
Certificate * is where you paste the client certificate text (which was created on the tunnel server hub).
The Tunnel > 3 - Tunnel Access List node on lets you restrict the access privileges for UIM users, addresses and commands.
Recommendation: Due to issues with tunnel access lists created with this release of the Admin Console hub configuration GUI, CA
recommends you use Infrastructure Manager to create these lists. Refer to Access List in the Infrastructure Manager hub configuration
guide for details.
Tunnel Access List lets you create tunnel access lists:

New and Delete let you create or delete an access list.
Source IP * is the IP address of the tunnel server, or the wildcard character (*).
Destination Address * is the address of the target hub, robot or probe.
Probe Command is the specific command you want to allow or deny. To find the command set, click the icon next to the hub probe
and select Probe Utility.
User * to whom you want to allow or deny access (regular expression is allowed).
Mode * settings let you specify the access mode:
ACCEPT access for the specified user, command or probe.
DENY access for the specified user, command or probe.
Note: This is normally used for debugging purposes when testing commands against targets before setting them up as
accept or deny rules. The result can be viewed in the hub log file before your deny or accept rules.

This article explains how to use Infrastructure Manager to configure a hub. For an overview of the hub, see hub.
Hub configuration includes:
Setting up hub-to-hub communication. If you have any secondary hubs in your deployment, you must create queues between them and
Checking traffic statistics for the hub and monitor its message flow.
Performing advanced configuration to tune hub performance.
See the following sections for details:

About UIM Queues
Example Queue
Set Up the Tunnel Server
Set up Access List Rules (optional)
Alarm Configuration
LDAP Configuration

Hubs discover other hubs by sending out broadcast (UDP) messages. This enables them to connect to the message bus. Secondary hubs that
are separated from the primary hub by routers or firewalls are unable to discover other hubs by this mechanism, and therefore cannot be
configured with Infrastructure Manager. You must configure a static route to these hubs. For example, static routes can be used to:
Connect two hubs that are in the same sector of a customer environment but in different network subnets.
Connect a hub outside a firewall so that you can create a secure tunnel to the hub.
Important! Do not connect a hub with both a tunnel and a static route. In some situations, data could be transmitted over the
insecure static route rather than over the secure tunnel. If you set up a static route so that you can configure a tunnel, make
sure you delete the static route after the tunnel is complete.
Follow these steps to set up a static route to a hub.

1. In Infrastructure Manager, navigate to the local hub that will tunnel to the remote hub, and open its hub probe in the configuration GUI.
4. In the New Static Hub dialog:
Leave Active enabled.
If desired, disable Synchronize. If this option is not checked, the parent hub does not send status information to the static hub. The
parent hub will still receive status info from the static hub, unless you disable this option on the static hub as well. Disabling this option
can reduce network traffic if your network runs on a telephone line or ISDN.
Enter the IP address of the static hub.
Note: The system fills in the Hub Information fields (hub name, domain and robot name) with information retrieved from the remote hub.
will create either:
Attachqueues on all secondary hubs to collect messages, and corresponding get queues on any intermediary hubs and on the primary
hub.
Post queues, which stream messages directly to a destination hub.
See About UIM Queue for more information on queue types.
Follow these steps to set up a hub-to-hub queues.
To set up attach and get queues:

1. On a hub that will have the attach queue:
c. Click New, then specify:
Active - enabled
Name - name of queue (must match the name of the get queue)
Type - attach
2. On a hub that will have the get queue:
Active - enabled
Type - get
Address - select the address of the hub that has the attach queue
Bulk size - specify the number of messages to be sent together (optional; if you expect the queue to carry a significant amount of
3. Click New, then specify:
Active - enabled
Name - name of queue
Type - post
Address - select the address of the hub that will receive the messages
About UIM Queues


alarms, alarms2).

Subject
Used by
alarm
Alarm messages
alarm2
alarm_new
alarm_update
alarm_close
alarm_assign
alarm_stats
Statistical event messages generated by the NAS probe that contain severity level summary information for all open
alarms
audit
probe_discovery
Device information
QOS_BASELINE
QOS_DEFINITION
QOS_MESSAGE
All QoS messages
Example Queue

Most companies have one or more firewalls in their network, both 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 (Virtual Private
Network) 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.
Tunnels can be created during hub installation, or afterward by configuring the hubs. This following process explains how to set up tunnels
between hubs that are already installed. Click the links for more information.
To set up a tunnel, you must:
The Tunnel Client accepts the attempt to setup the tunnel.
2. Ensure that both hubs appear in the navigation tree. Hubs discover each other by sending out broadcast (UDP) messages. However,
hubs separated by routers and firewalls are unable to discover other hubs by this mechanism. You must configure a static route to these
hubs.
3. Set up the tunnel server as a certificate authority. This creates a server certificate and gives the hub the ability to generate digital client
certificates.
4. Create the certificate for the tunnel client. This task is done on the tunnel server.
6. Remove the static route to either hub if you created one.
7. Create queues between the hubs, just as you would for secondary hubs that are not connected with tunnels. Refer to Setting up Queues.
8. Optional: On the tunnel client, you can set up access list rules to restrict tunnel access privileges for specified UIM addresses,
commands, or users.
Note: Networks that use NAT (Network Address Translation) affect how a tunnel is configured. For example configurations, refer to Setting up a
Tunnel in a NAT Environment.

Perform these tasks on the hub that will be the tunnel server.
1. In Infrastructure Manager, navigate to the hub that will be the tunnel server and open its hub probe in the configuration GUI.
2. On the General tab, select the Enable Tunneling.
3. Click the Tunnels tab, then click Server Configuration.
4. Enable the Active option.
5. In the Certificate Authority Setup dialog, enter your organization's information:

Who (optional): Company name, Organization unit, and e-mail address of your administrator
Where (optional): Country, state and community of your organization
Common Name: Host name of the hub that will be the tunnel server.
Password: Password for the authentication.
Expire days: How long the CA is valid.
6. Click OK. The hub is now a Certificate Authority and the server certificate is generated. This certificate is the basis for all the Client
Certificates generated by this tunnel server.
7. Select a security setting: None, Low, Medium, High, or Custom (which lets you define your own security setting; see www.oenssl.org/doc
s/apps/ciphers.html for information).
7.

Once the tunnel server hub is configured to be a Certificate Authority, you can create client certificates. You create the certificate on the tunnel
server hub. Follow these steps.
2. On the Tunnels tab, navigate to Server Configuration and click New.
3. In the Client Certificate Setup dialog, enter your information.
Authentication (required) - Enter the following:
Expire days - Number of days the certificate will be valid
4. Click OK.
6. Click Copy. Open a text editor (such as Notepad) and paste the certificate into a new blank file. Save the file to a location where the
tunnel client can access it. Exit the Certificate Information dialog.
7. Click Apply, then click Yes when asked to restart the probe.

The Access List lets you define a set of rules to restrict the access privileges for specified UIM addresses, commands, or users. The Access List
is defined on the tunnel client hub.
You can create three types of rules:
Accept rules enable access. Set up a rule to give access to a UIM component (such as a probe, robot or hub) to execute one or more
specific commands for one or more users.
Deny rules disallow access for the specified addresses, commands or users.
Log rules log all requests through the tunnel. This is normally used for debugging purposes when testing commands against targets
before setting them up as accept or deny rules. The result can be viewed in the hub log file before your deny or accept rules.
You can use regular expressions when defining the access rules.
Tip: When making a restrictive list, start with a few Accept rules, then make a Deny rule that denies access for all others. When making a less
restrictive list, start with a few Deny rules, then make an Accept rule that gives access for all others.
To add a rule:
1. Navigate to the Access List tab.
2. In the Edit Rule area, enter:
Source IP - IP address for the source hub, robot or probe
Destination Address - address of the target hub, robot or probe
Probe Command - the specific command you want to allow or deny (to view a probe's command set, open the Probe Utility for the
probe)
User - name of the user you want to allow or deny access
3. Select the mode: Accept, Deny, or Log.
In the rules table, use the Move Up and Move Down buttons to change the order of the rules. The order sets the priority.
In the example below, the first rule allows the administrator user on all nodes to access the target hub through the tunnel. The second
rule denies access to all users. If you place the Deny rule first, all users - including administrator - are denied access.
5. Click the Apply button to activate the list.

Follow these steps.
1. In Infrastructure Manager, navigate to the hub that will be the tunnel client and open its hub probe in the configuration GUI.
3. Go to the Tunnels and click Client Configuration.
4.

Leave the Active Tunnel and Check Server Common Name options enabled.
Enter the IP address of the tunnel server hub.
Enter the password you created when you generated the certificate.
Copy the certificate text from the file you saved it to, and paste it in the Certificate field.
Enter the server port or leave it blank to let the system assign the port.
If desired, specify a keep-alive interval.
5. Click Apply to activate the client.

The tunnel is now up and running between the tunnel server and tunnel client.

Networks that use NAT (Network Address Translation) affect how a tunnel is configured.
The scenarios below describe three possible configurations.
Important! You should be aware that when a tunnel is configured, it replaces the static hub and NAT setup in the hub configuration.
The Client certificate must be issued to (CommonName)--the IP address that is visible to the Server, which is in this case 10.2.1.111, not 193.71.5
5.111.
Uncheck the Check Server CommonName option in the Tunnel Client Setup Window. The reason for this is that the Server certificate has
10.1.1.1 as CommonName, not 202.1.1.1 which is what the client sees.
Combine the two methods described above. The Client certificate must be issued to (CommonName)--the IP address that is visible to the Server
(10.2.1.111) and uncheck the Check Server CommonName option in the Tunnel Client Setup Window.

The hubs SSL mode specifies the communication mode used by components managed by the hub. It is primarily used for robot-to-hub
communication. When hubs are not connected with tunnels, hub-to-hub communication is also controlled by each hubs SSL mode.
SSL communication is enabled through the <Nimsoft>/robot/robot.pem certificate, which is created by the controller upon startup. This file
contains the key that decodes encrypted UIM messages.
Important: The 7.70 release of the UIM hub and robot have improved the robustness of SSL communication. Prior to this version, in a
non-tunneled domain, hubs that were configured to communicate unencrypted were able to decode and respond to encrypted
messages. In a multi-hub domain, upgrading to v7.70 will break this type of communication. For details, see Impact of Hub SSL Mode
When Upgrading Non-tunneled Hubs in the Hub (hub) Release Notes.
Note: Any tunnels set up between hubs will remain after you upgrade, and communication will continue. CA strongly recommends that
you connect all UIM hubs with tunnels to help ensure communication integrity.

1. In Infrastructure Manager, expand the hub robot, then open the hub probe in the configuration GUI. Navigate to the General tab and click
Settings in the lower right corner.
2. Navigate to the SSL tab.
Recommendation: Wherever possible, CA recommends you use mode 1, compatibility mode. This enables secure communication
between all components that support SSL, while sill allowing communication with those that do not support SSL.

Viewing traffic statistics can help you avoid bottlenecks and to tune your UIM system. Statistics are available for the previous 30 days.
1. Click the Statistics button in the lower right corner of the configuration GUI.
2. View the total traffic managed by the hub:
Messages sent per minute
Messages received per minute
Requests per minute
3. To view the data from a specific period of time, change the dates and click Get.

2. In the Monitor window, click Traffic, Sniffer, or Tunnel to view the traffic the desired way:
Traffic displays a graph of the number of messages sent, received, and requested per second, and provides two lists:
Subscribers shows the permanent queues defined on the Queues tab.
Subjects shows all subjects defined for the queues.
Sniffer lets you filter the information by subject, probe, and/or robot:
c. Select a message in the list to open a callout containing vital information about the message, such as QoS name, QoS source,
QoS target, the time the sample was recorded, the sample value, etc.
Tunnel allows you to view the commands performed on the active tunnels. Click Start to view the the following information for each
command:
IP address and port number of of the client that executed the command.
Start and stop time for the transfer.

Total time used by the request through the tunnel (both directions).
UIM address to which the command was sent.
Last command issued during the message transfer.
Number of bytes sent and received during the session.

Follow these steps.
1. In Infrastructure Manager, navigate to the hub probe.
2. Ctrl+right-click the hub probe and select Raw Configure.
3. Select the hub section, and use New Key, Edit Key, and Delete Key to modify the keys as needed.
See the following sections for information on:
Alarm configuration
LDAP configuration
Alarm Configuration

tunnel_hang_retries - number of times the tunnel will try to reconnect before the hub is restarted
The httpd probe (hyper-text transfer protocol daemon) provides a simple http server that can be used to share information across the intranet.
LDAP Configuration
You can add two keys in the /LDAP/server section to affect how the hub communicates with the LDAP protocol.
Timeout specifies the number of seconds to spend on each LDAP operation, such as searching or binding (authentication) operations.
codepage is used when translating characters from UTF-8 encoding to ANSI. When text comes from the LDAP library as UTF-8, UIM
uses this codepage to translate the characters into ANSI.
Windows: Specify a valid codepage.For a list of codepages, go to . Note that the hub LDAP library uses the MultibyteToWideChar
and WideCharToMultiByte functions to translate to and from ANSI/UTF-8. These functions take a codepage as a parameter. Default: 2
8591
Unix: Use iconv functions. Refer to http://www.gnu.org/software/libiconv. Default: ISO-8859-1
Note: The codepage key is not shipped with the hub configuration file. The default codepage is ISO 8859-1 Latin 1;
Western European (ISO).

Advanced configuration lets you control how a hub communicates with its passive robots. Add any or all of the following keys to the hub section.
Key
Description
Default
The hub communicates with a robot through worker threads from a thread pool. CA
recommends you set the pool to 50% of the number of passive robots managed by the hub.
10
The number of seconds between trying to retrieve messages from a passive robot.
15
seconds
The number of messages the hub will accept from a passive robot in a single retrieval interval.
1000
The amount of time the comms API will block a call to a robot that is not responding.
15
seconds
The interval between retrying a non-responding passive robot will double every 10 minutes up to
this value.
Number of seconds the hub waits for passive robot management threads to stop before it kills
them.
Important! This should not be modified without advice from support because it can
cause a significant delay in monitoring functions.
60
seconds

To access the Infrastructure Manager hub configuration GUI, navigate to the hub you want to configure, then either:
Expand its robot and double-click the hub probe.
This article describes the tabs, fields and options available in the Infrastructure Manager hub configuration GUI. See the following sections for
details:
General Tab
Hubs Tab
Robots Tab
Name Services Tab
Queues Tab
Tunnels Tab
Access List
Advanced
Status Tab
General Tab
The General tab contains the basic hub information in the following sections.
Hub information provides the following:
Hub name
Domain to which the hub belongs
Hub IP address
Hub address in UIM format:/domain/hub_name/robot_name/hub
Version number and distribution date of the hub probe
Uptime, the length of time the hub probe has been running since the last time it was started
Modify (button) opens the Edit Hub Address dialog, enabling you to edit the hub name and domain (note that the hub's controller
probe restarts if you modify these parameters)
License information Each hub maintains a license system used by all of the robots connected to the hub. An invalid license causes
the message flow from the hub to its subscribers (mostly service probes) to stop. It also stop the various robot spoolers from uploading
their messages as long as the license key is invalid. The license key is built based on the following fields:
Licenses in use shows the number of robots currently connected to this hub, and the number of robots the license allows.
Expire date specifies when the license expires. An asterisk (*) indicates an unlimited license.
Owner of the license.
Modify (button) opens the Edit License dialog, which contains the hub's license key. License keys are provided by CA and must be
entered exactly as specified.
Login Settings for this hub lets you configure your log in settings for the hub.
Normal (login allowed) allows users to log on the hub from any robot.
Local machine only allows normal login on the hub if attempting to log in from the computer hosting the hub. Attempts to log in from
other robots are refused
No login disables login to the hub from either the local machine or a robot connected to the hub.
Log Level lets you specify the level of detail written to the log file.
Recommendation: Log as little as possible during normal operation to reduce disk consumption, and increase the level of detail when
debugging.
Log Size sets the size of the log file (default is 1024 KB). Large log files can cause performance issues, therefore use caution when
changing this size.
Advanced allows you to view and configure advanced options for the hub.
Enable tunneling activates the tunnel tab, where you can configure the tunnels. To disable tunnels, uncheck this option and click Ap
ply.
Disable IP validation. When a computer sends a request to a probe, the computers IP-address is validated. This option is typically
used when using NAT (Network Address Translation). See Setting up a Tunnel in a NAT Environment.
Statistics (button) displays traffic statistics for the hub for the previous 12 hours.
The graph shows the number of messages sent and received per minute, in addition to the number of requests. The Period section
lets you specify a time period. Click Get to update the values.
See Checking Traffic Statistics for more information.
Monitor (button) displays the current hub traffic. See Monitoring the Message Flow for more information.
View Log (button) displays the contents from the hubs log file. The log settings allow you to set the level of detail for the logging
function. The Log Viewer window provides the following:
File lets you save or print the file.
Edit lets you copy the contents and search in the log file.
Actions lets you limit the output in the window and highlight text or the date within the log file.
Start and Stop buttons let start/stop the log file updates.
Settings (button) opens the Hub Advanced Settings dialog. See Hub Advanced Settings for more information.
Navigation: General > Settings

General
SSL
LDAP
The General tab lets you specify the following settings.

Broadcast On turns the discovery broadcast on or off. You can specify the address on which the hub broadcasts (tells all other hubs that
it is alive). The default broadcast address is 255.255.255.255.
Hub Settings
Hub Request Timeout is the timeout value for hub communication requests. Default is 30 seconds.
Hub Update Interval is the interval at which the hub sends status information to the other hubs. Default is 600 seconds.
Queue Settings
Reconnect Interval is the interval at which a disconnected queue will be reconnected. Default is 180 seconds.
Disconnect passive queues is the interval at which queues that have been passive (no messages) will be disconnected. Default is
180 seconds.
Post Reply Timeout is the interval of time a hub waits for a reply to a message. A timeout will occur if no response is received within
this interval.
Alarm on queue size is the size of the queue file (in megabytes) on the hub. An alarm is sent if the queue exceeds this threshold.
Default is 10.
Lock Out Time
If the number of consecutive login failures from a user or an IP address reaches the Lock After Fails value, the system will not permit new
login attempts until the Lock Out Time has passed.
Important! These changes are not persistent, that is they do not survive over a hub stop and start.
Origin identifies where a message came from. QoS messages from probes are tagged with a name to identify the origin of the data. By
default, the name of the probes's parent hub is the origin. To override that value, you can:
Change the value here. The new value will be used for all QoS messages handled by the hub.
Set the origin at the robot level (in the Setup > Advanced section in controller configuration GUI).
Audit Settings for Robots allows the recording of important events, such as starting and stopping the robot. This setting is used for all
robots serviced by this hub. Select one of the following options:
Override: audit off
Override: audit on
Navigation: Hub > Settings > SSL

The SSL tab lets you configure the hubs SSL mode, which specifies the communication mode for components managed by the hub. It is primarily
used for robot-to-hub communication. However, when hubs are not connected with tunnels, hub-to-hub communication is also controlled by each
hubs SSL mode.
SSL settings for UIM components are controlled each component's hub. The hub propagates SSL settings to the robots; the robots then
propagate the settings to the probes. SSL settings are specific to each hub. Set them on each hub that requires SSL.

Cypher Type specifies the Cypher Suite used by the OpenSSL library.
There are two configuration options for LDAP: direct LDAP or Nimsoft Proxy Hub.
Direct LDAP
The hub can be configured to forward login requests to a LDAP server. This makes it possible to log on to the UIM consoles with LDAP
credentials. Users belonging to different groups in LDAP can be assigned to different UIM Access Control Lists (ACLs).
Note: Direct LDAP is only available on Linux and Windows hubs, due to the availability of the LDAP library the hub uses. Native LDAP is
not supported on Solaris.
Server Name: The hub can be configured to point to a specific LDAP server, using IP address or host name. A Lookup button lets you
test the communication. If you used a non-standard port for your hub, you must use the syntax "hostname:port" to indicate the server
name.
Note: You can specify multiple servers in this field, each separated with a space. The first entry acts as a primary server, while the
others act as secondary servers (taking over if the primary server goes down). Logins may take more time if a secondary server has
taken over.
Server Type: Choose an LDAP server type. Currently two server types are supported: Active Directory and eDirectory.
Authentication Sequence: Specify whether the hub authenticates using the LDAP login or Nimsoft Login first. For example, if you
select Nimsoft > LDAP, this means that the user will be verified against Nimsoft user credentials first. If this fails the hub will try to
verify the credentials against LDAP server credentials.
Use SSL: Select this option if you want to use SSL during LDAP communication. Most LDAP servers are configured to use SSL.
User and Password: You must specify a user name and a password to be used by the hub when accessing the LDAP server to
retrieve information:
Active Directory - the user can be specified as an ordinary user name.
eDirectory - the user must be specified as a path to the user in LDAP in the format CN=yyy,O=xxx, where CN is the user name and O
is the organization.
Group Container (DN): Specify a group container in LDAP to define where in the LDAP structure to search for groups. Click Test to
check if the container is valid.
User Container (DN): Specify a user container in LDAP to define more specifically where in the LDAP structure to search for users.
Nimsoft Proxy Hub
The hub can be configured to specify a UIM probe address to log in through.
Proxy Hub: The drop down list is empty by default. Click the Refresh icon next to the drop down list to perform a gethubs probe
request on the hub you are configuring, which will populate the drop down list with the hubs it knows about.
Proxy Retries: Specify the number of retries to perform in case of communication errors (network errors).
Proxy Timeout: Specify the time (in seconds per attempt) after which the proxy will be timed out.
Hubs Tab
This tab lists all known hubs and displays their information in different text colors:
Blue: Hub is within the same domain as the hub you are currently logged on to.
Black: Hub is outside the domain.
Red: Hub status is unknown, typically because the hub is not running.
The list contains the following information about each hub:

Status indicator:
Green - running
Red - not running
Domain
Hub name

Remove removes the selected hub from the hubs address list. The hub may appear later if it is running.
Robots Tab
The Robot tab lists lets you set the alarm level for robots and displays robot information.
Inactive Robot setup lets you set the severity level of the alarm issued if one of the robots in the list becomes unavailable.
Registered Robots displays the following information for each robot controlled by the hub:
Name
IP address
Operating system of the robot's host system
Right-clicking in the window opens a small menu with the following options:
Restart
This option only re-reads the configuration file for the selected robot. It does not do a stop and restart of the robot. If you have made any
changes to the robot configuration you must stop and restart the robot.
Check
Checks the selected robot.
Remove
Removes the selected active or passive robot from the list. An active robot may show up later since active robots will periodically request
the hub add them to the Registered Robots list.
Add Passive Robot
Opens the dialog to add a passive robot.
Name Services Tab

A hub knows the IP address and port number of all probes started by the robots that it controls. The robots are responsible for reporting all
changes in configuration and probe state to its hub. When a client (GUI or probe) wants to send a request to a probe it must first ask the local hub
for the address, if the target probe is on another hub the request is forwarded to that hub. The client can continue with the request to the probe if
the name-lookup succeeds.
Static Hubs
The hubs discover each other by sending out broadcast (UDP) messages. Hubs separated by routers and firewalls are normally unable
to discover other hubs by this mechanism. You must configure a static route to these hubs.
Note the Synchronize option in the New Static Hub dialog. If this option is not checked, the parent hub will not send status info to the
static hub. The parent hub will still receive status info from the static hub, unless you disable the Synchronize option on the static hub as
well.
This option can be disabled to reduce network traffic if your network runs on a telephone line or ISDN.
Important! Do not connect a hub with both a tunnel and a static route. In some situation, data could be transmitted over the
insecure static route rather than over the secure tunnel. If you set up a static route so that you can tunnel to a hub, make sure
you delete the static route after the tunnel is configured.
Network Alias tells the local hub the return address on requests from a remote NAT hub.
On hub A, set up the From address and the To address for hub B.
On hub B, set up the From address and the To address for hub A.
When hub B sends a request to hub A, the request will contain hub Bs From address. Hub A then knows that hub Bs To address must
be used when returning a request to hub B.
Queues Tab
The Queues tab lists all defined message queues. These include the queues that are automatically deployed, and those that an administrator
adds as needed. For example, if alarms need to be communicated from a secondary hub to the primary hub, you would create an attach queue
named nas with the subject alarm to forward alarms.
To edit a message queue, double-click the message queue (or select the message queue and click the Edit button).
Permanent queue content survives a hub restart. Permanent queues are meant for service probes that need to pick up all messages,
regardless of whether the service probe was running when they were created.
Temporary queue content is cleared during restarts. These queues are typically used for events to management consoles.
All queues defined on the Queues tab are permanent queues. Permanent queues are given a name related to their purpose. The permanent
queue named NAS is attached to the NAS (Nimsoft Alarm Server). You can set up a permanent queue from one hub to another by defining it as a
post type queue with the full UIM address of the other hub.
An Attach queue creates a permanent queue for a client to attach to.

A Get queue gets messages from a permanent attach queue on another hub.
The queue defined below (called get-hub-4) is defined as a get queue, getting messages from the queue xprone-attach defined on the
hub /HubTest/wm-hub-4/vm-hub-4/hub.
The dialog contains the following fields.

Active - Selecting this option activates the queue. This will also be reflected in the queue list under the Queues tab. Note that you may
also activate/deactivate the queues in the list.
Name is a unique and descriptive identifier of the queue. A required field.
Type of queue:
Post queues send a directed stream of messages to the destination hub.
Attach queues create a permanent queue for a get queue to attach to.
Get queues get messages from a permanent attach queue (on another hub).
Address is the UIM address of the source or target hub, and applies for get and post queues only. Can be selected from the drop-down
list.
Queue (for get queues) specifies the attach queue on another hub to get messages from.
Subject (for attach or post queues) specifies the messages that will be directed into the queue. Astersisk ( * ) for the subject collects
messages of all subjects.
All UIM messages contain a Subject ID, a text that classifies the message for all components on the message bus. This allows
components to subscribe to some messages and ignore others. All messages with the same subject should also have identical data
structure.
Tunnels Tab
This tab is enabled if the Enable Tunneling option is checked on the General tab of the hub configuration GUI.
Most companies have one or more firewalls in their networks, both internally between different networks and externally against a DMZ or Internet.
This makes it challenging to administer and monitor the whole network from a central location.
The solution is to set up a tunnel between two hubs that are separated by a firewall. The tunnel:
Sets up a VPN-like (Virtual Private Network) connection between the hubs. All UIM requests and messages are routed over the tunnel
and dispatched on the other side. This routing is transparent to all UIM users.
Requires that the firewall open one port for connection to the target hub.
Is implemented using the SSL (Secure Socket Layer) protocol.
Security is handled in two ways; certificates that authenticate the Client, and encryption to secure the network traffic over the Internet.
The tunnel provides authorization and authentication by using certificates. Both the Client and the Server need valid certificates issued by
the same CA (Certificate Authority) in order to set up a connection. In the case of setting up a tunnel, the machine receiving the
connection (the Server) is its own CA and will only accept certificates issued by itself.
Encryption
The encryption settings spans from None to High. No encryption means that the traffic is still authenticated and is therefore
recommended for tunnels within LANs and WANs. You should be careful when selecting higher encryption level since this will be more
resource intensive for the machines at both ends of the tunnel.
Important! Do not use static hubs (listed under the Name Services tab) when setting up a tunnel.

Access List
Advanced
Configuration tasks under this tab are for server (listening) side of the tunnel. The tab contains the following fields and buttons.
Active activates the tunnel server. The Certificate Authority Setup dialog appears. See Setting up a Tunnel for more information.
Common name is the IP address of the hub on the server side.
Expire date is the date the server certificate expires.
Port specifies the port that the tunnel server is listening on. This is the port that you have to open in your router or firewall for incoming
connections.
Security settings lets you select None, Low, Medium, High, or Custom, where you define your own security setting. For custom
definition: See http://www.openssl.org/docs/apps/ciphers.html
Note: High gives the highest degree of encryption, but slows the data traffic a lot. Normally None will be sufficient, where data is not
encrypted, but still authenticated.

Start and Stop starts or stops the tunnel server.
Server displays the server details and the server certificate.
CA displays the CA details and CA certificate.
New opens the Client Certificate Setup dialog. You can create certificates for the clients you will open for access. When creating the
certificate, you must set a password. This password, the certificate (encrypted text) and the servers port number must be sent to the
client site.
Delete deletes the selected client certificate.
View displays the selected client certificate.
The configuration tasks under this tab are for the client (connecting) side of the tunnel.
The fields are:
Server
The tunnel servers IP address or hostname.
Port
The tunnel servers port number.
Heartbeat
Keep-alive message interval.
Description
Brief description of the tunnel connection.
New button
Opens the New Tunnel Connection dialog. You can create a new Tunnel connection to the server that has generated the certificate.
Active Tunnel
Activates the defined tunnel connection.
Check Server CommonName
Uncheck this option to disable the Server IP address check on connection (see Setting up a Tunnel in a NAT Environment).
Description
Server
The IP address of the server on the server end of the tunnel.
Password
The password you have received with your certificate from the server side.
Server Port
The communication port on the server on the server side. Default is 48003. It is recommended that you do not change the default port.
Keep-alive interval
Small data packets are sent at the specified interval. This is to allow for firewall connection disruption on idle connections.
Certificate
You paste the received certificate in this field. See Creating Client Certificates for more information.
Edit button
Edits the selected server connection.
Delete button
Deletes the selected server connection.
Certificate button
Displays the selected client certificate.
Access List
This tab allows you to set access rules for tunnels. By default, all UIM requests and messages can be routed over the tunnel and dispatched on
the other side. This routing is transparent to UIM users.
must be defined on the tunnel client hub.

Edit Rule lets you add, modify or remove access rules. Four criteria are used when defining rules, and a rule is triggered based on
matching all four criteria:
Source IP is the name of the source hub, robot or probe.
Destination Address is the address of the target hub, robot or probe.
Probe Command is the specific command you want to allow or deny. The command-set varies from probe to probe. To view a
command set, open the Probe Utility.
User is the user you want to allow or deny access.
Note: Regular expression is allowed.
The rules table displays all the rules you have created. The order of the rules defined is important. The first rule in the list is processed
first. Processing stops on the first rule that matches all four criteria.
Advanced
This tab allows you to assign the first tunnel port, establish the hanging timeout, and configure the SSL session cache.
The tab contains the following options:
It is not necessary to select this option if only one tunnel is defined, as the tunnel is automatically assigned the port number specified as F
irst probe port number on the Setup > Advanced tab in the controller configuration.
First Tunnel Port
If you have configured more than one tunnel, you should specify the first port in the range of ports to be used by the tunnels.
Important! Do NOT use the same port that is specified for the controller probe's first probe port.
If this field is blank, random ports will be assigned by the operating system.
Clients are assigned ports from the configured port range and keep that port as long as the hub is running.
Servers assign ports from the configured port number and increment the number for each new client connection. If there are no
active clients, the hub resets the counter.
that are hanging.
If one or more tunnels are hanging, the hub attempts to restart the tunnel(s). If the restart fails, the hub performs a restart after the
specified number of seconds.
SSL Session Cache
Use Server Cache enables caching of SSL sessions and reuse previous session credentials. This speeds up the connection time
between the client and the server (assuming Use Client Cache is enabled on the client).
Status Tab
This tab contains four subsections that provide status information about the queues, subjects and tunnels you have defined.
Subscribers/Queues displays a list with status information on all subscribers/queues on this hub. You can view the messages received
by the hub and forwarded to interested parties. This status can be used to assist with debugging and load monitoring for your hub. The
fields in the list are:
Name of the queue
Type of subscriber
Queued shows the number of messages waiting to be transferred (unless you use message spooling, this number should be 0 in
normal operation as long as the subscriber is alive)
Sent shows the number of messages sent
Bulk Size is the maximum number of messages sent at once
Connection is the address of the subscribers network connection
Subjects shows a count of all messages that have been transferred since the last (re)start, grouped by the subject. This information can
assist you with debugging and load monitoring for your hub.
Peer Hub is the IP-address or hostname of the tunnels peer
Connection stats (ms) are the statistics for the time taken to set up the tunnel connection (a low minimum value could indicate a low
bandwidth; a high minimum value and a high average value could indicate packet loss)
Traffic in/out shows the amount of data received/sent through the tunnel
When you select a tunnel in the upper window, its connections appear in the lower window, which displays:
Last transfer time
In and Out show the amount of data received or sent
Command specifies the command executed on the target of the connection
Tunnel Statistics has statistics on SSL and on various events (such as server start time or when the last connection was received). Use
the drop-down list to select the server or client you want to view.

In the Admin Console hub configuration GUI, you can:
Control the ports assigned to tunnels, which is recommended if the hub will have more than one tunnel client
Create tunnel access lists to restrict access to a tunnel
Create hub-to-hub queues
Check the status of other hubs
This article covers the following topics:
Accessing the GUI

Setting up Hub-to-Hub Tunnels
Controlling the Ports Assigned to Tunnels
Creating Tunnel Access Lists
Creating a Static Route to a Hub
Creating Hub-to-Hub Queues
About UIM Queues
Example Queue
Controlling the Hub's Connectivity Behavior
Checking the Status of Other Hubs

Modifying the Log File Settings
Accessing the GUI

To open the hub configuration GUI:
1. In the Admin Console navigation tree, expand a hub and select its robot.
2. Click the arrow next to the hub probe and select Configure.
Note the following:
To restart the process, Deactivate and then Activate the hub probe.
Setting up Hub-to-Hub Tunnels

Follow these steps to set up a tunnel between two hubs.
Important: If your tunnel server will have multiple tunnel clients, you can control the port assignments instead of letting the hub assign
them based on the configuration for the controller probe. To control them, follow the steps in Controlling the Ports Assigned to Tunnels
before you create client certificates.
Note: Fields marked with an asterisk are required.
1. Ensure that both hubs appear in the Admin Console navigation pane. If either does not, create a static route to the hub.
3. Activate tunneling on the tunnel server:
a. In Admin Console, expand the hub that will be the tunnel server, then open its hub probe in the configuration GUI.
b. Select the Tunnel node. Check Tunnel Active and click Save.
4. Set up the tunnel server as a Certificate Authority. This creates a Certificate Authority certificate and enables the hub to create client
certificates.
a. Navigate to 1 - Tunnel Server.
b. In Tunnel Server CA Initialization, enter information about your organization.
c. Select Actions > Perform Tunnel Server CA Initialization. The CA certificate appears in the tunnel client certificate list.
d. Modify Tunnel Server Settings (optional):
Set Server Port to any available port (default is 48003).
Increase the Security Setting as desired.
5. Create the tunnel client certificate:
a. Under Client Certificate Configuration, specify the following:
Organization name, administrator email address, location (optional).
Common Name - enter the IP address of the tunnel client hub.
Note: Use regular expression to specify multiple tunnel client hubs and create multiple certificates.
Password - Create a password to be used to establish trust between the tunnel server and client. You will enter this password
when you install the certificate on the client.
Expiration days - Specify how long the certificate will be active.
b. Select Actions > Create Client Certificate. The certificate appears in the tunnel client certificate list
c. Copy all of the text in the Certificate field (below the Tunnel Client Certificate List) and close the GUI.
Note: Save the certificate to a file if you are not going to set up the tunnel client now.
6. Set up the tunnel client:
a.
6.
a. In Admin Console, expand the hub that will be the tunnel client and open its hub probe.
b. Navigate to Tunnel, check Tunnel Active, and click Save.
c. Navigate to 2 - Tunnel Client.
d. Under Client Certificates Configuration, click New. In the fields that appear:
Leave Certificate ID blank.
Server is the tunnel server's IP address.
If your environment uses NAT (network address translation), disable Check Server 'Common Name' Value.
Note: When this option is enabled, the tunnel server must verify that the tunnel is coming from the IP address specified in the
certificate. IP address mapping requires that this be disabled in NAT-ed environments. However, CA recommends you leave this
Optional: Enter a Description.
Enter the Password you created for the tunnel server.
Optional: modify the Keep Alive setting.
In the Certificate field, paste the text you copied from the tunnel server.
e. Click Save at the top of the page.
7. If you created a static route to a hub that is now connected to the message bus by a tunnel, you must delete the static route:
a. Expand the hub from which you configured the static route, then open its hub probe in the configuration GUI.
b. Navigate to Name Services and remove the static route.
Important! This must be done to ensure that all UIM data flows through the secure tunnel and not through the static route.
The tunnel is now active.
Controlling the Ports Assigned to Tunnels

If your tunnel server will have more than one tunnel client and you want to control the port assignments, perform the following steps on the tunnel
server before you create client certificates.
Important: This configuration is recommended for advanced users only. Contact Support if you need assistance.
1. In Admin Console, expand the hub that will be the tunnel server. Open its hub probe in the configuration GUI and navigate to Advanced
> Tunnel Settings.
2. In Tunnel Advanced Settings:
Enable Ignore Controller First Probe Port.
Specify the First Tunnel Port, the port to be used by the first tunnel you set up. For each additional tunnel, the tunnel server
increments the number and assigns that port to the tunnel client. The client keeps that port as long as the hub is running. Note the
following:
Make sure you do NOT use the port range that the controller probe uses.
3. Click Save.
Creating Tunnel Access Lists

By default, all UIM requests and messages can be routed over the tunnel and dispatched on the other side. This routing is transparent.
A tunnel Access List lets you restrict the access privileges for UIM users, addresses and commands. The Access List is created on the tunnel
client hub.
Recommendation: Use Infrastructure Manager to create these lists. Tunnel access lists created with the Admin Console hub configuration GUI
may have issues. Refer to Access List in the Infrastructure Manager hub configuration guide for details.

If a hub does not appear in the Admin Console navigation pane, you can create a static route to it. Follow these steps.
1. In Admin Console, expand the primary hub, then open its hub probe in the configuration GUI.
2. Navigate to Name Services.
3. In Static Hub List Entry:
Leave Active and Synchronize checked.
For Hostname/IP, enter the IP address of the secondary hub.
4. Select Actions > Create Static Hub.
5. Close the configuration GUI.
6. Verify that the secondary hub appears in the navigation pane.
Creating Hub-to-Hub Queues

will create:
Corresponding get queues on any intermediary secondary hubs and on the primary hub. These queues get the messages from the attach
queues.
You can either create one attach queue with the wildcard (*) subject to collect all messages, or create separate queues for different messages or
groups of messages. To learn more, refer to About UIM Queues.
Follow these steps:
1. In Admin Console, expand the hub, open the hub probe configuration GUI, and navigate to Queue List.
Queue Name: Enter a unique and descriptive name.
Recommendation: for usability, use a name similar or identical to the subject.
Active: Leave checked if you want to queue to be active immediately.
Type: Select attach, get, or post.
Note: The remaining fields in this area are active if they are required for the selected type.
Hub Address (get queues): Address for the hub that has the corresponding attach queue.
Subject (attach or post queues): Select the subject. Note that:
If the desired subject is not listed, enter it in the Queue List Entry Subject to Add field, then select Actions > Add Subject to List.
Remote Queue Name (get queues), which is the corresponding attach queue.
If desired, enter a Bulk Size, which specifies how many messages can be transferred simultaneously (in one bulk). The only time you
need to change this value from '<default>' is when you see that the queue grows and never shrinks to zero (see Subscribers Queues
on the Status tab). This indicates that the hub has problems delivering the messages to the target hub fast enough. The reason for
this behavior could be that the number of QoS messages delivered to the hub from the robots has increased a lot (See Statistics
button on the General tab) or that the latency is too high and slows down the deliveries (See Response Check, right-clicking a hub in
the hubs list).
About UIM Queues

alarms, alarms2).

Subject
Used by
Generated
by
alarm
Alarm messages
alarm2
alarm_new
alarm_update
alarm_close
Message sent when a client closes (acknowledges) an alarm and removes it from the currently active
alarms
alarm_assign
Message sent when a client closes (acknowledges) an alarm and removes it from the currently active
alarms
alarm_stats
statistical event messages generated by the NAS probe that contain severity level summary information
for all open alarms
audit
audit probe
probe_discovery
device information
discovery
probes
QOS_BASELINE
messages containing baseline data points for QoS metrics
QOS_DEFINITION
message that specifies a QoS definition
QOS_MESSAGE
All QoS messages
Example Queue
Controlling the Hub's Connectivity Behavior

When you install a hub, the way it connects with other hubs is determined by default values that are sufficient for most hubs. However, you may
want to adjust a hub's connectivity settings to meet the needs of your deployment or to improve performance. For example:
Hub Settings control the hub's request timeout, update interval and login mode.
Robot Settings specify the alarm sent for events that occur on robots connected to the hub.
Queue Settings control the behavior and size of queues.
Broadcast Configuration settings specify whether and where the hub lets other hubs know it is active.
Lockout Configuration settings let you avoid leaving the system vulnerable to brute-force password guessing.
1. In Admin Console, open the hub probe in the configuration GUI and navigate to Advanced.
2.
Checking the Status of Other Hubs

To check the status of another hub within your domain, follow these steps:
1. In Admin Console, open the hub configuration GUI for any hub in the domain.
2. Navigate to Hub List.
3. In the table that shows the status and other information for all hubs in the domain, select the hub you want to check.
4. Click Actions and choose the desired command:
Alive Check to view the status of the selected hub.
Response Check to view the response time (connect - reconnect, no transfer) between your hub and the one selected in the list.
Transfer Check to transfer data from your hub to the selected hub and view the transfer rate.
Modifying the Log File Settings

All UIM probes maintain log files. By default, the log file records:
Only messages classified as 0 - Fatal. This keeps a minimal amount of data.
If you are troubleshooting or debugging, you may want to view the hub's activity in more detail or keep more data in the log file. To do this:
1. In Admin Console, open the hub probe in the configuration GUI and navigate to the hub node.
2. In General Configuration, set the log level and file size as desired.
3. Activate the changes. Either:
Click Actions > Set In-Memory Log Level. This applies the changes without restarting the probe, but does not retain the changes
when the probe is restarted. This lets you view the hub's current activity in more detail.
Click Save at the top of the page. This restarts the hub and retains new settings.
v7.6 Hub AC GUI Reference

This section describes the configuration information and options available through the Admin Console hub configuration GUI. The navigation pane
hub
Advanced
SSL
Tunnel Settings
Hub List
Name Services
Queue List
Robot List
Tunnel
1 - Tunnel Server
2 - Tunnel Client
To access the hub configuration interface, select the hub's robot in the Admin Console navigation pane. In the Probes list, click the
arrow to the left of the hub probe and select Configure.
hub
Navigation: hub
This section lets you view information about the hub and adjust log file settings.
Probe Information
This section displays the probe name, start time, version and vendor.
Hub Information
This section displays the hub name, domain, IP address, hub address (/domain/hub_name/robot_name/hub), and uptime data.
License Information
This section displays details about the license used for the hub's robot is displayed; the total number of licenses and the number available
is also shown. An invalid license stops the message flow from the hub to its subscribers (mostly service probes) and prevents the robot
spoolers from uploading their messages.
This section lets you modify log file settings.
Log Level specifies the level of alarm information saved in the log file. 0 - Fatal (default) logs the least; 5 - Trace logs all alarms.
Recommendation: Log as little as possible during normal operation to reduce disk consumption. Increase the level when debugging.
Log Size controls the amount of data retained in the log file (in KB, default is 1024). Large log files can cause performance issues,
therefore use caution when changing this size.
One command is available.
Actions > Set In-Memory Log Level makes changes to the log file settings take effect immediately without restarting the hub, which
lets you view more detail about the hub's current activity. The settings are retained until the hub restarts.
Advanced
Navigation: hub > Advanced
This section allows you to control the hub's connectivity behavior.
Hub Settings
This section controls how the hub communicates.
Hub Request Timeout specifies how long the hub waits for a response from other hubs. Default: 30 seconds.
Hub Update Interval specifies how often the hub sends its messages to the other hubs. Default: 600 seconds.
Origin identifies the sender for data sent by the probes. It is used when reports are generated. This field obtains the origin from the co
ntroller probe configuration. This field is blank if the origin is not specified in the controller, and the hub name is used. The origin is
specified in the Controller probe configuration.
Disable IP Validation turns off the IP address validation the hub does for all computers sending requests to its probes. It is typically
used when using NAT (Network Address Translation).
Normal (default) allows logins from any robot connected to the hub.
Local Machine Only allows logins only from the computer hosting the hub. Attempts from any other robot connected to the hub
are refused.
No Login disables all logins to the hub.
Broadcast Configuration
This section controls whether and where the hub lets other hubs know it is active.
Broadcast On (default) enables the hub to broadcast its status.
Broadcast Address is the IP address on which the hub broadcasts. Default is 255.255.255.255 (the default broadcast address for
any local network).
Lockout Configuration
This section controls the lockout settings for the hub to avoid leaving the system vulnerable to brute-force password guessing.
Login Failure Count specifies the number of attempts from a single IP address.
Robot Settings
This section controls the alarm settings for events that occur on all robots connected to the hub.
Inactive Robot Alarm Severity specifies the level or warning sent when a robot fails to respond.
Audit Settings for Robots lets you turn auditing on or off for all of the hub's robots, or allow each robot to use its own settings.
Note: Auditing records important events, such as starting and stopping the robot.
Audit Once per User
Queue Settings
This section controls the behavior and size of queues.
Reconnect Interval is the number of seconds between a disconnected hub's attempts to reconnect (default is 180).
Disconnect Passive Queues specifies how long a queue can be passive (receive no messages) before being disconnected (default
is 180).
Post Reply Timeout specifies how long a hub waits for a reply to a message. A timeout occurs if no response is received within this
interval.
Alarm Queue Size is the size of the queue file on the hub. An alarm is sent if the queue exceeds this threshold (default is 10 MB)
SSL
Navigation: hub > Advanced > SSL

This section lets you configure a hub to use SSL.
SSL
This section lets you configure SSL settings. This configuration must be done on all hubs that require SSL.
Normal (login allowed) lets only UIM users log in to the hub.
Compatibility Mode (recommended) is mixed SSL/Normal mode. The system checks for SSL compatibility. If SSL compatibility
does not exist, the system uses the UIM login.
SSL Only lets the hub communicate only with components that support SSL.
Important: This mode significantly reduces traffic bandwidth and performance. Also note that some probes (particularly older ones)
do not support SSL. Mixing different versions of UIM components is not possible with the SSL Only mode.
Note: SSL settings for UIM components are controlled each component's hub. The hub propagates SSL settings to the robots; the
robots then propagate the settings to the probes.
Cypher Type specifies the Cypher Suite used by that the OpenSSL library.
Tunnel Settings
Navigation: hub > Advanced > Tunnel Settings

This section let you control the behavior of the hub's tunnels.
Tunnel Advanced Settings
These settings control how tunnels connect.
Enabled: the hub uses the First Tunnel Port setting (recommended if the hub will have more than one tunnel server).
Disabled: the tunnel is assigned the port number specified as First Probe Port in the controller probe configuration.
First Tunnel Port specifies the port to be used by the first tunnel you set up. For each additional tunnel, the tunnel server increments
the number and assigns that port to the tunnel client. The client keeps that port as long as the hub is running. Note the following:
Hang Timeout (in seconds, default is 120) specifies the interval between automatic tunnel restart attempts. The tunnel server
continuously checks the status of its tunnels. If a tunnel does not respond, the hub attempts to restart it. If it does not respond within
the time specified, it attempts another restart, and will continue to do so until the tunnel is active.
Tunnel SSL Session Cache
These settings control SSL caching.
Use Client Cache / Use Server Cache enables caching of SSL sessions, which allows previous session credentials to be used.
Enabling both options significantly speeds up the server/client connection time.
Server Cache Timeout (in seconds) specifies how long the cached sessions are valid for reuse by the client. Default is 7200 (2
hours).
Server Cache Size specifies how much data is stored in the cache. Default is 1024 KB.
Hub List
Navigation: hub > Hub List
This section lists all the hubs within a UIM domain, displays information about them, and lets you check their status.
Hub List
This section displays the following information about each hub:
Domain
Name
Status
Last Updated, date and time when the hub probe was last restarted
IP address
Port
Three commands let you check the status of other hubs:
Actions > Alive Check checks the status of the selected hub.
Actions > Response Check checks the response time (connect - reconnect, no transfer) between your hub and the one selected in
the list.
Actions > Transfer Check transfers data from your hub to the one selected in the list and checks the transfer rate.
Name Services
Navigation: hub > Name Services
This section lets you ensure hubs separated by firewalls or routers can discover each other and that hubs in a NAT environment can return
requests.
Static Hub List Entry
This section lets you enter information for the static route.
Active: enable to ensure the route is active upon creation.
Synchronize: enable to ensure the hub sends status information to the static hub.
Hostname/IP of the static hub.
Actions > Create Static Hub sets up the static route.
Static Hub List
This section displays the hubs to which there is a static route from the hub being configured.
Active indicates the route is active.
Synchronize indicates the hub is sending status information to the static hub.
Name, IP, Domain, and Robot Name identify the static hub.
Actions > Remove Static Hub removes the selected static hub.
Network Aliases
In a NAT environment, network aliases let the hub know the appropriate return address for requests from remote hubs.
From Address is the address from which the remote hub sends requests.
To Address is the address to which the responses should be sent.
Queue List
Navigation: hub > Queue List
This section lets you create hub-to-hub queues.
Queue List Entry
This section lets you add a new queue subject.
Subject To Add lets you specify the new subject.
Note: Some subjects are reserved for use by UIM probes. See Reserved UIM Subject IDs.
Actions > Add Subject To List adds a queue subject immediately so it can be used in a new queue.
Queue List Configuration
This section lets you enter information for new queues or view the configuration of existing queues. Some fields are specific to the type of
queue being created.
New and Delete let you add and delete queues.
Queue Name is the name of the queue being created.
Active shows the queue status.
Type specifies the type of queue being created: attach, post or get.
Hub Address (get queues) is the UIM address of the hub that has the corresponding attach queue.
Subject (attach or post queues) specifies the type(s) of messages to collect in the queue.
Remote Queue Name (get queues) is the name of the corresponding attach queue.
Remote Queue List (get queues) displays available attach queues found in the domain.
Bulk Size specifies the number of messages to be transferred in one package.
Robot List
Navigation: hub > Robot List
This section lists all the robots controlled by the hub, displays information about them, and lets you restart them.
Robot List
This section displays the following information about each robot.
Name
Status
IP address
Version of the robot probes
OS version and information
Two commands are available.
Actions > Alive Check checks the status of the selected robot.
Actions > Restart restarts the selected robot.
Tunnel
Navigation: hub > Tunnel
This section enables tunneling on a tunnel server or tunnel client. This must be done once on each hub that will have a tunnel.
1. Tunnel Activation
Tunnel Active: Check this option and then click Save to enable tunneling.
1 - Tunnel Server
Navigation: hub > 1 - Tunnel Server

This section lets you configure a hub to be a tunnel server.
Certificate Authority (CA) Initialization
This section lets you designate a hub as a Certificate Authority.
Note: This is a one-time task. After it has been done, this section will display Tunnel Server CA Is Initialized.
Server Settings
This section shows the tunnel server's status.
Active indicates the tunnel is running.
Tunnel Server Status shows whether the tunnel is running or stopped (change the status with the Actions commands).
Common Name is the IP address of the tunnel server.
Expiration Days shows the date the tunnel expires.
Server Port is the port the tunnel server will use to transfer data (default is 48003).
Security Setting specifies the encryption level used for tunneled packets:
NONE: No encryption but uses authentication. Fast but not very secure.
LOW: Fast but not very secure encryption and authentication.
MEDIUM: Slow but secure encryption and authentication.
HIGH: Slow but very secure encryption and authentication.
CUSTOM: Slowest but most secure encryption and authentication.
Custom Cipher * is specified when the Security Setting is Custom.
CA Certificates
This section lets you create the CA certificates, which give the hub the authority to issue client certificates.
Organization Name, Organization Unit Name, and Email Address identify the issuing entity.
Common Name is the IPV4 or IPV6 address (hexadecimal format) for the tunnel server hub.
Beginning Date and Ending Date specify when the certificate is valid.
Client Certificate Configuration
This section lets you create client certificates.
Note: Every tunnel client that will connect with the tunnel server requires a unique client certificate.
Organization Name, Organization Unit Name, and Email Address identify the receiving entity.
Common Name is the IPV4 or IPV6 address (hexadecimal format) for the tunnel client hub.
Note: The tunnel client hub must be active when the certificate is created.
Password lets you specify the password that will allow the tunnel client hub to access the tunnel server.
Beginning Date and Ending Date show when the certificate is valid.
Certificate * displays the client certificate text, which must be copied to the tunnel client hub configuration.
Actions > Create Tunnel Server Client Certificate creates the certificate.
Client Certificate List
This section lists your client certificates.
New and Delete let you add and delete certificates.
Rows in the table display information about the certificates.
Fields below the table display details for the selected certificate.
Certificate * displays the certificate text, which must be copied and pasted into the tunnel client hub configuration.
2 - Tunnel Client
Navigation: hub > Tunnel > 2 - Tunnel Client

This section lets you configure a hub to be a tunnel client.
Client Certificate Configuration
This section lets you add, delete and view tunnel client certificates.
Certificate ID is the number assigned to the certificate.
Active shows the certificate status.
Server * specifies the IP address of the tunnel server hub.
Server Port * specifies the port to be used for tunneled data.
Check Server 'Common Name' Value makes the tunnel server verify that the tunnel is coming from the IP address specified in the
client certificate. IP address mapping requires that this be disabled in NAT environments. However, CA recommends you leave this
Description lets you describe the tunnel.
Password * is the password that was defined when the tunnel client certificate was created.
Keep Alive (in seconds) specifies the interval at which small data packets are sent. This is to allow for firewall connection disruption
on idle connections.
Certificate * is where you paste the client certificate text (which was created on the tunnel server hub).
Navigation: hub > Tunnel > Tunnel Access List

This section lets you restrict the access privileges for UIM users, addresses and commands.
Recommendation: Due to issues with tunnel access lists created with this release of the Admin Console hub configuration GUI, CA recommends
you use Infrastructure Manager to create these lists. Refer to Access List in the Infrastructure Manager hub configuration guide for details.
Tunnel Access List
This section lets you create tunnel access lists.
New and Delete let you create or delete an access list.

Source IP * is the IP address of the tunnel server, or the wildcard character (*).
Destination Address * is the address of the target hub, robot or probe.
Probe Command is the specific command you want to allow or deny. To find the command set, click the icon next to the hub probe
and select Probe Utility.
User * to whom you want to allow or deny access (regular expression is allowed).
Mode *
These settings let you specify the access mode.
ACCEPT access for the specified user, command or probe.
DENY access for the specified user, command or probe.
Note: This is normally used for debugging purposes when testing commands against targets before setting them up as accept or
deny rules. The result can be viewed in the hub log file before your deny or accept rules.

This article explains how to use Infrastructure Manager to configure a hub. For an overview of the hub, see hub.
Hub configuration includes:
Setting up hub-to-hub communication. If you have any secondary hubs in your deployment, you must create queues between them and
Checking traffic statistics for the hub and monitor its message flow.
Performing advanced configuration to tune hub performance.
See the following sections for details:

Setting up Queues
About UIM Queues
Example Queue
Setting up a Tunnel
Setting up a Tunnel in a NAT Environment
Checking Traffic Statistics
Monitoring the Message Flow
Alarm Configuration
LDAP Configuration

Hubs discover other hubs by sending out broadcast (UDP) messages. This enables them to connect to the message bus. Secondary hubs that
are separated from the primary hub by routers or firewalls are unable to discover other hubs by this mechanism, and therefore cannot be
configured with Infrastructure Manager. You must configure a static route to these hubs. For example, static routes can be used to:
Connect two hubs that are in the same sector of a customer environment but in different network subnets.
Connect a hub outside a firewall so that you can create a secure tunnel to the hub.
Important! Do not connect a hub with both a tunnel and a static route. In some situations, data could be transmitted over the
insecure static route rather than over the secure tunnel. If you set up a static route so that you can configure a tunnel, make
sure you delete the static route after the tunnel is complete.
Follow these steps to set up a static route to a hub.

1. In Infrastructure Manager, navigate to the local hub that will tunnel to the remote hub, and open its hub probe in the configuration GUI.
4. In the New Static Hub dialog:
Leave Active enabled.
If desired, disable Synchronize. If this option is not checked, the parent hub does not send status information to the static hub. The
parent hub will still receive status info from the static hub, unless you disable this option on the static hub as well. Disabling this option
can reduce network traffic if your network runs on a telephone line or ISDN.
Enter the IP address of the static hub.
Note: The system fills in the Hub Information fields (hub name, domain and robot name) with information retrieved from the remote hub.
Setting up Queues
will create:
Corresponding get queues on any intermediary hubs and on the primary hub.
You also can create post queues, which stream messages directly to a destination hub. To learn more, refer to About UIM Queues.
Follow these steps to set up a hub-to-hub queue.
1. On a hub that will have the attach queue:

Active - enabled
Name - name of queue (must match the name of the get queue)
Type - attach
2. On a hub that will have the get queue:
Active - enabled
Type - get
Address - select the address of the hub that has the attach queue
2.

3. Click New, then specify:
Active - enabled
Name - name of queue
Type - post
Address - select the address of the hub that will receive the messages
About UIM Queues

alarms, alarms2).

Subject
Used by
alarm
Alarm messages
alarm2
alarm_new
alarm_update
alarm_close
alarm_assign
alarm_stats
Statistical event messages generated by the NAS probe that contain severity level summary information for all open
alarms
audit
probe_discovery
Device information
QOS_BASELINE
QOS_DEFINITION
QOS_MESSAGE
All QoS messages
Example Queue
Setting up a Tunnel
Most companies have one or more firewalls in their network, both 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 (Virtual Private
Network) 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.
Tunnels can be created during hub installation, or afterward by configuring the hubs. This following process explains how to set up tunnels
between hubs that are already installed. Click the links for more information.
To set up a tunnel, you must:
The Tunnel Client accepts the attempt to setup the tunnel.
2. Ensure that both hubs appear in the navigation tree. Hubs discover each other by sending out broadcast (UDP) messages. However,
hubs separated by routers and firewalls are unable to discover other hubs by this mechanism. You must configure a static route to these
hubs.
3. Set up the tunnel server as a certificate authority. This creates a server certificate and gives the hub the ability to generate digital client
certificates.
4. Create the certificate for the tunnel client. This task is done on the tunnel server.
6. Remove the static route to either hub if you created one.
7. Create queues between the hubs, just as you would for secondary hubs that are not connected with tunnels. Refer to Setting up Queues.
8. Optional: On the tunnel client, you can set up access list rules to restrict tunnel access privileges for specified UIM addresses,
commands, or users.
Note: Networks that use NAT (Network Address Translation) affect how a tunnel is configured. For example configurations, refer to Setting up a
Tunnel in a NAT Environment.

Perform these tasks on the hub that will be the tunnel server.
2. On the General tab, select the Enable Tunneling.
3. Click the Tunnels tab, then click Server Configuration.
4. Enable the Active option.
4.
5. In the Certificate Authority Setup dialog, enter your organization's information:

Who (optional): Company name, Organization unit, and e-mail address of your administrator
Where (optional): Country, state and community of your organization
Common Name: Host name of the hub that will be the tunnel server.
Password: Password for the authentication.
Expire days: How long the CA is valid.
6. Click OK.
The hub is now a Certificate Authority and the server certificate is generated. This certificate is the basis for all the Client Certificates
generated by this tunnel server.
7. Select a security setting: None, Low, Medium, High, or Custom (which lets you define your own security setting; see www.oenssl.org/doc
s/apps/ciphers.html for information).

Once the tunnel server hub is configured to be a Certificate Authority, you can create client certificates. You create the certificate on the tunnel
server hub. Follow these steps.
1.
2. On the Tunnels tab, navigate to Server Configuration and click New.
3. In the Client Certificate Setup dialog, enter your information.
Authentication (required) - Enter the following:
Expire days - Number of days the certificate will be valid
4. Click OK.
6. Click Copy. Open a text editor (such as Notepad) and paste the certificate into a new blank file. Save the file to a location where the
tunnel client can access it. Exit the Certificate Information dialog.
7. Click Apply, then click Yes when asked to restart the probe.

is defined on the tunnel client hub.
You can use regular expressions when defining the access rules.
Tip: When making a restrictive list, start with a few Accept rules, then make a Deny rule that denies access for all others. When making a less
restrictive list, start with a few Deny rules, then make an Accept rule that gives access for all others.
To add a rule:
1. Navigate to the Access List tab.

2. In the Edit Rule area, enter:
Source IP - IP address for the source hub, robot or probe
Destination Address - address of the target hub, robot or probe
Probe Command - the specific command you want to allow or deny (to view a probe's command set, open the Probe Utility for the
probe)
User - name of the user you want to allow or deny access
3. Select the mode: Accept, Deny, or Log.
In the rules table, use the Move Up and Move Down buttons to change the order of the rules. The order sets the priority.
In the example below, the first rule allows the administrator user on all nodes to access the target hub through the tunnel. The second
rule denies access to all users. If you place the Deny rule first, all users - including administrator - are denied access.
5. Click the Apply button to activate the list.

Follow these steps.
1.
1. In Infrastructure Manager, navigate to the hub that will be the tunnel client and open its hub probe in the configuration GUI.
3. Go to the Tunnels and click Client Configuration.
Leave the Active Tunnel and Check Server Common Name options enabled.
Enter the IP address of the tunnel server hub.
Enter the password you created when you generated the certificate.
Copy the certificate text from the file you saved it to, and paste it in the Certificate field.
Enter the server port or leave it blank to let the system assign the port.
If desired, specify a keep-alive interval.
5. Click Apply to activate the client.

The tunnel is now up and running between the tunnel server and tunnel client.
Setting up a Tunnel in a NAT Environment

Networks that use NAT (Network Address Translation) affect how a tunnel is configured.
The scenarios below describe three possible configurations.
Important! You should be aware that when a tunnel is configured, it replaces the static hub and NAT setup in the hub configuration.
The Client certificate must be issued to (CommonName)--the IP address that is visible to the Server, which is in this case 10.2.1.111, not 193.71.5
5.111.
Uncheck the Check Server CommonName option in the Tunnel Client Setup Window. The reason for this is that the Server certificate has
10.1.1.1 as CommonName, not 202.1.1.1 which is what the client sees.
Combine the two methods described above. The Client certificate must be issued to (CommonName)--the IP address that is visible to the Server
(10.2.1.111) and uncheck the Check Server CommonName option in the Tunnel Client Setup Window.
Checking Traffic Statistics

Viewing traffic statistics can help you avoid bottlenecks and to tune your UIM system. Statistics are available for the previous 30 days.
1. Click the Statistics button in the lower right corner of the configuration GUI.
2. View the total traffic managed by the hub:
Messages sent per minute
Messages received per minute
Requests per minute
If you want to view the data from a specific period of time, change the dates and click Get.
Monitoring the Message Flow

2. In the Monitor window, click Traffic, Sniffer, or Tunnel to view the traffic the desired way:
Traffic displays a graph of the number of messages sent, received, and requested per second, and provides two lists:
Subscribers shows the permanent queues defined on the Queues tab.
Subjects shows all subjects defined for the queues.
Sniffer lets you filter the information by subject, probe, and/or robot:
c.
c. Select a message in the list to open a callout containing vital information about the message, such as QoS name, QoS source,
QoS target, the time the sample was recorded, the sample value, etc.
Tunnel allows you to view the commands performed on the active tunnels. Click Start to view the the following information for each
command:
IP address and port number of of the client that executed the command.
Start and stop time for the transfer.
Total time used by the request through the tunnel (both directions).
UIM address to which the command was sent.
Last command issued during the message transfer.
Number of bytes sent and received during the session.

Follow these steps.
1. In Infrastructure Manager, navigate to the hub probe.
2. Ctrl+right-click the hub probe and select Raw Configure.
3. Select the hub section, and use New Key, Edit Key, and Delete Key to modify the keys as needed.
See the following sections for information on:
Alarm configuration
LDAP configuration
Alarm Configuration
The httpd probe (hyper-text transfer protocol daemon) provides a simple http server that can be used to share information across the intranet.
LDAP Configuration
Timeout
Number of seconds to spend on each LDAP operation, such as searching or binding (authentication) operations. Default: 15 seconds.
codepage
Codepage to use when translating characters from UTF-8 encoding to ANSI. When text comes from the LDAP library as UTF-8, UIM
uses this codepage to translate the characters into ANSI.
Windows: Specify a valid codepage.For a list of codepages, go to . Note that the hub LDAP library uses the MultibyteToWideChar
and WideCharToMultiByte functions to translate to and from ANSI/UTF-8. These functions take a codepage as a parameter.
Default: 28591
Unix: Use iconv functions. Refer to http://www.gnu.org/software/libiconv.
Default: ISO-8859-1
The codepage key is not shipped with the hub configuration file. The default codepage is ISO 8859-1 Latin 1; Western European (ISO).

Advanced configuration lets you control how a hub communicates with its passive robots. Add any or all of the following keys to the hub section.
The hub communicates with a robot through worker threads from a thread pool. The default is 10, but we recommend you set the pool to
50% of the number of passive robots you have.
The number of seconds between trying to retrieve messages from a passive robot. Default is15 seconds.
The number of messages the hub will accept from a passive robot in a single retrieval interval. Default is 1000.
The amount of time the comms API will block a call to a robot that is not responding. Default is 15 seconds.
The interval between retrying a non-responding passive robot will double every 10 minutes up to this value.
The hub will wait for this length of time for passive robot management threads to stop before it kills them. Default is 60 seconds.
Important! This should not be modified without advice from support because it can cause a significant delay in monitoring
functions.
Alarm
Configuration
Send an alarm when there are a significant number of subscriptions or queues (which can decrease hub performance).
Specify:
The httpd probe (hyper-text transfer protocol daemon) provides a simple http server that can be used to share information
across the intranet.
LDAP
Configuration
Timeout
Number of seconds to spend on each LDAP operation, such as searching or binding (authentication) operations. Default:
15 seconds.
codepage
Codepage to use when translating characters from UTF-8 encoding to ANSI. When text comes from the LDAP library as
UTF-8, UIM uses this codepage to translate the characters into ANSI.
Windows: Specify a valid codepage.For a list of codepages, go to . Note that the hub LDAP library uses the
MultibyteToWideChar and WideCharToMultiByte functions to translate to and from ANSI/UTF-8. These functions take a
codepage as a parameter.
Default: 28591
Unix: Use iconv functions. Refer to http://www.gnu.org/software/libiconv.
Default: ISO-8859-1
The codepage key is not shipped with the hub configuration file. The default codepage is ISO 8859-1 Latin 1; Western
European (ISO).
Passive
Robot
Configuration
Advanced configuration lets you control how a hub communicates with its passive robots. Add any or all of the following keys
to the hub section.
The hub communicates with a robot through worker threads from a thread pool. The default is 10, but we recommend
you set the pool to 50% of the number of passive robots you have.
The number of seconds between trying to retrieve messages from a passive robot. Default is15 seconds.
The number of messages the hub will accept from a passive robot in a single retrieval interval. Default is 1000.
The amount of time the comms API will block a call to a robot that is not responding. Default is 15 seconds.
The interval between retrying a non-responding passive robot will double every 10 minutes up to this value.
The hub will wait for this length of time for passive robot management threads to stop before it kills them. Default is 60
seconds.
Important! This should not be modified without advice from support because it can cause a significant delay in monitoring
functions.

To access the Infrastructure Manager hub configuration GUI, navigate to the hub you want to configure, then either:
Expand its robot and double-click the hub probe.
This article describes the tabs, fields and options available in the Infrastructure Manager hub configuration GUI. See the following sections for
details:
General Tab
Hubs Tab
Robots Tab
Name Services Tab
Queues Tab
Tunnels Tab
Access List
Advanced
Status Tab
General Tab
The General tab contains the basic hub information in the following sections.
Hub information provides the following:
Hub name
Domain to which the hub belongs
Hub IP address
Hub address in UIM format:/domain/hub_name/robot_name/hub
Version number and distribution date of the hub probe
Uptime, the length of time the hub probe has been running since the last time it was started
Modify (button) opens the Edit Hub Address dialog, enabling you to edit the hub name and domain (note that the hub's controller
probe restarts if you modify these parameters)
License information
Each hub maintains a license system used by all of the robots connected to the hub. An invalid license causes the message flow from the
hub to its subscribers (mostly service probes) to stop. It also stop the various robot spoolers from uploading their messages as long as
the license key is invalid. The license key is built based on the following fields:
Licenses in use shows the number of robots currently connected to this hub, and the number of robots the license allows.
Expire date specifies when the license expires. An asterisk (*) indicates an unlimited license.
Owner of the license.
Modify (button) opens the Edit License dialog, which contains the hub's license key. License keys are provided by CA and must be
entered exactly as specified.
Login Settings for this hub
This section lets you configure your log in settings for the hub.
Normal (login allowed) allows users to log on the hub from any robot.
Local machine only allows normal login on the hub if attempting to log in from the computer hosting the hub. Attempts to log in from
other robots are refused
No login disables login to the hub from either the local machine or a robot connected to the hub.
Log Level lets you specify the level of detail written to the log file.
Recommendation: Log as little as possible during normal operation to reduce disk consumption, and increase the level of detail when
debugging.
Log Size sets the size of the log file (default is 1024 KB). Large log files can cause performance issues, therefore use caution when
changing this size.
Advanced allows you to view and configure advanced options for the hub.
Enable tunneling activates the tunnel tab, where you can configure the tunnels. To disable tunnels, uncheck this option and click Ap
ply.
Disable IP validation. When a computer sends a request to a probe, the computers IP-address is validated. This option is typically
used when using NAT (Network Address Translation). See Setting up a Tunnel in a NAT Environment.
Statistics (button) displays traffic statistics for the hub for the previous 12 hours.
The graph shows the number of messages sent and received per minute, in addition to the number of requests. The Period section
lets you specify a time period. Click Get to update the values.
See Checking Traffic Statistics for more information.
Monitor (button) displays the current hub traffic. See Monitoring the Message Flow for more information.
View Log (button) displays the contents from the hubs log file. The log settings allow you to set the level of detail for the logging
function.
The Log Viewer window provides the following:
File lets you save or print the file.
Edit lets you copy the contents and search in the log file.
Actions lets you limit the output in the window and highlight text or the date within the log file.
Start and Stop buttons let start/stop the log file updates.
Settings (button) opens the Hub Advanced Settings dialog. See Hub Advanced Settings for more information.
Navigation: General > Settings

General
SSL
LDAP
The General tab lets you specify the following settings.

Broadcast On turns the discovery broadcast on or off. You can specify the address on which the hub broadcasts (tells all other hubs that
it is alive). The default broadcast address is 255.255.255.255.
Hub Settings
Hub Request Timeout is the timeout value for hub communication requests. Default is 30 seconds.
Hub Update Interval is the interval at which the hub sends status information to the other hubs. Default is 600 seconds.
Queue Settings
Reconnect Interval is the interval at which a disconnected queue will be reconnected. Default is 180 seconds.
Disconnect passive queues is the interval at which queues that have been passive (no messages) will be disconnected. Default is
180 seconds.
Post Reply Timeout is the interval of time a hub waits for a reply to a message. A timeout will occur if no response is received within
this interval.
Alarm on queue size is the size of the queue file (in megabytes) on the hub. An alarm is sent if the queue exceeds this threshold.
Default is 10.
Lock Out Time

If the number of consecutive login failures from a user or an IP address reaches the Lock After Fails value, the system will not permit new
login attempts until the Lock Out Time has passed.
Important! These changes are not persistent, that is they do not survive over a hub stop and start.
Origin identifies where a message came from. QoS messages from probes are tagged with a name to identify the origin of the data. By
default, the name of the probes's parent hub is the origin. To override that value, you can:
Change the value here. The new value will be used for all QoS messages handled by the hub.
Set the origin at the robot level (in the Setup > Advanced section in controller configuration GUI).
Audit Settings for Robots allows the recording of important events, such as starting and stopping the robot. This setting is used for all
robots serviced by this hub. Select one of the following options:
Override: audit off
Override: audit on
Navigation: Hub > Settings > SSL

SSL settings are specific to each hub. Set them on each hub that requires SSL.
Normal (login allowed) lets only UIM users log in to the hub.
Compatibility Mode (recommended) is mixed SSL/Normal mode. The system checks for SSL compatibility. If SSL compatibility
does not exist, the system uses the UIM login.
SSL Only lets the hub communicate only with components that support SSL.
Important: This mode significantly reduces traffic bandwidth and performance. Also note that some probes (particularly older ones) do
not support SSL. Mixing different versions of UIM components is not possible with the SSL Only mode.
Note: SSL settings for UIM components are controlled each component's hub. The hub propagates SSL settings to the robots; the
robots then propagate the settings to the probes.
Cypher Type specifies the Cypher Suite used by that the OpenSSL library.
There are two configuration options for LDAP: direct LDAP or Nimsoft Proxy Hub.
Direct LDAP
The hub can be configured to forward login requests to a LDAP server. This makes it possible to log on to the UIM consoles with LDAP
credentials. Users belonging to different groups in LDAP can be assigned to different UIM Access Control Lists (ACLs).
Note: Direct LDAP is only available on Linux and Windows hubs, due to the availability of the LDAP library the hub uses. Native LDAP is
not supported on Solaris.
Server Name: The hub can be configured to point to a specific LDAP server, using IP address or host name. A Lookup button lets you
test the communication. If you used a non-standard port for your hub, you must use the syntax "hostname:port" to indicate the server
name.
Note: You can specify multiple servers in this field, each separated with a space. The first entry acts as a primary server, while the
others act as secondary servers (taking over if the primary server goes down). Logins may take more time if a secondary server has
taken over.
Server Type: Choose an LDAP server type. Currently two server types are supported: Active Directory and eDirectory.
Use SSL: Select this option if you want to use SSL during LDAP communication. Most LDAP servers are configured to use SSL.
User and Password: You must specify a user name and a password to be used by the hub when accessing the LDAP server to
retrieve information:
Active Directory - the user can be specified as an ordinary user name.
eDirectory - the user must be specified as a path to the user in LDAP in the format CN=yyy,O=xxx, where CN is the user name and O
is the organization.
Group Container (DN): Specify a group container in LDAP to define where in the LDAP structure to search for groups. Click Test to
check if the container is valid.
User Container (DN): Specify a user container in LDAP to define more specifically where in the LDAP structure to search for users.
Nimsoft Proxy Hub
The hub can be configured to specify a UIM probe address to log in through.
Proxy Hub: The drop down list is empty by default. Click the Refresh icon next to the drop down list to perform a gethubs probe
request on the hub you are configuring, which will populate the drop down list with the hubs it knows about.
Proxy Retries: Specify the number of retries to perform in case of communication errors (network errors).
Proxy Timeout: Specify the time (in seconds per attempt) after which the proxy will be timed out.
Hubs Tab
This tab lists all known hubs and displays their information in different text colors:
Blue: Hub is within the same domain as the hub you are currently logged on to.
Black: Hub is outside the domain.
Red: Hub status is unknown, typically because the hub is not running.
The list contains the following information about each hub:

Status indicator:
Green - running
Red - not running
Domain
Hub name
Remove removes the selected hub from the hubs address list. The hub may appear later if it is running.
Robots Tab
The Robot tab lists lets you set the alarm level for robots and displays robot information.
Inactive Robot setup lets you set the severity level of the alarm issued if one of the robots in the list becomes unavailable.
Registered Robots displays the following information for each robot controlled by the hub:
Name
IP address
Operating system of the robot's host system
Right-clicking in the window opens a small menu with the following options:
Restart
This option only re-reads the configuration file for the selected robot. It does not do a stop and restart of the robot. If you have made any
changes to the robot configuration you must stop and restart the robot.
Check
Checks the selected robot.
Remove
Removes the selected active or passive robot from the list. An active robot may show up later since active robots will periodically request
the hub add them to the Registered Robots list.
Add Passive Robot
Opens the dialog to add a passive robot.
Name Services Tab

A hub knows the IP address and port number of all probes started by the robots that it controls. The robots are responsible for reporting all
changes in configuration and probe state to its hub. When a client (GUI or probe) wants to send a request to a probe it must first ask the local hub
for the address, if the target probe is on another hub the request is forwarded to that hub. The client can continue with the request to the probe if
the name-lookup succeeds.
Static Hubs
The hubs discover each other by sending out broadcast (UDP) messages. Hubs separated by routers and firewalls are normally unable
to discover other hubs by this mechanism. You must configure a static route to these hubs.
Note the Synchronize option in the New Static Hub dialog. If this option is not checked, the parent hub will not send status info to the
static hub. The parent hub will still receive status info from the static hub, unless you disable the Synchronize option on the static hub as
well.
This option can be disabled to reduce network traffic if your network runs on a telephone line or ISDN.
Important! Do not connect a hub with both a tunnel and a static route. In some situation, data could be transmitted over the
insecure static route rather than over the secure tunnel. If you set up a static route so that you can tunnel to a hub, make sure
you delete the static route after the tunnel is configured.
Network Alias tells the local hub the return address on requests from a remote NAT hub.
On hub A, set up the From address and the To address for hub B.
On hub B, set up the From address and the To address for hub A.
When hub B sends a request to hub A, the request will contain hub Bs From address. Hub A then knows that hub Bs To address must
be used when returning a request to hub B.
Queues Tab
The Queues tab lists all defined message queues. These include the queues that are automatically deployed, and those that an administrator
adds as needed. For example, if alarms need to be communicated from a secondary hub to the primary hub, you would create an attach queue
named nas with the subject alarm to forward alarms.
To edit a message queue, double-click the message queue (or select the message queue and click the Edit button).
Permanent queue content survives a hub restart. Permanent queues are meant for service probes that need to pick up all messages,
regardless of whether the service probe was running when they were created.
Temporary queue content is cleared during restarts. These queues are typically used for events to management consoles.
All queues defined on the Queues tab are permanent queues. Permanent queues are given a name related to their purpose. The permanent
queue named NAS is attached to the NAS (Nimsoft Alarm Server). You can set up a permanent queue from one hub to another by defining it as a
post type queue with the full UIM address of the other hub.
An Attach queue creates a permanent queue for a client to attach to.
A Get queue gets messages from a permanent attach queue on another hub.
The queue defined below (called get-hub-4) is defined as a get queue, getting messages from the queue xprone-attach defined on the
hub /HubTest/wm-hub-4/vm-hub-4/hub.
The dialog contains the following fields.

Active - Selecting this option activates the queue. This will also be reflected in the queue list under the Queues tab. Note that you may
also activate/deactivate the queues in the list.
Name is a unique and descriptive identifier of the queue. A required field.
Type of queue:
Post queues send a directed stream of messages to the destination hub.
Attach queues create a permanent queue for a get queue to attach to.
Get queues get messages from a permanent attach queue (on another hub).
Address is the UIM address of the source or target hub, and applies for get and post queues only. Can be selected from the drop-down
list.
Queue (for get queues) specifies the attach queue on another hub to get messages from.
Subject (for attach or post queues) specifies the messages that will be directed into the queue. Astersisk ( * ) for the subject collects
messages of all subjects.
All UIM messages contain a Subject ID, a text that classifies the message for all components on the message bus. This allows
components to subscribe to some messages and ignore others. All messages with the same subject should also have identical data
structure.
Unable to render {include}
The included page could not be found.
Tunnels Tab
This tab is enabled if the Enable Tunneling option is checked on the General tab of the hub configuration GUI.
Most companies have one or more firewalls in their networks, both internally between different networks and externally against a DMZ or Internet.
This makes it challenging to administer and monitor the whole network from a central location.
The solution is to set up a tunnel between two hubs that are separated by a firewall. The tunnel:
Sets up a VPN-like (Virtual Private Network) connection between the hubs. All UIM requests and messages are routed over the tunnel
and dispatched on the other side. This routing is transparent to all UIM users.
Requires that the firewall open one port for connection to the target hub.
Is implemented using the SSL (Secure Socket Layer) protocol.
Security is handled in two ways; certificates that authenticate the Client, and encryption to secure the network traffic over the Internet.
The tunnel provides authorization and authentication by using certificates. Both the Client and the Server need valid certificates issued by
the same CA (Certificate Authority) in order to set up a connection. In the case of setting up a tunnel, the machine receiving the
connection (the Server) is its own CA and will only accept certificates issued by itself.
Encryption
The encryption settings spans from None to High. No encryption means that the traffic is still authenticated and is therefore
recommended for tunnels within LANs and WANs. You should be careful when selecting higher encryption level since this will be more
resource intensive for the machines at both ends of the tunnel.
Important! Do not use static hubs (listed under the Name Services tab) when setting up a tunnel.

Access List
Advanced
Configuration tasks under this tab are for server (listening) side of the tunnel. The tab contains the following fields and buttons.
Active activates the tunnel server. The Certificate Authority Setup dialog appears. See Setting up a Tunnel for more information.
Common name is the IP address of the hub on the server side.
Expire date is the date the server certificate expires.
Port specifies the port that the tunnel server is listening on. This is the port that you have to open in your router or firewall for incoming
connections.
Security settings lets you select None, Low, Medium, High, or Custom, where you define your own security setting. For custom
definition: See http://www.openssl.org/docs/apps/ciphers.html
Note: High gives the highest degree of encryption, but slows the data traffic a lot. Normally None will be sufficient, where data is not
encrypted, but still authenticated.
Start and Stop starts or stops the tunnel server.
Server displays the server details and the server certificate.
CA displays the CA details and CA certificate.
New opens the Client Certificate Setup dialog. You can create certificates for the clients you will open for access. When creating the
certificate, you must set a password. This password, the certificate (encrypted text) and the servers port number must be sent to the
client site.
Delete deletes the selected client certificate.
View displays the selected client certificate.
The configuration tasks under this tab are for the client (connecting) side of the tunnel.
The fields are:
Server
The tunnel servers IP address or hostname.
Port
The tunnel servers port number.
Heartbeat
Keep-alive message interval.
Description
New button
Opens the New Tunnel Connection dialog. You can create a new Tunnel connection to the server that has generated the certificate.
Active Tunnel
Activates the defined tunnel connection.
Check Server CommonName
Uncheck this option to disable the Server IP address check on connection (see Setting up a Tunnel in a NAT Environment).
Description
Server
The IP address of the server on the server end of the tunnel.
Password
The password you have received with your certificate from the server side.
Server Port
The communication port on the server on the server side. Default is 48003. It is recommended that you do not change the default port.
Keep-alive interval
Small data packets are sent at the specified interval. This is to allow for firewall connection disruption on idle connections.
Certificate
You paste the received certificate in this field. See Creating Client Certificates for more information.
Edit button
Edits the selected server connection.
Delete button
Deletes the selected server connection.
Certificate button
Displays the selected client certificate.
Access List
This tab allows you to set access rules for tunnels. By default, all UIM requests and messages can be routed over the tunnel and dispatched on
the other side. This routing is transparent to UIM users.
must be defined on the tunnel client hub.
Edit Rule lets you add, modify or remove access rules. Four criteria are used when defining rules, and a rule is triggered based on
matching all four criteria:
Source IP is the name of the source hub, robot or probe.
Destination Address is the address of the target hub, robot or probe.
Probe Command is the specific command you want to allow or deny. The command-set varies from probe to probe. To view a
command set, open the Probe Utility.
User is the user you want to allow or deny access.
Note: Regular expression is allowed.
The rules table displays all the rules you have created. The order of the rules defined is important. The first rule in the list is processed
first. Processing stops on the first rule that matches all four criteria.
Advanced
This tab allows you to assign the first tunnel port, establish the hanging timeout, and configure the SSL session cache.
The tab contains the following options:
It is not necessary to select this option if only one tunnel is defined, as the tunnel is automatically assigned the port number specified as F
irst probe port number on the Setup > Advanced tab in the controller configuration.
First Tunnel Port
If you have configured more than one tunnel, you should specify the first port in the range of ports to be used by the tunnels.
Important! Do NOT use the same port that is specified for the controller probe's first probe port.
If this field is blank, random ports will be assigned by the operating system.
Clients are assigned ports from the configured port range and keep that port as long as the hub is running.
Servers assign ports from the configured port number and increment the number for each new client connection. If there are no
active clients, the hub resets the counter.
that are hanging.
If one or more tunnels are hanging, the hub attempts to restart the tunnel(s). If the restart fails, the hub performs a restart after the
specified number of seconds.
SSL Session Cache
Use Server Cache enables caching of SSL sessions and reuse previous session credentials. This speeds up the connection time
between the client and the server (assuming Use Client Cache is enabled on the client).
Status Tab
This tab contains four subsections that provide status information about the queues, subjects and tunnels you have defined.
Subscribers/Queues displays a list with status information on all subscribers/queues on this hub. You can view the messages received
by the hub and forwarded to interested parties. This status can be used to assist with debugging and load monitoring for your hub. The
fields in the list are:
Name of the queue
Type of subscriber
Queued shows the number of messages waiting to be transferred (unless you use message spooling, this number should be 0 in
normal operation as long as the subscriber is alive)
Sent shows the number of messages sent
Bulk Size is the maximum number of messages sent at once
Connection is the address of the subscribers network connection
Subjects shows a count of all messages that have been transferred since the last (re)start, grouped by the subject. This information can
assist you with debugging and load monitoring for your hub.
Peer Hub is the IP-address or hostname of the tunnels peer
Connection stats (ms) are the statistics for the time taken to set up the tunnel connection (a low minimum value could indicate a low
bandwidth; a high minimum value and a high average value could indicate packet loss)
Traffic in/out shows the amount of data received/sent through the tunnel
When you select a tunnel in the upper window, its connections appear in the lower window, which displays:
Last transfer time
In and Out show the amount of data received or sent
Command specifies the command executed on the target of the connection
Tunnel Statistics has statistics on SSL and on various events (such as server start time or when the last connection was received). Use
the drop-down list to select the server or client you want to view.
Hub Best Practices

V7.6
While most hubs perform their tasks sufficiently with little or no interaction from the administrator, you can modify various configuration
settings for better performance and usability.
Tunnels
Caching the SSL sessions can significantly speed up the server/client connection time.
If a non-functioning tunnel will significantly impact your operations, increase the level of alarm sent if a connection is lost or cannot be
made.
These settings are found on the Advanced > Tunnel Settings node in the Admin Console hub configuration GUI.
Queues
If the size of a get or post queue never shrinks to zero or if it always has many messages, increase the Bulk Size on the queue. This
allows the hub to transfer multiple messages in one packet.
Hub Troubleshooting
If your problem is not addressed here:
Look for a solution or ask other users for help on the CA UIM Community Forum.
Contact Support.
Send us feedback with the "rate this page" link below. We will strive to include a solution in the next release of this document.
Configuration Cannot be Retrieved

Problem: You see Error: Configuration was unable to be retrieved when you try to open the hub configuration GUI.
Solution: Deploy the PPM (probe provisioning manager) probe to the hub. The PPM probe contains all available probe configuration GUIs
accessed through Admin Console.
1. Click Archive above the navigation pane.
2. In the navigation pane, check the box next to the target robot.
3. Locate the PPM probe in your local archive and check the box next to it.
4. At the top of the probe list, click Deploy.
5. Click Infrastructure.
Queue Always Contains Messages

Problem: Queue size is never zero.
If a queue never shrinks to zero or if it always has many messages in the queue, the hub is not able to deliver the messages to the target hub fast
enough. This could be because that the number of QoS messages delivered to the hub from the robots has significantly increased or that the
latency is too high and slows down the deliveries.
Solutions:
If the queue collects messages for one subject, increase the bulk size of the queue so that messages are transferred in bulk.
If it is a wildcard or multiple-subject queue, you can create separate queues for different subjects.

Advanced users may find it helpful to view the log file. Click the icon next to the hub probe and select View Log. You also can modify the log file
settings so that it retains more data for troubleshooting.
hyperv (Microsoft Hyper-V Monitoring)
The Microsoft Hyper-V Monitoring probe allows you to monitor the health and performance of the Microsoft Hyper-V servers. The probe collects
the necessary information about the following systems:
Host Operating System (OS)
Corresponding hypervisor system (Windows 2008/2012/2012 R2 Server + Hyper-V / Windows 2008 Server Core + Hyper-V)
Virtual Machines that are configured on the Host OS
Note: Version 3.0 or later of the probe is now available only through the web-based GUI. The Infrastructure Manager (IM) GUI is only
available for version 2.2 or earlier.
The probe allows you to define alarms and their corresponding threshold values. You can compare the actual data at customizable intervals using
generated QoS messages. The probe then generates alarms when the corresponding threshold values are breached.
The probe monitors the following entities on the host:
CPU
Memory
Disk
Network
Resource Pool
The probe also monitors the following entities of each Virtual Machine (VM) on the host:
CPU
Memory
Disk
Network
The 3.10 or later versions of the probe allow you to create configuration templates. The templates are applicable to only the specific instance of
the probe on the robot. Only existing profiles can be configured using templates.
More information:
hyperv (Microsoft Hyper-V Monitoring) Release Notes
v3.0 hyperv AC Configuration

The hyperv probe is configured to monitor virtual environments created using Microsoft Hyper-V on the Windows Server environment. The probe
allows you to activate the monitoring checkpoints of the host system and the virtual systems to monitor their performance.
Note: The hyperv probe is configured on the network system only. You cannot monitor the local host with this probe.
The probe can monitor Windows Server 2008, 2008 R2, 2012 and 2012 R2 hosts. The hyperv probe configures the host system and automatically
displays the list of virtual machines and their associated monitoring checkpoints.
Important! The hyperv role must be enabled on the Windows Server environment for the probe to connect and collect required
information.
The probe has counters to monitor the NUMA topology of the Windows Server 2012 and Windows Server 2012 R2. The NUMA topology is used
to optimize the performance of high-performing applications (like SQL Server) by efficiently scheduling threads and allocating memory.
The recommended counters for NUMA are as follows:
\Hyper-V VM Vid Partition(*)\Physical Pages Allocated

\Hyper-V VM Vid Partition(*)\Remote Physical Page
The following diagram outlines the process to configure the probe to collect QoS data for Microsoft Hyper-V systems.
How to Monitor a Hyper-V Setup

Configure the Server
Configure the Client
Configure HTTP Settings
Migration Prerequisite
Alarm Thresholds
Configure a Node
Managing Profiles
Create Profile
Modify Profile
Delete Profile
How to Monitor a Hyper-V Setup

This section describes the minimum configuration settings required to configure the hyperv probe.
Follow these steps:
1. Ensure that the applicable preconfiguration requirements have been met.
Refer Preconfiguration Requirments for more information.
2. Deploy the probe on a Windows robot.
Note: The default monitoring interval is 10 minutes. It is recommended to keep it the same.
4. Create a profile with the authentication details of the hyper-v server to be monitored.
Refer Managing Profiles for more information.
Note: The profile goes into pending state to fetch the data for that particular host. On reloading the page or re-opening the GUI
after sometime, you are able to see the tree structure of the CPU, disk, network, resource pool and VMs for the particular host.
5. Activate the profile and save the configuration to establish the connection and discover resources.
The host, hypervisor, and VM resources are automatically discovered by the probe and displayed as nodes.
The following are the preconfiguration requirements of the Microsoft Hyper-V probe:
HTTP Configuration
Configure the Server

The hyperv probe requires Windows PowerShell and Windows Remote Management (WinRM) to be enabled and properly configured on the
server.
Follow these steps:
Note: If any of the following commands using single quotations fail, try to run the command with double quotes or without the quotation
marks.
1. Ensure that WinRM is enabled on the host.
Note: WinRM is enabled by default. However, if WinRM is disabled, use the following Microsoft links to enable WinRM on the
respective platforms:
Windows Server 2012 R2
Windows Server 2008 R2
If you follow the procedures in the links, skip the next step and proceed directly to step 3.
2. Open a PowerShell window on the server as an administrator and enter the following command:
Get-ExecutionPolicy
If the response says Restricted, you must change the setting to Unrestricted or RemoteSigned. For example, to set it to RemoteSigne
d:
d. Enter the following command to enable all firewall exception rules:
Configure-SMRemoting.ps1 -force -enable
3. Open a Windows Powershell window on the server as the Administrator user.
4. Enter the following command:
winrm quickconfig
5. Enter Y to accept the changes.
This configures WinRM with default settings.
6. Enter the following command to check the authentication status:
winrm get winrm/config/service
You see a section in the response similar to the following:
RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
MaxConcurrentOperations = 4294967295
MaxConcurrentOperationsPerUser = 15
EnumerationTimeoutms = 60000
MaxConnections = 25
MaxPacketRetrievalTimeSeconds = 120
AllowUnencrypted = false
Auth
Basic = false
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = false
CbtHardeningLevel = Relaxed
DefaultPorts
HTTP = 5985
HTTPS = 5986
IPv4Filter = *
IPv6Filter = *
EnableCompatibilityHttpListener = false
EnableCompatibilityHttpsListener = false
CertificateThumbprint
7. Enter the following command to enable basic authentication:
winrm set winrm/config/service/auth '@{Basic="true"}'
8. Enter the following command to allow unencrypted data:
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
9. Enter the following command to trust all hosts:
winrm set winrm/config/client '@{TrustedHosts="*"}'
To trust only specified hosts list the host names, as in the following example:
winrm set winrm/config/client '@{TrustedHosts="host1, host2, host3"}'
10. Enter the following command to provide sufficient memory, 1024 MB, for the probe to execute PowerShell commands on the server:
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="1024"}'
Note: If you see the message: "Process is terminated due to StackOverflowException," in the log file, increase the memory
value in this setting.
Configure the Client

The hyperv probe requires Windows PowerShell and Windows Remote Management (WinRM) to be enabled and properly configured on the
client.
Follow these steps:
Note: If any of the following commands using single quotations fail, try to run the command without the quotation marks.
1. Open a PowerShell window on the client and enter the following command:
Get-ExecutionPolicy
If the response says Restricted, you must change the setting to Unrestricted or RemoteSigned. For example, to set it to RemoteSigne
d:
2. Open a Command Prompt window on the client as the Administrator user.
3. Enter the following command:
winrm quickconfig
4. Enter Y to accept the changes.
This configures WinRM with default settings.
5.
5. Enter the following command to check the authentication status:

winrm get winrm/config/client
You see a section in the response similar to the following:
Auth
Basic = false
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = false
CBTHardeningLevel = Relaxed
6. Enter the following command to enable basic authentication:
winrm set winrm/config/client/auth '@{Basic="true"}'
7. Enter the following command to allow unencrypted data:
winrm set winrm/config/client '@{AllowUnencrypted="true"}'
8. Enter the following command to trust all hosts:
winrm set winrm/config/client '@{TrustedHosts="*"}'
To trust only specified hosts list the host names, as in the following example:
winrm set winrm/config/client '@{TrustedHosts="host1, host2, host3"}'
9. Enter the following command to provide sufficient memory, 1024 MB, for the probe to execute PowerShell commands on the client:
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="1024"}'
Note: If you see the message: "Process is terminated due to StackOverflowException," in the log file, increase the memory
value in this setting.
Configure HTTP Settings

You can use an HTTP connection type for WinRM.
Follow these steps:
1. To use HTTP to connect to WinRM, enter the following command:
winrm create winrm/config/listener?Address=*+Transport=HTTP
2. Enter the following command to test the WinRM connection:
winrm identify -r:http://winrm_server:5985 -auth:basic -u:user_name -p:password -encoding:utf-8
You should see a response similar to the following:...
IdentifyResponse
ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor = Microsoft Corporation
ProductVersion = OS: 6.1.7600 SP: 0.0 Stack: 2.0
You must clear the temporary files on each system that accesses the robot with the probe to be migrated if you are migration from an earlier
version of the probe to version 3.0.
1. Open the Run window.
2. Type %temp% and click OK.
The local Temp directory of the system opens.
3. Open the Util directory.
4. Delete all files in the directory.
The temporary file have now been cleared.
Alarm Thresholds
allow the probe to:
Configure a Node
Each section within a node enables you to configure the properties of the probe for monitoring the response of user-defined queries.
Follow these steps:
The specified section of the probe is configured. You can now define connections and profiles for the monitored instance.
Managing Profiles
You can configure the probe to create, modify or delete a profile to monitor the hypervisor system. You can configure the profile to send the QoS
messages and generate alarms on response time.
Create Profile
You can create a profile to monitor a Microsoft Hyper-V environment.
Follow these steps:
1. Click the Options icon next to the hyperv node in the navigation pane.
The profile is displayed as a node.
4. Navigate to the <Profile Name> node.
5. Click Verify Selection from the Actions drop-down.
A connection is established and the authentication details are verified.
6. Click Save.
The profile is saved and the nodes are auto discovered for the profile.
Modify Profile
You can modify a profile to change the authentication and connection details of a hypervisor.
Follow these steps:
1. Click the <Profile Name> node to view Resource Setup.
2. Modify the required field information.
3. Click Save.
The profile is saved with the updated details.
Delete Profile
You can delete a profile that is no longer required.
Follow these steps:
1. Click the Options icon next to the <Profile Name> node in the navigation pane.
3. Click Save.
The profile is deleted from the probe.
v3.0 hyperv AC GUI Reference
This article describes the various GUI elements of the Microsoft Hyper-V Monitoring (hyperv) probe.
Note: The hypervisor and the hyperv probe must be in the same locale, while monitoring the hypervisor remotely.
Contents
The Tree Hierarchy

Tree Icons
hyperv Node
<Profile Name> Node
<Host Name> Node
CPU Node
<CPU Name> Node
Disk Node
<Volume Name> Node
Memory Node
Network Node
<Interface Name> Node
Resource Pool
<Resource Pool CPU Name> Node
<Resource Pool Disk Name> Node
<Resource Pool Memory Name> Node
<Resource Pool Network Name> Node
Resources Node
<Resource Network Name> Node
<Resource Switch Name> Node
<Resource VM Name> Node
CPU Node
Disk Node
Memory Node
Network Node
The Tree Hierarchy

The tree contains a hierarchical representation of devices associated with each hypervisor.
Click a device in the tree to see the alarms, events, and QoS measurements you can configure for that component. After making any changes,
click Save.
Tree Icons
The icons in the tree indicate the type of object the node contains. For VMs, the color of the icon also indicates the status of the VM.
- Closed folder. Organizational node used to group similar objects. Click the node to expand it.
- Open folder. Organizational node used to group similar objects. Click the triangle next to the folder to collapse it.!
- Resource
- Server
- VM that is running
- VM that is stopped
- VM that is paused
- CPU or individual CPU processor

- Disk
- Memory
- Network interface
hyperv Node
Navigation: hyperv
View or modify the following values as required:
hyperv > Probe Information
This section displays information about the probe name, probe version, start time of the probe, and the probe vendor.
hyperv > Probe Setup
This section lets you configure the detail level of the log file.
Log Level: defines the level of detail written to the log file. The levels range from fatal errors only (0 - Fatal) to extremely detailed
information for troubleshooting (5 - Trace).
Default: 0 - Fatal
Note: Log as little as possible during normal operation to minimize disk consumption.
hyperv > Add New Profile

This section lets you add a profile to monitor the Microsoft Hyper-V Virtual Machines (VM), QoS data is generated according to the metric values
generated by the host sytem of the hypervisor and the VM's deployed.
Hostname: defines the hostname or IP address of the host system where the Microsoft Hyper-V is running and available for monitoring.
Port: Specifies the port on the hypervisor server through which the connection is established.
Default: 5985
Username: defines a username to log in on host system. The username also contains the domain name, if necessary.
Note: Prefix .\ if you are using local or non domain user account.
Password: defines a password to authenticate the given username to log in to the host system.
Server Version: specifies the version of the Windows Server hypervisor. The probe supports monitoring for version 2008, 2012, and 2012
R2.
Default: 2008
Note: Specify the correct version of the server, otherwise the values for some checkpoints is not populated correctly. For example,
Hyper-V Virtual IDE Controller.
Interval (secs): defines the time interval (in seconds) after which the probe collects data from the monitors.
Default/Recommended: 600
Note: The minimum recommended interval for the probe is 300 seconds.
Alarm Message: specifies the alarm to be generated when the profile is not responding.
Example: The profile does not respond if there is a connection failure or inventory update failure
<Profile Name> Node

This node allows you to manage resource profiles added in the hyperv node. Click Save at the top of the screen after making any changes.
Navigation: hyperv > Profile Name
The fields in this section are the same as hyperv > Add New Profile node.
Profile name > Actions > Verify Selection
Tests the connection to the resource.
Profile name > Delete Profile
Deletes the selected resource profile.
<Host Name> Node

This node lets you configure the performance counters for the hypervisor on the host. The probe generates QoS data according to the values
fetched from the Hyper-V.
Navigation: hyperv > Profile Name > Host Name
CPU
Disk
Memory
Network
Resource Pool
Resources
Each category is represented as a node under the <Host Name> node. You can set or modify the following values as required:
Host name > Monitors
This section lets you configure the performance counters to generate QoS.
Similarly, you can configure the other performance counters that are visible under the subsequent nodes.
CPU Node
This node allows you to configure the performance counters (in percentage) for all the CPUs present on the host machine.
Navigation: hyperv > Profile Name > Host Name > CPU
<CPU Name> Node
This node allows you to configure the performance counters for each CPU present on the host machine.
Navigation: hyperv > Profile Name > Host Name > CPU > CPU Name
Disk Node
This node allows you to configure the performance counters for the disk(s) present on the host machine.
Navigation: hyperv > Profile Name > Host Name > Disk
<Volume Name> Node
This node allows you to configure the performance counters for each disk volume on the host machine.
Navigation: hyperv > Profile Name > Host Name > Disk > Volume Name
Memory Node
This node allows you to configure the performance counters (in memory size) for the RAM present on the host machine.
Navigation: hyperv > Profile Name > Host Name > Memory
Network Node
This node allows you to configure the performance counters for all the network interfaces present on the host machine.
Navigation: hyperv > Profile Name > Host Name > Network
<Interface Name> Node
This node allows you to configure the performance counters for each network interface present on the host machine.
Navigation: hyperv > Profile Name > Host Name > Network > Interface Name
Resource Pool
Resource pools in hyper-V indicate the total resources available in the hypervisor for the installed VMs. The resource pool allows easy sharing
and monitoring of resources between the different VMs. This node groups all available resources on the host machine for the hypervisor.
Navigation: hyperv > Profile Name > Host Name > Resource Pool
CPU
Disk
Memory
Network
Each category is represented as a node under the Resource Pool node.
The Resource Pool and the associated CPU, Disk, Memory, and Network nodes do not have a section or field and are used to contain a
categorized list of resources in the resource pool.
<Resource Pool CPU Name> Node
This node allows you to configure the health, capacity, and availability performance counters for the shared virtual CPU in the resource pool.
Navigation: hyperv > Profile Name > Host Name > Resource Pool > CPU > Resource Pool CPU Name
<Resource Pool Disk Name> Node
This node allows you to configure the health, capacity, and availability performance counters for the shared virtual disks in the resource pool.
Navigation: hyperv > Profile Name > Host Name > Resource Pool > Disk > Resource Pool Disk Name
<Resource Pool Memory Name> Node
This node allows you to configure the health, capacity, and availability performance counters for the shared virtual RAM in the resource pool.
Navigation: hyperv > Profile Name > Host Name > Resource Pool > Memory > Resource Pool Memory Name
<Resource Pool Network Name> Node
This node allows you to configure the health, capacity, and availability performance counters for the shared virtual network interfaces in the
resource pool.
Navigation: hyperv > Profile Name > Host Name > Resource Pool > Network > Resource Pool Network Name
Resources Node
Resources in the probe are the various network interfaces and Virtual Machines (VMs) present on the host system. This node allows you to
configure the performance counters of these resources.
Navigation: hyperv > Profile Name > Host Name > Resources
Network
Switch
VMs
Each category is represented as a node under the Resources node.
The Network, Switch, and VMs nodes do not have a section or field and are used to contain a categorized list of network resources and VMs.
<Resource Network Name> Node
This node allows you to configure the speed and throughput performance counters for the shared virtual network interfaces.
Navigation: hyperv > Profile Name > Host Name > Resources > Network > Resource Network Name
<Resource Switch Name> Node
This node allows you to configure the speed and throughput performance counters for the shared virtual network switch(es).
Navigation: hyperv > Profile Name > Host Name > Resources > Network > Resource Switch Name
<Resource VM Name> Node
This node allows you to configure the performance counters for the various virtual machines present in the hypervisor.
Navigation: hyperv > Profile Name > Host Name > Resources > Network > Resource VM Name
CPU
Disk
Memory
Network
Each category is represented as a node under the <Resource VM Name> node.
CPU Node
This node allows you to configure the performance counters for the virtual CPU allocated to the virtual machine.
Navigation: hyperv > Profile Name > Host Name > Resources > Resource VM Name > CPU
Disk Node
This node allows you to configure the performance counters for the virtual disk allocated to the virtual machine.
Navigation: hyperv > Profile Name > Host Name > Resources > Resource VM Name > Disk
Memory Node
This node allows you to configure the performance counters for the virtual RAM allocated to the virtual machine.
Navigation: hyperv > Profile Name > Host Name > Resources > Resource VM Name > Memory
Network Node
This node allows you to configure the performance counters for the virtual network interface allocated to the virtual machine.
Navigation: hyperv > Profile Name > Host Name > Resources > Resource VM Name > Network
This entire structure of nodes is repeated for each profile configured in the probe.
hyperv Metrics
This article describes the metrics that can be configured for the Microsoft Hyper-V Monitoring (hyperv) probe.
Contents
QoS Metrics
QoS Metrics
The following table describes the checkpoint metrics that can be configured using the Microsoft Hyper-V Monitoring (hyperv) probe.
Note: The CPU Load Percentage QoS has been discontinued from version 3.0.
Monitor Name
Units
Description
Version
QOS_CPU_TIME_PCT
Percent
Percentage utilization of the CPU time
3.0
QOS_CPU_RESERVATION
Number
Amount of reserved CPU resource usage
3.0
QOS_CPU_LIMIT
Number
Utilization limit of the processor
3.0
QOS_CPU_SPEED
Megahertz
Clock speed of the CPU
3.0
QOS_DISK_KBPS
Kilobytes/Second
Kilobytes of transactions per second of the disk
3.0
QOS_DISK_IO_KB
Kilobytes
Number of kilobytes read or written by the disk
3.0
QOS_DISK_SECTOR_IO
Sectors/Second
Number of disk sectors read per second
3.0
QOS_DISK_SPACE_GB
Gigabytes
Total, available, or used space on the disk in gigabytes
3.0
QOS_DISK_SPACE_PCT
Percent
Available or used space on the disk in percentage
3.0
QOS_NETWORK_KBPS
Kilobytes/Second
Kilobytes of data transfers per second in the network
3.0
QOS_MEMORY_ALLOCATED
Megabytes
Memory allocated to the host or the VM
3.0
QOS_MEMORY_FREE
Megabytes
Free memory available to the host or the VM
3.0
QOS_UPTIME
Seconds
Number of seconds the host or the VM have been active
3.0
QOS_RESOURCE_POOL_CAPACITY
Allocation Units
Maximum active reservation capacity of the resource pool
3.0
QOS_RESOURCE_POOL_STATUS
Status
Health status of the resource pool
3.0
QOS_RESOURCE_POOL_RESERVED
Allocation Units
Current active reservations from the resource pool
3.0
QOS_CPU_HALTS
Halts/Second
Number of CPU halts per second
3.0
QOS_CPU_HALTS_COSTS
Number
Cost of CPU halts
3.0
QOS_IO_INSTRUCTION
Instructions/Second
Number of CPU Input/Output instructions per second
3.0
QOS_IO_INSTRUCTION_COST
Number
Cost of the CPU Input/Output instructions
3.0
QOS_PAGE_FAULT
Faults/Second
Number of CPU page faults per second
3.0
QOS_PAGE_FAULT_COST
Number
Cost of the CPU page faults
3.0
QOS_INTERRUPTS
Interrupts/Second
Number of interrupts per second
3.0
QOS_PARTITION_PAGES
Number
Number of pages in a partition
3.0
QOS_VIRTUAL_TLB
Flushes/Second
Number of virtual TLB flushes per second
3.0
QOS_GPA_SPACE
Modifications/Second
Number pf modifications to the GPA Space per second
3.0
QOS_VIRTUAL_TLB_PAGES
Number
Number of pages used by the virtual TLB
3.0
QOS_PAGE_SPACE_MB
Megabytes
Size of the page file in MBs
3.0
QOS_NUMBER_PROCESSORS
Number
Number of processor cores or hyper threads managed by the host machine
3.0
QOS_PARTITIONS
Number
Number of partitions in the monitored system
3.0
QOS_ADDRESS_SPACE
Number
Number of address spaces in the machine
3.0
QOS_CONNECTED_CLIENTS
Number
Number of clients connected to the machine
3.0
QOS_TOTAL_PAGES
Number
Total number of pages
3.0
QOS_NETWORK_PACKET_IO
Packets/Second
Number of packets sent be the network per second
3.0
QOS_VIRTUAL_MACHINE_HEALTH
Status
Current health of the Virtual Machine
3.0
QOS_NUMBER_VMS
Number
Number of Virtual Machines deployed on the hypervisor
3.0
QOS_GPA_PAGES
Number
Number of pages used by the GPA
3.0

This section contains the alert metric default settings for the Microsoft Hyper-V Monitoring (hyperv) probe.
Monitor Name
Warning
Threshold
Warning
Severity
Error
Threshold
Error
Severity
Description
ResourceCritical
None
None
None
Critical
Host is not responding.
MonitorWarning
None
None
None
Warning
The monitor on host is outside the expected limits.
MonitorCritical
None
None
None
Critical
The monitoring checkpoint has failed to retrieve data.
CPUWarning
None
None
None
Warning
The CPU monitor on host is outside the expected limits.
CPUCritical
None
None
None
Critical
The CPU monitor on host is outside the expected limits.
MemoryWarning
None
None
None
Warning
The memory usage for monitor on host is outside the expected

limits.
MemoryGenericWarning
None
None
None
Warning
The memory monitor on host is outside the expected limits.
MemoryCritical
None
None
None
Critical
The memory usage for a monitor on host is outside the expected

limits.
NetworkWarning
None
None
None
Warning
The network usage for a monitor on host is outside expected

limits.
NetworkCritical
None
None
None
Critical
The network usage for a monitor on host is outside the expected

limits.
DiskWarning
None
None
None
Warning
The disk usage for a monitor on host is outside the expected

limits.
DiskCritical
None
None
None
Critical
The disk usage for a monitor on host is outside the expected

limits.
Status
None
None
None
Major
The status is not as expected.
service_state
None
None
None
Major
The actual state of a service is not same as the expected state.
ResourcePoolWarning
None
None
None
Warning
The resource pool is not available on host.
ResourcePoolCapacityWarning
None
None
None
Warning
The capacity of the resource pool on host is outside the expected

limit.
ResourcePoolStatusWarning
None
None
None
Warning
The status of the resource pool on host is not as expected status.
ResourcePoolReservedWarning
None
None
None
Warning
The current reservation of the resource pool on host is not as

expected.
EventAlarm
None
None
None
Major
The event source, the event code, the event category and the
event description is displayed.
UptimeWarning
None
None
None
Warning
The uptime of system is not as expected.
ibm_svc (IBM SVC Monitoring)

The IBM SVC Monitoring probe enables you to monitor the IBM System Storage SAN Volume Controller (SVC) and IBM V7000 storage systems.
The ibm_svc probe retrieves the following performance data to generate alarms and QoS:
CPU Utilization: The total CPU utilization of the storage system.
Interfaces: The connection speed of the interfaces with the Fiber Cables (FC), iSCSI, and SAS hosts.
Volumes: The read and write speed and latency information of the volumes.
MDisks: The read write speed and latency information of the MDisks.
Note: The performance data is available at system and node levels.
The ibm_svc probe uses SMI-S provider and Command Line Interpreter (CLI) to retrieve status, configuration, and statistics data of the
IBM SVC storage server. The probe supports user authentication through SSH only. So, you require a password or a valid SSH key file to
access CLI.
More information:
ibm_svc (IBM SVC Monitoring) Release Notes
v1.0 ibm_svc AC Configuration

This article describes the configuration concepts and procedures to set up the ibm_svc probe. The probe configuration includes establishing a
communication link between the probe and IBM SVC storage server. The following diagram outlines the process to configure the probe to
monitor the IBM SVC and IBM V7000 storage systems.
Contents
Create and Configure a Profile

Alarm Thresholds
The ibm_svc probe requires a user account to access the web interface and command interpreter of the IBM System Storage SAN Volume
Controller (SVC). The user must have the privileges to retrieve the data from the storage server using SMI-S and CLI. Verify that required
hardware and software is available before you configure the probe. For more information, see ibm_svc (IBM SVC Monitoring) Release Notes.

You can set up the logging details of the probe. Log as little as possible during normal operation to minimize disk consumption, and increase the
Follow these steps:
1. Click the ibm_svc node.
2. Specify the level of details that are written to the log file in the Log Level field.
Default: 5-Trace

You can configure profiles in the ibm_svc probe to monitor the storage system. Each profile uses a connection to the IBM SVC storage system for
the probe to collect and store data.
Follow these steps:
1. Click the Options (icon) next to the ibm_svc node.
3. Select the Active checkbox to activate the profile after you finish creating it.
Default: Selected
4. Define the IP address or the hostname of the IBM SVC storage system in the Hostname field.
5. Specify the Interval (secs) at which the probe retrieves data from the storage system.
Default: 600
6. Specify a Username and Password to access the monitored storage system.

7. Select the Use SSL checkbox to allow the probe to use HTTPS to connect to the IBM SVC storage system.
Default: Selected
8. Specify the storage type to monitor. The available options are: SVC and V7000.
9. Specify the alarm message to be issued when the probe is unable to connect with the IBM SVC storage system.
The profile is created as a Profile Name node under the ibm_svc node.
12. Click Verify Selection from the Actions drop down.
A connection is established if the credentials are correct.
13. Click Save.
The profile is saved and the IP address of the resource is displayed under the ibm_svc node. You can select the IP Address node and
configure the monitors.
You can configure the monitors to set up alarms and QoS. The nodes in the profile tree have numeric as well as string monitors.
Numeric monitors: Used to set up alarms conditions and QoS messages for monitors that generate numeric metric data.
String monitors: Used to set up the alarm conditions for monitors that generate string metric data. String type monitors do not generate
QoS messages.
Follow these steps:
1. Navigate to the required node.
2. Select the monitor to configure the properties.
3. Set up the alarm conditions and QoS messages for monitors that generate numeric metric data.
Monitor (Numeric)
The following fields are configured before the alarm and threshold configuration:
Value Definition: select the type of values that the probe uses for alarms and QoS. The value definition can be Current Value, Av
erage Value Last n Samples, Delta Value (Current - Previous), or Delta Per Second.
Number of Samples: specify the number of values to consider for the probe metric calculations for QoS and alarms.
Monitor (String)
High Operator: select an operator to match the retrieved value with the threshold for the maximum limit. The drop-down list has
the = (equal to) and the != (not equal to) options.
Default: !=
High Threshold: specify the maximum threshold for the monitor.
High Message Name: specify the alarm message that is displayed when the threshold is breached for the maximum limit.
Default: MonitorError
Low Operator: select an operator to match the retrieved value with the threshold for the minimum limit. The drop-down list has the
disabled, = (equal to), and the != (not equal to) options.
Default: disabled (indicates that the low threshold alarm is disabled)
Low Threshold: specify the minimum threshold for the monitor.
Low Message Name: specify the alarm message that is displayed when the threshold is breached for the minimum limit.
Alarm Thresholds
allow the probe to:
v1.0 ibm_svc AC GUI Reference

This article describes the fields in the Admin Console interface of the IBM SVC Monitoring (ibm_svc) probe.
ibm_svc Node
<Host Name> Node
Clusters Node
<Cluster Name> Node
ibm_svc Node
This node lets you view the probe information and configure the log properties of the probe.
Navigation: ibm_svc
ibm_svc > Probe Information
ibm_svc > Probe Setup
This section allows you to configure the general setup properties of the probe.
Default: 5 - Trace
debugging.
ibm_svc > Options (icon) > Add New Profile

This section allows you to add a profile to the probe.
Hostname: specifies the host name or IP address of the storage system.
Port: specifies the port number on which the (Storage Management Initiative Specification) SMI-S provider is listening. The SMI-S is a
standard for managing heterogeneous storage systems in a SAN (Storage Area Network).
Interval (secs): specifies the Interval (secs) at which the probe retrieves data from the storage system.
Default: 600
Username: specifies a username to access the monitored system.

Password: specifies a password to access the monitored system.
Use SSL: allows the probe to use HTTPS for connecting to the IBM SVC storage system.
Storage Type: specifies the storage type to monitor. The available options are: SVC and V7000.
Alarm Message: specifies the alarm message to be issued when the probe is unable to connect with IBM SVC storage system.

The Resource Name node displays the resource connection properties and lets you update these properties. The properties include IP address of
the resource, port, and user authentication details.
Note: Each IBM SVC system is termed as a resource in the probe.
Navigation: ibm_svc > Resource Name

Resource Name > Resource Setup
The fields in this section are the same as the fields in the ibm_svc > Options (icon) > Add New Profile section.
Profile Name > Actions > Verify Selection
Verifies the values in the fields of the Resource Setup section to create a connection.
Resource Name > Options (icon) > Delete Profile
This section enables you to delete the selected profile.
<Host Name> Node

The Host Name node is used for configuring the following monitors of the IBM SVC Monitoring probe:
configurationExecutionTime
discoveryExecutionTime
statsExecutionTime
Monitors generate alarms and the QoS messages depending on the monitoring category. Monitors also enable the probe to fetch the following
data about the complete storage system:
Discovery Data: provides information whether the probe connects to the storage system.
Configuration Data: provides information about the storage system classification. For example, the number of clusters and other
components.
Statistical Data: provides statistical information about the storage system components. For example, total IO operations and read/write
latency on virtual disks.
Navigation: ibm_svc > Resource Name > Host Name
Host Name > configurationExecutionTime
This section enables you to configure the configurationExecutionTime monitor of the IBM SVC Monitoring probe.
Metric Type Id: identifies the unique identification number of the monitor.
Value Definition: specifies the value type to be compared with the threshold value and then generate alarms accordingly. Value type
is also used in QoS messages. Specify one of the following values:
Current Value
Average Value Last n Samples
Delta Per Second
Number of Samples: defines the number of samples for calculating the average value. This field is available for the monitors that
have the Value Definition enabled.
High Operator: specifies the operator for validating the alarm threshold value. For example, >= 90 means the monitor generates an
alarm if the measured value is more than 90.
High Threshold: defines the threshold value for comparing it with the actual value.
High Message Name: specifies the alarm message to be issued when the threshold value is breached.
Note: The Low Operator, Low Threshold, and Low Message Name fields are used for configuring low thresholds.
Typically, the low threshold generates a warning alarm and the high threshold generates an error alarm.
Similarly, you can configure the discoveryExecutionTime and statsExecutionTime monitors.
Clusters Node
The Clusters node is used for classifying the list of arrays, which are available in the IBM SVC storage system. This node does not contain any
fields or sections for configuring the monitors of the resource.
<Cluster Name> Node

The Cluster Name node represents the actual cluster name which is available in the IBM SVC storage system. This node contains only the Monit
ors section which displays a list of monitors for configuring at an array level.
Navigation: ibm_svc > Resource Name > Host Name > Clusters> Cluster Name
Select a monitor from the Monitors section and configure its properties. The monitor properties are same as configured in the Host Name node.
The Cluster Name node further contains sub nodes for representing elements of a cluster, which are as follows:
Disk Controller
Hosts
IO Groups
MDisk
MDisk Groups
Nodes
Ports
VDisk
The cluster element nodes further contain sub nodes for configuring monitors of different sections of an element. All element nodes and their
corresponding sub nodes contain only the Monitors section. The Monitors section is used for configuring monitors of that IBM SVC component.
v1.0 ibm_svc IM Configuration

This article describes the configuration concepts and procedures to set up the ibm_svc probe. The probe configuration includes establishing a
communication link between the probe and IBM SVC storage server. The probe configuration enables you to:
Use templates and auto configuration options to configure the monitors.
The following diagram outlines the process to configure the probe to monitor the IBM SVC and IBM V7000 storage systems.
Contents
Create a Resource
Configure the Monitors
Configure Monitors Manually
Use Templates
Add a Template to Auto Configurations
Manage Alarm Messages
The ibm_svc probe requires a user account to access the web interface and command interpreter of the IBM System Storage SAN Volume
Controller (SVC). The user must have the privileges to retrieve the data from the storage server using SMI-S and CLI. Verify that required
hardware and software is available before you configure the probe. For more information, see ibm_svc (IBM SVC Monitoring) Release Notes.
Create a Resource
You can create a resource to monitor the IBM SVC storage system. This resource establishes a connection between the storage system and the
probe to collect data about the storage system. This data is used to generate alarms and QoS messages. The ibm_svc probe enables you to
create more than one resource.
Follow these steps:
1. Click the Create New Resource icon on the toolbar. You can also right-click the Resources node in the navigation pane and select the
New Resource option.
The Resource dialog appears.
2. Enter the following information:
Hostname or IP Address: define the Hostname or IP address for accessing the IBM SVC storage system.
Port: define the port on which the SMI-S provider is listening. The default port is 5988 for HTTP, and 5989 for HTTPS.
Active: select the checkbox to enable the monitoring of the resource.
Username: define the user account for accessing the SMI-S provider and the command-line interface.
Password: define the password for the user account.
Alarm Message: specify the alarm message to be issued when the probe is not able to connect with the resource.
Check Interval: specify the time interval in seconds after which the probe retrieves data from the storage system. .
Default: 600
Namespace: specifies the root/ibm as the namespace for the IBM SVC storage system. This field is read-only.
Storage Type: select the storage type to monitor. The available options are: SVC and V7000.
Use SSL: select the checkbox to enable the probe to use HTTPS to connect with the storage system.
3. Click Test.
The probe discovers the IBM SVC system.
4. Click Apply on the dialog.
The new resource, which connects the probe to the IBM SVC storage system, appears under the Resources node. You can also right-click an
existing resource and select the Edit option for updating the resource properties.
Configure the Monitors

You can configure monitors for the probe in the following ways:
Configure Monitors Manually: Select and configure each monitor individually from the list of monitors.
Use Templates: Define a reusable set of monitors and apply them to more than one resource. Templates are also used with auto
configurations.
Use Auto Configurations: Apply monitor templates to all components of a resource and automatically add monitors for new devices.
Configure Monitors Manually

You can manually configure a monitor when the monitoring requirement is limited to certain elements of the entire storage system. For example,
you want to monitor the availability of individual arrays, instead of the entire storage system at a whole.
Follow these steps:
1.
1. Select a resource in the navigation pane.

The available monitors of that resource are listed in the content pane.
2. Select the corresponding checkbox to configure and activate the monitor.
3. Double-click the monitor that you want to configure.
The Monitor Properties dialog appears. See Monitor Properties section for more information.
4. Configure the monitor properties and click OK.
5. Click Apply.
The probe starts generating QoS and alarms as configured in the monitor.
The Monitor Properties dialog allows you to define the thresholds for generating alarms and configure the QoS messages.
Follow these steps:
1. Click the desired component in the left pane.
The list of its monitors is displayed in the right pane.
2. Double-click the required monitor. You can also right-click the monitor and select Edit from the menu.
The Monitor Properties dialog appears.
3. Enter the following information in this dialog:
Resources: specify the monitor name.
Key: identify the component type and component property.
Description: specify the additional information about the monitor.
Value Definition: specify the type of value for comparing it with the threshold value and generate alarms. This value type is also used
in the QoS messages.
Samples: specify the number of samples to use for The average value last option in the Value Definition field. The maximum
number of samples is 4.
Active: select the checkbox to activate the Enable Alarming and Publish Quality of Service (QoS) fields for configuring the alarms
and QoS.
Enable Alarming: select the checkbox to activate the Operator, Threshold, Unit, and Message ID fields for configuring the alarms.
You can configure both high and low thresholds. The low threshold generates a warning alarm and the high threshold generates an
error alarm.
Initially you can set the high threshold to a default value or the current value and disable the low threshold.
Publish Quality of Service (QoS): allows you to select the QoS message that the monitor displays from the QoS Name drop-down
list,.
4. Configure the monitor properties and click OK.
The configuration properties of the monitor take effect to enable the probe for generating alarms and QoS accordingly.
Use Templates
Templates are reusable sets of monitors. You can create templates and drag-and-drop them to the Auto Configurations node. The template
monitors are applied to all the relevant components of a resource. You can also apply a template on individual component of a resource. You can
also edit an existing template for updating the list of monitors and their corresponding monitoring parameters.
Follow these steps:
1. Click the Create New Template icon on the toolbar.
You can also right-click the Templates node in the navigation pane and select the New Template option from the menu.
2. Define the template name and description.
3. Click OK.
4. Add the monitors to the template in one of the following ways:
Drag-and-drop the monitors from the right pane onto the template node in the left pane.
Right-click the monitor and select Add to Template option from the menu.
5. Configure the monitor properties. For more information, see the Edit Monitor Properties section.
5.
Note: Select the Active and Enable Alarming options in the Monitor Properties dialog, which enables the monitor to collect
data.
6. Drag-and-drop the template on the Auto Configurations node and apply the template monitors to the resource.
You can also drag-and-drop the template on individual component of resource.
7. Click Apply.
The template is added in the left pane of probe.

The auto configurations feature automatically applies monitors to all components of a resource. Add monitors and templates to the Auto
Configurations node of a resource to apply them to the resource. As new devices are detected, these auto monitors are applied automatically to
the devices.
Important! Adding excessive monitors or templates to the Auto Configurations node can overburden the system.
The auto configurations feature is implemented through two sub nodes of the All Resources node in the navigation pane:
Auto Configurations Node: Lists the templates and individual monitors for the resource. The probe searches through the resources and
applies relevant monitors to its components.
Auto Monitors Node: Lists the auto monitors for applying them on new devices. The properties of these monitors are inherited from the
monitors and templates of the Auto Configurations node.
Note: A device is assumed to be new if no monitor is configured on that device.
Add a Template to Auto Configurations
You can add a template to the Auto Configurations node of a resource by applying all template monitors to all components of the resource. The
auto configuration is automatically applied to new devices for the resource.
Follow these steps:
The list of templates is displayed in the content pane.
2. Drag-and-drop the template from the content pane onto the Auto Configurations node.
Note: Drag-and-drop a template onto a component of the resource for applying the template only to that component.
3. Click the Auto Configurations node and verify that the template is listed in the content pane.
4. Click Apply.
The monitors of the template are applied to all components of the template.
You can add a single monitor to the Auto Configurations node of a resource to apply the monitor to all components of a resource.
Follow these steps:
1. Expand the All Resources node in the navigation pane and click a component.
The list of available monitors for the selected component is displayed in the content pane.
2. Drag-and-drop the required monitor on the Auto Configurations node.
3.
3. Click the Auto Configurations node.

4. Verify that the monitor is listed in the right pane.
5. Right-click the monitor and select Edit from the menu.
The Auto Configuration Properties appears.
6. Update the field information.
7. Click Apply.
8. Click OK to restart the probe when prompted for activating the configuration changes.
The selected monitor is applied to all components of the resource.
Manage Alarm Messages

The ibm_svc probe contains a pool of alarm messages that are configured in the monitors. You can add, edit, and delete the messages in this
pool as required. You can also customize the text, severity, and other properties of an alarm message.
Follow these steps:
The Message Pool dialog appears, which displays the list of all configured alarm messages.
2. Click Add or Edit from the toolbar in this dialog.
3. Set or modify the following values, as needed:
Identification Name: define a unique name for the alarm message. This name is used to select the message while configuring the
profile.
Token: specify the message token, which defines the type of alarm message.
Error Alarm Text: define the alarm message text that is issued on error alarm.
Clear Alarm Text: define the alarm message text that is issued on clear alarm.
Note: Use the Alarm Message Variables and provide real-time information in the Error Alarm Text and Clear Alarm Text
fields.
Error Severity: specify the severity of the error alarm.
Subsystem Sting/Id: specify the subsystem Id of the alarm message. The watcher uses this subsystem Id.
Note: These messages are configured under all monitoring profiles of the ibm_svc probe.
4. Click Ok on the Message Properties dialog.

5. Close the Message Pool dialog.
6. Click Apply on the probe GUI.
v1.0 ibm_svc IM GUI Reference

This article describes the fields in the IM interface of the ibm_svc probe.
To access the probe configuration GUI, double-click the probe in Infrastructure Manager. The interface appears with the following nodes in the left
navigation pane:
Contents
The Left Pane
Resources Node
Resource IP Address Node
Templates Node
The Right Pane
The Tool Buttons
General Setup
Alarm Message Variables
The Left Pane

The left side pane displays the list of resources, which are added to the probe for monitoring. Initially the Resources and Templates nodes appear
in this pane.
You can select a node to view details in the content pane. The left pane also displays the context menu for performing certain tasks on the
selected node.
Resources Node
The Resource node displays a list of IBM SVC resources, which are configured in the probe for monitoring. Each resource is used for
establishing a connection between the probe and IBM SVC system for collecting and storing data for the monitored components. The Resources
node also displays the connection status for each resource:
= Connection to the host is OK.

The Resource IP Address node for the IBM SVC storage has the following nodes:
Auto Configurations
Configures the unmonitored devices automatically. You can add one or more checkpoints (or templates) to this node using drag-and-drop
feature.
Auto Monitors
Lists the auto monitors and the location of the component in the Auto Configurations node where these are applied.
All Monitors
Lists all monitors, which are configured in the Auto Configurations and Auto Monitors node.
Clusters
Displays the cluster hierarchy of the storage system. You can drill down to view various elements such as Disk Controllers, Hosts, IO
Groups, MDisk, MDisk Groups, Nodes, Ports, and VDisk and devices with other physical elements of the IBM SVC storage system.
Templates Node
The Templates node displays a list of monitoring templates, which contain a list of monitors with their corresponding monitoring properties. You
can drag-and-drop a template monitor on a resource to apply all template monitors and start monitoring the resource.
The probe contains the default template: Default Auto Configurations.
The Right Pane

Information: A monitor where no value has yet been measured.
Black: The monitor is not activated for monitoring. This icon also means that the Enable Alarming option is not selected in the M
onitor Properties dialog for the monitor.
Green: The monitor is activated for monitoring, and the threshold value of the monitor has not exceeded.
Alarm Severity Colors: The monitor is activated for monitoring, and the threshold value of the monitor is exceeded.
If you select the Templates node in the navigation pane, the right pane lists Template definitions.
On right-clicking the content pane, a context menu appears. The menu items are New, Edit, Activate, and Rename for managing the selected
object.
fetched after the poll interval of the selected resource. See the section for details.
The Tool Buttons

The probe GUI contains a toolbar with following tool buttons:
General Setup
New Resource
Create New Template
General Setup
The General Setup button of the toolbar displays the Setup dialog for configuring the log level. Specify one of the following log options:
0= Fatal
1= Errors
2= Warnings
3= Information
4= Debug info
5= Debug information
Alarm Message Variables
For the alarm messages, the Error Alarm Text and Clear Alarm Text fields of the Message Properties dialog, lets you to use variables. These
variables are resolved with values specific to each instance of the alarm message when the message is issued. The dollar sign ($) is placed
before these variables. You can use the following variables:
$Resource: resource referred to in an alarm message.
$Source: source IP address for alarms and QoS data for the resource.
$Monitor: monitor (checkpoint) referred to in the alarm message.
$Desc: description of the monitor.
$Key: monitor key (typically the same as the name of the monitor).
$Value: current value of the monitor.
$Oper: operand to be combined with the value and the threshold in the alarm message.
$Thr: threshold value of the alarm.
$Unit: unit to be combined with the value in the alarm message (for example, Boolean).
ibm_svc Metrics
The following table describes the metrics that can be configured using the IBM SVC Monitoring (ibm_svc) probe.
QoS Metrics
QoS Monitor Name
Units
Description
Version
QOS_STORAGE_RESOURCE_CONFIGURATION_EXECUTION_TIME
Seconds
Time to Execute Configuration Command Group
v1.0
QOS_STORAGE_RESOURCE_DISCOVERY_EXECUTION_TIME
Seconds
Time to Execute Discovery Command Group
v1.0
QOS_STORAGE_RESOURCE_STATS_EXECUTION_TIME
Seconds
Time to Execute Statistics Command Group
v1.0
QOS_STORAGE_CLUSTER__PERCENT_FREE_CAPACITY
Percent
% Free Capacity
v1.0
QOS_STORAGE_CLUSTER__PERCENT_USED_CAPACITY
Percent
% used capacity
v1.0
QOS_STORAGE_CLUSTER__CONSOLE_PORT
Unit
Console Port
v1.0
QOS_STORAGE_CLUSTER__ALLOCATED_CAPACITY
Tera Bytes
Allocated Capacity
v1.0
QOS_STORAGE_CLUSTER__AVAILABLE_CAPACITY>
Tera Bytes
Available Capacity
v1.0
QOS_STORAGE_CLUSTER__TOTAL_CAPACITY
Tera Bytes
Cluster Total Capacity
v1.0
QOS_STORAGE_CLUSTER__BACKEND_STORAGE_CAPACITY
Tera Bytes
MDisk Storage Capacity
v1.0
QOS_STORAGE_CLUSTER__STATISTICS_FREQUENCY
Minute
Statistics Frequency
v1.0
QOS_STORAGE_CLUSTER__MAX_NUMBER_OF_NODES
Count
Max Number of Nodes
v1.0
QOS_STORAGE_CLUSTER__OPERATIONAL_STATUS
State
Cluster Operational Status
v1.0
QOS_STORAGE_CLUSTER__POOL_CAPACITY
Tera Bytes
Pool Capacity
v1.0
QOS_STORAGE_CLUSTER__STATISTICS_STATUS
Unit
Statistics Status
v1.0
QOS_STORAGE_CLUSTER__TOTAL_USED_CAPACITY
Tera Bytes
Total Used Capacity
v1.0
QOS_STORAGE_CLUSTER__TOTAL_OVERALLOCATION
Percent
Total Overallocation
v1.0
QOS_STORAGE_CLUSTER__TOTAL_VDISK_COPY_CAPACITY
Tera Bytes
Total VdiskCopy Capacity
v1.0
QOS_STORAGE_CLUSTER__CONNECTION_TYPE
Unit
Connection Type
v1.0
QOS_STORAGE_CLUSTER__FC_PORT_SPEED
MBps
Fibre Channel port speed
v1.0
QOS_STORAGE_CLUSTER_COMPRESSION_CPU_PC
Percent
CPU capacity utilized for compression
v1.0
QOS_STORAGE_CLUSTER_CPU_PC
Percent
Utilization of node CPUs
v1.0
QOS_STORAGE_CLUSTER_FC_MB
MBps
Fibre Channel throughput
v1.0
QOS_STORAGE_CLUSTER_FC_IO
Count/sec
Fibre Channel IOPS
v1.0
QOS_STORAGE_CLUSTER_SAS_MB
MBps
SAS throughput
v1.0
QOS_STORAGE_CLUSTER_SAS_IO
Count/sec
SAS IOPS
v1.0
QOS_STORAGE_CLUSTER_ISCSI_MB
MBps
IP-based Small Computer System Interface

(iSCSI) bandwidth.
v1.0
QOS_STORAGE_CLUSTER_ISCSI_IO
Count/sec
SCSI IOPS
v1.0
QOS_STORAGE_CLUSTER_WRITE_CACHE_PC
Count
Write cache fullness. Updated every ten

seconds.
v1.0
QOS_STORAGE_CLUSTER_TOTAL_CACHE_PC
Count
Total cache fullness. Updated every ten seconds.
v1.0
QOS_STORAGE_CLUSTER_VDISK_MB
MBps
Total VDisk throughput
v1.0
QOS_STORAGE_CLUSTER_VDISK_IO
Count/sec
Total VDisk IOPS
v1.0
QOS_STORAGE_CLUSTER_VDISK_MS
Milliseconds
Average VDisk latency
v1.0
QOS_STORAGE_CLUSTER_MDISK_MB
MBps
MDisk (SAN and RAID) throughput
v1.0
QOS_STORAGE_CLUSTER_MDISK_IO
Count/sec
MDisk (SAN and RAID) IOPS
v1.0
QOS_STORAGE_CLUSTER_MDISK_MS
Milliseconds
Average MDisk latency
v1.0
QOS_STORAGE_CLUSTER_VDISK_W_MB
MBps
VDisk write throughput
v1.0
QOS_STORAGE_CLUSTER_VDISK_W_IO
Count/sec
VDisk write IOPS
v1.0
QOS_STORAGE_CLUSTER_VDISK_W_MS
Milliseconds
Average VDisk write latency
v1.0
QOS_STORAGE_CLUSTER_MDISK_W_MB
MBps
MDisk (SAN and RAID) write throughput
v1.0
QOS_STORAGE_CLUSTER_MDISK_W_IO
Count/sec
MDisk (SAN and RAID) write IOPS
v1.0
QOS_STORAGE_CLUSTER_MDISK_W_MS
Milliseconds
Average MDisk write latency
v1.0
QOS_STORAGE_CLUSTER_VDISK_R_MB
MBps
VDisk read throughput
v1.0
QOS_STORAGE_CLUSTER_VDISK_R_IO
Count/sec
VDisk read IOPS
v1.0
QOS_STORAGE_CLUSTER_VDISK_R_MS
Milliseconds
Average VDisk read latency
v1.0
QOS_STORAGE_CLUSTER_MDISK_R_MB
MBps
MDisk (SAN and RAID) read throughput
v1.0
QOS_STORAGE_CLUSTER_MDISK_R_IO
Count/sec
MDisk (SAN and RAID) read IOPS
v1.0
QOS_STORAGE_CLUSTER_MDISK_R_MS
Milliseconds
Average MDisk read latency
v1.0
QOS_STORAGE_CLUSTER_POWER_W
Watts
Power Consumed
v1.0
QOS_STORAGE_CLUSTER_TEMP_C
Celsius
Temperature in Celsius
v1.0
QOS_STORAGE_CLUSTER_TEMP_F
Fahrenheit
Temperature in Fahrenheit
v1.0
QOS_STORAGE_NODE__FAILOVER_ACTIVE
Unit
Fail over Active
v1.0
QOS_STORAGE_NODE__IS_CONFIG_NODE
Unit
Configuration Node
v1.0
QOS_STORAGE_NODE__OPERATIONAL_STATUS
State
Node Operational Status
v1.0
QOS_STORAGE_NODE_COMPRESSION_CPU_PC
Percent
CPU capacity utilized for compression
v1.0
QOS_STORAGE_NODE_CPU_PC
Percent
Utilization of node CPUs
v1.0
QOS_STORAGE_NODE_FC_MB
MBps
Fibre Channel throughput
v1.0
QOS_STORAGE_NODE_FC_IO
Count/sec
Fibre Channel IOPS
v1.0
QOS_STORAGE_NODE_SAS_MB
MBps
SAS throughput
v1.0
QOS_STORAGE_NODE_SAS_IO
Count/sec
SAS IOPS
v1.0
QOS_STORAGE_NODE_ISCSI_MB
MBps
IP-based Small Computer System Interface

(iSCSI) throughput.
v1.0
QOS_STORAGE_NODE_ISCSI_IO
Count/sec
iSCSI IOPS
v1.0
QOS_STORAGE_NODE_WRITE_CACHE_PC
Count
Write cache fullness. Updated every ten

seconds.
v1.0
QOS_STORAGE_NODE_TOTAL_CACHE_PC
Count
Total cache fullness. Updated every ten seconds.
v1.0
QOS_STORAGE_NODE_VDISK_MB
MBps
Total VDisk throughput
v1.0
QOS_STORAGE_NODE_VDISK_IO
Count/sec
Total VDisk IOPS
v1.0
QOS_STORAGE_NODE_VDISK_MS
Milliseconds
Average VDisk latency
v1.0
QOS_STORAGE_NODE_MDISK_MB
MBps
MDisk (SAN and RAID) throughput
v1.0
QOS_STORAGE_NODE_MDISK_IO
Count/sec
MDisk (SAN and RAID) IOPS
v1.0
QOS_STORAGE_NODE_MDISK_MS
Milliseconds
Average MDisk latency
v1.0
QOS_STORAGE_NODE_VDISK_W_MB
MBps
VDisk write throughput
v1.0
QOS_STORAGE_NODE_VDISK_W_IO
Count/sec
VDisk write IOPS
v1.0
QOS_STORAGE_NODE_VDISK_W_MS
Milliseconds
Average VDisk write latency
v1.0
QOS_STORAGE_NODE_MDISK_W_MB
MBps
MDisk (SAN and RAID) write throughput
v1.0
QOS_STORAGE_NODE_MDISK_W_IO
Count/sec
MDisk (SAN and RAID) write IOPS
v1.0
QOS_STORAGE_NODE_MDISK_W_MS
Milliseconds
Average MDisk write latency
v1.0
QOS_STORAGE_NODE_VDISK_R_MB
MBps
VDisk read throughput
v1.0
QOS_STORAGE_NODE_VDISK_R_IO
Count/sec
VDisk read IOPS
v1.0
QOS_STORAGE_NODE_VDISK_R_MS
Milliseconds
Average VDisk read latency
v1.0
QOS_STORAGE_NODE_MDISK_R_MB
MBps
MDisk (SAN and RAID) read throughput
v1.0
QOS_STORAGE_NODE_MDISK_R_IO
Count/sec
MDisk (SAN and RAID) read IOPS
v1.0
QOS_STORAGE_NODE_MDISK_R_MS
Milliseconds
Average MDisk read latency
v1.0
QOS_STORAGE_MDISK_RB
Bytes
MDisk bytes Read in the sample period.
v1.0
QOS_STORAGE_MDISK__READ_I_OS_PER_SEC
Count/sec
MDisk Read IOPS
v1.0
QOS_STORAGE_MDISK_RO
Count
MDisk Read IOs in the sample period
v1.0
QOS_STORAGE_MDISK_WO
Count
MDisk Write IOs in the sample period
v1.0
QOS_STORAGE_MDISK__WRITE_I_OS_PER_SEC
Count/sec
MDisk Write IOPS
v1.0
QOS_STORAGE_MDISK__TOTAL_I_OS_PER_SEC
Count/sec
MDisk TotalIOPS
v1.0
QOS_STORAGE_MDISK_RE
Miliseconds
MDisk Average Read Latency
v1.0
QOS_STORAGE_MDISK_WE
Miliseconds
MDisk Average Write Latency
v1.0
QOS_STORAGE_MDISK__TOTAL_THROUGHPUT
KBps
MDisk Total Throughput
v1.0
QOS_STORAGE_IOGROUP__FLASH_COPY_FREE_MEMORY
Mega Bytes
IOgroup Flash Copy Free Memory
v1.0
QOS_STORAGE_IOGROUP__FLASH_COPY_TOTAL_MEMORY
Mega Bytes
IOgroup Flash Copy Total Memory
v1.0
QOS_STORAGE_IOGROUP__MIRROR_FREE_MEMORY
Mega Bytes
IOgroup Volume Mirroring Free
v1.0
QOS_STORAGE_IOGROUP__MIRROR_TOTAL_MEMORY
Mega Bytes
IOgroup Volume Mirroring Total
v1.0
QOS_STORAGE_IOGROUP__R_A_I_D_FREE_MEMORY
Mega Bytes
IOgroup RAID Free Memory
v1.0
QOS_STORAGE_IOGROUP__R_A_I_D_TOTAL_MEMORY
Mega Bytes
IOgroup RAID Total Free Memory
v1.0
QOS_STORAGE_IOGROUP__NUMBER_OF_HOSTS
Count
IOgroup Number of hosts
v1.0
QOS_STORAGE_IOGROUP__NUMBER_OF_NODES
Count
IOgroup Number of hosts
v1.0
QOS_STORAGE_IOGROUP__NUMBER_OF_VOLUMES
Count
IOgroup Number of Volumes
v1.0
QOS_STORAGE_IOGROUP__OPERATIONAL_STATUS
State
IOgroup Operational Status
v1.0
QOS_STORAGE_IOGROUP__REMOTE_COPY_FREE_MEMORY
Mega Bytes
IOgroup Global Mirror and Metro Mirror Free
v1.0
QOS_STORAGE_IOGROUP__REMOTE_COPY_TOTAL_MEMORY
Mega Bytes
IOgroup Global Mirror and Metro Mirror Total
v1.0
QOS_STORAGE_IOGROUP__COMPRESSION_SUPPORTED
Unit
IOgroup Compression supported
v1.0
QOS_STORAGE_POOL__PERCENT_FREE_CAPACITY
Percent
% Free Capacity
v1.0
QOS_STORAGE_POOL__PERCENT_USED_CAPACITY
Percent
% used Capacity
v1.0
QOS_STORAGE_POOL__NATIVE_STATUS
State
Pool Operational Status
v1.0
QOS_STORAGE_POOL__NUMBER_OF_BACKEND_VOLUMES
Count
Mdisk accessible from pool
v1.0
QOS_STORAGE_POOL__NUMBER_OF_STORAGE_VOLUMES
Count
Vdisk accessible from pool
v1.0
QOS_STORAGE_POOL__OPERATIONAL_STATUS
State
Pool Operational Status
v1.0
QOS_STORAGE_POOL__REMAINING_MANAGED_SPACE
Tera Bytes
Pool Remaining Managed Space
v1.0
QOS_STORAGE_POOL__TOTAL_MANAGED_SPACE
Tera Bytes
Pool Total Managed Space
v1.0
QOS_STORAGE_POOL__VIRTUAL_CAPACITY
Tera Bytes
Pool Virtual Capacity
v1.0
QOS_STORAGE_POOL__OVERALLOCATION
Tera Bytes
Pool Overalloaction
v1.0
QOS_STORAGE_POOL__PRIMORDIAL
Unit
Is Primordial?
v1.0
QOS_STORAGE_MDISK__AVAILABILITY
State
Availability
v1.0
QOS_STORAGE_MDISK__ACCESS
State
Media Access type
v1.0
QOS_STORAGE_MDISK__PERCENT_FREE_CAPACITY
Percent
% Free Capacity
v1.0
QOS_STORAGE_MDISK__PERCENT_USED_CAPACITY
Percent
% used Capacity
v1.0
QOS_STORAGE_MDISK__OPERATIONAL_STATUS
State
MDisk Operational Status
v1.0
QOS_STORAGE_MDISK__BLOCK_SIZE
Bytes
MDisk Block Size
v1.0
QOS_STORAGE_MDISK__NUMBER_OF_BLOCKS
Blocks
MDisk Number of Blocks
v1.0
QOS_STORAGE_MDISK__CONSUMABLE_BLOCKS
Blocks
MDisk consumable Blocks
v1.0
QOS_STORAGE_MDISK__EXTENT_STATUS
State
MDisk ExtentStatus
v1.0
QOS_STORAGE_MDISK__NO_SINGLE_POINT_OF_FAILURE
Unit
MDisk no Single point of failure?
v1.0
QOS_STORAGE_MDISK__DATA_REDUNDANCY
Unit
MDisk Data Redundancy
v1.0
QOS_STORAGE_MDISK__PACKAGE_REDUNDANCY
Unit
MDisk Package Redundancy
v1.0
QOS_STORAGE_MDISK__DELTA_RESERVATION>
Unit
MDisk Delta Reservation
v1.0
QOS_STORAGE_MDISK__PRIMORDIAL
Unit
MDisk is Primordail?
v1.0
QOS_STORAGE_MDISK__MODE
Unit
MDisk Model
v1.0
QOS_STORAGE_MDISK__MAX_PATH_COUNT
Count
MDisk Max Path count
v1.0
QOS_STORAGE_MDISK__PATH_COUNT
Count
MDisk Path Count
v1.0
QOS_STORAGE_MDISK__SEQUENTIAL_ACCESS
Unit
MDisk Sequential Accessible
v1.0
QOS_STORAGE_MDISK__QUORUM_INDEX
Unit
MDisk Quorum Index
v1.0
QOS_STORAGE_MDISK__CAPACITY
Tear Bytes
MDisk Capacity
v1.0
QOS_STORAGE_MDISK__REMAINING_MANAGED_SPACE
Unit
MDisk Remaining Managed Space
v1.0
QOS_STORAGE_FCPORT__FULL_DUPLEX
Unit
Fibre Channel is Full Duplex?
v1.0
QOS_STORAGE_FCPORT__MAX_SPEED
GBps
Fibre Channel Max Speed per sec
v1.0
QOS_STORAGE_FCPORT__OPERATIONAL_STATUS
State
Port Operational Status
v1.0
QOS_STORAGE_FCPORT__PORT_NUMBER
Unit
Fibre Channel Port number
v1.0
QOS_STORAGE_FCPORT__PORT_TYPE
Unit
Fibre Channel Port Type
v1.0
QOS_STORAGE_FCPORT__SPEED
GBps
Fibre Channel Speed per second
v1.0
QOS_STORAGE_FCPORT__SUPPORTED_MAXIMUM_TRANSMISSION_UNIT
Giga Bytes
Fibre Channel Max Transmission unit in Kilo

Bytes
v1.0
QOS_STORAGE_FCPORT__USAGE_RESTRICTION
State
Fibre Channel Restriction
v1.0
QOS_STORAGE_PORT__NUMBER_OF_PORTS
Count
Host Number of Ports
v1.0
QOS_STORAGE_PORT__NODE_LOGGED_IN_COUNT
Count
Node logged In Count on host
v1.0
QOS_STORAGE_PORT__PORT_AUTHENTICATED
Unit
Host Port Authenticated
v1.0
QOS_STORAGE_BACKENDCTR__OPERATIONAL_STATUS
State
Disk Controller Operational Status
v1.0
QOS_STORAGE_BACKENDCTR__VOLUME_LINK_COUNT
Count
Disk Controller Volume link count
v1.0
QOS_STORAGE_BACKENDCTR__VOLUME_MAX_LINK_COUNT
Count
Disk Controller Volume Max link count
v1.0
QOS_STORAGE_VDISK__AVAILABILITY
State
VDisk Availability
v1.0
QOS_STORAGE_VDISK__ACCESS
State
VDisk Media Access type
v1.0
QOS_STORAGE_VDISK__PERCENT_FREE_CAPACITY>
Percent
VDisk % Free Capacity
v1.0
QOS_STORAGE_VDISK__PERCENT_USED_CAPACITY
Percent
VDisk % used Capacity
v1.0
QOS_STORAGE_VDISK__BLOCK_SIZE
Bytes
VDisk Block Size
v1.0
QOS_STORAGE_VDISK__CONSUMABLE_BLOCKS
Blocks
VDisk Consumable Blocks
v1.0
QOS_STORAGE_VDISK__CONTROLLED
Unit
VDisk Controlled
v1.0
QOS_STORAGE_VDISK__COPY_COUNT
Count
VDisk Copy Count
v1.0
QOS_STORAGE_VDISK__DATA_REDUNDANCY
Unit
VDisk Data Redundany
v1.0
QOS_STORAGE_VDISK__NO_SINGLE_POINT_OF_FAILURE
Unit
VDisk no single point of failure
v1.0
QOS_STORAGE_VDISK__NUMBER_OF_BLOCKS
Count
VDisk Number of Blocks
v1.0
QOS_STORAGE_VDISK__OPERATIONAL_STATUS
State
Vdisk Operational Status
v1.0
QOS_STORAGE_VDISK__PRIMORDIAL
Unit
VDisk Primordial
v1.0
QOS_STORAGE_VDISK__THINLY_PROVISIONED
Unit
VDisk Thinly Provisioned
v1.0
QOS_STORAGE_VDISK__COMPRESSED
Unit
VDisk Compressed
v1.0
QOS_STORAGE_VDISK__THROTTLE_M_B_S
Unit
VDisk I/O Throttling
v1.0
QOS_STORAGE_VDISK__SYNC_RATE
Unit
VDisk Mirror Sync Rate
v1.0
QOS_STORAGE_VDISK__FLASH_COPY_MAP_COUNT
Unit
VDisk Flash Copy Map Count
v1.0
QOS_STORAGE_VDISK__CACHE_MODE
Unit
VDisk Cache Mode
v1.0
QOS_STORAGE_VDISK__CACHE_STATE
State
VDisk Cache State
v1.0
QOS_STORAGE_VDISK__CAPACITY
Giga Bytes
VDisk Capacity
v1.0
QOS_STORAGE_VDISK__REMAINING_MANAGED_SPACE
Unit
VDisk Remaining Managed Space
v1.0
QOS_STORAGE_HOST__ACCESS_GRANTED
Unit
Host Access Granted
v1.0
QOS_STORAGE_HOST__MAX_UNITS_CONTROLLED
Count
Host Max units controlled
v1.0
QOS_STORAGE_HOST__OPERATIONAL_STATUS
State
Host Operational Status
v1.0
ibm-ds (IBM Disk Storage System Monitoring)

The IBM Disk Storage System Monitoring (ibm-ds) probe monitors IBM DS3xxx, IBM DS4xxx, and IBM DS5xxx storage arrays. The probe stores
the monitoring information at customizable intervals. You can define alarms to be generated when specified thresholds are breached.
The probe uses an SMI-S interface to communicate with the IBM DS storage system arrays. Install the SMI-S provider to enable communication
between the probe and the storage system. SMI-S is a standard for managing heterogeneous storage systems in a SAN (Storage Area Network).
Storage Array
Storage Pools
Array Groups
Logical Volumes
Disks
More information:
ibm-ds (IBM Disk Storage Systems) Monitoring Release Notes
ibm-ds AC Configuration
This article describes the configuration concepts and procedures to set up the IBM Disk Storage System Monitoring (ibm-ds) probe. The
ibm-ds probe is configured to monitor components, such as arrays, controllers, hosts, logical units, and disks. Once a connection is established
between the probe and the IBM disk storage system, you can configure monitors for generating the QoS and alarms.
The following diagram outlines the process to configure the probe to monitor the IBM disk storage systems.
Verify that required hardware and software is available before you configure the probe. For more information, see ibm-ds (IBM Disk Storage
Systems Monitoring) Release Notes.

You can set up the logging details of the probe. Log as little as possible during normal operation to minimize disk consumption, and increase the
Follow these steps:
1. Click the ibm-ds node.
2. Specify the level of details that are written to the log file in the Log Level field.
Default: 3-Info

You can configure profiles in the ibm-ds probe to monitor the IBM disk storage system. Each profile uses a connection to the IBM disk
storage system for the probe to collect and store data.
Follow these steps:
1. Click the Options (icon) next to the ibm-ds node.
2.

3. Select Active to activate the profile and start monitoring the IBM disk storage system, on profile creation.
Default: Selected
4. Define the IP address or the hostname of the IBM DSxxxx system in the Hostname field.
5. Specify the Interval (secs) at which the probe retrieves data from the storage system.
Default: 600
6. Specify a Username and Password to access the monitored storage system.

7. Specify the alarm message to be generated when the probe is unable to connect with the IBM disk storage system.
8. Select the Use SSL checkbox to allow the probe to use HTTPS to connect with the IBM disk storage system.
Default: Selected
The profile is created as a Profile Name node under the ibm-ds node.
11. Click Verify Selection from the Actions drop down.
A connection is established if the credentials are correct.
12. Click Save.
The profile is saved and the IP address of the resource is displayed under the ibm-ds node.

You can configure the monitors to set up alarms and QoS. The nodes in the profile tree have numeric as well as string monitors.
Numeric monitors: Used to set up alarms conditions and QoS messages for monitors that generate numeric metric data.
String monitors: Used to set up the alarm conditions for monitors that generate string metric data. String type monitors do not generate
QoS messages.
Follow these steps:
1. Navigate to the required node.
2. Select the required monitor to configure its properties.
3. Set up the alarm conditions and QoS messages for monitors that generate numeric metric data.
Monitor (Numeric)
Value Definition: select the type of values that the probe uses for alarms and QoS. The value definition can be Current Value, Av
erage Value Last n Samples, Delta Value (Current - Previous), or Delta Per Second.
Number of Samples: specify the number of values for the probe metric calculations to generate QoS and alarms.
Monitor (String)
High Operator: select an operator to match the retrieved value with the threshold for the maximum limit. The drop-down list has
the = (equal to) and the != (not equal to) options.
Default: !=
High Threshold: specify the maximum threshold for the monitor.
High Message Name: specify the alarm message that is displayed when the threshold is breached for the maximum limit.
Default: MonitorError
Low Operator: select an operator to match the retrieved value with the threshold for the minimum limit. The drop-down list has the
disabled, = (equal to), and the != (not equal to) options.
Default: disabled (indicates that the low threshold alarm is disabled)
Low Threshold: specify the minimum threshold for the monitor.
Low Message Name: specify the alarm message that is displayed when the threshold is breached for the minimum limit.
Alarm Thresholds
allow the probe to:
ibm-ds AC GUI Reference

This article describes the fields in the Admin Console interface of the IBM Disk Storage System Monitoring (ibm-ds) probe.
Contents
ibm-ds Node
<IP Address> Node
Arrays Node
<Array Name> Node
ibm-ds Node
This node lets you view the probe information and configure the log properties of the probe.
Navigation: ibm-ds
Set or modify the following values, as required:
ibm-ds > Probe Information
ibm-ds > Probe Setup
This section lets you configure the log properties of the probe.
Default: 3 - Info
debugging.
ibm-ds > Options (icon) > Add New Profile

This section allows you to add a profile to the probe.
Hostname: specifies the host name or the IP address of the IBM DSxxxx system to be monitored.
Active: (if selected) activates the profile, on creation.
Port: specifies the port number to connect to the SMI-S provider.
Interval (secs): specifies the time interval after which the probe retrieves data from the IBM DS server. This can be set in seconds,
minutes or hours. CA recommends polling once every 10 minutes. The polling interval should not be smaller than the time required to
collect the data.
Default: 600
Username: specifies a valid domain name and username to be used by the probe to access the SMI-S provider.
Password: specifies a valid password for the given username.
Alarm Message: specifies the alarm message to be generated when the probe is unable to connect with the IBM DSxxxx system.
Use SSL: allows the probe to use HTTPS for connecting to the IBM SVC storage system.

The Resource IP Address node enables you to view and update the resource connection properties, such as, host name, port, and authentication
details.
Navigation: ibm-ds > Resource IP Address
The fields in this section are same as the fields described under ibm-ds Node -> Add New Profile.
<IP Address> Node

The IP Address node is used for configuring monitors of the IBM Disk Storage System Monitoring probe. These monitors enable the probe to
retrieve data about the complete storage system for generating alarms and QoS. These checkpoints are classified as follows:
Discovery Data: allows you to get data if the probe is able to connect with the storage system.
Configuration Data: allows you to get information about the classification of the storage system. For example, the number of arrays and
other components.
Statistical Data: allows you to get statistical information about all components of entire storage system. For example, total IO operations,
and number of arrays with low disk space.
The IP Address node enables you to configure the following checkpoints:
Configuration
Discovery
Statistics
Status
Navigation: ibm-ds > Resource IP Address > IP Address
IP Address > Configuration
This section enables you to configure the Configuration monitor of the IBM Disk Storage System Monitoring probe.
Value Definition: specifies the value type for comparing it with the threshold value and generate alarms. This value type is also used
in the QoS messages. Specify one of the following values:
Current Value
Average Value Last n Samples
Delta Per Second
Number of Samples: defines the number of samples for calculating the average value. This field is available for the monitors where
the Value Definition field is enabled. This field is enabled when the Value Definition field value is Average Value Last n Samples.
High Operator: specifies the operator for validating the alarm threshold value. For example, >= 90 means the monitor generates an
alarm if the measured value is 90 or more.
High Threshold: defines the threshold value for comparing the actual value.
High Message Name: specifies the alarm message that the probe generates when the threshold value is breached.
Note: The Low Operator, Low Threshold, and Low Message Name fields are used for configuring low thresholds. The
low threshold generates a warning alarm and the high threshold generates an error alarm.
Similarly, you can configure the Discovery, Statistics, and Status monitors.
Arrays Node
The Arrays node is used for classifying the list of arrays, which is available in the IBM disk storage system.
Note: This node does not contain fields or sections for configuring the monitors of the resource.
<Array Name> Node

The Array Name node represents the actual array name which is available in the IBM disk storage system. This node contains only the Monitors
section which displays a list of monitors for configuring at an array level. Select the monitor and configure its properties, which are the same as
configured in the IP Address node.
The Array Name node also contains the following sub nodes for representing array elements:
Components
Disks
Hosts
Service Processors
Storage Pools
Volumes
These array element nodes further contains sub nodes for configuring monitors of different sections of an element. All the element nodes and
their corresponding sub nodes contain only the Monitors section.
ibm-ds IM Configuration
This article describes the configuration concepts and procedures to set up the ibm-ds probe. The probe configuration includes establishing a
communication link between the probe and IBM DSxxxx system. The probe enables you to:
Use templates and auto configuration options to configure the monitors.
The following diagram outlines the process to configure the probe to monitor the IBM DSxxxx system.
Contents
Create a Resource
Set Up Verification
Set the Logging Level
Add Monitors
Using Templates
Verify that required hardware and software is available before you configure the probe. For more information, see ibm-ds (IBM Disk Storage
Systems Monitoring) Release Notes.
Create a Resource
The probe requires a resource to connect to the IBM DS server to collect data about the server. This data is used to generate alarms and QoS
messages. The ibm-ds probe enables you to create more than one resource.
Follow these steps:
1. Click the New Resource icon on the toolbar. You can also right-click the Resources node in the navigation pane and select the New
Resource option.
The Resource[New] dialog appears.
Hostname or IP address: specifies the host name or the IP address of the IBM DSxxxx system that you want to monitor.
Port: specifies the port to connect to the SMI-S provider.
Default: 443
Username: specifies a valid domain name and username to be used by the probe to access the SMI-S provider.
Password: specifies a valid password for the given username.
Alarm Message: specifies the alarm message to be issued when the probe is unable to connect to the resource.
Note: For more information about creating or modifying a message, see Using Message Pool Manager.
Check Interval: specifies the time interval after which the probe retrieves data from the IBM DS server. The value can be set in
seconds, minutes, or hours. CA recommends polling once every 10 minutes. The polling interval cannot be smaller than the time
required to collect the data.
Namespace: specifies root/LsiArray13 as the namespace for IBM DSxxxx arrays.

Use SSL: allows you to enable the probe to use HTTPS to connect with the IBM DS system.
3. Click Test to verify the connection to the resource.
A success or failure message appears. Enter the information again, if required.
IMPORTANT! Even after correctly entering values for all the fields in the Resource dialog, if you are unable to connect to the
IBM DS system, you can use a tool to view and manipulate the CIM objects on the SMI-S server. You can use tools such as
CimNavigator (not affiliated with or endorsed by CA Unified Infrastructure Management). The tool can help you identify
configuration issues.
4. Click OK to add the resource.

The initial data collection or the polling cycle starts. The resource hierarchy populates once the polling cycle has completed.
Set Up Verification
This section describes how to verify your configuration and communication with the IBM storage device. To verify your setup, perform the
following steps:
1. Verify the probe configuration.
2. Verify network communication.
Verify the Probe Configuration

If you enter an incorrect value when defining a resource, the system generates an error message when you click Test in the Resource dialog.
Verify that you have correctly defined all the fields that are described in the Create a Resource section.
Note: If you cannot collect performance data, ensure that the firmware version of the IBM system is 7.0 or later. Upgrade the firmware,
if required.
Verify Network Communication

Ensure there is network communication between the probe and the SMI-S provider.
Use the following ports:
Port 5988 for HTTP communications
Port 5989 for HTTPS.
Check to see if a firewall is blocking the necessary port, or if some other network problem is preventing communications:
1. Log in to the server where the SMI-S provider is installed and ping the probe server. Verify that the ping is successful.
2. Log in to the server where the probe is installed and run the following tests:
a. Ping the SMI-S server. Verify that the ping is successful
b. Telnet into the SMI-S server and verify a successful response. For example: telnet 69.80.220.10 5988
If any of the tests fail, you need to resolve a network communication problem. Once that is done, open the Resource dialog and click Test. The
IBM storage device is listed.
Set the Logging Level

You can set the level of details that are written to the log file for the probe.
Follow these steps:
1. Click the General Setup button on the toolbar.
2. Set the desired logging level on the sliding scale. Log as little as possible during normal operation to minimize disk consumption.
3. Click Apply.
The log level is set.
Add Monitors
You can manually select monitors to be measured.
Follow these steps:
1.
1. Expand the Resources node in the navigation pane.

2. Navigate through the hierarchy to the desired resource in the Navigation pane, and click on it.
The available monitors for that resource are listed in the content pane.
3. Click the checkboxes next to the monitors you want to enable.
Note: You can also select the All Monitors node to list all active monitors in the content pane. Then, you can select monitors,
as required.
Enable Monitors for QoS and Alarming
When the monitors for a resource are visible in the content pane, the Value column shows the current values for the monitors. To enable the
probe to send QoS data or alarms for threshold breaches, you can use the information in the Value column to modify the properties for each
monitor.
To edit the properties of a monitor, double-click the monitor, or right-click it and select Edit. The Monitor Properties dialog appears.
Set or modify the following values, as required:
Value Definition: allows you to select the value that is used to generate alarms and QoS.
Samples: allows you to select the number of samples to use for The average value last option in the Value Definition field. The
maximum number of samples is 4.
Active: allows you to select the checkbox to activate or deactivate the monitor without changing any of its settings.
Enable Alarming: allows you to select this option to enable the alarm capability of the monitor.
Note: Enabling this option in the Monitor Properties dialog also enables the monitor in the content pane. You can enable or
disable monitoring of the checkpoint from the content pane or with this field.
Alarms: specifies the alarm properties of the monitor by defining high and low threshold. By default, the high threshold is set to a default
value, or the current value. Set this value to match your organizational requirements. The low threshold is initially disabled. You can
select and configure an operator other than "disabled" from the list to match your organizational requirements.
Operator: allows you to select the operator to use when setting the alarm threshold for the measured value. For example, >= 90 means
the monitor is in alarm condition if the measured value is above 90. = 90 means the monitor is in alarm condition when the measured
value is exactly 90.
Threshold: define the alarm threshold value. An alarm message is sent when this threshold is exceeded.
Unit: indicates a unit for the monitored value.
Example: %, Mbytes, or KB. The field is read-only.
Message ID: allows you to select the alarm message to be issued when the specified threshold value is breached. These messages
reside in the message pool. You can manage the messages in the Message Pool Manager.
Using Message Pool Manager
You can add, remove, or modify alarm messages. These messages are sent when a QoS threshold is breached.
Add or Edit an Alarm Message
Follow these steps:
2. Click Add to add an alarm message or click Edit to modify an existing message.
Identification Name: specifies a name for the message.
Token: specifies the type of alarm, either "monitor_error" or "resource_error".
3.
Error Alarm Text: specifies the alarm text that is sent when a violation occurs. You can also use variables in this field.
Example: $monitor
This variable puts the actual monitor name in the alarm text. Examples of available variables are $resource, $host, $port, $descr,
Clear Alarm Text (OK): specifies the text that is sent when an alarm is cleared.
Error Severity: specifies the severity of the alarm.
Subsystem string/id: specifies the alarm subsystem ID that defines the alarm source.
The message is added or modified.

Auto configurations enable you to add monitors to newly added storage components automatically. When new IBM DSxxxx system components
are detected, auto monitors are created for these devices.
Example: The auto configuration feature creates auto monitors for new components when a new IBM DSxxxx component is detected. The probe
automatically starts monitoring the component.
The auto configurations feature consists of two sub-nodes that are located under the Resources node in the navigation pane:
Auto Configurations
You can drag-and-drop one or more templates or individual checkpoints to this node. Click the Apply button and restart the probe to
activate the changes.
The probe then searches through the resources. Auto monitors representing the monitors or templates in the Auto Configuration node
are created for devices that are not monitored at the time they are discovered. The new auto monitors are listed under the Auto Monitors
node.
IMPORTANT! Adding too many monitors or templates to the Auto Configurations node can overburden the system.
Auto Monitors
This node lists the auto monitors created for previously unmonitored devices. The values are based on the content added to the Auto
Configurations node. Auto monitors are only created for devices that are not being monitored when the device is discovered.

You can add a template to the Auto Configurations node as follows:
A list of all available templates is displayed in the content pane.
2. To add a template, drag the checkpoints of the template from the list and drop them on the Auto Configurations node in the navigation
pane.
3. Click the Auto Configurations node and verify that the template was successfully added.
Note: Click Apply and restart the probe to activate configuration changes.

You can add one or more monitors to the Auto Configurations node.
Follow these steps:
1. Expand the Resources node in the navigation pane and navigate to a specific storage component.
A list of all available monitors for that resource appears in the content pane.
2. Add the monitor to the Auto Configurations node by dragging and dropping the monitor on the Auto Configurations node.

To view the monitors or templates added to the Auto Configurations node, click the Auto Configurations node in the navigation pane to the
left:
To edit the properties for the templates or monitors, right-click in the list and select Edit from the menu. See the section Edit Monitor
Properties for detailed information.
To delete a template or monitor from the list, right-click in the list and select Delete from the menu.
Using Templates
Templates let you define reusable sets of monitors to apply to the available auto configurations. Applying monitoring with templates provides
consistent monitoring across multiple devices.
You can create your own templates and can define a set of monitors belonging to them. You can then apply these templates to the Auto
Configurations node in the navigation pane by dragging and dropping the checkpoints of the template.
If you drag-and-drop a checkpoint of a template to the Auto Configurations node, the monitors are applied to all relevant components of the IBM
DSxxxx system and new DSxxxx components added.
Create a Template
You can create a template:
Click the New Template button on the toolbar.
Right-click the Templates node in the navigation pane, and select New Template.
In the Template Properties dialog that appears, enter a name and description for the new template and click OK.
To edit an existing template, right-click the template under the Templates node in the navigation pane, and select Edit.

To add a monitor to a template, drag-and-drop it from the content pane to the navigation pane. You can edit the properties for monitors in the
template as described in Edit Monitor Properties section.
Apply a Template
Follow these steps:
2. Select the desired template from the list in the content pane.
3. Drag-and-drop it on the Auto Configurations node in the navigation pane.
4. Click the Auto Configurations node to verify that the content was successfully added to the template.
ibm-ds IM GUI Reference

This article describes the fields in the IM interface of the ibm-ds probe.
Contents

The Toolbar Buttons
The Navigation (Left) Pane

Resources Node
Templates Node
The Content (Right) Pane

The probe GUI consists of a toolbar and a window with two panes:
The Navigation pane
The Content pane
In addition, a status bar at the bottom of the window shows version information, and when the probe was last started.
The Toolbar Buttons

The Navigation (Left) Pane

The Navigation pane displays the list of resources and templates, that are added to the probe for monitoring.
You can select a node to view details in the content pane. The left pane also displays a context menu for performing certain tasks on the selected
node.
Resources Node
The Resources node displays a list of IBM DS resources, which are configured in the probe for monitoring. Each resource is an SMI-S provider
that can discover DSxxxx systems and provide a connection to them, allowing the probe to collect and store data for the monitored components.
The Resources node also displays the connection status for each resource as follows:
= Connection to the host is OK.

The Resource IP Address node for the IBM SVC storage has the following nodes:
Auto Configurations
Configures the unmonitored devices automatically. You can add one or more checkpoints (or templates) to this node using drag-and-drop
feature.
Auto Monitors
Lists the auto monitors and the location of the component in the Auto Configurations node where these are applied.
All Monitors
Lists all monitors, which are configured in the Auto Configurations and Auto Monitors node.
Arrays
Displays the equipment hierarchy of an IBM DSxxxx system. You can click in the hierarchy to view various elements such as Disks,
Hosts, Service Processors, Storage Pools, and, Volumes with other physical elements of the IBM DS storage system.
Templates Node
The Templates node displays a list of monitoring templates that contains a list of monitors with their corresponding monitoring properties. You
can drag-and-drop a template monitor on a resource to apply all template monitors and start monitoring the resource.
The probe contains the following default templates:
Status Monitors
Controller Monitors
Disk Monitors
Port Monitors
Array Monitors
Pool Monitors
Array Monitors
Default Auto Configurations
Logical Volume Monitors
The Content (Right) Pane

Information: A monitor where no value has yet been measured.
Black: The monitor is not activated for monitoring. This icon also means that the Enable Alarming option is not selected in the M
onitor Properties dialog for the monitor. See the section Edit Monitor Properties.
Green: The monitor is activated for monitoring, and the threshold value of the monitor has not exceeded.
Alarm Severity Colors: The monitor is activated for monitoring, and the threshold value of the monitor is exceeded. The color
reflects the Message ID selected in the Monitor Properties dialog for the monitor.
If you select the Templates node in the navigation pane, the right pane lists the template definitions.
On right-clicking the content pane, a context menu appears. The menu items are New, Edit, Activate, and Rename for managing the selected
object.
retrieved after the poll interval of the selected resource.
ibm-ds Metrics
This section describes the metrics for the IBM Disk Storage System Monitoring (ibm-ds) probe.
Contents
QoS Metrics
QoS Operational Status Values
QoS Metrics
This section contains the QoS metrics for the probe.
QoS Monitor
Unit
Description
Version
QOS_STORAGE_ARRAY_KBYTES_READ
KB
The kilobytes of array data read in the sample period
1.0
QOS_STORAGE_ARRAY_KBYTES_READ_RATE
KB/Sec
The kilobytes of array data read in a second
1.0
QOS_STORAGE_ARRAY_KBYTES_TRANSFERRED
KB
The kilobytes of array data transferred in the sample period
1.0
QOS_STORAGE_ARRAY_KBYTES_TRANSFERRED_RATE
KB/Sec
The kilobytes of array data transferred in a second
1.0
QOS_STORAGE_ARRAY_KBYTES_WRITTEN
KB
The kilobytes of array data written in the sample period
1.0
QOS_STORAGE_ARRAY_KBYTES_WRITTEN_RATE
KB/Sec
The kilobytes of array data written in a second
1.0
QOS_STORAGE_ARRAY_MAX_HOT_SPARES
Count
The maximum number of Hot Spares
1.0
QOS_STORAGE_ARRAY_MAX_SNAPSHOTS
Count
The maximum number of Snapshots
1.0
QOS_STORAGE_ARRAY_MAX_STORAGE_VOLUMES
Count
The maximum number of Storage Volumes
1.0
QOS_STORAGE_ARRAY_MAX_VOL_COPYS
Count
The maximum number of Volume Copies
1.0
The operational status of the array. For more information, see QoS
Operational Status Values.
1.0
QOS_STORAGE_ARRAY_OPERATIONAL_STATUS
QOS_STORAGE_ARRAY_READ_HIT_IOS
Count
The number of array read hit IOs in the sample period
1.0
QOS_STORAGE_ARRAY_READ_HIT_RATIO
Percent
Array Read Hit Ratio in the sample period
1.0
QOS_STORAGE_ARRAY_READ_IOS
Count
Array Read IOs in the sample period
1.0
QOS_STORAGE_ARRAY_READ_IOS_RATE
Count/Sec
Array Read IOs Rate in the sample period
1.0
QOS_STORAGE_ARRAY_REMAINING_MANAGED_SPACE
Gigabytes
Remaining Managed Space
1.0
QOS_STORAGE_ARRAY_TOTAL_IOS
Count
Array Total IOs in the sample period
1.0
QOS_STORAGE_ARRAY_TOTAL_IOS_RATE
Count/Sec
Array Total IOs Rate in the sample period
1.0
QOS_STORAGE_ARRAY_TOTAL_MANAGED_SPACE
Gigabytes
Total Managed Space
1.0
QOS_STORAGE_ARRAY_WRITE_HIT_IOS
Count
Array Write Hit IOs in the sample period
1.0
QOS_STORAGE_ARRAY_WRITE_HIT_RATIO
Percent
Array Write Hit Ratio in the sample period
1.0
QOS_STORAGE_ARRAY_WRITE_IOS
Count
Array Write IOs in the sample period
1.0
QOS_STORAGE_ARRAY_WRITE_IOS_RATE
Count/Sec
Array Write IOs Rate in the sample period
1.0
QOS_STORAGE_ARRAY_USED_MANAGED_SPACE
Gigabytes
Displays used managed space of array.
1.0
QOS_STORAGE_ARRAY__PERCENT_USED_CAPACITY
Displays percent used capacity of array.
1.0
QOS_STORAGE_COMPONENT_OPERATIONAL_STATUS
The operational status of the component. For more information, see Q

oS Operational Status Values.
1.0
QOS_STORAGE_COMPONENT_TOTAL_OUTPUT_POWER
Total Output Power
1.0
QOS_STORAGE_DISK_AVAILABILITY
Disk Availability
1.0
QOS_STORAGE_DISK_BLOCK_SIZE
Disk Block Size
1.0
QOS_STORAGE_DISK_CAPABILITIES
Disk Capabilities
1.0
Disk Total Capacity in Gigabytes
1.0
Disk Consumable Capacity in Blocks
1.0
Percent
Gigabytes
QOS_STORAGE_DISK_CONSUMABLE_BLOCKS
QOS_STORAGE_DISK_CONSUMABLE_CAPACITY
Gigabytes
Disk Consumable Capacity in Capacity
1.0
QOS_STORAGE_DISK_KBYTES_READ
KB
Disk Kbytes Read in the sample period
1.0
QOS_STORAGE_DISK_KBYTES_READ_RATE
KB/Sec
Disk Kbytes Read Rate in the sample period
1.0
QOS_STORAGE_DISK_KBYTES_TRANSFERRED
KB
Disk Kbytes Transferred in the sample period
1.0
QOS_STORAGE_DISK_KBYTES_TRANSFERRED_RATE
KB/Sec
Disk Kbytes Transferred Rate in the sample period
1.0
QOS_STORAGE_DISK_KBYTES_WRITTEN
KB
Disk Kbytes Written in the sample period
1.0
QOS_STORAGE_DISK_KBYTES_WRITTEN_RATE
KB/Sec
Disk Kbytes Written Rate in the sample period
1.0
QOS_STORAGE_DISK_NOMINAL_ROTATION_RATE
RPM
Disk Speed (RPM)
1.0
QOS_STORAGE_DISK_NUMBER_OF_BLOCKS
Disk Total Capacity in Blocks
1.0
QOS_STORAGE_DISK_OPERATIONAL_STATUS
The operational status of the disk. For more information, see QoS
1.0
QOS_STORAGE_DISK_READ_IOS
Count
Disk Read IOs in the sample period
1.0
QOS_STORAGE_DISK_READ_IOS_RATE
Count/Sec
Disk Read IOs Rate in the sample period
1.0
QOS_STORAGE_DISK_READ_TIME_MAX
ms
Disk Maximum Read Time
1.0
QOS_STORAGE_DISK_RECOVERED_ERRORS
Count
Disk Number of Recovered Errors
1.0
QOS_STORAGE_DISK_RETRIED_IOS
Count
Disk Retried IOs
1.0
Disk Spare Status
1.0
QOS_STORAGE_DISK_SPARE_STATUS
QOS_STORAGE_DISK_TIMEOUTS
Count
Disk Number of Timeouts
1.0
QOS_STORAGE_DISK_TOTAL_IOS
Count
Disk Total IOs in the sample period
1.0
QOS_STORAGE_DISK_TOTAL_IOS_RATE
Count/Sec
Disk Total IOs Rate in the sample period
QOS_STORAGE_DISK_UNRECOVERED_ERRORS
Count
Disk Number of Unrecovered Errors
1.0
QOS_STORAGE_DISK_WRITE_IOS
Count
Disk Write IOs in the sample period
1.0
QOS_STORAGE_DISK_WRITE_IOS_RATE
Count/Sec
Disk Write IOs Rate in the sample period
1.0
QOS_STORAGE_DISK_WRITE_TIME_MAX
ms
Disk Maximum Write Time
1.0
QOS_STORAGE_POOL_CAPACITY_USED_PERCENT
Percent
Array Percent Free Capacity
1.0
The operational status of the storage pool. For more information, see
QoS Operational Status Values.
1.0
QOS_STORAGE_POOL_OPERATIONAL_STATUS
QOS_STORAGE_POOL_REMAINING_MANAGED_SPACE
Gigabytes
Storage Pool Free Capacity
1.0
QOS_STORAGE_POOL_TOTAL_MANAGED_SPACE
Gigabytes
Storage Pool Total Capacity
1.0
QOS_STORAGE_PORT_KBYTES_READ
KB
Port Kbytes Read in the sample period
1.0
QOS_STORAGE_PORT_KBYTES_READ_RATE
KB/Sec
Port Kbytes Read Rate in the sample period
1.0
QOS_STORAGE_PORT_KBYTES_TRANSFERRED
KB
Port Kbytes Transferred in the sample period
1.0
QOS_STORAGE_PORT_KBYTES_TRANSFERRED_RATE
KB/Sec
Port Kbytes Transferred Rate in the sample period
1.0
QOS_STORAGE_PORT_KBYTES_WRITTEN
KB
Port Kbytes Written in the sample period
1.0
QOS_STORAGE_PORT_KBYTES_WRITTEN_RATE
KB/Sec
Port Kbytes Written Rate in the sample period
1.0
QOS_STORAGE_PORT_MAINT_OP
Count
Port Number of Maintenance Operations in sample period.
1.0
QOS_STORAGE_PORT_MAX_SPEED
The maximum speed of the port
1.0
QOS_STORAGE_PORT_OPERATIONAL_STATUS
The operational status of the port. For more information, see QoS
1.0
QOS_STORAGE_PORT_PORT_NUMBER
The port number
1.0
QOS_STORAGE_PORT_PORT_TYPE
The type of the port
1.0
QOS_STORAGE_PORT_READ_IOS
Count
Port Read IOs in the sample period
1.0
QOS_STORAGE_PORT_READ_IOS_RATE
Count/Sec
Port Read IOs Rate in the sample period
1.0
The speed of the port
1.0
QOS_STORAGE_PORT_SPEED
QOS_STORAGE_PORT_TOTAL_IOS
Count
The total number of IO operations from the port in the sample period
1.0
QOS_STORAGE_PORT_TOTAL_IOS_RATE
Count/Sec
The total number of IO operations from the port in a second
1.0
QOS_STORAGE_PORT_WRITE_IOS
Count
Port Write IOs in the sample period
1.0
QOS_STORAGE_PORT_WRITE_IOS_RATE
Count/Sec
Port Write IOs Rate in the sample period
1.0
QOS_STORAGE_SP_CACHE_MEMORY_SIZE
MB
The size of the controller cache in megabytes
1.0
QOS_STORAGE_SP_KBYTES_READ
KB
Controller Kbytes Read in the sample period
1.0
QOS_STORAGE_SP_KBYTES_READ_RATE
KB/Sec
Controller Kbytes Read Rate in the sample period
1.0
QOS_STORAGE_SP_KBYTES_TRANSFERRED
KB
Controller Kbytes Transferred in the sample period
1.0
QOS_STORAGE_SP_KBYTES_TRANSFERRED_RATE
KB/Sec
Controller Kbytes Transferred Rate in the sample period
1.0
QOS_STORAGE_SP_KBYTES_WRITTEN
KB
Controller Kbytes Written in the sample period
1.0
QOS_STORAGE_SP_KBYTES_WRITTEN_RATE
KB/Sec
Controller Kbytes Written Rate in the sample period
1.0
The operational status of the controller. For more information, see Qo

S Operational Status Values.
1.0
QOS_STORAGE_SP_OPERATIONAL_STATUS
QOS_STORAGE_SP_PROCESSOR_MEMORY_SIZE
MB
The size of the controller memory in megabytes
1.0
QOS_STORAGE_SP_READ_HIT_IOS
Count
Controller Read Hit IOs in the sample period
1.0
QOS_STORAGE_SP_READ_HIT_RATIO
Percent
Controller Read Hit Ratio in the sample period
1.0
QOS_STORAGE_SP_READ_IOS
Count
Controller Read IOs in the sample period
1.0
QOS_STORAGE_SP_READ_IOS_RATE
Count/Sec
Controller Read IOs Rate in the sample period
1.0
The reset status of the controller
1.0
QOS_STORAGE_SP_RESET_CAPABILITY
QOS_STORAGE_SP_TOTAL_IOS
Count
Controller Total IOs in the sample period
1.0
QOS_STORAGE_SP_TOTAL_IOS_RATE
Count/Sec
Controller Total IOs Rate in the sample period
1.0
QOS_STORAGE_SP_WRITE_HIT_IOS
Count
Controller Write Hit IOs in the sample period
1.0
QOS_STORAGE_SP_WRITE_HIT_RATIO
Percent
Controller Write Hit Ratio in the sample period
1.0
QOS_STORAGE_SP_WRITE_IOS
Count
Controller Write IOs in the sample period
1.0
QOS_STORAGE_SP_WRITE_IOS_RATE
Count/Sec
Controller Write IOs Rate in the sample period
1.0
The size of the LUN block
1.0
QOS_STORAGE_VOL_BLOCK_SIZE
QOS_STORAGE_VOL_CAPACITY
Gigabytes
LUN Total Capacity in Gigabytes
1.0
QOS_STORAGE_VOL_CONSUMABLE_BLOCKS
Blocks
LUN Consumable Blocks
1.0
QOS_STORAGE_VOL_CONSUMABLE_CAPACITY
Gigabytes
LUN Consumabe Capacity in Gigabytes
1.0
QOS_STORAGE_VOL_KBYTES_READ
KB
LUN Kbytes Read in the sample period
1.0
QOS_STORAGE_VOL_KBYTES_READ_RATE
KB/Sec
LUN Kbytes Read Rate in the sample period
1.0
QOS_STORAGE_VOL_KBYTES_TRANSFERRED
KB
LUN Kbytes Transferred in the sample period
1.0
QOS_STORAGE_VOL_KBYTES_TRANSFERRED_RATE
KB/Sec
LUN Kbytes Transferred Rate in the sample period
1.0
QOS_STORAGE_VOL_KBYTES_WRITTEN
KB
LUN Kbytes Written in the sample period
1.0
QOS_STORAGE_VOL_KBYTES_WRITTEN_RATE
KB/Sec
LUN Kbytes Written Rate in the sample period
1.0
QOS_STORAGE_VOL_NUMBER_OF_BLOCKS
Count
The total number of blocks in the LUN
1.0
The operational status of the LUN. For more information, see QoS
1.0
QOS_STORAGE_VOL_OPERATIONAL_STATUS
QOS_STORAGE_VOL_READ_HIT_IOS
Count
LUN Read Hit IOs in the sample period
1.0
QOS_STORAGE_VOL_READ_HIT_RATIO
Percent
LUN Read Hit Ratio in the sample period
1.0
QOS_STORAGE_VOL_READ_IOS
Count
LUN Read IOs in the sample period
1.0
QOS_STORAGE_VOL_READ_IOS_RATE
Count/Sec
LUN Read IOs Rate in the sample period
1.0
QOS_STORAGE_VOL_READ_TIME_MAX
ms
LUN Maximum Read Time
1.0
QOS_STORAGE_VOL_TOTAL_IOS
Count
LUN Total IOs in the sample period
1.0
QOS_STORAGE_VOL_TOTAL_IOS_RATE
Count/Sec
LUN Total IOs Rate in the sample period
1.0
QOS_STORAGE_VOL_WRITE_HIT_IOS
Count
LUN Write Hit IOs in the sample period
1.0
QOS_STORAGE_VOL_WRITE_HIT_RATIO
Percent
LUN Write Hit Ratio in the sample period
1.0
QOS_STORAGE_VOL_WRITE_IOS
Count
LUN Write IOs in the sample period
1.0
QOS_STORAGE_VOL_WRITE_IOS_RATE
Count/Sec
LUN Write IOs Rate in the sample period
1.0
QOS_STORAGE_VOL_WRITE_TIME_MAX
ms
LUN Maximum Write Time
1.0
QoS Operational Status Values

You can set up the threshold for operational status using a numeric value between 0 and 17. Each value is assigned to an operational status
value of any component as follows:
Unknown(0)
Other(1)
OK(2)
Degraded(3)
Stressed(4)
Predictive Failure(5)
Error(6)
Non-Recoverable Error(7)
Starting(8)
Stopping(9)
Stopped(10)
In Service(11)
No Contact(12)
Lost Communication(13)
Aborted(14)
Dormant(15)
Supporting Entity in Error(16)
Completed(17)
ibmvm (IBM Virtualization Monitoring)

The IBM Virtualization Monitoring (ibmvm) probe monitors the health and performance of the IBM virtualization enabled systems. The probe is
capable of monitoring the managed systems connected to Hardware Management Console (HMC) interfaces.
More information:
ibmvm (IBM Virtualization Monitoring) Release Notes
v2.3 ibmvm AC Configuration

This section contains configuration details that are specific to the ibmvm probe.
Contents
Add Resource Profiles
Add Monitoring
Alarm Thresholds
At a high level, configuring the probe consists of the following steps:
1. Add a Resource profile for each IBM virtualization enabled system that you want to monitor.
2. Add monitors to the appropriate system components and configure monitor data.

A resource profile contains the settings needed for the IBM Virtualization Monitoring probe to connect to an IBM virtualization enabled system.
Create a profile for each Hardware Management Console or Integrated Virtualization Manager server you want to monitor. Once you create a
Resource profile, the Resource is added to the tree, and the tree hierarchy is automatically populated with the server components.
Follow these steps:
1. Click the Options icon next to the ibmvm node in the tree.
3. Update the field information:
Fields to know:
Hostname
3.
Active
Port
Interval (secs)
Username
Password
Alarm Message
4. Click Submit.
The profile is created and appears in the tree.
Add Monitoring
Once you add a resource profile, the components of the resource are displayed in the tree. Click a node in the tree to see any associated
monitors for that component. Configure the QoS measurements that you want to collect data for, and any alarms or events you want, by modifying
the appropriate fields.
Note: Users of CA Unified Infrastructure Management Snap can skip this step. The Default configuration is automatically applied when you
activate the probe in Snap.
Follow these steps:
1. Go to ibmvm > profile name > resource name.
2. Click a managed system, device, virtual I/O server (VIO), or virtual machines (VMs) name. It might be necessary to expand the node in
the tree to view the monitors and QoS metrics.
The available monitors appear in a table on the right side of the screen.
3. Select the monitor that you want to modify in the table.
4. Change monitor settings in the fields below the table.
6. Click OK.
The tree is updated with the new configuration.
Alarm Thresholds
allow the probe to:
v2.3 ibmvm AC Apply Monitoring with Templates
This article describes how to apply monitoring for the IBM VM Monitoring (ibmvm) probe with templates.
Note: This article describes how to apply monitoring with templates for a single probe. For more information about how to use policies
to configure templates for multiple probes, see Configure Probes with Policies in the CA Unified Infrastructure Management wiki.
Contents
Overview
Using Templates
Create a Template
Activate a Template
Overview
Applying monitoring with templates saves time compared to manual monitor configuration and provides consistent monitoring across multiple
devices. At a high level, applying monitoring with templates is a process in which you:
1. Enable bulk configuration
Before using the template editor, you first enable bulk configuration. This feature is disabled by default. It is also disabled if the probe has
been previously configured. Bulk configuration is possible only on a newly deployed probe (v2.3 or later) with no configuration.
2. Use the template editor
Once bulk configuration is enabled, you can copy and modify a default template or create a new template to define unique monitoring
configurations for an individual device or groups of devices in your environment.
Important! Bulk configuration is only possible on a newly deployed v2.3 (or later) probe with no previous configuration. When you
enable bulk configuration, Infrastructure Manager is disabled and the Template Editor appears in the Admin Console GUI. Once you
enable bulk configuration, there is no supported process for going back to manual configuration. Be sure that you fully understand and
accept the consequences of enabling bulk configuration before enabling it.

Before using the template editor, first enable bulk configuration, which is disabled by default.
Follow these steps:
2. Click Configure.
3. In the Probe Setup dialog, select Enable Bulk Configuration.
A dialog appears.
4. Click Reload.
Bulk configuration is enabled.
Using Templates
The template editor allows you to configure and apply monitoring templates. Templates reduce the time that you need for manual configuration
and provide consistent monitoring across the devices in your network. You can configure monitoring on many targets with a well-defined template.
You can also create multiple templates to define unique configurations for all devices and groups of target devices in your environment.
You can use the template editor to:
Copy, modify, and apply a default template
Create and apply a new template
You can customize any template that you copy or create by configuring:
Precedence
precedence of one overrides the settings in the other template. If the precedence numbers are equal, then the templates are applied in
alphabetical order.
Note: The default template is applied with a precedence of 100. Be sure to set the precedence of your other templates to a
number lower than 100 so that the probe applies them at a higher priority than the default template. We recommend using incre
ments of 10. Using increments of 10, you can easily add custom templates and assign them a precedence that results in the
probe applying them in the order that you desire.
Filters
Rules
Monitors
Note: Wait for the component discovery process to complete before using templates. Some QoS metrics are only applied to
components on specific devices. Determine what device types exist in your environment before you activate a template.
The default templates contain settings fora recommended monitor configuration. These default configurations include high-value metrics for
Follow these steps:

2. Click ibmvm >Template Editor.
3. Select either UMP_Metrics or VM_and_Host_Template.
7. Check Active.
8. Click Submit.
9. Click Save.
You can modify a default template to meet your specific needs. When your modifications are complete, you activate the template. The probe then
applies the template to the appropriate devices and components.
Follow these steps:
2. Click ibmvm > Template Editor.
3. Select either UMP_Metrics or VM_and_Host_Template.
7. Click Submit.
8. Click Save.
9. (Optional) Create template filters.
10. (Optional) Add rules to a template filter.
11. (Optional) Add monitors to a template filter.
12. In the navigation tree, select the template that you created in steps 1-5.
The template set up dialog appears in the detail pane.
13. Check Active.
The probe applies the template with the modified settings.
Create a Template
You can create your own template.

Follow these steps:
2. Click Configure.
3. Click ibmvm > Template Editor.
Note: Do not activate the template if you want to configure template monitoring filters or rules. If you change the template state
to active, the probe immediately applies the configuration.
7. Click Submit.
8. Click Save.
The system creates a template that you can configure and activate.
For more information, see Create Template Filters, Add Rules to a Template Filter, Add Monitors to a Template Filter, and Activate a
Template.
Follow these steps:
1. In the template editor, select the template that you created.
2. Choose any node that has the Options (...) icon next to it.
3. Enter a descriptive name for the filter and a precedence.
4. Repeat the previous steps for every template that requires filters.
5. Click Submit.
The template filter is created.
Note: You must activate the template for the probe to apply the filter configuration. When you change the template state to
active, the probe immediately applies all template configuration, including filters, rules, and monitors.
A filter allows you to control which devices and monitors are associated with a particular template. You specify more device criteria by using rules.
within a group of systems or reduce the set of devices that the probe monitors. For example, you can add a rule to apply a configuration to all
devices with the name Cisco.
Note: If no rules exist, the probe always applies the monitor configuration in an active template to all applicable devices.
Follow these steps:

1. To add a filter that applies to the entire template, click ibmvm > Template Editor >ibmvm probe > template name.
Or, to add a rule to a specific device filter, go to Template Editor > ibmvm probe > template name > Device Filters > device filter.
The details pane displays the filter configuration.
2. In the details pane, go to the Rules section. Select New.
3. Select the type of rule.
For example, these are commonly available rule types for device filters:
Computer Name - Devices that match the entered computer name name.
Label - Devices that match the entered component name.
Primary DNS - Devices that match the entered primary DNS server.
4. Select a condition. The conditions that you can apply to the rules are:
Contains
Does not contain
Ends with
Equals
Not equals
Regex (regular expression)
Starts with
5. Enter a value for the rule.
6. Click Save.
The rule is created.
Note: You must activate the template for the probe to apply the rule configuration. When you change the template state to active, the
probe immediately applies all template configuration, including filters, rules, and monitors.
Device filters contain a set of commonly used monitors that you can configure to meet you specific needs.
Follow these steps:
1. Click ibmvm > Template Editor >ibmvm probe > template name.
2. Click the desired device filter.
3. In the Detail pane, in the Monitors section, select any monitor.
A configuration dialog for the monitor appears below.
4. Check Include in Template to turn on the monitor.
5. (Optional) Check Publish Data.
6. (Optional) Check Publish Alarms.
Enter the desired settings for these required fields:
Value Definition
High Threshold
High Message Name
Low Operator
Low Threshold
Low Message Name
See Configure Alarm Thresholds for details.
7. Click Save.
The monitor is added.
Activate a Template
The probe does not automatically apply the template configuration. The probe only applies templates in an active state. The template icon in the
navigation pane indicates the state of the template. The states are inactive (
to apply it.
) and active (
). You must activate a template for the probe
Follow these steps:

1. Go to the Template Editor > ibmvm > template name.
2. Check the Active box.
3. Click Save.
The probe applies the monitoring configuration.
Note: You cannot modify a configured monitor in the probe configuration GUI once you activate a template.

The Template Summary View appears in the detail pane. It contains three sections.
1. The top section shows the basic configuration of the template:
1.
Template Name
Description
Precedence
Activation Status
2. The middle section shows the All Monitors table that lists all monitors available in the template.
3. The bottom section shows the detailed configuration for a monitor selected in the table.
You can view all of the monitors included in any template configuration in the All Monitors table.
Follow these steps:
1. In the left-hand navigation tree, select a template.
The Template Summary view appears in the detail pane. In the Monitors Included in Template table, you see all of the monitors available
for the template and their configuration status.
2. To see details for a specific monitor, click on it.
The configuration details appear below the table.
When you copy a default read-only template or create your own new template, you can edit the template's monitors from the Template Summary
View.
Note: For a default read-only template, you can view but cannot edit the template's monitor configuration in Template Summary View.
Follow these steps:

1. Select a monitor from the Monitors Included in Template table.
2. In the detail pane below the table, click on the Edit in Context hyperlink.
The hyperlink takes you to the autofilter that contains the selected monitor.
For more information about how to configure monitors, see Add Monitors to a Template Filter. For more information about how to configure
alarms, see Configure Alarm Thresholds.
v2.3 ibmvm AC GUI Reference

This article describes the fields and features in the IBM VM Monitoring (ibmvm) probe.
Contents
Tree Hierarchy
Tree Icons
ibmvm Node
Template Editor
Profiles Node
Resource Node
<Device> Nodes
VIOs Node
VMs Node
Tree Hierarchy
monitors available for that component. The tree contains a hierarchical representation of the components that exist in the IBM virtualization
environment.
Tree Icons
- Closed folder. Organizational node that is used to group similar objects. Click the node to expand it.
- Open folder. Organizational node that is used to group similar objects. Click the triangle next to the folder to collapse it.
- Unknown.
- Storage pool
- Datastore
The VM icon indicates the state of the VM.
- Running
- Stopped
- Paused

- Disk
- Memory
- Network interface
- VIOs or VMs
ibmvm Node
Navigation: ibmvm Node
The ibmvm node contains the following sections:
ibmvm > Probe Information
ibmvm > Probe Setup
You can set up the probe's Log Level. The default level is 3 (Recommended). You can set the log level to 4 or 5 for troubleshooting and
return it to 3 for normal operations.
ibmvm >
>Add New Profile
You can manually add a device profile. The profile icon indicates the status of subcomponent discovery.
Fields to know:
Hostname
Active
Port
Interval (secs)
Username
Password
Alarm Message
Template Editor
You use the template editor to apply monitoring templates, with optional filters, rules, and monitors, to one or more resources.
Note: For more information about how to use the Template Editor, see v2.3 Apply Monitoring with Templates.
Profiles Node
device.
Navigation: ibmvm Node > profile name
profile name >

> Delete Profile

Fields to know:
Hostname
Note: If you use an IPv6 address, you must follow the Java standard of enclosing the IPv6 address in square brackets. For
example: The input string [f0d0:0:0:0:0:0:0:10.0.00.0] works. But the input string f0d0:0:0:0:0:0:0:10.0.00.0 causes a stack
trace error that includes the exception: Caused by: java.lang.NumberFormatException: For input string:
"f0d0:0:0:0:0:0:0:10.0.00.0".
Active
Port
Interval (secs)
Username
Password
Alarm Message
Resource Node
The Resource node contains the managed systems that are associated with the resource.
Navigation: ibmvm > profile name > resource name
Click to view a Hosts node containing the managed systems that are on the resource.

Under each <managed system> node you can view device, VIO, and VM nodes, and can manage the QoS metrics and thresholds for the
managed system.
Navigation: ibmvm Node > profile name > resource name > Hosts > managed system name
Fields to know:
QoS Name
Description
Units
Metric Type Id
Publish Data
Publish Alarms
Value Definition
Current Value -- The most current value that is measured will be used.
Delta Per Second -- The delta value that is calculated from the samples that are measured within a second will be used.
Note: The value definition effects the QoS publication interval. For example: If you set the value definition to an "average
of n," the probe will wait n cycles before it sends any QoS data to the Discovery server. If you set the value definition to
"delta," the probe will wait two cycles before it sends any QoS data to the Discovery server.
Number of Samples
Operator
Example:
Threshold
Message Name
pool.
<Device> Nodes
<Device> nodes exist for managed systems, VIOs, and VMs. Possible devices are CPUs, CPU Pools, disks, memory, network interfaces, and
storage pools.
Navigation options:
Managed system device -- ibmvm Node > profile name > resource name > Hosts > managed system name > device name
VIO device -- ibmvm Node > profile name > resource name > Hosts > managed system name > VIOs > VIO name > device name
VM device -- ibmvm Node > profile name > resource name > Hosts > managed system name > VMs > VM name > device name
Note: If you click a <Device> node, you might see a table with QoS metrics or more named device nodes. You must click the named device
<Device> > Monitors
Fields to know:
QoS Name
Description
Units
Metric Type Id
Publish Data
Publish Alarms
Value Definition
Current Value -- The most current value that is measured
Delta Value (Current - Previous) -- The delta value that is calculated from the current and the previous measured sample
Delta Per Second -- The delta value that is calculated from the samples that are measured within a second
Average Value Last n Samples -- The user specifies a count and the value is averaged based on the last "count" items
Number of Samples
Operator
Example:
Threshold
Message Name
pool.
VIOs Node
The VIOs node contains the VIO resources on a managed system.
Navigation: ibmvm Node > profile name > resource name > Hosts > managed system name > VIOs
Click to view the VIO resources. Each VIO resource contains nodes for the devices that are associated with the VIO. For more information about
devices, see <Device> Nodes.
VMs Node
The VMs node contains the VM resources on a managed system.
Navigation: ibmvm Node > profile name > resource name > Hosts > managed system name > VMs
Click to view the VM resources. Each VM resource contains nodes for the devices that are associated with the VIM. For more information about
devices, see <Device> Nodes.
v2.30 ibmvm AC Configure Alarm Thresholds

For more information about configuring thresholds for numeric monitors for the IBM VM Monitoring (ibmvm) v2.30 or later, see Configuring Alarm
Thresholds. The link takes you to a page that describes how to configure centralized thresholds for select probes in CA Unified Infrastructure
Management.
Important!
Thresholds for the following three types of monitors can only be configured in Admin Console:
Event Forwarding Monitors
Alarm Forwarding Monitors
Monitors with Boolean, Enumeration, or String-only Metrics
v2.3 ibmvm IM Configuration

This section describes the configuration concepts and procedures for setting up the IBM VM Monitoring (ibmvm) probe.
Contents
Overview
Probe Configuration
General Setup
Adding Monitors
Using Templates
Apply a Template
Overview
The probe does not monitor anything automatically. You need to define what to monitor. Perform the following steps to configure a probe:
1. Connect to a resource (Hardware Management Console or Integrated Virtualization Manager).
2. Add monitors (checkpoints).
3. Configure the checkpoints to send QoS data and alarms if the thresholds specified are breached.
The following component entities can be monitored on the Managed System:
CPU
CPU Pool
Disk
Memory
Network
Storage Pool
The following component entities can be monitored on the virtual I/O server (VIOs) and virtual machines (VMs):
CPU
Disk
Memory
Network
Probe Configuration
Double-click the line representing the probe in Infrastructure Manager to open the probe GUI.
When the probe is initially installed, this screen displays with the following:
An empty Resources node
An empty Templates node.
General Setup
Click the General Setup button to set the level of details written to the log file for the ibmvm probe. The log level is a sliding scale. Level 1 logs
only fatal errors. Level 5 logs extremely detailed information used for debugging purposes. The default level is 3 (recommended). You can set the
log level to 4 or 5 for troubleshooting and return it to 3 for normal operations. Log as little as possible during normal operation to minimize disk
consumption.

Hostname or IP address
Port
Active
SSH connection timeout (sec)
Time to wait for connection to establish.
Check interval
How often the probe checks the values of the monitors.
Username
A valid username to be used by the probe to log on to the IBM server.
Password
A valid password to be used by the probe to log on the IBM server.
Group
The group you want the resource associated with.
Alarm Message
Note: You can edit the message or create your own message using Message Pool Manager.
Check Interval
The check interval defines how often the probe checks the values of the monitors. This can be set in seconds, minutes or hours. The IBM
server data is updated once per minute. We recommend polling once every 10 minutes. The polling interval should not be smaller than
the time required to collect the data.
Test button
Note: The very first time you click the Test button after you have created your first resource, you may receive an error message. In that
case, wait for at least 20 seconds and click the Test button again.
After completing the fields and testing that the connection works, click OK to add the Resource.

You can add, remove, or modify alarm messages.These are the messages sent when a QoS threshold has been breached.

Identification Name
3.
Token
Error Alarm Text
Example: $monitor
Error Severity
Subsystem string/id
The ID within NAS that corresponds to the probe or a common component such as CPU. This is used for categorizing alarms.


5. Click OK.
Adding Monitors
There are three different ways to add monitors to ibmvm entities:
Monitor dialog.
Use Templates
Templates let you define reusable sets of monitors to apply to various ibmvm monitored entities.
- A green button means that the monitor is configured and active.

- A grey button means that the monitor is configured but not active.
- A black button means that the monitor is not configured.
Selecting the checkbox next to a monitor name only enables the monitor. To configure the probe to send QoS data and/or send alarms you must
modify the properties for each monitor.
Double-click a monitor (or right-click and select Edit) to launch the monitors properties dialog. See Edit Monitor Properties for further information.
Update the fields as necessary. The fields are:
Resources
This is a read-only field, that contains the name of the resource associated with the name of a monitor. The monitor name is displayed
when the monitor is retrieved from the IBM Server.
Key
Description
This is a read-only field. describing the monitor. This description appears when the monitor is retrieved from the IBM Server.
Value Definition
The current value -- The most current value measured will be used.
The delta value (current - previous) -- The delta value calculated from the current and the previous measured sample will be used.
Delta per second -- The delta value calculated from the samples measured within a second will be used.
The average value (cur + prev)/2 -- The current plus the previous value of the sample divided by 2.
The average value last... -- The user specifies a count. The value is then averaged based on the last "count" items.
Active
Activates monitoring on the probe.
Enable Alarming
Activates alarming.
Note that the monitor will also be selected in the list of monitors in the right pane when this option is selected. You can enable/disable
monitoring from that list.
Operator
The operator to be used when setting the alarm threshold for the measured value.
Example:
Threshold
Unit
Message ID
The alarm message to be issued if the specified threshold value is breached. These messages are kept in the message pool. The

QoS Name
The name to be used on the QoS message issued.
Using Templates
Templates provide an easy way to consistently monitor of your IBM virtualization environment by allowing you to predefine reusable sets of
monitors.
These default templates are included with the probe:
UMP Metrics
VM and Host Template
The default templates contain commonly used metric configurations that let you quickly apply monitoring.
You can also create your own templates and define a set of monitors belonging to each. You can then apply these templates to anything in the
assigns the template monitors to the drop point and everything below it
You can apply a default template as you do any other template. However, you may want to copy the default template and then apply the copy.
Copying the default template allows you to make modifications to the copies without losing the original default template's monitor settings.
Follow these steps:
2. Select the default template.
3. Right-click>Copy Template.
The Templates Properties dialog appears.
4. Give the copy a name and description.
The default template is copied and appears under the Templates node and in the content pane.

Note: You can also edit an existing template: Select one of the templates defined under the Templates node in the navigation pane,

Apply a Template
After you create a template and define a set of monitors for that template, you can perform the following actions:
Drag and drop the template into the resource hierarchy where you want to monitor.
This action applies the monitors to a resource entity and any subordinate items. Any templates applied within the Resources hierarchy
are static monitors. The static monitors override any auto monitors for that specific resource entity.
Drag and drop the template monitors into the Auto Configurations node to add the template contents to the list of auto configuration
monitors.
This action applies the monitors to any new devices that are not currently monitored when the probe searches the environment for new
devices.
You can perform both actions within a single probe. You can place general-purpose templates into Auto Configuration, and apply special-purpose
templates to override the Auto Configuration templates on specific nodes, for specific purposes. See Using Automatic Configurations for details on
Auto Configuration.
Follow these steps:
2. Select the desired template from the list in the content pane.
3. Drag and drop it on the Auto Configurations node in the navigation pane.

configuring your resources. When new managed system/VM entities are detected, "Auto Monitors" are created for devices that are not currently
You can add contents from one or more templates or individual checkpoints to this node, using drag-and-drop. Click the Apply button and
restart the probe to activate the changes. The probe then searches through the IBM virtualization environment for applicable entities. Auto
Monitors representing the monitor(s) under the Auto Configuration node are created (and listed under the Auto Monitor node, see below)
for applicable entities where the metric does not already have a static monitor configured for it.
Important! If you are experiencing performance problems, we recommend increasing the polling cycle and/or the memory configuration
for the probe. Increase memory when the probe is running out of memory. Increase polling cycle when the collection takes longer than
the configured interval.
Auto Monitors node

This node lists Auto Monitors, created based on the contents added to the Auto Configuration node. Auto Monitors are only created for
content without an existing static monitor.

3. Click the Auto Configurations node to verify that the template's content was successfully added. See the Using Templates section to
learn more about templates.

To edit the properties for a monitor, right-click in the list and choose Edit from the menu. See the section To Edit Monitor Properties for
All defined Auto Monitors are listed under the Auto Monitors node. When you restart the probe, it searches through the Resource's entities. For
each one that is currently not monitored, an Auto Monitor is created for each of the monitors listed under the Auto Configurations node.
v2.3 ibmvm IM GUI Reference
This article describes the fields and features in the Infrastructure Manager interface for the IBM VM Monitoring (ibmvm) probe.
Contents
Probe GUI Overview

Toolbar Buttons
The Left Pane
Resources Node
Templates
The Right Pane
Probe GUI Overview

The window consists of a row of tool buttons above a window split into two parts:
The Navigation pane
The Content pane
At the bottom of the window, a status bar shows probe version information and when the probe was started.
Note: The probe is only configurable in Admin Console if you see the following message: "The probe is running in bulk configure mode.
This GUI is not supported in bulk configure mode. Exiting." For more information, see the v2.3 ibmvm AC Configuration guide.
Toolbar Buttons
These buttons are:

General Setup
New Resource
New Template
The Left Pane

The left pane shows the monitoring groups containing the resources that are defined, QoS definitions, and templates. Initially the Default Group
and the standard QoS definitions are created and appear in the pane.
Resources Node
The Resource is configured as a link to an IBM virtualization enabled system. The icon for each Resource node indicates the status of the
resource:
Inactive
Marked for deletion
Unable to connect
New (not yet saved)
Connected and inventory is ready to browse
Loading inventory and not ready to browse
Each Resource node contains the following sub-hierarchies:
Auto Configurations
The monitors under this node are used to automatically configure newly discovered devices. Drag-and-drop individual monitors or
templates (which define a set of monitors) onto this node.
Auto Monitors
Lists the monitors that were created based on the Auto-Configuration entries and the inventory available on the Resource.
All Monitors
Lists all monitors for the Resource, including Auto Monitors and manually configured monitors.
IBM Virtualization Environment hierarchy
Lists the Machine Resources, CPUs, CPU Pools, Disks, Memory, Network, Storage Pools, MSPPs, VIOs, and VMs available in the IBM
virtualization environment for monitoring.
Note: A node for Network will only appear if the device can be monitored. If the node does not appear, and the log level is set
to 2, a message is generated indicating that the network adapter does not return valid output. This is not an issue.
Templates
Templates are a useful tool for defining checkpoints to be monitored to on the various managed systems or Logical Partitions. This node contains
the following default templates:
VM and Host Templates
UMP Metrics
The default templates contain commonly used monitoring configurations that enable you to quickly apply monitoring.
For more information about how to apply monitoring with templates, see the Using Template section of the v2.3 ibmvm IM Configuration article.

Right-click with the mouse pointer in the navigation pane over the hostname or IP address node to open a pop-up menu for managing the
selected object or creating objects of its type. Options typically include: New, Edit, Delete, Deactivate, and Refresh.
The Right Pane

The right pane contains the QoS metrics for the resource that is selected in the left pane. If the resource selected in the left pane does not have
any QoS metrics associated with it, the right pane is blank.

Right-click on objects in the content pane to open a pop-up menu with menu items for managing the selected object type (Edit, Delete, and Add
to Template).
Contents
Add Monitoring
Alarm Thresholds
1. Add a Resource profile for each IBM virtualization enabled system you want to monitor.

Follow these steps:
Fields to know:
Hostname
3.

Active
Port
Interval (secs)
Username
Password
Alarm Message
4. Click Submit.
Add Monitoring
monitors for that component. Configure the QoS measurements you want to collect data for, and any alarms or events you want, by modifying the
appropriate fields.
Follow these steps:
2. Click on a managed system, device, virtual I/O server (VIO) or virtual machines (VMs) name. It might be necessary to expand the node in
6. Click OK.
Alarm Thresholds
allow the probe to:

This article describes the fields and features in the probe.
Contents
Tree Hierarchy
Tree Icons
ibmvm Node
Profiles Node
Resource Node
<Device> Nodes
VIOs Node
VMs Node
Tree Hierarchy
environment.
Tree Icons
- Open folder. Organizational node used to group similar objects. Click the triangle next to the folder to collapse it.
- Unknown.
- Storage pool
- Datastore
- The VM icon indicates the state of the VM.
- Running
- Stopped
- Paused

- Disk
- Memory
- Network interface
- VIOs or VMs
ibmvm Node
Set or modify the following values based on your requirements.
ibmvm > Probe Setup
Fields to know:
Log Level: Select the amount of log information you would like to collect for this probe.
Default: 3 (Recommended)
ibmvm >
>Add New Profile
You can manually add a device profile.

Fields to know:
Hostname
Active
Port
Interval (secs)
Username
Password
Alarm Message
The profile icon indicates the status of subcomponent discovery.
Profiles Node
device.
profile name >

> Delete Profile
Fields to know:
Hostname
Active
Port
Interval (secs)
Username
Password
Alarm Message
Resource Node
The Resource node contains the managed systems associated with the resource.
Click to view a Hosts node containing the managed systems on the resource.

Under each <managed system> node you can view device, VIO, and VM nodes, and manage the QoS metrics and thresholds for the managed
system.
Fields to know:
QoS Name
Description
Units
Metric Type Id
Publish Data
Publish Alarms
Value Definition
Number of Samples
Operator
Example:
Threshold
Message Name
pool.
<Device> Nodes
storage pools.
Navigation options:
Note: If you click a <Device> node, you might see a table with QoS metrics or additional named device nodes. You must click the named device
<Device> > Monitors
You can change monitor settings in the fields below the table.Select a monitor in the table to view the monitor configuration fields.
Fields to know:
QoS Name
Description
Units
Metric Type Id
Publish Data
Publish Alarms
Value Definition
Number of Samples
Operator
Example:
Threshold
Message Name
pool.
VIOs Node
Click to view the VIO resources. Each VIO resource contains nodes for the devices associated with the VIO. For more information about devices,
see <Device> Nodes.
VMs Node
Click to view the VM resources. Each VM resource contains nodes for the devices associated with the VIM. For more information about devices,
see <Device> Nodes.
v2.1 ibmvm IM Configuration

This article describes the configuration concepts and procedures for setting up the IBM VM Monitoring (ibmvm) probe.
Contents

Probe Configuration
Preparing the Probe
General Setup
Adding Monitors
Using Templates
Apply a Template

The probe configuration interface is automatically downloaded and installed by Infrastructure Manager when the probe is deployed on a robot.
The following component entities can be monitored on the Managed System:
CPU
CPU Pool
Disk
Memory
Network
Storage Pool
The following component entities can be monitored on the virtual I/O server (VIOs) and virtual machines (VMs):
CPU
Disk
Memory
Network
Probe Configuration
Double-click the line representing the probe in the Infrastructure Manager open the IBM virtualization probe GUI.
When the probe is initially installed, this screen displays with the following:
An empty Resources node
An empty Templates node
Preparing the Probe

The ibmvm probe does not monitor anything automatically. You must define what to monitor. Perform the following steps to configure a probe:
1. Connect to a resource (Hardware Management Console or Integrated Virtualization Manager).
2. Add monitors (checkpoints).
3. Configure the checkpoints to send QoS data and alarms if the thresholds specified are breached.
General Setup
Click the General Setup button to set the level of details written to the log file for the ibmvm probe. Log as little as possible during normal
operation to minimize disk consumption. This is a sliding scale with the range of information logged being fatal errors all the way to extremely
detailed information used for debugging purposes.

Right-click Resources in the navigation pane and select New Resource.
The Resource (New) dialog appears. Enter the appropriate field information:
Port
Active
SSH connection timeout (sec)
Time to wait for connection to establish.
Check interval
How often the probe checks the values of the monitors.
Username
Password
Group
The group that you want the resource associated with.
Alarm Message
Note: You can edit the message or create your own message using Message Pool Manager.
Check Interval
The check interval defines how often the probe checks the values of the monitors. This can be set in seconds, minutes or hours. The IBM
server data is updated once per minute. We recommend polling once every 10 minutes. The polling interval should not be smaller than
the time required to collect the data.
Test button
Note: The very first time you click the Test button after you have created your first resource, you may receive an error message. In that
case, wait for at least 20 seconds and click the Test button again.
After completing the fields and testing that the connection works, click OK to add the Resource.

You can add, remove, or modify alarm messages.These are the messages sent when a QoS threshold has been breached.

Identification Name
Token
Error Alarm Text
Example: $monitor
Error Severity
Subsystem string/id
The ID within NAS that corresponds to the probe or a common component such as CPU. This is used for categorizing alarms.

1.


5. Click OK.
Adding Monitors
There are three different ways to add monitors to ibmvm entities:
available check-boxes to enable QoS monitoring for the selected metrics. To enable Alarm thresholding, launch the Edit Monitor dialog.
See the section Manually Selecting Monitors to be Measured.
Use Templates
Templates let you define reusable sets of monitors to apply to various ibmvm monitored entities.
Resources hierarchy. Select a folder in the hierarchy to see the monitors for it, listed in the right pane. Click the check box next to the Monitors
Select the All Monitors node to list all monitors currently being measured in the right pane. You can select or clear monitors here, too.
Selecting the checkbox next to a monitor name only enables the monitor. To configure the probe to send QoS data or send alarms you must
modify the properties for each monitor.
Update the fields as necessary. The fields are:
Resources
This is a read-only field, that contains the name of the resource associated with the name of a monitor. The monitor name is displayed
when the monitor is retrieved from the IBM Server.
Key
Description
This is a read-only field. describing the monitor. This description appears when the monitor is retrieved from the IBM Server.
Value Definition
The current value -- The most current value measured will be used.
The delta value (current - previous) -- The delta value calculated from the current and the previous measured sample will be used.
Delta per second -- The delta value calculated from the samples measured within a second will be used.
The average value (cur + prev)/2 -- The current plus the previous value of the sample divided by 2.
The average value last... -- The user specifies a count. The value is then averaged based on the last "count" items.
Active
Activates monitoring on the probe.
Enable Alarming
Activates alarming.
Note that the monitor will also be selected in the list of monitors in the right pane when this option is selected. You can enable/disable
monitoring from that list.
Operator
The operator to be used when setting the alarm threshold for the measured value.
Example:
Threshold
Unit
Message ID
The alarm message to be issued if the specified threshold value is breached. These messages are kept in the message pool. The
QoS Name
The name to be used on the QoS message issued.
Using Templates
Templates provide an easy way to consistently monitor of your IBM virtualization environment by allowing you to predefine reusable sets of
monitors. After you create a template and define a set of monitors for that template, you can perform the following actions:
Drag and drop the template into the resource hierarchy where you want to monitor.
This action applies the monitors to a resource entity and any subordinate items. Any templates applied within the Resources hierarchy
are static monitors. The static monitors override any auto monitors for that specific resource entity.
Drag and drop the template monitors into the Auto Configurations node to add the template contents to the list of auto configuration
monitors.
This action applies the monitors to any new devices that are not currently monitored when the probe searches the environment for new
devices.
You can perform both actions within a single probe. You can place general-purpose templates into Auto Configuration, and apply special-purpose
templates to override the Auto Configuration templates on specific nodes, for specific purposes. See Using Automatic Configurations for details on
Auto Configuration.
Click the toolbar button for New Template (
).
Right-click the Templates node in the navigation pane, and select New Template from the menu.
Note: You can also edit an existing template: Select one of the templates defined under the Templates node in the navigation pane,

Apply a Template
Drag the template to the Auto Configurations node or the Resource entity (For example, VMs, Memory, Storage Pool, or VIO) where you want it
applied, and drop it there.

configuring your resources. When new managed system/VM entities are detected, "Auto Monitors" are created for devices that are not currently
You can add contents from one or more templates or individual checkpoints to this node, using drag-and-drop. Click the Apply button and
restart the probe to activate the changes. The probe then searches through the IBM virtualization environment for applicable entities. Auto
Monitors representing the monitor(s) under the Auto Configuration node are created (and listed under the Auto Monitor node, see below)
for applicable entities where the metric does not already have a static monitor configured for it.
Important! If you are experiencing performance problems, we recommend increasing the polling cycle or the memory configuration for
the probe. Increase memory when the probe is running out of memory. Increase polling cycle when the collection takes longer than the
configured interval.
Auto Monitors node

This node lists Auto Monitors, created based on the contents added to the Auto Configuration node. Auto Monitors are only created for
content without an existing static monitor.

3. Click the Auto Configurations node to verify that the template's content was successfully added. See the Using Templates section to
learn more about templates.
To edit the properties for a monitor, right-click in the list and select Edit from the menu. See the section Edit Monitor Properties for
To delete a monitor from the list, right-click in the list and select Delete from the menu.
All defined Auto Monitors are listed under the Auto Monitors node. When you restart the probe, it searches through the Resource's entities. For
each one that is currently not monitored, an Auto Monitor is created for each of the monitors listed under the Auto Configurations node.
v2.1 ibmvm IM GUI Reference

This article describes the fields and features in the Infrastructure Manager interface for the IBM VM Monitoring (ibmvm) probe.
Contents
Probe GUI Overview

Toolbar Buttons
The Left Pane
Resources Node
Templates
The Right Pane
Probe GUI Overview

The GUI consists of a row of tool buttons and two window panes. At the bottom of the window, a status bar shows probe version information and
when the probe was started.
Toolbar Buttons
The configuration tool also contains a row of toolbar buttons:
These buttons are:

General Setup
New Resource
New Template
The Left Pane

The left pane shows the monitoring groups containing the resources that are defined, QoS definitions, and templates. Initially the Default Group
and the standard QoS definitions are created and appear in the pane.
Resources Node
The Resource is configured as a link to an IBM virtualization enabled system.
The icon for each Resource node indicates the status of the resource:
Inactive
Marked for deletion
Unable to connect
New (not yet saved)
Connected and inventory is ready to browse
Loading inventory and not ready to browse
Each Resource node contains the following sub-hierarchies:
Auto Configurations
The monitors under this node are used to automatically configure newly discovered devices. Drag-and-drop individual monitors or
templates (which define a set of monitors) onto this node.
Auto Monitors
Lists the monitors that were created based on the Auto-Configuration entries and the inventory available on the Resource.
All Monitors
Lists all monitors for the Resource, including Auto Monitors and manually configured monitors.
IBM Virtualization Environment hierarchy
Lists the Machine Resources, CPUs, CPU Pools, Disks, Memory, Network, Storage Pools, MSPPs, VIOs, and VMs available in the IBM
virtualization environment for monitoring.
Note: A node for Network will only appear if the device can be monitored. If the node does not appear, and the log level is set
to 2, a message is generated indicating that the network adapter does not return valid output. This is not an issue.
Templates
Templates are a useful tool for defining checkpoints to be monitored to on the various managed systems or Logical Partitions.

Right-click with the mouse pointer in the navigation pane over the hostname or IP address node to open a pop-up menu for managing the
selected object or creating objects of its type. Options typically include: New, Edit, Delete, Deactivate, and Refresh.
The Right Pane

The right pane contains the QoS metrics for the resource that is selected in the left pane. If the resource selected in the left pane does not have
any QoS metrics associated with it, the right pane is blank.

Right-click on objects in the content pane to open a pop-up menu with menu items for managing the selected object type (Edit, Delete, and Add
to Template).
Contents
Add Monitoring
Alarm Thresholds
1. Add a Resource profile for each IBM virtualization enabled system you want to monitor.

Follow these steps:
Fields to know:
Hostname
Active
Port
Interval (secs)
Username
Password
Alarm Message
4. Click Submit.
Add Monitoring
monitors for that component. Configure the QoS measurements you want to collect data for, and any alarms or events you want, by modifying the
appropriate fields.
Follow these steps:
2. Click on a managed system, device, virtual I/O server (VIO) or virtual machines (VMs) name. It might be necessary to expand the node in
6. Click OK.
Alarm Thresholds
allow the probe to:

This article describes the fields and features in the IBM VM Monitoring (ibmvm) probe.
Contents
Tree Hierarchy
Tree Icons
ibmvm Node
Profiles Node
Resource Node
<Device> Nodes
VIOs Node
VMs Node
Tree Hierarchy
environment.
Tree Icons
- Open folder. Organizational node used to group similar objects. Click the triangle next to the folder to collapse it.
- Unknown.
- Storage pool
- Datastore
- The VM icon indicates the state of the VM.
- Running
- Stopped
- Paused

- Disk
- Memory
- Network interface
- VIOs or VMs
ibmvm Node
Set or modify the following values based on your requirements.
ibmvm > Probe Setup
Fields to know:
Log Level: Select the amount of log information you would like to collect for this probe.
Default: 3 (Recommended)
ibmvm >
>Add New Profile
You can manually add a device profile.

Fields to know:
Hostname
Active
Port
Interval (secs)
Username
Password
Alarm Message
The profile icon indicates the status of subcomponent discovery.
Profiles Node
device.
profile name >

> Delete Profile

Fields to know:
Hostname
Active
Port
Interval (secs)
Username
Password
Alarm Message
Resource Node
The Resource node contains the managed systems associated with the resource.
Click to view a Hosts node containing the managed systems on the resource.

Under each <managed system> node you can view device, VIO, and VM nodes, and manage the QoS metrics and thresholds for the managed
system.
Fields to know:
QoS Name
Description
Units
Metric Type Id
Publish Data
Publish Alarms
Value Definition
Number of Samples
Operator
Example:
Threshold
Message Name
pool.
<Device> Nodes
storage pools.
Navigation options:
Note: If you click a <Device> node, you might see a table with QoS metrics or additional named device nodes. You must click the named device
<Device> > Monitors
You can change monitor settings in the fields below the table.Select a monitor in the table to view the monitor configuration fields.
Fields to know:
QoS Name
Description
Units
Metric Type Id
Publish Data
Publish Alarms
Value Definition
Number of Samples
Operator
Example:
Threshold
Message Name
pool.
VIOs Node
Click to view the VIO resources. Each VIO resource contains nodes for the devices associated with the VIO. For more information about devices,
see <Device> Nodes.
VMs Node
Click to view the VM resources. Each VM resource contains nodes for the devices associated with the VIM. For more information about devices,
see <Device> Nodes.
ibmvm Metrics
The following table lists the metrics you can collect with the IBM Virtualization Monitoring (ibmvm) probe.
Resource
Metric
Name
Unit
Description
Version
RESOURCE
Build
String
Build of Hardware Management Console (HMC) host.
v1.0
RESOURCE
Release
String
Release of HMC host.
v1.0
RESOURCE
Response
Time
Milliseconds
Response time of data collection from HMC host.
v1.0
RESOURCE
Version
String
Version of HMC host.
v1.0
RESOURCE_MEM
Buffers
Megabytes
HMC buffers memory.
v2.1
RESOURCE_MEM
Percent
Used
Percent
HMC percent memory used.
v2.1
RESOURCE_MEM
Total
Megabytes
HMC total memory.
v2.1
RESOURCE_MEM
Used
Megabytes
HMC used memory.
v2.1
RESOURCE_SWAP
Cached
Megabytes
HMC swapspace cached.
v2.1
RESOURCE_SWAP
Percent
Used
Percent
HMC percent swap used.
v2.1
RESOURCE_SWAP
Total
Megabytes
HMC total swap capacity.
v2.1
RESOURCE_SWAP
Used
Megabytes
HMC used swap.
v2.1
RESOURCE_CPU_GROUP Average
Kernel
Utilization
Percent
The average HMC kernel CPU utilization.
v2.1
RESOURCE_CPU_GROUP Average
User
Utilization
Percent
The average HMC CPU utilization for non-kernel function.
v2.1
RESOURCE_CPU
I/O Waiting
Percent
HMC CPU I/O waiting percentage.
v2.1
RESOURCE_CPU
Idle Task
Percent
HMC CPU idle task percentage.
v2.1
RESOURCE_CPU
System
Mode
Percent
HMC CPU system mode percentage.
v2.1
RESOURCE_CPU
User Mode
Percent
HMC CPU user mode percentage.
v2.1
RESOURCE_DISK
Filesystem
String
HMC filesystem that this mount belongs to.
v2.1
RESOURCE_DISK
Percent
Used
Percent
Percent usage for this HMC filesystem.
v2.1
RESOURCE_DISK
Total
Megabytes
Total available capacity of the HMC disk.
v2.1
RESOURCE_DISK
Used
Megabytes
Used filesystem space on the HMC disk.
v2.1
HOST
Active
Memory
Sharing
Capable
Boolean
Active Memory Sharing is a virtualization technology that allows multiple partitions

to share a pool of physical memory. Valid values:
0 - not capable
1 - capable
v1.0
HOST
CoD Memory
Capable
Boolean
Capacity on Demand. The ability to add compute capacity in the form of CPU or
memory to a running system by simply activating it. The resources must be
pre-staged in the system prior to use and are (typically) turned on with an
activation key. Valid values:
0 - not capable
1 - capable
v1.0
HOST
CoD
Processor
Capable
Boolean
Capacity on Demand. The ability to add compute capacity in the form of CPU or
memory to a running system by simply activating it. The resources must be
pre-staged in the system prior to use and are (typically) turned on with an
activation key. Valid values:
0 - not capable
1 - capable
v1.0
HOST
Managed
System
Execution
State
String
The host managed system execution state label. Valid values:

Operating - the managed system is running
<Empty> - the managed system is not running
v1.0
HOST
Managed
System
Execution
State Value
Integer
The host managed system execution state. Valid values:

0 - not running
1 - running
v1.0
HOST
Maximum
LPARs
Supported
Number
The maximum VMs supported by the host.
v1.0
HOST
Model
String
The managed system model.
v1.0
HOST
Serial
Number
String
The managed system serial number.
v1.0
HOST
VIO Total
Number
The current VIO count.
v1.0
HOST
VM Total
Number
The current VM count.
v1.0
HOST
VMs
Stopped
Number
Number of stopped VMs.
v1.0
HOST
Virtual Fiber
Channel
Capable
Boolean
Indicates if this managed system is Virtual Fiber Channel Capable.
v1.0
HOST
Virtual I/O
Server
Capable
Boolean
Indicates if this managed system is Virtual I/O Server Capable.
v1.0
HOST
Virtual
Switch
Capable
Boolean
Indicates if this managed system is Virtual Switch Capable.
v1.0
HOST_CPU
Available
Processing
Units
Number
Current number of configurable processing units on the managed system that are
not assigned to partitions.number of available processing units.
v1.0
HOST_CPU
Configurable
Processing
Units
Number
Total number of configurable processing units on the managed system.
v1.0
HOST_CPU
Deconfigured
Processing
Units
Number
The number of processing units on the managed system that have been
unconfigured. This includes processing units that have been unconfigured by the
system due to hardware failure, and processing units that have been manually
unconfigured.
v1.0
HOST_CPU
Installed
Processing
Units
Number
The total number of processing units installed on the managed system.
v1.0
HOST_MEMORY
Assigned
Memory
Megabytes
Amount of memory assigned to VMs. This figure is equal to the "Installed

Memory" minus "Unassigned Memory".
v1.0
HOST_MEMORY
Configurable
Memory
Megabytes
Total amount of configurable memory available on the managed system.
v1.0
HOST_MEMORY
Deconfigured
Memory
Megabytes
The amount of memory, in megabytes, on the managed system that has been
unconfigured. This includes memory that has been unconfigured by the system
due to hardware failure, and memory that has been manually unconfigured.
v1.0
HOST_MEMORY
Installed
Memory
Megabytes
Total amount of memory installed on the managed system.
v1.0
HOST_MEMORY
Percent
Memory
Assigned
Percent
Percentage of configurable memory that has been assigned.

100 * (("Configurable Memory" - "System Firmware Current Memory") "Unassigned Memory")/("Configurable Memory" - "System Firmware Memory")
v1.0
HOST_MEMORY
System
Firmware
Current
Memory
Megabytes
Amount of memory used by the system firmware.
v1.0
HOST_MEMORY
Unassigned
Memory
Megabytes
Amount of memory available to be assigned to VMs.
v1.0
HOST_COD
Available
CoD
processors
Count
Total available processors for Capacity on Demand (CoD).
v2.1
HOST_COD
CoD Memory
Activated
Megabytes
The amount of memory activated for CoD.
v2.1
HOST_COD
CoD Memory
Available
Megabytes
The amount of memory available for CoD.
v2.1
HOST_COD
CoD Memory
Requested
Days
Available
Days
The total number of days for CoD memory requests.
v2.1
HOST_COD
CoD Memory
Requested
Days Left
Days
The remaining number of days available for CoD memory requests.
v2.1
HOST_COD
CoD Memory
Requested
Hours Left
Hrs
The remaining number of hours available for CoD memory requests.
v2.1
HOST_COD
CoD Memory
State
String
The memory state for CoD. For example, "Available" or "Code Not Entered."
v2.1
HOST_COD
CoD
Processor
State
String
The processor state for CoD. For example, "Available" or "Code Not Entered."
v2.1
HOST_COD
CoD
Processors
Activated
Count
The total number of processors activated for CoD.
v2.1
HOST_COD
CoD
Processors
Available
Count
The number of processors available for CoD.
v2.1
HOST_COD
CoD
Processors
Day Hours
Left
Hrs
The remaining number of hours available for CoD.
v2.1
HOST_COD
CoD
Processors
Requested
Days
Available
Days
The total number of days for CoD processor requests.
v2.1
HOST_COD
CoD
Processors
Requested
Days Left
Days
The remaining number of days available for CoD processor requests.
v2.1
HOST_COD
Total
Permanent
CoD Memory
Megabytes
The total amount of permanent CoD memory for CoD.
v2.1
HOST_COD
Unreturned
CoD Memory
Megabytes
The total amount of unreturned Cod memory for CoD.
v2.1
HOST_COD
Unreturned
CoD
Processors
Count
The total amount of unreturned Cod processors for CoD.
v2.1
HOST_DISK_GROUP
Disks
Missing
Metrics
Number
Number of disks not marked as 'Failed' but missing metrics.
v2.1
HOST_DISK_GROUP
Failed Disks
Number
Number of disks in 'Failed' or 'Problem' state.
v2.1
HOST_DISK
Disk Parent
String
The host disk capacity.
v1.0
HOST_DISK
Disk Size
Megabytes
Percent bandwidth used for each disk.
v1.0
HOST_DISK
Disk Status
String
Disk data transfer rate per second for each disk.
v1.0
HOST_DISK
Storage Pool
String
The storage pool this volume belongs to.
v1.0
HOST_DISK
Disk
Bandwidth
Used (%)
Percent
Network interface description.
v2.3
HOST_DISK
Disk Data
Transfer
Rate
Kilobytes/Second
Total number of kilobytes received.
v2.3
HOST_DISK
Disk KB
Read
KB
Disk total number of kilobytes read.
v2.1
HOST_DISK
Disk KB
Write
KB
Disk total number of kilobytes written.
v2.1
HOST_DISK
Transfers
Per Second
tps
Number of transfers per second issued to the physical disk. A transfer is an I/O
request to the physical disk. Multiple logical requests can be combined into a
single I/O request to the disk. A transfer is an indeterminate size.
v2.1
HOST_NIC
Description
String
Network interface description, for example: "Logical Host Ethernet Port".
v1.0
HOST_NIC
Kilobytes
Received
Kilobytes
v1.0
HOST_NIC
Kilobytes
Sent
Kilobytes
Total number of packets received.
v1.0
HOST_NIC
Last Reset
Time
String
The last time the network statistics were reset.
v1.0
HOST_NIC
Packets
Received
Packets
v1.0
HOST_NIC
Packets Sent
Packets
The host disk capacity.
v1.0
HOST_NIC
Status
String
Network interface status.
v1.0
CPU_POOL
Global
Shared
Processor
Pool Size
Number
Size of the global shared processor pool. The Global Shared Processor Pool
consists of the processors that are not already assigned to running partitions with
dedicated processors.
v1.0
CPU_POOL
Global
Shared
Processor
Pool
Utilization
Percent
The average global shared processor pool utilization.
v1.0
CPU_MSPP
Shared
Processor
Pool Size
Number
Size of the shared processor pool. Shared-processor pools have been available
since the introduction of IBM's POWER5 processor-based systems. This
technology allows you to share a group of processors between multiple LPARs.
Shared pools allow LPARs to juggle processor usage to balance out overall
processor usage. Originally, POWER5 systems allowed only one shared
processor pool. POWER6 processors enable the capability to have multiple
shared-processor pools. To employ multiple shared-processor pools, you must
use PowerVM Standard or Enterprise Edition.
v2.0
CPU_MSPP
Shared
Processor
Pool
Utilization
Percent
The average shared processor pool utilization.
v2.0
SR
Number of
Backing
Devices
Count
Number of backing devices.
v1.0
SR
Storage Pool
Free
Megabytes
Total space free in the storage pool.
v1.0
SR
Storage Pool
Size
Megabytes
Total size of the storage pool.
v1.0
SR
Storage Pool
Used
Megabytes
Total space used in the storage pool.
v1.0
SR
Storage Pool
Utilization
Percent
Percentage of storage space used.
v1.0
VIO
Average
CPU
Utilization
Percent
The average CPU utilization of this VIO Server.
v1.0
VIO
Disk Paging
Pages
Disk paging activity (pages in and out).
v1.0
VIO
Primary
HMC
String
Amount of data transfered in the entire system in kilobytes per second.
v1.0
VIO
Primary
HMC IP
String
The execution state of the VM.
v1.0
VIO
Secondary
HMC
String
v1.0
VIO
Secondary
HMC IP
String
Size of the global shared processor pool. The Global Shared Processor Pool
consists of the processors that are not already assigned to running partitions with
dedicated processors.
v1.0
VIO
System Disk
Data
Transfer
Rate
Kilobytes/Second
Amount of data transferred in the entire system in kilobytes per second.
v1.0
VIO
VIOS
Version
String
Size of the shared processor pool. Shared-processor pools have been available
since the introduction of IBM's POWER5 processor-based systems. This
technology allows you to share a group of processors between multiple LPARs.
Shared pools allow LPARs to juggle processor usage to balance out overall
processor usage. Originally, POWER5 systems allowed only one shared
processor pool. POWER6 processors enable the capability to have multiple
shared-processor pools. To employ multiple shared-processor pools, you must
use PowerVM Standard or Enterprise Edition.
v1.0
VIO
VM
Execution
State
String
v1.0
VIO
VM
Execution
State Value
Integer
The execution state value, in integer form, of the VM.
v1.0
VIO_CPU
Active
Processors
Processing Units
Number of processors or virtual processors that are varied on for the partition.
v2.1
VIO_CPU
Assigned
Processors
Processing Units
Current number of processors or virtual processors assigned to the partition.
v2.1
VIO_CPU
Current
Processing
Units
Processing Units
Current number of processing units assigned to the logical partition.
v2.1
VIO_CPU
Maximum
Processors
Processing Units
Maximum number of processors or virtual processors that can be dynamically

assigned to the partition.
v2.1
VIO_CPU
Minimum
Processors
Processing Units
Minimum number of processors or virtual processors that can be dynamically

v2.1
VIO_CPU
Physical
Processors
Consumed
Processing Units
The number of physical processors used by the partition
v2.1
VIO_CPU
Processing
Mode
String
Indicates whether the partition is using dedicated or shared resources.
v2.1
VIO_CPU
Processor
Entitlement
Consumed
Percent
Percentage of the entitled processing cycles used by the partition.
v2.1
VIO_CPU
Processor
Frequency
megahertz
The frequency of the physical processor associated with this VIO.
v2.1
VIO_CPU
Processor
Type
String
The type of the physical processor associated with this VIO.
v2.1
VIO_CPU
Runtime
Processing
Units
Processing Units
Number of processing units that are varied on for the partition.
v2.1
VIO_CPU
SMT
Enabled
Boolean
Is Symmetric Multi-Threading (SMT) enabled for processors.
v2.1
VIO_CPU
SMT
Threads
Count
The number of Symmetric Multi-Threading (SMT) threads per processor.
v2.1
VIO_CPU
Sharing
Mode
String
The sharing mode of the partition (cap/uncap)
v2.1
VIO_DISK_GROUP
Disks
Missing
Metrics
Number
Number of disks not marked as 'Failed' but missing metrics.
v2.1
VIO_DISK_GROUP
Failed Disks
Number
Number of disks in 'Failed' or problematic state.
v2.1
VIO_DISK
Disk
Bandwidth
Used (%)
Percent
v1.0
VIO_DISK
Disk Data
Transfer
Rate
Kilobytes Per
Second
v1.0
VIO_DISK
Disk KB
Read
KB
v1.0
VIO_DISK
Disk KB
Write
KB
v1.0
VIO_DISK
Disk Size
Megabytes
The size of the virtual disk
v2.1
VIO_DISK
Disk Status
String
The status of the virtual disk
v2.1
VIO_DISK
Storage Pool
String
The storage pool this volume belongs to.
v1.0
VIO_DISK
Transfers
Per Second
TPS
v1.0
VIO_DISK
Virtual
Storage
Adapter
String
The shared virtual storage adapter of the virtual disk
v2.1
VIO_NIC_GROUP
HEA Total
Number
Total number of host ethernet adapters.
v2.1
VIO_NIC_GROUP
Interfaces
Configured
Number
Count of interfaces configured with IP address.
v2.1
VIO_NIC_GROUP
Interfaces
DOWN
Number
Count of interfaces down.
v2.1
VIO_NIC_GROUP
Interfaces
Detached
Number
Count of interfaces in 'detach' state.
v2.1
VIO_NIC_GROUP
Interfaces
UP
Number
Count of interfaces up.
v2.1
VIO_NIC_GROUP
SEA Defined
Number
Number of shared ethernet adapters in 'Defined' state.
v2.1
VIO_NIC_GROUP
SEA Total
Number
Total number of shared ethernet adapters.
v2.1
VM
VM
Execution
State
String
The current runtime state of the partition. Valid values follow:

Not Activated
Starting
Running
Shutting Down
Error
Open Firmware
Not Available
v1.0
VM
VM
Execution
State Value
Integer
The execution state of the VM. Valid values:

0 - not running
1 - running
v1.0
VM_CPU
Active
Processors
Processing Units
Current number of processors or virtual processors assigned to the partition.
v1.0
VM_CPU
Assigned
Processors
Processing Units
Number of processors or virtual processors that are varied on for the partition.
v1.0
VM_CPU
Current
Processing
Units
Processing Units
Current number of processing units assigned to the logical partition.
v1.0
VM_CPU
Maximum
Processors
Processing Units
Maximum number of processors or virtual processors that can be dynamically

v1.0
VM_CPU
Minimum
Processors
Processing Units
Minimum number of processors or virtual processors that can be dynamically

v1.0
VM_CPU
Physical
Processors
Consumed
Processing Units
The number of physical processors used by the partition.
v1.0
VM_CPU
Processing
Mode
String
Indicates whether the partition is using dedicated or shared resources. . The

mode cannot change dynamically. Valid values:
ded - dedicated
shared - shared
v1.0
VM_CPU
Processor
Entitlement
Consumed
Percent
Percentage of the entitled processing cycles used by the partition.
v1.0
VM_CPU
Runtime
Processing
Units
Processing Units
Number of processing units that are varied on for the partition.
v1.0
VM_CPU
Sharing
Mode
String
The sharing mode of the partition (cap/uncap).
v1.0
VM_MEMORY
Assigned
Memory
Megabytes
Amount of memory assigned to the partition.
v1.0
VM_MEMORY
Maximum
Memory
Megabytes
Maximum amount of memory that can be dynamically assigned to the partition.
v1.0
VM_MEMORY
Minimum
Memory
Megabytes
Minimum amount of memory that can be dynamically assigned to the partition.
v1.0
VM_MEMORY
Used
Memory
Megabytes
Memory used by the partition at the time of sample.
v1.0
VM_DISK
Disk
Bandwidth
Used (%)
Percent
v1.0
VM_DISK
Disk Data
Transfer
Rate
Kilobytes/Second
v1.0
VM_DISK
Disk KB
Read
KB
v1.0
VM_DISK
Disk KB
Write
KB
v1.0
VM_DISK
Disk Size
Megabytes
The VM disk capacity.
v1.0
VM_DISK
Disk Status
String
v1.0
VM_DISK
Transfers
Per Second
TPS
v1.0
VM_DISK
Virtual
Storage
Adapter
String
Total number of kilobytes sent.
v1.0
VM_DISK_GROUP
Count
Problem
Storage
Volumes
Number
Number of disks not in one of the states "Available", "Enabled", or "Defined".
v1.0
VM_DISK_GROUP
Disks
Missing
Metrics
Number
Number of disks not marked as "Failed" but missing metrics.
v1.0
VM_NIC
Kilobytes
Received
Kilobytes
v1.0
VM_NIC
Kilobytes
Sent
Kilobytes
Total number of packets sent.
v1.0
VM_NIC
Packets
Received
Packets
Network interface status.
v1.0
VM_NIC
Packets Sent
Packets
Amount of memory assigned to the partition.
v1.0
VM_NIC
Status
String
Maximum amount of memory that can be dynamically assigned to the partition.
v1.0
ica_response (Citrix Client Response Monitoring)

The Citrix Client Response Monitoring (ica_response) probe tests the Citrix terminal server client connection by executing the login and logout
commands. The probe also enables you to launch an application or run a macro script.
You can create profiles for each Citrix ICA server to be monitored. The probe connects to the Citrix ICA servers as specified in the profiles, logs
in, and monitors the time taken to perform different tasks shown in the following diagram. The diagram displays a complete ICA server session for
different events. It also shows the various time durations, monitored by the probe through macro. A macro can measure either time 1 (t1) or time 2
(t2).
The terms used in this figure are explained as follows:

ICA Ping: waiting time to receive a response on an ICA ping.
Connect: time to connect to the ICA Server.
Logon: time to log-in to the ICA Server.
Application startup: total calculated time between the log-in and start of an application.
Logoff: time to logout from the ICA Server.
Session: total calculated time from start connect to disconnect from ICA server.
Total: total time to complete all activities of the monitoring profile.
Macro before connect: total calculated time between the connection establish and the macro execution.
Macro after connect: total calculated time between the start of the login process and completion of the macro execution.
Macro after logged on: total calculated time between the completion of the login process and completion of the macro execution
The probe also supports QoS (Quality of Service) data to generate trending data over a period. The QoS data reflects the actual accessibility as
experienced by end users attempting to log in the Citrix ICA servers. The probe generates the QoS data on the following metrics:
Connect time
Session time
Login time
Logout time
Startup publish application time
ICA ping
Total profile time
More information:
ica_response (Citrix Client Response Monitoring) Release Notes
ica_response AC Configuration
This section describes the configuration concepts and procedures for setting up the Citrix Client Response Monitoring probe. This probe is
configured to monitor the performance of the Citrix terminal server client connection, launch an application, and run a macro script. The following
diagram outlines the process to configure the probe to connect to the Citrix ICA servers, create a monitoring profile and configure alarms and
QoS.
Contents
Activate Monitors
Record a Macro
Verify that required hardware and software is available before you configure the probe. For more information, see ica_response (Citrix
Client Response Monitoring) Release Notes.
Verify that you have installed any one of the following Citrix Client software on the host system.
Citrix Receiver
Citrix Online Plug-in
Web Client Plug-in
Determine the user credentials to access the Citrix server.
Verify that PPM 2.80 or later is running on the primary hub.
Verify that you made the required registry changes
Verify that you have changed the citrixfilepath variable value in the CFG file to mention the correct installed path of the Citrix receiver.
Perform Registry Changes

The ica_response probe requires certain registry changes on the host system (where the probe is installed) to establish connection with the Citrix
Server.
Note: These registry changes are mandatory for the ICA functionality to work properly.
Follow these steps:

1. Deploy the ica_response probe and then deactivate it from the Infrastructure Manager (IM) or Admin Console. Deactivation is
recommended because these registry settings are used by the probe.
2. Install the appropriate Citrix client software on the computer where the probe is deployed.
3. Click Start, type regedit in the Search programs and files text box and press ENTER.
4. Select regedit.exe from the search results.
The Registry Editor window appears.
5. Open the hierarchy for HKEY_LOCAL_MACHINE as HKEY_LOCAL_MACHINE --> SOFTWARE --> Citrix --> ICA Client.
Note: For 64-bit, the hierarchy is HKEY_LOCAL_MACHINE --> SOFTWARE --> Wow6432Node -->Citrix --> ICA Client
6. Right-click on the ICA Client folder and select the New --> Key option.
A new folder gets created as a child of ICA Client parent folder.
7. Rename the new folder as CCM, right-click on this folder and select the NEW --> DWORD (32-bit) Value option.
A new attribute is created in the right-side pane of the Registry Editor window.
8. Rename the new attribute as AllowSimulationAPI.
9. Double-click the AllowSimulationAPI.
The Edit DWORD (32-bit) Value dialog appears.
10. Define 1 in the Value data field and click OK.
11. Restart your system.
Change the citrixfilepath Variable Value

You must change the citrixfilepath variable value in the CFG file using raw configuration option to mention the correct installed path of the Citrix
receiver.
Follow these steps:
1. Change the value for citrixfilepath variable, in the CFG file, with the path where the Citrix client software is installed. For example, if it is
installed at C:\ drive, then for:
32-bit Windows:
The value for citrixfilepath variable is the C:\Program Files\Citrix\ICA Client\.
64-bit Windows:
The value for citrixfilepath variable is C:\Program Files (x86)\Citrix\ICA Client\.
Note: The paths must end with "\".

The probe can now communicate with the Citrix server and retrieve the monitoring data.

You can create one or more monitoring profiles for monitoring a specific Citrix server and cater to different monitoring requirements. For example,
one monitoring profile executes application A and monitors the response time; while another monitoring profile executes a macro and monitors the
end user experience of application B.
Follow these steps:
1. Click the ica_response node of the probe.
2. Define user credentials under the General Configuration section. These user credentials are of the host system, where the probe is
deployed. These credentials provide necessary rights to the probe for executing the Citrix receiver client, which is installed on the host
system.
3. Click the Options (icon) next to the ica_response node.
4. Select the Add Profile option.
5. Configure the following properties in the General Profile Configuration dialog:
Connection: specifies the connection type of the profile, if the profile connects to the Citrix server or the published application.
Address: defines the IP address of the Citrix server for the profile to establish connection and capture the monitoring data. This field
specifies the name of the Application if Published Application option is selected in the Connection drop down.
Browser Address: defines the web URL or the IP address of the Citrix server for accessing the hosted application. This option, does
not allow you to define the application separately in the Application Configuration section and enable QoS data for Startup Publish
Application Time monitor.
Network Protocol: specifies the network protocol for locating the Citrix server or application.
Username: defines the user name that has appropriate access to the Citrix Server.
Password: defines the password for authenticating the Citrix server user.
Domain: defines the domain name of the Citrix server.
Check Interval: defines the time frequency for executing the monitoring profile. Do not overload the Citrix ICA server by checking too
often. A minimum time interval of 15 minutes is recommended.
Check Interval Unit: specifies the measurement unit of Check Interval field value.
6. Click Submit.
The profile appears as a separate node under the ica_response node in the navigation pane.
7. Click Save to update the probe configuration file with the new profile details.
The profile details are saved to probe configuration file and a Monitors node appears under the profile name node in the navigation
pane.
Activate Monitors
After creating a monitoring profile you must activate the required monitors to fetch monitoring data. All these monitors allow you to generate
alarms and generate QoS data when the specified thresholds are breached.
Follow these steps:
2.
2. Select the desired monitor from the Monitors section.

The related fields of the monitors are displayed below the Monitors section.
Note: The Total Profile Time monitor only generates QoS messages. The probe does not generate alarms even if Publish
Alarms is selected.
The probe restarts and reloads the probe GUI. The monitoring profile fetches the monitoring data of the configured monitors for generating alarms
and QoS.
Note: The probe takes considerable time after saving and reloading the configuration, so avoid saving the configuration frequently. The
recommendation is to configure all necessary monitors at once and then save the configuration.
Record a Macro
Macro recording is a functionality that records user actions for playback at a later time. In ica_response, for using the macro recording
functionality, a conf_ica_macro_recording application is provided with the probe. This application is available in the location where the probe is
deployed on your system.
You must first get connected with the ICA Server that you have defined in the selected profile. Once connected, you can open the conf_ica_macr
o_recording application and record the steps to execute certain functionality. These steps can be saved for future references. To enable the
macro recording functionality in the probe, you must enable the Run macro script option in the Macro Configuration section under the Profile
Name node.
Create a Macro Script

Select the Run macro script option in the Macro Configuration section to start using the macro recording functionality to create and save a macro
script.
You can either:
Create a new macro script using Macro recorder, or
Browse and locate the saved recording from the File option.
Click Macro recorder to perform other functionalities (playing the recording, modifying commands, and so on).
Follow these steps to create a new macro script:
1. Select the Run macro script check box in the Macro Configuration section under the Profile Name node.
2. Locate and run the conf_ica_macro_recording application.
The Macro Recorder dialog appears.
3. Click Macro Recorder.
The ICA Macro Script Recorder dialog appears.
a. Click Connect in the above dialog or click inside the empty window, marked Click here to connect to server to connect you to the
ICA server defined in the selected profile.
The server desktop appears in the window. If the profile is configured to start a published application, the application appears in the
window when started.
After the connection is established, the Connect button gets disabled and Log off gets enabled, in the ICA Macro Script Recorder di
alog.
b. For example, you have to work on Notepad and record a session containing some steps. So, click Start on the desktop that appears
in the window and select the Notepad application.
The Notepad application starts in the window.
c. Click Record to start the recording and start performing the steps.
After you click Record, recording starts and Stop button gets enabled. Also, Record, Play step, and Clear buttons get disabled.
If you want mouse move events to be included in the macro script, you can select the Record mouse move events checkbox. The
mouse events create many commands.
The recorded commands are listed at the bottom of the application window.
d. After the required session has been recorded, click Stop in the dialog.
The macro recording stops.
Note: The Record, Play step, and Clear buttons get enabled again. Click Log off to log you off the ICA server and disconnect.
e. Click Save and Exit to save the macro script and exit from the macro recording functionality. The Save macro script dialog appears
which allows you to save the macro script.
Click Play step to play the steps selected from the commands list at the bottom of the application window.
Click Clear to clear all recorded commands.
Click Exit to exit the macro recorder without saving the macro script.
Click Start -->Log off -->Disconnect, in the desktop that appear in the window, to disconnect you from the ICA server.
f. Enter the name of the recording in the File box and click OK. The macro script gets saved at the selected location with .rec extension.
This location now appears in the Filename text box in the Application tab of the Profiles tab, when you click the ellipsis (...) button.
Edit a Macro Script

To edit a macro script, you must modify the commands listed at the bottom of the application window, while recording the macro script. When you
right-click a command line in the macro script, four options are displayed - New before, New after, Edit and Delete. Select the Edit option to
modify the macro script.
Follow these steps:
1. Right-click the command that you want to modify and select the Edit option.
The Edit macro script line dialog appears.
2. Perform the required modifications and click OK.

The selected macro script is now modified.
Similarly, you can perform the other functionalities - Delete, New before, and New after.
Select New before to add a new entry before the selected line.
Select New after to add a new entry after the selected line.
The command line format is: Elapsed time;Command;Arg1;Arg2;Arg..
ica_response AC GUI Reference

Contents
Probe Interface
ica_response Node
<Profile Name> Node
Monitors Node
Probe Interface
The probe interface is divided into a navigation pane and a details pane. The navigation pane contains a hierarchical representation of the probe
inventory which includes monitoring targets and configurable elements. The details pane usually contains information based on your selection in
ica_response Node
The ica_response node is used to configure the general settings of the Citrix Client Response Monitoring probe, which are applicable to all
monitoring profiles of the probe.
Navigation: ica_response
ica_response > Probe Information
ica_response > General Configuration
This section lets you configure the default log level and other probe-related alarms.
Default: 0 - Fatal
Username: defines the user name having administrator rights on the host system, where the probe is installed. This user can be a
local user or a domain user and must have the appropriate rights to launch ica_response_poll.exe. If you do not enter any value in
these fields, then the exe is launched using the system account.
Password: defines the password of the corresponding user name.
Domain: defines the network domain name of the user.
Maximum Concurrent Sessions: specifies the number of profiles, which the probe can execute simultaneously. Each profile creates a
different session of the given user on the Citrix server.
Default: 5
Maximum Concurrent Sessions Reached Alarm: specifies the alarm message when the maximum number of concurrent sessions
reached.
Default: MaxSessionsReached
Maximum Concurrent Sessions Reached Clear: specifies the clear alarm message when the number of concurrent sessions is less
than maximum concurrent sessions limit.
Default: MaxSessionsOK
Profile Already Running Alarm: specifies the alarm message when the probe attempts to run an already running profile. For example,
a profile runs for a longer session than a monitoring interval and the probe runs the profile again before the previous session is
finished.
Default: ProfileAlreadyRunning
Profile Already Running Clear: specifies the clear alarm message when the profile already running alarm situation is rectified.
Default: ProfileAlreadyRunningOK
ica_response > Message Pool

This section lets you view the alarm message details that are available in the Citrix Client Response Monitoring probe. These alarms are
used for different monitoring parameters of the probe. This section is read-only.
Name identifies the unique name of the alarm message.
Text: identifies text of the alarm message.
Severity: identifies a severity level of the alarm.
<Profile Name> Node

The profile name node defines the monitoring parameters and configures appropriate QoS data and alarms for each profile.
Navigation: ica_response > profile name
profile name > General Profile Configuration
This section defines all the properties of the monitoring profile.
Default: Not selected.
Profile Name: defines a unique name of the profile.
Connection: specifies the connection type of the profile when the profile connects to the Citrix server or the published application.
Default: Server
Address: defines the IP address of the Citrix server for the profile for establishing connection and capture the monitoring data. This field
defines the name of the application if Published Application is selected in the Connection drop-down.
Browser Address: defines the web URL of the Citrix server for accessing the hosted application. This option disables the options for
defining the application separately in the Application Configuration section and enable QoS data for Startup Publish Application
Time monitor.
Default: HTTPonTCP
Username: defines the user name which is having appropriate access to the Citrix Server.
Password: defines the password for authenticating the Citrix Server user.
Check Interval: defines the time frequency for executing the monitoring profile.
Default: 60 Min
Check Interval Unit : defines the check interval unit.
Default: Hours
profile name > Application Configuration
This section defines the application details for monitoring application startup time during server monitoring.
Start Published Application: enables the monitoring profile to execute an application in each monitoring interval.
Application Name: defines the application name for the monitoring profile for executing for monitoring application startup time.
Arguments: defines the argument, which can be required, for the application startup.
Logoff Delay: defines the waiting time before logging off the monitoring session from the Citrix server after completing the monitoring
activities.
Default: 0
profile name > Macro Configuration
This section is used for running the Macro Recorder script on the Citrix ICA server.
Run Macro Script: enables you to run the Macro script on the Citrix ICA server.
File enables you to locate the Macro script to be run on the Citrix ICA server.
Start Point: enables you to select at which point in the test sequence the macro is started. The options are: Before connect, After
connect and After login.
profile name > Client Settings
This section is used for configuring an ICA file which contains setting for connecting to the Citrix server, user authentication details, and
application configuration details. This section is optional.
Use ICA File: enable the probe to fetch necessary Citrix server connection settings from the ICA file.
Filename: defines the ICA file path. You can use the Browse button for navigating to the ICA file.
Override Address Setting in ICA file: overrides the Citrix server address details in the ICA file with the General Profile Configuration sec
tion details.
Override Authentication Setting in ICA file: overrides the user authentication details in the ICA file with the General Profile
Configuration section details.
Override Application Setting in ICA file: overrides the application configuration details in the ICA file with the Application Configuration
section details.
Encryption Level: defines the encryption level for communication between the probe and the Citrix server.
Default: None
Monitors Node
The Monitors node lets you configure QoS data and alarms for the monitoring profile. This node contains a table displaying the list of all monitors.
You can select one or more than one monitor from the list. Then you can activate QoS data and and configure the alarm thresholds and
appropriate error alarm messages for the selected monitor.
Navigation: ica_response > profile name > Monitors
Notes:
Though the Publish Alarms option is visible for the Total Profile Time monitor, only QoS is generated for this monitor.
If the alarms are ON against any QoS, then these alarms are generated based on both Threshold Value fields. Thus, it is
mandatory to provide values for both the thresholds to generate alarms.
ica_response IM Configuration
This article describes the configuration concepts and procedures for setting up the ica_response probe. This probe is configured to monitor the
performance of the Citrix terminal server client connection, launch an application, and run a macro script. The following diagram outlines the
process to configure the probe to connect to the Citrix ICA servers, create a monitoring profile and configure alarms and QoS.
Contents
Create Profile
Record a Macro
Verify that you have installed any one of the following Citrix Client software on the host system:
Citrix Receiver
Web Client Plug-in
Verify that you made the required registry changes.

Server.
Important! These registry changes are mandatory for the ICA functionality to work properly.
Follow these steps:


receiver.
Follow these steps:
32-bit Windows:
64-bit Windows:
2.

Create Profile
This section describes the process to create a monitoring profile. You can create one or more monitoring profiles for monitoring a specific Citrix
server and cater to different monitoring requirements. For example, one monitoring profile executes application A and monitors the response time;
while another monitoring profile executes a macro and monitors the end user experience of application B.
Follow these steps:
The contents of the Profiles tab are displayed, by default.
2. Right-click in the profile pane, and click New to create a new profile.
The ICA Profile Properties dialog appears. Specify the values in the following fields:
Name: the name of the profile.
Connection: authentication details such as server IP for communication between the client and Citrix ICA server.
Check Interval: time interval between each response check. Do not overload the Citrix ICA server by checking too often. A minimum
time interval of 15 minutes is recommended.
3. Click the Alarms Tab to list the different alarm situations.
Define the Response properties (for alarm situations related to response time) or Event properties (for the other alarm situations) for
the selected alarm situation.
4. Click the Misc. tab. Select the QoS messages that you want to send and the timeout values for the different tasks performed by the
probe.
5. Click OK.
The new monitoring profile is created.
Record a Macro
Macro recording is a functionality that records user actions for playback at a later time.
You must first get connected with the ICA Server which you have defined in the selected profile by clicking Connect or by clicking Click here to
connect to server. Once connected, you can open the required application and record the steps to execute certain functionality. These steps can
be saved for future references. To enable the macro recording functionality in the ica_response probe, you are required to enable the Run macro
script option under the Application tab of the Profiles tab. This action enables the fields in this section and you can start using the macro
recording functionality to create and save a macro script.
You can either:
Browse and locate the saved recording from the Filename option to select the path.
Follow these steps:
1. Select the Run macro script check box.
A warning message is displayed as shown in the following dialog:
2. Click OK.
3. Select the Start point value at which the macro is to be started in the test sequence. Available values are Before connect, After
connect, and After login.
4. Click Macro recorder.
Note: Initially, the main window of the application is empty.
5. Click Connect in this dialog or click on the link Click here to connect to server to connect you to the ICA server defined in the selected
profile.
The server desktop appears. If the profile is configured to start a published application, this application appears in the window, when
started.
After the connection is established, the Connect button gets disabled and Log off gets enabled, in the ICA Macro Script Recorder dialo
g.
6. For example, you have to record a session containing some steps on a Notepad, click Start on the desktop and select the Notepad appli
6.
cation.
The Notepad application appears.
7. Click Record to start the recording and start performing the steps.
8. After the required session has been recorded, click Stop in the dialog.
The Record, Play step, and Clear buttons get enabled again. Click Log off to log you off the ICA server and disconnect.
9. Click Save and Exit to save the macro script and exit from the macro recording functionality.
The Save macro script dialog appears which allows you to save the macro script.
10. Enter the name of the recording in the File box and click OK.
The macro script gets saved at the selected location with .rec extension.
Note: This location appears in the Filename text box in the Application tab of the Profiles tab.
Edit a Macro Script

To edit a macro script, you need to modify the commands listed at the bottom of the application window, while recording the macro script. When
you right-click a command line in the macro script, four options are displayed - New before, New after, Edit and Delete.
You can, then, select the Edit option to modify the macro script.
Follow these steps:
Notes:
The command line format is: Elapsed time;Command;Arg1;Arg2;Arg.. See the section Macro Functions Overview for a
description of the commands and arguments available.
ica_response IM GUI Reference

This article describes the fields and features of the ica_response probe.
Contents
General Tab
Profiles Tab
General Tab
Application Tab
Alarms Tab
Client Settings Tab
Misc. Tab
The Status Tab
Macro Functions Overview
General Tab
This tab is used to:

specify the user name and password that are used by the probe to access its folder on local machine.
specify maximum number of sessions that can run simultaneously
set the level of details written to the log file, and
specify alarms to generate when maximum concurrent sessions are reached and an already running profile is again run by the probe
The fields are explained as follows:
ICA Client User
This is the user name and password the probe uses to access its folder on the local machine (Program
Files/Nimsoft/Probes/application/ica_response).
This user can be a local user or a domain user and must have the appropriate rights to launch ica_response_poll.exe. If you do not enter
any value in these fields, then the exe is launched using the system account.
Note: The ica_response_poll.exe is a child exe for each profile that is created by the user. For example, if the user creates four
profiles, then, there will be one ica_response.exe file in the probe installation directory and four ica_response_poll.exe files in
that directory.
Alarms
Maximum concurrent sessions reached
Select the alarm message to be issued when the probe exceeds the maximum number of concurrent sessions. You can also select
the Clear message to be issued when the number of concurrent sessions is below the maximum threshold.
Profile already running
Select the alarm message to be issued if the probe attempts to run a profile that is already running. This happens when the profile
runs a long session, and the check interval instructs the probe to run the profile again before the previous session is finished.
Also select the Clear message to be issued when the alarm situation is cleared.
Maximum concurrent sessions
Specifies the maximum number of sessions (profiles) allowed running simultaneously.
Log Level
Profiles Tab
This tab lists all the configured profiles and is used to add, modify, copy, or delete a profile. When you add or modify a profile, the Profile
Properties dialog is displayed with tabs - General, Application, Alarms, Client Settings, and Miscellaneous where you need to enter/select
the required information associated with the profile. Each entry in the Profiles list defines a monitoring profile for one Citrix ICA server logon/logoff
connection. The check boxes beside the active profiles are shown as selected. In order to define a valid profile, login user/password credentials
are mandatory. The password is encrypted in the probe configuration file.
Note: You must use different login users for different profiles defined to avoid conflicts if unexpected disconnects occur.
The following commands are available when you right-click in the profile pane:
New
Enables you to create a new profile by displaying the ICA Profile Properties dialog.
Edit
Enables you to edit profile properties for the selected profile by displaying the ICA Profile Properties dialog
Copy
Makes a copy of the selected profile. The Profile Properties dialog appears with all the properties copied from the selected profile.
Rename the copied profile and click the OK button.
Delete
Deletes the selected profile. A confirmation dialog is displayed for the deletion.
When you select the New or Edit option as explained above, the ICA Profile Properties dialog appears. This dialog has five tabs - General, App
lication, Alarms, Client Settings and, Misc. All these tabs are explained in the subsequent topics.
General Tab
This tab is used to specify:

the name or IP address of the Citrix ICA Server
authentication details for communication between the client and Citrix ICA server
time interval between each response check
The General tab contains the following fields:
Name
Specifies a unique profile name.
Connection
Server
Specifies the name or IP address of the Citrix ICA Server.
Published application
Specifies the name of the published application (as it is published on the ICA Server) to be launched through this profile. This field
is optional.
If you use this option:
The probe uses the Browser address (see below) and searches for servers running the published application specified. The Publi
shed application fields on the Application tab will be disabled.
You cannot measure Startup publish application time (this option will be disabled on the Misc tab).
Browser addr.
Defines the address the ICA Client object uses to locate the application or server.
Network protocol
Defines the protocol the ICA Client object uses to locate the application or server.
Valid protocols are:
HTTPonTCP
IPX
NetBIOS
SPX
UDP
Default: HTTPonTCP
Authentication
Username
Specifies user credentials for communication between the client and the Citrix ICA server. You must specify a valid user, password
and domain. The probe uses users, configured in the profiles, to login to the Citrix server.
The user can be a local user on the Citrix server or domain user on the Citrix server.
The users must be part of group Remote Desktop Users on the Citrix server.
The users must be part of group Terminal Server Computers on the Citrix server.
The user must be able to publish the application manually.
Domain
Specifies the domain to use in ICA login.
Password
Defines the password to be used in ICA login. Note that this password must also be entered in the Confirm password field.
Check interval
Check Interval
Specifies the time interval between each response check. Do not overload the Citrix ICA server by checking too often. A minimum
Application Tab

enter the published application that should start immediately after successful login, and / or
select a script to run on the Citrix ICA server.

Start published application
Selecting this option enables the Published application fields for input. Thus, you can select a published application that should start
immediately after the login.
Application
Defines the name of the published application that should start immediately after the login.
Arguments
Provides the argument list for the published application, if any.
Run macro script
Selecting this option enables the Macro script fields for input. Thus, you can select a script to be run on the Citrix ICA Server.
Macro script
Filename
The name of the script to be run. Either specify the name of the script with full path, or use the browse button
to locate the script. Click the Macro recorder button to create your own script.
Start point
Use this drop-down menu to select at which point in the test sequence the macro is started.
The options are:
Before connect
After connect
After login
ICA Client Object version
The probe detects and displays the ICA Client Object version running on the client computer.
Alarms Tab
This tab lists the different alarm situations. You can define the Response properties (for alarm situations related to response time) or Event
properties (for the other alarm situations) for the selected alarm situation.
This dialog contains the following fields:
Response / Event properties
Response properties
Enables you to set the response properties, after selecting an alarm situation related to response time. You can specify/edit the
threshold for the selected alarm situation by right-clicking in the Thresholds window.
The New Threshold dialog lets you select an operand and a threshold value, an alarm message to be issued if the threshold is
breached and a severity level for the alarm message.
You can also select a clear message (and severity level) to be issued when the threshold value is no longer breached.
Event properties
Selecting an alarm situation related to other events than response time, you can set the event properties.
Select an Alarm message to be issued if the selected error situation occurs and a severity level for the alarm message.
Further, select a Clear message (and severity level) to be issued when the alarm situation is cleared.
Client Settings Tab
This tab is used to select whether to use an ICA file or not.

Use ICA file
Select this option if you want to use configuration settings other than as specified in the ica_response probe configuration file. If the
option is not selected, all other fields are grayed out and not active. If selected, you can:
Click Browse to browse for the ICA file you want to use.
You can also select to override certain sections of the ICA file specified:
The address settings.
The authentication settings.
The application settings.
Encryption level
It is used to set the encryption level for the communication between the probe and the server.
Valid options are:

None
Basic
128 bits login only (only login session encrypted)
40 bits
56 bits
128 bits
Misc. Tab
This tab allows you to select which QoS messages to send and timeout values for the different tasks performed by the probe.
Send QoS
Check the QoS values you want to be sent:
Connect time
Logoff time
ICA ping time
Session time
Logon time
Total profile time
Measures time taken for the total operations for the profile.
Gives NULL if:
Connect fails, Logon fails, Macro fails, Published application fails, ICA file fails, Logoff fails, or Session exit fails.
Timeout
Select the timeout values for different tasks performed by the probe. These are:
Connect
Logoff
Session
Publish application
Logon
Macro script
Miscellaneous
Logoff delay
Specify a logoff delay. This is the time the probe waits from the application start command has been executed until starting the logoff
session.
If no application is to be started, the delay is the time from successful login completed until starting the logoff session.
The Message Pool lists all available alarm messages. You can also add, modify, or delete alarm messages.
This list displays the add, edit and delete options on right-clicking. The following screen appears on clicking the New or Edit option.
Name
Specifies the identification name of the alarm message. This name will appear in the pull-down list when selecting an alarm message on
the Alarms tab in the Profiles dialog.
Text
Typing $ in this field, lists all valid variables.
Subsystem
Specifies the ID of the subsystem being the source of this alarm. This id is managed by the nas.
Severity
Specifies the severity of the alarm (clear, information, warning, minor, major or critical).
The Status Tab
The graph displays the total session time for the selected profile. All active profiles are listed below the graph.

This section details a list of all macro functions that can be used by the macro recorder.
Command line format:
Elapsed time;Command;Arg1;Arg2;Arg..
Connect
Arguments
1. Horizontal resolution.
2. Vertical resolution.
Example: 0;Connect;800;600
Disconnect
No arguments
KeyDown
Arguments: see KeySend
KeySend
Arguments
1. Keynumber
Example: 0;KeySend;65
Special key codes:
Shift = 16
Ctrl = 17
Alt = 18
AltGr = 17, 18 (Ctrl + Alt)
Caps Lock = 20
Samples:
Send Abc:
0; KeyDown;16
100;KeySend;65
200;KeyUp;16
300;KeySend;66
400;KeySend;67
//
//
//
//
//
Press shift
a (Down and up)
Release shift
b (Down and up)
c (Down and up)
Send an exclamation (!):
0;KeyDown;16
100;KeySend;49
200;KeyUp;16
// Press shift
// 2
// Release shift
KeyUp
LogOff
No arguments.
MouseDown
Arguments:
1. Button id
2. Modifiers
3. X Position
4. Y Position
Button IDs: 1 - Left, 2 - Right, 4 - Middle.
Modifier = 0.
Example: 0;MouseDown;1;0;200;400
MouseMove
Arguments: See mouse down
MouseUp

Pause
Arguments:
1. Delay in milliseconds.
Example: 0;Pause;1000
WindowActivate
Arguments:
1. Window title
Example: 0;WindowActivate;Calculator
WindowLocation
Arguments:
1. X position
2. Y position
3. Window title
Example: 0;WindowLocation;200;100;Calculator
WindowSize
Arguments:
1. Window width
2. Window height
3. Window title
Example: 0;WindowSize;300;200;Calculator
WindowWait
Arguments:
1. TimeOut in milliseconds.
2. Window title
Example: 0;WindowWait;10000;Calculator
ica_response Version 3.0

This section contains documentation for versions 3.02 and earlier of the ica_response probe:
v3.0 ica_response AC Configuration
v3.0 ica_response IM Configuration
v3.0 ica_response AC Configuration

This section describes the configuration concepts and procedures for setting up the Citrix Client Response Monitoring probe. This probe is
configured to monitor the performance of the Citrix terminal server client connection, launch an application, and run a macro script. The following
diagram outlines the process to configure the probe to connect to the Citrix ICA servers, create a monitoring profile and configure alarms and
QoS.
Contents
Activate Monitors
Record a Macro
Verify that you have installed any one of the following Citrix Client software on the host system.
Citrix Receiver
Web Client Plug-in
Verify that PPM 2.80 or later is running on the primary hub.
Verify that you made the required registry changes
Server.
Note: These registry changes are mandatory for the ICA functionality to work properly.
Follow these steps:

1.
receiver.
Follow these steps:
32-bit Windows:
64-bit Windows:


You can create one or more monitoring profiles for monitoring a specific Citrix server and cater to different monitoring requirements. For example,
one monitoring profile executes application A and monitors the response time; while another monitoring profile executes a macro and monitors the
end user experience of application B.
Follow these steps:
1. Click the ica_response node of the probe.
2. Define user credentials under the General Configuration section. These user credentials are of the host system, where the probe is
deployed. These credentials provide necessary rights to the probe for executing the Citrix receiver client, which is installed on the host
system.
3. Click the Options (icon) next to the ica_response node.
4. Select the Add Profile option.
5. Configure the following properties in the General Profile Configuration dialog:
5.
Connection: specifies the connection type of the profile, if the profile connects to the Citrix server or the published application.
Address: defines the IP address of the Citrix server for the profile to establish connection and capture the monitoring data. This field
specifies the name of the Application if Published Application option is selected in the Connection drop down.
Browser Address: defines the web URL or the IP address of the Citrix server for accessing the hosted application. This option, does
not allow you to define the application separately in the Application Configuration section and enable QoS data for Startup Publish
Application Time monitor.
Username: defines the user name that has appropriate access to the Citrix Server.
Password: defines the password for authenticating the Citrix server user.
Check Interval: defines the time frequency for executing the monitoring profile. Do not overload the Citrix ICA server by checking too
often. A minimum time interval of 15 minutes is recommended.
Check Interval Unit: specifies the measurement unit of Check Interval field value.
6. Click Submit.
The profile appears as a separate node under the ica_response node in the navigation pane.
7. Click Save to update the probe configuration file with the new profile details.
The profile details are saved to probe configuration file and a Monitors node appears under the profile name node in the navigation
pane.
Activate Monitors
After creating a monitoring profile you must activate the required monitors to fetch monitoring data. All these monitors allow you to generate
alarms and generate QoS data when the specified thresholds are breached.
Follow these steps:
2. Select the desired monitor from the Monitors section.
The related fields of the monitors are displayed below the Monitors section.
Note: The Total Profile Time monitor only generates QoS messages. The probe does not generate alarms even if Publish
Alarms is selected.
The probe restarts and reloads the probe GUI. The monitoring profile fetches the monitoring data of the configured monitors for generating alarms
and QoS.
Note: The probe takes considerable time after saving and reloading the configuration, so avoid saving the configuration frequently. The
recommendation is to configure all necessary monitors at once and then save the configuration.
Record a Macro
Macro recording is a functionality that records user actions for playback at a later time. In ica_response, for using the macro recording
functionality, a conf_ica_macro_recording application is provided with the probe. This application is available in the location where the probe is
deployed on your system.
You must first get connected with the ICA Server that you have defined in the selected profile. Once connected, you can open the conf_ica_macr
o_recording application and record the steps to execute certain functionality. These steps can be saved for future references. To enable the
macro recording functionality in the probe, you must enable the Run macro script option in the Macro Configuration section under the Profile
Name node.
Create a Macro Script
Select the Run macro script option in the Macro Configuration section to start using the macro recording functionality to create and save a macro
script.
You can either:
Browse and locate the saved recording from the File option.
Follow these steps to create a new macro script:
1. Select the Run macro script check box in the Macro Configuration section under the Profile Name node.
2. Locate and run the conf_ica_macro_recording application.
The Macro Recorder dialog appears.
3. Click Macro Recorder.
a. Click Connect in the above dialog or click inside the empty window, marked Click here to connect to server to connect you to the
ICA server defined in the selected profile.
The server desktop appears in the window. If the profile is configured to start a published application, the application appears in the
window when started.
After the connection is established, the Connect button gets disabled and Log off gets enabled, in the ICA Macro Script Recorder di
alog.
b. For example, you have to work on Notepad and record a session containing some steps. So, click Start on the desktop that appears
in the window and select the Notepad application.
The Notepad application starts in the window.
c. Click Record to start the recording and start performing the steps.
d. After the required session has been recorded, click Stop in the dialog.
Note: The Record, Play step, and Clear buttons get enabled again. Click Log off to log you off the ICA server and disconnect.
e. Click Save and Exit to save the macro script and exit from the macro recording functionality. The Save macro script dialog appears
which allows you to save the macro script.
f. Enter the name of the recording in the File box and click OK. The macro script gets saved at the selected location with .rec extension.
This location now appears in the Filename text box in the Application tab of the Profiles tab, when you click the ellipsis (...) button.
Edit a Macro Script
To edit a macro script, you must modify the commands listed at the bottom of the application window, while recording the macro script. When you
right-click a command line in the macro script, four options are displayed - New before, New after, Edit and Delete. Select the Edit option to
modify the macro script.
Follow these steps:

The command line format is: Elapsed time;Command;Arg1;Arg2;Arg..
v3.0 ica_response AC GUI Reference

Contents
Probe Interface
ica_response Node
<Profile Name> Node
Monitors Node
Probe Interface
The probe interface is divided into a navigation pane and a details pane. The navigation pane contains a hierarchical representation of the probe
inventory which includes monitoring targets and configurable elements. The details pane usually contains information based on your selection in
ica_response Node
The ica_response node is used to configure the general settings of the Citrix Client Response Monitoring probe, which are applicable to all
monitoring profiles of the probe.
Navigation: ica_response
ica_response > Probe Information
ica_response > General Configuration
This section lets you configure the default log level and other probe-related alarms.
Default: 0 - Fatal
Username: defines the user name having administrator rights on the host system, where the probe is installed. This user can be a
local user or a domain user and must have the appropriate rights to launch ica_response_poll.exe. If you do not enter any value in
these fields, then the exe is launched using the system account.
Password: defines the password of the corresponding user name.
Domain: defines the network domain name of the user.

Maximum Concurrent Sessions: specifies the number of profiles, which the probe can execute simultaneously. Each profile creates a
different session of the given user on the Citrix server.
Default: 5
Maximum Concurrent Sessions Reached Alarm: specifies the alarm message when the maximum number of concurrent sessions
reached.
Default: MaxSessionsReached
Maximum Concurrent Sessions Reached Clear: specifies the clear alarm message when the number of concurrent sessions is less
than maximum concurrent sessions limit.
Default: MaxSessionsOK
Profile Already Running Alarm: specifies the alarm message when the probe attempts to run an already running profile. For example,
a profile runs for a longer session than a monitoring interval and the probe runs the profile again before the previous session is
finished.
Default: ProfileAlreadyRunning
Profile Already Running Clear: specifies the clear alarm message when the profile already running alarm situation is rectified.
Default: ProfileAlreadyRunningOK
ica_response > Message Pool
This section lets you view the alarm message details that are available in the Citrix Client Response Monitoring probe. These alarms are
used for different monitoring parameters of the probe. This section is read-only.
Name identifies the unique name of the alarm message.
Text: identifies text of the alarm message.
Severity: identifies a severity level of the alarm.
<Profile Name> Node
The profile name node defines the monitoring parameters and configures appropriate QoS data and alarms for each profile.
Navigation: ica_response > profile name
profile name > General Profile Configuration
This section defines all the properties of the monitoring profile.
Default: Not selected.
Profile Name: defines a unique name of the profile.
Connection: specifies the connection type of the profile when the profile connects to the Citrix server or the published application.
Default: Server
Address: defines the IP address of the Citrix server for the profile for establishing connection and capture the monitoring data. This field
defines the name of the application if Published Application is selected in the Connection drop-down.
Browser Address: defines the web URL of the Citrix server for accessing the hosted application. This option disables the options for
defining the application separately in the Application Configuration section and enable QoS data for Startup Publish Application
Time monitor.
Default: HTTPonTCP
Username: defines the user name which is having appropriate access to the Citrix Server.
Password: defines the password for authenticating the Citrix Server user.
Check Interval: defines the time frequency for executing the monitoring profile.
Default: 60 Min
Check Interval Unit : defines the check interval unit.
Default: Hours
profile name > Application Configuration
This section defines the application details for monitoring application startup time during server monitoring.
Start Published Application: enables the monitoring profile to execute an application in each monitoring interval.
Application Name: defines the application name for the monitoring profile for executing for monitoring application startup time.
Arguments: defines the argument, which can be required, for the application startup.
Logoff Delay: defines the waiting time before logging off the monitoring session from the Citrix server after completing the monitoring
activities.
Default: 0
profile name > Macro Configuration
This section is used for running the Macro Recorder script on the Citrix ICA server.
Run Macro Script: enables you to run the Macro script on the Citrix ICA server.
File enables you to locate the Macro script to be run on the Citrix ICA server.
Start Point: enables you to select at which point in the test sequence the macro is started. The options are: Before connect, After
connect and After login.
profile name > Client Settings
This section is used for configuring an ICA file which contains setting for connecting to the Citrix server, user authentication details, and
application configuration details. This section is optional.
Use ICA File: enable the probe to fetch necessary Citrix server connection settings from the ICA file.
Filename: defines the ICA file path. You can use the Browse button for navigating to the ICA file.
Override Address Setting in ICA file: overrides the Citrix server address details in the ICA file with the General Profile Configuration sec
tion details.
Override Authentication Setting in ICA file: overrides the user authentication details in the ICA file with the General Profile
Configuration section details.
Override Application Setting in ICA file: overrides the application configuration details in the ICA file with the Application Configuration
section details.
Encryption Level: defines the encryption level for communication between the probe and the Citrix server.
Default: None
Monitors Node
The Monitors node lets you configure QoS data and alarms for the monitoring profile. This node contains a table displaying the list of all monitors.
You can select one or more than one monitor from the list. Then you can activate QoS data and and configure the alarm thresholds and
appropriate error alarm messages for the selected monitor.
Navigation: ica_response > profile name > Monitors
Notes:
Though the Publish Alarms option is visible for the Total Profile Time monitor, only QoS is generated for this monitor.
If the alarms are ON against any QoS, then these alarms are generated based on both Threshold Value fields. Thus, it is
mandatory to provide values for both the thresholds to generate alarms.
v3.0 ica_response IM Configuration

This article describes the configuration concepts and procedures for setting up the ica_response probe. This probe is configured to monitor the
performance of the Citrix terminal server client connection, launch an application, and run a macro script. The following diagram outlines the
process to configure the probe to connect to the Citrix ICA servers, create a monitoring profile and configure alarms and QoS.
Contents
Create Profile
Record a Macro
Verify that you have installed any one of the following Citrix Client software on the host system:
Citrix Receiver
Web Client Plug-in
Verify that you made the required registry changes.
Server.
Important! These registry changes are mandatory for the ICA functionality to work properly.
Follow these steps:

7.
receiver.
Follow these steps:
32-bit Windows:
64-bit Windows:

Create Profile
This section describes the process to create a monitoring profile. You can create one or more monitoring profiles for monitoring a specific Citrix
server and cater to different monitoring requirements. For example, one monitoring profile executes application A and monitors the response time;
while another monitoring profile executes a macro and monitors the end user experience of application B.
Follow these steps:
The contents of the Profiles tab are displayed, by default.
2. Right-click in the profile pane, and click New to create a new profile.
The ICA Profile Properties dialog appears. Specify the values in the following fields:
Name: the name of the profile.
Connection: authentication details such as server IP for communication between the client and Citrix ICA server.
Check Interval: time interval between each response check. Do not overload the Citrix ICA server by checking too often. A minimum
3. Click the Alarms Tab to list the different alarm situations.
Define the Response properties (for alarm situations related to response time) or Event properties (for the other alarm situations) for
the selected alarm situation.
4. Click the Misc. tab. Select the QoS messages that you want to send and the timeout values for the different tasks performed by the
probe.
5. Click OK.
The new monitoring profile is created.
Record a Macro
Macro recording is a functionality that records user actions for playback at a later time.
You must first get connected with the ICA Server which you have defined in the selected profile by clicking Connect or by clicking Click here to
connect to server. Once connected, you can open the required application and record the steps to execute certain functionality. These steps can
be saved for future references. To enable the macro recording functionality in the ica_response probe, you are required to enable the Run macro
script option under the Application tab of the Profiles tab. This action enables the fields in this section and you can start using the macro
recording functionality to create and save a macro script.
You can either:

Browse and locate the saved recording from the Filename option to select the path.
Follow these steps:
1. Select the Run macro script check box.
A warning message is displayed as shown in the following dialog:
2. Click OK.
3. Select the Start point value at which the macro is to be started in the test sequence. Available values are Before connect, After
connect, and After login.
4. Click Macro recorder.
Note: Initially, the main window of the application is empty.
5. Click Connect in this dialog or click on the link Click here to connect to server to connect you to the ICA server defined in the selected
profile.
The server desktop appears. If the profile is configured to start a published application, this application appears in the window, when
started.
After the connection is established, the Connect button gets disabled and Log off gets enabled, in the ICA Macro Script Recorder dialo
g.
6. For example, you have to record a session containing some steps on a Notepad, click Start on the desktop and select the Notepad appli
cation.
The Notepad application appears.
7. Click Record to start the recording and start performing the steps.
8. After the required session has been recorded, click Stop in the dialog.
The Record, Play step, and Clear buttons get enabled again. Click Log off to log you off the ICA server and disconnect.
9. Click Save and Exit to save the macro script and exit from the macro recording functionality.
The Save macro script dialog appears which allows you to save the macro script.
10. Enter the name of the recording in the File box and click OK.
The macro script gets saved at the selected location with .rec extension.
Note: This location appears in the Filename text box in the Application tab of the Profiles tab.
Edit a Macro Script
To edit a macro script, you need to modify the commands listed at the bottom of the application window, while recording the macro script. When
you right-click a command line in the macro script, four options are displayed - New before, New after, Edit and Delete.
You can, then, select the Edit option to modify the macro script.
Follow these steps:
Notes:
The command line format is: Elapsed time;Command;Arg1;Arg2;Arg.. See the section Macro Functions Overview for a
description of the commands and arguments available.
v3.0 ica_response IM GUI Reference

This article describes the fields and features of the ica_response probe.
Contents
General Tab
Profiles Tab
General Tab
Application Tab
Alarms Tab
Client Settings Tab
Misc. Tab
The Status Tab
General Tab

specify the user name and password that are used by the probe to access its folder on local machine.
specify maximum number of sessions that can run simultaneously
set the level of details written to the log file, and
specify alarms to generate when maximum concurrent sessions are reached and an already running profile is again run by the probe
ICA Client User
This is the user name and password the probe uses to access its folder on the local machine (Program
Files/Nimsoft/Probes/application/ica_response).
This user can be a local user or a domain user and must have the appropriate rights to launch ica_response_poll.exe. If you do not enter
any value in these fields, then the exe is launched using the system account.
Note: The ica_response_poll.exe is a child exe for each profile that is created by the user. For example, if the user creates four
profiles, then, there will be one ica_response.exe file in the probe installation directory and four ica_response_poll.exe files in
that directory.
Alarms
Maximum concurrent sessions reached
Select the alarm message to be issued when the probe exceeds the maximum number of concurrent sessions. You can also select
the Clear message to be issued when the number of concurrent sessions is below the maximum threshold.
Select the alarm message to be issued if the probe attempts to run a profile that is already running. This happens when the profile
runs a long session, and the check interval instructs the probe to run the profile again before the previous session is finished.
Also select the Clear message to be issued when the alarm situation is cleared.
Maximum concurrent sessions
Specifies the maximum number of sessions (profiles) allowed running simultaneously.
Log Level
Profiles Tab
This tab lists all the configured profiles and is used to add, modify, copy, or delete a profile. When you add or modify a profile, the Profile
Properties dialog is displayed with tabs - General, Application, Alarms, Client Settings, and Miscellaneous where you need to enter/select
the required information associated with the profile. Each entry in the Profiles list defines a monitoring profile for one Citrix ICA server logon/logoff
connection. The check boxes beside the active profiles are shown as selected. In order to define a valid profile, login user/password credentials
are mandatory. The password is encrypted in the probe configuration file.
Note: You must use different login users for different profiles defined to avoid conflicts if unexpected disconnects occur.
The following commands are available when you right-click in the profile pane:
New
Enables you to create a new profile by displaying the ICA Profile Properties dialog.
Edit
Enables you to edit profile properties for the selected profile by displaying the ICA Profile Properties dialog
Copy
Makes a copy of the selected profile. The Profile Properties dialog appears with all the properties copied from the selected profile.
Rename the copied profile and click the OK button.
Delete
Deletes the selected profile. A confirmation dialog is displayed for the deletion.
When you select the New or Edit option as explained above, the ICA Profile Properties dialog appears. This dialog has five tabs - General, App
lication, Alarms, Client Settings and, Misc. All these tabs are explained in the subsequent topics.
General Tab
This tab is used to specify:
the name or IP address of the Citrix ICA Server
authentication details for communication between the client and Citrix ICA server
time interval between each response check
The General tab contains the following fields:
Name
Specifies a unique profile name.
Connection
Server
Specifies the name or IP address of the Citrix ICA Server.
Specifies the name of the published application (as it is published on the ICA Server) to be launched through this profile. This field
is optional.
If you use this option:
The probe uses the Browser address (see below) and searches for servers running the published application specified. The Publi
shed application fields on the Application tab will be disabled.
You cannot measure Startup publish application time (this option will be disabled on the Misc tab).
Browser addr.
Defines the address the ICA Client object uses to locate the application or server.
Network protocol
Defines the protocol the ICA Client object uses to locate the application or server.
Valid protocols are:
HTTPonTCP
IPX
NetBIOS
SPX
UDP
Default: HTTPonTCP
Authentication
Username
Specifies user credentials for communication between the client and the Citrix ICA server. You must specify a valid user, password
and domain. The probe uses users, configured in the profiles, to login to the Citrix server.
The user can be a local user on the Citrix server or domain user on the Citrix server.
The users must be part of group Remote Desktop Users on the Citrix server.
The users must be part of group Terminal Server Computers on the Citrix server.
The user must be able to publish the application manually.
Domain
Specifies the domain to use in ICA login.
Password
Defines the password to be used in ICA login. Note that this password must also be entered in the Confirm password field.
Check interval
Check Interval
Specifies the time interval between each response check. Do not overload the Citrix ICA server by checking too often. A minimum
Application Tab
enter the published application that should start immediately after successful login, and / or
select a script to run on the Citrix ICA server.
Start published application
Selecting this option enables the Published application fields for input. Thus, you can select a published application that should start
immediately after the login.
Application
Defines the name of the published application that should start immediately after the login.
Arguments
Provides the argument list for the published application, if any.
Run macro script
Selecting this option enables the Macro script fields for input. Thus, you can select a script to be run on the Citrix ICA Server.
Macro script
Filename
The name of the script to be run. Either specify the name of the script with full path, or use the browse button
to locate the script. Click the Macro recorder button to create your own script.
Start point
Use this drop-down menu to select at which point in the test sequence the macro is started.
The options are:
Before connect
After connect
After login
ICA Client Object version
The probe detects and displays the ICA Client Object version running on the client computer.
Alarms Tab
This tab lists the different alarm situations. You can define the Response properties (for alarm situations related to response time) or Event
properties (for the other alarm situations) for the selected alarm situation.
This dialog contains the following fields:
Response / Event properties
Response properties
Enables you to set the response properties, after selecting an alarm situation related to response time. You can specify/edit the
threshold for the selected alarm situation by right-clicking in the Thresholds window.
The New Threshold dialog lets you select an operand and a threshold value, an alarm message to be issued if the threshold is
breached and a severity level for the alarm message.
You can also select a clear message (and severity level) to be issued when the threshold value is no longer breached.
Event properties
Selecting an alarm situation related to other events than response time, you can set the event properties.
Select an Alarm message to be issued if the selected error situation occurs and a severity level for the alarm message.
Further, select a Clear message (and severity level) to be issued when the alarm situation is cleared.
Client Settings Tab
This tab is used to select whether to use an ICA file or not.
Use ICA file
Select this option if you want to use configuration settings other than as specified in the ica_response probe configuration file. If the
option is not selected, all other fields are grayed out and not active. If selected, you can:
Click Browse to browse for the ICA file you want to use.
You can also select to override certain sections of the ICA file specified:
The address settings.
The authentication settings.
The application settings.
Encryption level
It is used to set the encryption level for the communication between the probe and the server.
Valid options are:
None
Basic
128 bits login only (only login session encrypted)
40 bits
56 bits
128 bits
Misc. Tab
This tab allows you to select which QoS messages to send and timeout values for the different tasks performed by the probe.
Send QoS
Check the QoS values you want to be sent:
Connect time
Logoff time
ICA ping time
Session time
Logon time
Total profile time
Measures time taken for the total operations for the profile.
Gives NULL if:
Connect fails, Logon fails, Macro fails, Published application fails, ICA file fails, Logoff fails, or Session exit fails.
Timeout
Select the timeout values for different tasks performed by the probe. These are:
Connect
Logoff
Session
Publish application
Logon
Macro script
Miscellaneous
Logoff delay
Specify a logoff delay. This is the time the probe waits from the application start command has been executed until starting the logoff
session.
If no application is to be started, the delay is the time from successful login completed until starting the logoff session.
The Message Pool lists all available alarm messages. You can also add, modify, or delete alarm messages.
This list displays the add, edit and delete options on right-clicking. The following screen appears on clicking the New or Edit option.
Name
Specifies the identification name of the alarm message. This name will appear in the pull-down list when selecting an alarm message on
the Alarms tab in the Profiles dialog.
Text
Typing $ in this field, lists all valid variables.
Subsystem
Specifies the ID of the subsystem being the source of this alarm. This id is managed by the nas.
Severity
Specifies the severity of the alarm (clear, information, warning, minor, major or critical).
The Status Tab
The graph displays the total session time for the selected profile. All active profiles are listed below the graph.
This section details a list of all macro functions that can be used by the macro recorder.
Command line format:
Elapsed time;Command;Arg1;Arg2;Arg..
Connect
Arguments
1. Horizontal resolution.
2. Vertical resolution.
Example: 0;Connect;800;600
Disconnect
No arguments
KeyDown

KeySend
Arguments
1. Keynumber
Example: 0;KeySend;65
Special key codes:
Shift = 16
Ctrl = 17
Alt = 18
AltGr = 17, 18 (Ctrl + Alt)
Caps Lock = 20
Samples:
Send Abc:
0; KeyDown;16
100;KeySend;65
200;KeyUp;16
300;KeySend;66
400;KeySend;67
//
//
//
//
//
Press shift
a (Down and up)
Release shift
b (Down and up)
c (Down and up)
Send an exclamation (!):
0;KeyDown;16
100;KeySend;49
200;KeyUp;16
// Press shift
// 2
// Release shift
KeyUp
LogOff
No arguments.
MouseDown
Arguments:
1. Button id
2. Modifiers
3. X Position
4. Y Position
Button IDs: 1 - Left, 2 - Right, 4 - Middle.
Modifier = 0.
Example: 0;MouseDown;1;0;200;400
MouseMove
MouseUp
Pause
Arguments:
1. Delay in milliseconds.
Example: 0;Pause;1000
WindowActivate
Arguments:
1. Window title
Example: 0;WindowActivate;Calculator
WindowLocation
Arguments:
1. X position
2. Y position
3. Window title
Example: 0;WindowLocation;200;100;Calculator
WindowSize
Arguments:
1. Window width
2. Window height
3. Window title
Example: 0;WindowSize;300;200;Calculator
WindowWait
Arguments:
1. TimeOut in milliseconds.
2. Window title
Example: 0;WindowWait;10000;Calculator
ica_response Metrics
This section describes the metrics that can be configured for the Citrix Client Response Monitoring (ica_response) probe.
Contents
QoS Metrics
QoS Metrics
The following table describes the checkpoint metrics that can be configured using the ica_response probe.
Monitor Name
Units
Description
Version
QOS_ICA_CONNECT
Milliseconds
Monitor the time taken to connect to the ICA server.
v3.0
QOS_ICA_LOGON
Milliseconds
Monitor the time taken to log on the ICA server.
v3.0
QOS_ICA_MACRO
Milliseconds
Monitor the time taken to execute the recorded script.
v3.0
QOS_ICA_LOGOFF
Milliseconds
Monitor the time taken to log off the ICA server.
v3.0
QOS_ICA_PING
Milliseconds
Monitor the time to wait for a response on an ICA ping.
v3.0
QOS_ICA_APPLICATION
Milliseconds
Monitor the time taken to measure Startup publish application.
v3.0
QOS_ICA_TOTAL
Milliseconds
Monitor total profile time.
v3.0
QOS_ICA_SESSION
Milliseconds
Monitor session from start connect to disconnect again from the server.
v3.0

This section contains the alert metric default settings for the ica_response probe.
QoS Metric
Warning Threshold
Warning Severity
Error Threshold
Error Severity
Description
ConnectFailed
None
None
None
Critical
Connect to $address failed
ConnectionDisconnected
None
None
None
Critical
Connection disconnected
ConnectionTimeout
None
None
None
Critical
Connection timed out
ConnectResponseHigh
None
None
None
Critical
Connect response time too long
IcaFileFailed
None
None
None
Critical
Read ICA file failed
LogoffFailed
None
None
None
Critical
Logoff failed
LogoffResponseHigh
None
None
None
Critical
Logoff response time too long
LogonFailed
None
None
None
Critical
Logon failed
LogonResponseHigh
None
None
None
Critical
Logon response time too long
LogonTimeout
None
None
None
Critical
Logon timed out
Macro Failed
None
None
None
Critical
The Macro Recording Script failed
Macro Time Out
None
None
None
Critical
The Macro response timed out.
MaxSessionsReached
None
None
None
Critical
Maximum concurrent sessions limit reached
ProfileAlreadyRunning
None
None
None
Critical
PublishedAppFailed
None
None
None
Critical
Published application failed
PublishedAppResponseHigh
None
None
None
Critical
Published application response time too long
PublishedAppTimeOut
None
None
None
Critical
Published application timed out
SessionResponseHigh
None
None
None
Critical
Session response time too long
SessionTimeOut
None
None
None
Critical
Session timed out
icmp (Internet Control Message Protocol)

The Internet Control Message Protocol (icmp) is an internet-standard protocol used to collect response time, service availability, and packet loss
information for network devices, such as routers, on an IP network. The icmp probe collects this information by sending ICMP echo requests at
user-defined intervals, and waiting for the network device to return an ICMP echo response. The echo response should contain the complete
ICMP message from the echo request when the echo request does not encounter any network issues. If an error condition is encountered, such
as the router identified in the echo request is unreachable, the echo response returns with an ICMP error in the packet. If ping has been disabled
on a device, the icmp probe generates an unreachable Q0S message.
The icmp probe generates QoS messages based on the following response data:
Average Response Time (Default Monitor)
Maximum Response Time
Minimum Response Time
Successful Attempts
Failed Attempts
Percentage of Packet Loss (Default Monitor)
Service Availability (Default Monitor)
You can deploy the icmp probe to any robot where the ppm v3.0 or later probe is running. Configure the icmp probe using only Admin Console.
This probe can monitor up to 50,000 resources in about 5 minutes. Use the Verify Filter option in the ICMP GUI to filter the resources displayed
in the navigation pane, as it is limited to displaying up to 255 resources at a time. The alarms generated from the icmp probe are displayed in
Infrastructure Manager, in reports displayed in CA Unified Management Portal (UMP), or from the Metrics tab in Unified Service Manager.
More Information:
icmp (Internet Control Message Protocol) Release Notes
v1.2 icmp AC Configuration

This article describes how to configure the icmp probe to collect QoS metrics.
Before configuring the icmp probe, verify that required software and information is available.
Follow these steps:
1. Determine the path to the primary hub. See the Discovery Server topic for details.
2. Verify in Admin Console that the following probes are installed and running:
CA Unified Infrastructure Management discovery_server is running on the primary hub
ppm v3.0 probe is running on each hub with a robot running the icmp probe
alarm_enrichment v4.6 and nas v4.6 probes are running on each hub with a robot running the icmp probe
prediction_engine v1.0 or later is running on each hub with a robot running the icmp probe
3. Verify CA Unified Management Portal (UMP) is running on a hub if you want to look at metrics and alarms in UMP
4. Have the following information:
IP address for UMP
Login credentials for UMP
Path to your CA Unified Infrastructure Management primary hub
The following diagram shows the tasks you complete to configure monitoring devices to collect QoS data for availability, response time, and
packet loss for network devices.
Contents
Discovery of Network Devices
Configure icmp Probe Settings
Apply a Monitoring Configuration with the Probe Configuration GUI
Test the Connection to a Device
Add Discovery Filters
Manually Update Discovery
Filter the Number of Device Profiles Displayed
Discovery of Network Devices

Before you configure the icmp probe settings or create a template, it's recommended to run the Discover Wizard from the CA Unified
Management Portal (UMP) to discover the IP devices in your network. Use the Scopes tab in the wizard to discover devices based on network
seed devices, addresses, ranges, or masks to reduce the number of devices discovered. The Schedule tab lets you run discovery immediately or
schedule discovery for a convenient time.
Follow these steps:
1. Enter the address for UMP in your browser, and then log in.
2. If this is the first time you are logging in to UMP, the Discovery Wizard may be displayed.
If the Discovery Wizard is not displayed, you see the Unified Service Manager (USM) portlet. Select Actions > Discovery Wizard.
3. Click the Scopes tab.
4. Click New range scope or New seed scope.
4.
Note: When you enter a subnet mask, the number of IP addresses the mask represents is displayed (the number of effective
hosts minus two). Only /16 subnets or smaller are supported.
5. Enter a scope name and an address, range, or mask.

6. Click the Schedule tab and select the appropriate options.
7. Click Finish to run discovery.
See the Define Scopes article on the CA Unified Infrastructure Management Wiki for more details about using the Scope tab.
Configure icmp Probe Settings

Initially, you can use the icmp probe GUI to configure the general settings, such as the level of messages to collect for the log. These settings
apply to the individual probe you are configuring. The settings in templates you create override the settings in the probe configuration GUI.
1. In the Admin Console navigation pane, click the down arrow next to the hub, then the robot the icmp probe resides on.
2. Click the down arrow next to the icmp probe, and select Configure.
3. Select a log level to specify the level of alarms to be captured in the log file.
4. Select Timeout, Number of Packets, Delay Between Packets, and Interval in Seconds values for the ICMP echo request packet.
See the icmp Node section for information about these settings.
5. Enter the maximum Buffer Size (in bits) for the ICMP buffer on the robot where the icmp probe resides.
6. Select Hostname, IP address, or Robot as the override source. The selected override source overrides the default QoS source (robot)
with the provided value.
All modifications are written to the configuration file and the icmp probe uses the new configuration. QoS messages are generated only for the
devices listed in the icmp tree that have the Publish Data option selected in the profiles.
Apply a Monitoring Configuration with the Probe Configuration GUI

You can use the probe configuration GUI to apply a monitoring configuration to a few devices. Use the following tasks to test a monitoring
configuration on a few devices. When you are satisfied with a monitoring configuration, create a template to apply the configuration across your
environment. For more information about templates, see the Create a Template section.
Follow these steps:
1. Go to icmp > Options (...) > Add New Profile.
2. Enter a hostname (or IP address), an Interval for sending an echo packet, and the ICMP buffer size.
Note: Do not select the Active check box until you want the probe to begin monitoring a device.
3. Click Submit, then click Save.

While the probe creates the device's profile, a pending message appears.
4. When the profile is created, go to icmp > device > device profile.
Information about metrics and thresholds for the host appear in the details pane.
5. Do one of the following steps:
To turn data collection off for a QoS metric, click a monitor name in the table, and then clear the Publish Data box.
To turn data collection on for a QoS metric, click a monitor name in the table, and then select the Publish Data box.
Note: For additional information about threshold settings, see Configuring Alarm Thresholds.
6. Go to icmp > device and select the Active check box.
7. Save your change.

The icmp probe starts monitoring the device based on the associated configured profile.
Test the Connection to a Device

After you add a resource to the icmp tree, you can test the connection to the device.
Follow these steps:
1. Go to icmp > device.
2. Click Actions > Test Connection.
The probes sends an echo request to the device. If the device is reachable, a Success message is displayed.
Add Discovery Filters

You can configure Discovery Filters to restrict the number of devices you receive from Discovery Server. You can use one or more of these filters
to control the list of available monitoring targets that appear under the icmp node when you manually query the discovery server.
Important! Add filters before you manually update discovery. The probe only applies templates to new devices.
1. In the probe configuration GUI, click the Discovery Filters node.

2. Enter information in one or more filters to restrict the number of devices.
The following filters are available:
Discovery Server - Filter devices by discovery server path. The path must be the complete path, following the pattern /<domain>/<hub
>/<robot>/discovery_server. The Discovery Server field only accepts a discovery server path. You cannot enter an IP address or host
name.
Note: If a discovery_server path is not specified, the icmp probe will assume that the discovery_server and the probe are
running on the same robot.
Discovery Scopes - Filter devices by IP address (1.2.3.4), IP range (1.2.3.0-100), or subnet mask (1.2.3.0/24).
Discovery Agents - Filter devices by the agent address, robot with the agent, or IP address of the robot with the agent. The agent
address must be the complete path, following the pattern /<domain>/<hub>/<robot>/discovery_agent.
Discovery Origins - Filter devices by origin. The origin is a name that is assigned to QoS data from probes to identify the origin of the
data. If you are an MSP, for example, typically the origin is the name of each customer. For enterprise customers, typically the hub
name is used.
Note: When you add information to a discovery scope, discovery agent, or discovery origins filter, the data entry field
appears below the filter table. Click New to add more rows to the table.
3. Click Save. The filters are active the next time you select icmp node > Options > Query Discover Server.
Manually Update Discovery

After you set up Scopes and Schedule in the UMP Discovery Wizard, CA Unified Infrastructure Management automatically discovers your IP
devices. You can manually run discovery to add resource profiles to the probe. You might also want to manually run discovery if you made
changes to a device and you want to confirm that those changes are updated in the probe GUI.
After the discovery process is complete, a profile for each device is listed under the icmp node.
Follow these steps:
1. In the probe configuration GUI, click icmp node > Options > Query Discover Server.
Device discovery is launched. When discovery is complete, a Success dialog is displayed. This process can take some time when your
1.
devices are first discovered.
Note: If icmp templates have been activated and saved, settings configured in the templates are applied to the filtered devices.
2. Click Reload to refresh your screen. A profile for each device is listed under the icmp node. The profile icon indicates the status of the
subcomponent discovery.
Filter the Number of Device Profiles Displayed

The navigation pane in the icmp GUI can display up to 255 resources at one time. Use the Profile Filtering option to display resources that match
the address or regex (regular expression) you enter. The first 255 resources that match the filter criteria display.
Follow these steps:
1. In the Profile Filtering field, enter an address or regex.
You can enter an asterisk as a wildcard but Java regular expressions are not accepted.
2. Click Actions > Verify Filter to view the number of resources that match the specified filter value.
v1.2 icmp Applying Monitoring with Templates

This article describes how Admin Console users can use a template to apply a monitoring configuration to multiple devices.
Note: Wait for the component discovery process to complete before you create a monitoring configuration. Some QoS metrics are only
applied to components on specific devices. Determine what device types exist in your environment before applying a monitoring
configuration.
Contents
Using the Template Editor

Create a Template
Using Filters
Configure Host Filter Template Settings
Configure ICMP Filter Template Settings
Activate a Template
Apply a Template
Using the Template Editor

Use the template editor to create monitoring configuration templates. You can configure monitoring on many targets with a well-defined template.
Templates reduce the time that you need for manual configuration and provide consistent monitoring across the devices in your network.
You can create multiple templates to define unique monitoring configurations for all devices and groups of target devices in your environment. The
monitor settings in a template override any monitor settings in the probe configuration.
When creating templates, review the following considerations:
It is recommended to leave all Active check boxes unselected until you have finished configuring all the host and icmp filter settings.
Selecting the Include in Template check box lets you configure the Resource Setup, Monitoring, and Probe Setup parameters.
Go to icmp > Template Editor > template name > Host node > Host node filter and select the Active check box in the Resource
Setup section. When you save your changes, the probe updates all profiles with these settings.
When you want to begin monitoring devices, go to icmp > Template Editor > template name, select the Active check box, and save
your changes. When you select icmp > Query Discovery Server, the template settings are applied to all newly discovered devices that
meet the rules specified with Discovery Filters.
Note: The icmp probe stops monitoring discovered devices when the Active check box for the Resource Settings is not
selected.
Click Discard to discard all changes that have not been saved.
Click Save to save all your changes.
You can create several filters for a single template. The precedence setting determines which filter applies to a device.
For each template, there must be at least one host filter and one icmp filter. The system displays an error message if a host filter or icmp
filter does not exist for a template.
Create a Template
When you create a template, you also configure host filters and icmp filters as part of the template.
Follow these steps:
1. Go to the icmp GUI and click Template Editor.
4. (Optional) Determine if you must modify the default precedence setting.
Precedence controls the order of template application. The lower the precedence number, the higher the priority. The probe applies a
template with a precedence of 1 after a template with a precedence of 2. If there are any overlapping configurations between the two
templates, then the settings in the template with a precedence of 1 overrides the settings in the other template. If the precedence
numbers are equal, then the templates are applied in alphabetical order.
Note: Do not select the Active check box for the template until after you have configured template monitoring filters or rules.
5. Click Submit.
The system creates a template that you can configure. The hierarchical structure within a template is host filters, then icmp filters.
6. Click Save.
The template settings are saved. Configure the host filter and the icmp filter settings before you activate the template. The template is not
activated until you select the Active check box and click Save.
Using Filters
A filter allows you to control which network devices are associated with a particular template. You specify additional device criteria by using rules.
within a group of systems or reduce the set of devices that are monitored by the probe. For example, you can add a rule to apply a monitoring
configuration to all devices with the IPV4 address that contains 1.1.1.1. Or you can add a rule to apply the monitor SuccessfulAttempts to all
devices with the Label <host name>.
Note: If no rules exist, the probe always applies the monitoring configuration in an active template to all applicable devices.
Configure Host Filter Template Settings
When you create a template, a Host Auto Filter for monitoring settings appears as a template node. You can modify the settings in the Host Auto
Filter or copy the Auto Filter to keep the original as a default filter. The Host Auto Filter contains the icmp and monitoring parameters and lets you
add rules to indicate which network devices will be configured with these settings.
Follow these steps:

1. In the template editor, under the template you created, click the Host node > Options (...) > Create Filter to create a new filter.
You can also click Host Auto Filter node > Options (...) > Copy to create a copy of the default host auto filter.
2. Enter a unique filter name and select a precedence.
Note: The precedence in the Auto Filter is set to zero (highest precedence) by default. Remember to change the precedence in
the Auto Filter to a higher number to allow the filters you're creating to be applied to devices.
3. Click Submit.
4. Open the filter you just created or copied.
5. In the Rules section click New.
6. Configure one or more rules to indicate which devices will use these monitoring settings.
Label - Devices that match the label (or component name).
Condition - Options include contains, does not contain, ends with, equals, not equals, regex (regular expression), and starts with.
Value - A value that applies to the Label and Condition.
7. In the Resource Setup section, click Include in Template to include the resource settings in the template.
Uncheck this option to exclude these settings from the template.
8. Enter values for the Interval and ICMP Buffer Size parameters.
These settings pertain to the robot where the icmp probe resides.
9. Click a QoS metric in the Monitors table.
10. To configure the monitoring settings, select Include in Template.
11. For the selected monitor, select the Publish Data, Publish Alarms, and Compute Baseline check boxes to allow baselines to be
computed and QoS data and alarms to be displayed in UMP or Infrastructure Manager.
12. Select and configure alarm thresholds for the selected metric. See Configuring Alarm Thresholds for details.
You can return to this filter at a later time and activate the Resource settings (by selecting the Active check box) when you want the probe to
apply these settings to discovered targets.
Configure ICMP Filter Template Settings
When you create a template, an icmp Auto Filter for probe-specific settings appears as a template node. You can modify the settings in the icmp
Auto Filter or copy the Auto Filter to keep the original as a default filter. The icmp Auto Filter contains the icmp parameters and lets you add rules
to indicate which network devices will be configured with these settings.
Follow these steps:
1. In the template editor, under the template you created, click the icmp node > Options (...) > Create Filter to create a new filter.
You can also click icmp Auto Filter node > Options (...) > Copy to create a copy of the default host auto filter.
2. Enter a unique filter name and select a precedence.
Note: The precedence in the Auto Filter is set to zero (highest precedence) by default. Remember to change the precedence in
the Auto Filter to a higher number to allow the filters you're creating to be applied to devices.
3. Click Submit.
4. Open the filter you just created or copied.
5. In the Rules section click New.
6. Configure one or more rules to indicate which devices will use these icmp settings.
Label - Devices that match the label (or component name).
Condition - Options include contains, does not contain, ends with, equals, not equals, regex (regular expression), and starts with.
Value - A value that applies to the Label and Condition.
7.
7. Select Include in Template.

8. Configure the icmp settings. See the icmp Probe GUI Reference v1.2 for details.
Activate a Template
The probe does not automatically apply the template monitoring configuration. The probe only applies templates that are in an active state. The
template icon in the navigation pane indicates the state of the template. Mouse over the icon to see the state (Inactive or Active).
Follow these steps:

1. Go to icmp > Template Editor > template name and select the Active check box.
2. Save your change.
Apply a Template
You can apply activated templates to newly discovered devices.
1. Access the icmp GUI.
2. Go to icmp > Template Editor > template name > Host > host filter and verify that the precedence, rules, resource setup, and
monitoring settings are appropriate for the devices to which you want to apply the template. Then close the template editor.
3. Go to icmp > Discovery Filters and verify the discovery filtering settings are correct.
4. Select icmp > Options (...) > Query Discovery Server.
A Response dialog appears indicating the number of devices that match the rules configured with Discovery Filters.
5. Close the Response dialog.
6. Refresh the browser.
The newly discovered devices appear underneath the icmp node in the navigation pane. The template is applied to all newly discovered
devices.
After the template has been applied you see a display panel containing links to the template and template filter used to configure a device.
v1.2 icmp Configure Alarm Thresholds

Alarm Thresholds
allow the probe to:
v1.2 icmp AC GUI Reference
This article explains the configuration information and options available through the Admin Console icmp configuration GUI and the Raw
Configure menu option.
Probe Interface
icmp Node
Device Profile
Resource Setup
Device Monitors
Discovery Filters Node
Template Editor
<Template Name> Node
Host Filters Node
<Host Filter> Node
ICMP Filters Node
<icmp> Node
Probe Interface
The probe interface is divided into a navigation pane and a details pane. The left navigation pane contains a hierarchical representation of the
probe inventory which includes monitoring targets and configurable elements. The right details pane usually contains information that is based on
your selection in the navigation pane.
icmp Node
Navigation: icmp
This section lets you view probe information, change the probe setup values, apply a filter to limit the number of devices that appear in the
navigation tree, discover devices based on entered attributes, and create a template to bulk configure icmp attributes for monitored devices.
Probe Information
Probe Setup
Log Level: Sets the amount of detail that is logged to the log file. The default is 1-Error.
Timeout (sec): The time limit for a device to send an ICMP echo response. If this time limit is exceeded, the ICMP echo response
contains an error code. The default is 2 seconds.
Number of Packets: The number of packets sent in an ICMP echo request. The default is 3 packets.
Delay Between Packets The number of milliseconds to wait before sending another packet. The default is 1000 milliseconds.
Buffer Size: Maximum size, in bits, of the ICMP buffer. The default is 64 bits.
Interval in Seconds: Time interval between each ICMP echo request. The default is 600 seconds.
Override Source: Overrides the default QoS source with the provided value. Values include Robot, Hostname, and IP. The default
value for the QoS source is Robot where the probe is deployed.
Note: If you change the Override Source field after the initial configuration, multiple graphs display on the Unified Service
Management (USM) Metrics view (one for every QoS source value).
Profile Filtering
The value in the Filter Criteria field is used to limit the number of resources displayed in the navigation pane.
icmp > Actions > Verify Filter
Filter Criteria: Enter the complete IP address or use regex (regular expressions) patterns. You cannot enter a range (for example
10.1.1.1-9). Instead, to achieve the same results as entering a range, use 10.1.1.[1-9]{1}$.
Additional examples include:
10.*: this is equal to 10.*.*.*

*.10: this is equal to *.10.*.*
Where: * (asterisk) refers to any value between 0 and 255. Only an asterisk is accepted as a wildcard. For example, *.*.*.10 fetches
all resources with IP address (1 to 255).(1 to 255).(1 to 255).10.
Note: By default, the first 255 resources are visible under the icmp node in the navigation pane.
icmp > Add New Profile

Select this option to manually add a new profile (device) to the navigation pane. See Device Profile for details.
icmp > Query Discovery Server
Discovers IP devices in your environment and applies activated templates to the discovered IP devices. When device discovery is
completed, a Success dialog is displayed. Click Reload to refresh your screen.
Device Profile
Navigation: icmp node > Options > Add New Profile
This section lets you create a profile for monitoring a specific device. This profile is displayed as a child node in the icmp tree.
Resource Setup
Navigation: icmp node > device profile

Hostname: Defines the resource host name or IP address.
Note: The probe resolves a host name of a resource to its IP address.
Active: Uses the interval and ICMP buffer size settings for the resource specified in the Hostname parameter.
Interval in Seconds: The time interval between each ICMP echo request. The default is 600 seconds.
ICMP Buffer Size: Maximum size, in bits, of the ICMP buffer. The default is 64 bits.
icmp > device profile > Action > Test Connection
Select this option to determine if a device is reachable. A Success dialog displays to indicate the probe successfully received a response
from the device.
icmp > device profile > Option (...) > Delete Profile
Select this option to delete a device profile.
Device Monitors
Navigation: icmp node > device profile > device

Manage data collection for QoS monitors. Fields to know:
QoS Name: The name to be used on the QoS message issued. This field is read-only.
Description: Information describing the metric. This field is read-only.
Metric Type: Identifies a unique id of the QoS. This field is read-only.
Units: Unit for the QoS metric measurement. This field is read-only.
Publish Data: Select this option if you want to turn on data collection for a QoS monitor.
Publish Alarms: Select this option if you want to turn on alarms for a QoS monitor.
Compute Baseline: Select this option to enable thresholds. This option might not be available depending on your CA Unified
Infrastructure Management configuration.
Dynamic Alarm, Static Alarm, Time Over Threshold Alarm, Time To Threshold Alarm. For more information, see Configuring Alarm
Thresholds.
Discovery Filters Node

Navigation: snmpcollector > Discovery Filters
The Discovery Filters node contains filters that you can configure to restrict the number of devices you receive from Discovery Server. You can
use one or more of these filters to control the list of available monitoring targets that appear under the Profiles node when you query the discovery
server.
Discovery Filters > Discovery Server
Restrict device discovery by discovery server path. Filter devices by discovery server path. The path must be the complete path, following
the pattern /<domain>/<hub>/<robot>/discovery_server.
Discovery Filters > Discovery Scopes
Restrict device discovery by IP address (1.2.3.4), IP range (1.2.3.0-100), or subnet mask (1.2.3.0/24). Click New or Delete to add or
remove a filter in the table.
Discovery Filters > Discovery Agents
Restrict device discovery by Discovery Agent name. Click New or Delete to add or remove a filter in the table.
Discovery Filters > Discovery Origins
Restrict device discovery by origin. The origin is a name that is assigned to QoS data from probes to identify the origin of the data. If you
are an MSP, for example, typically the origin is the name of each customer. For enterprise customers, typically the hub name is used. Click
New or Delete to add or remove a filter in the table.
Template Editor
Navigation: icmp > Template Editor
The template editor allows you to create monitoring and icmp configuration templates with filters and filter rules.
Template Editor > icmp probe > Options (...) > Create Template
Fields to know:
Template Name: A meaningful name for the template
Description: Text description of the template
Precedence: A number that indicates the order of template application by the probe. The lower the precedence number, the higher the
priority. If the precedence numbers are equal, then the templates are applied in alphabetical order.
Active: Indicates the template state.
<Template Name> Node
Navigation: Template Editor > icmp probe > template name

The template node contains the template configuration.
template name > Template
View or modify the template configuration. Fields to know:
Template Name: A meaningful name for the template
Description: Text description of the template
Precedence: A number that indicates the order of template application by the probe. The lower the precedence number, the higher the
priority. If the precedence numbers are equal, then the templates are applied in alphabetical order.
Active: Indicates the template state.
template name > Options (...)

Available options:
Copy - Click to create a new template with a configuration that is similar to a preexisting template.
Delete Template - Click to permanently remove a template.
Host Filters Node
Navigation: Template Editor > icmp probe > template name > Host Filters
An organizational node in the template tree. This node contains the device filters for the probe monitoring profile.
icmp probe > template name > Host > Options (...) > Create Filter
Click to add a new device filter to a template. Fields to know:
Filter Name: A meaningful name for the filter
Precedence: A number that indicates the order of filter application by the probe. The lower the precedence number, the higher the
priority. If the precedence numbers are equal, then the template filters are applied in alphabetical order.
<Host Filter> Node
Navigation: Template Editor > icmp probe > template name > Host Filters > device filter
Device filters apply monitoring configurations that are based on the attributes of target devices. Multiple filters can exist for a device.
host filter > Filter
View or modify the filter configuration. Fields to know:
host filter > Rules
Control which devices are associated with a particular template. Enter a rule type, condition, and value.
host filter > Resource Setup
Control icmp settings for a device. Enter an interval and ICMP buffer size for a resource.
host filter > Monitors
Control monitoring settings for a device. Fields to know:
Monitors table: Lists the QoS metrics and the configured settings.
Include in Template: Select this check box to include the monitoring alarm threshold settings in the Host filter.
QoS Information: Display-only information about the QoS metric selected in the Monitors table.
Publish Data, Publish Alarms, Compute Baseline: Select these check boxes for each monitor to allow the probe to publish data and
alarms. and/or compute baselines for the selected monitor.
Static Alarm, Dynamic Alarm, Time Over Threshold, and Time To Threshold Alarm: Select the appropriate check box to publish the
selected type of alarms in Infrastructure Manager or UMP. For the selected alarm type, configure the alarm severity and threshold
settings. See Configure Alarm Thresholds for more details.
host filter > Options (...)
Available options:
Copy - Click to create a new device filter with a similar configuration to an existing filter.
Delete Filter - Select Delete Filter and click Save to permanently remove a device filter.
Note: At least one host filter must exist for each template. If you inadvertently delete the only existing host filter for a template and click
Save, an error appears the next time you click Template Editor > icmp probe > template name > Host Filters. You'll be required to
delete the template and create a new one.
ICMP Filters Node
Navigation: Template Editor > icmp probe > template name > icmp Filters
An organizational node in the template tree. This node contains the icmp filters for the probe-specific settings.
icmp probe > template name > icmp > Options (...) > Create Filter
Click to add a new icmp filter to a template. Fields to know:
<icmp> Node
Navigation: Template Editor > icmp probe > template name > icmp Filters > filter
ICMP filters apply probe-specific settings. Multiple filters can exist for a device.
icmp filter > Filter
icmp filter > Rules
Control which devices are associated with a particular template. Enter a rule type, condition, and value.
device filter > Probe Setup
Include in Template: Select this check box to include the probe-specific settings in the icmp filter.
Log level: Sets the level of information saved to the log.
See Probe Setup for details about the remaining fields.
device filter > Options (...)
Available options:
Copy - Click to create a new icmp filter with a similar configuration to an existing filter.
Delete Filter - Select Delete Filter and click Save to permanently remove an icmp filter.
Note: At least one icmp filter must exist for each template. If you inadvertently delete the only existing icmp filter for a template and click
Save, an error appears the next time you click Template Editor > icmp probe > template name > icmp Filters. You'll be required to
delete the template and create a new one.
icmp Metrics
The following table describes the QoS metrics monitored by the Internet Control Message Protocol (icmp) probe.
Monitor Name
Unit
Description
Version
QOS_AVG_RESPONSE_TIME
Milliseconds
Average response time of the monitored resource measured in milliseconds
v1.2
QOS_MAX_RESPONSE_TIME
Milliseconds
Maximum response time of the monitored resource measured in milliseconds
v1.2
QOS_MIN_RESPONSE_TIME
Milliseconds
Minimum response time of the monitored resource measured in milliseconds
v1.2
QOS_FAILED_ATTEMPTS
Count
Number of failed attempts in receiving a response from the monitored resource.
v1.2
QOS_SUCCESSFUL_ATTEMPTS
Count
Number of successful attempts in receiving a response from the monitored resource.
v1.2
QOS_PACKET_LOSS
Percent
Percentage of lost packets in an echo-request. By default, 3 packets are sent in 1 echo-request.
v1.2
QOS_SERVICE_AVAILABILITY
Percent
Percentage of returning packets in an echo-request. The value of this monitor is 0% when no

packet returns and it is 100% when at least one packet returns.
v1.2
iis (IIS Server Monitoring)

The IIS Server Monitoring (iis) probe monitors the health and status of Microsoft IIS servers. The probe performs HTTP GET queries to the
selected Microsoft IIS servers. These values are then used for generating QoS and alarms. You can use this probe for both local and remote
monitoring.
More information:
iis (IIS Server Monitoring) Release Notes
v1.7 iis IM Configuration

selected Microsoft IIS servers. The probe uses the query result for generating alarms and QoS.
The following diagram outlines the process to configure the probe to collect QoS data for Microsoft IIS servers.
Contents
Create Host Profile
Enable a Monitor
Monitor the Application Pool
Verify that required hardware and software is available before you configure the probe. For more information, see iis (IIS Server Monitoring)
Release Notes.
Create Host Profile

This section enables you to create a host profile for monitoring the IIS servers.
Follow these steps:
1. Click the Create a New Host Profile toolbar button to create a new host profile . The Profile[New] dialog-box appears.
Hostname or IP address: Enter the name or IP address of the host to be monitored. If the probe is located on the same computer as
the IIS Server, just specify localhost instead of the name or IP address of the host. This is to avoid authentication issues.
Active: Enables you to activate or deactivate monitoring of the checkpoints on the host. Note that you may also activate/deactivate
monitoring of the various checkpoints individually.
Group: Select from the drop-down list which group folder you want to put the host. Use the group folders to place the hosts in logical
groups.
Alarm Message: Select the alarm message to be issued if the host does not respond. Using the Message pool, you can edit this
message or add other messages.
Server address for http response: Select the address to be tested for http response on the format: http://193.71.55.8 or http://www.n
imsoft.com.
Note: The probe does not support HTTP Response value monitor for HTTPS connections.
Description: Specify a short optional description of the monitored host.

Data collection interval: Select the data collection interval (how often to collect data from the host) from the drop-down menu. You
can also type in a value. The minimum possible value for data collection interval is 1 min.
Filter port: Enter the port which will be used to communicate between the add-on and the probe. The default value is 999. If changed,
the same port number has to be set at the IIS probe as well.
Windows Authentication
Username and Password
Enter the credentials to login (a valid user name and password with administrator privileges) on the monitored host.
Domain
Enter the DNS domain name if the host is a local machine. The blank field means that the machine is hosting the probe.
Test
Click this button to verify if your windows authentication works.
Http Server Authentication
None
Select this value if you require no authentication against the http server (will still require windows authentication for performance
data).
Basic
Select this value if you require basic authentication against the http server. Uses the Http server authentication Username and
Password specified.
Windows
Select this value if you require the Windows authentication, Username and Password specified as described above (see Windows
Authentication above).

Enter the login properties (a valid user name and password with administrator privileges) on the http server.
3. Click OK to save the profile.

The host profile is created.
Enable a Monitor
The IIS Server Monitoring displays the list of available monitors in the right-pane for the selected component in the left-pane. You can configure
the monitor properties for generating corresponding QoS and alarm messages. Adding a monitor can be optional as the probe has default
monitors which are enabled.
Follow these steps:
1. Double-click the monitor in the right-pane. The Monitor Properties dialog appears.
Description: Specify the monitor description.
Monitoring Object: Specify the counter name.
Enable Monitoring: Select this checkbox to generate alarms when the threshold is breached.
Value: Select which value to be compared with the Threshold Value as follows:
Current Value: Compares the last measured value with the Threshold Value.
Compute Average: Calculates the average of the values as measured in the given time interval.
Operator: Specifies the threshold operator while comparing the threshold value with the actual value. For example, use the =>o
perator for generating alarm when the measured value is greater than or equal to the threshold value.
Threshold Value: Defines the alarm threshold value.
Unit: Identifies the unit of the monitored value. For example, % and Mbytes.
Message Token: Specifies the alarm message to be issued when the threshold value is breached.
Publish Quality of Service (QoS): Generates the QoS messages on the monitor.
3. Click OK and save the monitor properties.
4. Click Apply on the probe interface for applying the changes.
The probe is restarted and starts measuring the monitor value for generating QoS and alarm messages.

An application pool lets you run web sites or URL in groups. Each group is part of the different application pool. Each application pool runs in a
different worker process of the IIS server where each worker process runs in isolation. This isolation prevents other application pools from going
down when one application pool is down. You can also define different security rights for each application pool.
The IIS Server Monitoring probe lets you select more than one application pools of the IIS server for monitoring. This monitoring ensures the web
site availability and response time at an expected level.
Important! The Application Pool monitoring feature is supported for IIS 7.0 or later. The APP_POOL_WAS monitor must be available
on the Windows Performance Monitor of the system where IIS 7.0 server or later is installed.
The probe gives the following list of monitors for monitoring the application pool:
Current Worker Processes: fetches the total number of worker processes that are currently running in the application pool.
Recent Worker Process Failures: fetches the total number of times that the worker processes for the application pool has failed during
the rapid-fail protection interval.
Total Worker Process Startup Failures*: fetches the total number of times the Windows Process Activation Service (WAS) has failed to
start a worker process.
Current Application Pool State: fetches the current status value of the application pool, which can be one of the following values:
1 - Uninitialized
2 - Initialized
3 - Running
4 - Disabling
5 - Disabled
6 - Shutdown Pending
7 - Delete Pending
Application Pool Running: fetches the current running status of the application pool, which can be one of the following values:
1 - Running
0 - Not Running
Total Worker Process Failures*: fetches the total number of times the worker processes have crashed after starting the application pool.
Total Application Pool Recycles*: fetches the total number of times the application pool is recycled after the WAS is started.
Total Worker Process Ping Failures*: fetches the total number of times the WAS has failed to receive a ping response from the worker
process.
Total Worker Process Shutdown Failures*: fetches the total number of times the WAS has failed to shut down a worker process.
Application Pool Memory: fetches the total memory all the worker processes of the application pool.
Application Pool CPU: fetches the total CPU used by all the worker processes of the application pool.
Note: The counters marked with an asterisk (*) return the difference between values of the current and last monitoring interval.
You can configure more than one counter for each application pool for monitoring, after adding the IIS server host to the probe.
Follow these steps:
1. Right-click the Application Pool group for the appropriate IIS host and select the Rediscover option.
2. Select the appropriate application pool from the Available Application Pools list to the Selected Application Pools list.
3. Click OK.
The selected application pools appear under the Application Pool group in the left-pane.
4. Select the application pool from the left-pane. Its counters are displayed in the right-pane.
5. Select the check box for each checkpoint and activate the counter for monitoring.
6. Double-click the counter and configure the counter properties in the Monitor Properties dialog.
The probe starts fetching values for the activated counters of the application pool for generating QoS and alarm messages.
Set Device ID Key Using Raw Configure

If you want to monitor local Microsoft IIS servers, and you also want to create the probe Device ID same as robot Device ID, set the useRoboDev
IDForLocalhost key to Yes. By default, this key is set to No.
Follow these steps to change the Device ID key value:
2. Click the Setup folder.
3. Click the default value no and change the value to yes.
4. Click Apply.
The iis probe now monitors local IIS servers.
v1.7 iis IM GUI Reference

Contents
The Left Pane

The Right Pane
The Tool Buttons
This article describes the fields and features of the iis probe GUI.
The probe configuration interface consists of a row of tool buttons and two window panes, as follows:
Left pane
Right pane
Toolbar buttons
Note: When you have made configuration modifications, you must click the Apply button to activate the new settings.
The Left Pane

The left pane shows the various groups and all hosts belonging to a group. Under each host, you will find a number of classes, a way of
sorting the different checkpoints.
Select a group to display all hosts in that group in the right pane.
Select a host to display all predefined checkpoints in the left pane.
Select a class to display the predefined checkpoints belonging to that class in the left pane.
The symbols indicate if a monitored host responds or not:

indicates that the host responds.
indicates that the host does not respond.

indicates that the host responds, but has no monitored interfaces.
Also, note that the checkpoints initially are not activated. You must activate the ones you want to monitor, and you also have the possibility
to hide/show the ones that are not available on the host by clicking the rightmost tool button.
Right-click in the pane opens a pop-up menu, with the following options:
New Host
Opens the profile dialog that enables you to define a new host to be monitored.
New Group
Opens the profile dialog that enables you to define a new group. Use the group folders to place the hosts in logical groups.
New
Opens the profile dialog that enables you to define a new host to be monitored.
Edit
Opens the profile dialog for the selected host that enables you to modify the properties for the host.
Delete
Lets you delete the selected host or group. Note that you are not allowed to delete the group Default.
Rename
Lets you rename the selected group or host. Note that you are not allowed to rename the group Default.
Refresh
Makes a refresh to reflect the current values of the objects listed in the right window pane.
Note: When attempting to refresh a host that does not respond, the checkpoints description fields in the right pane appears with
red letters.
Activate All
Activates all checkpoints on the selected host.
Deactivate All
De-activates all checkpoints on the selected host.
You can move a host from one group to another by left-clicking the host, dragging it and dropping it in another group.
The Right Pane

The right-pane is multi-functional and shows:
Hosts when a group is selected in the left-pane.
List of monitoring counters when a host is selected in the left-pane.
List of checkpoints belonging to the selected class when a class is selected in the left-pane.
The right-pane displays the counters status using the following symbols:Note the meaning of the different icons in the window, which can
be:
: Counter value is not breaching the threshold value.
: Counter value is breaching the threshold value.
: Counter is not selected for monitoring.
: Counter value is not available.
: Counter value is being fetched.
Right-click in the pane to view the following options:
Edit
Opens the Monitor Properties dialog that enables you to modify the monitoring properties for the selected checkpoint.
Activate
Activates the selected checkpoint to be monitored by the probe. Note that you may also activate it by clicking the checkbox belonging
to the checkpoint.
Deactivate
Deactivates the selected checkpoint (if activated) after which the probe will stop monitoring the checkpoint.
Monitor
Opens the monitor window for the selected checkpoint showing the values recorded since the probe was started.
Note: The horizontal red line in the graph indicates the alarm threshold (in this case 90 %) defined for the checkpoint.
When clicking and holding the left mouse button inside the graph, a red vertical line appears. If you continue to hold the left
mouse-button down and move the cursor, you can read the exact value at different points in the graph. The value is displayed in the
upper part of the graph on the format: <Day> <Time> <Value>.
Right-clicking inside the monitor window lets you select the backlog (the time range shown in the monitor window). In addition, the
right-click menu lets you select the option Show Average. This adds a horizontal blue line in the graph, representing the average
sample value.
Note the status bar at the bottom of the monitor window. The following information can be found:
The number of samples since the probe was started.
The minimum value measured.
The average value measured.
The maximum value measured.
The backlog: This is the time range shown in the monitor window. The backlog can be selected to 6, 12, 24 or 48 hours by
right-clicking inside the graph. Note that the graph can not show a time range greater than the selected Maximum data storage
time setting in the Setup section of the GUI.
The Tool Buttons

General Setup
Clicking this button opens the Setup dialog for the probe, allowing you to modify the general probe parameters.

General Tab
Log-level: Defines the detail level for messages logged to the log-file.
Advanced Tab
Autorefresh GUI
Enables you to refresh the page.
Maximum Data Storage Time
Enables you to select the maximum data storage time from the drop-down list. Valid choices are: 6 hours, 12 hours, 24 hours, and,
48 hours.
This is the time range within which the monitored values are picked when calculating the average value (used when setting the
alarm threshold). 24 hours means that the values stored within the last 24 hours will be used.
Maximum concurrent threads
Specifies the maximum number of profiles the probe can run simultaneously. The valid range is 0 - 100.
Displays the database status for the monitored hosts in the right pane.
The list shows the first and the last date backlog and summary data that has been recorded and written to the database, and also the
number of records in the period.
Show User Specified Objects

Displays all user specified objects in the right pane.
Right-click in the right pane to display the User Object dialog. This dialog enables you to define a new object.
The probe includes a set of pre-defined checkpoints available on most hosts running the IIS software, but you can also define your own
objects to be monitored. Click this button to list previously user specified objects in the right pane.
Right-click in the right pane to display these three options:

New
Edit
Delete
Select the New option to display the User Object dialog that enables you to define a new object. This enables you to use objects that are not a
part of the IIS Monitor standard objects, but are available from the windows performance system.

Login Profile
Selects one of the defined hosts from the drop-down list as a Login Profile.
Performance Object Selector
Object Name
Defines the name of the new object.
Counter Name
Defines the counter name. For example, Disk Transfers/sec, if the object LogicalDisk is selected.
Instance Name
Defines the instance name. For example, disk drive D:, if object and counter name are selected as LogicalDisk and Disk
Transfers/sec is selected.
Object Preferences
Description
Specifies an optional description of the object.
Make Available As QoS

Enables you to make the measured value available as QoS, when selected.
Unit
Specifies the unit of the QoS value, such as Mbytes and %.
Note: When clicking the Apply button in the probe GUI, the new user object will be added to the list of user-defined objects and
also under the User Objects sub-node under each host listed in the left pane. When restarting the probe, the probe has to wait for
a couple of minutes before it can show the measured values for the new user defined object.
Create a New Group Folder

Creates a new group folder in the left window pane. Use the group folders to place the hosts in logical groups.
Create a New Host Profile
You can create a new host profile by selecting the group it should belong to and click the Create a New Host Profile tool button. The
Profile[New] dialog-box appears and prompts you for the hostname or IP-address of the IIS host to monitor and some additional
parameters.
Specifies the name or IP address of the host to be monitored. If the probe is located on the same computer as the IIS Server, you
should just specify localhost instead of the name or IP address of the host. This is to avoid authentication issues.
Active
If selected, activates or deactivates monitoring of the checkpoints on the host. Note that you may also activate/deactivate monitoring
of the various checkpoints individually.
Group
Select from the drop-down list which group folder you want to put the host. Use the group folders to place the hosts in logical groups.
Alarm Message
The alarm message to be issued if the host does not respond. Using the Message pool, you can edit this message or add other
messages.
Server address for http response
The address to be tested for http response on the format: http://193.71.55.8 or http://www.nimsoft.com.
Description
Specifies a short optional description of the monitored host.
Data collection interval
Select the data collection interval (how often to collect data from the host) from the drop-down menu. This value overrules the
Common minimum data collection interval defined on the General Setup dialog.
Note: You may also type in a value. The minimum possible value for data collection interval is 1 min.
Filter port
Defines the port which will be used to communicate between the add-on and the probe. The default value is 999. If changed, the same
port number has to be set at the IIS probe as well.
Windows Authentication
The credentials to login (a valid user name and password with administrator privileges) on the monitored host.
Domain
Defines the DNS domain name if the host local machine. The blank field means that the machine is hosting the probe.
Test
Clicking this button verifies if your windows authentication works.
Http Server Authentication
None
Indicates no authentication against the http server (will still require windows authentication for performance data).
Basic
Indicates basic authentication against the http server. Using the Http server authentication Username and Password specified.
Windows
Uses the Windows authentication, Username and Password specified as described above (see Windows Authentication above).
The login properties (a valid user name and password with administrator privileges) on the http server.
The alarm messages for each alarm situation are stored in the Message Pool. This option lets you customize the alarm text, and you can
also create your own messages.
Note: Variable expansion is supported in the message text. If you type a $ in the Error Alarm Text field, a dialog pops up, offering a
set of variables to be chosen.
View IIS Summary
Click this button to open the IIS Summary Report for the selected host. The window contains a graph, showing the HTTP response time and the
Cache hits/misses per day.
Note: You must select the IIS sub node for a host in the left pane to activate the button.
Click the drop-down menu in the upper left corner to display the graph with the values for:
Per hour
Displays the values with a solution of one hour for the period selected using the From and To fields.
Click the Submit button to fetch the values for the selected period.
Per day
Displays the values with a solution of one day for the period selected using the From and To fields.
Click the Submit button to fetch the values for the selected period.
Last day
Displays the values with a solution of one hour for the last day.
Last month
Displays the values with a solution of one hour for the last month.
When clicking and holding the left mouse-button down and move the cursor, you can read the exact value at different points in the
graph. The value is displayed in the upper part of the graph on the format: <Day> <Time> <value>.
View IIS Server Requests
The iis probe enables you to view IIS server data (requests) in a separate window. To enable this functionality, some configuration tasks
must be done on the computer running the IIS server software.
Open the configuration tool for the probe by double-clicking the line representing the probe in the Infrastructure Manager.
Using the tool buttons located in the upper part of the window, you can select between different statistics views. The most recent request
running on the IIS server (at the time of the last sample).
Request statistics (hourly, daily and monthly)
The entries in the list can be selected and copied to clipboard (CTRL + C), in the case you want to paste the entries into another
application (CTRL + V).
Left-click the entries to select them, or select CTRL+ A to select all.
Request database status, showing the number of records in the request database
If you want to delete some or all records, you right-click in the list and select Delete Request Data.
The following dialog appears, asking you to select for which period to delete data. Make your selection and click the OK button.
Using the calendar functionality, you can select to show the statistics for a specific period. Select a period and click Submit.
Show/Hide checkpoints that are not available

You can select to show or hide the checkpoints that are not available at the selected host from the list in the right window pane.
Click this button to show/hide checkpoints from the list that are not available on the selected host.
v1.7 iis AC Configuration

selected Microsoft IIS servers. The probe uses the query result for generating alarms and QoS.
The following diagram outlines the process to configure the probe to collect QoS data for Microsoft IIS servers.
Contents
Add Host
Alarm Thresholds
Verify that required hardware and software is available before you configure the probe. For more information, see iis (IIS Server Monitoring)
Release Notes.
Add Host
You can add the IIS host server under the iis node to monitor the IIS server.
Follow these steps:
1. Click the Options(icon) next to the iis node in the navigation pane.
2. Click the Add New Host option.
3. Set or modify the following values in the Add New Host window
Hostname or IP Address: Enter the name or IP address of the IIS server to be monitored.
Active: Enables you to activate the host for monitoring.
Default: Selected
Alarm Message: Specify the alarm message to be used when the host does not respond.
URL for http response: Specify the address to be tested for http response. For example, http://10.112.69.14 or http://www.msn.com.
Description: Specify a short description of the monitored host.
Data Collection Interval (min): Specify how often the probe collects data from the host.
Default: 1
Filter Port: Define the port which is used to communicate between the IIS add-on (IISrequest.dll) and the probe. This option is used for
monitoring the IIS server remotely.
Default: 999
Windows Username: Define a valid user name with administrator privileges for logging in to the monitored host.
Windows Password: Define the password for logging in to the monitored host.
Windows Domain: Define the DNS domain name for locating the IIS server when it is not hosted on the local system. Leave the field
blank, when both IIS and probe are installed on the same system.
Http Server Authentication: Specify the auhentication type as follows:
None: indicates no authentication against the http server (still requires the Windows authentication for performance data).
Basic: indicates basic authentication against the http server. The Http Username and Http Password fields values are used for
the authentication.
Windows: uses the Windows authentication credentials as specified in Windows Username and Windows Password fields.
Http Username: Define a valid user name with administrator privileges of the http server.
Http Password: Define the password for logging in to the http server.
2. Click Submit.
3. Click the Test Windows Credential option from the Actions drop-down to verify the entered values.
The host is saved under the iis node. Every new host contains four child nodes (ASP, IIS, System, and Webservices), which are used
to configure the monitoring properties of the host.
Alarm Thresholds
allow the probe to:

Monitoring the health and status of the application pool is important for the website administrator. This monitoring ensures web site availability and
response time at an optimum level. The probe gives the lists of available application pools on the monitored host and lets you configure
monitoring counters for each application pool separately.
Important! The Application Pool monitoring feature is applicable for IIS 7.0 or later. The APP_POOL_WAS counter must be available
on the Windows Performance Monitor of the system where IIS 7.0 server or later is installed.
Follow these steps:

1. Go to the Application Pool node in the navigation pane.
2. Select more than one application pool from the Available list and move to the Selected list and click Save.
The selected applications pools appear under the Application Pool node in the navigation pane.
3. Select the appropriate application pool name node.
4. Activate the application pool monitoring in the General Configuration section.
5. Activate the required monitoring counters of the application pool.
6. Click Save.
The probe starts fetching values for the selected monitoring counters of the application pool for generating alarms and QoS.

If you want to monitor local Microsoft IIS servers, and you also want to create the probe Device ID same as robot Device ID, set the useRobotDe
vIDForLocalhost key to Yes. By default, this key is set to No.
Follow these steps to change the Device ID key value:

1. Open the Raw Configuration interface of the probe.
2. Click the Setup folder.
3. Click the default value no and change the value to yes.
4. Click Apply.
The iis probe now monitors local IIS servers.
There may be the following impact of setting this key:
Probe
Version
Key
Value
Impact
Previous
to v1.71
NA
NA
Upgrade
to v1.71
No
No Impact
Upgrade
to v1.71
Yes
Previously, all QoS and alarms for the local host profile were generated on the old Device ID. Now, the probe generates all
the QoS and alarms for local host profiles on the new Device ID i.e. Robot Device ID. This breaks the old data continuity
on the USM portal.
v1.7 iis AC GUI Reference

This section contains configuration details specific to the IIS Server Monitoring probe. You can configure the probe to monitor the health and
performance of the IIS Servers. The IIS Server Monitoring probe performs the HTTP GET queries to the selected Microsoft IIS servers. The probe
uses the query result for generating alarms and QoS.
iis Node
Host-<Host Name> Node
<Host Name> Node
IIS Server Node
Application Pool Node
<Application Pool Name> Node
ASP Node
IIS Node
System Node
Webservices Node
iis Node
This section contains configuration details specific to the IIS Server Monitoring probe. In this node, you can view the probe information and can
configure the log properties of the probe. You can also configure the advanced properties of the probe to set maximum summary storage and
number of concurrent threads.
Navigation: iis
iis > Probe Information
iis > General Configuration
This section lets you configure the default log level for the probe.
Default: 3 - Info
iis > Advanced Configuration
This section lets you set the maximum summary storage time and the number of concurrent threads for the probe.
Max Summary Storage: specifies the maximum data storage time for local monitoring purpose. This value is the time range within which
the monitored values are picked for calculating the average value (used when setting the alarm threshold). This option does not affect the
QoS data.
Default: 6 hours
Maximum Concurrent Threads: specifies the maximum number of profiles the probe can run simultaneously. The valid range is 0 - 100.
Default: 20
iis > Messages
This section lets you view the default alarm messages for the different error conditions.
Error: identifies the error message text. You can use variables by typing "$" from the following list:
state
expected_state
name
display_name
profile_name
credential
expected_credential
restarts
OK: identifies the clear message text.
Subsystem: identifies a descriptive text name for the subsystem.
Host-<Host Name> Node

The Host-host name node displays information about the IIS host, which the IIS Server Monitoring probe is monitoring. The Host-host name node
is displayed under the iis node. You can view information about the host name and the server address for http response.
Navigation: iis > Host-host name
Host-host name > Host Configuration
This section lets you view and update details of the IIS host, which the IIS Server Monitoring probe is monitoring.
Hostname or IP address: defines the host name or IP address of the system, where the IIS is running.
Windows Username: defines a valid user name with administrator privileges for logging in to the monitored host.
Windows Password: defines the password for logging in to the monitored host.
Server Address for Http Response: specifies the address for testing http response.
Host-host name > Options (icon) > Delete Host
This option allows you to delete this host when you no longer want the probe to monitor it.
<Host Name> Node

The host name node represents the IIS host, which the IIS Server Monitoring probe is monitoring. The host name node is displayed under the
Host-host name node.
This node does not contain any field or sections.
IIS Server Node

The IIS Server node is displayed under the host name node. You can configure the properties of the IIS Server node to generate alarms when the
server does not respond. You can also configure the Windows credentials and http server authentication details.
Navigation: iis > Host-host name > host name > IIS Server
IIS Server > Host Configuration
This section lets you configure the IIS Server details and test the Windows user credentials.
Hostname or IP Address: defines the name or IP address of the IIS server to be monitored.
Active: activates the host monitoring.
Default: Selected
Alarm Message: specifies the alarm message when the host does not respond.
URL for http response: specifies the address to be tested for http response. For example, http://10.112.69.14 or http://www.msn.com.
Description: specifies a short description of the monitored host.
Data Collection Interval (min): specifies how often the probe collects data from the host.
Default: 1
Filter Port: defines the port which is used to communicate between the IIS add-on (IISrequest.dll) and the probe. This option is used for
monitoring the IIS server remotely.
Default: 999
Windows Username: defines a valid user name with administrator privileges for logging in to the monitored host.
Windows Password: defines the password for logging in to the monitored host.
Windows Domain: defines the DNS domain name for locating the IIS server when it is not hosted on the local system. Leave the field
blank, when both IIS and probe are installed on the same system.
Http Server Authentication: specifies the authentication type as follows:
None: indicates no authentication against the http server (still requires the Windows authentication for performance data).
Basic: indicates basic authentication against the http server. The Http Username and Http Password fields values are used for the
authentication.
Windows: uses the Windows authentication credentials as specified in Windows Username and Windows Password fields.
Http Username: defines a valid user name with administrator privileges of the http server.
Http Password: defines the password for logging in to the http server.
Note: Click the Test Windows Credential option from the Actions drop-down to verify the entered values.
Application Pool Node

The Application Pool node is a group node for displaying all application pools running in an IIS server. This node lets you select more than one
application pools for configuring the CPU, Memory, Running State and other related monitoring counters.
An application pool lets you run web sites or URL in groups. Each group is a part of different application pool. Each application pool runs in a
different worker process of the IIS server where each worker process runs in isolation. This isolation prevents other application pools from going
down when one application pool is down. You can also define different security rights for each application pool.
Navigation: iis > Host-host name > host name > Application Pool
Application Pool > Available Pools
This section lets you select the application pool for monitoring from the Available list, which is then visible in the Selected list. The selected
application pools are added under the Application Pool node.
<Application Pool Name> Node

The application pool name node represents an actual application pool running in the IIS server and is selected for monitoring in the probe.
Navigation: iis > Host-host name > host name > Application Pool > application pool name
This node lets you configure the following counters for monitoring:
Current Worker Processes: fetches the total number of worker processes that are currently running in the application pool.
Recent Worker Process Failures: fetches the total number of times the worker processes for the application pool has failed during the
rapid-fail protection interval.
Total Worker Process Startup Failures*: fetches the total number of times the Windows Process Activation Service (WAS) has failed to
start a worker process.
Current Application Pool State: fetches the current status value of the application pool, which can be one of the following values:
1 - Uninitialized
2 - Initialized
3 - Running
4 - Disabling
5 - Disabled
6 - Shutdown Pending
7 - Delete Pending
Application Pool Running: fetches the current running status of the application pool, which can be one of the following values:
1 - Running
0 - Not Running
Total Worker Process Failures*: fetches the total number of times the worker processes have crashed after starting the application pool.
Total Application Pool Recycles*: fetches the total number of times the application pool is recycled after the WAS is started.
Total Worker Process Ping Failures*: fetches the total number of times the WAS has failed to receive a ping response from the worker
process.
Total Worker Process Shutdown Failures*: fetches the total number of times the WAS has failed to shut down a worker process.
Application Pool Memory: fetches the total memory of all the worker processes of the application pool.
Application Pool CPU: fetches the total CPU used by all the worker processes of the application pool.
Note: The counters marked with an asterisk (*) return the difference between values of the current and last monitoring interval.
Click the Options (icon) next to the Application Pool node and select the Delete Application Pool option to delete the Application Pool.
Alternatively, you can move the application pool back from the Selected list to the Available list in the Application Pool node, and click
Save to stop monitoring the application pool.
ASP Node
The ASP node is used to configure the following counters of the IIS server:
Requests Bytes In Total
Requests Executing
Requests Queued
IIS Node
The IIS node is used to configure the following counters of the IIS server:
Host Availability
HTTP Response Time
HTTP Response Value
IIS max request time
IIS Status Value
Total Allowed Async I/O Requests
URI Cache Flushes
URI Cache Hits
URI Cache Hits %
URI Cache Hits/minute
URI Cache Misses
URI Cache Misses/minute
System Node
The System node is used to configure the following counters of the IIS server:
Available Physical Memory
Memory In Use
Memory Usage
NW Bytes Total/sec
Total CPU
Total Memory
Webservices Node
The Webservices node is used to configure the following counters of the IIS server:
Bytes Received/sec
Bytes Sent/sec
Bytes Total/sec
Connection Attempts/sec
Current Connections
Get Requests/sec
Measured Async I/O Bandwidth Usage
iis Metrics
This section contains the metrics for the IIS Server Monitoring (iis) probe.
Contents
QoS Metrics
Alert Metric Default Settings
QoS Metrics
This table contains the QoS metrics for the IIS Server Monitoring probe.
Monitor Name
Units
Description
Version
QOS_ASYNCIO_BWUSAGE
v1.0
QOS_BYTESRECEIVD_PS
Bytes received/sec
Web server bytes received per second
v1.0
QOS_BYTESSENT_PS
Bytes sent/sec
Web server bytes sent per second
v1.0
QOS_BYTESTOTAL_PS
Bytes Total/sec
Web server bytes total per second
v1.0
QOS_CONNATTEMPTS_PS
Connection attempts/sec
Connection attempts per second
v1.0
QOS_CPU_USAGE
Percent
CPU Usage
v1.0
QOS_CURRENTCONNECTS
Current connections
Current connections
v1.0
QOS_IIS_DISK_USAGE
Megabytes
Disk Usage
v1.0
QOS_GET_REQUESTS_PS
Get Requests/sec
Get requests per second
v1.0
QOS_IIS_HTTPRESTIME
Milliseconds
http response time
v1.0
QOS_IIS_USEROBJ
Value
IIS User object
v1.0
QOS_MEMAVPHY
Megabytes
Physical Memory available
v1.0
QOS_MEMORY_INUSE
Percent
Memory in Use %
v1.0
QOS_MEMORY_USAGE
Megabytes
Memory Usage
v1.0
QOS_MEMORYAVAILPHYS
Megabytes
Physical Memory available
v1.0
QOS_NETWORK_BTPS
Bytes Total/sec
Network interface bytes total per second
v1.0
QOS_WSC_CACHEHITSPC
Cache hits
Web service cache hits %
v1.0
QOS_WSC_CACHEHITSPM
Cache hits/minute
Web service cache hits
v1.0
QOS_WSC_CACHEMISSPM
Cache misses/minute
Web Service Cache Misses
v1.0
This table describes the QoS metrics on the Application pool for the IIS Server Monitoring probe.
QoS on Application Pool
Units
Description
Version
QOS_IIS_RECENT_WRKR_PROCESSES_FAILURE
Count
Total number of times the worker processes for the application pool
has failed during the rapid-fail protection interval.
1.0
QOS_IIS_WRKR_PROCESSES
Count
Total number of worker processes that are currently running in the

application pool.
1.0
QOS_IIS_TOT_WRKR_PROCESS_STARTUP_FAILURE
Count
Total number of times the Windows Process Activation Service (WAS)

has failed to start a worker process.
1.0
QOS_IIS_APP_RUNNING_STATE
State
Current status value of the application pool.
1.0
QOS_IIS_APP_RUNNING
State
Current running status of the application pool.
1.0
QOS_IIS_TOT_WRKR_PROCESSES_FAILURE
Count
Total number of times the worker processes has crashed after starting
the application pool.
1.0
QOS_IIS_TOT_APP_POOLS_RECYCLES
Count
Total number of times the application pool is recycled after the WAS is
started.
1.0
QOS_IIS_TOT_WRKR_PROCESSES_PING_FAILURES
Count
Total number of times the WAS has failed to receive a ping response
from the worker process.
1.0
QOS_IIS_TOT_WRKR_PROCESSES_SHUTDOWN_FAILURES
Count
Total number of times the WAS has failed to shut down a worker
process.
1.0
QOS_IIS_APP_POOL_MEMORY
Percent
Total memory used by all worker processes of the application pool.
1.0
QOS_IIS_APP_POOL_CPU
Percent
Total CPU used by all worker processes of the application pool.
1.0
Alert Metric Default Settings

This section contains the alert metric default settings for the IIS Server Monitoring probe.
QoS Metric
Error Threshold
Error Severity
Description
MsgAgentError
Critical
The IIS is not running on host.
MsgPerfHandleError
Minor
Unable to obtain handle to Perfmon probe.
MsgPerSelectedError
Warning
Unable to extract performance counters.
MsgHostAvailError
Warning
Host is not available or not responding.
MsgWarning
Warning
Message warning
MsgError
Critical
Message error
interface_traffic (Interface Traffic Monitoring)

The Interface Traffic Monitoring (interface_traffic) probe monitors network traffic on SNMP agents using standard MIB-II queries. The probe
queries the SNMP agent on the defined host for interface traffic data. The probe uses a combination of SNMPGet requests in predefined
intervals. This period is calculated as the interval * number of samples. You can define a warning threshold and a critical threshold.
The probe can monitor one or more interfaces for traffic congestion and inactive interfaces. The probe can be configured to monitor the network
interface on a Windows or UNIX systems, or router or switch. The probe then reports whenever the traffic breaches a predefined threshold. The
probe also supports Quality of Service (QoS) messages for the Service Level Agreement (SLA) family.
Note: Probes that support SNMP on Linux (interface_traffic, snmptd, and snmpget) use an SNMP library. This library can cause newer
Linux systems to issue the following message in the Linux console log:
process interface_traff is using obsolete setsockopt SO_BSDCOMP

AT
The SNMP library supports older versions of glibc which require the flag for sockets to work correctly. The network portion of the glibc
library sends this message. The message shows that an unsupported flag is being sent to the setsockopt function. The library ignores
this flag, so you can also ignore it.
More information:
interface_traffic (Interface Traffic Monitoring) Release Notes
v5.4 interface_traffic IM Configuration

This article contains the configuration information for the interface_traffic probe. The following diagram outlines the process to configure the probe
to monitor network traffic on SNMP agents.
Contents
Create Host Profile

Set Monitoring Options for Interfaces
Add Connection
Create Group
Configure Alarm Messages
Set Default Interface Parameters
Set Bulk Configuration
Get Routing Table
Get Interface Details
Create Virtual Interface
Generate Checksums
Create Host Profile

You can create host profiles for SNMP hosts. The ways to create a profile are as follows:
Add a host profile: You can add a profile for a specific host to the probe.
Add a range of host profiles using a specified connection: You can scan across a range of IP addresses to find and add all applicable
hosts.
Drag-and-drop host records to create host profiles using a specified connection: Use a preexisting
list of hostnames or IP addresses and add them to the probe as profiles.
Add Host Profile

This section describes how to add a host to start monitoring.
Follow these steps:
1. Select a group in the left pane.
2. Click
to open the Host Profile [NEW] window.
The General Settings tab is available. The Advanced and Message Definition tabs are disabled.
3. Enter the host name or the IP address of the SNMP host in Host address.
The Start Query button is enabled.
4. Set or modify the following values:
Poll interval: Specify the interval for the probe to poll the selected host.
SNMP Properties
This section defines the connection details for the host profile.
SNMP Version: Select the SNMP software version number (SNMPv1, SNMPv2c, or SNMPv3).
Authentication: Select the type of authentication strategy (none, MD5, or SHA).
Note: Enabled only when SNMPv3 is selected.
Port: Specify the port to be used to send SNMP requests to the host.
Default: 161
Timeout: Select the timeout value for the SNMP requests.
Default: 1 second
Retries: Set the maximum number of attempts to send SNMP requests without response from the device to consider the device as
not available.
Default: 5
Community/password
Specify the community, if SNMPv1 or SNMPv2c is selected from the SNMP Version field.
Specify the password, if SNMPv3 is selected from the SNMP Version field and enabled when Security is selected as AuthNoPriv
or AuthPriv.
Show Community/password: Display the string in the Community/password field as plain text, if selected.
Username: Specify a username to access the monitored device.
Note: The Username, Security, Priv. Protocol, and Priv. Passphrase fields are enabled only when SNMPv3 is
selected from the SNMP Version field.
Security: Specify the security level for the user.

Valid levels are NoAuthNoPriv, AuthNoPriv, and AuthPriv.
Priv. Protocol: Specify the privacy protocol to use.
Enabled only when AuthPriv is selected as Security.
Priv. Passphrase: Define your privacy passphrase. It must be at least eight characters long.
Monitoring group: Specify the name of the group where the host profile is created.
Default: Default group
Description: Specify additional information about the monitored SNMP host in the profile.
5. Click Start Query.
The SNMP Query window appears if the query is successful.
6. Click OK.
The Host Profile window appears and the Advanced and Message Definition tabs are enabled.
7. Click OK (on the Host Profile window).
The SNMP host is added to the list of monitored devices.
Note: The OK button (on the Host Profile dialog) gets enabled once the SNMP query is successfully completed.
Add a Range of Host Profiles

This section gives information about how to add a range of IP addresses as host profiles in the probe. All hosts within the range are queried using
a single connection.
Follow these steps:
1. Select a group in the left pane.
2. Click
and select New Range.
The Add Agent Range window appears.
3. Specify the initial IP address for the range.
4. Specify the Number of agents to query as SNMP hosts.
5. Click OK.
6. Select a connection to use for all hosts in the specified range from the Connection Information drop-down list.
Default: Auto
Note:
You must select a connection from the Connection Information drop-down before clicking the Start Query button to
collect SNMP data.
You can also select <Add New> from the Connection Information to add a new connection to be used. Refer Add
Connection for more information.

Timeout: Select the timeout value for the SNMP requests.
7.
Default: 1 second
Retries: Set the maximum number of attempts to send SNMP requests without response from the device to consider the device as not
available.
Default: 5
8. Select Activate interface monitor to automatically activate monitoring of the interfaces that are detected on the hosts that are found by
the query.
You can select one of the three available monitoring criteria:
For all interfaces that are up
Monitoring is activated for all interfaces detected that are up and running (green indicator).
For all interfaces that are matching
Monitoring is activated for all interfaces that are detected with Interface names matching the string specified.
Example: FastEthernet0, Ethernet0, and Ethernet1 all match the string Eth
For all interfaces matching index
Monitoring is activated for all interfaces that are detected with an ID matching the index specified. This setting can be a single ID or a
comma-separated list.
10. Click OK.
Drag-and-Drop Hosts
This section describes how to drag-and-drop a host record to create a new host profile.
Follow these steps:
1. Open the file with the IP addresses or hostnames in a word editor such as Microsoft Word or WordPad.
2. Select the SNMP hosts to monitor.
3. Drag the selection to the applicable group in the navigation pane.
4. Select a connection to use for all hosts in the specified range from the Connection Information drop-down list.
Default: Auto
Note: The connection has the following conditions:

You must select a connection from the Connection Information drop-down before clicking the Start Query button to
collect SNMP data.

Timeout: select the timeout value for the SNMP requests.
Default: 1 second
Retries: Set the maximum number of attempts to send SNMP requests without response from the device to consider the device as not
available.
Default: 5
6. Select Activate interface monitor to automatically activate monitoring of the interfaces detected on the hosts found by the query.
Monitoring is activated for all interfaces detected that are up and running (green indicator).
Monitoring is activated for all interfaces that are detected with Interface names matching the string specified.
Monitoring is activated for all interfaces that are detected with an ID matching the index specified. This setting can be a single ID or a
comma-separated list.
8. Click OK.
Set Monitoring Options for Interfaces

This section describes how to activate various monitoring options in an interface.
Follow these steps:
1. Double-click the interface (or right-click the interface and select Edit).
The InterfaceName window appears.
2. You can publish QoS using different criteria, set the values of low and high threshold, set the alarm severity level, and configure other
alarm-generation settings in the Traffic tab.
Publish Quality of Service: generate Quality of Service (traffic) for the selected data series.
The following options can be selected from the drop-down list:
Interface traffic only
Aggregated traffic only
Interface and aggregated traffic
You can also select the QoS to be published in different formats:
Value (bytes/second)
Percentage of the maximum speed
Both values and percentage of the maximum speed
kbit/second
kbit/second and percentage of the maximum speed
Enable monitoring: enable monitoring of the traffic on the interface.
Using percentage: Specify the alarm thresholds using percentage. The default value for Low threshold is 90% and for High
threshold is 98%.
Using values: Specify the alarm thresholds, using values. When selected, you can specify the low and high threshold values in B/s,
Kb/s Mb/s, or Gb/s.
Samples to base average on: Specify the number of samples to base the average value on. This number and the polling interval
determine the period for calculating the average value. The average value is checked against the thresholds and alarms are issued
if the average value breaches the thresholds.
Low threshold: Specify the low alarm threshold value (either in percentage or in value).
Alarms with the severity level (say, Warning) specified in the Alarm severity level field are issued when the traffic (average value)
exceeds this value.
Default: Disabled
High threshold: Specify the high alarm threshold value.
Alarms with a high severity level (for example, Critical) specified in the Alarm severity level field are issued when the traffic
(average value) exceeds this value.
Notes:
You must specify either Low threshold or High threshold, as specifying one of these values is mandatory.
An error message is displayed, if using values option is selected with both thresholds and you specify only Low
threshold or High threshold or none of these.
The error message also displays if one of the checkboxes is selected and you do not enter any value in it.
Alarm when traffic less than or equal to: select to issue alarms with the selected severity level when traffic is less than or equal to
the defined value on the selected interface:
Inbound traffic: Alarms are issued when inbound traffic is less than or equal to defined value.
Outbound traffic: Alarms are issued when outbound traffic is less than or equal to defined value.
Both interfaces: Alarms are issued when both inbound and outbound traffic is less than or equal to defined value. This is the
default selection.
Any interface: Alarms are issued if either inbound or outbound traffic is less than or equal to defined value.
Max (Extreme) value: Enter the maximum value for the traffic.
Action required: Select the action to be performed when the max value is breached. Action required has following values:
No Action: The probe generates the alarms and QoS with the actual values, if applicable fields are selected.
Use max value: The defined maximum value is used in alarms and QoS.
Discard: The defined maximum value is discarded. No alarm that is related to the threshold is sent. Also, NULL QoS is sent.
Use zero: The zero is used in alarms and QoS.
Send Alarm when Max value is breached: Select if you want the probe to send an alarm when the defined max value is breached.
Note: This field is enabled only when maximum value for traffic Max (Extreme) value is provided.
Set Default: click to display the Default interface settings dialog. Refer Set Default Interface Parameters for more information.
Each option, when selected, opens a confirmation dialog.
Monitor: click to display the interface traffic in a graphical format.
3. You configure various settings for Error Packets, Discarded Packets, and Processed Packets in the Packets tab.
Error Packets
The number of packets that could not be transmitted because of errors. You can select QoS to be published as:
Packets per second
Number of packets
Packets per second and number of packets
Percentage %
Publish Quality of Service (QoS): select this option to publish the Quality of Service (number of packets with errors) for the selected
interface when checked.
Enable monitoring: enable monitoring of the number of packets with errors on the interface.
Max. error packets: specify the maximum number of packets with errors on the interface that are allowed before an alarm is issued.
Alarm severity level: select the severity level of the alarms issued when the maximum monitoring threshold is breached.
Max (Extreme) value: specify the threshold for the extreme maximum number of packets with errors on the interface that are
allowed before an alarm is issued.
Extreme severity level: select the severity level of the alarms issued when the extreme maximum monitoring threshold is breached.
Note: The alarm severity and message string of Max (Extreme) value can be changed from the Message Pool dialog.
Action Required: select the action to be performed when the maximum value is breached. This field can have the following values:
Use max Value: The defined maximum value is used in alarms and QoS.
Discard: The defined maximum value is discarded. No alarm related to the threshold is sent. In addition, NULL QoS is sent.
Zero: The zero is used in alarms and QoS.
Send Alarm when Max value is breached: select this option to send an alarm when defined max value is breached.
Note: This field is enabled only when Max (Extreme) value is provided.
Discarded Packets
The number of packets that were discarded from the interface. You can select QoS to be published as:
Packets per second
Number of packets
Percentage %
Publish Quality of Service (QoS): select this option to publish the Quality of Service (number of discarded packets) for the selected
Enable monitoring: enable monitoring of the number of discarded packets on the interface.
Max. discarded: specify the maximum number of packets discarded by the interface that are allowed before an alarm is issued.
Alarm severity level: select the severity level of the alarms issued when the maximum monitoring threshold is breached.
Max (Extreme) value: specify the threshold for the extreme maximum number of discarded packets from the interface that are
Extreme severity level: select the severity level of the alarms issued when the extreme maximum monitoring threshold is breached.
Processed Packets
The number of packets that were processed by the interface. You can select QoS to be published as:
Packets per second
Number of packets
Percentage %
Publish Quality of Service (QoS): select this option to publish the Quality of Service (number of processed packets) for the selected
Enable monitoring: enable monitoring of the number of processed packets on the interface. You can specify the maximum number of
packets processed by the interface that are allowed before an alarm is issued.
Max (Extreme) value: specify the threshold for the extreme maximum number of discarded packets from the interface that are allowed
before an alarm is issued.
4. You can specify the length of the output packet queue in the Queue Length tab. Queue length is the maximum permissible number of
packets in the output queue before the alarm is raised.
Publish Quality of Service: select this option to publish Quality of Service (the length of the output packet queue) for the selected
Enable monitoring: enable monitoring of the length of the output packet queue on the interface.
Max. packets in the output queue before alarm: specify the maximum number of packets in the output queue on the
interface allowed before an alarm is issued.
Alarm severity level: select the severity level of Queue length alarms.
5. You can configure the current and desired operational state of the interface in the State tab.
Set or modify the following values in the State tab:
Interface Operational State
Configures monitoring of the current operational state of the interface.
Publish Quality of Service: select this option to publish Quality of Service (the state of the interface).
Enable monitoring: enable monitoring of the operational state of the interface.
Legal states: select the expected states of the interface from the multiple options provided.
Note: A down state indicates that no packets can be passed. If the current state of the interface is not in the list of
legal states, an alarm with the selected severity level is generated.
Alarm severity level: select the severity level of alarms when the state is not as expected.
Interface Administrative State:
Configures monitoring of the desired state of the interface.
Publish Quality of Service: select this option to publish Quality of Service (the state of the interface).
Enable monitoring: enable monitoring of the operational state of the interface.
Legal states: select the expected states of the interface from the multiple options provided.
Note: If the current state of the interface is not in the list of legal states, an alarm with the selected severity level is
generated.
Alarm severity level: select the severity level of alarms when the state is not as expected.
Ignore Operational State when admin state is not as expected
Ignores the operational state when admin state is not as expected, when selected.
Note: This check box is enabled only when both Enable monitoring checkboxes are selected.
6. You can specify advanced configuration for an interface in the Advanced tab.
Interface speed: The valid options are:
Automatic detection: The speed of the interface is automatically detected.
Manual override: specify a value to override the detected interface speed. The speed can be specified using one of these units:
B/s, Kb/s, Mb/s, and Gb/s. The speed rate specified is equally divided on inbound and outbound traffic.
Manual override per direction: override the speed individually per direction. The speed can be specified using one of these units:
B/s, Kb/s, Mb/s, and Gb/s.
Total: specify the value and unit for the manual override.
Override Outbound Traffic Monitoring: override the high and low thresholds for Outbound Traffic monitoring.
QoS Destination: override the QoS target value with interface name, description, and user-specified description. Depending on the
option selected in this field, the same appears in the QoS.
User specified description: define a custom description. When listing the interfaces for a host, this description appears in the User
column. This option makes it easier to distinguish between different interfaces.
7. Click OK to save the interface configuration.
Add Connection
This section describes how to create a new connection. The same settings can be applied to the Add Host Profile section.
Follow these steps:
1. Click the
button on the toolbar.
The Setup window appears.
3. Click the
icon to open the Add connection information window.

Name: specify a name for the connection.
SNMP Version: select the SNMP software version number (SNMPv1, SNMPv2c, or SNMPv3).
Authentication: select the type of authentication strategy (none, MD5, or SHA).
Note: Enabled only when SNMPv3 is selected from the SNMP Version field.
Port: specify the port to be used to send SNMP requests to the host.
Default: 161
Community/password
Specify the community, if SNMPv1 or SNMPv2c is selected.

Specify the password, if SNMPv3 is selected and enabled when Security is selected as AuthNoPriv or AuthPriv.
Username: specify a username to access the monitored device.
Note: The Username, Security, Priv. Protocol, and Priv. Passphrase fields are enabled only when SNMPv3 is selected.
Security: specify the security level for the user.

Priv. Protocol: specify the privacy protocol to use.
Priv. Passphrase: define your privacy passphrase. It must be at least eight characters long.
5. Click OK.
The new connection is created.
Note: You can also select a connection and click
to delete a connection.
Create Group
This section allows you to create a group in the left pane of the probe. Groups are used to categorize and arrange profiles in the probe.
Example: A group can be created for each department with users of exchange servers within the same network.
Follow these steps:
1. Click the
button on the toolbar.
A new group is created along the Default Group.
2. Specify a name of the group.
3. Press Enter.
Configure Alarm Messages

Follow these steps:
1. Click
.
2. Click
or right-click and select New to create a new message.
You can also select a message and click

message.
, or double-click a message or right-click on a message and select Edit to modify the

Identification Name: specify an identification code as a name for the message.
Token: select the message token to identify the type of message.
Error Alarm Text: specify the alarm text in case error occurs.
Clear Alarm Text (OK): specify the alarm text in case no error occurs.
Error Severity: select the severity level for the error message.
Subsystem string/id: select the subsystem id for the message.
4. Click OK.
The new message gets added or the selected message gets modified.
Note: Variable expansion in the message text is supported. Enter $ in the Alarm text fields to open the variable expansion pop-up with
a set of variables.
Set Default Interface Parameters

You can set default interface parameters for any hosts you add to the probe configuration. All interfaces that follow the rules specified in this
section has the same monitoring parameters,
Follow these steps:
1. Click
.
The Default interface settings window appears.
You can select one of the following options:
Default interface settings (General) to use the predefined standards. This is the default selection.
Default interface settings (ifType Specific) to select interfaces of a specific type.
Default interface settings (ifName specific) to select interfaces with names matching the specified regular expression.
Refer Using Regular Expressions for more information.
Default interface settings (ifSpeed specific) to select from interfaces with specified transfer speed.
Note: The settings is applied on priority as stated below:
Regular expression (ifName)
ifSpeed
ifType
Default settings (General).
2. Select the parameter in the drop-down list.

3. Click OK.
4. Configure the settings for an interface/interfaces. Refer Set Monitoring Options for Interfaces section for more details.
Note: You can also click Set Default in the InterfaceName window and set the configuration as the applicable default
interface.
5. Right-click in the main window and select Rediscover Interfaces.

6. Click Yes for the confirmation message.
7. Click Yes to clear the current list of interfaces and add again.
You can also click No to merge any new interfaces with the current list of interfaces.
8. Click OK.
The list of interfaces for the selected host is rediscovered.
Set Bulk Configuration

This section describes how to configure multiple hosts together. You can specify the same monitoring parameters to multiple interfaces on
multiple hosts.
Follow these steps:
1. Click
.
The Bulk Configuration window appears.
Select Agents
All Agents: indicate that the configuration parameters is distributed to all the monitored SNMP hosts.
Only active ones: indicate that the configuration parameters is distributed to all the active monitored SNMP hosts.
All agents matching: specify the pattern of host names where the configuration parameters is distributed. Refer Using Regular
Expressions for more information.
All agents in the group: select the group of hosts where the configuration parameters is distributed.
Selected Agents: indicate that the configuration parameters is distributed to one or more SNMP hosts selected in a group.
Select Interfaces
Apply to all Interfaces: indicate that the configuration parameters is distributed to all interfaces on the monitored SNMP hosts.
Only active ones: indicate that the configuration parameters is distributed to all the active interfaces on the monitored SNMP hosts.
Apply to interfaces matching: specify the pattern of interface names names where the configuration parameters is distributed on
the monitored SNMP hosts. Refer Using Regular Expressions for more information.
Selected Interfaces: indicate that the configuration parameters is distributed to one or more interfaces selected in the monitored
SNMP hosts.
Note: If you select one or more interfaces in the probe GUI and then click the Bulk Configuration button, the bulk
configuration applies to the selected interfaces.
Modify Agent values

Interval: specify the interval for the probe to poll the selected host.
Version: select the SNMP software version number (SNMPv1, SNMPv2c, or SNMPv3).
Auth.: select the type of authentication strategy (none, MD5, or SHA).
Default: 161
Default: 1 second
Retries: set the maximum number of attempts to send SNMP requests without response from the device to consider the device as
not available.
Default: 5
Community/password
Show Community/password: display the string in the Community/password field as plain text, if selected.
Note: The Username, Security, Priv. Protocol, and Priv. Passphrase fields are enabled only when SNMPv3 is
selected.


Advanced
Prefix alarm messages with the Description
Indicates the probe to prefix the Description text string to the alarm messages issued on breached thresholds from the selected
host, if selected.
Automatically re-map interfaces after an index shift
Indicates the probe to automatically discover and map active profiles to new indexes, if selected.
When modifications have been made on a monitored host (such as replacement of interface cards, deleted/added VLANs), the
probe sends an SNMP query to the host, attempting to rediscover all interfaces. The probe uses the interface names found during
the initial interface discovery to map the profiles.
Modify Interface Values
Use the default interface settings: Indicate the probe that the default interface parameters are used.
Configure interface settings: open the InterfaceName window, enabling you to define your own set of parameters for this bulk
configuration.
Monitoring
Indicates that the settings done in the upper sections of the Bulk Configuration dialog are not applied to an interface/all
interfaces.
Note: This section is available only when Modify interface values check box is selected.
Activate: apply the settings done in the upper part of the Bulk Configuration dialog on interfaces, if selected.
3. Click OK.
The bulk configuration is applied to the interfaces.
Get Routing Table

This section describes how to extract the routing information for a selected host. The routing information for a host identifies the various network
interfaces that the host response must travel through.
Follow these steps:
1. Select a host from the main window.
Note: You can skip step 1 to specify a host currently not monitored by the probe. The Routing information window appears,
but then the host values must be specified.
2. Click
.
The Routing information window appears with the details of the host.
Profile: select the host profile to find the routing information.
Host address: specify the host name or IP address of the host to be monitored.
Version: select the SNMP software version number (SNMPv1, SNMPv2c, or SNMPv3).
Auth.: select the type of authentication strategy (none, MD5, or SHA).
Default: 161
Default: 1 second
Retries: set the maximum number of attempts to send SNMP requests without response from the device to consider the device as not
available.
Default: 5
Community/password
Show password: display the string in the Community/password field as plain text, if selected.
Note: The Username, Security, Priv. Protocol, and Priv. Passphrase fields are enabled only when SNMPv3 is selected.

4. Click Go.
The routing information for the selected host is displayed in the window.
This section provides you the details about Active and Inactive interfaces. Click
to display the Interface Details window with the interface
statistics of the probe. Inactive interfaces continue to generate fail alarms and must be cleared.
Create Virtual Interface

This section allows you to create virtual interface which can be used to combine inbound and outbound statistics from two different physical
interfaces. You can create virtual interfaces in the probe to represent virtual network interfaces that can be present in the SNMP host. A virtual
interface can also be used to compare the inbound and outbound statistic of two related interfaces in an SNMP host. For example, consider that
two interfaces are at the two ends of a pipeline. The difference between the inbound traffic at the source interface and the outbound traffic at the
end interface provides the data loss from the pipeline.
Follow these steps:
1. Select the host in the left pane
2. Right-click in the right pane and select Virtual Interfaces > Create Virtual Interface.
The Virtual Interface window appears.
Name: specify the name of the virtual interface.
Description: specify the description of the virtual interface.
Virtual Inbound Interface
Specify the interface to measure inbound traffic.
Interface mapping: select how you want to map an interface to the Virtual Inbound Interface.
The values can be as follows:
Fixed interface: select one of the physical interfaces present on the host from the Physical Interface field.
Automatic mapping based on ifAlias: allows you to enter a regular expression in the Physical Interface field to define which
physical interfaces to map to the Virtual Interface. Refer Using Regular Expressions for more information.
Use physical outbound as inbound statistics: indicate the probe that the physical outbound statistics is used as virtual inbound
statistics, if selected.
Virtual Outbound Interface
Specify the interface to measure outbound traffic.
Interface mapping: select how you want to map an interface to the Virtual Outbound Interface.
The values can be as follows:

Fixed interface: select one of the physical interfaces present on the host from the Physical Interface field.
physical interfaces to map to the Virtual Interface. Refer Using Regular Expressions for more information.
Use physical inbound as outbound statistics: indicate the probe that the physical inbound statistics is used as virtual outbound
Generate Checksums
The probe (versions 4.35 and earlier) had a checksum issue which was corrected in version 4.36. However, the index of an interface can change
when you upgrade to a later version of the probe. You can generate checksums to verify that the profile remains valid after the upgrade.
Follow these steps:
1. Right-click the host in the main window and select Generate Checksum.
Note: Generate Checksum is only valid if there is a problem with corrupted interface names.
The Generate Interface Checksum dialog appears with the selected host profiles listed.
Note: Click the More Information button in this dialog to learn more about the checksum issue.
2. Click the Generate button to generate the new checksums.

3. You have the following options:
You can evaluate and select individual interfaces by selecting Manual interaction.
Control questions are asked when the OK button is clicked.
You can also automatically replace old interfaces by selecting Automatic.
4. Click OK.

Regular expressions are used to find all hosts or interfaces in the probe with names that match a pattern. Regular expressions are used to filter
hostnames in Bulk Configuration. They are also used to filter interface names to specify default interface parameters, bulk configuration, and
mapping virtual interfaces with physical inbound and outbound interfaces.
A regular expression (regex for short) is a special text string to describe a search pattern. Constructing regular expression and pattern matching
You can also use simple text with some wild-card operators for matching the target string. For example, *test* expression matches the text test in
target string.
Notes:
Regular expressions specified in the Default interface settings (ifName specific) field are case-sensitive.
Regular expressions must be enclosed in an asterisk (*), for example, *regex*.
A regular expression is applied on the interface name and on the substring of the interface.
If default settings for a regular expression corresponding to an interface are saved once, other regular expressions for the
same interface which are created later are not applicable
The following table describes some examples of regex and pattern matching for the probe.
Regular expression
Explanation
[A-Z]
Standard (PCRE)

Example: ALPHA
/[A-Z]
Custom
Matches for any string with exactly one Uppercase character.

Example: G
Standard (PCRE)
Matches a single instance of any character or numeral.

Example: a
.e*
Custom
Matches any string where the second character is lowercase e.

Example: beta
Standard (PCRE)
Matches against zero or more occurrences of the previous character or expression.

Example: alert23a
/[a-d]*
Custom
Matches for any string name which starts from letters a, b, c, or d.

Example: delta
v5.4 interface_traffic IM GUI Reference

This article describes the configuration GUI details for the Interface Traffic Monitoring (interface_traffic) probe.
Contents
Probe GUI
Toolbar
Left Pane
Right Pane
Interface Status Indicators
General Setup
General Tab
Advanced Tab
Host Profile Window
General Settings Tab
Advanced Tab
Add Agent Range Window
SNMP Query Window
Monitor Interface Window
<InterfaceName> Window
Traffic Tab
Packets Tab
Queue Length Tab
State Tab
Advanced Tab
Rediscover Interfaces
Virtual Interfaces
Probe GUI
The interface_traffic probe is configured by double-clicking the probe in the Infrastructure Manager.
Toolbar
The interface_traffic GUI contains a toolbar, which allows you to configure the interface_traffic probe:
The toolbar contains following buttons:
General Setup
Displays the Setup window, which allows you to set general properties of a host.
New Folder
Creates a folder for a group in the left pane.
New SNMP Host
Displays the Host Profile window, which allows you to create new host profile to be monitored.
Displays the Message Pool window, which contains a list of all the messages.
Set the default interface parameters
Allows you to set default parameters for all or specific interfaces.
Bulk Configuration
Allows you to set default parameters for multiple hosts.
Get Routing Table
Displays routing information for a specific profile.
Displays a count of active and inactive interfaces.
Update interface status
Allows you to update the status of an interface.
Left Pane
The left pane contains various groups and hosts belonging to a specific group. You can right-click in the left pane to display the following options:
New
Displays the Host Profile window, which allows you to define a new host to be monitored.
Rename
Lets you rename the selected group or host.
Delete
Lets you delete the selected group or host from the list of monitored devices.
Expand group
Expands/opens the group folder to show all associated hosts.
Collapse group
Collapses/closes the group folder to hide all associated hosts.
Show all agents
If selected, displays the All Agents folder, which contains all defined agents (SNMP hosts). If not selected, hides the All Agents folder.
Note: If selected, overrides the Show All Agents option in the Setup window.
The following symbols indicate if a monitored host is responding or not:

Indicates that the host responds
Indicates that the host does not respond
Indicates either that the profile is created, but you have not yet clicked the Apply button, or the profile is not active.
Indicates that the host responds, but has no monitored interfaces
Right Pane
The right-pane contains:

Hosts when a group is selected in the left pane.
Interfaces when a host is selected in the left pane.
You can right-click in the right pane to display the following options. These options vary depending on whether a host or an interface is selected.
New
Opens the Host Profile window, enabling you to define a new SNMP host to be monitored. This option is Available only when a group is
selected in the left pane.
Edit
Displays the properties window for the selected host or interface, as selected in the left pane.
The properties window enables you to modify the properties of the selected host or interface.
Rename
Allows you to rename a selected interface.
This option is available only when a host is selected in the left pane.
Delete
Deletes the selected host or interface, as selected in the left pane.
Activate
Starts monitoring the selected host or interface, as selected in the left pane.
Deactivate
Stops monitoring the selected host or interface, as selected in the left pane.
Monitor
Displays the interface monitor window and starts monitoring the selected interface.
This option is available only when a host is selected in the left pane.
Refresh
Refreshes the list of hosts or interfaces in the right pane.
Query SNMP Agent
Displays the SNMP Query window showing the hostname, uptime, and SNMP system information.
Generate Checksums
Displays the Generate Interface Checksums window. The interface checksums are used to remap interface indexes when an interface
index shift occurs. This utility should be used for profiles/interfaces added using interface_traffic version 4.35 or earlier.
Rediscover interfaces
Sends an SNMP query to the agent hosting the selected interface, attempting to find all interfaces available on the agent. All interfaces
found are listed in the right pane.
This option is available only when a host/profile is selected in the left pane.
Virtual Interfaces
Used to create a new virtual interface and modify the details of an existing virtual interface.
Interface Status Indicators
Interfaces appear with a status indicator where:

Green
Indicates that the monitored interface status is OK.
Black
Indicates that the operating status is not available from the monitor.
Yellow
Indicates a warning situation, due to traffic congestion.
Red
Indicates an error situation.
Indicates a warning situation related to configuration.
Example: A monitored interface has been removed from the host.
Indicates that an interface that has been deleted from the MIB.
Note: The Interface Status Indicators are disabled by default when probe GUI comes up. Therefore, Black color display for every
interface is expected when you launch the probe GUI. These indicators are enabled only when the
General Setup
When you click the General Setup button on the toolbar, the Setup window is displayed.
This window contains the below listed tabs:
General
Advanced
General Tab
button is clicked.
This tab is used to configure the general settings for the probe such as setting the log-level, sending the alarms when the interface is down, and
so on.
The fields in the General tab are described as follows:
Send Alarm Once (if Interface is Down)
Sends alarm once when the operational state for the interface is down. This alarm is sent with the Ignore other alarms when
operational state is down/not present/lower layer down field of the Advanced tab.
Send Alarm Once (if Interface is Unavailable/Deleted)
Sends alarm only once for the interface operational state, when an interface is deleted or unavailable. The alarm is sent with the Ignore
other alarms when operational state is down/not present/lower layer down field of the Advanced tab
Show All Agents
Displays a group called All Agents in the left pane. It contains all defined hosts.
Note: You can right-click in the left pane of the user interface and select Show All Agents to override this option.
Polling interval
Specifies the default interval for the probe to poll the selected host. You can override this value in the Host Properties window.
Log-level
Default: 0 - Fatal
Note: Log as little as possible during normal operation to minimize disk consumption and increase the amount of detail when
debugging.
Log-size
Defines the size of the probe log file to which probe-internal log messages are written. When this size is reached, the contents of the file
are cleared.
Default: 100 KB
Note: In version 5.42 and later, the maximum logsize is enhanced to 2 GB (2097151 KB).
ifSpeed Interval (Multiple of poll interval)

Specifies the time interval in seconds to update the ifSpeed value. Here, the ifSpeed value is updated for any change after an interval,
which is multiple of poll interval.
For example, if the defined Poll interval is 3 seconds and ifSpeed interval is 10, then the value is updated at an interval of 3*10 = 30
seconds.
Use IfDescription for CI Name
Displays the description of the Configuration Item (CI) as the target in the QoS Message.
Default: selected
Note: The Use IfDescription for CI Name option is added from version 5.40 onwards of the probe. Refer interface_traffic
(Interface Traffic Monitoring) Release Notes > Upgrade Considerations for more information.
Use Alias
Displays the alias name of the Configuration Item in the Description column on the probe GUI. By default, this checkbox is not selected.
When you select the checkbox then the probe GUI displays the interface description in the Name column and the interface alias in the De
scription column (like version 5.32) and SNMP_v3 support.
Note: The Use Alias option is added from version 5.41 onwards of the probe. Refer interface_traffic (Interface Traffic
Monitoring) Release Notes > Upgrade Considerations for more information.
Advanced Tab
This tab is used to maintain the connection information and also perform some advanced settings.
The fields in the Advanced Tab are explained as follows:

Connection Information
Specifies (add or delete) the SNMP community strings to be used.
You can click the
icon to add a connection using the Add connection information window.
Bind to network interface

Binds all the network operations to the controller IP address.
Concurrent sessions
Specifies the number of concurrent parallel sessions.
Encrypt community strings
Encrypts the community string in the configuration file.
Items in sample array
Specifies the default number of samples stored in memory for each interface. This value can be overridden for each interface.
Save inactive interface definitions
Saves interface definitions for all inactive and active interfaces. If not selected, saves interface definitions for active interfaces only.
Include Alarm/QoS Settings
Saves alarm and QoS settings information for inactive interfaces. If not selected, the alarm and QoS settings information for inactive
interfaces is not saved.
Note: This field is enabled only if Save inactive interface definitions is selected.
SNMP request timeout

Selects the timeout value for the SNMP requests. Use the default value, or select another value (in seconds) from the drop-down list.
Ignore other alarms when operational state is down/not present/lower layer down
Alarms related to threshold breach of traffic, packet, and queue length are not sent, if the operational state is either down, not present or
lower layer down and this option is selected.
Note: You can select this and the Send Alarm Once (if Interface is Unavailable or Deleted) to configure the Op State
(operational state) alarm. The alarm is generated once when the interface is down or unavailable and all other alarms except
Admin State are ignored.
Single SNMP requests

Uses a single PDU to collect the interface data. PDU (Protocol Data Unit) is information delivered through a network layer.
UI config timeout (sec.)
Defines the timeout value for the UI. This is the maximum time the probe can use to read the configuration file from the controller before
giving up. If monitoring a large number of hosts, the configuration file is large. It is then recommended to increase this size.
Hide community strings
Hides the community string when listing hosts in the right pane. The hosts is listed in the right pane when selecting All Agents in the left
pane.
Send QoS in Kbps only
Sends the QoS in Kbps only and not in its default unit bytes/sec. If the unit selected for QoS is kbit/sec and this option is unchecked, then
QoS is sent in both Kbps and bps. If Send QoS in Kbps only is selected and unit for QoS is also selected as kbit/sec then default
Bytes/second will not come and only QoS in kbit/sec comes.
Host Profile Window

You can create, modify, or delete host profiles for SNMP hosts. The Host Profile window has the following tabs:
General Settings
Advanced
Message Definitions
Note: The Advanced and Message Definitions tabs are enabled after a successful SNMP query to the host.
General Settings Tab
When you add a single host, the Host Profile window appears with General Settings tab is displayed. Through this tab, you can specify the host
that needs to be added and can configure some general settings for that host.
The fields in the General Settings tab are explained as follows:
Host address
Defines the host name or the IP address of the SNMP host.
Poll interval
Specifies the interval for the probe to poll the selected host.
SNMP Properties
This section defines the connection details for the host profile.
SNMP Version: selects the SNMP software version number (SNMPv1, SNMPv2c, or SNMPv3).
Authentication: selects the type of authentication strategy (none, MD5, or SHA).
Port: specifies the port to be used to send SNMP requests to the host.
Default: 161
Community/password
Represents community, if SNMPv1 or SNMPv2c is selected.
Represents password, if SNMPv3 is selected and enabled when Security is selected as AuthNoPriv or AuthPriv.
Show Community/password: displays the string in the Community/password field as plain text, if selected.
Username: specifies a username to access the monitored device.
Note: The Username, Security, Priv. Protocol, and Priv. Passphrase fields are enabled only when
SNMPv3 is selected.
Security: specifies the security level for the user.

Priv. Protocol: specifies the privacy protocol to use.

Priv. Passphrase: defines your privacy passphrase. It must be at least eight characters long.
Timeout
Selects the timeout value for the SNMP requests. Default: 1 second
Retries
Sets the maximum number of attempts to send SNMP requests without response from the device to consider the device as not
available. Default: 5
Monitoring group
Specifies the name of the group where the host profile is created. Default: Default group
Description
Specifies additional information about the monitored SNMP host in the profile.
SNMP V3 Support
The probe is enabled to monitor hosts/agents based on the SNMP V3 protocol. Few guidelines that must be adhered to when monitoring the
SNMP V3 hosts are given as follows:
If the same probe instance is monitoring multiple SNMP V3 hosts/agent, the user must ensure that the EngineID of all the hosts/agents is
unique. The absence of unique EngineID causes sporadic connection timeouts and failure alarms.
The probe does not support creating multiple monitoring profiles for one V3 host/agent. Adding such duplicate profiles is disabled in the
probe GUI at most of the places, except the Bulk Configure screen. Do not use the Raw Configure option or add directly in the
configuration file for creating multiple profiles for the same V3 host/agent. Doing so, causes the probe for producing some unpredictable
results.
Advanced Tab
This tab is used to configure some advanced settings for the new host to be added. These settings include alarm and QoS identification settings,
number of interfaces to be monitored (through automatic detection or by specifying manually), and whether to re-map interfaces automatically
after an index shift or not.
The fields in the Advanced tab are explained as follows:
Alarm identification method
Selects alarm messages issued on breached thresholds from the selected host to be identified by the host address or the profile name.
QoS identification method
Selects QoS messages issued from the selected host to be identified by the host address, profile name, and interface description.
Prefix alarm messages with the 'Description'
Prefixes the alarm messages issued on breached thresholds from the selected host with the Description text string (from the General
Settings tab).
Monitor the number of interfaces
Specifies the number of interfaces on the selected host to be monitored. You can set the number of interface(s) to be monitored using
the Manual option number or select Automatic Detection to automatically select the number of interfaces.
Show Multicast/Broadcast Packets
Allows QoS and alarms to be generated for unicast, multicast, and broadcast packets for the processed packets. Refer Monitor
Interface Window section for more information.
Default: selected
Automatically re-map interfaces after an index shift
Sends an SNMP query to the host, attempting to rediscover all interfaces when modifications have been made on a monitored host (such
as replacement of interface cards, deleted/added VLANs etc.). The probe maps the active profiles to the new indexes using the interface
names found during the initial interface discovery.
This tab displays a list of token values, and the message ids.
You can select a message ID for the different message tokens.
Add Agent Range Window
You can add a range of IP addresses as host profiles in the probe. All hosts within the range are queried using a single connection.
The fields in the Add Agent Range window are described as follows:
IP address
Specifies the initial IP address for the range.
Number of agents
Specifies the Number of agents to query as SNMP hosts.
SNMP Query Window
The SNMP Query window allows you to send queries to SNMP hosts. This window is displayed when you either add a range of hosts or
drag-and-drop a host record to the probe.
The fields in the SNMP Query window are described as follows:
Connection Information
Selects a connection to use for all hosts in the specified range from the drop-down list.
Default: Auto
Notes:
You must select a connection from the Connection Information drop-down before clicking the Start Query button to collect
SNMP data.
Timeout
Selects the timeout value for the SNMP requests.
Default: 1 second
Retries
Sets the maximum number of attempts to send SNMP requests without response from the device to consider the device as not available.
Default: 5
Monitoring group
Specifies the name of the group where the host profile is created.
Activate interface monitor
Automatically activate monitoring of the interfaces detected on the hosts found by the query.

Activates monitoring for all interfaces detected that are up and running (green indicator).
Activates monitoring for all interfaces detected with Interface names matching the string specified.
Activates monitoring for all interfaces detected with an ID matching the index specified. This can be a single ID or a comma-separated
list.
Monitor Interface Window

You can collect interface traffic data from any interface, listed in the 'interface window', by activating the interface option. This window enables you
to view the traffic as graphs, activated by right-clicking and selecting Monitor. You can right-click in the graph to clear the graph and make the
graph show aggregated data (in and outbound traffic in one graph and the aggregated traffic in another graph).
The Set Collect Interval option lets you select another collect interval (how often the graph is updated with data from the monitor).
Default: 3 seconds.
The fields in the above window are explained as follows:
Interface Data Type
Indicates the interface name, identity, and interface speed. On rediscovering the interface, if the speed has changed it will show updated
speed.
State (indicator)
Indicates the interface status (green = OK, red = error, yellow = unknown).
Scale unit
Sete the units for the scales (B/s, KB/s etc.).
Auto scale
If selected, the scales will automatically be adjusted to match the current traffic.
Inbound/Outbound
Traffic
Displays the current traffic.
Bandwidth
Indicates the current percentage of the bandwidth (max. speed). Red means that the max threshold is exceeded, Green means OK.
Note: If the Show Multicast/Broadcast Packets option is selected on the Advanced tab, the Broadcast and Multicast traffic is
shown in the above graph and not the NUcast.
Definition of some traffic-related terms are as follows:

Octets: Total unicast and non-unicast (or broadcast and multicast) packets delivered to a higher layer protocol.
Octets: The number of octets (bytes, in- or outbound) on the interface, including framing characters.
Unicasts: The number of subnetwork-unicast packets delivered to a higher-layer protocol.
OutUcasts: The total number of packets that higher-layer protocols requested be transmitted to a subnetwork-unicast address, including
those that were discarded or not sent.
InNUcasts: The total number of non-unicast (subnetwork- broadcast or subnetwork-multicast) packets delivered to a higher-layer
protocol.
OutNUcasts: The total number packets that higher-layer protocols requested be transmitted to a non-unicast (i.e. a
subnetwork-broadcast or subnetwork-multicast) address, including those that were discarded or not sent.
Errors: The number of packets (in- or outbound) containing errors preventing them from being delivered to a higher-layer protocol.
Discards: The number of packets (in- or outbound), which were chosen to be discarded, even though no errors had been detected to
prevent them from being delivered to a higher-layer protocol. One possible reason for discarding such a package could be to free up
buffer space.
<InterfaceName> Window
You can double-click the interface (or right-click the selected interface and then choosing Edit) brings up a window-box, enabling you to activate
various monitoring options.
The window contains five tabs - Traffic, Packets, Queue Length, State, and Advanced.
Traffic Tab
Traffic is defined as the number of bytes transmitted over the interface. When you double-click on an interface (or select the Edit option), the Traff
ic tab is displayed by default. This tab is used to publish QoS using different criteria, set the value(s) of low and high threshold, set the alarm
severity level, and configure other alarm-generation settings.
The fields in the Traffic tab are explained as follows:

Generates Quality of Service (traffic) for the selected data series.
The following options can be selected from the drop-down list:
Interface traffic only
Aggregated traffic only

Interface and aggregated traffic
You can also select the QoS to be published in different formats:
Value (bytes/second)
Percentage of the maximum speed
Both values and percentage of the maximum speed
kbit/second
kbit/second and percentage of the maximum speed
Enable monitoring
Enables monitoring of the traffic on the interface.
Using percentage: specifies the alarm thresholds using percentage. The default values for Low threshold is 90 % and for High
threshold is 98%.
Using values: specifies the alarm thresholds, using values. When selected, you can specify the low and high threshold values in B/s,
Kb/s Mb/s, or Gb/s.
Samples to base average on: specifies the number of samples to base the average value on. This number and the polling interval
determine the period for calculating the average value. The average value is checked against the thresholds and alarms are issued if
the average value breaches the thresholds.
Low threshold: specifies the low alarm threshold value (either in percentage or in value). Alarms with the severity level (say, Warning)
specified in the Alarm severity level field is issued when the traffic (average value, see above) exceeds this value.
Default: Disabled
High threshold: specifies the high alarm threshold value. Alarms with a high severity level (for example, Critical) specified in the Alar
m severity level field is issued when the traffic (average value) exceeds this value.
Notes:
You must specify either Low threshold or High threshold, as specifying one of these values is mandatory.
An error message is displayed, if using valuesoption is selected with both thresholds and you specify only Low
threshold or High threshold or none of these.
The above error message also displays if one of the checkboxes is selected and you do not enter any value.
Alarm when traffic less than or equal to

Selects to issue alarms with the selected severity level when traffic is less than or equal to the defined value on the selected interface:
Inbound traffic: Alarms is issued when inbound traffic is less than or equal to defined value.
Outbound traffic: Alarms is issued when outbound traffic is less than or equal to defined value.
Both interfaces: Alarms is issued when both inbound and outbound traffic is less than or equal to defined value.
Any interface: Alarms is issued if either inbound or outbound traffic is less than or equal to defined value.
Max (Extreme) value: defines the maximum value for the traffic.
Action required: selects the action to be performed when the max value is breached. Action required has following values:
Use max value: The defined maximum value is used in alarms and QoS.
Discard: The defined maximum value is discarded. No alarm related to the threshold is sent. Also, NULL QoS is sent.
Use zero: The zero is used in alarms and QoS.
Send Alarm when Max value is breached
Indicates the probe to send an alarm when defined max value is breached, if selected.
Note: This field is enabled only when maximum value for traffic Max (Extreme) value is provided.
Set Default
Displays the Default interface settings dialog.
Each option, when selected, opens a confirmation dialog.
Monitor
Displays the interface traffic in a graphical format.
Packets Tab
This tab is used to configure various settings for Error Packets, Discarded Packets, and Processed Packets.
The fields in the Packets tab are explained as follows:

Error Packets
The number of packets that could not be transmitted because of errors. You can select QoS to be published as:
1.
Packets per second

Number of packets
Percentage %
Publish Quality of Service (QoS): selects this option to publish the Quality of Service (number of packets with errors) for the selected
Enable monitoring
Enable monitoring of the number of packets with errors on the interface.
Max. error packets: specifies the maximum number of packets with errors on the interface that are allowed before an alarm is
issued. Alarms can be raised for pkts\s, pkts, and percent.
Alarm severity level: selects the severity level of the alarms issued when the maximum monitoring threshold is breached.
Max (Extreme) value: specifies the threshold for the extreme maximum number of packets with errors on the interface that are
Extreme severity level: selects the severity level of the alarms issued when the extreme maximum monitoring threshold is
breached.
Action Required: selects the action to be performed when the maximum value is breached. This field can have the following values:
Send Alarm when Max value is breached: selects this option to send an alarm when defined max value is breached.
Discarded Packets
The number of packets that were discarded from the interface. You can select QoS to be published as:
Packets per second
Number of packets
Percentage %
Publish Quality of Service (QoS): selects this option to publish the Quality of Service (number of discarded packets) for the selected
Enable monitoring
Enable monitoring of the number of discarded packets on the interface.
Max. discarded: specifies the maximum number of packets discarded by the interface that are allowed before an alarm is
issued. Alarms can be raised for pkts\s, pkts, and percent.
Alarm severity level: selects the severity level of the alarms issued when the maximum monitoring threshold is breached.
Max (Extreme) value: specifies the threshold for the extreme maximum number of discarded packets from the interface that are
Extreme severity level: selects the severity level of the alarms issued when the extreme maximum monitoring threshold is
breached.
Note: The alarm severity and message string of Max (Extreme) value can be changed from the Message Pool dialo
g.
Important! The probe is unable to provide a correct value for the current percentage of interface errors. This happens
when you have enabled the monitoring of errors and discarded packets. For more information about how to enable
the probe to calculate the correct value for current percentage of interface errors, see interface_traffic
Troubleshooting.
Processed Packets
The number of packets that were processed by the interface. You can select QoS to be published as:
Packets per second
Number of packets
Percentage %
Publish Quality of Service (QoS): selects this option to publish the Quality of Service (number of processed packets) for the
selected interface when checked.
Enable monitoring: enable monitoring of the number of processed packets on the interface. You can specify the maximum number
of packets processed by the interface that are allowed before an alarm is issued. Alarms can be raised for pkts\s and pkts.
Max (Extreme) value: specifies the threshold for the extreme maximum number of discarded packets from the interface that are
Queue Length Tab
You can use this tab to specify the length of the output packet queue. Queue length is the maximum permissible number of packets in the output
queue before the alarm is raised.
The fields in the Queue Length tab are explained below:
Publishes Quality of Service (the length of the output packet queue) for the selected interface when checked.
Enable monitoring
Enables monitoring of the length of the output packet queue on the interface.
Max. packets in the output queue before alarm

specify the maximum number of packets in the output queue on the interface allowed before an alarm is issued.
Alarm severity level
Allows you to select the severity level of Queue length alarms.
State Tab
These settings can be set for both the following:

Interface Operational State (The current operational state of the interface)
Interface Administrative State (The desired state of the interface)
Note: A "down state" indicates that no packets can be passed.
The fields in the State tab are explained below:

Publishes Quality of Service (the state of the interface).
Enable monitoring
Enables monitoring of the operational state of the interface.
Legal states
The expected state(s) of the interface can be selected from the multiple options provided.
Note: If the current state of the interface is not in the list of legal states, an alarm with the selected severity level is generated.
Alarm severity level

Select the severity level of alarms when the state is not as expected.
Ignore Operational State when admin state is not as expected
Enables you to ignore the operational state when admin state is not according to expectation.
Note: This checkbox is enabled only when both Enable monitoring checkboxes are selected.
Advanced Tab
Using this option requires in-depth understanding of the implications to the monitoring profile.
The fields in the Advanced tab are explained as follows:
Interface speed
The valid options are:
Automatic detection: The speed of the interface is automatically detected.
Manual override: You can specify a value and thus override the detected interface speed. The speed can be specified using one of
these units: B/s, Kb/s, Mb/s, and Gb/s. The speed rate specified is equally divided on inbound and outbound traffic.
Manual override per direction: Overrides the speed individually per direction. The speed can be specified using one of these units:
B/s, Kb/s, Mb/s, and Gb/s.
Override Outbound Traffic Monitoring
Allows you to manually override the high and low thresholds for Outbound Traffic monitoring.
QoS Destination
Overrides the QoS target value with interface name, description, and user-specified description. Depending on the option selected in this
field, the same appears in the QoS.
User specified description
Defines a custom description. When listing the interfaces for a host, this description will appear in the User column. This option makes it
easier to distinguish between different interfaces.
Rediscover Interfaces
All interfaces are discovered during the initial SNMP query. There are, however, situations where new interfaces are added to the device after a
period of time. For example, a new subnet is needed and so on.
You can rediscover interfaces that are new or removed by right-clicking the right-pane, whenever a host is selected in the left-pane, and selecting
Rediscover Interfaces.
Notes:
You can use Rediscover Interfaces to "undo" a previous delete.
You can delete the interfaces that are not required by right-clicking the device and selecting Delete from the pop-up menu.
Select the Activate option to activate that interface and the Active column changes the status to yes. Select the Deactivate o
ption to deactivate the interface.
Select the Monitor option to display the interface traffic data for the selected interface. Refer Monitor Interface Window.
Virtual Interfaces
A Virtual Interface in this context is an interface that combines inbound and outbound interface statistics from two different physical interfaces. It is
possible to cross-connect the physical interfaces, so that the inbound on the physical interface is treated as the outbound for the Virtual interface.
The Virtual Interface window provides options for doing this.
After creating a Virtual Interface, it will appear in the probe GUI together with the physical interfaces, and it is configured (QoS and Alarms
settings) like any other interface. The virtual interface is automatically configured with a set of standard monitoring parameters, which you should
edit according to your requirements.
The probe will use data collected from the physical interfaces to send QoS and Alarms for the Virtual Interface. When created, the interface can
be treated and configured as any physical interface when it comes to QoS, monitoring, bulk-configuration, and so on.
The fields in the Virtual Interface window are explained as follows:

Name: specifies the name of the virtual interface.
Description: specifies the description of the virtual interface.
Virtual Inbound Interface
Specifies the interface to measure inbound traffic.
Interface mapping: selects how you want to map an interface to the Virtual Inbound Interface. The values can be as follows:
Fixed interface: selects one of the physical interfaces present on the host from the Physical Interface field.
physical interface(s) to map to the Virtual Interface. Refer Using Regular Expressions for more information.
Use physical outbound as inbound statistics: indicate the probe that the physical outbound statistics is used as virtual inbound
Virtual Outbound Interface
Specifies the interface to measure outbound traffic.
Interface mapping: selects how you want to map an interface to the Virtual Outbound Interface. The values can be as follows:
Fixed interface: selects one of the physical interfaces present on the host from the Physical Interface field.
physical interface(s) to map to the Virtual Interface. Refer Using Regular Expressions for more information.
Use physical inbound as outbound statistics: indicate the probe that the physical inbound statistics are used as virtual outbound
interface_traffic Metrics
Contents
QoS Metrics
This section describes the metrics for the Interface Traffic Monitoring (interface_traffic) probe.
QoS Metrics
The following table describes the checkpoint metrics that can be configured using the interface_traffic probe.
Monitor Name
Units
Description
Version
QOS_INTERFACE_ADMINSTATUS
State
Displays the administrative status of the interface
v4.0
The values are: up or down.
QOS_INTERFACE_DISCARDS
Packets/sec
Displays the number of inbound and outbound packets discarded by the interface.
v4.0
QOS_INTERFACE_ERRORS
Packets/sec
Displays the number of inbound and outbound error packets on the interface.
v4.0
QOS_INTERFACE_OPSTATE
State
Displays the current operational state of the interface.
v4.0
The values are: up, down, not present, or unknown.
QOS_INTERFACE_PACKETS
Packets/sec
Displays the number of packets received or sent by the interface
v4.0
The packet types are: unicast, multicast, broadcast, and total.
QOS_INTERFACE_QLEN
Packets
Displays the queue length of the outbound packets across the interface.
v4.0
QOS_INTERFACE_TRAFFIC
Bytes/sec
Displays the inbound and outbound traffic on the interface.
v4.0
QOS_INTERFACE_TRAFFIC_KBITS
Kilobits/sec
Displays the inbound and outbound traffic on the interface in kilobits per second.
v4.0

This section contains the alert metrics defaults settings for the interface_traffic probe.
QoS Metric
Warning
Threshold
Warning
Severity
Error
Threshold
Error
Severity
Description
InOctets
profile
The inbound traffic on interface is too high.
OutOctets
profile
The outbound traffic on interface is too high.
InOctetsExtreme
critical
The max value has been breached by inbound traffic on the interface.
OutOctetsExtreme
critical
The max value has been breached by outbound traffic on the interface.
NoTraffic
profile
No network traffic is detected on interface.
InErrors
profile
The number of inbound errors is exceeding the threshold.
OutErrors
profile
The number of outbound errors is exceeding the threshold.
InErrorsExtreme
profile
The max value has been breached by inbound error packets on interface.
OutErrorsExtreme
profile
The max value has been breached by outbound error packets on

interface.
InDiscards
profile
The number of discarded inbound packets is exceeding the threshold.
OutDiscards
profile
The number of discarded outbound packets is exceeding the threshold.
InDiscardsExtreme
profile
The max value has been breached by inbound discarded packets on the
interface.
OutDiscardsExtreme -
profile
The max value has been breached by outbound discarded packets on the
interface.
OutQLen
profile
The queue length on the outbound interface is exceeding the threshold.
OpStatus
profile
The interface name on the agent is not as expected.
AdminStatus
profile
The interface administrative status on agent is not as expected.
AgentState
critical
The SNMP agent is not responding.
IndexShift
major
The interface index number has changed for the interface. You need to
rediscover the interface.
InterfaceCount
warning
The number of interfaces has changed on agent.
InPackets
major
The total number of inbound packets on the interface is too high.
OutPackets
major
The total number of outbound packets on the interface is too high
InPacketsExtreme
critical
The max value has been breached by inbound packets on the interface.
OutPacketsExtreme
critical
The max value has been breached by outbound packets on the interface.
NoMaxDefined
critical
The max interface speed of the interface on the agent could not be
determined.
VirtualInterface
critical
The physical interface(s) to use for virtual interface on the agent could not
be determined.
InterfaceExist
major
The interface index on the agent does not exist on the MIB.
interface_traffic Troubleshooting
This article contains troubleshooting points for the interface_traffic probe.
Contents
Probe Calculates More Than 100 % for Error and Discarded Packets
Probe Calculates More Than 100 % for Error and Discarded Packets
Symptom:
The probe is unable to provide a correct value for the current percentage of interface errors. This happens when you enable the monitoring of
errors and discarded packets.
Solution:
Do the following:
1. Go to the Raw Configuration interface of the interface_traffic probe.
2. Set the value of the incerrdistototal key as 1
Default: 0
When the value of this key is set as 1, the error and discarded packets are added to the total packets. The probe is now able to calculate the
correct value for current percentage of interface errors.
jdbc_response (Java Database Connectivity SQL Queries Response Monitoring)

The Java Database Connectivity SQL Queries Response Monitoring (jdbc_response) probe monitors the connection to the JDBC database.The
probe executes custom SQL queries to the database servers through the JDBC client interface and measures the response time.
The probe currently supports monitoring SQL queries on the following databases:
MySQL
Oracle
PostgreSQL
IBM DB2
IBM Informix
More information
jdbc_response (Java Database Connectivity SQL Queries Response Monitoring) Release Notes
jdbc_response AC Configuration
This article describes the configuration concepts and procedures to set up the jdbc_response probe. Configure this probe to monitor the
connection to the JDBC database, by executing custom SQL queries. A profile is used to define these queries and also to configure the alarms
and QoS.
The following diagram outlines the process to configure this probe:
Verify that required hardware and software is available before you configure the probe. For more information, see jdbc_response (Java
Database Connectivity SQL Queries Response Monitoring) Release Notes .
Verify that exclude_connection_time key from Raw Configuration is set to yes.
Note: Connection time is one of the parameters that is used to calculate the response time. If this connection time is not
excluded from the calculation by setting the exclude_connection_time key to yes, the response time keeps increasing.
Configure Log Properties

You can configure the log properties of the probe to define where and how to maintain the log information.
Follow these steps:
1. Navigate to the jdbc_response node.
2. Update the following information under General Configuration, as required:
Log File: defines the file which stores the probe information.
Log Level: specifies the level of information written in the log file.
Default: 3-info
when debugging.
The logging properties are saved.
Create a Connection Profile

You can create a connection to the JDBC database to start the monitoring process.
Follow these steps:
1. Click the Options (icon) beside the jdbc_response node in the navigation pane.
2. Select Add New Connection.
The Add New Connection dialog appears.
Connection Name: specifies a unique name for the connection.
Database URL: specifies the JDBC URL to connect to the database. Some examples are as follows:
IBM DB2: jdbc:db2://IP address:Port Number/Database Name
IBM Informix: jdbc:informix-sqli://IP address:Port Number/Database Name:INFORMIXSERVER=Server Name
jdbc:postgresql://IP address:Port Number/Database Name
Microsoft SQL Server: jdbc:sqlserver://IP address:Port Number;DatabaseName=Database Name
MySQL: jdbc:mysql://IP address:Port Number/mysql
Oracle: jdbc:oracle:thin:@IP address:Port Number:Database Name
Driver Name: specifies the java class name of the JDBC driver.
Note: The default driver name is used for Microsoft SQL Server. You need to update it for other databases.
Driver Path: specifies the absolute path of JDBC driver in the file system. Example: [CA UIM Installation
Directory]/probes/database/jdbc_response/lib/sql_drv.jar
Note: For Microsoft SQL Server and Oracle databases, drivers are already installed with the probe. So, this field is disabled.
4. Define the User ID and Password for querying the database.

5. Click Submit.
A success message dialog appears.
6. Click Reload.
The connection details are saved.
7. Navigate to the <Connection Name> node.
8. Complete the following connection information:
Timeout (Value): defines the time for which the probe attempts to connect to the database.
Default: 30
Timeout (Unit): defines the unit for measuring the value of timeout.
Default: sec
Connection Error: select Active check box to generate an alarm when connection to the database fails. The specified Severity and
Message are sent when the connection fails.
Connection Established: select Active check box to generate an alarm when connection to the database is successful. The
specified Severity and Message are sent when the connection is made.
9. Click on Actions and select Test Connection. If the test fails, check the log file for error messages.
The profile is configured.
9.
Note: If you do not want to use this connection, click Options icon on the connection and click on Delete Connection.
Add a Query
You can add a query which when executed helps to monitor the database connection.
Follow these steps:
1. Click the Options icon beside the connection name node.
2. Click the Add New Query option.
3. Enter the query name in Add New Query dialog and click Submit.
A success message dialog appears.
4. Click Reload.
5. Navigate to the <Query Name> node.
6. Update the general information of the query:
Active: allows you to use this query for monitoring, on creation.
Description: defines the query description
Alarm source override, QoS source override: defines the values that overrides the default source values, which is the robotname
where the probe is deployed.
Important! CA does not recommend you to change the source override fields after the initial configuration. In case you
change the QoS source later, multiple graphs are displayed on the Unified Service Management (USM) Metrics view (one
for every QoS source value). Also, CA recommends you to keep the source identical for both alarm and QoS.
Run Interval (Value): specifies the time interval after which a profile runs automatically.
Default: 5
Run Interval (Units): specifies the unit for measuring the Run Interval.
Default: min
Simple Query: specifies the query to be executed.
Query Timeout (Value): select the time interval after which an alarm is generated when the SQL query fails to validate.
Default: 5
Query Timeout (Units): specifies the unit for the Query Timeout value.
Default: min
Timeout Error: defines the severity level of the alarm to be generated when the SQL query fails to validate.
7. Click on Actions and select Test SQL Query to test if the query is valid.
The profile is saved and you can configure the alarms and QoS for the probe.
Note: If you do not want to use this query, click Options icon on the query and click on Delete Query.
Configure Alarms and QoS

To successfully monitor the database connection, configure alarms and QoS based on the following components:
Total response time
Total number of rows returned by the defined SQL query
Value of a selected column in the first row of the results returned by the defined SQL query
You can configure high threshold, low threshold, and clear alarm messages. The low threshold can be used to generate a warning alarm and the
high threshold can be used to generate an error alarm. For example, generate a high threshold alarm when the query response time exceeds 22
milliseconds.
Follow these steps:
1. Navigate to the <Query Name> node.
2. Update the following information under Query Response Time, Row count, and Value, as required.
Publish Data: allows you to enable the profile to generate the QoS messages.
Publish Alarms: allows you to enable the profile to generate the Alarm messages.
(If you are adding information under Value section) Comparison: defines the type of comparison to be used to check the value
returned from the SQL query. For example, to check the numeric value of the column, select Numeric.
Note: If character or regular expression is selected, "=" and "!=" operators are valid. If regular expression is selected, a Java
regular expression as defined in the Java Pattern class is used to check the value.
(If you are adding information under Value section) Column: defines the column value to be checked. If multiple rows are returned
from the SQL query, the value is always from the first row.
(If adding information for Row count and Value sections) Operator: defines the operator to use to check the number of rows returned
against the threshold values. For example if the Operator is "<=" and the threshold value is 10 and the number of rows returned is 9,
an alarm will be sent for that threshold. If the next query returns 11 rows, a clear alarm (if configured) will be sent.
High Threshold: select the check box to define the properties for high threshold. Specify the maximum Value (in milliseconds) that
will be compared with the value returned from the SQL query. For example, if the response time exceeds this threshold value, an
alarm is generated. The Severity of the alarm and Message is sent when this threshold value is breached.
Low Threshold: select the check box to define the properties for low threshold. Specify the minimum Value (in milliseconds) that will
be compared with the value returned from the SQL query. For example, if the response time exceeds this threshold value, an alarm is
generated. The Severity of the alarm and Message is sent when this threshold value is breached.
Clear: select the check box to define the clear alarm. Define the Severity of the alarm to clear or maintain history of the alarms. The
Message is sent when the threshold value is not breached.
Alarm Thresholds
allow the probe to:
jdbc_response IM Configuration
This article describes the configuration concepts and procedures to set up the jdbc_response probe. Configure this probe to monitor the
connection to the JDBC database, by executing custom SQL queries. A profile is used to define these queries and also to configure the alarms
and QoS.
The following diagram outlines the process to configure this probe:
Create a Connection
Create a Profile
Run the Profile
Verify that required hardware and software is available before you configure the probe. For more information, see jdbc_response (Java
Database Connectivity SQL Queries Response Monitoring) Release Notes.
Verify that exclude_connection_time key from Raw Configuration is set to yes.
Note: Connection time is one of the parameters that is used to calculate the response time. If this connection time is not
excluded from the calculation by setting the exclude_connection_time key to yes, the response time keeps increasing.

You can configure the log properties of the probe to define where and how to maintain the log information.
Follow these steps:
1. Navigate to the Setup tab.
2. Update the following fields:
Log File: defines the file where the logging information will be saved.
Log Level: sets the level of details written to the log file.
when debugging.
Create a Connection
To enable the monitoring process you can create a connection to the JDBC database.
Follow these steps:
1. Right-click on the Connections tab and click New.
2. Enter the name for the connection and click OK.
The New Connection window appears.
3. Complete the following field information:
Win/Domain Authorization: select the check box, if you want to use Windows integrated security for MS SQL Server to connect to
the database.
Database URL: specifes the JDBC URL. Examples:
IBM DB2
jdbc:db2://IP address:PortNumber/Database Name
IBM Informix
jdbc:informix-sqli://IP address:Port Number/Database Name:INFORMIXSERVER=Server Name
Micrsoft SQL Server
jdbc:sqlserver://IP address:Port Number;DatabaseName=Database Name
MySQL
jdbc:mysql://IP address:Port Number/Database Name
Oracle
jdbc:oracle:thin:@IP address:Port Number:Database Name
PostgreSQL
jdbc:postgresql://IP address:Port Number/Database Name
Driver Name: specifies the java class name of the JDBC driver. Examples:
com.ibm.db2.jcc.DB2Driver
com.informix.jdbc.IfxDriver
com.microsoft.sqlserver.jdbc.SQLServerDriver
com.mysql.jdbc.Driver
oracle.jdbc.driver.OracleDriver
org.postgresql.Driver
Driver Path: specifies the absolute file system path to the JDBC driver. Example: [CA UIM Installation
Directory]/probes/database/jdbc_response/lib/sql_drv.jar
Note: For Microsoft SQL Server and Oracle databases, this field is disabled as drivers are already installed with the probe.
(If Win/Domain Authorization check box is not selected) User ID: enter the User ID to connect to the database.
(If Win/Domain Authorization check box is not selected) Password: enter the password of the specified user ID.
Timeout: defines the time for which the probe will attempt to connect to the database.
Connection Error Alarm: defines the severity of the alarm when the connection fails.
Connection Error Alarm Message: specifies the alarm message to be sent to the hub when the connection fails.
Connection Established Alarm: defines the severity of the clearing alarm when the connection is successful.
Connection Established Alarm Message: specifies the message to be sent when the connection is successful.
4. Click the Test button.
If a connection is made to the database, the LED turns green. Otherwise the LED remains black. Check the log file for error messages.
Notes:
To modify an existing connection, right click or double-click on a connection and select Edit.
To delete an existing connection, right click on a connection and select Delete.
Create a Profile
Profiles are associated with a configured connection and contains the SQL query to be executed on the database. As a system administrator, you
can create multiple profiles to monitor the database response time.
Follow these steps:
1. Right-click on the Profiles tab and click New from the context menu.
2. Enter the name of the profile and click OK.
The Edit Profile tab appears.
3. Complete the following fields on the General tab:
Connection: defines the database connection to be used by this profile.
Alarm Source Override, QoS Source Override: defines the values that overrides the default source values, which is the robotname
where the probe is deployed.
Important! CA does not recommended to change the source override fields after the initial configuration. In case you
change the QoS source later, multiple graphs are displayed on the Unified Service Management (USM) Metrics view (one
for every QoS source value). CA also recommends to keep the source identical for both alarm and QoS.
Timeout error: defines the severity level of the alarm to be generated when the SQL query fails to validate
Query Timeout: select the time interval after which an alarm is generated when the SQL query fails to validate.
Run Interval: specifies how often the SQL query and tests should run.
4. Navigate to the SQL Query tab.
5. Enter the SQL query in Simple Query or read the query from a file using the From File option.
Note: If you select the From File option, ensure that the query file is located in the probe home directory. Once the file name is
entered, the query can be loaded by clicking on the Read File button.
6. Click the Test button to test your query.
Notes:
To copy the attributes of a selected profile to another, right click on a profile and select Copy.
To modify an existing profile, right click or double-click on a profile and select Edit. If changes have been made to a profile,
restart the probe for the changes to take effect.
To delete an existing profile, right click on a profile and select Delete.

To successfully monitor the database connection, configure alarms and QoS based on the following components:
Total response time from the Response tab.
Total number of rows returned by the defined SQL query from the Row count tab.
Value of a selected column in the first row of the results returned by the defined SQL query from the Value tab.
You can configure high threshold, low threshold, and clear alarm messages. Typically, the low threshold generates a warning alarm and the high
threshold generates an error alarm. For example, generate a high threshold alarm when the query response time exceeds 22 milliseconds.
Follow these steps:
1. Select Alarms or QoS, as required. Consider the following information:

(For response time) If Alarm is selected, the defined threshold values are applied to the total response time. If QoS is selected, a
QOS_JDBC_RESPONSE message is sent to the hub.
(For row count) If Alarm is selected, the defined threshold values are applied to the number of rows read by the defined SQL query. If
QoS is selected, a QOS_JDBC_ROWS message is sent to the hub.
(For column value) If Alarm is selected, the defined threshold values are applied to the value returned by the defined SQL query. If
QoS is selected, a QOS_JDBC_VALUE message will be sent to the hub.
2. Complete the following field information:
1.
(If Value tab is selected) Comparison: defines the type of comparison that checks the value returned from the SQL query. For
example, to check the numeric value of the column, select Numeric. Consider the following points:
If character or regular expression is selected, "=" and "!=" operators are valid.
If regular expression is selected, a Java regular expression as defined in the Java Pattern class is used to check the value.
(If Value tab is selected) Column: defines the column value to be checked. If multiple rows are returned from the SQL query, the
value is always from the first row.
(If Row Count tab or Value tab is selected) Operator: defines the operator to use to check the number of rows returned against the
threshold values. For example if the Operator is "<=" and the threshold value is 10 and the number of rows returned is 9, an alarm will
be sent for that threshold. If the next query returns 11 rows, a clear alarm (if configured) will be sent.
High Threshold: specifies the maximum Value (in milliseconds) that will be compared with the value returned from the SQL
query. For example, if the response time exceeds this threshold value, an alarm is generated. The Severity of the alarm and Messag
e is sent when this threshold value is breached.
Low Threshold: specifies the minimum Value (in milliseconds) that will be compared with the value returned from the SQL query. For
example, if the response time exceeds this threshold value, an alarm is generated. The Severity of the alarm and Message is sent
when this threshold value is breached.
Clear Severity: defines the Severity of the alarm to clear or maintain history of the alarms. The Message is sent when the threshold
value is not breached.
Note: By default, the Clear Severity level is set to inactive to maintain alarm history in the alarm console.
Note: For more information about using variables in a message, see Attribute Substitution.
2. Click OK to save the information.
Run the Profile

After you have created and configured a profile you need to activate it for it to start monitoring. On the Profiles tab, right-click on a profile and
click on Run now.
jdbc_response Metrics
The following section describes the metrics that can be configured with the Java Database Connectivity SQL Queries Response Monitoring
(jdbc_response) probe.
Contents
QoS Metrics
QoS Metrics
The following table describes the QoS metrics that can be configured using the jdbc_response probe.
Monitor Name
Units
Description
Version
QOS_JDBC_RESPONSE
Milliseconds
Returns the query response time of the JDBC connection.
1.1
QOS_JDBC_ROWS
Rows
Displays the number of rows returned by the query.
1.1
QOS_JDBC_VALUE
Value
Displays the value returned by the query.
1.1

This section contains the alert metric default settings for the jdbc_response probe.
Metric
Name
Warning
Threshold
Warning
Severity
Error
Threshold
Error
Severity
Description
Version
Response
time
NA
Warning
NA
Major
Monitors the alarm value that is sent if the response time of the profile exceeds
the Value setting in milliseconds. This time is calculated on the following
parameters:
1.1
Connection time: Time required to connect to the database

Prepared statement phase time: Time required to execute certain JDBC
statements
Query time: Time required to execute the specified query
Results phase time: Time required to fetch the result of the query
Close connection phase time: Time required to close the connection
Row
count
NA
Warning
NA
Major
Monitors the alarm value that is sent if the number of rows of the profile exceeds
the Condition and Value settings.
1.1
Value
NA
Warning
NA
Major
Monitors the alarm value that is sent if the value exceeds the threshold value.
1.1
jdbc_response Troubleshooting
This section contains the troubleshooting points for jdbc_response probe.
Unable to Create JDBC Connection

Valid on jdbc_response probe version 1.23 or later
Symptom:
Unable to create a JDBC connection with the database using Windows authentication.
Solution:
Ensure that you can access SQL Server database with the Windows credentials.
Follow these steps:
1. Check the JRE version installed on the system where the jdbc_response probe is deployed. It should match with the version mentioned
in jdbc_response (Java Database Connectivity SQL Queries Response Monitoring) Release Notes.
2. Ensure that you can access SQL Server database with Windows credentials by following these steps:
a. Remove sql_auth.dll from the system (if any) where this probe is deployed.
b. In Infrastructure Manager, right click on the jdbc_response probe, and select Edit.
c. Define the argument field as following:
-DNIMV_CONTIP=$NIMV_CONTIP -DNIMCPRID=$NIMCPRID
-DNIM_PROBE_KEY=$NIM_PROBE_KEY -DNIMPROBEPORT=$NIMPROBEPORT
-DNIM_CONTROLLER_PORT=$NIM_CONTROLLER_PORT
-DNIM_SPOOLER_PORT=$NIM_SPOOLER_PORT -cp "./*;lib/*" -Djava.libra
ry.path="C:/Program
Files/Nimsoft/probes/database/jdbc_response/lib" com.nimsoft.nimb
us.probes.database.jdbc_response.JdbcResponse
d. Launch the probe, right-click on the Connections tab, and click New.
e. Enter all the field information.
f. Click the Test button.
g. Go to the Run command window, specify services.msc and click OK.
h. Right-click Nimsoft Robot Watcher service and select Properties option.
i. Click the Log on tab and select This account option.
j. Specify the username in This account field.
k. Define the password to establish the connection and click OK.
l. Restart Nimsoft Robot Watcher service.
m. If you are still unable to create the connection, check the following points:
If you are running 32-bit Java Virtual Machine (JVM) on x64 version operating system, use the sqljdbc_auth.dll file in the x86 folder.
If you are running 64-bit JVM on x64 processor, you are not required to update the dll file.
If you are running 64-bit JVM on Itanium processor, use the sqljdbc_auth.dll file in the IA64 folder.
Note: You can download Microsoft JDBC Drivers 4.2, 4.1, and 4.0 for SQL Server. (sample path for download: C:\Microsoft
SQL Server JDBC Driver\sqljdbc_<version>\enu\auth\x86).
jdbc_response Attribute Substitutions

The messages defined for all alarms can use attribute substitution to make the message unique for the particular profile, connection and
threshold. The pattern must be separated by white space for the substitution to occur. The following attribute substitution patterns can be placed
in the message definition:
Pattern
Substitution
$profile
The profile name.
$url
The JDBC URL of the profile's connection.
$query
The SQL query for this profile.
$con
The name of the connection for this profile.
$threshold
The value of the threshold crossed.
$time
The response time measured.
$rows
The number of rows returned by the query.
$value
The value of the selected column in row 1 of the query.
$condition
The condition selected for the threshold ("=", "!=", etc.).
jdbcgtw (Java Database Connectivity Gateway)

The Java Database Connectivity Gateway probe uses the JDBC connection to access a database. The probe monitors the database transaction
execution time and generates alarms when any threshold is breached. The probe reads data from the database for generating alarms and Quality
of Service (QoS) messages. Also, the probe writes QoS and alarm messages in the database tables.
v1.0 jdbcgtw IM Configuration

This article describes the configuration concepts and procedures for setting up the jdbcgtw probe. The following figure provides an overview of the
Create a new Provider

The Providers tab displays the list of jdbc connection providers that can be used by all the profiles.
To create a new provider, follow these steps:
1. Click the Providers tab.
2. Right click in the list space.
3. Select New from the shortcut menu. The Add new provider dialog appears.
4. Enter appropriate name for the connection provider in the Name text box, and click OK. The New Provider dialog appears
5. Enter a valid connection path in the Path field.
6. Enter the appropriate Driver in the Driver field, and click OK.
The connection provider is created.
Create a new connection

The "Connections" tab contains a pool of database connections that can be used by all the profiles.
To create a new connection, follow these steps:
1. Click the Connections tab.
3. Select New from the shortcut menu. The Add New connection dialog appears.
4. Enter new connection name in the Name text box and click OK. The New Connection dialog appears.
5. Create a connection by selecting the Provider, entering the URL, and user credentials for the database.
6. Click Test to test the connection.
The connection to the database is created.
Create a new profile

To create a new profile, follow these steps:
3. Select New from the shortcut menu. The Create New Profile dialog appears.
4. Select the desired type of profile from the available options: Alarm, Publish, QoS and Subscribe, and click OK. The New <Profile Type>
dialog appears.
5. Select the desired connection for the profile under the General tab and then define a query under the SQL Query tab to read data from
the database.
6. Click Test to execute the defined query.
7. Save the profile.
You can now use this profile to start monitoring.
How to use SQL queries

Some of the input fields in the jdbcgtw probe let you use data from the rows as input.
For example, the SQL query
SELECT Name, Age, Address FROM Phonebook

gives you three different variables that you can use in the input fields. To use the row values, refer to the value using $Name, $Age or $Address.
These can be used alone or together with other input.
For example '$Name lives in $Address and is $Age old'.
Example - Setting Up Network Transaction Logging

This example describes how to set up the jdbcgtw log network transactions to a table in a database. In this example, we assume that the table Ala
Add a connection to the database.
Add a new profile and select Subscribe.
Click the General tab and select the connection you created.
Click the Subscribe tab and select subject nas_transaction and table AlarmTransactionLog.
Activate the profile, save it and watch the table get filled.
v1.0 jdbcgtw IM GUI Reference

Double-click the jdbcgtw probe in the Infrastructure Manager, the probe GUI with various tabs and fields for configuring the probe appears. This
article describes the fields and features of the jdbcgtw probe.
Contents
Setup Tab
Providers Tab
Connections Tab
Profiles Tab
General Tab
SQL Query Tab
Alarm Definition Tab
Publish Message Tab
Quality of Service Definition Tab
Subscribe Tab
Setup Tab
Log File
The file where the probe logs information about its internal activity.
Log Level
Sets the level of details written to the log file. Log as little as possible during normal operation to minimize disk consumption, and
Connection Error Severity
Lets you specify the severity level for the alarms issued when communication errors occur.
Providers Tab
The Providers tab displays the list of jdbc connection providers that can be used by all the profiles.
Connections Tab
The Connections tab contains a pool of database connections that can be used by all the profiles.
For adding new connection, the Edit Connection dialog opens.
The fields are explained below.
Provider
Select connection provider from the drop dwon list.
Driver
Define the driver for the selected provider.
URL
Type the URL to access the server.
Example:
Micrsoft SQL Server
MySQL
Oracle
User ID
Enter the database User ID.
Password
Enter the valid password for the given user id.
QOS Generation
Enter the QOS Server (Target Host) string
Test button
Click this button to test the defined connection.
Profiles Tab
New profiles can be created by right-clicking and selecting New under the Profiles tab.
A "Profile" is a definition of one specific JDBC Gateway task. The tasks can be one of the following types:
1. Send alarms
2. Publish messages
3. Publish QoS messages
4. Subscribe to messages.
You can create four types of profiles:
1. Alarm
2. Publish
3. Qos
4. Subscribe
When clicking the OK button, the Profile dialog appears. The two first tabs of the "Profile" dialog is common for most of the profile types, and
contains:
General Tab

Active
The profile is activated when this option is selected.
Description
Description of the profile.
Connection
One of the connections from the connection pool.
Run Interval
How often the SQL query and tests should run.
Query Timeout
Change the time the JDBC Gateway should wait for the query to finish.
SQL Query Tab

Simple Query
For simple one line queries.
From File
Alternatively, you can store the multi line queries in a file. This way a query can be shared between different profiles. It also makes it
possible to create queries with other tools. The files are stored in the same directory that the jdbcgtw is installed. You can select either
Simply Query or From File option.
Read File
Click this button to read the query from the file.
Test
Using the test button, you can test the query, written in either the Simple Query field or in the file mentioned in the From File field.
The third tab of the "Profile" dialog depends on the profile type selected in the New Profile dialog:
Alarm Definition Tab

Severity
Severity of the alarm. The alarm severity levels are currently not user-configurable in jdbcgtw probe and you can only select an alarm
severity from the predefined list shown in the drop-down.
Subsystem
Subsystem of the alarm.
Message
Alarm message text. Supports variable expansion.
Advanced
Use advanced alarm configuration.
Suppression Key
Suppression key is used to create a logical checkpoint that is used for suppression of alarms.
Source of Sender
Used to impersonate another source that the machine that runs the JDBC Gateway.
Alarm Condition
Define an Alarm condition that must be fulfilled in order to send the alarm.
Column
What column the condition should be checked against.

Publish Message Tab
Messages without any mapping will post a message using all the values in the row and the column names as variable names.
The field is explained below.
Subject
The subject used for publishing.
To create a new variable:
1. Right click in the Variable Mapping frame.
2. Select New from the shortcut menu.
The New Variable Mapping dialog opens.
Variable
Variable name in the message and must be unique for the message.
Value
The value of the variable. Supports variable expansion. For example, '$b follows $b'.
Quality of Service Definition Tab
There are three different QoS types supported by the JDBC gateway.
Query Response. How long (in milliseconds) it took to run the SQL query.
Row Count. How many rows the SQL query returned.
Value QoS. Sends the value of selected column (must be a numeric value) returned by the SQL query.
You can send a QoS message and/or send an alarm if the threshold is breached.
Send QoS Message
Enable/disable Quality of Service messages.
Send Alarm
Enable/disable Alarm.
Severity
Alarm severity.
Message
Alarm message text.
Subsystem
Alarm subsystem.
Threshold
Alarm condition and threshold value.
Suppression key
Suppression key is used to create a logical checkpoint that is used for suppression of alarms.
Source of Sender
Used to impersonate another source that the machine that runs the JDBC Gateway.
Subscribe Tab
A subscriber profile makes it possible to subscribe to a subject and insert the data into a specific table. You must create the target table before
you configure a new Subscribe profile. Make sure that the columns are named corresponding to the message that you want to subscribe to and
that they are of the correct data type. This will make it much easier to create the profile.
Subject
Select the subject you want to subscribe to.
Table
The table you want to insert the data into.
You have to select a connection before the Table pull down is populated. When you create the profile a queue will be created on the hub as well.
This queue will be enabled/disabled corresponding to the profile, and it will be deleted when you delete the profile.
jdbcgtw Tips
The query
There are some rules that you should follow when you create a query:
1. Use column names in the query. E.g. SELECT a, b FROM table1.
This makes it easier to determine the variables available in the profile. In this case $a and $b.
2. Try to limit the number of rows that is returned by the query. It is not funny getting 12432 alarms every 5 minutes.
Use selects like this one if possible: SELECT a, b FROM table1 WHERE somedate < DATEADD(n,-10,GETDATE())
3. Use queries that returns one row if you can. E.g. SELECT count(*) as rows FROM table1.
Remember that each row returned by a query results in one alarm or on message.
Using column variables
It is possible to use variables in most fields in Alarm and Publish profiles. The number of variables available depends on the select statement
used in the query. Always use column names in the query. E.g. SELECT a, b FROM table1. This makes it easier to determine the variables
available in the profile. In this case $a and $b.
The example above could in an Alarm profile result in a Message definition like this: $a contains $b. Each variable will be replaced with the
corresponding value from the select.
Using message variables
This applies to the Subscribe profile only. When you create a table that you are going to use to insert Nimsoft messages try to use the same name
on the columns as the variables used in the message (PDS). You can use a sniffer tool (the hub) to find out what the message contains.
Some data types are treated specially:
1. Numbers that look like this: 1022649974 is most likely an EPOC value, this number corresponds to the date Wednesday, May 29, 2002
05:26:14. EPOC is a system date used by computers and starts on Thursday, January 01, 1970 00:00:00 with the value 0. This value can
be inserted into the database as a datetime value.
2. Formats for number and decimal types must contain only one variable and that value must contain numbers only.
3. The string can contain anything, including multiple variables.
jdbcgtw Metrics
The following section describes the metrics that can be configured with the jdbcgtw (JDBC Gateway) probe.
Contents
Monitor Name
Units
Description
Version
QOS_SQL_RESPONSE
Milliseconds
SQL Query Response Time
1.0
QOS_SQL_ROWS
Count
Number of rows returned by SQL Query
1.0
QOS_SQL_VALUE
Value
Value returned by SQL Query
1.0
v1.0 jdbcgtw AC Configuration
This article describes the configuration concepts and procedures for setting up the jdbcgtw probe. The following figure provides an overview of the
The Java Database Connectivity Gateway probe is configured to establish a JDBC connection with a database. You can create a connection
using different types of database providers. You can also create profiles for monitoring database transactions.
Create a new Provider

The Providers section displays the list of jdbc connection providers that can be used by all the profiles.
To create a new provider, follow these steps:

1. Click the Providers section under the jdbcgtw node.
2. Click New.
3. Enter appropriate name for the connection provider.
4. Enter a valid connection path in the Path field.
5. Enter the appropriate Driver in the Driver field, and click OK.
The connection provider is created.
Add Connection
You can create a JDBC connection of the Java Database Connectivity Gateway probe for monitoring a database.
Follow these steps:
1. Click the Options icon next to the jdbcgtw node in the navigation pane.
2. Click Add New Connection.
The new JDBC connection is available for database monitoring and is visible below the jdbcgtw node in the left pane.
Manage Profiles
You can add a profile of the JDBC connection in the Java Database Connectivity Gateway probe for database monitoring.
Follow these steps:
1. Click Options next to the connection name node in the navigation pane.
3. Update the field information.
4. Define the query for accessing database tables and read data from them under the Sql Query Setup section.
5. Click the Test option under the Actions drop-down to execute the defined query.
The new profile is available for database monitoring.
Delete Connection
You can delete a JDBC connection to stop database monitoring.
Follow these steps:
1. Click the Options icon next to the Connection-connection name node that you want to delete.
2. Select Delete Connection.
3. Click Save.
The JDBC connection is deleted.
Delete Profile
You can delete a custom profile of the connection to stop database monitoring.
Follow these steps:
2. Select the Delete Profile.
3. Click Save.
v1.0 jdbcgtw AC GUI Reference

This article describes the fields and features of the jdbcgtw probe.
jdbcgtw node
This node lets you view the probe information and configure the log properties. You can also view and configure the list of database providers.
Navigation: jdbcgtw
jdbcgtw > Probe Information
jdbcgtw > General Configuration Setup
This section lets you configure the log properties and severity level of Java Database Connectivity Gateway probe.
Log File: defines the log file name.
Severity: specifies the severity level of the communication error alarm.
jdbcgtw > Providers
This section lets you view the list of database providers. You can also add a custom provider using New option or delete an existing
provider using Delete option.
Path: specifies the .jar file path of the provider.
Driver: specifies the provider driver path.
jdbcgtw > Add New Connection
This section lets you establish a new JDBC connection with the database server.
Connection Name: defines the new connection name.
Providers: specifies the database provider used for establishing connection.
URL: specifies the JDBC URL for connecting to the database.
Example:
Micrsoft SQL Server
MySQL
Oracle
User ID: defines the database user name.
Server: defines the server IP address.
Connection-<Connection Name> Node
This section lets you view the new connection information.

Note: This node is referred to as Connection-connection name node in the document and is user-configurable. The fields of this section are same
as described in the Add New Connection section under the jdbcgtw node.
Navigation: jdbcgtw > Connection-connection name
This node lets you view and configure the connection information. You can add a monitoring profile for monitoring the database transactions. A
default profile defines a specific Java Database Connectivity Gateway task. The following three types of default profiles are created when you
establish a new connection:
Metric
Publish
Subscribe
Note: This node is referred to as connection name node in the document and is user-configurable. The fields of this section are same as
described in the Add New Connection section in a checkpoint under the jdbcgtw node.
Navigation: jdbcgtw > Connection-connection name > connection name

connection name > Add New Profile
This section lets you add a custom monitoring profile.
Profile: specifies the task category of the profile.
Metric Node
This node represents the Metric type profile for Java Database Connectivity Gateway probe. All custom Metric type profiles are displayed as
child nodes of this node. There are no fields in this section. The Java Database Connectivity Gateway probe generates the following QoS
messages:
Query Response QoS
Row Count QoS
Value QoS
Navigation: jdbcgtw > Connection-connection name > connection name > Metric
<Metric Profile Name> Node
This node lets you view and configure the Metric type profile properties. You can set the QoS and alarm values for monitoring the transaction
execution.
Note: This node is referred to as metric profile name node and is user-configurable.
Navigation: jdbcgtw > Connection-connection name > connection name > Metric > metric profile name
metric profile name > General Setup
This section lets you configure the profile properties and set the timeout values.
Active: activates the database monitoring.
Profile Name: indicates the profile name.
Connection Name: indicates the provider name.
Query Timeout: specifies the Java Database Connectivity Gateway probe waiting time for query execution.
Run Interval: specifies the time interval between each SQL query execution.
Interval Unit: specifies the measurement unit of Run Interval.
metric profile name > SQL Query Setup
metric profile name > Query Response QoS
This section lets you configure the threshold properties for Query Response QoS value.
Severity: specifies the alarm severity level.
Default: information
Message: defines the alarm message issued.
Default: 1.1.13-Database
Threshold: specifies the alarm threshold operator.
Threshold Value (ms): specifies the time interval exceeding which alarms are issued.
Suppression Key: defines the logical checkpoint at which the alarms get suppressed.
Source of Sender: defines the IP of another machine that runs Java Database Connectivity Gateway probe.
Note: Similarly, you can configure the Row Count QoS and Value QoS.
Publish Node
This node represents the Publish type profile for Java Database Connectivity Gateway probe. All custom Publish type profiles are displayed as
child nodes of this node. There are no fields in this section.
Navigation: jdbcgtw > Connection-connection name > connection name > Publish
<Publish Profile Name> Node
This node lets you view and configure the Publish profile properties. You can set the variable value and

CA Unified Infrastructure Management Probes - ENU - 20160311

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CA Unified Infrastructure Management Probes - ENU - 20160311

Uploaded by

Copyright:

Available Formats

1. CA Unified Infrastructure Management Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1 Alphabetical List of Probe IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.100 salesforce (Salesforce Monitoring) Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.4.3 adevl Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.16.2.2 v8.0 billing IM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.28 cluster (Clustered Environment Monitoring) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.40.3 dns_response Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.53 ha (High Availability) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.65.1.2 v2.3 ibmvm AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.76.2.1 v1.0 journal IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.92 nq_services (NQ Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.102.1.1 v1.6 perfmon AC GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.113 service_host (Service Host) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.122.3.1 v1.3 snmptoolkit IM GUI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.135.5.2 v4.2 url_response AC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.142.4 webservicemon Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5.154.4.1 Recommended zops Alarm Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Join the CA UIM Community today at https://communities.ca.com/community/ca-infrastructu

Alphabetical Probe Articles

Probe Development Tools

Alphabetical List of Probe IDs

Automatic Configuration Engine

Active Directory Response Monitoring

Active Directory Server Monitoring

Active Directory Events Monitoring

ActiveX Data Objects (ADO) Gateway

Apache HTTP Server Monitoring

Application Performance Management Gateway

AppLogic Application Monitoring

AppLogic Platform Grid Monitoring

Maintain Data Structures for Robot Auditing

Automated Deployment Engine

Amazon Web Services Monitoring

Microsoft Azure Monitoring

Capacity Management Data Adapter

Cisco CallManager Monitoring

CPU, Disk, and Memory Performance

EMC Celerra Monitoring

Cisco Hardware Monitoring

Cisco NX-OS Monitoring

Cisco Class-Based QoS Statistics Monitoring

Cisco Unified Communications Manager Monitoring

Cisco UCS Monitoring

Cisco Unity Connection Monitoring

Clustered Environment Support

SLM Database Gateway

Cloud Monitoring Gateway

Data Access and Collection

DB2 Database Monitoring

Data Center Infrastructure Management Monitoring

DHCP Server Response Monitoring

File and Directory Scan

iSeries Disk Monitoring

DNS Response Monitoring

E2E Application Response Monitoring

Email Response Monitoring

Event Management Service

Microsoft Exchange Server Response Monitoring

Microsoft Exchange Monitoring

Microsoft Exchange Monitoring Backend

Microsoft Exchange Monitoring Reports

Retrieve QSYSOPR Messages on iSeries