OV201 : Opsview System Administration

Miquel Ruiz Martin

Introducción

Introducción

4

• Quien soy yo?

• Quienes sois?

– Nombre

– A qué os dedicáis

– Experiencia previa con Opsview?

– En qué estáis más interesados?

• Qué vamos a aprender?

Objetivo del curso

5

• Entender conceptos de monitorización

• Entender la arquitectura Opsview

• Realizar tareas comunes de configuración y administración

Agenda

• What is Opsview

• Architecture & Installation

• Service checks

• Plugins

• Active checks

• Passive checks

• State types

• Acknowledgement

• Determining status and reachability using parent/child relationships

• Notifications

6

• Comments

• Downtimes

• Keywords

• Contacts

• Host Templates

• Agents

• Dashboard

Documentación

Recursos http://docs.opsview.com

8

Qué es Opsview

Qué es Opsview?

• Opsview es una herramienta open source de monitorización de red, servidores y aplicaciones.

• Opsview ofrece una interfaz web al usuario que permite acceder a las vistas de monitorización y a la configuración del sistema.

Arquitectura

Master

• Ofrece:

– La interfaz web de Opsview

– El motor Nagios

– La aplicación Nagvis

– La base de datos

– Los gráficos de rendimiento

12

Servidor Master – Arquitectura no distribuida

13

Arquitectura de Opsview

15

Conceptos básicos de monitorización

Servicios

• Los servicios se comprueban de forma regular

• Deben estar asociados a un host

• Si un servicio falla, Opsview comprobará si el host también falla

26

Hosts

• Hosts = contenedores de varios servicios

• Los hosts solo se comprueban cuando se requiere – Cached Service Checks

• Si la comprobación de un host ha fallado

entonces comprobará si los padres del host han fallado (disponibilidad de la red)

• Si la comprobación de un host ha fallado entonces se generarán únicamente notificaciones sobre él, no sobre sus servicios

27

Tipos de Service Checks

• Checks activos – Se ejecutan de forma

regular

– Son iniciados por Nagios

• Checks pasivos – Son iniciados por una

aplicación externa. Ej.: SNMP Traps

– El estado de los checks pasivos tiene que ser cambiado manualmente después de un fallo

28

Estados de servicios y de hosts

29

Tipos de estado

• objetivo: reducir el número de falsos positivos, ej: un puerto de switch que vuelve a estado normal después de un fallo momentaneo

• Soft = inicio probable de un fallo

30

Tipos de estado • Hard – un problema real • El estado de un servicio

pasará a HARD si: – Se ha alcanzado el valor

de max_check_attempts – Una transición de un

estado Hard a otro estado Hard

– Si el host está en estado DOWN o bien UNREACHABLE

31

Intervalos de check

32

Relaciones padres-hijos

• Usando relaciones padres-hijos, el motor de monitorización puede determinar si un host está fallando o bien es inalcanzable

• Para que este mecanismo funcione, se requiere indicar como los hosts están relacionados entre sí desde el punto de vista del master

33

KBS BANK Network

34

KBS BANK visto desde Opsview

35

Determinar el alcance por red

36

Determinar el alcance por red 2

37

Que son los Plugins

• Todos los checks activos usan un plugin

• Disponen de la lógica para determinar si algo está funcionando o no

• Toman parámetros para establecer los diferentes umbrales

• Un mismo plugin puede ser usado en diferentes servicios

• Todos los plugins devuelven un estado, información y (opcionalmente) datos de rendimiento

38

Notificaciones

• Se generan: – Cuando hay algún cambio en el

estado Hard de un servicio o host

– Cuando un host o servicio se mantiene en un estado que no sea OK

– Cuando un servicio se recupera

– Cuando se atiende un problema

41

Notificaciones (2) • Se generan notificaciones hasta que se

atiende la alerta o se pone un downtime manual

• Las notificaciones pueden mandar emails, SMS, … También son plugins

• El filtrado de notificaciones pasa por varios niveles: – Las opciones de notificaciones del host o

servicio – El periodo de tiempo de las notificaciones – Las opciones contenidas en el perfil de

notificación de cada usuario

• El paso a estado OK también se notifica

42

Notificaciones: Limitaciones

• Se pueden lanzar desde el master y/o desde los esclavos.

• Limitación: Las notificaciones de un esclavo pueden no contener toda la información que tiene el master, dado que la topología padre/hijo puede ser diferente.

• Limitación: Las notificaciones desde los esclavos no se almacenan de forma centralizada.

43

Reconocer/Atender una alerta

• Los reconocimientos son una forma de detener las notificaciones

• Ideal para caídas no planificadas

• Desaparecen ante un cambio de estado

• Existe una pantalla para hacer reconocimientos masivos

44

45

This is the flow if sticky acknowledgements are applied:

= acknowledgement applied

Sticky & Non Sticky Alerts

Reconocido vs. no reconocido

• Un servicio está reconocido si: – El servicio está OK

– El servicio está en tiempo de downtime o ha sido reconocido

– El host está caído (DOWN o UNREACHABLE)

• Un host está reconocido si: – El host está UP

– El host está en downtime o reconocido

46

Reconocido vs. no reconocido

• Los no reconocidos son problemas nuevos

– Empezar el diagnóstico

47

Qué aporta Opsview?

• Saber lo que pasa sobre los sistemas

• Poder detectar los problemas por adelantado

• Un healthcheck, ejecutándose continuamente

48

Opsview no es

• Una herramienta para corregir automáticamente los problemas

• No sustituye a la inteligencia del personal técnico

49

Interfaz de configuración

Visualización por listas

• Con opción de búsqueda

• Permite eliminar, duplicar y editar

• Menú contextual y otra información relevante

52

Vista de edición

• Las pantallas de edición también se usan para crear nuevos objetos y objetos duplicados

• Usa pestañas para reducir la complejidad de las pantallas

• Ayuda contextual para la mayoría de los campos

53

Hosts

• Estos son todos los hosts configurados en Opsview • Lo primero, rellenar la información acerca del

host. • Después, seleccionar alguna plantilla, y todos los

checks adicionales que se requieran. • Se pueden consultar de forma automatizada las

interfaces del host vía SNMP (extremadamente útil para dispositivos de networking)

• Atributos de Host – nueva funcionalidad para guardar metadatos (discos, interfaces de red, particiones, …)

54

Service checks

• Todos los servicios que se quieran comprobar deberán tener un service check

• Agrupados para encontrarlos de forma fácil

• Dependencias:

– Sólo son posibles dependencias en un mismo host

– Caso de uso inicial: fallo del agente de monitorización

• Reportar cada fallo: sirve para checks pasivos

55

Otros tipos de service check

• SNMP Polling – Un tipo de check activo basado en variables SNMP específicas

• Check pasivo – un servicio vacio

• SNMP Traps - un sistema basado en reglas de alertas en caso de traps

56

Plantillas de hosts (templates)

• Cada plantilla del host tiene una lista de service checks asociados

• A un mismo host se le pueden aplicar múltiples plantillas

• El orden en que se añaden es importante!! • Primero los monitores

específicos del host • Luego, según el orden de las

plantillas del host • En el menú contextual de cada host

se pueden consultar los service checks que se le están aplicando

57

Excepciones

• Se pueden cambiar los parámetros indicados en el plugin

– Ejemplo de uso: Load average, cuando algunos hosts tienen más carga

• Se puede cambiar el periodo de tiempo durante el cual desea que cambien los parámetros

– Ejemplo de uso: Mientras corren los backups, un servidor tendrá un aumento de carga temporal

58

Host groups y service groups

• Clave para el control de acceso

• Cada service check pertenece únicamente a un único grupo

• Cada host pertenece únicamente a un host group

• Los host groups tienen jerarquía

• Se pueden hacer modificaciones en dicha jerarquía mediante “drag & drop”

• Los host groups tienen algunas restricciones

59

Keywords – palabras claves • Una palabra clave es una

selección de servicios

• Se puede editar la lista de hosts y servicios a partir de la página de keyword

• Se puede habilitar una ventana de visualización y elegir su estilo

60

Contactos

• Un contacto es un usuario de Opsview

• Puede tener diferentes esquemas de autenticación. Actualmente sólo soporta LDAP y autenticación interna

• Autorización basada en roles

• Cada usuario tiene un perfil de notificación para determinar qué alertas recibe

61

Niveles de acceso • VIEWALL, VIEWSOME - capacidad para ver

estados

• NOTIFYSOME – capacidad para recibir alertas

• ACTIONALL, ACTIONSOME – capacidad para realizar reconocimientos, etc

• DOWNTIMEALL, DOWNTIMESOME – capacidad para definir downtimes

• CONFIGUREHOSTS, CONFIGUREKEYWORD, CONFIGUREVIEW – Capacidad para visualizar configuraciones

• CONFIGURESAVE – guardar configuración

• RELOAD – capacidad para recargar Opsview

• VIEWPORTACCESS – capacidad para visualizar viewport

• RRDGRAPHS – capacidad para ver gráficos

• ADMINACCESS - todo! 62

Roles por defecto

63

Role View Notification Action Admin

Admin Todos Algunos Todos Sí

View all, change

some

Todos Algunos Algunos No

View some, change

some

Algunos Algunos Algunos No

View all, change

none

Todos Algunos Ninguno No

View some, change

none

Algunos Algunos Ninguno No

Que significa “algunos”? Parte 1

• Lista de palabras claves

Y

• La intersección de host groups y service groups

64

Que significa “algunos”? Parte 1

65

Que significa “algunos”? Parte 2 • La lista total de servicios es la unión de la

intersección host group y grupo de servicio más la lista de servicios para las palabras clave.

• Todos los hosts adecuados son añadidos también

• Las duplicaciones no representan problema alguno

• La intersección host group y grupo de servicio es interesante para equipos

• La selección de las palabras claves son interesantes para administradores o usuarios finales

• A partir de Opsview 3.11.0: Los objetos de tipo acceso se definen al nivel de rol

66

Servidores de monitorización

• Lista todos los servidores de monitorización en el sistema Opsview

• El enlace al estado del esclavo muestra el estado de los esclavos, basándose en checks generados automáticamente

• Permite arrastrar y soltar host entre los servidores de monitorización

67

Host check command

• Define el check que el host usa para determinar si está caído

• Generalmente usa un ping, pero se puede comprobar cualquier otra cosa

• También son plugins

68

Métodos de notificación

• Se pueden definir diferentes métodos: Email, SMS, …

• Puede definir si la notificación será invocada por el master o por el esclavo que la inicia

• Sorpresa!! También son plugins.

69

Punto de control

• Cuántos tipos de plugins utiliza Nagios y para qué se utilizan?

• Puede haber contactos de sólo lectura?

• Un hostgroup puede contener otros hostgroups?

Agentes

Por qué agentes?

• Para monitorizar recursos locales sobre máquinas remotas

– Ej: CPU, uso de disco, …

• La información no se hace pública

• Se requiere un agente para recuperar esa información

• Opsview usa 3 tecnologías de agentes:

– SNMP

– SSH

– NRPE

72

Agentes

• SNMP : Simple Network Management Protocol

• Más en el curso OV203.....

73

check_by_ssh • check_by_ssh ejecuta plugins en

remoto

• Necesita acceder vía SSH entre el servidor que monitoriza y el host remoto

• Provee de autenticación y encriptación

• Menos administración, pero más acceso libre desde Opsview

74

NRPE: Nagios Remote Plugin Executor • NRPE se ejecuta en máquinas

monitorizadas

• Escucha a través del puerto 5666

• El servidor Opsview ejecuta check_nrpe para conectar

• La máquina ejecuta el plugin localmente y devuelve el resultado

• No hay autenticación, pero el tráfico está cifrado

• Se puede filtrar a nivel IP

• Suele ser necesario abrir firewalls

• No requiere acceso a la shell

75

Monitorización de servidores Unix/Linux

Cómo usar NRPE en UNIX • Instale el agente NRPE

– Ya empaquetado para muchas distribuciones de Linux/UNIX

• /usr/local/nagios/etc/nrpe.cfg lista qué plugins pueden ser ejecutados – command[check_disk]=/usr/local/nag

ios/libexec/check_disk $ARG1$

• Para consultar un host por NRPE se debe utilizar el plugin check_nrpe desde Opsview

77

Monitorización de Servidores Windows

Monitoring Windows Servers • Agente Opsview para Windows

• Basado en NSclient

• Compatible con NRPE

• Contiene funciones integradas además de la capacidad para ejecutar cualquier programa

80

Resumen

• Entender conceptos de monitorización

• Entender la arquitectura Opsview

• Realizar tareas comunes de configuración y administración

82

Evaluación del curso

• www.surveymonkey.com/s/ov201