Real time monitoring for Multi-site deployment

[Gremlin]

How do we achieve real time monitoring of ALL agents and queues in a multi-site environment using CC Pulse ?

I did consider a centralized statistic server connected to every T-server in every country BUT this would simply take up too much bandwidth - thus what would be the alternative or recommended setup for such multi-site's command centres to view the real-time status of all the agents and queue for all countries within a single CC Pulse view ?

"In a multi-site deployment where customer wants to have single agent group.

How can a centralized URS determine the status of the agents in every country / site, without a centralised stat server connected to every T-server / SIP server in every country ? (considering a centralized stat server is discouraged due to bandwidth considerations)

[Steve]

Unless you are running your Stat-Servers under different users, (i.e they are all running as the system user) they will be getting updates from every T-Server anyway. So pointing CC-Pulse to one of these is not really an issue.

If you want a single group for routing, your URS will connect to one of your Stat-Servers and get all the updates it needs.

[Gremlin]

Thanks Steve,

So if I have a multisite deployed, example

Site A: Nortel with Tsvrs_A pair (and HA) and statsvr_A

Site B: Avaya with Tsvrs_B pair and Statsvr_B

Site C: Siemens HiPath with SIPsvrs_C pair and Statsvr_C

Does it mean that all Stat servers will connect to ALL Tsvr/Sipsvr pairs (total 6) ?

E.g. Statsvr_A will also be connected to Tsvrs_A, Tsvr_B and SIPsvrs_C ?

if so, won't the bandwidth requirements across sites be very high ??   

[Timur Karimov]

[quote author=Gremlin link=topic=5884.msg25617#msg25617 date=1285289880]
So if I have a multisite deployed, example
Site A: Nortel with Tsvrs_A pair (and HA) and statsvr_A
Site B: Avaya with Tsvrs_B pair and Statsvr_B
Site C: Siemens HiPath with SIPsvrs_C pair and Statsvr_C
Does it mean that all Stat servers will connect to ALL Tsvr/Sipsvr pairs (total 6) ?
E.g. Statsvr_A will also be connected to Tsvrs_A, Tsvr_B and SIPsvrs_C ?
if so, won't the bandwidth requirements across sites be very high ?? 
[/quote]
if you want achive this - you MUST configure all stat servers to connect to all t-servers. and, if you use this stat servers as source for routing servers and at the same time as source for reporting(ODS, ICON)  - so - it's realy bad idea!
WBR Thaler

[Steve]

It does matter what T-Servers the Stat-Servers are connected to, T-Servers broadcast status updates. So it is happening anyway if the network allows it, and it probably does as they are all connected to get to a common CME.
It is easy to prove connect CC-Pulse to a stat-server at one site and try to monitor an agent or a group of agents at one of the other sites.

To restrict it you need to run each site's Stat-Servers as a different user. Then you can set permissions to stop it happening.

[Gremlin]

Thanks !! Really appreciate all ur advise

[Gulden_NL]

Just saw this and thought I would add the time zone question to the equation.

I've always deployed a sufficiently robust (HA and plenty of great database syncronization) a single "Data Mart"  that has its data pulled from ODSs located at all of the different sites. Only one ODS (Operational Data Source) per time zone is required.

Make sure that you assign the correct time zone when defining ODSs to the Data Mart (using ETL Assistant). You cannot change this assignment after initial entry. Any report that any site runs on any object across any time zone will be displayed in that site’s time zone. We always keep all of our servers on UTC (GMT..kind of) so when we generate reports presented in a particular time zone , we customize the selection criteria derived from time fields that are not GMT-based, in each of the desired canned reports, to hold the equivalent values of the time zone on which you wish to generate reports.

And this is a Genesys description of how to adjust the times:
"Wherever search criteria is used in each of these reports (such as specifying the date range on which to generate the report), each non-GMT based time field used in that search criteria would have to be converted to the appropriate time zone value. For instance, where search criteria are derived from BEGIN_TIME, you might substitute NEW_TIME(BEGIN_TIME_GMT,’GMT’,’CST’) using the Oracle NEW_TIME function to convert BEGIN_TIME to its Central Standard Time equivalent. Criteria may involve any time-related fields for which GMT, generally, does not appear in the column name, such as ADD_TIME, BEGIN_TIME, DELETE_TIME, END_TIME, OBJ_ADD_TIME, and OBJ_DEL_TIME."