Support Tools for BSM/OMi Data Collection and Troubleshooting

Support Tools for BSM/OMi Data Collection and Troubleshooting

Here's a list of support tools for BSM/OMi data collection and troubleshooting.

*checkIndices.bat (.sh) *

*Objective *

Check OMi event DB for missing indices. Unlike opr-dbValidator, this tool can also be used to

craete missing indices, or newly introduced indices into OMi DB configuration due to performance

issues.

*Location *

<TOP AZ\_HOME>\opr\support\

*Usage *

usage:
-c,--create
-h,--help
-v,--verbose

Create missing indices.
Help
Verbose output

Running tool without any argument will check index status only without creating if
missing any.

*Supported Versions *

This tool is available for

OMi 9.01 (Hotfix QCCR1A124223 or patch OMI_00010) OMi 9.10 (Hotfix QCCR1A129906)

OMi 9.2x

*QA Testing Scenarios *

Test tool against all available options. Especially worth testing after an upgrade.

 

ciGenerator.bat (.sh)

Objective

Generate a set of sample CIs Location

<TOP AZ\_HOME>\opr\support\

*Usage *

Usage: ciGenerator -h | -file <file> [-customer <id>] [-start <start>] [-count <count>] [-v]

This tool is to be used only for testing purposes by HP Support.

This tool helps generate one or several CIs and relations in UCMDB.

-c,-counter <counter> Counter to set multiplicity. <count>
will determine how many CIs of the same type to create.

-customer <customer>
-f,-file <file>
See example below

-h,-help

-s,-start <start>
suffix. See example below

Customer ID
CI descriptor filename in XML format.
Help
Start identifier to be replaced in XX

The CI and relation candidates are imported from an xml descriptor file
Example for descriptor file:
<?xml version="1.0" encoding="UTF-8"?>
<cis>
<ci name="testnode1" type="nt">
<attribute>name=testnode1_XX</attribute>
<attribute>primary_dns_name=hostname1_XX</attribute>
</ci>
<ci name="testnode2" type="unix">
<attribute>name=testnode2_XX</attribute>
<attribute>primary_dns_name=hostname2_XX</attribute>
</ci>
<ci name="testDisk" type="file\_system">
<attribute>name=testDisk</attribute>
<attribute>root_container=testnode1_XX</attribute>
<attribute>mount_point=/</attribute>
</ci>
<rel type="composition" source="testnode1" target="testDisk"/>
</cis>
The suffix 'XX' will be replaced with numbers indicated in <start> and <count>
arguments

*Supported Versions *

The detailed tool usage is first available with 9.23.

*QA Testing Scenarios *

 

DBReader.bat (.sh)

*Objective *

Reads all events from the database and dumps them as XML on command line or in a file.

Location

<TOP AZ\_HOME>\opr\support\

*Usage *

Usage: DBReader [-f output-file]

Example

DBReader -f OMIEvents.xml

*Supported Versions *

QA Testing Scenarios

 

opr-analyseEventFlow.bat (.sh)

*Objective *

This tool combines several flowtrace logfiles so that events can easily be followed across GWs and DPS. However, it requires considerable processing time when many logfiles are processed: 30 logfiles with a total of ~300000 lines take about 24 hours. Therefore it makes sense to first check which files do contain an interesting event, and run the tool only on those: 5 logfiles with a total of ~45000 lines just run for 3:30 min.

This tool ignores logfile lines that are not flowtrace logs. It is necessary to enable DEBUG logging for GW and DPS flowtrace for the tool to be useful.

*Location *

<TOP AZ\_HOME>\opr\support\

*Usage *

Usage: opr-analyseEventFlow [INPUT_FILE]... [-o <OUTPUT\_FILE>] [-d]
-o Use file <OUTPUT\_FILE> as output
-d order the incidents by time (do not use this if your files come from different

machines)

*Supported Versions *

QA Testing Scenarios

 

opr-certcheck.bat (.sh)

Objective

Check validity of certificates on DPS Location

<TOP AZ\_HOME>\opr\support\

*Usage *

Usage: opr-certcheck [-h] <-u <username>> <-p <password>> [-v] [-version]
-h Print help message
-u user name
-p password
-v verbose output
-version print version information

*Supported Versions *

This tool is available for OMi, version 09.23 and higher

*QA Testing Scenarios *

Test tool against all available options.

 

opr-checker.bat (.pl)

*Objective *

Gather System/OS information (hostname, IP, RAM size) from system and check BSM platform basic

settings, such as component versions, patches, running services, stc. Tool also validates OMi's

connection settings against an OM classic server.

*Location *

<TOP AZ\_HOME>\opr\support\

*Usage *

Usage: opr-checker.bat [-xml][check options]

-xml print the output in XML format available checks:

-sys gather System/OS information (hostname, IP, RAM size, ...)

-bsm check BSM platform basics (version, patches, running services, ...) -opr some more Opr related checks (patchlevel, ...)

-om check OM Sync related stuff (bbcutil -ping, ...)

-all|-a check everything

*Supported Versions *

This tool is available for released versions of OMi (8.10, 9.x)

*QA Testing Scenarios *

Test tool against all available options.

 

opr-check-forwarding.bat (.sh)

Objective

Check all prerequisites required for forwarding OM events to OMi. Location

<TOP AZ\_HOME>\opr\support\

*Usage *

Running tool without any options will do the check.

*Supported Versions *

This tool is available for

OMi 8.10 (Patch OMI_00001 or higher) OMi 9.x

*QA Testing Scenarios *

Test tool just by running it to check forwarding prerequisites.

 

opr-dbValidator.bat (.sh)

*Objective *

Validate OMi's event database (tables, columns or indices) against OMi's OOTB database

configuration.

*Location *

<TOP AZ\_HOME>\opr\support\

*Usage *

usage:
-a,--validateAll
-c,--validateTablesAndColumns
-h,--help
-i,--validateTablesAndIndexes
-t,--validateTablesOnly
-v,--verbose

*Supported Versions *

Validate tables, columns and indexes
Validate tables and columns
Help
Validate tables and indexes
Validate tables only
Verbose output

This tool is available for

OMi 8.10 (Patch OMI_00007)

OMi 9.01 (Hotfix QCCR1A124223 or patch OMI_00010) OMi 9.10 (Hotfix QCCR1A129906)

OMi 9.12 (Patch OMI_00008 Windows, OMI_00009 Linux)

*QA Testing Scenarios *

Test tool against all available options. Especially worth testing after an upgrade.

 

opr-eventCacheComparator.bat (.sh)

*Objective *

Compares active events of multiple Gateway Servers and reports differences in their lifecycle states.

*Location *

<TOP AZ\_HOME>\opr\support\

*Usage *

Usage: opr-eventCacheComparator -s GW-Server:29601* <-u <username>> <-p
<password>> [-sl <sleep>] [-c <count>]

-c,-count
-h,-help
-p,-password
console
-s,-servers <servers>
-sl,-sleep
-u,-username <username>

Example

Count of repetitions
help on this command
Password required for the user to access the JMX
List of servers
Time (s) between repetitions
username

opr-eventCacheComparator -s gw1:29601 gw2:29601 gw3:29601 -u admin -p admin -sl 5 - c2

GW gw1:29601:
40b28848-4ddc-71e3-0a25-1039438b0000(OPEN)
GW gw2:29601:
40b28848-4ddc-71e3-0a25-1039438b0000(OPEN)
GW gw3:29601:
GW gw1:29601:
40b28848-4ddc-71e3-0a25-1039438b0000(OPEN)
GW gw2:29601:
40b28848-4ddc-71e3-0a25-1039438b0000(OPEN)
GW gw3:29601:
**Warning (GW gw1:29601): Found same difference as last time: 40b28848-4ddc-71e3-
0a25-1039438b0000(OPEN)
**Warning (GW gw2:29601): Found same difference as last time: 40b28848-4ddc-71e3-
0a25-1039438b0000(OPEN)

*Supported Versions *

09.23 and newer

*QA Testing Scenarios *

Test tool in a distributed environment with multiple GW servers.

 

opr-export-events.bat (.sh)

Objective

Export events as XML into a file.

*Location *

<TOP AZ\_HOME>\opr\support\

*Usage *

Usage: opr-export-events [-a] [-h] -o <outputFile> [-p <pageSize>] [-q <query>] [-s
<server>] [-ssl] [-u <username>]

-a,-all

-h,-help
-o,-outputFile <outputFile>
-p,-pageSize <pageSize>
-q,-query <query>
-s,-server <server>
-ssl,-ssl
-u,-username <username>

Example

export all event properties and include
closed events
help on this command
output file
page size to use for a single request
additional query options
BSM server to connect to
use SSL to connect

username

opr-export-events -o OMiEvents.xml -u admin

*Supported Versions *

QA Testing Scenarios

 

opr-impactChecker.bat (.sh)

*Objective *

Tool to check whether there is an impact relationship defined in the uCMDB between two given CIs.

There are three possible outputs:

1.

"Linkexists"incasethereactuallyisanimpactrelationshipbetweenthetwo provided CI instances

2.

"Linkdoesnotexist"incasethereisapossibilityforanimpactrelationship between the two CI types, but the actual instances do not have this relation

3.

<NoOutput>incasethereisnoteventhepossibilityforanimpactrelationship between the two give CIs.

*Location *

<TOP AZ\_HOME>\opr\support\

*Usage *

usage: opr-impactChecker -h | -cis <ciID1> <ciID2> [-customer <id>] [-v]

|
 
|

This tool is not to working properly in OMi 09.22 and always returns a "Missing required option..." error. This will be fixed for OMi 09.23.

|

-cis <cis>

-customer <customer>
-h,-help

-v,-verbose

Two IDs of CIs to check for impact
relationship.
Customer ID.
Print this message and exit.
Print verbose output.

-version Print the version information and exit.

Example

opr-impactChecker -cis 9e76bafea39c49e786360baeb2551fd7
ba784c64577d49ab8a5c4e3194199d02
INFO: Connected to UCMDB
INFO: Link exists : relation "containment" from "srv0" to "16.57.65.89"

*Supported Versions *

*QA Testing Scenarios *

 

opr-jmsQueueCleaner.bat (.sh)

*Objective *

Sometimes it even helps to simply ping the Sonic queues with the opr- jmsQueueCleaner.bat.

Sometimes Sonic just hangs and doesn't tell opr-backend there are some events in the queue. By just running this additional tool that looks into the queue Sonic suddenly recognizes there are events and will deliver them to opr-backend again. For this it should be sufficient to just run it with "-c 1" or even without any option.

*Location *

<TOP AZ\_HOME>\opr\bin\

Usage

Usage:
-a,--acknowledge Remove messages from queue
-c,--count <count> Maximum number of messages
--customer <customer> Customer (default: 1)
-h,--help Help

If you want to have a look at what's stuck in the queue you can turn on DEBUG logging for opr-cli and the opr-cli.log should then have the details of each event read.

 

opr-jmsUtil.bat (.sh)

*Objective *

Utility to monitor the number of messages and the size of the Sonic JMS bus queues and topics.

*Location *

<TOP AZ\_HOME>\opr\support\

Usage

Usage: opr-jmsUtil [-c <containerName>] [-b <brokerName>] [-n <number>] [-w
<waittime in seconds>]

-b,-brokerName <broker\_name>
-c,-containerName <container\_name>
-h,-help
-n,-number <number>
-w,-waittime <waittime>

Example

opr-jmsUtil
opr-jmsUtil -n 10 -w 10

*Supported Versions *

QA Testing Scenarios

 

opr-jmxClient.bat (.sh)

Objective

JMX console command line client. Location

<TOP AZ\_HOME>\opr\support\

*Usage *

Name of the Sonic Broker
Name of the Sonic Container
Help
number of status updates
seconds to wait between status
updates

Usage: opr-jmxClient -system host:port -user <user> [-password <password>] -bean
<bean> -method <method> [-arguments <argument>*]

-a,-arguments <arguments>
-b,-bean <bean>
-h,-help
-m,-method <method>
-p,-password <password>
-s,-system host:port
-u,-user <user>

Examples

List of arguments that are passed to the MBean
method
MBean to be used
Display help text
MBean method to be executed
Password required for the user to access the
JMX console
Host name and port for the JMX console
User required to access the JMX console

opr/support/opr-jmxClient.sh -a OPR -b "Foundations:type=NannyManager" -m showStackTrace -u admin -p admin -s manxhund.deu.hp.com:11020 opr/support/opr-jmxClient.sh -b "opr.console:name=BusinessLogicDelegateMBean" -m reinitIncidentCache -u admin -p installed -s vmbert1.deu.hp.com:29601 opr/support/opr-jmxClient.sh -b "com.hp.opr.backend.maintenance.ArchiveEventsMBean" -m triggerArchiveEvnts -u admin -p admin -s manxhund.deu.hp.com:29622

As you can see, the JMX port numbers differ from the HTML JMX console port numbers. For example:

HTML JMX console direct JMX port authenticate with

nanny 11021 mercuryAS 8080/jmx-console

11020 MX4J admin 29601 JBoss admin 29622 MX4J admin 29604

RTSM admin

OPR wde RTSM

29922

29904 21212/jmx-console

*Supported Versions *

QA Testing Scenarios

 

opr-support-utils.bat (.sh)

*Objective *

Manage several troubleshooting scenarios, enumerating from bsm and omi related infrastructure

settings management via command line, especially when BSM is offline to monitoring OMi event

pipeline and process status in whole BSM:

*Location *

<TOP AZ\_HOME>\opr\support\

*Usage *

Usage: opr-support-utils -help [-h]
Setting Utility:

License Checker:
Process Status Util:
<hprofFilePath>
Hac Status Lister:
Retrieve uCMDB Capacity:

-list_contexts
-list_settings -context <name>
-get_setting -context <name> -get <name>
-set_setting -context <name> -set <name> <value>
-listOmiLicenseInfo
-listBacLicenseInfo
-startAll
-stopAll
-start <servicename>
-stop <servicename>
-restart <servicename>
-getServiceInfo [-gi] <servicename>
-generateThreadDump [-gtd] <servicename>
-generateHeapDump [-ghd] <servicename> -file
-listAllServicesStatus [-ls]
-listStatusAsHTML [-lh]
-listHacStatus

-retrieve

Event Pipeline Statistics:
-reset
-getReport [-gr]

*Supported Versions *

This tool is available for all released versions of OMi (8.10, 9.x). Option for thread and heap dump generation per process is first available in 9.23 IP1 and in 9.22 IP2 Rollup HF 5

*QA Testing Scenarios *

Test tool against all available options.

 

ovinventory.bat (.sh)

*Objective *

Returns a list of all installed HPOv* (OpenView) packages.

*Location *

<TOPAZ\_HOME>\opr\support\ (Linux, only)

*Usage *

usage: . ./ovinventory.sh [ -graphical ]
[ -text ] <outputFile>
[ -xml ] <outputFile>
[ -html ] <outputFile>
[ -help ]
[ -config <config\_filename> ]
"-gra | -graphical" Start the Java GUI to display packages
"-cc" Display Common Components Only
"-all" Display All Components
"-text" Text Output

"-xml" Xml Output

"-html" Html Output

"-help" Print this usage message.

Example

./ovinventory.sh

*Supported Versions *

QA Testing Scenarios

 

sendEvent.bat (.sh)

*Objective *

Sending OMi test events.

Remark: Custom attributes like NodeInfo will not be processed. Use options -nh, - rch, etc. instead!

*Location *

<TOP AZ\_HOME>\opr\support\

*Options *

[-mm|-magicMode ]

[-s|-severity <Severity>]

[-pr|-priority <Priority>]

[-eh|-etiHint <ETI> <ETIValue>]

[-ca|-customAttribute <Name> <Value>]

[-aa|-automaticAction <Action> (AVAILABLE | RUNNING | SUCCEEDED | FAILED) <Host>] [-oa|-operatorAction <Action> (AVAILABLE | RUNNING | SUCCEEDED | FAILED) <Host>] [-g|-gateway Gateway:Port]

[-t|-title <Title>]

[-nd|-nodeDnsName <DNS-Name>]

[-ni|-nodeIpAddress <IP-Address>]

[-d|-description <Description>]

[-c|-category <Category>]

[-sc|-subCategory <SubCategory>]

[-rch|-relatedCiHint <CI Info>]

[-nh|-nodeHint <Host Hint>]

[-sch|-sourceCiHint <Source Hint>]

[-ty|-type <Type>]

[-p|-prop <PropertiesFile>]

[-n|-number <Number>]

[-m|-mult <Multiplicity>]

[-nci|-nodeCoreId <Agent Core Id>]

[-k|-key <Correlation Key>]

[-ckp|-closeKeyPattern <Correlation Key Pattern>]

[-nds|-noDupSupp ]

[-lo|-logOnly ]

[-sid|-omServiceId <OM Service ID>]

[-odns|-originatingServerDNS <Originating Server DNS Name>] [-oip|-originatingServerIP <Originating Server IP Address>] [-ocid|-originatingServerCoreID <Originating Server Core ID>]

[-sol|-solution <Solution>]

[-a|-application <Application>]

[-o|-object <Object>]

[-tr|-trace true|false]

Example

sendEvent -t Test -s normal

sendEvent -t TestEvent -d "Test: Database Performance Low" -s warning -nh oml- db.mambo.net -rch orcl -eh DatabasePerformance Low

*Supported Versions *

*QA Testing Scenarios *

 

submitEvent.bat (.sh)

Objective

Sending OMi test events.

Remark: Similar to 'sendEvent' but 'submitEvent' will not utilize the gateway and put the events directly on the Sonic bus to be further processed by the OMi backend on the data processing server. Custom attributes like NodeInfo will not be processed. Use options -nh, -rch, etc. instead! 'submitEvent' is only located on the data processing server!

*Location *

<TOPAZ\_HOME>\opr\support\ (DPS only)

Options

-h|help | -v|-version | [<customer>] <option> ...
-h|-help : print usage
-v|-version : print version
customer (optional, default=1): -cu|-customer <id> : customer ID
options:
-f|-file <name> : read commands from file
one command per line, either <cmd> or <cmd>:<arg>
-<cmd> : command without argument
-<cmd> <arg> : command with argument

This tool allows to submit one or multiple events into the event system. All events are first collected in a list, which will finally be submitted in one bulk.

Command can be specified either as command line options or read from a file.
Two types of commands can be used:
- attribute commands: set attributes of the current event
- control commands: used to collect and submit events
attribute commands:
c|category <arg> : set category of current event
ckp|closeKeyPattern <arg> : set close-key-pattern of current event
ca|customAttribute <arg> : set a custom attribute of current event

tc|timeCreated <arg>
d|description <arg>
eh|etiHint <arg>
k|key <arg>
lo|logOnly <arg>
nh|nodeHint <arg>
od|originalData <arg>
rch|relatedCiHint <arg>
scid|subComponentId <arg>
s|severity <arg>
sch|sourceCiHint <arg>
sc|subCategory <arg>
t|title <arg>

arg with format <cma-name>=<value>
: set creation date and time of current event
using format 'MM/dd/yyyy HH:mm:ss'
: set description of current event
: set ETI hint of current event
: set key of current event
: set log-only flag of current event

arg starts with t or T: true, else false : set node hint of current event

: set original data of current event

: set related CI hint of current event

: set sub component ID of current event

: set severity of current event

arg: NORMAL|WARNING|MINOR|MAJOR|CRITICAL
: set source CI hint of current event
: set sub-category of current event
: set title of current event

tr|trace <arg>
control commands:
n|next
sw|submitWait [<arg>]

Example

: set tracing of current event: true|false
: add next event to list
: submit all events in list as bulk,
optionally wait <arg> milliseconds

submitEvents -t Test -s normal -ca DemoCA=TestVal

*Supported Versions *

QA Testing Scenarios

 

what.bat (.sh)

*Objective *

Used by CPE to stamp official hotfixes with its output. The tool is very useful to retrieve

manifest information from jar/war/ear files.

*Location *

<TOP AZ\_HOME>\opr\support\

*Usage *

Usage: what.bat <filename>

*Supported Versions *

This tool is available for

OMi 8.10 (Patch OMI_00001 or higher) OMi 9.0x and OMi 9.1x

*QA Testing Scenarios *

Test tool against an existing jar/war/ear file to retrieve the version information. 

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk