Pandora: Documentation es: Anexo Plugins Considerations

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

1 Consideraciones en el desarrollo de plugins

1.1 Introducción

Los plugins permiten a Pandora obtener información que requiere un procesamiento complejo o que requiere el uso de sistemas o APIs complejas. Ejemplos de plugins pueden ser la monitorización de bases de datos Oracle que requiere un complejo proceso para la monitorización y además ciertas tareas de auto descubrimiento, otro ejemplo podría ser un plugin de parseo de HTML simple, pero que requiera algo que no puede hacer Goliat.

1.2 Diferencias en la implementación y rendimiento

Pandora ofrece dos posibilidades a la hora de ejecutar plugins: ejecución en el agente o en el servidor. Los plugin de servidor realizan ejecuciones independientes para recoger cada pieza de información. La ejecución de plugin de servidor es muy costosa por lo que sólo es viable para plugins que no sean pesados, es decir, que no requieran varias consultas para obtener una única pieza de información. Un plugin de servidor podría ser un plugin de parseo HTML específico que no requiere muchas consultas y por lo tanto no cargará mucho el servidor.

Los plugin de agente permiten obtener varios módulos de una vez y por ello son mucho más flexibles que los plugins de servidor. Son ideales para plugins que requieran varias consultas para obtener una pieza de información ya que permiten más flexibilidad al programador ya que se pueden devolver varios módulos a la vez.

1.3 Tareas de reconocimiento

Para realizar tareas de reconocimiento en plugins que así lo requieran tenemos de nuevo dos posibilidades.

La primera consiste en usar el servidor Recon Task del servidor de Pandora. Para ello será necesario crear el código ad-hoc para la tecnología o situación concreta. De nuevo las Recon Task cargar el servidor de Pandora por lo que si para realizar la tarea de reconocimiento son necesarias muchas peticiones de datos esta opción deberá ser descartada.

Como alternativa es posible crear una tarea de recon usando un plugin de agente. Normalmente los plugins de agente devuelve unos módulos que se adjuntan al XML que envía el agente al servidor de Pandora. Ahora bien, al instalar el agente el una máquina con es se instala Tentacle lo que permite enviar XML al servidor de Pandora. Para realizar una recon task desde un plugin de agente es posible aprovechar esto y, además de añadir los módulos al agente como hace un plugin normal, dotar a nuestro plugin de la capacidad de enviar XMLs a Pandora con la información de otros agentes actualizada como lo haría una recon task.

La idea es que el plugin además de crear los módulos normales, recolecte la información, monte y envíe los XML simulando otros agentes instalados si fuera necesario.

La razón para realizar un plugin que envíe datos por XML y además realice tareas de reconocimiento es para poder distribuir la carga de la monitorización en distintas máquinas y no centralizarla en el servidor.

1.4 ¿Plugin de servidor o plugin de agente?

Se usará un plugin de servidor cuando:

  • La carga de cada ejecución sea poca, por ejemplo consultas simples.
  • La Recon Task no requierá mucho proceso de datos
  • Los intervalos de ejecución de la Recon Task sean grandes, por ejemplo una vez a la semana.

Se usará un plugin de agente cuando:

  • La colecta de información requiera de mucho proceso o muchas consultas.
  • La Recon Task asociada requiera una alta carga de proceso o de muchas consultas.
  • Los intervales de ejecución de la Recon Task están cerca de los intervalos de ejecución típicos para agentes, por ejemplo cada 5 minutos.

1.5 Estandarización en el desarrollo

Con el fin de que todos los plugins sean lo más estandar posible y que dispongan de características similares hay que tener en cuenta los siguientes aspectos.

1.5.1 Versionado de plugins y extensiones

En Pandora FMS seguimos un sistema de versiones para los plugin que tiene el siguiente formato:

v1r1

Siendo:

  • vX: versión del plugin, el paso de una versión a otra se produce cuando se añade una nueva funcionalidad importante o se corrige un error que impide el correcto funcionamiento del plugin. La primera versión es la v1.
  • rY: revisión del plugin, el paso de una revisión a otra se produce cuando se arregla algún bug o se implementa una feature menor. La primera revisión es la r1.

Siempre que se pase a una nueva versión se comenzará por la primera revisión, es decir, si tenemos un plugin en la versión v1r5 y debe aumentar el número de versión entonces tendremos v2r1.

1.5.2 Usage y versión del plugin

Todos los plugins deberán responder ante una llamada sin parámetros, o bien con una opción tipo -h o --help, mostrando el comando para su ejecución y los diferentes parámetros del mismo, además será necesario mostrar la versión del plugin. Por ejemplo:

$ ./myplugin

myplugin version: v1r1

Usage myplugin <param1> <param2> <param3>

	param1: este parametro es una cosa
	param2: este parametro es otra cosa


Volver a Indice de Documentacion Pandora FMS