Se identifica la necesidad y la problemática de medir. Se aborda todo aquello que facilita los procesos de "Soporte Proactivo", "Capacity Planning", "Verificación de SLAs". Se presentan los conceptos fundamentales de gestión de fallas y performance de infraestructura y servicios TIC.

1. Monitoreo de Infraestructura y Servicios TIC

2. Seminario
“Monitoreo / medición
de infraestructura y servicios TIC”
Ing. Marcelo Utard
Socio Gerente - U&R Consultores
mutard@uyr.com.ar
Ing. Nicolás Matsunaga
Gerente de Tecnología - U&R Consultores
nmatsunaga@uyr.com.ar

3.  Se identifica la necesidad y la problemática de medir.
 Se aborda todo aquello que facilita los procesos de
"Soporte Proactivo", "Capacity Planning", "Verificación
de SLAs".
 Se presentan los conceptos fundamentales de gestión
de fallas y performance de infraestructura y servicios
TIC.
Contenido

4.  Se describen las metodologías, mecanismos,
herramientas, tecnologías, que se suelen y pueden
utilizar para medir.
 Se detallan algunas métricas (variables) y métodos de
medición (probes).
 Se presenta de qué modo se suele mostrar la
información resultante de las mediciones (vistas,
reportes).
Contenido

5. ¿Por qué medir?
 Gestión de calidad de servicio
 satisfacción de necesidades
 Gestión presupuestaria
 control de gastos e inversiones
 control de proveedores

6. La medición o monitoreo, sistemático y permanente,
permite hacer:
 Soporte proactivo
 Capacity planning
 Verificación de SLAs
¿Para qué medir?

7. Para que los usuarios no perciban fallas:
 minimizar el tiempo de restauración MTTR
 maximizar el MTBF (disminuir la ocurrencia de fallas)
 evitar las fallas predecibles
 evitar las fallas recurrentes
¿Para qué medir?
Soporte Proactivo

8. Medir permite:
 minimizar el tiempo de restauración MTTR
 detectar las fallas en forma temprana
 alertar a los operadores y administradores
 contar con información para el diagnóstico
¿Para qué medir?
Soporte Proactivo

9. Medir permite:
 evitar la saturación de recursos
 identificar el desperdicio o mal uso de recursos
 predecir los cuellos de botella
 evitar fallas recurrentes
 identificándolas y corrigiendo sus causas
¿Para qué medir?
Soporte Proactivo

10. Redimensionar los recursos,
 en función de las necesidades genuinas,
 racionalizando el presupuesto,
 con el tiempo de antelación suficiente.
¿Para qué medir?
Capacity Planning

11. Medir facilita el capacity planning,
 relevando el grado de utilización de los recursos TIC
 mostrando la tendencia en el uso de los recursos
 permitiendo la estimación de la medida justa de
incremento
¿Para qué medir?
Capacity Planning

12. SLA Service Level Agreement (Acuerdo de Nivel de Servicio)
 define clara y cuantitativamente el alcance del servicio
 compromete a quien lo provee
 su incumplimiento es penalizado
¿Para qué medir?
Verificación de SLAs

13. “Extended enterprise”
 SLAs con usuarios internos
 SLAs con clientes
 SLAs con proveedores
¿Para qué medir?
Verificación de SLAs

14. Medir facilita la verificación de los SLAs:
 relevando las métricas
 comparándolas con umbrales
 calculando el grado de cumplimiento
 generando reportes
¿Para qué medir?
Verificación de SLAs

15. En términos generales, es necesario medir variables o
métricas de:
 Estado
 Uso de recursos
 Performance
¿Qué medir?
Variables o Métricas

16.  Alcanzabilidad de un host o router
 Estado operativo de una interfaz
 Estado de un proceso
 ...
¿Qué medir?
Variables de Estado

17.  Carga de CPU
 Uso de memoria
 Uso de ancho de banda
 Tráfico Tx/Rx (tramas/paquetes, bytes)
 Composición de tráfico (por aplicación, por src/dst, ...)
 ...
¿Qué medir?
Variables de Uso de Recursos

18.  Time
 round trip time
 response time
 transit delay
 delay jitter
 Packet loss
 ...
¿Qué medir?
Variables de Performance

19.  Info “real time” para:
 saber si todo está up&running
 Info histórica para:
 identificar y diagnosticar fallas y problemas
 hacer baselining
 dimensionar capacidad
 controlar SLAs
¿Qué medir?
Real time vs Histórica

20.  operaciones
 mesa de ayuda
 administradores de plataformas/aplicaciones
 planificación/tecnología/ingeniería
 jefes/supervisores/gerentes
 con mayor o menor dominio técnico
¿Para quién medir?
Grupos de usuarios

21.  Fácil para tomar decisiones
 operativas (troubleshooting)
 de negocios (costo/beneficio)
 Escalable
 Confiable
 Costo/beneficio
 Restricciones presupuestarias
 ROI
¿Para quién medir?
Requisitos de usuarios

22. NSM: Network & System Management
 NMS Network Management Station
 Probes & Agents “Activos”
 ICMP Echo (ping), SNMP
 TCP, UDP, DNS (nslookup/dig)
 HTTP/HTTPS (wget), SQL (query/SP), ...
 Probes & Agents “Pasivos”
 Sniffer, RMON, Netflows, ...
¿Cómo medir?
Arquitectura de NSM

23. Clases de Funciones de Management:
 Fault/Problem Management
 Performance/Resource Mgmt
 Configuration Management
 Security Management
 Accounting/Billing Management
NSM
Funciones de Management

24.  Licenciadas & Free
 Especializadas en management de:
 Líneas de dispositivos:
- Routers/Switches, Servers, etc
 Servicios:
- Mail, RDBM, ERP, etc
 Tipo/clase de management:
- Fault,Perf,Config,etc
 Plataformas de integración
NSM
Aplicaciones / Herramientas

25.  p/integrar aplicaciones de NSM
 p/compartir datos
 de config,
 de status,
 de eventos
 es un único tablero de control
 disminuye las tareas de sysadmin
NSM
Plataformas de management

26. Tipos de objetos medidos/monitoreados:
 Servicios
 Nodos (Equipos, Dispositivos)
 Recursos
 Trafico
NSM
Medición / Recolección de datos

27.  Reachability/Availability
 Tiempo de respuesta
 Grado de utilización
 Verificación de contenidos
 SLA conformance/violation
NSM
Tipos de Mediciones

28.  Composición de tráfico
 por Source/Destination Address
 por Protocolo (ICMP,TCP,UDP,etc)
 por ICMP Type
 por Src/Dst Port
NSM
Tipos de Medición

29.  Composición de retardo
 end-to-end time
 network transit time
 queueing time
 insertion time
 propagation time
 processing/switching/forwarding time
 connection setup time
NSM
Tipos de Medición

30. Rondas de muestreo
 Intervalo de muestreo
 Timeout y retries
 Problema de timeouts
NSM
Polling

31. Almacenamiento de datos recolectados:
 Flat files
 RDBMs
 RRDBs
 Ocupación de espacio
 Sumarización/Promediación
NSM
Recolección de datos

32. Probes (puntas de prueba):
 Activos
 Pasivos (sniffers/snoopers)
 Embebidos (agents)
 Dedicados/externos
 Propietarios
NSM
Probes

33. ICMP Echo (Ping)
 %disponibilidad de nodos e interfaces
 RTT (Round Trip Time)
 Throughput
NSM
Probes

34. SNMP
 snmpget, snmpset, snmpnext, snmptrap
 OIDs
 MIBs:
 MIB2
 Host, etc
 SNMPv1, SNMPv2c, SNMPv3
NSM
Probes

35.  TCP
 UDP
 SMTP, POP3, IMAP4
 DNS, LDAP, Radius
 DHCP
 SQL
 HTTP/HTTPS
NSM
Probes

36.  SNMP Master agent / MIB subagents
 RMON Agents
 Cisco Netflows
 Cisco IPSLA Agent
 Nagios Agents
 Propietary Agents
 HP, IBM, BMC, CA
NSM
Agents

37. Generación de eventos por detección de:
 fallas
 cambios de estado
 tiempos de respuesta lenta
 recursos agotados/saturados
 recolección de datos y cruce de umbrales
 >, <, =, !=
 fijos, variables
 baselines
NSM
Evento, Alarmas & Alertas

38. Mecanismos/protocolos de notificación de eventos:
 snmptraps
 mails
 syslogs
NSM
Evento, Alarmas & Alertas

39. Tratamiento de los eventos:
 Formato de mensajes de log
 Categorización de eventos
 por severidad
 por tipo/clase
 Disparo de alertas
 Events forwarding
 Events correlation
 Seguimiento de estado de alarmas
NSM
Evento, Alarmas & Alertas

40. Mecanismos de alerta:
 Logs
 Mails
 Paging
 Audio: TextToSpeech, Streaming
 Llamada telefonica
 TroubleTickets
 Otras acciones (command exec)
NSM
Evento, Alarmas & Alertas

41.  Event Notification
 Exception Notification
 KeepAlive Notification
 Data Collection
 Polling
 Reporting
¿Cómo medir?
Metodologías

42.  Notificación de eventos
 por excepción
 keep-alive
 mensajes de log
 disparo de alertas
 ejecución automática de acciones
¿Cómo medir?
Event Notification

43.  sólo notifica excepciones
 “no news, good news”
 problema de pérdida de notificaciones
 no sirve para seguimiento de estados
 tormenta de eventos
 demasiada información, “se escapa la tortuga”
 no sirve para coleccionar datos
¿Cómo medir?
Exception Event Notification

44. Notifica siempre, periódicamente
 resuelve el problema de pérdida de notificaciones
 sirve para seguimiento de estados
 sirve para coleccionar datos (ver reporting)
¿Cómo medir?
KeepAlives Notification

45. Encuestado periódico desde la NMS
 medición de variables más relevantes
 comparación con umbrales
 almacenamiento de muestras
¿Cómo medir?
Data Collection: Polling

46. Sirve para:
 seguimiento de estados
 generar alertas
 coleccionar datos históricos
¿Cómo medir?
Data Collection: Polling

47. Desventajas:
 Mayor consumo de ancho de banda que Event
Notification
 Complejidad de probes en NMS
 Mayor exigencia de CPU y memoria en NMS
¿Cómo medir?
Data Collection: Polling

48. Otros problemas:
 dependencias topológicas
 ronda de polling y timeouts
 secuenciación inevitable
¿Cómo medir?
Data Collection: Polling

49. Notificación periódica de datos a la NMS
 medición de variables más relevantes
 comparación de umbrales
 almacenamiento de muestras
Sirve para:
 seguimiento de estados
 coleccionar datos históricos
¿Cómo medir?
Data Collection: Reporting

50. Contras:
 Complejidad de probes en Agentes
 Mayor exigencia de CPU y memoria en Agentes
Pros:
 Menor exigencia de CPU y memoria en NMS
 Mayor escalabilidad que el polling
 Evita muchos problemas del polling
¿Cómo medir?
Data Collection: Reporting

51. el estado de medición de una variable depende del estado
de medición de otras variables
 dependencias topológicas
 árbol vs malla de dependencias
• polling/recolección en función del estado
 alarmas en función del estado
 cálculo de disponibilidad en función del estado
¿Cómo medir?
Estado de una variable

52. Vistas, Mapas, Reportes
 de Estado
 de Uso de Recursos
 de Performance
 de Disponibilidad
 de Log de Eventos
 ...
¿Cómo mostrar lo medido?
Vistas, Mapas y Reportes

53. La implementación y el mantenimiento del NSM es un
proceso cíclico que consiste en:
 Relevar/ corregir “baselines”
 Configurar/ ajustar umbrales y alarmas
 Monitorear
 Analizar fallas detectadas
 ¿Excesivas fallas no detectadas?
 ¿Excesivas falsas alarmas?
NSM (Net & Sys Mgmt)
Tareas de OA&M

54. ABM (Altas, Bajas y Modificaciones) de:
 mediciones/recolecciones
 umbrales/baselines
 eventos/alarmas/alertas
 vistas/mapas
 usuarios
 reportes
NSM
Tareas de OA&M

55.  costo de adquisición de herramientas
 costo de capacitación del personal
 personal especializado
 rotación del personal
NSM con Recursos Propios

56. Tercerización del NSM para implementación,
mantenimiento, operación, soporte y/o consultoría
 mejora el costo/beneficio
 mayor know-how
 recursos compartidos
 recursos redundantes
 ¿independiente de otros SPs?
NSM Service Providers

57. ¡Muchas gracias!
Ing. Marcelo Utard
Socio Gerente - U&R Consultores
mutard@uyr.com.ar
Ing. Nicolás Matsunaga
Gerente de Tecnología - U&R Consultores
nmatsunaga@uyr.com.ar