Prima di iniziare a esaminare uno strumento di monitoraggio del server SQL, pensa al tuo ambiente specifico:
- Quante istanze vuoi monitorare?
- Si trovano in una posizione o sono dispersi?
- Devi monitorare il sistema operativo e/o l'hypervisor?
- Quanta cronologia è necessaria per ottenere un quadro accurato dei limiti operativi della tua istanza?
- Sono tutti on-premise o alcuni nel cloud?
- I tuoi team sono distribuiti?
- Acquisti software con un budget di spesa in conto capitale o di spesa operativa?
- Puoi permetterti di investire una somma forfettaria in anticipo su infrastruttura e licenza o preferisci ripartire i costi nel tempo?
- Hai istanze di infrastruttura e database disponibili da dedicare a uno strumento di monitoraggio?
- Hai tempo per costruire un'infrastruttura di monitoraggio?
- Hai un'esperienza costantemente elevata in tutto il tuo team?
- Utilizzi risorse junior per il triage iniziale o dipendi dai tuoi esperti per tutto?
- Hai tempo o risorse internamente per mantenere l'infrastruttura di monitoraggio?
Dovrei tirare il mio?
Posso dichiarare il nostro pregiudizio qui. Quest Software ha sviluppato strumenti di monitoraggio delle prestazioni negli ultimi 20 anni. C'è un ottimo motivo per cui noi e molti altri come noi siamo rimasti in questo segmento per così tanto tempo e perché abbiamo una base di clienti in crescita. Il monitoraggio delle prestazioni fatto bene non è facile!
Esistono infatti alcuni ottimi modi per raccogliere metriche da SQL Server utilizzando PerfMon, tracce, DMV e XEvents, solo per citarne alcuni. Farlo su base una tantum per un singolo problema va bene, se hai il tempo da investire nella ricerca di dove e come raccogliere i dati per quel problema. Una volta che i problemi iniziano a crescere e il numero di istanze aumenta, questo diventa rapidamente non scalabile.
Sono disponibili diverse centinaia di metriche di cui vale la pena tenere traccia per ottenere un quadro completo dell'integrità delle prestazioni di SQL Server. Oltre a ciò, c'è il codice SQL che viene eseguito e i piani di query associati a ciascuna esecuzione dello stesso. Alcune metriche dovrebbero essere raccolte ogni secondo, altre ogni ora e altre in base all'esecuzione del codice. Alcuni metodi di raccolta possono influire sull'istanza monitorata e dovrebbero essere evitati.
Ogni metrica avrà soglie diverse che ne definirebbero lo stato. Istanze particolari possono avere livelli non standard. Quindi devi archiviare tutto questo. Il volume dei dati si somma MOLTO velocemente. Dovrai mettere in atto una strategia per eliminare regolarmente i dati dettagliati e quindi, se necessario per la tendenza, aggregare questi dati per i rapporti.
È MOLTO lavoro ... e, naturalmente, ogni volta che esce una nuova versione di SQL Server, hai un mal di testa da regressione da affrontare. A meno che tu non voglia effettivamente vendere uno strumento di monitoraggio, ti sconsiglio vivamente di lanciare il tuo a meno che il volume dei problemi non sia basso e i problemi che devi risolvere siano molto specifici.
E gli strumenti gratuiti?
Spesso vale la pena prendere in considerazione gli strumenti gratuiti, soprattutto per i team più piccoli con istanze meno critiche. Pensalo come il prossimo passo nella scala della scalabilità dopo il "roll your own". Molti degli strumenti di monitoraggio di server SQL commerciali entry-level dovrebbero avere considerazioni simili. Considera quanto segue:
- Lo strumento copre un'ampiezza sufficiente di metriche per offrirti una copertura adeguata per tutti i casi d'uso nelle istanze monitorate? Molti strumenti gratuiti daranno una sorta di "personalizzazione" per aggiungere le tue metriche. Quando la "personalizzazione" viene utilizzata per colmare le lacune nelle funzionalità, scoprirai rapidamente che il tuo team finisce per "rotolare il proprio" con la necessaria distrazione e mal di testa per la manutenzione.
- Lo strumento supporta gli avvisi? È preconfigurato? La configurazione degli avvisi può richiedere molto tempo. Gli avvisi pronti all'uso sono un must per evitare molte ore di lavoro perse durante la configurazione dello strumento di qualcun altro. Dovrebbe inoltre facilitare la personalizzazione degli avvisi per i casi limite che non sono conformi alle impostazioni predefinite.
- Come e dove vengono archiviati i dati? La maggior parte degli strumenti gratuiti lascia a te la gestione dell'archiviazione dei dati sulle prestazioni. Diffida del monitoraggio "gratuito" dei fornitori di cloud. Fanno pagare per lo spazio di archiviazione e questo può diventare grande e costoso in fretta!
Quindi, con tutti i mezzi, sfrutta gli strumenti gratuiti disponibili. Basta essere consapevoli dei loro limiti e prestare attenzione ai classici anti-pattern all'interno del tuo team, come:
- Più tempo dedicato alla riparazione o alla manutenzione dello strumento che al suo utilizzo per risolvere i problemi
- Più soldi spesi per l'infrastruttura e lo storage
- Molti dati ma nessun approfondimento
- Diagnostica insufficiente per risolvere i problemi
- Non abbastanza scalabile per soddisfare le tue esigenze
Se noti uno dei precedenti, dovrebbe indicare la necessità di eseguire l'aggiornamento a una soluzione più robusta.
Architettura tipica di un sistema di monitoraggio di SQL Server
Quando si valuta se scegliere una soluzione locale tradizionale o una soluzione SaaS (Hosted Software as a Service), è utile considerare l'architettura dell'applicazione di monitoraggio. Ecco un riepilogo dei componenti chiave dell'architettura.
La deviazione chiave tra SaaS e on-premise riguarda la posizione in cui vengono archiviati i dati sulle prestazioni e chi gestisce questo repository. Per una soluzione locale, questa è responsabilità dell'utente finale. Questi repository possono diventare grandi rapidamente, quindi devono essere gestiti con attenzione. L'infrastruttura deve essere pianificata e preventivata (più sotto).
In una soluzione SaaS per il monitoraggio del server SQL, questi componenti chiave dell'infrastruttura sono ospitati e gestiti per te.
| Soluzione tradizionale in locale | Soluzione SaaS |
|
|
Per maggiori dettagli, consulta il nostro blog, Database Monitoring System Architecture.
