Monitoreo de Infraestructura y Servicios TIC
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
 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
 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
¿Por qué medir?
 Gestión de calidad de servicio
 satisfacción de necesidades
 Gestión presupuestaria
 control de gastos e inversiones
 control de proveedores
La medición o monitoreo, sistemático y permanente,
permite hacer:
 Soporte proactivo
 Capacity planning
 Verificación de SLAs
¿Para qué medir?
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
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
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
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
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
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
“Extended enterprise”
 SLAs con usuarios internos
 SLAs con clientes
 SLAs con proveedores
¿Para qué medir?
Verificación de SLAs
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
En términos generales, es necesario medir variables o
métricas de:
 Estado
 Uso de recursos
 Performance
¿Qué medir?
Variables o Métricas
 Alcanzabilidad de un host o router
 Estado operativo de una interfaz
 Estado de un proceso
 ...
¿Qué medir?
Variables de Estado
 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
 Time
 round trip time
 response time
 transit delay
 delay jitter
 Packet loss
 ...
¿Qué medir?
Variables de Performance
 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
 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
 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
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
Clases de Funciones de Management:
 Fault/Problem Management
 Performance/Resource Mgmt
 Configuration Management
 Security Management
 Accounting/Billing Management
NSM
Funciones de Management
 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
 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
Tipos de objetos medidos/monitoreados:
 Servicios
 Nodos (Equipos, Dispositivos)
 Recursos
 Trafico
NSM
Medición / Recolección de datos
 Reachability/Availability
 Tiempo de respuesta
 Grado de utilización
 Verificación de contenidos
 SLA conformance/violation
NSM
Tipos de Mediciones
 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
 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
Rondas de muestreo
 Intervalo de muestreo
 Timeout y retries
 Problema de timeouts
NSM
Polling
Almacenamiento de datos recolectados:
 Flat files
 RDBMs
 RRDBs
 Ocupación de espacio
 Sumarización/Promediación
NSM
Recolección de datos
Probes (puntas de prueba):
 Activos
 Pasivos (sniffers/snoopers)
 Embebidos (agents)
 Dedicados/externos
 Propietarios
NSM
Probes
ICMP Echo (Ping)
 %disponibilidad de nodos e interfaces
 RTT (Round Trip Time)
 Throughput
NSM
Probes
SNMP
 snmpget, snmpset, snmpnext, snmptrap
 OIDs
 MIBs:
 MIB2
 Host, etc
 SNMPv1, SNMPv2c, SNMPv3
NSM
Probes
 TCP
 UDP
 SMTP, POP3, IMAP4
 DNS, LDAP, Radius
 DHCP
 SQL
 HTTP/HTTPS
NSM
Probes
 SNMP Master agent / MIB subagents
 RMON Agents
 Cisco Netflows
 Cisco IPSLA Agent
 Nagios Agents
 Propietary Agents
 HP, IBM, BMC, CA
NSM
Agents
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
Mecanismos/protocolos de notificación de eventos:
 snmptraps
 mails
 syslogs
NSM
Evento, Alarmas & Alertas
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
Mecanismos de alerta:
 Logs
 Mails
 Paging
 Audio: TextToSpeech, Streaming
 Llamada telefonica
 TroubleTickets
 Otras acciones (command exec)
NSM
Evento, Alarmas & Alertas
 Event Notification
 Exception Notification
 KeepAlive Notification
 Data Collection
 Polling
 Reporting
¿Cómo medir?
Metodologías
 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
 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
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
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
Sirve para:
 seguimiento de estados
 generar alertas
 coleccionar datos históricos
¿Cómo medir?
Data Collection: Polling
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
Otros problemas:
 dependencias topológicas
 ronda de polling y timeouts
 secuenciación inevitable
¿Cómo medir?
Data Collection: Polling
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
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
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
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
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
ABM (Altas, Bajas y Modificaciones) de:
 mediciones/recolecciones
 umbrales/baselines
 eventos/alarmas/alertas
 vistas/mapas
 usuarios
 reportes
NSM
Tareas de OA&M
 costo de adquisición de herramientas
 costo de capacitación del personal
 personal especializado
 rotación del personal
NSM con Recursos Propios
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
¡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

Servicio de monitoreo de infraestructura it

  • 1.
  • 2.
    Seminario “Monitoreo / medición deinfraestructura 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 identificala 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 describenlas 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 omonitoreo, sistemático y permanente, permite hacer:  Soporte proactivo  Capacity planning  Verificación de SLAs ¿Para qué medir?
  • 7.
    Para que losusuarios 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:  minimizarel 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:  evitarla 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 elcapacity 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 LevelAgreement (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”  SLAscon usuarios internos  SLAs con clientes  SLAs con proveedores ¿Para qué medir? Verificación de SLAs
  • 14.
    Medir facilita laverificació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 deun host o router  Estado operativo de una interfaz  Estado de un proceso  ... ¿Qué medir? Variables de Estado
  • 17.
     Carga deCPU  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  roundtrip time  response time  transit delay  delay jitter  Packet loss  ... ¿Qué medir? Variables de Performance
  • 19.
     Info “realtime” 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  mesade 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 paratomar 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 Funcionesde 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 aplicacionesde 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 objetosmedidos/monitoreados:  Servicios  Nodos (Equipos, Dispositivos)  Recursos  Trafico NSM Medición / Recolección de datos
  • 27.
     Reachability/Availability  Tiempode respuesta  Grado de utilización  Verificación de contenidos  SLA conformance/violation NSM Tipos de Mediciones
  • 28.
     Composición detrá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 deretardo  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 datosrecolectados:  Flat files  RDBMs  RRDBs  Ocupación de espacio  Sumarización/Promediación NSM Recolección de datos
  • 32.
    Probes (puntas deprueba):  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 Masteragent / MIB subagents  RMON Agents  Cisco Netflows  Cisco IPSLA Agent  Nagios Agents  Propietary Agents  HP, IBM, BMC, CA NSM Agents
  • 37.
    Generación de eventospor 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ónde eventos:  snmptraps  mails  syslogs NSM Evento, Alarmas & Alertas
  • 39.
    Tratamiento de loseventos:  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 deeventos  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 notificaexcepciones  “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 desdela NMS  medición de variables más relevantes  comparación con umbrales  almacenamiento de muestras ¿Cómo medir? Data Collection: Polling
  • 46.
    Sirve para:  seguimientode estados  generar alertas  coleccionar datos históricos ¿Cómo medir? Data Collection: Polling
  • 47.
    Desventajas:  Mayor consumode 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:  dependenciastopológicas  ronda de polling y timeouts  secuenciación inevitable ¿Cómo medir? Data Collection: Polling
  • 49.
    Notificación periódica dedatos 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 deprobes 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 demedició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 yel 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, Bajasy Modificaciones) de:  mediciones/recolecciones  umbrales/baselines  eventos/alarmas/alertas  vistas/mapas  usuarios  reportes NSM Tareas de OA&M
  • 55.
     costo deadquisición de herramientas  costo de capacitación del personal  personal especializado  rotación del personal NSM con Recursos Propios
  • 56.
    Tercerización del NSMpara 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. MarceloUtard Socio Gerente - U&R Consultores mutard@uyr.com.ar Ing. Nicolás Matsunaga Gerente de Tecnología - U&R Consultores nmatsunaga@uyr.com.ar