# TensorFlow # Introducción Este plugin es una implementación de detección de anomalías utilizando un autoencoder simple con TensorFlow. Un autoencoder es un tipo de red neuronal que aprende a codificar y decodificar datos. En este caso, el autoencoder se utiliza para reconstruir datos y calcular el error de reconstrucción. La idea es que si el autoencoder no puede reconstruir con precisión un dato nuevo, podría considerarse una anomalía. El plugin recoge datos históricos de los módulos de un agente seleccionado y evalúa si el ultimo dato es anómalo comparándolo con su histórico de datos. [](https://pandorafms.com/guides/public/uploads/images/gallery/2023-08/image-1690970258648.png) # Funcionamiento de la detección de anomalías **Modelo** El modelo utilizado es un Autoencoder, una red neuronal especializada en aprendizaje no supervisado. Su propósito principal es reducir la dimensionalidad de los datos y luego reconstruirlos. Se compone de un codificador que comprime la entrada en un espacio latente de menor dimensión y un decodificador que intenta reconstruir la entrada original. El entrenamiento implica alimentar los mismos datos a la entrada y salida del modelo, optimizando la función de pérdida que mide el error de reconstrucción. **Recolección de datos** Los datos históricos de módulos se recolectan desde la base de datos, indicando la fecha a partir de la que se buscarán los datos con el parémetro --time\_data, y el intervalo de datos con el parámetro --time\_interval. Se puede indicar un número mínimo de datos con --level\_data. **Evaluación de los datos** La evaluación de anomalías se basa en el cálculo del error de reconstrucción entre el dato original y su versión reconstruida por el modelo Autoencoder. Primero, se preparan los datos de entrenamiento y prueba, donde se utiliza la secuencia de datos hasta el penúltimo valor para entrenar el modelo y el último valor se considera el dato que se evaluará para detectar anomalías. Una vez entrenado el modelo, se realiza una predicción en el último valor de prueba para obtener su versión reconstruida . A continuación, se calcula el error de reconstrucción como la media del valor absoluto de la diferencia entre el dato original y su versión reconstruida. Además, se calcula la media y la desviación estándar de los errores de reconstrucción de los datos de entrenamiento. Ajustando un umbral basado en la desviación estándar (multiplicada por un factor), se determina si el último valor es una anomalía o no. Si el error de reconstrucción es mayor que el umbral, se considera una anomalía. De lo contrario, no se consideraría anomalía. Este enfoque de evaluación de anomalías permite identificar valores atípicos en la secuencia de datos, ya que el modelo Autoencoder aprende a representar patrones normales en el espacio latente y encuentra dificultades en reconstruir datos anómalos, generando una discrepancia significativa entre la entrada original y la versión reconstruida. # Matriz de compatibilidad
**Sistemas donde se ha probado** | CentOS 7, Fedora, rocky linux |
**Sistemas donde debería funcionar** | Cualquier sistema linux |
--agent\_name | Nombre del agente del que se pretende monitorizar los módulos. (Obligatorio) |
--target\_agent | Crea un agente nuevo, que contendrá los módulos generados por el plugin, si no se usa estos módulos se generaran en el agente indicado con --agent\_name. |
--time_data | Periodo de tiempo a monitorizar en segundos. Por defecto : 604800 ( una semana, opcional) |
--time_interval | Intervalo de datos para el periodo de tiempo. Por defecto : 60 (opcional) |
--level_data | Mínimo de nivel de datos históricos necesario en el módulo para monitorizar anomalías. Por defecto 50 |
--threads | Número de hilos a usar en la creación de módulos. Por defecto 1 |
--modules_list | Lista de nombres de módulos a monitorizar (opcional), la sintaxis es la siguiente :
'["Memory_Used","Cswap"]'
Si no se usa este parámetro se monitorizará todos los módulos del agente seleccionado. |
--dbhost | Host de la base de datos. Por defecto "127.0.0.1" |
--dbname | Nombre de la base de datos. Por defecto "pandora" |
--dbuser | Usuario de la base de datos. Por defecto "pandora" |
--dbpass | Contraseña de la base de datos. Por defecto "pandora" |
--dbport | Puerto de la base de datos. Por defecto 3306 |
--transfer\_mode | Modo de transferencia, local o tentacle. Por defecto será local. (opcional) |
--tentacle\_port | Puerto de tentacle. Por defecto 41121 (opcional) |
--tentacle\_address | Ip del servidor tentacle al que mandar los datos (opcional) |
--tentacle\_client | Ruta del cliente de tentacle. Por defecto "tentacle\_client" (opcional) |
--tentacle\_opts | Opciones extras de tentacle. (opcional) |
--interval | Intervalo de monitorización del agente. Por defecto 300 (opcional) |
--temporal | Ruta para ficheros temporales. Por defecto "/tmp" (opcional) |
-g,--group | Grupo de destino de Pandora FMS (opcional) |
--data\_dir | Directorio de datos de Pandora FMS. **Por defecto** es /var/spool/pandora/data\_in/ (opcional) |
Recuerda que la ruta recomendada para el uso de los plugins de servidor es: /usr/share/pandora\_server/util/plugin/
Y en parámetros del plugin introduciremos estos seguidos de la macro "\_field<N>\_", el único parámetro obligatorio es **--agent\_name**. Una vez hecho esto, daremos a "crear". Una vez hecho esto, solo queda llamarlo por lo que iremos a la vista de algún agente y crearemos un módulo de complementos: [](https://pandorafms.com/guides/public/uploads/images/gallery/2023-07/image-1689158791553.png) Le daremos un nombre y en el apartado "plugin" pondremos el que acabamos de configurar. Una vez hecho esto, damos a crear. Si el modulo se muestra con 1, quiere decir que se esta ejecutando correctamente. # Módulos generados por el plugin El plugin creará el siguiente módulo por cada módulo monitorizado.<*module\_name*>.TF.ANOMALY | Reconstruction error: < *reconstruction\_error* > / < *threshold* > | 1 si el último dato no es anómalo, 0 si lo es. |
<*target\_agent*>.<*module\_name*>.TF.ANOMALY |