Hi Ravi,

Patrol agents monitors the performance of a server and applications running on it according to the configuration that is applied for the same. This is done using various KMs that are installed on the host along-with the agent.

Patrol Agent sends the data and events to BPPM server via IS.

PCO can be used to configure thresholds or KM's on a few servers, and also to view the configuration applied to the agent. Also we can see the graphs for parameters being monitored on the host.

As for PCM, it is the Patrol configuration MAnager through which you can configure multiple agents at the same time. Also we can see the default configuration of the agent.

RT variable is used to help agent to connect to the console server and thus to PCO. RT variable can also be used to discover the agents installed on host across the infrastructure using PCM.

Hope this helps.

Thanks,

Shweta

This is in addition and FYI to Sweta's respond..

We normally do not use PATROL Configuration Manager (PCM) to configure KMs because in past version of BPPM we have encountered conflicts between CMA policy and PCM configuration.  In other words, all monitoring are performed from ProactiveNet CMA.  We do, however, use PCM to inquire whenever we are logged onto a PCO (or a central console).  We widely urge to list agent configuration via ProactiveNet's operator (web browser) console with the "Query Agent" option.  Or login from any server (or desktop with proper credentials) to retrieve via Unix shell or Windows CLI with the old 'pconfig +get <server_name> -p <port>.'

RT servers are utilized for PATROL 7, aka PATROL Classic.  Because we use BPPM, we utilize BPPM's integration service (either on same server or separate physical server from a BPPM parent/child server).  Our integration servers are the destinations of our events/alarms before these events are forwarded to a BPPM child server to propagate to the BPPM parent server.  These events can come from a PATROL agent --again, configured via CMA policy, from Oracle Enterprise Mgr (OEM) and Foglight events via msend --BPPM's feature, and SNMP traps from Infosim and other network devices.  We could have utilize SNMP traps with OEM and Foglight, but we opted for "msend" due to easiness-of-use.

Clarification:  PATROL 7 is PATROL Central Console.  PATROL 3 is PATROL Classic console.

I stand clarified (corrected)... PATROL 3 = the PATROL Classic Console; and yes PATROL 7 = PATROL Central Console

Thank you Garland: )

If this is a new implementation of BPPM or TrueSight then you should not be installing PCO and RTservers.  They're part of old, unneeded infrastructure.

There are very limited use cases for PCM and PATROL Classic Console for debugging but if any of your day to day workflow involves those, then you're doing it wrong.

--Hal

Hi Ravi,

Hal is correct. PATROL Central and the RTServer are old middleware components that pre-date BPPM. They are only required if you want to use the PATROL Central Operator console (PCO) or PATROL Reporting. Both of these components connect to PATROL agents via the RTServer 'cloud'. In general, BPPM customers should not need either of these components, so there is no point in setting up the RTServer middleware.

When you create PATROL agent installation packages, specify the Integration Services variable only and leave the RT Server field blank. It is not necessary to specify both.

PATROL Configuration Manager (PCM) is largely unnecessary for BPPM 9.x users. It has been replaced by the Central Monitoring Administration (CMA) feature of BPPM. PCM does not use RTServer or PATROL Central. It connects directly to the agents. As PC points out earlier in this thread, it is not a good idea to use both. If you are a new BPPM customer, you should use CMA to configure PATROL agents, not PCM.

I recommend you have a look at these best practices webinars for BPPM 9.5:

Connect with BMC ProactiveNet Performance Management (BPPM) 9.5 Best Practices Webinar Series

They should answer most of your questions about the right way to deploy BPPM.

Regards,

Brendan

On my previous contract I got to spend a good deal of time sorting thru the use or non-use of PCM.  Daric Smith and Michael Evans helped to reshape my old school ideas and get me very close to a PCM-free approach.

The single biggest win, imo, from using CMA for all configuration is that it frees you to purge an Agent's configuration at any point if the Agent is misbehaving.  That's possible because CMA will reapply the assigned policies and thus rebuild the configuration automatically.  I found this very useful when testing and tweaking policies.  Others such as Lori Brown have mentioned that it's a more or less standard procedure where she works when Agents misbehave.

That said, I did have to stick with PCM for setting up Remote Monitoring.  The BPPM 9.6 CMA omits any ability to use credential profiles and that's a huge problem in shops where the remote access account password has to be regularly changed.  And, FWIW, that's also a case where I mixed CMA and PCM on the same Agent.  Base OS (i.e., Windows or Unix KM) monitoring done by CMA but configuration for remote monitoring done by PCM.

--Hal