2016-06-07 26 views
5

su questo link: https://azure.microsoft.com/en-us/documentation/articles/app-insights-api-custom-events-metrics/Il thread TelemetryClient di Application Insight è sicuro?

Si dice esplicitamente:

TelemetryClient è thread-safe.

Si consiglia di utilizzare un'istanza di TelemetryClient per ogni modulo della propria app.

Tuttavia, la documentazione MSDN (https://msdn.microsoft.com/en-us/library/azure/microsoft.applicationinsights.telemetryclient.aspx) dice:

statici pubblici (in Visual Basic) di questo tipo è thread-safe. Non è garantito che tutti i membri di istanza siano thread-safe.

Quindi il problema è che molte funzioni come TrackEvent e TrackMetric non sono statiche. Se seguo il primo articolo, avendo un'istanza singleton per il mio servizio web, dovrei incorrere in problemi di threading?

+0

Non si verificheranno problemi di threading. Se hai bisogno di me posso entrare in ulteriori dettagli che posso, ma per tutti gli scopi intensivi non ti imbatterai in problemi di threading. – IdahoSixString

risposta

7

TelemetryClient è thread-safe. Un utilizzo valido è creare un singleton e riutilizzarlo. Non ti imbatterai in problemi riutilizzando un'istanza.

+0

è possibile che si desideri utilizzare nuove istanze di TelemetryClient da diverse posizioni, in modo da poter impostare un ID operazione o altri campi che si desidera utilizzare per collegare la telemetria. ad esempio, richiesta + dipendenza, o visualizzazione di pagina + dipendenza utilizzano un id di operazione condivisa in modo da poter trovare le chiamate di dipendenza provenienti da una specifica richiesta o visualizzazione di pagina. se utilizzi solo un telemetryclient in tutta la tua app, è un po 'più difficile farlo. –

+2

Ogni TelemtryClient creerà il proprio canale, le proprie copie di inizializzatori di telemetria, processori, ecc. È uno spreco di risorse. La gestione dei campi deve essere eseguita tramite l'inizializzatore di telemetria e il contenitore comune come HttpContext o OperationContext o alcuni DI. –