SystemDataRecorder

Desafío

SystemDataRecorder es quizás el paquete más completo y sencillo para la supervisión profesional del rendimiento, el análisis del rendimiento, el dimensionamiento de sistemas y la planificación de la capacidad en entornos empresariales exigentes. Proporciona un registro de datos coherente en todos los sistemas y dispositivos, permite acceder a los datos sin procesar y está diseñado para realizar análisis de series temporales. Puede que a los no expertos en software no les lo parezca, pero lo cierto es que se trata de una solución muy potente y largamente esperada para un problema de larga data.

Aunque los ordenadores existen desde hace más de 25 años, sigue sin haber una supervisión coherente del rendimiento entre distintos sistemas operativos, ya que cada entorno despliega su propio tipo de herramientas de supervisión y recopilación de datos. El registro coherente de datos entre distintos sistemas operativos es muy difícil de realizar sin adquirir software independiente para cada entorno o instalar soluciones de terceros. Incluso el formato utilizado para registrar los datos varía de un sistema a otro, lo que convierte la recopilación y el análisis de datos en una pesadilla logística.

Si se observan detenidamente los distintos sistemas operativos, es fácil ver que los métodos para obtener datos de rendimiento son en realidad similares, pero se utilizan distintas interfaces con terminología variable según los distintos proveedores y el tipo específico de implementación. La idea en la que se basa SystemDataRecorder es disponer de varios agentes estándar de recopilación de datos para obtener métricas de las interfaces del sistema y exportar esta información de forma unificada. Para los datos exportados, se puede utilizar un archivo de texto plano, renunciando a cualquier formato de archivo especial, para que este archivo sea utilizable por cualquier herramienta analítica disponible. De este modo, un sencillo módulo de registro de datos puede utilizarse para la resolución de problemas del sistema, el análisis del rendimiento, el análisis de caídas del sistema, etc., y es fácil de habilitar en un gran número de hosts de un centro de datos, y el sistema operativo utilizado ya no desempeña ningún papel.

SystemDataRecorder ya estaba disponible y estaba demostrando ser la luz al final del túnel para sistemas Linux y Solaris, cuando se contactó con Redwerk para adaptarlo también a entornos de servidores Windows 2003 y 2008. El objetivo era que estos servidores funcionaran con métricas similares a las de SystemDataRecorder para Linux o Solaris. La solución tenía que utilizar el menor número posible de recursos del sistema, ser de pequeño tamaño y lo suficientemente robusta para no crear sobrecargas en el sistema. Los grabadores debían implementarse como servicios de Windows, es decir, aplicaciones nativas para sistemas de 32 y 64 bits. Todos los datos debían almacenarse en un archivo de texto sin formato.

Un reto adicional fue trasladar a Windows la capacidad de supervisar la salida de los archivos de datos sin procesar. Por cada cambio en un archivo, debía enviarse un POST HTTP/HTTPS a un sistema backend para su posterior análisis. El programa debía distribuirse como un paquete de software apto para su instalación automática en Windows sin necesidad de interacción del usuario.

Solución

Nuestra investigación demostró que un servicio escrito en C/C ++ que recibe docenas de parámetros y escribe datos en un archivo utiliza unos 2 MB de RAM y sólo unos recursos de CPU menores. El mismo servicio en C# utiliza un mínimo de 6 MB, y aunque es más fácil de desarrollar también requiere un mínimo de .NET 2.0. Tras analizar las ventajas y desventajas, el código se desarrolló en C. De esta forma conseguimos minimizar la abstracción y pudimos utilizar rutinas sencillas para acceder a las métricas del núcleo de Windows sin los sobrecostes que hubiera conllevado el uso de un lenguaje orientado a objetos. Todos los datos del servicio se obtuvieron de la API WMI.

Para cada registrador individual, el parámetro clave que debe utilizarse es el número de segundos entre cada medición. El valor por defecto era de 60 segundos. También encontramos una solución para el lanzamiento con un parámetro determinado en Windows. Los grabadores se inician y escriben los datos en sus propios archivos individuales. Tras este paso inicial, los archivos se rotan y comprimen. En Linux o Solaris esto se implementa utilizando cron, pero para Windows tuvimos que encontrar nuestra propia solución.

El proceso de desarrollo fue muy sólido y se basó en pasos lógicos de investigación, pruebas e implantación. Las pruebas incluyeron algunas cuestiones muy interesantes. Tuvimos que asegurarnos de que los grabadores funcionaran sin fugas de memoria ni otras desviaciones durante al menos 48 horas. Incluso los dejamos funcionando durante el fin de semana, para poder supervisarlos adecuadamente, realizando pruebas de aceptación adecuadas.

Para que el proceso y la solución sean sólidos y completos, también hay que tener en cuenta situaciones de emergencia como cortes de electricidad o reinicios imprevistos del sistema. Para hacer frente a estas situaciones, los servicios deben reiniciarse automáticamente durante el arranque del sistema y seguir registrando y almacenando datos en los archivos de salida.