Una delle funzionalità maggiormente utili di SCOM consiste nella possibilità di registrare un percorso o un’insieme di URL che poi saranno monitorate dal watcher node prescelto. La funzionalità, che ha fatto la sua prima apparizione nel Web site e webservices management pack di MOM2005 permette quindi di verificare la disponibilità e le performance di una singola URL, di un intero percorso di navigazione (transazione) inclusi link, risorse e tutto quanto è possibile misurare nelle applicazioni web

Ovviamente in SCOM questa funzionalità è parte integrante delle funzionalità di base e i risultati riporti all’interno del Data warehouse si integrano e vengono utilizzati per generare report di performance molto utili per determinare e tenere sotto controllo la user experience delle web application.

Purtroppo anche questa funzionalità condivide con l’intero prodotto una sostanziale mancanza di documentazione tecnica dei dettaglio e quindi si può finire nei guai come sono finito io perché, senza saperlo, si possono generare quantità di dati fuori controllo e che pregiudicano la funzionalità stessa.

Nel mio caso il problema consiste nell’interruzione del flusso dati da watcher node al RMS che si materializza nell’interruzione dei grafici con i tempi di risposta rilevati dall’agente sul watcher node.

Un workaround consiste nel restart dell’agente di SCOM sul watcher node e al simultaneo aumento dei Private Bytes e Handles attraverso un bel override. Purtroppo, come quasi tutti i workaround, questo strategemma alza solo la soglia oltre la quale la rilevazione dei dati viene interrotta.

Dopo diversi tentativi, tra i quali aumenti di risorse a disposizione dei server, raddoppio dei server da dedicare ai watcher node, abbiamo anche accelerato l’upgrade alla R2 che, stando alle dichiarazioni di Microsoft, ha aumentato notevolmente la sua efficienza.

Purtroppo il watcher node continuava a fermarsi anche se con un numero di applicazioni maggiori confermadoci che c’era qualcosa di sbagliato nelle web application visto che alcune create ex-novo funzionavano correttamente.

Sul Watcher node apparivano errori con Event ID 4503 con sorgente HealthService e l’esecuzione di query tipo la seguente sul DB non dava risultati:

SELECT PerformanceSourceInternalID,countername,InstanceName

from PerformanceCounterView

WHERE InstanceName Like '<%MYWEBAPPNAME>%'

Il problema risiedeva nell’inclusione di link e risorse nelle analisi da fare nel percorso da riprodurre come testimoniato anche dal log ETL dell’agente che riportava errori nei workflow:

0              00000000             [1]2916.2452::08/26/2009-15:00:14.497 [HealthServiceRuntime]  Verbose CSinkPort::CompleteShutdown(SinkPort_cpp715)Shutdown called on already shutdown sink port.

0              00000000             [1]2916.2452::08/26/2009-15:00:14.497 [HealthServiceCommon]  Verbose CFileUtility::_RemoveDirectory(FileUtility_cpp408)GetFileAttributes on path "\\?\C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 4\5390\" failed with code 2(ERROR_FILE_NOT_FOUND) indicating the path does not exist, will report success.

0              00000000             [1]3768.448::08/26/2009-15:00:14.497 [ConfigurationManager]  Warning CConfigurationManager::WorkflowFailed(ConfigurationManager_cpp2568)Workflow ‘WebApplication_56c259f98ca945e0b5c70975ebb34289.Request2.Resources.StatusCode.Monitor’ from management pack ’32ec7a6d-4498-abaa-1a19-6b8023f427ee’ failed with code WINERROR=80FF0032.

0              00000000             [1]3768.448::08/26/2009-15:00:14.497 [ConfigurationManager]  Warning CConfigurationManager::WorkflowFailed(ConfigurationManager_cpp2581)Module ’3′ for workflow ‘WebApplication_56c259f98ca945e0b5c70975ebb34289.Request2.Resources.StatusCode.Monitor’ reported error event 3221229975.

0              00000000             [1]3768.448::08/26/2009-15:00:14.497 [HealthServiceCommon]  Warning EventLogUtil::LogEvent(EventLogUtil_cpp275)Logging warning event with args <MANAGEMENTGROUP>, 1, 1

I link e le risorse sono inclusi nella rilevazione di disponibilità e performance attraverso i checkbox:

- Enable health evaluation and performance collection for Resources

- Enable health evaluation and performance collection Internal Links

In questo modo ogni risorza (immagine, JS o similari) e ogni link, di ogni pagina del vostro percorso deve essere elaborata dall’agente.  Potete immaginare come, vista la ricchezza tipica di una pagina web contemporanea, queste opzioni facessero schizzare verso livelli intollerabili per il servizio dell’agente che veniva resettato e quindi falliva il completamento dei workflow con l conseguente stop della rilevazione dati.

Al momento, con quelle due opzioni disabilitate, riesco a monitorare tutte le applicazioni web dell’azienda anche con un solo watcher node e senza particolari problemi di performance. Ovviamente sono opportuni override atti a consentire un limite di memoria ed handle utilizzati più alti di quelli che normalmente vengono impostati per semplici agent.