PDF de programación - Monitorización del sistema

Monitorización del sistema

Administración de sistemas informáticos

Fernando Pérez Costoya – Noviembre de 2013



Índice

● Aspectos generales de la monitorización
● Monitorización del procesador
● Monitorización de la memoria
● Monitorización de los discos
● Monitorización de la red
● Monitorización remota
● Monitores integrados: visión general de Nagios
● Monitores para sistemas distribuidos



Un día en la vida del administrador
● Empresa 24/7, 4 A.M., caída servicio web

● ¿cómo se entera el administrador?
● ¿cómo detecta cuál es el problema?

– ¿servidor web caído, nodo caído, red caída, partición llena,

servidor DNS caído, …?

● ¿cómo lo corrige?

● Adm. ocasionalmente instala/configura/actualiza
● Permanentemente vigila y supervisa



Sistema de monitorización

● Conjunto herramientas que supervisan sistema

● Mostrando datos del mismo
● Y, sobretodo, notificando problemas a equipo admin.

● Un buen sistema de monitorización:

● Facilita la vida a los administradores
● Posibilita el correcto dimensionamiento del sistema
● Facilita el cumplimiento de SLAs
● Se integra en el plan estratégico de la organización



Sistema de monitorización

● Un mal sistema de monitorización:

● Mayor agujero de seguridad
● Genera sobrecarga en el sistema
– Recursos de procesamiento y de red

● Provoca falsas alarmas
● Genera demasiados avisos

– Si falla un router avísame sólo de ese fallo

● No me notifiques que no tengo acceso a cada uno de los servicios

ejecutando en cada una de las máquinas detrás del router

● Acaba siendo ignorado por la organización (SPAM)



Equipo de administración

● Complejo, jerárquico, con roles especializados

● Administrador del SGBD, de la red, ...

● Política de distribución de notificaciones y

responsabilidad en su tratamiento:
● ¿quién está de guardia?, ¿hay alguien tratando ya el
problema?, ¿qué ocurre si el responsable no trata el
problema detectado en un tiempo dado?, ¿de qué
tipo de problemas debería ser informado un
administrador de alto nivel?, ...



Tantas cosas pueden ir mal...

● Aplicación/servicio con comportamiento erróneo
● Caído, no responde, ejecución ralentizada, incluso

ralentiza o cuelga todo el sistema

● S.O. con comportamiento erróneo

● Sistema ralentizado o incluso colgado

● Fallos de componentes hardware

● No responde o de forma ralentizada o errónea,

incluso ralentiza o cuelga sistema (tarjeta red
interrumpe sin cesar)

● Disco lleno (aunque no sea fallo HW)

● Ataques a la seguridad → objeto de otro tema



Tantas cosas pueden ir mal...

● Aunque no fallen componentes HW o SW...

● Carga actual satura procesador|memoria|discos|red

– Hay nuevas aplicaciones/servicios
– Crecen demandas aplicaciones/servicios existentes

● P.e. Servidor web con mayor número de clientes

● Incluso sin saturación, optimización en rendimiento

de aplicaciones, servicios y del propio S.O.
– Permite mejor servicio: a más y/o más rápido



Vigilancia de los síntomas

● Monitorización de disponibilidad

● Aplicaciones/servicios activos y respondiendo

– P.e. Solicitar página web a servidor

● Dispositivos en correcto funcionamiento

– “Probe” de dispositivos
– Discos no llenos

● Comprobación de logs del sistema

● Monitorización de rendimiento

● Supervisión gasto de recursos por procesos y S.O.
● Profiling de procesos y S.O.



“Cura” ante fallos disponibilidad

● Ante no disponibilidad aplicación/servicio

● Reactivación apl/srv con posible actual./reconf previa

– Análisis de logs de aplicación/servicio
● Ante no disponibilidad del sistema

● Reinicio con posible actualización/reconfig. previa

– Análisis de logs del sistema

● Ante fallo disponibilidad HW

● Sustitución/actualización de componentes HW
● Ante disco lleno, borrar ficheros



“Cura” ante déficit de rendimiento

● Primero determinar causa

● Si aplicación/servicio erróneo acapara recursos

– Reactivación apl/srv con posible actual./reconf previa (logs)

● Si SO erróneo acapara recursos

– Reinicio con posible actualización/reconfig. previa (logs)

● Si componente HW erróneo acapara recursos

– Sustitución/actualización de componentes HW

● Si no errores en HW/SW, saturación de carga

– Mejora equipamiento HW (más UCPs, memoria, discos,...)
– Reconfiguración de sistema de almacenamiento



● RAID, SSD, alg. plan. disco, tipo de journaling, ...



– Reconfiguración de red

Ciclo de vida del mantenimiento

Sensores

Objetivo

<>

Equipo
Admin.

Sistema

Actuadores



Ciclo de vida del mantenimiento

● Sistema: Conócelo/documéntalo:(conf. HW/SW)

● Deberás compartir esa información al pedir ayuda

● Sensores: Establecer métricas (¿qué se mide?)
● Monitorización de disponibilidad vs. de rendimiento

– Buen funcionamiento (booleano) vs. Grado de uso

● Uso de múltiples herramientas de monitorización
● Obtención de históricos: establecer baselines
● Puede incluir profiling de aplicaciones o del SO

– Además de qué recursos se gastan, ¿dónde?



● Principio de incertidumbre

– Herramientas ligeras (p.e. mejor no en Java)



Ciclo de vida del mantenimiento

● Objetivo (¿qué queremos conseguir):

● Disponibilidad: componentes HW/SW funcionando
● Rendimiento: uso eficiente de componentes HW/SW

– Relativos a baselines
– Relativos a sistemas afines o estándares

● Control y actuadores:
● Asegurar estabilidad
● Cambios incrementales
● Medir después de cada cambio
● Plan de vuelta atrás
● Todo documentado exhaustivamente



Bucle cerrado de control

Sensores

Objetivo

<>

Lógica de
control

Sistema

Actuadores



Autonomic Computing

● Sistemas cada vez más complejos: autogestión

● Iniciativa de IBM aplicable especialmente a SD

– Inspirado por sistema nervioso autónomo

● 4 áreas funcionales:

● Auto-configuración; Auto-reparación
● Auto-optimización; Auto-protección

● 5 niveles evolutivos de implantación:

● Desde gestión manual componentes aislados (hoy)
● Hasta g. automatizada de sistema en su integridad
– Uso de bucle cerrado de control → ¿el futuro cercano?



Profiling

● Estadísticas de gasto de recursos de módulo SW

● ¿Qué recursos se usan en cada parte del módulo?
● Aplicable a aplicaciones y al propio SO

● Detección de partes a optimizar
● Implementación clásica: muestreos periódicos
● Implementación actual:

● Usa “contadores de rendimiento” HW

● Linux: oprofile, perf (más moderna y general)

● https://perf.wiki.kernel.org/index.php/Tutorial



Logs

● SO, servidores, apps. generan eventos de log

● Diversos niveles de gravedad: de info. a emergencia
● Info. problemas HW/SW, seguridad, instalación, ...

● Fuente de info. básica para la monitorización
● Sistemas ofrecen funcionalidad para:

● Configurar tratamiento eventos (UNIX syslog)
● Ver los eventos (Windows Event Viewer)
● Rotación de logs (UNIX logrotate)
● Herramientas de análisis de logs (UNIX logckeck)



Monitorización del (mal)rendimiento

● Procesadores | Memoria | Almacenamiento | Red
● Supervisión a nivel global vs. a nivel de proceso

● A veces hay que centrarse en una aplicación

– Por su importancia (web) o por su comportamiento erróneo

● Modo de muestreo:

● Instantáneo (con varias iteraciones), agregado desde

arranque, basado en histórico (UNIX: sar)

● Windows: Task Manager, perfmon y Data

Collector Set



Monitorización de los procesadores

● Parámetros relevantes

● Uso de los procesadores

– Distinguiendo entre distintos niveles de ejecución

● Linux: %usr %nice %sys %iowait %irq %soft %steal %guest %idle

● Longitud de la cola de listos:

– Buen indicador de la carga del sistema

● Otros: nº c. contexto, nº interrup., nº proc. creados…



Mon. procesadores Linux

● uptime ; w
● vmstat
● mpstat
● Otros: procinfo | top | iostat | /proc/loadavg
● sar (modo instantánea e histórico)



Monitorización uso de UCP/proceso
● Uso de procesador por parte del proceso

● Distinguiendo tiempo usuario y sistema

● Herramientas Linux

● ps, top, time
● /proc/pid/stat
● Profiling: además de oprofile y perf

– Traza llamadas al sistema (strace) y de biblioteca (ltrace)



Monitorización de la memoria

● Parámetros relevantes:

● Tamaño de memoria física y su estado:

– Asignada actualmente a procesos
– Asignada al SO (en Linux SO siempre residente)
– Usada para caché de ficheros u otro tipo de buffers

● Tamaño|ocupación disp(s) paginación (Linux swap)
● Estadísticas sobre las operaciones:

– Tasa de fallos de página

● Distinguiendo minor (sin E/S) y major (con E/S)

– Páginas leídas/escritas del sistema de ficheros
– Páginas leídas/escritas del dispositivo de paginación



Mon. memoria en Linux

● free
● swapon
● vmstat
● Otros: procinfo | top | /proc/meminfo
● sar (modo instantánea e histórico)



Linux: interpretación mandato free

total used free shared buffers cached
Mem: 2074304 1921392 152912 0 96128 1522424
-/+ buffers/cache: 302840 1771464
Swap: 4000112 129044 3871068



Monitorización memoria/proceso
● Memoria virtual y física consumida por proceso

● Fallos de página causados por el mismo

● Herramientas Linux

● ps, top
● /proc/pid/status, /proc/pid/statm
● pmap, /proc/pid/pmap



Monitorización de E/S de disco

● Parámetros relevantes

● Bloques leídos/escritos (total y cuántos/seg.)
● Porcentaje de ocupación del disco
● Nº operaciones que pueden juntarse
● Tamaño medio de cola de espera del disco
● Tiempo medio de servicio una petición

● Linux no estadísticas de E/S disco por proceso

● lsof (fuser): qué procesos usan qué ficheros



Mon. E/S de disco en Linux

● vmstat
● iostat
● /proc/diskstats
● sar (modo instantánea e histórico)



Monitorización de la red

● Parámetros relevantes

● Paquetes enviados/recibidos

– Distinguiendo los de tipo multicast

● Bytes enviados/recibidos
● Estadísticas sobre distintos tipos de errores

– Paquetes erróneos recibidos,