Existe un número creciente de excelentes sistemas de monitoreo de rendimiento de bases de datos. Recientemente, las soluciones locales más tradicionales se han unido a las soluciones de software como servicio (SaaS).
Este blog contrasta la arquitectura típica de una solución local con la de una solución SaaS. Por supuesto, los componentes variarán en nombre y estructura de un proveedor a otro, pero los conceptos clave discutidos aquí se representarán de una forma u otra.
Diferencias entre soluciones locales y SaaS
En general, estos son algunos de los componentes clave de cada solución:
Solución local tradicional
- 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.
Solución SaaS
- 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.
Tenga en cuenta que los nombres de los diversos componentes variarán de una solución a otra. En algunos casos, la funcionalidad puede dividirse entre múltiples servicios o fuentes de datos.
Soluciones locales
Proceso de recopilación de datos
El recopilador de datos suele ser un servicio sin agente en las instalaciones que recopila datos de cualquier extremo supervisado en las instalaciones. Este proceso organiza cómo y cuándo se recopilan los datos. Debe ser capaz de recopilar datos a diferentes frecuencias para equilibrar la necesidad de más detalles con el impacto en la carga de trabajo monitoreada. Las frecuencias de recopilación y los umbrales de alerta deben venir preconfigurados en cada métrica.
Todos tendrán una instancia "ruidosa" que no se ajusta a los umbrales estándar. Esto puede resultar en una gran cantidad de falsos positivos. Para hacer frente a esto, el sistema debe tener la capacidad de crear reglas a nivel de instancia para hacer frente a circunstancias excepcionales. Esto evita la "fatiga de alarma" de los falsos positivos.
En algunos casos, este servicio también organiza alertas y notificaciones. En organizaciones grandes con cientos de instancias monitoreadas, puede ser necesario equilibrar la carga "federando" varios recopiladores de datos. La federación sincroniza colecciones y configuraciones en un sistema disperso.
Repositorio de diagnósticos a corto plazo
Aquí es donde se almacenan los datos detallados. Esto incluiría datos de DMV, archivos de registro, XEvents y otras fuentes de datos de SQL Server. Deben evitarse las fuentes que podrían ejercer presión sobre las instancias monitoreadas, por ejemplo, la mayoría de los rastros no son adecuados para el monitoreo en tiempo real.
Debido a que las frecuencias de recopilación pueden ser tan frecuentes como cada segundo y se recopilan fragmentos de datos más grandes, como TSQL y planes, este repositorio puede crecer rápidamente. Como resultado, la mayoría de los sistemas normalmente limitarán el historial entre una semana y un mes (estas limitaciones no se aplican a una solución SaaS). Este repositorio es de naturaleza altamente transaccional.
Repositorio de análisis/informes a largo plazo
Al final de un tiempo predefinido, estos datos detallados se agregan y almacenan en un repositorio de informes para análisis y tendencias de alto nivel. La cantidad de detalles retenidos tendrá un impacto significativo en el tamaño final de este repositorio y la capacidad informática que uno puede esperar razonablemente que un usuario ponga a disposición para analizarlo. Esto tiende a variar considerablemente de una solución a otra. Las soluciones que admitan análisis más profundos tendrán arquitecturas compatibles y pueden usar arquitecturas OLAP para facilitar el análisis multidimensional.
Ampliar una solución de supervisión local
Se diseñarán soluciones más sofisticadas para facilitar una arquitectura distribuida de los componentes clave para soportar la escala. El servicio de recopilación de datos tendrá un número superior de conexiones supervisadas que puede admitir. Una vez que se alcanza este límite, se debe "federar" un recopilador de datos adicional para coordinar la recopilación de datos y orquestar el almacenamiento de los datos.
Los propios repositorios de datos de rendimiento pueden compartir una instancia o pueden distribuirse entre varias instancias para admitir la escala. El almacenamiento que requieran será directamente proporcional al número de conexiones monitoreadas y al volumen de datos retenidos. La estructura y la arquitectura del repositorio de análisis también afectarán la capacidad total.
Experiencia de usuario
La mayoría de las herramientas locales tendrán un front-end de Windows. Algunos tienen interfaces de navegador basadas en una implementación alojada localmente. El acceso remoto a estos puede ser complicado y, por lo general, requiere una VPN. Rara vez admiten aplicaciones móviles.
Alta disponibilidad
El software de monitoreo que monitorea las cargas de trabajo de misión crítica debe ser resistente por derecho propio. Deben tomarse medidas para manejar situaciones de desastre que puedan desconectar la estructura de monitoreo. Esto también debe considerarse desde una perspectiva de arquitectura y costo.
Soluciones SaaS
Proceso de recopilación de datos
Aunque una oferta de SaaS se aloja principalmente, a menudo mantendrá un recopilador de datos local para las cargas de trabajo locales. Esto ayuda a abordar las limitaciones de rendimiento y seguridad. De esta manera, cualquier conexión a nivel de instancia se realiza a través del recopilador local, que luego transmite los datos de rendimiento de la base de datos monitoreada al servicio de ingreso a la nube. Todos los datos deben cifrarse en tránsito.
Repositorios de diagnósticos e informes/análisis
La buena noticia aquí es que el proveedor de SaaS maneja todo su almacenamiento de datos. No tiene que preocuparse por crear instancias para los repositorios de diagnóstico, repositorios de informes, vaciar el repositorio de diagnóstico o muchos de los otros dolores de cabeza asociados con una implementación local.
Las soluciones alojadas se basarán en diferentes estrategias de almacenamiento en el back-end para facilitar una combinación de actividad transaccional y analítica, según corresponda. Pueden aprovechar los recursos de la nube para manejar mayores volúmenes de datos y el procesamiento necesario para el análisis; por ejemplo, Spotlight Cloud guarda un año de datos detallados. Por lo tanto, no solo puede informar un año atrás en el tiempo, sino que también puede reproducir su carga de trabajo hasta un año en el pasado. Esta es una capacidad realmente poderosa.
Una solución SaaS para el monitoreo del rendimiento de la base de datos puede usar una variedad de estrategias de almacenamiento de back-end no solo para adaptarse a la naturaleza más transaccional del diagnóstico y el monitoreo, sino también para facilitar el procesamiento de números de alta intensidad asociado con el análisis a largo plazo. El proveedor de SaaS puede aprovechar considerables economías de escala para utilizar una infraestructura mucho más poderosa que estaría a disposición de las organizaciones individuales.
Cómo escalar una solución SaaS
Escalar una solución SaaS es responsabilidad del proveedor y no del usuario. Cualquier solución SaaS para el monitoreo del rendimiento de la base de datos debe construirse para escalar desde el primer día y, como resultado, tiende a manejar la escala con calma.
Experiencia de usuario
Las aplicaciones SaaS tendrán un navegador Ux predeterminado y muchas también tendrán aplicaciones móviles integrales. Esto facilita equipos dispersos y remotos.
Seguridad y Cumplimiento
La mayoría de las soluciones SaaS se construirán sobre una de las principales infraestructuras en la nube, como Azure o Amazon. Muchos de los proveedores líderes cuentan con infraestructuras de seguridad sofisticadas. Invierten mucho en respaldar las necesidades de cumplimiento de sus clientes.
Alta disponibilidad
La buena noticia aquí nuevamente es que esto es responsabilidad del vendedor. Vale la pena consultar con su proveedor para averiguar qué provisión han realizado en términos de conmutación por error y alta disponibilidad. Las aplicaciones SaaS deben diseñarse para ser muy resistentes. Los diversos servicios que componen una aplicación SaaS generalmente están diseñados para ser resistentes individualmente. También se pueden hacer provisiones para interrupciones del centro de datos en las que la aplicación conmutaría por error de un centro de datos a otro en caso de una interrupción del centro de datos.
