Misurazione della velocità effettiva massima di rilevamento sostenibile

Dopo aver distribuito una soluzione line-of-business nella piattaforma BizTalk Server, è necessario tenere traccia e monitorare il sistema per comprendere quanto segue:

• Quali sono le prestazioni del sistema

• Quali eccezioni ed errori possono verificarsi e perché

• Lo stato corrente dei processi di business implementati come soluzioni BizTalk

  Per molte organizzazioni, è anche importante registrare i messaggi non elaborati effettivi che passano attraverso il sistema per scopi non ripudio. BizTalk Server offre due tipi di funzionalità di rilevamento che rispondono a questi requisiti:

• Rilevamento dei dati e rilevamento delle attività (DTA). DTA rileva numerose proprietà di messaggi definite dall'utente, eventi di debug delle orchestrazioni, eventi di flusso dei messaggi e lo stato delle istanze dei servizi. È possibile utilizzare il rilevamento per eseguire query nei dati memorizzati nel database di rilevamento DTA BizTalk (BizTalkDTADb). Il rilevamento DTA include anche il rilevamento dei messaggi non elaborati, ovvero corpi dei messaggi, ai fini del non-ripudio e della risoluzione dei problemi.

• Rilevamento BAM (Business Activity Monitoring). BAM utilizza un profilo di rilevamento definito dall'utente per rilevare lo stato di un processo di business in un set speciale di database BAM.

  In questo argomento vengono descritti l'architettura DTA e un approccio sistematico per determinare la velocità effettiva massima che può essere sostenuta all'infinito da un sistema che utilizza DTA. Sebbene DTA e BAM condividano alcuni componenti a livello di architettura, in questo argomento viene trattato solo il comportamento di DTA. Per informazioni sull'architettura BAM, vedere Business Activity Monitoring (BAM).

Panoramica dell'architettura di rilevamento di DTA

Quando i messaggi circolano nel sistema, vari elementi sottoposti a rilevamento, ad esempio corpi dei messaggi, proprietà ed eventi, passano attraverso una serie di processi e database, per venire infine scritti nel database BizTalkDTADb. Dopo che gli elementi sono stati scritti nel database BizTalkDTADb, è possibile utilizzare il rilevamento per eseguire query sulle informazioni sottoposte a rilevamento. Per informazioni sulla configurazione e sull'uso del database e del rilevamento BizTalkDTADb, vedere Visualizzazione dei dati cronologici e rilevati.

Per verificare che il sistema sia sostenibile e possa venire eseguito all'infinito a una data velocità del flusso di messaggi, è necessario mantenere l'integrità del percorso seguito dagli elementi sottoposti a rilevamento per arrivare al database BizTalkDTADb e del database stesso. Ad esempio, l'aumento del numero dei messaggi nelle tabelle del database o nel DTA può causare una crescita smisurata del file di database, che se non viene gestita potrebbe diventare insostenibile.

Per iniziare, quindi, verranno esaminati l'architettura e i percorsi seguiti dalle informazioni sottoposte a rilevamento. Verranno esposte le risorse chiave e gli indicatori di prestazioni che è necessario monitorare per determinare l'integrità del sistema di rilevamento con il flusso del traffico dei messaggi attraverso il motore di BizTalk Server.

Nella seguente figura è illustrata una panoramica dell'architettura di rilevamento DTA e dei percorsi.

Seguendo nell'ordine i processi numerati della figura, tutti i dati rilevati da DTA vengono scambiati con il database BizTalkDTADb come segue:

1. Il processo di runtime di BizTalk Server include un componente chiamato intercettore. È compito dell'intercettore memorizzare nella cache gli elementi sottoposti a rilevamento in fase di esecuzione e al successivo ciclo di andata e ritorno dal database MessageBox (ad esempio, per inserire in coda un messaggio nel database MessageBox) inoltrare gli elementi memorizzati nella cache al database MessageBox. L'intercettore determina quali elementi rilevare osservando la configurazione di rilevamento (ovvero il profilo di rilevamento), che viene ottenuto dal database di gestione e viene memorizzato nella cache in ogni istanza del runtime dell'host, in modo da poter essere utilizzato dall'intercettore.

   Come illustrato nella figura precedente, nel database MessageBox vengono inseriti due flussi di dati:

   • Uno rappresentato dalla tabella Spool

   • Uno dalla tabella TrackingData

     I corpi dei messaggi rilevati utilizzano entrambi flussi. I corpi dei messaggi stessi (raffigurabili come blob di dati) vengono gestiti tramite una serie di tabelle rappresentate dalla tabella Spool. Gli eventi dei messaggi associati ai corpi dei messaggi (ad esempio, identificatori dei messaggi, momento di rilevamento dei corpi dei messaggi, istanze a cui sono associati i corpi dei messaggi) vengono gestiti tramite la tabella TrackingData. Tutti gli elementi rilevati non associati al rilevamento dei corpi dei messaggi vengono gestiti solo tramite la tabella TrackingData.

2. Il database MessageBox costituisce il primo punto di arresto per i dati rilevati e viene utilizzato per memorizzare nella cache i dati rilevati in modo che il runtime possa continuare l'elaborazione senza venire bloccato direttamente da ulteriori elaborazioni di dati per il rilevamento.

   Per trasferire i corpi dei messaggi rilevati (BLOB) al database BizTalkDTADb in cui è possibile visualizzarli e archiviarli in una risorsa di archiviazione più permanente, BizTalk Server usa un processo di SQL Agent denominato TrackedMessages_Copy_BizTalkMsgBoxDb che viene eseguito in ogni server di database MessageBox. È compito di questo processo copiare i corpi dei messaggi contrassegnati per il rilevamento nel database BizTalkDTADb.

3. Tutti i dati rilevati diversi dai corpi dei messaggi vengono spostati dal database MessageBox al database BizTalkDTADb da un servizio denominato TDDS che viene eseguito in uno o più host BizTalk Server. Ogni volta che un host viene configurato come host che ospita il rilevamento tramite le pagine delle proprietà nella console di amministrazione di BizTalk Server, in ogni istanza di tale host verrà eseguito il sottoservizio TDDS.

4. Se non si elimina periodicamente il contenuto del database BizTalkDTADb, le sue dimensioni potrebbero aumentare senza controllo, con conseguenti problemi a livello operativo. L'attività di eliminazione del contenuto del database BizTalkDTADb viene svolta da un solo processo dell'agente SQL chiamato Purge and Archive (BizTalkDTADb). Per impostazione predefinita questo processo viene eseguito ogni minuto ed elimina il contenuto di tutte le istanze completate con un'età maggiore di quella configurata dall'utente (ad esempio, 24 ore).

   Per altre informazioni sul processo di eliminazione e archiviazione DTA, vedere How to Configure the DTA Purge and Archive Job.For more information abut the DTA Purge and Archive job, see How to Configure the DTA Purge and Archive Job.

5. Facoltativamente il processo di ripulitura e archiviazione DTA può archiviare anche i dati di BizTalkDTADb come backup SQL per consentire un'archiviazione più prolungata e/o la visualizzazione offline dei dati. Se è necessario eseguire query sui dati di BizTalkDTADb archiviati, è necessario innanzitutto ripristinarlo come nuovo database in SQL Server, quindi utilizzare il rilevamento o SQL Query Analyzer per eseguire le query.

Contenuto della sezione

• Informazioni sul comportamento delle prestazioni di rilevamento DTA

• Scenari di test per misurare la velocità effettiva massima sostenibile del rilevamento DTA

• Suggerimenti per individuare la velocità effettiva massima sostenibile del rilevamento DTA

Vedere anche

Indicazioni per la definizione delle dimensioni del database di rilevamento