Knowledge ArticleBest Practices for making changes to an active Manager run in BMC Performance Assurance for Servers

Back to Answers Printer Friendly Rate this Page

Knowledge Article ID:  KA310873

Version:  1.0

Status:  Published

Published date:  01/20/2011

 

ProblemThe goal of this document is to cover how to make changes to an active Manager run, which changes require a Manager run

to be resubmitted, and when changes will be applied to an active Manager run.

NOTE: This document was originally published as Solution SLN000000168714.

BMC Performance Assurance for Servers  7.4.10,  7.4.00,  7.3.00,  7.2.00

Unix

Solution

Section I: Overview

There are 4 scripts executed by an active Manager run that collects, processes, and transfers data. These are:

The [date]-[date].Manager script (Jan-01-2004.00.00-Dec-31-2004.23.59.Manager)

o The .Manager script is created when a Manager run is submitted and the same script is used for the

entire duration of the Manager run

o The .Manager script is scheduled to run 'COLLECT_LEAD_TIME' minutes before the start of data

collection. By default the COLLECT_LEAD_TIME is 30 minutes and is configurable under Options -> Collect

tab -> "Run script before collection time". In Perform version 7.1.20 and earlier the .Manager script was

executed 15 minutes before data collection start time.

o The .Manager script creates and schedules all of the other scripts used for data collection, data transfer,

and data processing

o The .Manager script will remove itself from cron/pcron when the End Date of the Manager run has been

reached

o In Perform version 7.2.00 and later the *.Manager script executes the udrCollectMgr processes which

handle data collection and data transfer for the Manager run

The [date]-[date].Collect script (Jan-01-2004.00.00-Jan-01-2004.23.59.Collect)

o A new .Collect script is created each day by the .Manager script

o In Perform version 7.2.00 and later, the *.Collect script's only purpose is to ensure that there is a

udrCollectMgr process running for the Manager run. It will run every 'Collector restart interval' minutes and

start a new udrCollectMgr process to take over data collection and data transfer for the run if one isn't

already running.

o In Perform version 7.1.20 and earlier, the .Collect script is scheduled to run at the specified start time of

data collection. So, if data collection is scheduled to run from 00:00 to 23:59 the .Collect script will be

scheduled to run each day at 00:00. The data collection start time is controlled by the Daily Begin field in

Manager.

o In Perform version 7.1.20 and earlier, the .Collect script will remove itself from cron/pcron when it has

finished starting data collection

o In Perform version 7.1.20 and earlier, if Collector Restart is enabled in Manager, after the .Collect script

has started data collection it will reschedule itself as the '[date]-[date].Collect query' script. This script will run

every 'Restart Interval' (by default 15 minutes) to query each remote node to ensure that data collection is

running.

The [date]-[date].XferData script (Jan-01-2004.00.00-Jan-01-2004.23.59.XferData)

o A new .XferData script is created each day by the .Manager script

o The .XferData script is scheduled by Manager to run Processing Delay minutes after data collection has

completed. So, if the Options => Advanced Features => Other => Processing Delay is set to 10 minutes (the

default) and the Daily End is set to 23:59 then the .XferData script will be scheduled to run at 00:09 (10

minutes after data collection completes)

o The .XferData script will remove itself from cron/pcron when it has finished all data transfer attempts

o The .XferData script executes the .ProcessDay script when all data transfer attempts have been

executed, or when all expected data is present on the managing node (whichever comes first)

o In Perform version 7.2.00 and later the purpose of the *.XferData script is to check if all data has been

transferred to the console by the udrCollectMgr process or if the Transfer Duration has elapsed. Once either

of those two events has happened it will execute the *.ProcessDay script.

The [date]-[date].ProcessDay script ((Jan-01-2004.00.00-Jan-01-2004.23.59.ProcessDay)

o A new .ProcessDay script is created each day by the .Manager script

o The .ProcessDay script is executed by the .XferData script after data transfer is complete (or time has

expired)

Section II: Making changes to a Manager run

The rule: You should only press the green activate button in the Manager GUI when scheduling a new Manager run.

Do not press the activate button again after making modifications to an active Manager

Each night the .Manager script will read all of the files that define your Manager run. This includes:

Your .vcmds file

The Workload definition file (.an file) specified for the run

All the Domain files (.dmn files) specified for the run

What that means is that any changes made to the .vcmds, .an file, or .dmn file will propagate into the next execution of the Manager run without it being re-activated.

The changes will be propagated into the Manager run when the new scripts are created at night. But,

keep in mind that all of the scripts for a day of data collection and data processing are created at the same time - 15 minutes before data collection begins. What that means is that changes to data collection will be seen starting with the data collection run on the night of your change, but changes to data processing will occur the next night.

So, if a change is made to a Manager run that collects data from 00:00 to 23:59 and has a 31 minute processing delay:

Change made Seen for data collection Seen for data processing

Jan 1, 2004 @ 10:00 Jan 2, 2004 @ 00:00 Jan 3, 2004 @ 00:30

So, if on January 1st at 10:00 a new workload is added to the .an file for a Manager run, the new workload will not appear in

Visualizer until January 3rd (it will be applied to the data collected on January 2nd). The reason is that the data processing

scripts for the data collected on January 1st have already been created. So, even though the workload characterization has

changed, the .ProcessDay script that is scheduled to run that night has already been created with the old workload

characterization.

Changes to some Manager options require that the run be stopped and restarted

There are some fields in a Manager run that should not be modified until the old Manager run is stopped and restarted.

These fields are:

The 'Output Files Directory' from the Main Manager GUI -> Data tab

The 'Data Source' toggle from the Main Manager GUI -> Data tab

The 'Start Date' from the Main Manager GUI -> Schedule tab

The 'End Date' from the Main Manager GUI -> Schedule tab

The 'Use time stamp for output directory' button from the Options -> Advanced Features -> Other tab

All other fields within the .vcmds file can be modified without stopping and restarting the Manager run. All fields in the .an file

and .dmn files can be modified without stopping and restarting the Manager run.

Section III: Frequently Asked Questions

Question 1

Is there an easy way to make changes to a Manager run and have them applied to the run immediately. For example

add a node for data collection at 10:00 and have it start collecting data immediately and process that data that

night? What about add a workload to the .an file and have it process today's workload with that new workload

characterization?

Unfortunately there is no easy way to get a change applied to a Manager run immediately. The files that define the base

Manager run (.vcmds file, .an file, .dmn files) are only referenced when the scripts are created at night. From that point

forward the run is controlled by files in the Manager output directory such as the [date]-[date].Variables file, the [date]-

[date].NItable file, and the scripts themselves. For that reason adding a node to the domain (.dmn) file won't have any effect

on the active Manager run because the active node list is stored in the [date]-[date].NItable file. Likewise, adding a workload

to the Workload definition (.an) file won't have any effect on the active Manager run because the workload definition that will

be used is store within the .ProcessDay script itself.

Question 2

Is there any way to stop and restart a Manager run in such a way that all collected data (the data from the beginning

of the day collected by the old Manger run, and the data collected after the Manager run has been restarted) will be

processed by the new Manager run which includes my desired change?

There is no seamless way to do this.

In Perform version 7.2.00 and later it is possible but it isn't simple. Once you've made you change to the Manager vcmds file,

Domain (dmn) file, or Analyze Commands (.an) File you would need to do the following:

1. Put a run.quit file into the existing Manager Output Directory for the run.

2. Find the running udrCollectMgr process from the Manager run you just stopped and kill it.

3. Rename the *.vcmds file to a new name.

4. Submit the Manager run under the new vcmds file name with a start date of today's date without changing the start

time of data collection (so if it was 00:00 leave it at that).

In general changes to your Manager run are best handled when you can wait a 24-hour period for the change to take effect.

In Perform version 7.1.20 and earlier there is no easy way to do that. Stopping the original Manager run will cause the data

collected by that Manager run to be left on the remote node (as the new Manager run will not know the data exists and will

thus not transfer it). Hence, the only data that will be processed and available in Visualizer will be the data collected from the

time that the new Manager run was activated.

Question 3

What happens if I don't deactive my existing Manager run but do press the green active button after making

changes to its .vcmds file?

In Perform version 7.2.00 and later the Manager GUI should reject your attempt to reactive the already active Manager run.

In Perform version 7.1.20 and earlier there will be two Manager runs using the same .vcmds file active. That means that

each Manager run will attempt to issue data collection requests for the same set of nodes, process the data from the same

set of nodes, and create Visualizer files for the same set of nodes. This will certainly result in wasted processing time, but

can result in other problems as well. It is best to ensure that only one Manager run is active for any .vcmds file. Until one of

the Manager runs is stopped there will be two Visualizer files created having the same name and containing the same data

but in different Manager output directories.

Question 4

If I absolutely need a change to occur in my Manager run immediately, what can I do?

First, ask yourself, "Why do I need this change to happen immediately? Why can't I wait 24 hours for this to happen?" Trying

to make a change that happens immediately will introduce a great deal of unnecessary risk into your environment since it

isn't well support and could mean the entire Manager run will fail.

There are two basic options at this point:

A. If you are willing to lose data from the current day for the period before the change was made, stop and restart

your Manager run. Data collection will start on the next whole hour and whatever change was made will be part of

this new Manager run. The data collected from before the change will never be transferred to the managing node

and it won't be processed by the re-activated Manager run. You must stop the previously activated Manager run or

data will be double processed - the whole day by the original Manager run and the part of the data including your

change by the new Manager run. That means that the data from whichever run finishes last will end up being

populated into Visualizer (which will typically be the original run - not what you want).

B. If you cannot lose any data you should contact Technical Support for suggestions. Technical Support may be able

to suggest the necessary modifications to the existing configuration files in the Manager Output Directory to apply

the change you want to make to the existing Manager run. This is somewhat risky as incorrectly applied changed

could cause data processing to fail. For Perform version 7.2.00 and later, see the answer to 'Question 2' for an

overview of what you need to do.

Knowledge ArticleHow can I change nodes with missing metric groups from Warnings to OK state in UDR Collection Manager (UCM) status reports?

Back to Answers Printer Friendly Rate this Page

Knowledge Article ID:  KA295604

Version:  1.0

Status:  Published

Published date:  01/20/2011

 

ProblemHow can I change nodes with missing metric groups from Warnings to OK state in UDR Collection Manager (UCM) status

reports?

This document was originally published as Solution SLN000000203444.

BMC Performance Assurance for Virtual Servers  7.5.00,  7.4.10,  7.4.00,  7.3.00,  7.2.00

BMC Performance Assurance for Servers  7.5.00,  7.4.10,  7.4.00,  7.3.00,  7.2.00

Unix console

Windows console

Solution

Section I: Introduction

In the Collector Status Reporting (CSR) reports nodes and domains can be in one of three different states: OK, Warning, or

Failed. A node will be assigned an 'OK' state for data collection if data collection has been successfully started on the

remote node and data is being collected for all configured metric groups. A node will be assigned a 'Warning' state for data

collection if data collection has failed to start on the remote node, or if data collection has failed for one or more configured

metric groups on the remote node. A node will be assigned a 'Failed' state for data collection after data collection has failed

and the time for all configured retries have passed.

By default, it is quite likely that some configured metric groups will not be collected on almost every node. For example, the

Solaris collector will attempt to gather the 'SRM Statistics' group which will only be enabled on machines using the Solaris

Resource Manager. Each operating system has at least one group that is unlikely to be collected on the majority of the

machines in an environment. This means that almost all nodes will be assigned a 'Warning' status for data collection. Even

nodes where data collection has been requested but the Perform product isn't even installed will be assigned a 'Warning'

status for most of the day because by default UDR Collection Manager (UCM) will continue to issue a start collection request

(if previous ones have failed) over the first 90% of the collection interval (just under 22 hours). This means that in order to

make the collection status useful a mechanism is needed to filter the groups that are known to be uncollectible on a

machine. This will allow nodes with successful collection (collecting the configured groups we believe they should collect) to

appear in 'OK' state and those with collection problems will appear in 'Warning' state. This is where the udrCollectFilter

command comes in.

Section II: Running udrCollectFilter for a specific node against a specific collection interval

During normal data collection when the remote node is able to communicate back to the console on port 6768 the remote

node will send status messages to the console indicating data collection problem. The messages are reported in the

Collection Status Reporting (CSR) reports under the 'Messages' section of each nodes status page. For example, here are

some messages for a node called 'topgun':

  Thu May 19 23:30:06 2005 [UCM-Information] Collect request sent from console and received by the agent  Thu May 19 23:30:06 2005 [Agent-Information] Collect Request - Data Collection pending  Fri May 20 00:00:00 2005 [Agent-Information] Collect Request - Data Collection active  Fri May 20 00:00:15 2005 [Agent-Information] Collect Request - Agent repository write active  Fri May 20 00:00:25 2005 [Agent-Warning] Metric group not supported SRM Statistics

These messages indicate that topgun received and accepted a data collection request from the console at 11:30 PM, started

collecting the data at midnight, and notified the console that data for the 'SRM Statistics' group was requested, but is not

being collected on the machine. This missing group causes the node to appear in 'Warning' state in the CSR reports.

The udrCollectFilter command can be used to tell the CSR reports that the missing 'SRM Statistics' group is acceptable for

this node. The command to run is:

  > $BEST1_HOME/bgs/bin/udrCollectFilter -d Mar-16-2006 -n topgun

This will create a file called 'topgun.flt' in the /usr/adm/best1_default/local/manager/filter directory on the console using the

groups that were not collected on March 16th 2006. The '-d MM-DD-YYYY' flag is optional. If the -d date flag is not specified

then all groups that have failed to collect at any point will be included in the nodes filter file.

The contents of the topgun.flt file created by the udrCollectFilter command is in this case just a single line:

  "SRM Statistics"

This indicates that if the agent on node 'topgun' reports that the 'SRM Statistics' metric group isn't being collected that is OK,

and the node can be reported in 'OK' state rather than 'Warning' state. If some time in the future another group were to stop

being collected node 'topgun' would be reported in 'Warning' state again. Using udrCollectFilter enables specific groups to

be filtered while maintaining the alerting feature if another group unexpectedly stops being collected.

NOTE: You should only run udrCollectFilter against a data collection request that has completed to get a complete list of

groups to be filtered. Group that haven't been terminated by the collector but contain no data will not show as unavailable

until data collection has completed.

NOTE: By default udrCollectFilter will not overwrite an existing filter file for the node. You must specify the '-r' flag to force an

existing filter file to be overwritten.

Section III: Running udrCollectFilter against all nodes

The udrCollectFilter command can also be run to create filter files for all nodes that have sent messages to the console. The

command to run udrCollectFilter against all nodes is simply:

$BEST1_HOME/bgs/bin/udrCollectFilter

If there is already an existing [hostname].flt file for a node the udrCollectMgr process will not overwrite it. Instead it will only

create new [hostname].flt files. If you wanted to overwrite existing [hostname].flt files it would be necessary to specify the '-r'

flag.

Section IV: Inadvertently masking real problems with udrCollectFilter

The udrCollectFilter command will create filter entries for any metric groups which currently aren't being collected on a

machine. That means that if udrCollectFilter is run against a machine that is having collection problems critical groups may

be added to the filter list for that machine.

For example, here are messages for node 'topcat':

  Wed May 18 23:30:04 2005 [UCM-Information] Collect request sent from console and received by the agent  Thu May 19 00:24:42 2005 [Agent-Information] Collect Request - Data Collection active  Thu May 19 00:24:57 2005 [Agent-Warning] Metric group currently has no data available for collection Cpu Statistics

  Thu May 19 00:24:58 2005 [Agent-Warning] Metric group not available PRM Configuration  Thu May 19 00:24:58 2005 [Agent-Information] Collect Request - Agent repository write active  Thu May 19 23:59:19 2005 [Agent-Information] Collect Request - Data Collection Complete  Thu May 19 23:59:19 2005 [Agent-Warning] Collect Request - Data not collected for metric group Cpu Statistics  Thu May 19 23:59:19 2005 [Agent-Warning] Collect Request - Data not collected for metric group Raid Configuration  Thu May 19 23:59:19 2005 [Agent-Warning] Collect Request - Data not collected for metric group Raid Statistics  Thu May 19 23:59:19 2005 [Agent-Warning] Collect Request - Data not collected for metric group User Id Statistics  Thu May 19 23:59:19 2005 [Agent-Information] Collect Request - Processing complete  Fri May 20 00:04:02 2005 [UCM-Warning] No data collected for some of the configured metric groups  Fri May 20 00:04:08 2005 [UCM-Information] Collect Request - Agent data transfer successful  Fri May 20 00:04:08 2005 [UCM-Information] Collect Request - Data deleted in Agent repository

Running udrCollectFilter will create a topcat.flt file that looks like this:

  "PRM Configuration"  "Cpu Statistics"  "Raid Configuration"  "Raid Statistics"  "User Id Statistics"

Note that the 'Cpu Statistics' group is included in that list. That could be the sign of a data collection problem on the machine

which should be investigated. If it were determined that 'Cpu Statistics' shouldn't be filtered then the

/usr/adm/best1_default/local/manager/filter/topcat.flt file could be edited and the 'Cpu Statistics' line could be deleted. This

would cause the node to report in Warning state for the 'Cpu Statistics' group until the problem was resolved.

By default udrCollectFilter will not overwrite an existing filter file for the node. You must specify the '-r' flag to force an

existing filter file to be overwritten.

Section V: Development documentation

Here is some documentation created by Development during the design of udrCollectFilter which describes some of the

command line options available.

Creating baseline filters

(command format: udrCollectFilter [–n "computer_name"] [–d "date"] ] [ -b "best1_home"] [ -r] ) From the udrCollectFilter

command line an option can be set to cause creation of filter files. A filter file will be created in the filter’s directory for each

unique node in the event log directory. Each event log file (and any backups) will be read and we will add one line per

unique group in the file. Use of the –n option will allow creation/update of a single computer. Use the –d option to specify a

date restraint - to use only results for a specific date.

Use of the –r option will cause overwrite of any existing filters found. Default behavior is to create only those filters that aren’t

already present.

Example:

Mdow1.flt"NT Internet Info Services Statistics""NT NetBEUI Statistics""NT NetBEUI Resource Statistics"

3.1.4 Filtering

With the existing collection status report we have had many requests to avoid displaying the status of computers with certain

missing groups as warnings. This should be done on the console side by allowing a user to specify what groups they wish to

ignore. It would also be beneficial to allow a user to create a baseline filter from existing results. 

A filter file per node (for 7.1.01 computers and later) will be added to the new BEST1_HOME/local/manager/filters directory.

The name of the computer will be used for the filename. Each file will contain a list of groups that will be ignored - one group

per line.

It will also be possible to specify a "global" filter per platform. This will allow a user to specify one set of groups that will be

used whenever a computer with missing groups is examined and no filter file for that computer is found. There will be one

UNIX file bmc-UNIX.flt and one Windows file bmc-Windows.flt. These files will only be used when a computer level filter file

is not found.

The UDR collection manager component will utilize this information and when missing groups are encountered, it will

compare them against the filtered groups. If all groups are accounted for, then no warning status will be reported. The status

report will display the OK health in the "Collect" column. The number of groups filtered will be shown on the status page in

the request details section.

Legacy ID15063344 SLN15063344 SLN000015063344 20000760

Knowledge ArticleHow can Perform UDR capacity planning data be manually transferred from the remote agent node to the Perform console server?

Back to Answers Printer Friendly Rate this Page

Knowledge Article ID:  KA340164

Version:  1.0

Status:  Published

Published date:  01/20/2011

 

ProblemProcesses available for manually transferring the Perform capacity planning data from the Perform remote agent server to

the Perform console server when manager run does not successfully transfer the data.

NOTE: This Knowledge Article was originally published as Resolution 210290.

BMC Performance Assurance for Microsoft Windows Servers  7.5.00,  7.4.00,  7.3.00,  7.2.00

BMC Performance Assurance for Unix  7.5.00,  7.4.00,  7.3.00,  7.2.00

Manager

Solution

Section I: UNIX Perform Console Options

There are three options available to recover from a failed data transfer for all supported releases of Perform and one

additional option for Perform version 7.4.10 and later:

A. For Perform version 7.4.00 and later only: Re-run the [date]-[date].XferData script with the '-r' flag.

B. Use the UDR Collection Manager (UCM) command line utility to recover the Manager run that failed to

transfer the data.

C. Transfer the data using the best1collect run command from the command line

D. Manually transfer the data using an external tool such as ftp or scp

For Perform version 7.4.00 and later

Option A: For Perform version 7.4.00 and later: Re-run the [date]-[date].XferData script

The [date]-[date].XferData script supports a new '-r' recovery option to allow it to automatically recover failed data transfer

and initiate data processing.

If the *.XferData script is being kept in the Manager Output Directory (not automatically deleted) after the Manager run

completes it can be re-run to re-transfer and then execute re-processing for the Manager run.

For example, to re-try data transfer for the Manager run in the '/bmc/perform/manager/run1/Mar-16-2008.15.16' Manager

Output Directory for the April 24th 00:00 - 23:59 Manager run:

  /bmc/perform/manager/run1/Mar-16-2008.15.16/Apr-23-2008.00.00-Apr-23-2008.23.59.XferData -r &INFO: Thu Apr 24 13:06:13 CDT 2008 XferData Starting UDRCollectManager in recovery mode.udrCollectMgr: manager run was initiatedINFO: Thu Apr 24 13:06:13 CDT 2008 XferData Recovery RC=0, Run is initiated..INFO:Thu Apr 24 13:06:14 CDT 2008 XferData recovery started.udrCollectMgr: time is expired for manager runudrCollectMgr: manager run is registered and complete for date specified

The [date]-[date].XferData script will initiate udrCollectMgr processes to handle the data transfer and then once the transfer

phase is complete it will initiate the [date]-[date].ProcessDay script to re-process the data.

For all supported releases of Perform (including 7.4.00 and later)

Option B: Use the UCM Command Line Utility

To recover failed data transfer using the UCM command line executable:

  $BEST1_HOME/bgs/bin/udrCollectMgr -b /usr/adm/best1_default -d MM-DD-YYYY -v /path/name.vcmds -r

For example:

  $BEST1_HOME/bgs/bin/udrCollectMgr -b /usr/adm/best1_default -d 04-23-2005 -v /home2/best1data/files/topgun_daily.vcmds -r

The -r parameter restarts Manager runs that have been aborted, or runs that are already complete. Specify this option along

with the required run date and the script file name (VCMDS), which identifies the run.

When run after the run has finished (so in transfer recovery mode) the command will only attempt to re-transfer data from

the nodes defined as part of the specified Manager run that failed to transfer data previously. It will not attempt to re-transfer

data from nodes that already successfully sent their data to the console.

Option C: Transfer the data using the best1collect

Transfer the data using the best1collect command from the command line. However, this method requires that you know a

good deal about exactly where the data resides on the remote computer. 

The following is an example of the command:

$BEST1_HOME/bgs/scripts/best1collect -n [NODENAME] -B [BEST1_COLLECT_HOME] -d [REMOTE_DATA_REPO] -D [MANAGING_NODE_DATA_REPO] -b [DATE_TIME_STAMP_DIR] -p PUSH

$BEST1_HOME; Generally specified as /usr/adm/BEST1_nn, where nn is the product version number

-n NODENAME; The hostname of the agent node

-B BEST1_COLLECT_HOME; Generally specified as /usr/adm/BEST1_nn.

-D MANAGING_NODE_DATA_REPO; The data repository on the managing node (where you want the data to end up)

-b DATE_TIME_STAMP_DIR; The date/time stamp directory where the data resides on the agent node. This is in the format

Mmm-dd-yyyy.hh.mm - for Manager run started data collection, hh.mm will typically be '00.00' (midnight).

-p PUSH|PULL; The type of data transfer to use. A PUSH type transfer will delete the data from the agent node after the

transfer is complete. A PULL type transfer will not delete the data from the agent node. Use PUSH unless a firewall prevents

the PUSH type transfer from working properly. More information regarding data transfer in Perform can be find in Resolution

140635.)

The following is an example of the command that would transfer the data from a UNIX agent computer that would transfer

data from the /usr/adm/BEST1_nn/collect directory (where nn is the product version number) on the agent computer topgun

to the /BEST1data directory on the managing node:

> $BEST1_HOME/bgs/scripts/best1collect -n topgun -B /usr/adm/best1_7.2.00 -d /usr/adm/best1_default/collect -D /best1data -b Sep-23-2004.00.00 -p PUSH

For a Windows agent computer, use the same parameters but specify Windows paths instead, as shown in the following

example:

> $BEST1_HOME/bgs/scripts/best1collect -n winmachine -B "C:\\Program Files\\BMC Software\\PATROL3\\BEST1\\7.2.00" -d "C:\\Program Files\\BMC Software\\PATROL3\\BEST1\\7.2.00\\History" -D /best1data -b Sep-23-2004.00.00 -p PUSH

For Windows, make sure that if there are spaces in the paths that the command line parameter is enclosed in double-quotes

(as in the example above). Also ensure that the directory separators are specified as two backslashes, not a single

backslash. The following is an example of the messages you might receive for a successful transfer request:

best1collect on [managing node]: requesting a push of collected data via the Service Daemon...Node : [remote node]. Start from: Mon Mar 18 00:00:00 2002.Sun Dec 8 15:12:19 2002*Node: [agnent node] has acknowledged Push request successfully.

Option D: Manually transfer the data

Transfer the UDR data using an external transfer tool if necessary.

Section II: Windows Perform Console

The PATROL Perform Manager on the Windows managing console assumes that the data is already present on the

managing node when executing a Manager run that uses the Use existing data option. Therefore, you need to use another

method to get the data to the managing node before running Manager again to reprocess the data.

Option A: For Perform version 7.4.00 and later: Use the 'Recover' option in the GUI

In Perform version 7.4.00 and later there is a new 'Recover' option in the Perform console Manager 'Schedule' GUI to

recover data transfer and data processing.

Step 1

Open the Perform console and select the Manager -> Schedule object in the left-pane. That will bring up the Manager

Schedule list.

Step 2

Select the target Manager run for transfer recover. Right-click and select 'Recover' from the menu. That will pop-up a

message box that says the following:

Executing : "%BEST1_HOME%\bgs\bin\best1man.exe" "%BEST1_HOME\local\manager\B1_Mmm-dd-yyyy.hh.mm.ss_[run_name]_###\[run_name].msf" -id #### -s MM-DD-YYYY -r

Step 3

Click OK in that Information dialog.

That will start a Manager run to re-transfer and re-process the data once the transfer is complete. Note that the 'Scheduler'

will continue to list the job as 'FINISHED' but it will really be reprocessing.

Option B: Using the UCM Command Line Utility

To recover failed data transfer using the UCM command line executable:

  %BEST1_HOME%\bgs\bin\udrCollectMgr -b %BEST1_HOME% -d MM-DD-YYYY -v X:\path\name.msf -r

The -r parameter restarts Manager runs that have been aborted, or runs that are already complete. Specify this option along

with the required run date and the script file name (VCMDS), which identifies the run.

When run after the run has finished (so in transfer recovery mode) the command will only attempt to re-transfer data from

the nodes defined as part of the specified Manager run that failed to transfer data previously. It will not attempt to re-transfer

data from nodes that already successfully sent their data to the console.

Option C: Using the Collect Data Wizard

The Collect Data Wizard includes functionality to transfer this type of data in this type of situation.

Step 1

Start the Collect Data Wizard by choosing Start => Programs => BMC PATROL => Perform => Collect Data.

Step 2

The Collect Data Wizard window is displayed. Click the Start a collect process on a

Console or Agent computer option (the icon shows a green traffic light).

Step 3

Click Next on the Welcome to the Collect Wizard window.

Step 4

The Select the Collection Mode window is displayed. Click Standard Mode, and then click Next.

Step 5

The Select Computers window is displayed. On this window there are two options.

a. Select the Agent computer or network address radio button, and in the edit box, type in the list of computers from which to

transfer data, separated by commas.

b. Alternately, if the list of computers is long, create a text file (using a text editor such as Notepad) that contains a list of all

the computers from which you want to transfer data. This text file should contain a list of computers, with one computer

name on each line in the text file. Once the text file is created, Choose the Select a file that contains the computers to collect

radio button and then either type the full path to the file into its edit box, or click the Browse button to browse to the file.

NOTE: The agent nodes must have the same remote data repository path for the text file method to work.

Step 7

In the Repositories and Actions window, fill in the following three edit boxes:

a. Top box: The directory on the managing computer where the data should be transferred.

b. Middle box: Where does the data reside on the agent computer (it needs to be the same for all computers).

c. Bottom box, choose the data transfer type. The options are Pull data or Push data.

Step 8

Click the Next button.

Step 9

The Data Collection Frequency window is displayed. Enter how frequently you want the data collected, summarized, and

saved. Click Next.

Step 10

The Collection Schedule window is displayed. In the Begin and End by Date and Time section, enter the date and time that

corresponds to the date/time stamp directory of the data on the remote computer. Manager passes this directory from the

managing computer so it will be the same on all remote computers (if Manager initially collected the data).

Step 11

Click the Next button.

Step 12

The Completing the Collect wizard window is displayed. This lists the command that is going to be run. Click Finish here to

get back to the main collect data window.

Step 13

The messages generated by the transfer will appear in the messages window. Check each computer and make sure that the

message Request was completed successfully on node: [nodename] was generated. For each computer that failed to

transfer the data, it may be necessary to try a different transfer type (such as PULL instead of PUSH) or to manually transfer

the data.

Legacy ID1012242 KM-1012242 KM-000001012242 KM-000001012242

Knowledge ArticleWhat are the format flags available for the udrCollectStat command?

Back to Answers Printer Friendly Rate this Page

Knowledge Article ID:  KA307660

Version:  1.0

Status:  Published

Published date:  01/20/2011

 

Problem

BMC Performance Assurance for Microsoft Windows Servers  7.4.10,  7.4.00,  7.3.00,  7.2.00

BMC Performance Assurance for Unix  7.4.10,  7.4.00,  7.3.00,  7.2.00

Perform Unix and Windows console

SolutionThe udrCollectStat command is a command line interface to the data available in the UDR Collection Manager (UCM) Status

Report HTML pages. This command can be used to get basic status information that could then be used as input to another

script or to create a daily e-mail report. All of the information available from udrCollectStat is also available from the Collector

Status Reporting HTML pages.

Information regarding the udrCollectStat command is also documented in the online help. Select the Help button on the

Collect Status report, then select the "Generating Status Information from the Command Line" link.

NOTE: This document was originally published as Solution SLN000000228509.

Within the udrCollectStat command line utility options can be specified to control both the format and what information is

presented when the command is run.

When run from UNIX, the –b option must specify a valid BEST1_HOME.

An optional –f option is available to allow a greater level of flexibility in choosing the output format. When specified, the -f

flag supports a list of option that contains specifiers to be replaced by the actual information they represent. This allows a

user to specify which fields, in which order, and how to separate the fields. If the -f format flag is not specified any important

fields for debugging will be reported. 

Using the –e 'errors only' option causes udrCollectStat to output only those items (runs or computers) that contain errors (in

either health of collection or transfer). Using the –w 'warnings only' option causes udrCollectStat to output only those items

that contain warnings (in either health of collection or transfer) Using the –o option causes udrCollectStat to output only

those items that contain no errors or warnings. A combination of these options may be specified or none in which case the

default will be to output all items.

Four different major output options are available:

'-O' flag: Run Overview

-O flag: Output overview of a run or all runs that fall in a given date. The –r option can be used to specify a specific run to

limit output details to just that run. The –d option can be used to specify a date to show data for all runs that started on that

date. Or neither flag can be specified to output a list of all runs. 

udrCollectStat –O [ -b “best1_home”]  [ -r “run_name” or –d “date”]  [ -f “format”]  [ –e ]  [ –w ]  [ -o ]

Available '-f' format specifiers:

%v = manager script

%r = name of manager run

%d = date of manager run

%ct = start time of collection

%s = state of run

%ch = health of collection [Error, Warning, OK]

%th = health of transfer [Error, Warning, OK, NA]

%e = total number of errors

%w = total number of warnings

%o = total number of oks

%V = version

\' = single quote

\" double quote

\n = new line

\r = carriage return

\t = tab

%% = percent

For example: 

  –f  "%r, %d, %s, %ch, %th"

will output:

[run name], [run_date], [state], [collect_health], [transfer_health]

> $BEST1_HOME/bgs/bin/udrCollectStat -O -f "%r, %d, %s, %ch, %th"operations_daily, 10-10-2006, COMPLETE, 2, 1topgun_daily, 10-10-2006, COMPLETE, 2, 1operations_daily, 10-11-2006, COMPLETE, 2, 1topgun_daily, 10-11-2006, COMPLETE, 2, 1topgun_daily, 10-12-2006, COMPLETE, 2, 1operations_daily, 10-12-2006, COMPLETE, 2, 1

'-D' flag: Run Detail

-D flag: Output details for a specific run. To view output for a specific run use the –s option to specify a script and the –d

option to specify the run date. The –r option may be used in place of the –s option, but the user should be aware that there

may be duplicate manager run names for the same date. (the script and date are the unique identifiers) If the –d option is

used without either a –s or –r option, detailed information for every registered run on that date will be output. If neither –d, –s

or –r are specified, information for every registered run across every date will be output.

udrCollectStat –D [-s (-v) manager script] [–r “run_name”] [–d “date”] [ -b “best1_home”]  [ -f “format”]  [ –e ]  [ –w ]  [ -o ]

Available '-f' format specifiers:

%v = manager script

%r = name of manager run

%d = date of manager run

%n = name of computer (node)

%na = name of agent computer (proxy host or same as name of computer)

%no = computer OS

%V = computer version

%a = application type

%i = instance name

%R = console data repository

%Ra = agent data repository

%s = state of computer collection/transfer

%ch = health of collection [Error, Warning, OK]

%ce = last collect error id

%ces = last collect error string

%cel = last collect error level [Error, Warning, Information]

%th = health of transfer [Error, Warning, OK, NA]

%te = last transfer error

%tes = last transfer error string

%tel = last transfer error level [Error, Warning, Information]

%ta = transfer attempts

%tg = number of groups transferred

%tb = number of bytes transferred

%tt = total transfer time (in seconds)

%xe = last data deletion error

%xes = last data deletion error string

%xel = last data deletion error level [Error, Warning, Information]

%xa = delete attempts

%gc = groups configured

%gad = groups active with data

%gan = groups active with no data

%gtd = groups terminated with data

%gtn = groups terminated with no data

%gtf = groups terminated and filtered

\' = single quote

\" double quote

\n = new line

\r = carriage return

\t = tab

%% = percent

For example:

-f "%n: %s, %ch, %ce, %th, %te [%xe]"

will output:

  [computer name]: [state], [collect_health], [last_collect_error], [transfer_health], [last_transfer_error] [[last_delete_error]]

> $BEST1_HOME/bgs/bin/udrCollectStat -D -f "%d %n: %s, %ch, %ce, %th, %te [%xe]"10-17-2006 topgun: COLLECT_RUNNING, WARNING, 98, N/A, 0 [0]10-17-2006 operations: COLLECT_RUNNING, WARNING, 98, N/A, 0 [0]10-16-2006 operations: COMPLETE, WARNING, 98, OK, 54 [57]10-16-2006 topgun: ABORTED, WARNING, 98, ERROR, 107 [107]

'-G' flag: Generate status report

-G: Generate status reports. This will update the .xml pages in the status directory for the web-based status report. Use the

–s option to specify a script and the –d option to specify the run date. 

'-E' flag: Comma separated list of errors codes and definitions

-E: Output a comma separated list of all error ids, levels and strings (no options)

For example:

> $BEST1_HOME/bgs/bin/udrCollectStat -EID,  Severity,  Description0,  Information,  Normal Operation1,  Error,  No conditions in alert2,  Information,  Drill down request received3,  Information,  Drill down request cleared4,  Error,  Bad selector received in message5,  Error,  Invalid metric request received6,  Error,  Policy file does not exist7,  Warning,  Cannot reach agent for alert<-- cut -->

Legacy ID15105952 SLN15105952 SLN000015105952 20014487

Knowledge ArticleWhat is the best way to identify UDR data that has been left on remote nodes and transfer that data to the console or delete it?

Back to Answers Printer Friendly Rate this Page

Knowledge Article ID:  KA342394

Version:  2.0

Status:  Published

Published date:  12/12/2011

Updated:  12/12/2011

 

ProblemOver time I have agent data 'stranded' on my clients. This results from the push processes not completing as

expected. I need a way to occasionally cleanup this data on the clients to assure I don't fill up the filesystems. If there

is a way to list the collect data on ALL my clients that would be fine. Then I could somehow follow up with a push or

delete for the data as needed. Ideally, if there ways a way to push ALL data from ALL clients as a global 'clean up',

that would be great. 

 

BMC Performance Assurance for Virtual Servers  7.5.10, 7.5.00, 7.4.10,  7.4.00,  7.3.00,  7.2.00

BMC Performance Assurance for Servers  7.5.10, 7.5.00,7.4.10,  7.4.00,  7.3.00,  7.2.00

Perform console

SolutionThis question is answered in four part:

 

How can I prevent data from being stranded on remote nodes forever?

How can I list the data is stranded in the data repository on my remote nodes?

How can I transfer the data in the data repository on my remote nodes to the console?

How can I delete the data in the data repository on the remote nodes from the console?

Is there any automatic way to report and recover failed transfers?

 

Section I: How can I prevent data from being stranded on remote nodes forever?

When the data collection request is issued from Manager, an option can be specified to instruct the Perform Agent on the

remote node to automatically delete the data from the remote node if it has never been deleted (generally because it has

never been successfully transferred to the console).

That option can be specified in Unix Manager under Options -> Advanced Features -> Other -> 'Delete collected data on

agent computer if transfer fails' (Days/Hours).

That option can be specified in Windows Manager under Properties -> Collect tab -> 'Automatic data deletion an agent

computer' 'Delete collect data if transfer fails' (Days/Hours).

Make sure you specify a time period less than 27 days if you have unpatched Perform version 7.2.00 remote node because

a value of 27 days or more caused Perform Agent problems.

 

Section II: How can I list the data is stranded in the data repository on my remote nodes?

Perform version 7.2.00 and later remote nodes support a 'best1collect' flag that allows you to get a list of Mmm-dd-

yyyy.hh.mm directories are still on the remote node.

The command to run is:

Unix:

  $BEST1_HOME/bgs/scripts/best1collect -n [remote hostname] -p LIST

 

Windows:

  %BEST1_COLLECT_HOME%\bgs\bin\best1collect.exe -n [remote hostname] -p LIST

 

Here is some sample output:

$BEST1_HOME/bgs/scripts/best1collect -n operations -p LIST

Manager Daemon: INFO - A Manager Daemon is currently running using port 57201

Manager Daemon: INFO - This is a normal condition

best1collect on topgun: requesting a listing of collected data via the Service Daemon...

Node      : operations.

Fri Apr 27 17:43:11 2007

  VERSION = "7.3.00"

  ROOT_REPOSITORY_NAME = "/apps/perform/best1_7.3.00/perform/history"

  NODE_SELECTOR = "operations"

  INSTANCE_SELECTOR = "noInstance"

  STATUS = 0

  STATUS_EXPLANATION = "Success"

----    --------        ----

Node    Instance        Time

----    --------        ----

operations      noInstance      Apr-27-2007.00.00

operations      noInstance      Mar-23-2006.00.00

----    --------        ----

*Node: operations has acknowledged List request successfully.

 

This output shows there are two different UDR repositories still on the remote node 'Apr-27-2007.00.00' (today's active

collection) and a standed 'Mar-23-2006.00.00' UDR data repository.

You must run the query against one node at a time. Therefore, it would be necessary to write some custom scripts to parse

a domain/policy file to get a list of machines.

 

Section III: How can I transfer the data in the data repository on my remote nodes to the console?

KA340164 -- How can Perform UDR capacity planning data be manually transferred from the remote agent node to the

Perform console server?

If you caught the transfer failure within 7 days then you can use the 'udrCollectMgr' command to pull the data from the

remote notes for that day. If you are beyond the 7 day window then you'll need to use the 'best1collect' command to transfer

the data yourself. If it is a Perform version 7.2.00 or later remote node you can use the PULL_DELETE option to transfer the

data to the console and then have it automatically deleted after the transfer has completed.

 

Section IV: How can I delete the data in the data repository on the remote nodes from the console?

There is no good way to tell a remote node to delete data in its data repository from the Perform console.

If it is a Perform version 7.2.00 or later remote node you can use the PULL_DELETE option to transfer the data to the

console and then have it automatically deleted after the transfer has completed.

If it is a Perform version 7.1.41 or earlier remote node there really isn't a great way to delete the data from the command line

on the console. You could use the 'PUSH' type transfer to transfer the data to the Perform console and have it deleted from

the remote node (assuming a firewall didn't prevent the PUSH type transfer).

 

Section V: Is there any automatic way to report and recover failed transfers?

The UDR Collection Manage (UCM) status reports will tell you if data was successfully transferred from the remote nodes to

the console each night. You can find the HTML reports in the $BEST1_HOME/local/manager/status directory on Unix or see

then via the PATROL-Manager - Status Reports link in the Perform console.

There currently isn't any proactive notification within the product that data transfer has failed. It would be possible to write a

custom script to alert on failed transfers using the output from the $BEST1_HOME/bgs/bin/udrCollectStat command on Unix

or the %BEST1_HOME%\bgs\bin\udrCollectStat.exe command on Windows.

Some information on how to use that command is documented in KA307660 -- What are the format flags available for the

udrCollectStat command?

Technical Support has created an unsupported proof-of-concept command for the Unix console that uses udrCollectStat

output (and other Manager output) to report on collect, transfer, processing, and populate status. 

You can find that script here ftp://ftp.bmc.com/pub/perform/gfc/tools/processing_status.tar.Z.

Usage and sample output are in the comments at the top of the script. I don't believe anything like that really exists for the

Windows console.

 

Legacy ID10035731 KM-10035731 KM-000010035731 KM-000010035731

Knowledge ArticleWhat is the quickest way to recover from a populate failure in Manager on the BMC Performance Assurance for Unix console?

Back to Answers Printer Friendly Rate this Page

Knowledge Article ID:  KA307987

Version:  1.0

Status:  Published

Published date:  01/20/2011

 

ProblemWhen using Unix populate (also called 'mpopulate') to populate Visualizer files into the Oracle database it may be necessary

to manually execute the population event if there is a failure during nightly processing. This could be due to the database

being offline for maintenance, a problem with the database tablespace (such as it being full), or some other reason.

What is the fastest way to recover a failed mpopulate run?

BMC Performance Assurance for Virtual Servers  7.5.00,  7.4.10,  7.4.00,  7.3.00,  7.2.00

BMC Performance Assurance for Servers  7.5.00,  7.4.10,  7.4.00,  7.3.00,  7.2.00

Unix

SolutionFor the Manager runs where you still have the *.ProcessDay script from the day when population failed you should be able

to re-run just the populate step of the Manager run using the following command:

  > /[Manager Output Directory]/[Start]-[End].ProcessDay -p

For example, to populate the Visualizer file from March 16th if you have the *.ProcessDay script and the Visualizer file from

that day:

  > cd [Manager Output Directory]  > ./Mar-16-2006.00.00-Mar-16-2006.23.59.ProcessDay -p

This tells the ProcessDay script to only run the populate event.

For Manager runs where the *.ProcessDay script has been deleted you'll need to run the mpopulate command by hand from

the command line.

The command to run is:

  > /usr/adm/best1_V.V.VV/bgs/scripts/mpopulate.sh -f /path/visfile.vis  -u dbuser -p dbpass  -d DBINSTANCE -l /path/logfile.log -t 1 -s

where:

/path/visfile.vis is the full path to the Visualizer file (or just the name of the Visualizer file if you are running the

command from within the Manager Output Directory (where the Visualizer file resides)

dbuser is the Database Username (the 'Db_Username' field from the *.Variables file in the Manager Output

Directory)

dbpass is the unencrypted Database Password (alternately, you could specify the '-P [encrypted password]'

instead and use the 'Db_Password' field from the *.Variables file in the Manager Output Directory)

DBINSTANCE is the Database Instance name (the 'Db_Instance' field from the *.Variables file in the Manager

Output Directory)

/path/logfile.log is the mpopulate log file. This can be any file.

Note for VMWare data type Visualizer files

In Perform version 7.4.10 and earlier the VMWare Visualizer files are created using a different process than the normal

system Visualizer files and they won't be populated when the '*.ProcessDay -p' command is run. The problem is that the list

of Visualizer files that will be populated is build when the Visualizer files are created. That list of created files is then used in

the population step. When you run the '*.ProcessDay -p' command it doesn't have that list of VMWare type Visualizer files

that had been created by the 'Extract' step so it doesn't know to populate them. There is no way to get those files

automatically populated without re-running the whole data processing steps.

In Perform version 7.5.00 the VMware Visualizer files are no longer created through this alternate method so they should be

populated by the '*.ProcessDay -p' command.

Legacy ID15104412 SLN15104412 SLN000015104412 20013528