Suggerimenti per la registrazione tramite ULS (Unified Logging Service) - Parte 2
Suggerimenti per la registrazione tramite ULS (Unified Logging Service) - Parte 2
Nella prima parte dei suggerimenti per la registrazione tramite ULS (https://blogs.msdn.com/b/sharepoint_it/archive/2011/03/21/suggerimenti-per-la-registrazione-tramite-uls-unified-logging-service.aspx) ho incluso il codice necessario per aggiungere un'area di registrazione personalizzata a un registro ULS e ho illustrato come utilizzarlo all'interno di un progetto. Dopo averlo utilizzato per qualche tempo, tuttavia, ho notato quanto segue:
1. Alcune parti del codice non sono ottimizzate per la versione più recente dell'SDK. In pratica, il codice implementa alcuni elementi che in base al contenuto dell'SDK non sono necessari. Inoltre, alcune operazioni vengono eseguite in modo diverso rispetto all'esempio dell'SDK (questi aspetti verranno modificati in un aggiornamento separato).
2. La registrazione avviene solo se TraceSeverity ha valore Medium e non esiste un sistema efficace per definire ulteriori livelli di traccia.
3. Il problema più grave è costituito dal fatto che, se si tenta di richiamare la classe personalizzata necessaria per l'area personalizzata al fine di eseguire una registrazione durante un'attività POST, si verifica un errore. Si tratta di un errore molto comune che impedisce di aggiornare un oggetto SPWeb durante un'operazione POST, a meno che la proprietà AllowUnsafeUpdates non venga impostata su true. Impostare tale valore per un oggetto SPWeb durante un evento di registrazione solo per farlo funzionare è semplicemente da pazzi, così ho deciso di trovare una soluzione migliore.
In questo post ho pertanto intenzione di migliorare l'esempio precedente e di aggiungervi ulteriori funzionalità strada facendo. Verrà illustrato quanto segue:
1. Una classe migliorata per l'area personalizzata (questa versione è più breve della precedente).
2. Integrazione con Configura registrazione diagnostica (Configure diagnostic logging) , nella sezione Monitoraggio (Monitoring) di Amministrazione centrale (Central Administration). Questa integrazione consentirà inoltre di aggiungere il supporto per la configurazione dei livelli di traccia per aree e categorie personalizzate.
3. Informazioni sulla registrazione. Una soluzione molto semplice per effettuare e annullare la registrazione della classe di registrazione ULS in modo che possa essere integrata e rimossa in Amministrazione centrale (Central Administration).
Iniziamo quindi dalla versione ottimizzata della classe. Questa versione presenta molte analogie con quella illustrata nel primo post, ma è lievemente più breve e più semplice. La classe ha ora l'aspetto seguente.
[Guid("833B687D-0DD1-4F17-BF6A-B64FBC1AC6A8")]
public class SteveDiagnosticService : SPDiagnosticsServiceBase
{
private const string LOG_AREA = "Steve Area";
public enum LogCategories
{
SteveCategory
}
public SteveDiagnosticService()
{
}
public SteveDiagnosticService(string name, SPFarm parent)
: base(name, parent)
{
}
public static SteveDiagnosticService Local
{
get
{
return SPDiagnosticsServiceBase.GetLocal<SteveDiagnosticService>();
}
}
public void LogMessage(ushort id, LogCategories LogCategory,
TraceSeverity traceSeverity, string message,
params object[] data)
{
if (traceSeverity != TraceSeverity.None)
{
SPDiagnosticsCategory category
= Local.Areas[LOG_AREA].Categories[LogCategory.ToString()];
Local.WriteTrace(id, category, traceSeverity, message, data);
}
}
protected override IEnumerable<SPDiagnosticsArea> ProvideAreas()
{
yield return new SPDiagnosticsArea(LOG_AREA, 0, 0, false,
new List<SPDiagnosticsCategory>()
{
new
SPDiagnosticsCategory(LogCategories.AzureConfig.ToString(),
TraceSeverity.Medium, EventSeverity.Information, 1,
Log.LOG_ID)
});
}
}
Le modifiche più importanti rispetto alla prima versione sono le seguenti:
1. Aggiunta dell'attributo Guid alla classe:
[Guid("833B687D-0DD1-4F17-BF6A-B64FBC1AC6A8")]
Ho aggiunto l'attributo Guid alla classe perché SharePoint ne ha bisogno per identificare univocamente la classe nel database di configurazione.
2. Modifica del costruttore predefinito:
public SteveDiagnosticService()
{
}
Ora è semplicemente un costruttore vuoto standard. Nella versione precedente viene utilizzato l'altro overload del costruttore, che accetta un nome di servizio e un oggetto SPFarm. Se possibile, è sempre meglio cercare di ottenere lo stesso risultato utilizzando meno codice.
3. Eliminazione dell'override HasAdditionalUpdateAccess. Anche in questo caso, ho notato che di fatto non serve quindi l'ho rimosso, sempre per cercare di limitare il più possibile la lunghezza del codice.
4. Notevole abbreviazione del metodo ProvideAreas, che ora segue lo stesso chema utilizzato nell'SDK:
yield return new SPDiagnosticsArea(LOG_AREA, 0, 0, false,
new List<SPDiagnosticsCategory>()
{
new
SPDiagnosticsCategory(LogCategories.AzureConfig.ToString(),
TraceSeverity.Medium, EventSeverity.Information, 1,
Log.LOG_ID)
});
Così ho risolto il primo dei problemi elencati in precedenza. Ora il codice è più breve e lineare. Tutti gli altri problemi, ovvero la mancanza dei livelli di traccia, la generazione di un'eccezione in caso di registrazione durante un'operazione POST e l'integrazione con Amministrazione centrale (Central Administration), sono stati risolti estendendo ulteriormente il codice ed effettuando le registrazione. L'esempio attualmente disponibile nell'SDK non è esaustivo da questo punto di vista, ma sono riuscito comunque a ottenere l'effetto desiderato. Per semplificare le cose, ho creato nel mio assembly una nuova funzionalità che contiene la classe ULS presonalizzata descritta in precedenza, quindi ho aggiunto un ricevitore di funzionalità. La registrazione dell'assembly ULS personalizzato viene eseguita durante l'evento FeatureInstalled e annullata durante l'evento FeatureUninstalling. Questa soluzione è perfetta per il mio scenario, perché in questo modo l'ambito della funzionalità è costituito da una farm e la funzionalità si attiva automaticamente quando la soluzione viene aggiunta e distribuita. Il codice necessario per eseguire e annullare la registrazione è incredibilmente semplice:
public override void FeatureInstalled(SPFeatureReceiverProperties properties)
{
try
{
SteveDiagnosticsService.Local.Update();
}
catch (Exception ex)
{
throw new Exception("Error installing feature: " + ex.Message);
}
}
public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
{
try
{
SteveDiagnosticsService.Local.Delete();
}
catch (Exception ex)
{
throw new Exception("Error uninstalling feature: " + ex.Message);
}
}
In questo caso, è importante sottolineare che è possibile fare riferimento a "SteveDiagnosticService" perché a) ho aggiunto un riferimento all'assembly con la classe di registrazione personalizzata al progetto in cui è stato creato il pacchetto della funzionalità e b) ho aggiunto un'istruzione using alla classe del ricevitore di funzionalità per l'assembly con la classe di registrazione personalizzata.
Le registrazione della classe di registrazione ULS personalizzata consente di ottenere numerosi vantaggi:
· Se si scrive in un registro ULS durante un POST, non vengono più generati errori dovuti a problemi di aggiornamento dell'oggetto SPWeb.
· Poiché l'area e la categoria di registrazione personalizzate vengono visualizzate in Amministrazione centrale (Central Administration), posso accedere a Configura registrazione diagnostica (Configure diagnostic logging) e modificare i livelli di traccia e di evento. Se ad esempio il livello di traccia predefinito è Medio (Medium), nel registro vengono eseguite tutte scritture ULS di livello TracingSeverity.Medium, mentre quelle di livello TracingSeverity.Verbose vengono ignorate. Per includere nel registro anche le voci di livello TracingSeverity.Verbose, è sufficiente accedere a Configura registrazione diagnostica (Configure diagnostic logging) e impostare il livello di traccia Dettagliato (Verbose).
In generale, la soluzione è più semplice e più completa. Penso che sia una delle più vantaggiose attualmente in circolazione.
P.S. Desidero protestare ufficialmente per l'ingiustizia subita da LaMarcus Aldridge di Portland Trailblazers, che non è stato inserito nel team Western Conference NBA. Certo, questo è un commento strettamente personale. So che tutti coloro che visitano questo blog sperano di trovare informazioni interessanti per il proprio lavoro. Spero che questo post vi sia stato utile.
Questo è un post di blog localizzato. Consultate l'articolo originale: Tips for ULS Logging Part 2