Pandora:Documentation es:Introduccion

From Pandora FMS Wiki

Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

Introducción

¿Qué es exactamente Pandora FMS?


Pandora FMS es un software de monitorización orientado a todo tipo de entornos. Generalizar "monitorización" es algo arriesgado, ya que existen cientos de herramientas, cada una adaptada a un tipo de entorno: no es lo mismo monitorizar impresoras en una pequeña oficina, que miles de interfaces de switches y tráfico de red en un centro de datos con miles de servidores.

Pandora FMS está orientado a servir en todo tipo de roles y organizaciones. Su objetivo, es ser suficientemente flexible como para gestionar y controlar toda su infraestructura, y que no le haga falta invertir tiempo ni dinero en otras herramientas.

FMS son acrónimos de "Sistema de Monitorización Flexible" (en inglés). Su propósito es ser capaz de monitorizar tanto herramientas y sistemas de última generación -complejas-, como elementos anticuados, de difícil acceso y poca compatibilidad, en la misma plataforma.


Mapared enterprise.png


Pandora FMS dispone a día de hoy agentes para todos los sistemas operativos "modernos" del mercado, esto significa: desde Windows NT4, a Windows 2008. Pasando por supuesto por todos los Unices modernos (AIX, Solaris, HPUX, BSD, Linux) en todo tipo de versiones y distribuciones.

Por supuesto, Pandora FMS se puede emplear con éxito no sólo para monitorizar sistemas, sino todo tipo de dispositivos de red, ya sea usando SNMP (versiones 1,2,3), o mediante sondas de protocolo TCP (snmp, ftp, dns, http, https, etc), ICMP o UDP.

Acerca de la documentación


Toda esta potencia y flexibilidad, tiene implícita cierta dificultad inicial. Pese a que la mayoría de la configuración es gráfica, somos conscientes de que aprender a manejar Pandora FMS es a veces complicado. Por eso hemos distribuido el manual de forma que las más de 800 páginas de documentación están repartidas en varios bloques:

  • Primera parte. Entendiendo Pandora FMS.
  • Segunda parte. Instalación y configuración.
  • Tercera parte. Monitorización con Pandora FMS.
  • Cuarta parte. Usando y gestionando Pandora FMS.
  • Quinta parte. Entornos complejos y máximo rendimiento.
  • Sexta y séptima parte. Referencias y apéndices técnicos.

Además de la documentación oficial, existe un foro de usuarios donde puedes preguntar, en inglés, español y japonés a otros usuarios. Si necesitas formación oficial, existe un programa de formación oficial por parte de las personas que desarrollan Pandora FMS.

Existen unas guías rápidas para ayudar a configurar Pandora FMS e implementar monitorizaciones simples con la herramienta. También existen guías rápidas de la instalación de agentes software tanto para Linux como para Windows.

Existen vídeos sobre partes específicas de la configuración y hay workshops periódicos programados. Puedes consultar toda esta información en nuestra web, http://pandorafms.com

La evolución del proyecto Pandora FMS


Pandora FMS nace de un desarrollo personal de su autor original, Sancho Lerena en 2003. Desde entonces ha ido evolucionando sin parar, convirtiéndose en una herramienta robusta y madura en los últimos años.

Aunque inicialmente era 100% de código abierto, con los años, surge la necesidad de ofrecer una versión orientada a grandes empresas: la versión Enterprise. Esta versión ofrece algunas características específicas para entornos que requieren procesar grandes volúmenes de información y poder trabajar con miles de dispositivos. La empresa que financia el desarrollo de Pandora FMS, y que coordina todo el trabajo de soporte es Ártica Soluciones Tecnológicas, una empresa española, fundada en 2005 por el creador de Pandora. La versión OpenSource, sin embargo, sigue evolucionando y siendo plenamente operativa y funcional para el uso en producción, y de hecho, la mayoría de la gente que no necesita un soporte profesional o dispone de personal de sobra, utiliza la versión OpenSource.


Roadmap 2014-44.png

A día de hoy, Pandora FMS, se puede encontrar entre los primeros puestos de Sourceforge, tiene miles de descargas y usuarios satisfechos en todo el mundo. Puedes encontrar más información sobre la evolución y el roadmap del proyecto en http://pandorafms.com

Un vistazo a las funcionalidades de Pandora FMS


Explanation scheme.png


  • Auto descubrimiento. En local, los plugins "por defecto" de los agentes de Pandora permiten detectar los discos duros, las particiones o las bases de datos en un servidor de base de datos, entre otras muchas cosas.
  • Auto exploración. En remoto, y usando la red, puede detectar sistemas activos, catalogarlos según su sistema operativo, y dado un perfil empezar a monitorizarlos. Incluso puede detectar la topología de la red y "pintar" un esquema de red basado en su enrutamiento.
  • Monitorizar. Los agentes de Pandora FMS son de los más poderosos del mercado. Pueden obtener información desde la ejecución de un comando, hasta la llamada a más bajo nivel de la API de Windows: eventos, logs, datos numéricos, estados de un proceso, consumo de memoria o de CPU. Pandora dispone de una biblioteca de monitores por defecto, pero lo importante de Pandora FMS es lo fácil que es añadir y crear nuevos monitores.
  • Controlar. Los propios agentes pueden levantar servicios, borrar ficheros temporales o ejecutar procesos. También puede hacerlo de la consola, ejecutando remotamente tareas como parar o arrancar servicios. Incluso puede programar tareas para su ejecución periódica. Además, puede usar Pandora FMS para acceder remotamente a máquinas windows (vía VNC) o a sistemas de red o Unix mediante Telnet o SSH, todo desde un interfaz web.
  • Alertar y notificar. Tan importante como detectar un fallo es avisar de él. Con Pandora, tiene una variedad casi infinita de formas y formatos de notificación, incluyendo: escalados, correlación de alertas y protección de cascada de eventos.
  • Visualizar y analizar. Monitorizar no sólo es recibir un trap o visualizar un servicio caído, es presentar informes de tendencias, gráficas resumen de datos correlados durante meses, generar portales de usuarios, delegar informes a terceros o definir sus propias gráficas y tablas. Pandora incorpora todo ello desde la interfaz WEB.
  • Inventariar. Al contrario que otras soluciones donde el concepto de CMDB es la base, para Pandora es opcional. El inventario es flexible y dinámico (se puede auto-descubrir, hacer remotamente, etc). Puede notificar de cambios (p.e: software des-instalado en un equipo) o simplemente ser usado para elaborar listados.

Introducción a la monitorización


Todos los manuales técnicos de software empiezan a hablar rápidamente de configuración, ficheros de texto, bases de datos, protocolos, etc. Muchas veces aprendemos a configurar una herramienta a bajos niveles pero no somos conscientes de para qué sirve esa herramienta, o qué puede hacer y en que contextos. El propósito de este apartado es explicar de forma breve pero sistemática la "teoría" que hay detrás de la monitorización, con una aproximación independiente del software que se vaya a usar para monitorizar.

Tipos de monitorización


Cuando hablamos de "saber como está" un determinado elemento, sea este un servidor, una base de datos, un elemento de red o una nevera, podemos plantearnos varias cuestiones.

  1. ¿Cómo obtenemos la información?, ¿tenemos algo ahí que se encarga de ello, o tenemos que "ir y venir" preguntando?.
  2. ¿Nos interesa estar preguntando constantemente o esperar a que "ocurra algo" ?
  3. ¿Qué tipo de información me da?. ¿Es algo que pueda dibujar en una gráfica y ver su progresión?.

Estas preguntas responden a tres cuestiones clave que condicionan toda la forma de plantear nuestro "modelo" de monitorización.

La primera pregunta responde a si nosotros vamos a utilizar una monitorización basada en agentes, que se ejecutan dentro del dispositivo que vamos a controlar o por el contrario todo se hace de forma externa, utilizando una conexión de red. Existen sistemas de monitorización que funcionan de una u otra forma, y dispositivos que sólo se pueden monitorizar de una forma y no de la otra. Pandora FMS soporta todos los modelos.

La segunda pregunta responde a si la monitorización es síncrona (cada X segundos se pregunta, independientemente que la información haya cambiado o no) o bien asíncrona (sólo me llega información cuando algo relevante ha ocurrido). Si utilizo monitorización síncrona con 10 millones de elementos y cada 5 minutos recojo datos, la carga será considerable, sin embargo si lo hago cada 50 minutos, será mas manejable, pero si ocurre algo puedo tardar 50 minutos en enterarme. Si utilizo monitorización asíncrona (p.e: con traps SNMP o con logs), ahorro muchos recursos, pero no podré trazar gráficas ni hacer históricos, salvo de los sucesos ocurridos. Muchas herramientas se basan sólo en uno de los modelos, a veces se conocen como herramientas de "rendimiento" o "capacity", y herramientas basadas en modelo de gestión de "eventos" y muchas veces no sirven para ambas cosas. Pandora FMS soporta ambas aproximaciones.

La tercera pregunta, hace referencia a que a veces nos interesa una cadena de texto (un evento descriptivo), a veces un número con coma flotante (para poder pintar gráficas), o simplemente un estado (caído, vivo). Poder trabajar con diferentes tipos de datos aporta más flexibilidad. Pandora FMS soporta cualquier tipo de datos.

Estos tres "paradigmas" condicionan mucho su entorno y la herramienta que debe elegir para monitorizarlo. Sea consciente de la información que necesita y piense cuál es la mejor forma de obtenerla. Planifique qué elementos de información dispone y como pretende monitorizarlos.

Monitorización remota


Cuando hablamos de monitorización remota, nos referimos a que el servidor de Pandora FMS es quien sondea (hace "polling"), de forma regular (síncronamente) a los dispositivos que desea monitorizar. Cuando hablamos de este modelo, no hacemos referencia a la monitorización "Local" o basada en agentes instalados sobre los dispositivos que deseamos observar.


Esquema-REMOTE-MODULE-EXECUTION.png


Generalmente, cuando hacemos una monitorización remota se hace para dos propósitos diferentes:

  • Comprobar que están vivos (p.e: interfaz, o sistema activo).
  • Obtener un valor numérico (p.e: medir el tráfico de red o el número de conexiones activas).

Esta monitorización cuando es síncrona, siempre se realiza en el mismo sentido: desde el servidor de monitorización hacia el elemento monitorizado.

A veces puede interesarnos lo contrario, que el dispositivo "nos avise" cuando algo ocurre. Esto es monitorización asíncrona, y en el caso de monitorización remota se habla generalmente de "traps SNMP".

La monitorización síncrona se suele realizar usando el protocolo SNMP que es el más extendido en equipamiento de red. No obstante también se puede hacer mediante WMI, un protocolo similar, pero propietario de Microsoft.

Ambos protocolos funcionan de forma parecida, básicamente un servidor "pregunta" por la red para un elemento concreto de configuración del "agente SNMP" o "Servicio WMI" que escucha en el dispositivo. Ese elemento concreto en SNMP se llama OID, y en WMI se identifica mediante una query WQL. Puede ser la memoria libre del sistema, el nº de conexiones del router o el tráfico en una interfaz determinada.

Si su monitorización está orientada sobre todo a entornos de red, necesita conocer SNMP en detalle y será la parte que más le interese usar de su herramienta de monitorización. La monitorización asíncrona mediante traps SNMP también es vital. Necesitará además de una herramienta de monitorización, un explorador 'externo' de dispositivos SNMP, acceso a las colecciones de MIBS de los fabricantes de sus dispositivos de red (que son como bibliotecas de OID's) y por supuesto, mucha paciencia para investigar, ya que cada dispositivo tiene generalmente su propia colección de OID's y sólo le interesarán algunos elementos dentro de los miles que dispone cada dispositivo.

Si su monitorización está orientada a servidores windows y no le interesa instalar agentes en las máquinas, la monitorización remota WMI es también muy apropiada y potente. La interfaz WMI es aún más potente (y mejor organizada que la de SNMP), mediante WMI podrá obtener prácticamente cualquier dato, estado o evento de sus servidores Windows.

Los sistemas Unix y Windows también pueden ser sondeados mediante SNMP, pero la información que devuelven es escasa, además necesitará activar y configurar los agentes SNMP del sistema operativo, cosa a que veces es mucho más complicado que simplemente instalar un agente de monitorización de Pandora FMS.

Finalmente siempre podrá monitorizar elementos de red mediante el uso de pruebas TCP o ICMP. El ICMP se usa básicamente para dos cosas:

  • Saber si un sistema responde (ping).
  • Saber el tiempo de latencia (respuesta) de ese dispositivo (en milisegundos).

Mediante las pruebas TCP, se puede probar por ejemplo que un servidor WEB responde adecuadamente, o que un servidor de correo (SMTP) envía bien los correos. Este tipo de pruebas no busca simplemente que el servicio "abra el puerto" sino que responda como debe, es decir, el comando de enviar correo reciba un OK o la respuesta del servidor WEB sea "200 OK" (respuesta válida en protocolo HTTP).

Existe una serie de plugins "por defecto" para chequeos TCP, pero puede implementarse fácilmente sus propios chequeos, adaptando sus propios scripts o desarrollando nuevos. La integración con Pandora FMS no requiere "API", estructuras complejas o librerías propietarias.

La monitorización transaccional web, aunque es monitorización remota, recibe un capítulo específico para ello por su importancia.

Monitorización local (con agentes)


Cuando se habla de sistemas y aplicaciones, sin duda la mejor forma de obtener información es directamente, sobre el sistema. Esto es, ejecutando comandos, o "preguntando" a las fuentes de datos del sistema, desde la propia maquina que se quiere monitorizar. Esto supone que hay que ejecutar algún tipo de comando, script o hacer alguna forma de consulta sobre el sistema o la aplicación. Para ello usamos el agente de monitorización de Pandora, que es un software específico, para hacer esas pequeñas tareas de monitorización.

Los agentes sólo se pueden instalar sobre sistemas operativos Unix y Windows. No se puede instalar un agente sobre un dispositivo cisco, p.e. En la nomenclatura que usa Pandora FMS, se habla de agente para referirse a la "entidad" contenedora de información, por ello hablamos de "agente software" como a la pieza de software que se instala en un sistema para extraer información y reportarla al servidor de Pandora FMS. El agente software se ejecuta constantemente sobre el sistema (como servicio) y reporta información cada X tiempo.


Esquema-AGENT-MODULE-EXECUTION.png


Los agentes, además de obtener información mediante comandos, permiten hacer más cosas, como por ejemplo, obtener información de inventario. También se pueden configurar para que "actúen" en caso de problema o fallo, interactuando automáticamente con el sistema, borrando algún fichero temporal o ejecutando algún comando.

Para obtener información precisa y específica de lo que nos interesa muchas veces tendremos que consultar la documentación de la aplicación que queremos monitorizar, ya que aunque dispongamos de monitores "genéricos", puede que lo que buscamos no sea tan trivial.

En Windows existe una variedad casi infinita de acceso a la información: WMI, Perfcounters, Eventlog, logs del sistema, registro, comandos, scripts de powershell, API de NT, etc. De hecho la arquitectura de Microsoft es de las más fáciles, potentes y mejor documentadas a la hora de obtener información del sistema. En sistemas Unix/Linux la capacidad del agente software para ejecutar cualquier comando nos permite aprovechar toda la potencia de la shell.

Procedimientos en la monitorización


¿Ha pensado para que quiere realmente monitorizar?, quiero decir, una vez que tenga datos sobre sus servidores: cuándo se caen o qué consumo tienen, ¿ha pensado qué hará?. Quizás si primero se plantea qué es lo crítico se ahorre un montón de tiempo "cacharreando" e investigando en cosas que luego no serán útiles en su día a día.


Ciclo monitorizacion.png


Dedique cinco minutos a responderse a alguna preguntas. ¿En su caso, cuál cree que describe mejor su necesidad de monitorización ?.

  • Sirve para evitar pérdidas -> Disponibilidad.
  • Analizar degradaciones -> Rendimiento.
  • Evaluar crecimientos -> Planificación de capacidad.

En cada uno de los casos tendrá que enfocarse en unos aspectos concretos.

Disponibilidad, el primer caso. Le interesa sobre todo la monitorización basada en eventos, y probablemente con monitorización remota le sea suficiente, es más rápida de desplegar y podrá tener resultados relativamente breves. Los informes de SLA son los que busca.

Rendimiento, el segundo caso. Lo suyo son las gráficas y los números, puede obtener esa información tanto con agentes como remotamente, pero probablemente necesite agentes para obtener información pormenorizada de sus sistemas. Los informes agrupados y las gráficas combinadas son lo que más le interesa.

Planificación de capacidad, el tercer caso. Mucho mas especializado, necesita obtener datos, como en el segundo caso, pero jugar con ellos, con monitores de tipo predictivo e informes de proyección, muy específicos. Establecer alertas tempranas le será de mucha ayuda, y necesitará conocer bien los conceptos de estados WARNING y CRITICAL, además de elaborar una serie de políticas de gestión de eventos que le permita prever el problema antes de que suceda, sin duda el caso más complejo e interesante.

Ahora que ya sabe que modelo va a seguir, ¿ ya se ha planteado qué hará cuando el sistema le diga que X servicio se ha caído?, o peor aún, ¿ qué sucederá cuando la capacidad de sus servidores llegue al límite el próximo viernes ?.

Necesita pensar en procedimientos de actuación.

Procedimientos de actuación


Llamamos procedimientos de actuación a algo que no puede hacer con ninguna herramienta (por ahora), que es básicamente pensar y planificar cómo va a notificar las cosas que ocurran. Para ello habrá que tener en cuenta varios factores:

  • Criticidad del suceso: ser capaz de discriminar algo habitual, de algo poco frecuente o algo crítico.
  • Forma de notificar: email, sms o porqué no, un calambrazo al operador para que no se duerma (nosotros aún no lo hemos implementado, pero no sería difícil...).
  • Escalado: consiste básicamente en que primero notifica a alguien, si no se arregla, notifica además a otra persona, y si aún no se ha solucionado, llama a un tercero, que probablemente sea alguien a quien los anteriores tengan algo de respeto.

Lo ideal sería que antes de configurar nada, tuviera en la cabeza estos conceptos. Mejor aún, ármese de paciencia y una herramienta de diseño visual (visio, opendraw...) y dibuje sus elementos críticos, y pinte con flechas como se obtiene la información y a quién se notificará o que se hará con esa información.


Scalation example.png


Si primero se centra en lo mas crítico, ya tiene el punto de partida sobre qué es lo más importante para su organización. Una vez que sepa qué es lo más crítico, ya descubrirá el cómo monitorizarlo, y mientras tanto pensará en el quién es el responsable de los problemas en esos sistemas y cómo notificarlo.

Modelos de supervisión


Por supervisión entendemos el hecho de que un sistema de monitorización esta diseñado para reportar información a un sistema automático, pero que, de hecho, es vigilado por un ser humano de forma directa o indirecta. Esta persona, a menudo recibe el nombre de "operador", que es la persona que "mira" la pantalla o recibe los eventos de cualquier otra manera, que puede ser: mediante un dispositivo "smartphone" o similar, o mediante correos o registros log recogidos con otra herramienta. El sistema no importa, lo importante es el concepto de que hay alguien "Pendiente" del sistema.


Notice ways.png


Por otro lado existe una serie de personas, que generalmente podemos denominar "administradores de sistemas" o "personal de infraestructura" que son los que, cuando algo sucede, reciben una llamada del operador "oye, tenemos un problema", o directamente una notificación automática por parte del sistema avisándoles de algo, es decir, un SMS, o un correo, en la mayoría de los casos.

Aquí ya vemos una gran diferencia:

  • El modelo de supervisión directa implica que hay una persona, o varias, mirando constantemente el sistema, y si sucede algo crítico lo verá en el acto. Probablemente puede ver pequeños cambios, no críticos, y tener mucha más flexibilidad. No es necesario definir "notificaciones" (alertas en Pandora) para cada caso posible, basta con mirar los eventos (una especie de visor de sucesos, sobre cambios de estado), para hacerse una idea de "qué se cuece" en el sistema en ese momento. Se pueden definir muchas pantallas, y además definir alertas para apoyar esa supervisión. En grandes entornos se usa este modelo, ya que por mucho que definamos una política de alertas, no se puede nunca garantizar una supervisión "autónoma y perfecta".
  • El modelo de supervisión indirecta, implica que no hay una persona permanentemente mirando la pantalla, así pues es necesario definir de antemano que notificaciones automáticas (alertas) va a tener el sistema, ya que los eventos, las gráficas y los mapas no los mirará nadie. Este sistema esta bien cuando tenemos pocos dispositivos, o tenemos muy bien identificado lo que es crítico y como abordar el problema (solución y notificación).

Para trabajar en equipo, cuando intervienen operadores, administradores y personal de tercer nivel son muy útiles las herramientas de las que dispone Pandora FMS como: marcado de eventos, creación de incidencias, escalado de notificaciones, mensajería interna, tablón de avisos y chat entre usuarios de Pandora FMS.

¿ Y ahora qué ?


Los siguientes capítulos ya son para hablar exclusivamente de Pandora FMS. Hasta ahora hemos hablado de cosas generales que es importante que sepa antes de seguir explorando Pandora FMS. Probablemente ya sepa muchas cosas, y haya probado otros programas de monitorización, quizás haya oído que tal o cual aplicación se monitoriza de una determinada manera en todas partes y que su forma es la mejor.

Puede, pero en nuestra experiencia, cada cliente hace las cosas de una manera, y por mucho que sepamos de monitorización, no creemos que sepamos más de como tiene montada su infraestructura que usted. Monitorizar cosas sencillas es fácil, lo difícil es adaptar la monitorización a su negocio sin adaptar su negocio a la monitorización, eso no es trivial. Tiene más de 800 páginas por delante para descubrir la mejor manera de monitorizar su organización con Pandora FMS, todo un reto.


Volver a Indice de Documentacion Pandora FMS