Fine tuning di APM in ambienti noisy

APM profila il codice .NET di un sito web ed in base a delle soglie, può essere configurato per tradurre la violazione di questi limiti in allarmi sulla console.

Lo strumento ha un ottimo grado di granularità e quindi permette di definire dei soglie specifiche della singola applicazione e tiene conto delle sue limitazioni e bug conosciuti.

Per decidere queste soglie consiglio fortemente di fare un gruppo di lavoro tra sviluppo, gestione e, se necessario, l’aiuto di un PFE.

Queste sono nozioni di base da tener presenti.

Prima nozione importante è quella di conoscere il modello di APM che permette di capire come vengono strutturati i siti web e le applicazioni con l'utilizzo del template di SCOM .NET Application Monitoring.

Questo articolo di Daniele Muscetta lo spiega benissimo ed è importante tenerlo a mente perché è una delle componenti che determina come vengono calcolati i valori che vengono poi verificati con le soglie:

http://blogs.technet.com/b/momteam/archive/2012/01/14/apm-object-model.aspx

Questo articolo spiega qualche strategia per limitare il rumore di fondo: Authoring Strategies for .NET Application Monitoring (http://technet.microsoft.com/en-us/library/hh543991.aspx)

Qui potete trovare il dettaglio del significato dei vari settaggi del .NET Application monitoring template: .NET Application Performance Monitoring Template (http://technet.microsoft.com/en-us/library/hh457578.aspx#BKMK_SSCustom)

Infine questi due articoli spiegano delle possibili modalità per andare con precisione chirurgica a gestire le soglie di ogni singola componente del sito:

Using Exception Handlers to Define Critical Exceptions -  http://technet.microsoft.com/en-us/library/hh543992.aspx

All you need to know about APM "Transactions" - http://blogs.technet.com/b/momteam/archive/2012/04/03/all-you-need-to-know-about-apm-transactions.aspx

Sostanzialmente si tratta di utilizzare al massimo possibile la granularità di monitoraggio definendo delle soglie meno restrittive in generale e molto più restrittive e specializzate per tutte quelle componenti che APM può misurare singolarmente (Leggi Transactions, ovvero pagine ASP.NET e/o Definizione di Critical Exceptions).

Questo tipo di approccio è comunque potenzialmente molto pericoloso perché si monitorerebbe in maniera stringente solo quello che si conosce lasciando limiti alti per situazioni non contemplate durante l'analisi. (Pagine e/o exception non explicitamente sorvegliate verranno monitorate con i limiti generici.

 Dunque non esiste un modo ottimale univoco per definire le soglie più adatte su APM, non solo sulla singola applicazione ma sulla singola web “Transactions”. In generale, it depends.