Esiste un numero crescente di ottimi sistemi di monitoraggio delle prestazioni del database là fuori. Di recente, alle soluzioni locali più tradizionali si sono aggiunte soluzioni SaaS (Software as a Service).
Questo blog mette a confronto l'architettura tipica di una soluzione on-premise con quella di una soluzione SaaS. Naturalmente, i componenti varieranno nel nome e nella struttura da un fornitore all'altro, ma i concetti chiave discussi qui saranno rappresentati in una forma o nell'altra.
Differenze tra soluzioni locali e SaaS
Nel complesso, ecco alcuni dei componenti chiave di ciascuna soluzione:
Soluzione tradizionale in locale
- Processo di raccolta dei dati.
- Repository [diagnostica] delle prestazioni a breve termine.
- Repository di analisi/rapporti a lungo termine.
- Client Windows o browser.
- Qualsiasi infrastruttura di failover richiesta per l'infrastruttura di monitoraggio.
Soluzione SaaS
- Processo di raccolta dati (per destinazioni locali).
- Client browser.
- App per dispositivi mobili.
- Il fornitore SaaS gestisce l'applicazione e l'archiviazione dei dati di back-end.
Nota che i nomi dei vari componenti variano da una soluzione all'altra. In alcuni casi, la funzionalità può essere suddivisa su più servizi o origini dati.
Soluzioni locali
Processo di raccolta dei dati
Il raccoglitore di dati è in genere un servizio locale senza agente che raccoglie i dati da qualsiasi endpoint monitorato in locale. Questo processo orchestra come e quando i dati vengono raccolti. Dovrebbe essere in grado di raccogliere dati a frequenze diverse per bilanciare la necessità di maggiori dettagli con l'impatto sul carico di lavoro monitorato. Le frequenze di raccolta e le soglie di avviso dovrebbero essere preconfigurate in ogni metrica.
Tutti avranno un'istanza "rumorosa" che non è conforme alle soglie standard. Questo può portare a molti falsi positivi. Per far fronte a questo, il sistema dovrebbe avere la capacità di creare regole a livello di istanza per affrontare circostanze eccezionali. Ciò evita la "stanchezza dell'allarme" da falsi positivi.
In alcuni casi, questo servizio orchestra anche avvisi e notifiche. Nelle grandi organizzazioni con centinaia di istanze monitorate, potrebbe essere necessario bilanciare il carico "federando" tra una serie di raccoglitori di dati. La federazione sincronizza le raccolte e la configurazione in un sistema disperso.
Repository di diagnostica a breve termine
È qui che vengono archiviati i dati dettagliati. Ciò includerebbe dati da DMV, file di registro, XEvents e altre origini dati di SQL Server. Dovrebbero essere evitate le fonti che potrebbero esercitare pressione sulle istanze monitorate, ad esempio la maggior parte delle tracce non sono adatte per il monitoraggio in tempo reale.
Poiché le frequenze di raccolta possono essere pari a ogni secondo e vengono raccolti blocchi di dati più grandi come TSQL e piani, questo repository può diventare grande rapidamente. Di conseguenza, la maggior parte dei sistemi limita in genere la cronologia a un periodo compreso tra una settimana e un mese (queste limitazioni non si applicano a una soluzione SaaS). Questo repository è di natura altamente transazionale.
Repository di analisi/rapporti a lungo termine
Al termine di un tempo predefinito, questi dati dettagliati vengono aggregati e archiviati in un repository di report per analisi e trend di alto livello. La quantità di dettagli conservati avrà un impatto significativo sulla dimensione finale di questo repository e sulla capacità di calcolo che ci si può ragionevolmente aspettare che un utente metta a disposizione per analizzarlo. Questo tende a variare notevolmente da una soluzione all'altra. Le soluzioni che supportano analisi più approfondite avranno architetture di supporto e potrebbero utilizzare architetture OLAP per facilitare l'analisi multidimensionale.
Ridimensionamento di una soluzione di monitoraggio locale
Saranno progettate soluzioni più sofisticate per facilitare un'architettura distribuita dei componenti chiave per supportare la scalabilità. Il servizio di raccolta dati avrà un numero superiore di connessioni monitorate che può supportare. Una volta raggiunto questo limite, un raccoglitore di dati aggiuntivo dovrebbe essere "federato" per coordinare la raccolta dei dati e orchestrare l'archiviazione dei dati.
Gli stessi repository di dati sulle prestazioni possono condividere un'istanza o possono essere distribuiti su più istanze per supportare la scalabilità. Lo spazio di archiviazione richiesto sarà direttamente proporzionale al numero di connessioni monitorate e al volume di dati conservati. Anche la struttura e l'architettura del repository di analisi influiranno sulla capacità totale.
Esperienza utente
La maggior parte degli strumenti locali avrà un front-end di Windows. Alcuni hanno front-end del browser basati su una distribuzione ospitata localmente. L'accesso remoto a questi può essere complicato e in genere richiede una VPN. Raramente supportano le app mobili.
Alta disponibilità
Il software di monitoraggio che monitora i carichi di lavoro mission-critical deve essere di per sé resiliente. Dovrebbero essere presi provvedimenti per gestire situazioni di emergenza che potrebbero mettere offline la struttura di monitoraggio. Questo dovrebbe essere considerato anche dal punto di vista dell'architettura e dei costi.
Soluzioni SaaS
Processo di raccolta dei dati
Sebbene un'offerta SaaS sia principalmente ospitata, spesso manterrà un raccoglitore di dati in locale per i carichi di lavoro in locale. Questo aiuta a risolvere i vincoli di prestazioni e sicurezza. In questo modo, tutte le connessioni a livello di istanza vengono effettuate tramite il raccoglitore locale, che quindi inoltra i dati sulle prestazioni del database monitorato al servizio di ingresso nel cloud. Tutti i dati devono essere crittografati in transito.
Repository di diagnostica e reportistica/analisi
La buona notizia qui è che il fornitore SaaS gestisce tutta l'archiviazione dei dati. Non devi preoccuparti di mantenere in piedi le istanze per i repository di diagnostica, di segnalare i repository, di svuotare il repository di diagnostica o di molti altri mal di testa associati a una distribuzione in locale.
Le soluzioni in hosting attingeranno a diverse strategie di archiviazione nel back-end per facilitare un mix di attività transazionale e analitica, a seconda dei casi. Possono attingere alle risorse cloud per gestire volumi di dati più elevati e l'elaborazione necessaria per l'analisi; ad esempio, Spotlight Cloud conserva un anno di dati dettagliati. Quindi non solo puoi riportare un anno indietro nel tempo, ma puoi anche riprodurre il tuo carico di lavoro fino a un anno prima. Questa è una capacità davvero potente.
Una soluzione SaaS per il monitoraggio delle prestazioni del database può utilizzare una varietà di strategie di archiviazione back-end non solo per adattarsi alla natura più transazionale della diagnostica e del monitoraggio, ma anche per facilitare il crunching ad alta intensità dei numeri associato all'analisi a lungo termine. Il fornitore SaaS può sfruttare considerevoli economie di scala per utilizzare un'infrastruttura molto più potente che sarebbe a disposizione delle singole organizzazioni.
Come scalare una soluzione SaaS
Il ridimensionamento di una soluzione SaaS è responsabilità del fornitore e non dell'utente. Qualsiasi soluzione SaaS per il monitoraggio delle prestazioni del database deve essere progettata per essere scalabile sin dal primo giorno e, di conseguenza, tende a gestire la scalabilità nel suo passo.
Esperienza utente
Le applicazioni SaaS utilizzeranno per impostazione predefinita un browser Ux e molte avranno anche app mobili complete. Ciò facilita i team dispersi e remoti.
Sicurezza e conformità
La maggior parte delle soluzioni SaaS sarà costruita su una delle principali infrastrutture cloud, come Azure o Amazon. Molti dei principali fornitori dispongono di sofisticate infrastrutture di sicurezza. Sono fortemente investiti nel supportare le esigenze di conformità dei loro clienti.
Alta disponibilità
La buona notizia anche qui è che questa è responsabilità del venditore. Vale la pena consultare il proprio fornitore per scoprire quali disposizioni hanno effettuato in termini di failover e disponibilità elevata. Le applicazioni SaaS dovrebbero essere progettate per essere molto resilienti. I vari servizi che compongono un'applicazione SaaS sono in genere progettati per essere resilienti individualmente. È inoltre possibile prevedere le interruzioni del data center in cui l'applicazione potrebbe eseguire il failover da un data center all'altro in caso di interruzione del data center.
