Bonus : Monitoreo

Una definición de monitoreo lo considera como el proceso de recolección dinámica, interpretación y presentación de información concerniente a procesos de software bajo observación que se ejecutan concurrentemente[1].

El monitoreo es el primer paso para entender un proceso computacional y para ello proporciona una indicación de lo “QUE” sucede sirviendo como prerrequisito para explicar el “POR QUE” sucede[2].

Para Schroeder, el monitoreo recolecta información de un proceso computacional a medida que éste se ejecuta y puede ser clasificado según su funcionalidad[3] como:

• Monitoreo de Tolerancia a fallos y seguridad (dependability).
• Mejoras al desempeño del sistema (performance enhancement), que incluyen la configuración dinámica del sistema, afinamiento de la programación y manejo en línea del sistema.
• Verificación de exactitud (correctness) que consiste en el monitoreo de la aplicación para asegurar su consistencia respecto a las especificaciones formales.
• Monitoreo de Seguridad (Security monitoring) para detectar intentos de violación de seguridad como accesos ilegales a archivos o al sistema.
• Control, que considera casos en los cuales el sistema de monitoreo es parte del sistema objetivo siendo a su vez un componente necesario de la funcionalidad de dicho sistema.
• Depuración (debugging) y pruebas (testing) emplean las técnicas de monitoreo para extraer datos desde las aplicaciones que están siendo probadas.
• Evaluación del desempeño (performance evaluation) utiliza el monitoreo para extraer datos desde el sistema que posteriormente serán analizados para garantizar el desempeño del mismo.

La técnica ideal de instrumentación para medir la performance debería ser no intrusiva, exacta y fácil de activar y desactivar[4]. Debido a las restricciones teóricas y prácticas para realizar este ideal es que se han desarrollado una plétora de técnicas de instrumentación de hardware y software.

Muchas de las técnicas son variantes de cuatro formas básicas como lo considera Daniel Reed[5]:

• “Profiling”, es la forma más común de instrumentación y en su forma estándar el contador de programa se muestrea a intervalos fijos por lo que el número total de muestras del histograma es una aproximación al tiempo empleado en ese fragmento de código.
• “Counting”, elimina el potencial error estadístico del profiling pero a expensas de una instrumentación más intrusiva. Ahora bien, los contadores pueden perturbar la ejecución del programa lo que en un servidor uniprocesador se manifiesta en un incremento del tiempo de ejecución del programa.
• “Interval Timing”, se realiza insertando llamadas al reloj del sistema dentro del código para computar el  monto de tiempo usado en un fragmento de código en particular.
• “Event Tracing”, potencialmente es el más invasivo y el más detallado; y al igual que el “counting”  y el “timing”, el código del programa a monitorear debe ser modificado para insertar la instrumentación. A nivel de sistema operativo debe emplearse con cuidado pues produce gran nivel de detalle debido a que los eventos ocurren en la escala de microsegundos.

Sin embargo, en términos generales se reconocen dos formas básicas de monitoreo[6]:

• Por muestreo basado en el tiempo (“Time Driven” o “Clock Driven”) también conocido como “sampling”.
• Por eventos basados en ocurrencias que se producen en el proceso o sistema observado (Event Driven), en donde podemos encontrar las técnicas de profiling, counting e interval timing como se puede ver en la figura:

En todos los casos se debe reconocer que el monitoreo genera una carga adicional al consumo de recursos de hardware, pero como indica Almeida[7], esto no llega al 4%, o como indica Bodkin[8], “en la práctica, se añade una inelegible sobrecarga al tiempo de respuesta final de muchas aplicaciones”.

El monitoreo también se puede realizar de dos formas[9]:

1.-  Monitoreo Externo: El consumo de recursos usados por un servidor de aplicaciones o servidor web puede ser monitoreado externamente por medio del envío de peticiones (requests) hacia el sistema operativo donde se ejecutan dichos procesos.

Debido a que las peticiones de monitoreo se originan fuera del servidor a ser monitoreado, algunos denominan a esta forma como aproximación de “caja negra”. Por ejemplo, productos comerciales como Mercury SiteScope y LoadRunner usan esta aproximación.

Se debe tener presente que debido a que esta aproximación no tiene un agente, no significa que no sea “intrusiva”, pues el monitoreo siempre impone una sobrecarga al sistema en observación.

2.- Monitoreo con Agente: Esta aproximación se conoce como “caja blanca” debido a que los monitores son instalados dentro de cada servidor de aplicaciones y servidor web bajo observación.

Los monitores se “instrumentan” para reconocer lo que se quiere monitorear.

La clasificación de monitoreo también considera dos grandes formas[10] de realizarlo:

Intrusivo: Utiliza los recursos del sistema en observación para registrar su comportamiento e incluso puede alterar el desempeño actual del mismo. Un ejemplo de esto es la inserción de sentencias “print” en un programa para mostrar el valor de las variables (esto es lo que se conoce como “instrumentation code”). En este caso,  el monitoreo del sistema utiliza recursos del mismo (procesador, memoria, etc.) lo cual puede cambiar el desempeño del sistema en observación, lo que se conoce como el “efecto Heisenberg”[11] para software.

No Intrusivo: No afecta el tiempo ni el orden de los eventos en el sistema bajo observación. Esto es especialmente importante en el monitoreo de sistema de tiempo real en donde dichas características de tiempo y orden son críticas para la seguridad del sistema. Un ejemplo de monitoreo de este tipo es la adición de un procesador para ejecutar los programas de monitoreo que registran el comportamiento de un sistema en tiempo real.

Además, como menciona Aredo, existen dos técnicas de monitoreo fundamentales para recolectar información[12]:

TRACING : En esta técnica, cada ocurrencia de un evento predefinido  es detectada y todas las ocurrencias de estos eventos son recolectadas de manera continua durante un cierto intervalo de tiempo, típicamente mientras dure la ejecución del sistema en observación. Pequeñas piezas de código, usualmente conocidas como “sensores” son incorporados en el sistema a observar, las cuales ejecutan el registro de la información deseada. Los sensores pueden ser desarrollados de diversas formas.

SAMPLING : en esta técnica, la información acerca de las ocurrencias de los eventos predeterminados es recolectada de forma asíncrona, usualmente debido a requerimientos desde un módulo de monitoreo. El “sampling” o muestreo puede ser ejecutado por “sensores” (sensors) o en algunos casos por “sondas” (probes) que residen en el módulo de monitoreo y que tiene acceso directo al espacio de funcionamiento de la aplicación.

  

La aproximación de muestreo es especialmente útil cuando estamos interesados en estadísticas de tipo acumulativo como por ejemplo el número total de mensajes enviados o recibidos por un nodo durante las diferentes etapas de ejecución de la aplicación bajo observación.

El uso de sondas puede minimizar la perturbación en que podría incurrir la aplicación al tener sensores debido a que los sensores se ejecutan de forma continua mientras que las sondas son invocadas después de cierto intervalo de tiempo basado en el ratio de muestreo especificado por el usuario.

Pese a todo, el monitoreo de un sistema distribuido traen dos complicaciones[13] básicas como son:

• El tamaño del sistema es físicamente grande y lógicamente complejo, lo que lo hace muy difícil de manejar.
• Los programas distribuidos tienen un comportamiento no determinístico lo que hace que su ejecución sea difícil de reproducir.

Para Schoeder[14] el monitoreo de sistemas distribuidos  tiene otras complicaciones:

• Existe un retardo en transferir la información, lo que significa que la información pueda estar desactualizada.
• Retardos variables en la transferencia de la información pueden resultar en eventos que arriban de manera desordenada.
• El número de objetos generando información para el monitoreo en sistemas grandes puede colapsar fácilmente a los monitores.
• Debido a que los eventos que ocurren en un sistema distribuido son heterogéneos, se requiere una forma estándar de codificar los mensajes pasados entre máquinas heterogéneas.

---

[1] AL-SHAER, Ehab Salem; “A Hierarchical Filering-Based Monitoring Architecture for large-Scale Distributed Systems”. Tesis Doctoral, Universidad Old Dominion, Norfolk, Virginia, Estados Unidos; Diciembre del 1998.

[2] SNODGRASS, Richard. “A Relational Approach to Monitoring Complex Systems”. Universidad de Carolina del Norte, Estados Unidos; pág. 158.

[3] SCHROEDER, Beth A.  “Online Monitoring: A Tutorial”. Universidad Estatal de Nueva York, Binghamton. 1995.

[4] REED, Daniel A., "Experimental Analysis of Parallel Systems: Techniques and Open Problems," Proceedings of the 7th International Conference on Modelling Techniques and Tools for Computer Performance Evaluation, Viena, Austria, Mayo de 1994, pp. 25-51.

[5] REED, Daniel; Op. Cit.

[6] KERGOMMEAUX, J. Chassin; MAILLET, E; VINCENT, J.M. « Monitoring Parallel Programs for Performance Tuning in Cluster Environments »; pág. 139.

[7] ALMEIDA Jussara M.; ALMEIDA,  Virgilio; YATES, David J.; "WebMonitor: a Tool for Measuring World-Wide Web Server Performance", “First Monday, Peer-Reviewed Journal on the Internet”,  vol. 2, No. 7, July 1997.

[8] BODKIN, Ron. “AOP@Work: Performance Monitoring with ApsectJ, Part1“, publicado en IBM DeveloperWorks.

[9] Tomado de MAR, Wilson. En:  http://www.wilsonmar.com/1perfmon.htm

[10] Autor desconocido. Obtenido de la siguiente fuente:  http://media.wiley.com/product_data/excerpt/63/04711840/0471184063.pdf

[11] El efecto Heisenberg describe un sistema en el cual la observación o medida de un evento cambia el evento. Fuente: http://www.inf.ethz.ch/news/focus/res_focus/april_2005

[12] AREDO, Demissie B. “Monitoring and Visualization of Distributed Systems”, pág. 20.

[13] AREDO, Demissie B.;Op. Cit pág 5.

[14] SCHROEDER, Beth A.  “Online Monitoring: A Tutorial”. Pág 74,75.