sql >> Base de Datos >  >> RDS >> Sqlserver

Elegir una herramienta de supervisión de SQL Server que se adapte a sus necesidades

Antes de comenzar a buscar una herramienta de monitoreo de servidor SQL, piense en su entorno específico:

  • ¿Cuántas instancias desea monitorear?
  • ¿Están en un solo lugar o dispersos?
  • ¿Necesita monitorear el sistema operativo y/o el hipervisor?
  • ¿Cuánto historial necesita para obtener una imagen precisa de los límites de funcionamiento de su instancia?
  • ¿Están todos en las instalaciones o algunos están en la nube?
  • ¿Están distribuidos sus equipos?
  • ¿Compra software con un presupuesto de gastos de capital o de gastos operativos?
  • ¿Puede permitirse invertir una suma global por adelantado en infraestructura y licencia o prefiere repartir los costos a lo largo del tiempo?
  • ¿Tiene instancias de infraestructura y base de datos disponibles para dedicarlas a una herramienta de monitoreo?
  • ¿Tiene tiempo para construir una infraestructura de monitoreo?
  • ¿Tiene un alto nivel de experiencia constante en todo su equipo?
  • ¿Utiliza recursos jóvenes para la clasificación inicial o depende de sus expertos para todo?
  • ¿Tiene tiempo o recursos internos para mantener la infraestructura de monitoreo?

¿Debería enrollar el mío?

Puedo declarar nuestro sesgo aquí. Quest Software ha estado construyendo herramientas de monitoreo de rendimiento durante los últimos 20 años. Hay una excelente razón por la que nosotros y muchos otros como nosotros hemos permanecido en este segmento durante tanto tiempo y por la que tenemos una base de clientes en crecimiento. ¡La supervisión del rendimiento bien hecha no es fácil!

De hecho, hay algunas formas excelentes de recopilar métricas de SQL Server mediante PerfMon, seguimientos, DMV y XEvents, por mencionar algunas. Hacer esto de forma única para un solo problema está muy bien, si tiene tiempo para invertir en investigar dónde y cómo recopilar los datos para ese problema. Una vez que los problemas comienzan a acumularse y la cantidad de instancias aumenta, esto rápidamente se vuelve inescalable.

Hay varios cientos de métricas disponibles que vale la pena rastrear para obtener una imagen completa del estado de rendimiento de su SQL Server. Además de eso, está el código SQL que se ejecuta y los planes de consulta asociados a cada ejecución del mismo. Algunas métricas deben recopilarse cada segundo, algunas cada hora y otras en función de cuándo se ejecuta el código. Algunos métodos de recopilación pueden afectar la instancia supervisada y deben evitarse.

Cada métrica tendrá diferentes umbrales que definirían su estado. Los casos particulares pueden tener niveles que no son estándar. Entonces tienes que almacenar todo esto. El volumen de datos se suma MUY rápido. Deberá implementar una estrategia para depurar los datos detallados periódicamente y luego, si es necesario para las tendencias, agregar estos datos para generar informes.

Es MUCHO trabajo... y por supuesto, cada vez que sale una nueva versión de SQL Server, tienes que lidiar con un dolor de cabeza de regresión. A menos que realmente desee vender una herramienta de monitoreo, le recomiendo encarecidamente que no implemente la suya a menos que el volumen de problemas sea bajo y los problemas que debe resolver sean muy específicos.

¿Qué pasa con las herramientas gratuitas?

A menudo vale la pena considerar las herramientas gratuitas, especialmente para equipos más pequeños con instancias menos críticas. Piense en ello como el siguiente paso en la escalera de la escalabilidad después de "roll your own". Muchas de las herramientas comerciales de monitoreo de servidor SQL de nivel de entrada deben tener consideraciones similares. Considere lo siguiente:

  • ¿La herramienta cubre una amplitud suficiente de métricas para brindarle una cobertura adecuada para todos los casos de uso en sus instancias monitoreadas? Muchas herramientas gratuitas le darán algún tipo de "personalización" para agregar sus propias métricas. Cuando se usa la "personalización" para llenar los vacíos en la funcionalidad, rápidamente encontrará que su equipo termina "haciendo lo suyo" con la distracción necesaria y el dolor de cabeza de mantenimiento.
  • ¿Admite alertas la herramienta? ¿Está preconfigurado? La configuración de alertas puede llevar mucho tiempo. Las alertas listas para usar son imprescindibles para evitar muchas horas-hombre perdidas configurando la herramienta de otra persona. También debería facilitar la personalización de alertas para los casos extremos que no se ajustan a los valores predeterminados.
  • ¿Cómo y dónde se almacenan los datos? La mayoría de las herramientas gratuitas le permiten administrar el almacenamiento de los datos de rendimiento. Tenga cuidado con el monitoreo "gratuito" de los proveedores de la nube. Cobran por el almacenamiento, ¡y esto puede volverse grande y costoso rápidamente!

Entonces, por todos los medios, explote las herramientas gratuitas que existen. Solo tenga en cuenta sus limitaciones y esté atento a los antipatrones clásicos dentro de su equipo, como:

  • Se dedica más tiempo a reparar o mantener la herramienta que usarla para solucionar problemas
  • Más dinero gastado en infraestructura y almacenamiento
  • Muchos datos pero ninguna información
  • No hay suficiente profundidad en el diagnóstico para resolver problemas
  • No es lo suficientemente escalable para satisfacer sus necesidades

Si nota algo de lo anterior, debería indicar la necesidad de actualizar a una solución más robusta.

Arquitectura típica de un sistema de monitoreo de SQL Server

Al considerar si optar por una solución local tradicional o una solución de software como servicio (SaaS) alojada, es útil considerar la arquitectura de la aplicación de monitoreo. Este es un resumen de los componentes clave de la arquitectura.

La desviación clave entre SaaS y local se relaciona con dónde se almacenan los datos de rendimiento y quién administra este repositorio. Para una solución local, esto es responsabilidad del usuario final. Estos repositorios pueden crecer rápidamente, por lo que deben administrarse con cuidado. La infraestructura debe planificarse y presupuestarse (más información a continuación).

En una solución SaaS para la supervisión del servidor SQL, estos componentes clave de la infraestructura se alojan y administran para usted.

Solución local tradicional Solución SaaS
  • Proceso de recopilación de datos
  • Repositorio de [diagnósticos] de rendimiento a corto plazo
  • Repositorio de análisis/informes a largo plazo
  • Windows o cliente de navegador
  • Cualquier infraestructura de conmutación por error requerida para la infraestructura de monitoreo
  • Proceso de recopilación de datos (para objetivos locales)
  • Cliente del navegador
  • Aplicación móvil
  • El proveedor de SaaS administra la aplicación y el almacenamiento de datos de back-end.

Para obtener más detalles, consulte nuestro blog, Arquitectura del sistema de supervisión de bases de datos.