CEM147351

Vista previa del material en texto

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY 
CAMPUS ESTADO DE MÉXICO 
H'.:f 35) 
.(Y ./fECA 
SISTEMA DE MONITOREO EXPERTO APLICADO A EQUIPOS DE CÓMPUTO 
TESIS PARA OBTENER EL GRADO DE 
MAESTRO EN CIENCIAS DE LA COMPUTACIÓN 
CON ESPECIALIDAD EN REDES 
PRESENTA 
ING. ARTURO RODOLFO CASTRO LOERA 
Asesor: Dr. RAÚL MONROY 
Asesor: M. en C. MARCO GONZÁLEZ 
Comité de Tesis: Dr. JESÚS V AZQUEZ 
M. en C. FRANCISCO CAMARGO 
Jurado: Dr. JESÚS V AZQUEZ 
M. en C. FRANCISCO CAMARGO 
Dr. RAÚL MONROY 
M. en C. MARCO GONZÁLEZ GALICIA 
Atizapan de Zaragoza, Edo. Mex., Noviembre del 2000. 
RESUMEN 
La administración de servicios de cómputo se enfoca principalmente a mantenerlos en 
operación continua. Por eso gran parte del tiempo del administrador se enfoca principalmente al 
monitoreo, o la revisión de los servicios de cómputo para garantizar su funcionamiento correcto 
la mayor parte del tiempo. Existen muchas herramientas que ayudan al administrador a realizar 
esta labor, sobre todo, cuando el administrador no está presente para solucionar un problema de 
mal funcionamiento del servicio. No existe la herramienta perfecta para un monitoreo efectivo, 
por eso en esta tesis presentamos una solución que puede ayudar a la labor de monitoreo del 
administrador. La idea es obtener la experiencia de administradores expertos en un sistema de 
cómputo dado y administrar ese conocimiento para realizar un monitoreo efectivo, tal y como lo 
haría el propio administrador. Este conocimiento puede aplicarse en otros sistemas de cómputo 
similares, ya que solo es el conocimiento lo que se está aplicando. 
5 
CONTENIDO 
1 Introducción ................................................................................................. ......... 1 O 
2 Sistemas de Monitoreo ......... ................................................................................. 14 
2.1 Herramientas de Monitoreo ...................................................................... 14 
2.2 Scripts ........................................................................................... ............ 15 
2.3 Expect. ...................................................................................................... 16 
2.3 .1 Historia de Expect. ...................................................................... 16 
2.3 .2 Qué es Expect. ............................................................................. 17 
2.3.3 Expect: Herramienta de monitoreo efectivo .............................. .18 
2.3 .4 Limitaciones de Expect. ..................................................... ......... 19 
2.4 Sistema experto como complemento de Expect.. .................................... . 19 
2.5 Conclusiones ..................................... ................................ .. ... ........... ....... 19 
3 Sistema Experto .................... ................................................................................. 20 
3 .1 Sistemas expertos ..................................................................................... 20 
3 .2 Características de un sistema experto ...................................................... 21 
3.3 Sistema de soporte de decisiones ............................................................. 22 
3 .4 Conocimiento ........................................................................................... 22 
3.4.1 Conocimiento procedural y declarativo ...................................... 22 
3.4.2 Representación del conocimiento ............................................... 23 
3.4.3 Representación en lógica ...... .... .. ..... .. ........ ... .. ....... ............. ........ 23 
3.4.4 Lógica proposicional. .... .............. .............. .. ... ............. .. .............. 24 
3.5 CLIPS ....................................................................................................... 28 
3.5.1 ¿Qué es clips? .............................................................................. 28 
3.5.2 CLIPS como complemento de expect. ........................................ 28 
3.5.3 Reglas ........... .... ........... ..................................... .......... .. ............... 29 
3.6 Conclusiones ............................................................................................ 29 
4 Sistema de Monitoreo Experto .............................................................................. 30 
4.1 Arquitectura del sistema ........................................................................... 30 
4.1.1 Base de conocimientos ................................................................ 31 
4.1.2 Módulo de soporte de decisiones ................................................ 32 
4.1.3 Módulo alimentador de la base de conocimientos ...................... 34 
4.1.4 Módulo ejecutor .......................................................................... 35 
4.1.5 Módulo de reportes ..................................................................... 38 
4.2 Mapas de conocimiento ................... ......................................................... 39 
4.3 Conclusiones ................................ ...... .................. ................ .................... 39 
5 Resultados .............................................................................. ............................... 40 
5.1 Caso 1. Servidor de Lotus Notes ............................................................ .40 
5.2 Caso 2. Servicio de correo electrónico .................................................... 47 
5.3 Conclusiones ............. ............................................................................... 51 
6 Trabajo a Futuro .................. .................................................................................. 52 
6.1 Módulo Ejecutor ....................................................................................... 53 
6.2 Base de conocimientos ............................................................................. 53 
6.3 Módulo Alimentador ................................................................................ 54 
6.4 Seguridad .................................................................................................. 55 
6.5 Conclusiones ............................................................................................ 55 
7 Conclusiones ......................................................................................................... 56 
7.1 Sistema de monitoreo experto aplicado a sistemas de cómputo .............. 56 
7 .2 Utilización de expect. ............................................................................... 57 
7.3 Utilización de un sistema experto ............................................................ 57 
7.4 Perspectivas .............................................................................................. 57 
8 Referencias y Bibliografia ..................................................................................... 58 
INDICE DE FIGURAS 
Figura 3.1 Forma general de un proceso lógico ............................................ ........... 23 
Figura 3.2 Relaciones lógicas ................................................................................... 26 
Figura 4.1 Arquitectura del sistema ........................................................................ .30 
Figura 4.2 Ejemplo de una regla ............................................................................. .32 
Figura 4.3 Ejemplo de una regla .............................................................................. 33 
Figura 4.4 Operación del módulo alimentador ........................................................ .34 
Figura 4.5 Ejemplo de un listado para ingresar reglas ............................................. 35 
Figura 4.6 Operación del módulo ejecutor.. ............................................................ .35 
Figura 4. 7 Ejemplo de una regla de la forma en como está almacenada en la base de 
conocimientos........................................................................................................... 3 8 
Figura 5.1 Gráfica del 24 de enero del 2000 ........................................................... .41 
Figura 5.2 Gráfica del 25 de enero del 2000 ............................................................ 42 
Figura 5.3 Gráfica del 26 de enero del 2000 ........................................................... .43 
Figura 5.4 Gráfica del 27 de enero del 2000 ........................................................... .44 
Figura 5.5 Gráfica del 1 de Febrero del 2000 ......................................................... .45 
Figura 5.6 Gráfica del 2 de Febrero del 2000 ......................................................... .46 
Figura 5. 7 Gráfica del 3 de Febrero del 2000 ......................................................... .46 
Figura 5.8 Gráfica del 4 de Febrero del 2000 ......................................................... .47 
Figura 5.9 Gráfica del 18 de Septiembre del 2000 .................................................. .48 
Figura 5.1 O Gráfica del 20 de Septiembre del 2000 ................................................. 49 
Figura 5.11 Gráfica del 22 de Septiembre del 2000 ................................................. 50 
Figura 6.1 Base de conocimientos ............................................................................ 53 
Figura 6.2 Reglas de la base de conocimientos ....................... ................................. 54 
ÍNDICE DE TABLAS 
Tabla 3 .1 Propiedades de satisfacibilidad ................................................................ 25 
Tabla 3.2 Fórmulas equivalentes .............................................................................. 26 
Tabla 3.3 Leyes de equivalencia .............................................................................. 27 
1 INTRODUCCIÓN 
Los sistemas de cómputo han sido desde hace algunos años puntos estratégicos para el desarrollo 
de las empresas. Con el desarrollo de Internet las empresas tienen una gran posibilidad de 
incrementar su productividad en un amplio margen de mercado. Es por esta razón que se le ha 
dado tal importancia a los equipos de cómputo ya que albergan grandes cantidades de 
información que es consultada por millares de usuarios a toda hora. La información debe estar 
disponible en cualquier momento para otorgarla a quien la necesita, por lo que es clave que los 
sistemas de cómputo estén operando en todo momento. 
El usuario final es, en todo caso, el objetivo principal de cualquier empresa que tiene equipo de 
cómputo dedicado a su servicio. Se le debe entonces, otorgar el mejor servicio en el momento 
que se necesite, no importando quien es, de donde ni a que hora se conecte. Es por esta razón que 
los equipos de cómputo deben estar en operación continua sin interrupciones. 
No obstante, en nuestra experiencia como administradores de sistemas, podemos afirmar que 
mantener la operación continua de los equipos de computo es una misión compleja y muchas 
veces no se logra del todo. En algún momento se necesita dar de baja el servicio para darle 
mantenimiento, o por alguna falla tanto de "software" como de "hardware". Cuando el 
administrador del equipo decide tomar vacaciones, el sistema también decide lo mismo. Hay 
ocasiones que el sistema está operando bien por varias horas, estando el personal presente y deja 
de operar cuando no hay nadie que lo pueda restaurar. 
Tal es el caso de un servidor de Lotus Notes operando en un sistema RS/6000, que presentó fallas 
inesperadas por errores de programa y detuvo la operación del servicio, a veces por horas. Estos 
errores cuestan mucho a la empresa o a la institución que está prestando el servicio y produce 
pérdida de tiempo y recursos. Aunque con el transcurso del tiempo el fabricante se ha esforzado 
por mejorar la calidad de su producto para prevenir futuras interrupciones, éstas no dejan de 
presentarse aunque sea en menor medida. 
10 
La labor del administrador de un sistema de cómputo es importante ya que necesita realizar 
ciertas tareas para que un sistema de cómputo esté en operación todo el tiempo. Debe, por 
ejemplo, revisar el sistema para poder diagnosticar una futura falla. Revisar bitácoras que el 
sistema envía para poder reconocer cuando es necesario darle mantenimiento. De vez en cuando 
correr tareas específicas para reparar bases de datos dañadas, añadir espacio de disco duro cuando 
este se termina, etc. Aplicar parches o nuevas versiones del producto que está administrando, 
tanto del sistema operativo como de la aplicación o servicio que se está revisando. Revisar la 
vulnerabilidad del sistema en contra de ataques informáticos. Y varias tareas más. 
Realizar estas tareas le ocupa al administrador mucho tiempo, por lo que es fundamental contar 
con herramientas que le permitan estar al tanto del estado de los sistemas que administra. Estas 
herramientas además de permitirle revisar el estado de un sistema también pueden o deben 
permitirle realizar ciertas tareas de forma que el administrador no esté supervisando el servicio 
constantemente, tarea que le ocupa la mayor parte del tiempo. 
Existen en el mercado una gran variedad de herramientas de tipo comercial, que pueden en gran 
medida solventar este espacio de tiempo y recursos que el administrador requiere para poder 
cumplir con su labor elemental. La desventaja de estas herramientas es en primer lugar el precio, 
que normalmente es elevado, dependiendo de la complejidad del producto. 
Tivoli™, un producto de IBM™, es una herramienta conocida para controlar los sistemas de 
cómputo de forma automatizada que podría, en cierta forma, ayudar con las tareas del 
administrador. Tivoli™ abarca muchas de las tareas que el administrador de un sistema de 
cómputo requiere realizar. Entre éstas están revisar el estado de un sistema de cómputo, espacio 
en disco duro, revisión de bitácoras, etc. Estas tareas se realizan de forma automática permitiendo 
al administrador realizar tareas de mayor relevancia. Tivoli™ está diseñado para operar en tareas 
específicas, por lo que es necesario adquirir un nuevo módulo siempre que se requiera monitorear 
una nueva tarea y siempre que exista este nuevo módulo. Si se requiere administrar o monitorear 
un equipo o tarea muy especifica que no se incluya en los módulos de Tivoli™, se tendrá que 
recurrir a programarlo externamente. 
También existen herramientas para monitoreo que solo realizan operaciones específicas, que si 
bien ayudan a revisar ciertos puntos del sistema, no son suficientes para revisar un sistema de 
cómputo de forma integral. Por mencionar algunas, SATAN, Ws_Ping, NetAnalizer, NetView, 
etc. Estas solo realizan una parte especifica de las labores que debe realizar un administrador y a 
veces algunas tareas son demasiado específicas por lo que no hay una herramienta que pueda 
ayudar a realizarlas. 
Cuando el administrador de un sistema de cómputo no encuentra herramientas comerciales que 
puedan ayudarle en sus labores cotidianas, desarrolla scripts 1• Los scripts incluyen el 
procedimiento que normalmente realiza el administrador para cumplir con una tarea específica 
para monitorear un sistema de cómputo. 
Para desarrollar un script es necesario conocer un lenguaje de programación, como por ejemplo: 
Peri, JavaScript, Shell o Expect. Estos lenguajes, a diferencia de los lenguajes de programación 
I Pequeños programas que son interpretados al momento de ejecución. 
11 
ya conocidos, C/C++, Java, Fortran, etc., penniten realizar pequeños programas sin la necesidad 
de compilarlos para ejecutar una labor específica. En el script, el administrador incluye el 
procedimiento que él realiza para ejecutar una labor, como la de revisar el espacio libre de un 
disco duro, o revisar el comportamiento del sistema en cuestión. 
El problema de los scripts es que no son fácilmente compartibles. Si otro administrador quisiera 
usar un script o simplemente revisarque es lo que hace, le resultaría complicado y sobre todo le 
quitaría mucho tiempo analizarlo para poder utilizarlo en otro sistema o para poder modificarlo y 
realizar otra tarea por muy similar que parezca a la tarea original. Esto se debe a que el 
conocimiento procedural para realizar la tarea está oculto en el código del script. 
Otra limitante de los scripts es que, en algunos lenguajes, no funcionan con programas o tareas 
interactivas, es decir, que no leen la salida de un programa y no envían datos a un programa sin 
que inicie o tennine su ejecución. En muchos casos es necesario trabajar con un sistema 
interactivo, ya que de otra fonna no es posible conocer el estado en el que se encuentra el 
sistema. 
Entre los lenguajes de programación para scripts que mejor ayudan a las tareas administrativas y 
de monitoreo de un sistema de cómputo están Perl y Expect. Perl pennite generar scripts para la 
mayoría de las tareas administrativas de un sistema de cómputo. Perl es un lenguaje sencillo de 
usar. El problema de Perles que no pennite el manejo de programas interactivos. 
Expect al igual que Perl, pennite generar scripts, pero su diseño está orientado a trabajar con 
programas interactivos. Esto ofrece una gran ventaja, ya que podemos monitorear el servicio de 
cómputo directamente, desde el punto de vista del usuario. Se pueden hacer simulaciones de una 
sesión que establece el usuario con el servicio computacional, pennitiendo medir el servicio que 
se está otorgando por el sistema de cómputo. Esto hace a Expect la herramienta más efectiva para 
el monitoreo de sistemas de cómputo, tanto locales como remotos. 
En ocasiones es necesario modificar el procedimiento que se sigue para monitorear un sistema de 
cómputo, de tal fonna que sea compatible con el procedimiento de otro sistema de cómputo. El 
problema es que el procedimiento a seguir está integrado al script. Si se deseara modificar el 
procedimiento, sería necesario modificar el script. Esto se vuelve complicado sobre todo para el 
administrador que está intentando implementar un script, que no generó, en sus sistemas de 
cómputo. 
Una fonna de solucionar este problema es quitar el procedimiento de monitoreo del script de 
Expect. Lo que proponemos es obtener el conocimiento del administrador para generar los 
procedimientos necesarios para monitorear los sistemas de cómputo, o sea, su experiencia. Para 
manejar los procedimientos utilizaremos un sistema experto. Este sistema es el que manejará la 
experiencia para monitorear los sistemas de cómputo y Expect se encargará de ejecutarlos. 
En esta tesis se presenta un sistema de monitoreo experto que resuelve el problema de monitoreo 
efectivo y la portabilidad de los procedimientos a seguir en el monitoreo. Se utilizará Expect 
como el sistema de ejecución y se utilizará un sistema experto, explicado en el capítulo 3, como 
administrador de conocimiento. 
Un script de Expect obtiene la información del procedimiento de una tarea en particular, de una 
base de conocimientos. Esta base de conocimientos incluye el procedimiento, separado del 
12 
código, escrito en reglas sencillas que son entendidas por el sistema experto. El script, llamado 
"Ejecutor", realiza la tarea que le es indicada en la base de conocimientos. El Ejecutor no incluye 
nada del procedimiento que se va a ejecutar, por lo que puede ejecutar cualquier procedimiento 
que esté en la base de conocimientos. 
Cada vez que Expect ejecuta una tarea espera encontrar un patrón que le es proporcionado en las 
reglas del procedimiento. Una vez que se encuentra este patrón Expect lo afirma como un hecho. 
Esta afirmación es utilizada por el sistema experto para poder inferir la siguiente regla. 
El sistema experto que se utilizó en este sistema de monitoreo y control es una herramienta 
llamada CLIPS. CLIPS es una máquina de inferencias que pretende simular el razonamiento 
humano por medio de premisas o hechos para poder inferir o dar conclusiones acerca del hecho 
que se ha declarado. En el capítulo 3 discutiremos más sobre este sistema experto. 
En el capítulo 4 discutiremos sobre el diseño y la arquitectura de nuestro sistema de monitoreo y 
control experto y cómo se desarrolló. En el capítulo 5 se exponen los resultados con dos casos, 
uno acerca del servidor de Lotus Notes y otro acerca de un sistema de correo electrónico. Estos 
dos sistemas se analizaron dada la relevancia que presentan para la Rectoría Zona Sur del 
Tecnológico de Monterrey. En el primer caso se trata de los cursos que los alumnos llevan en sus 
materias, por lo que es importante que el acceso se garantice en cualquier momento. En el 
segundo caso se trata del correo electrónico tanto de alumnos como de personal de la Zona Sur 
del Tecnológico de Monterrey del cual también se tiene que garantizar el acceso. En el capítulo 7 
se encuentran las conclusiones del trabajo. Los anexos, scripts y bases de conocimientos, que se 
utilizaron en los casos pueden encontrarse en la siguiente dirección: 
ftp ://bretonnia.rzs.itesm.mx/pub/agentes. 
13 
2 SISTEMAS DE MONITOREO 
En este capítulo analizaremos las herramientas de monitoreo que existen en el mercado, con el 
propósito de identificar las diferencias entre unas y otras. En este capítulo comentaremos por qué 
elegimos Expect como sistema de monitoreo entre las demás. 
2.1 HERRAMIENTAS DE MONITOREO 
Existen en el mercado diversas herramientas que revisan la disponibilidad de los sistemas de 
cómputo. Estas herramientas varían tanto en costo como en operación de acuerdo a las 
necesidades de monitoreo del cliente, que pueden servir para propósitos específicos o generales. 
Entre estas herramientas también se encuentran algunos lenguajes de programación. 
Las herramientas de monitoreo pueden ser tan sencillas o tan complejas como uno imagine. 
TIVOLI™ de IBM™ es un conjunto de herramientas que puede monitorear una gran variedad de 
sistemas de cómputo. TIVOLI™ es tan compleja como poderosa y además es cara. 
TIVOLI™ puede realizar las siguientes acciones, cada una con un módulo diferente: 
• Monitoreo de sistemas operativos abiertos 1 
• Monitoreo de bases de datos 
• Monitoreo de servicios de Internet 
• Monitoreo de servidores de Lotus Notes 
• Monitoreo de redes de área local 
• Respaldo y recuperación de información 
• Distribución e inventario de software en máquinas cliente y servidores 
I Sistemas abiertos: equipos UNÍX, Linux, Windows, etc., del que se tienen estándares de operación y diseño. 
14 
• Monitoreo de la seguridad de equipos de cómputo 
• Administración de usuarios 
Además de TIVOLI™ existen otras herramientas que no son tan caras pero que no abarcan tantas 
áreas específicas. Entre estas herramientas está Big Brother, que es una herramienta que funciona 
desde un servidor http2• Big Brother revisa servicios por máquina, haciendo una prueba de 
comunicación (ping) para saber si el servicio está "vivo" y en algunos casos revisa disco, 
memoria y procesador de los servidores, aunque requiere de instalar software en el servicio 
monitoreado. 
Existen otras herramientas muy variadas y que solo realizan funciones específicas. Hay algunas 
que revisan la seguridad de un equipo de cómputo, como SAT AN (Security Administrator' s Tool 
for Analyzing Networks), que además envía un reporte detallado de lo que encontró en el equipo 
monitoreado. SAT AN solo revisa que el equipo no presente problemas de seguridad que puedan 
afectar el servicio monitoreado. En sus reportes muestra los problemas que haya encontrado con 
niveles de seguridad: alto, moderado y bajo, de acuerdo a los reportes de seguridad que están 
publicados en Internet, y en la mayoría de los casos recomienda una acción a ejecutar. SAT AN es 
gratuito, es sencillo de instalar y aplicar. Solo basta con indicarle el equipo o equipos de cómputo 
que van a ser revisados. 
2.2 SCRIPTS 
La mayoría de los administradores de sistemas de cómputo eligen diseñar sus propias 
herramientas de monitoreo ya que elloles permite generar programas que se ajusten a las 
necesidades del sistema de cómputo. Para ello se basan en lenguajes de programación como C, 
C++, Java, Peri, Expect, Shell, etc. Los lenguajes Peri, Expect y Shell' s se caracterizan en que no 
desarrollan programas sino "scripts" que son interpretados por el sistema de cómputo. Esto le 
permite al adm~nistrador desarrollar scripts para realizar tareas específicas, tales como revisar 
espacio sobrante en disco, revisar el comportamiento del equipo de cómputo tanto en hardware 
como en software, etc. 
Uno de los lenguajes más utilizado por administradores es Peri (Practica} Extraction and Report 
Language ). Peri es muy utilizado para desarrollar scripts que realicen tareas administrativas y 
mejoren el desempeño del equipo de cómputo. Peri también es utilizado para desarrollar CGis 
(Common Gateway Interface) que son aplicaciones para interactuar con el usuario a través de 
WEB. 
Expect es un lenguaje que facilita el desarrollo de scripts para monitoreo. Entre sus características 
más importantes es la de interactuar con programas que son diseñados para trabajar directamente 
con el usuario y por tanto, esperan respuesta de él. 
Expect se utiliza en este trabajo de tesis para el diseño de su sistema de monitoreo. En lo que 
resta de este capítulo, hablaremos de Expect, cuales son sus características, cómo funciona y 
sobre todo en qué puede ayudar a este trabajo de tesis. 
2 http: Hyper Text Transfer Protocol. Protocolo de transferencia para sesiones de WEB. 
15 
2.3 EXPECT 
La utilización de scripts, es una práctica común entre muchos administradores de sistemas de 
cómputo. Los scripts tienen la limitante de que no pueden interactuar con un programa 
interactivo, o sea, no pueden tomar decisiones sobre el resultado de un programa que no ha 
terminado su ejecución, y por lo tanto no pueden ingresarle datos y/o comandos. Con Expect 
podemos resolver este problema ya que nos permite trabajar con programas interactivos. 
Con Expect podemos diseñar programas que puedan ejecutar acciones de manera automática 
sobre procesos en los que se requiere de una entrada para continuar la ejecución. Esto facilita 
enormemente el trabajo del administrador, otorgándole tiempo para dedicarse a otras tareas, más 
orientadas a la administración. Además esto permite lograr un monitoreo más efectivo, ya que 
podemos, desde el punto de vista del usuario, revisar el servicio que está ofreciendo el sistema. 
2.3.1 HISTORIA DE EXPECT 
Expect es una herramienta ampliamente difundida en Internet desde hace varios años. Fue 
desarrollada por el gobierno de los Estados Unidos en el año de 1987. Tuvo mucha influencia del 
personal de la Universidad de Berkeley. Inicialmente se ideó como una herramienta que 
permitiera automatizar sesiones remotas a través del programa telnet. Esta versión de Expect se 
denominó stelnet, donde se realizaban procesos sencillos de reconocimiento y envío de 
comandos. Fue hasta 1990 con la ayuda de una herramienta llamada Tcl3 que Expect tomó forma 
como herramienta de uso general para automatización de procesos. 
Cuando en 1990 se liberó la primera versión inmediatamente tuvo mucha demanda de 
administradores en todo Internet y ese mismo año Expect sufrió muchos cambios desde la versión 
1.0 hasta la versión 2.33. La demanda hizo saber a los diseñadores la verdadera utilidad que tiene 
Expect por lo que se ha continuado desde entonces con su desarrollo. La última versión de 
Expect fue liberada el 12 de Mayo del 2000 con la versión 5.31.8. 
Aunque Expect en sus inicios solamente tenía versiones para plataformas UNIX, actualmente hay 
versiones liberadas para Windows NT, dada la demanda que ha tenido esta herramienta. 
3 Too! Command Language 
16 
2.3.2 QUÉ ES EXPECT 
Expect es una herramienta que permite controlar aplicaciones interactivas, sobre todo en líneas de 
comando. Estas aplicaciones, de forma interactiva, preguntan y esperan a que el usuario 
introduzca una serie de caracteres en respuesta. Expect puede ayudar a automatizar estas 
interacciones. El uso de programas automáticos puede ayudar a solucionar problemas que no se 
habían considerado anteriormente[l ]. 
Expect es un lenguaje orientado a terminal (tty). Una tty es una interfaz, que se utiliza 
principalmente en UNIX, con las características de un puerto serial conectado a una terminal que 
sólo transmite caracteres. Mientras que los programas que utilizan el modelo entrada / salida por 
omisión son fáciles de interconectar, los programas que se conectan directamente a las terminales 
de usuario (tty) no son sencillas de interconectar. Expect resuelve el problema usando una 
pseudoterminal, mejor conocida como pty, cuando se comunica con estos programas, como lo 
haría usualmente un usuario. 
Como ejemplo, considere el comando fsck, que es un programa para revisar la consistencia de un 
sistema de archivos UNIX. Este programa se puede correr en un script solamente con las 
opciones -y o -n. La opción -y sirve como respuesta a la pregunta: "Hay errores en el sistema 
de archivos, ¿deseas que sean reparados?" La opción -n es la más segura pero es inútil si se 
encuentra algún problema con el sistema de archivos. 
Este tipo de interfaz es sin excusa mala y muchos programas tienen el mismo estilo. El comando 
f tp, un programa de transferencia de archivos, tiene una opción que deshabilita la interacción y 
permite ejecutarse desde un script. Aún así no provee forma de tomar acciones alternativas en 
caso de que ocurriera algún error. 
Expect puede resolver estos problemas otorgando toda la funcionalidad de interacción de forma 
no-interactiva. Los problemas con f sck y f tp ilustran una mayor limitación en la interfaz de 
usuario ofrecida por los shells como sh, csh, ksh y otros. Algunos programas no pueden 
ejecutarse desde un script de shell. Por ejemplo, passwd programa que sirve para cambiar una 
contraseña, no puede ejecutarse sin que el usuario de forma interactiva ingrese la nueva 
contraseña. Algunos programas similares como telnet, crypt, su, rlogin, no pueden ser 
automatizados en un script de shell. Expect está diseñado específicamente para interactuar con 
programas interactivos[ 1]. 
Expect se llama así por un comando específico del lenguaje que espera la salida de un programa. 
El comando expect es el corazón del programa Expect. El comando expect tiene una lista de 
patrones que tiene que buscar. Cada patrón es seguido de una acción. Si el patrón es encontrado, 
la acción es ejecutada. 
Por ejemplo, el siguiente fragmento[ 1] es extraído de un script que involucra un login. Cuando se 
ejecuta, el script espera las siguientes cadenas "bienvenido", "falla", u "ocupado" y ejecuta una 
de las correspondientes acciones. La acción asociada con ocupado muestra que se tienen que 
ejecutar varias acciones. La palabra reservada timeout es un patrón especial que se ejecuta si 
ninguno de los otros patrones se encuentra en un tiempo determinado. 
17 
expect { 
"bienvenido" break 
"falla" abort 
timeout abort 
"ocupado" { 
} 
puts "Login ocupado" 
continue 
Hay ocasiones donde es necesario detectar que una fuente de entrada desaparece por alguna 
razón, o no se recibe esa entrada en un periodo determinado de tiempo. Expect tiene patrones 
especiales eof y timeout para probar esas condiciones. 
El comando expect es utilizado cuando la intervención humana es necesaria. Sin embargo, Expect 
tiene un comando para utilizar cuando la actividad principal del programa que se necesita 
controlar es interactiva. Este comando es interact. Con este comando el script de Expect tiene la 
capacidad de interceptar selectivamente y actuar con el usuario y con el programa que está 
controlando. 
2.3.3 EXPECT COMO HERRAMIENTA PARA UN MONITOREO EFECTIVO 
Algunos programas muestran un comportamiento diferente cuando corren interactivamente y 
cuando no, y esto se hace intencionalmente. Por ejemplo, muchos programas piden algún dato 
solamente cuando corren de formainteractiva. De manera no interactiva no piden dato alguno. 
Un problema ocurre cuando se trabaja con pro.gramas que cambian la forma en la que almacenan 
su salida dependiendo si corren de forma interactiva o no. Los programas en UNIX que utilizan 
la librería de entrada / salida estándar envían su salida a un buffer4 cuando corren de forma no 
interactiva. Esto causa problemas cuando es necesario ver la salida inmediatamente. Expect 
puede hacer que los programas crean que están corriendo interactivamente resolviendo el 
problema de la salida de datos. 
Como otro ejemplo, un shell obliga al usuario a teclear caracteres de control ("Z, "C) y palabras 
clave (fg, gb)5 para intercambiar procesos. Esto no puede ser programado desde un script en 
shell. Es imposible construir scripts en shell para probar cierto comportamiento de un shell. Con 
Expect es posible manejar el problema utilizando las características interactivas del shell. 
Expect es muy útil para automatizar procesos en background a través de cron6. Usar Expect con 
eran permite no solo automatizar interacciones sino arrancar los procesos en primera instancia. 
Por ejemplo, copiar archivos cada noche de un equipo a otro. De estos archivos probablemente 
solo se quieran copiar aquellos que cumplan ciertas características como tamaño, fecha de 
4 Espacios de almacenamiento temporal de un sistema operativo. 
5 fg: Foreground. Sirve para traer un proceso que está corriendo en background; bg: background. Sirve para correr un proceso en 
background 
6 Cron: comando para programar eventos en un sistema de cómputo UNIX 
18 
creación, fecha de modificación, etc. O también se quiere realizar la transferencia sólo si el 
tiempo de respuesta entre los equipos sea favorable para realizar la transferencia. 
También es posible tener un proceso cron que de fonna interactiva contacte al usuario mientras 
está en background. Por ejemplo, un script f t p puede necesitar un password para continuar con 
lo que está haciendo. Después de obtener el password, Expect lo usará para completar la tarea. 
Hacer que Expect busque passwords pennite que no estén escritos en el script. 
Expect es gratuito y se puede obtener de muchos sitios de Internet. El sitio oficial de expect se 
encuentra en http://expect.nist.gov. En esta dirección también se encuentran otras herramientas 
como Tcl, y algunas otras que son de utilidad. El software de Expect incluye manuales, ejemplos 
y referencias. 
2.3.4 LIMITACIONES DE EXPECT 
Como se mencionó anteriormente el hecho de utilizar un script de Expect para monitorear 
efectivamente un sistema de cómputo, induce uno de los problemas de los que se habló en un 
principio: el conocimiento no es portable o compartido. El hecho de construir un script involucra 
que el conocimiento esté incluido en el código de ese script y por lo tanto no se pueda utilizar 
fácilmente en otra tarea o para otro procedimiento. Sería necesario modificar el script para que 
ejecute otra tarea diferente. Para resolver este problema utilizaremos una herramienta adicional 
para que nuestro sistema sea utilizable con cualquier procedimiento sin la necesidad de rescribir 
el código para el nuevo procedimiento. 
2.4 SISTEMA EXPERTO COMO COMPLEMENTO DE EXPECT 
Para poder resolver el problema de la portabilidad y de la inclusión del procedimiento en el 
código del script utilizaremos un sistema experto. Este sistema experto guarda el procedimiento 
en una base de conocimiento que incluye todos los pasos del procedimiento que se seguirá en el 
monitoreo. 
Expect ayuda a resolver el problema de la interactividad de los programas que se necesitan 
monitorear y comportarse ante ellos como lo haría el administrador del sistema. Un sistema 
experto ayuda a resolver el problema de la portabilidad y administración del conocimiento. 
2.5 CONCLUSIONES 
A pesar de que existen muchas herramientas para mantener en operación continua a un sistema de 
cómputo, es necesario generar programas que ayuden a realizar tareas de propósito muy 
especifico. Expect facilita el monitoreo eficiente de equipos de cómputo, pero el conocimiento 
procedural sigue mezclado con el código del script y no permite usarlo en otros sistemas. 
Expect apoyado de un sistema experto puede dar paso a un sistema de monitoreo y control 
experto que pueda controlar y administrar tareas y procesos orientados a mantener en operación a 
un servicio computacional. Además de que el conocimiento que se tiene que aplicar a estas tareas 
puede ser fácilmente portado a otros sistemas de cómputo sin tener la necesidad de modificar el 
código del script y adaptar el conocimiento a las nuevas tareas de cómputo. 
19 
3 SISTEMA EXPERTO 
La necesidad de utilizar un sistema experto en nuestro sistema de monitoreo y control cumple con 
la limitante que existe en un script de Expect para administrar el conocimiento de un 
procedimiento cualquiera. De esta forma queda completa la solución que en esta tesis se sugiere 
para resolver problemas de monitoreo y tareas de administración de equipos de cómputo. 
En este capítulo hablaremos acerca de un sistema experto y como administrar el conocimiento, 
así como de un sistema de soporte de decisiones. 
3.1 SISTEMAS EXPERTOS 
Un sistema experto es un programa de computadora que representa y razona con conocimiento de 
algún tema en especial con el objetivo de resolver problemas o dar algún consejo[6]. 
Este tipo de sistema puede completar una función que normalmente requiere de experiencia 
humana, o puede jugar el papel del asistente de una persona que toma decisiones. Esta persona 
usualmente es un experto en su área, en cuyo caso el programa puede justificar su existencia para 
mejorar la productividad de este experto. 
Las tareas típicas de un sistema experto involucran la interpretación de datos, el diagnóstico de 
fallas, el análisis estructural de objetos complejos ( como un componente químico), la 
configuración de un objeto complejo ( como un sistema computacional), y la planeación de 
secuencias de acciones. 
20 
3.2 CARACTERÍSTICAS DE UN SISTEMA EXPERTO 
Un sistema experto puede distinguirse de un programa de aplicaciones convencional en que[6]: 
Simula el razonamiento humano acerca del dominio de un problema, más que simular el dominio 
mismo. Esto distingue a un sistema experto de programas similares que envuelven modelos 
matemáticos. Esto no quiere decir que el programa es un modelo psicológico del experto, más 
bien, se enfoca a emular las habilidades en resolver problemas del experto, esto es, realizar las 
tareas relevantes tan bien, o mejor, que el experto. 
Realiza razonamiento sobre representaciones del conocimiento humano, además de realizar 
cálculos numéricos u obtención de datos. El conocimiento en el programa es expresado en algún 
lenguaje de propósito específico y se mantiene separado del código que realiza el razonamiento. 
Estos módulos del programa se refieren a la base de conocimiento y la máquina de inferencia, 
respectivamente. 
Resuelve problemas por heurística o métodos aproximados los cuales, al contrario de las 
soluciones algorítmicas, no se garantiza su éxito. Una heurística es esencialmente una regla la 
cual codifica un pedazo de conocimiento acerca de cómo resolver problemas en un dominio. 
Dichos métodos son aproximados en el sentido de que no requieren datos perfectos y las 
soluciones derivan en que el sistema puede ser propuesto con varios niveles de confianza. 
Un sistema experto difiere de otros tipos de programas de inteligencia artificial en que: 
Trata con la importancia de un asunto de complejidad real que normalmente requiere de un 
monto considerable de experiencia humana. Muchos programas de inteligencia artificial son por 
si solos vehículos de investigación, y se enfocan en problemas matemáticos abstractos. Los 
sistemas expertos, por otro lado, resuelven problemas de importancia científica o de interés 
comercial. 
Deben exhibir alto desempeño en términos de velocidad y de forma que sea unaherramienta útil. 
Los sistemas expertos deben proponer soluciones en un tiempo razonable y ser correctos la 
mayoría del tiempo, al menos tanto como un humano experto. 
Debe ser capaz de explicar y justificar soluciones o recomendaciones para convencer al usuario 
de que su razón es correcta. Los programas de investigación son ejecutados típicamente solo por 
sus creadores, o por otras personas del mismo laboratorio. Un sistema experto podrá ser 
ejecutado por un amplio rango de usuarios, y debe ser diseñado de forma que su utilidad sea 
transparente. 
El término sistema basado en conocimiento es a veces utilizado como un sinónimo de un sistema 
experto, pero no en el sentido estricto de la palabra. Un sistema basado en conocimiento es 
cualquier sistema que realiza una tarea aplicando reglas de una representación simbólica de 
conocimiento, en lugar de aplicar métodos algorítmicos o estadísticos. 
En resumen, los sistemas expertos codifican el conocimiento de un dominio de algún campo y 
usan este conocimiento para resolver problemas, en lugar de utilizar métodos independientes del 
dominio derivados de alguna ciencia computacional o matemática. El proceso de construir un 
sistema experto también es llamado ingeniería del conocimiento, y es considerado como 
inteligencia artificial aplicada. 
21 
3.3 SISTEMA DE SOPORTE DE DECISIONES 
Un sistema de soporte de decisiones (SSD) puede ser definido como: 
"Un programa computacional que provee información en un dominio de aplicación dado por 
medio de modelos analíticos de decisión y accesos a bases de datos, para dar soporte a la toma de 
decisiones de manera que se tomen decisiones efectivas en tareas complejas y semiestructuradas 
(no programables)"[l 1] 
El concepto de problemas semiestructurados es opuesto al concepto de "bien estructurados" que 
es bien conocido. Los problemas estructurados son rutinarios y repetitivos, dado que cada 
problema tiene un método de solución sencillo. Un problema menos estructurado tiene más 
alternativas de solución. Las soluciones pueden ser no equivalentes. Un problema completamente 
no estructurado no tiene método de solución conocido. 
El número de situaciones donde las decisiones tienen que tomarse y donde el problema es no-
programable es muy complejo de administrar. La importancia económica de investigación, el 
desarrollo en resolver este tipo de problemas y la necesidad de proveer SSD para todas estas 
clases de decisiones. El desarrollo de tecnología de Inteligencia Artificial ha ampliado el espectro 
de aplicaciones para estos sistemas. Uno de ellos son los sistemas expertos. 
3.4 CONOCIMIENTO 
El conocimiento involucra relaciones entre cosas. El conocimiento es activo. Los datos, por otro 
lado, son pasivos. El conocimiento que se obtiene del análisis de los datos es activo[?]. 
3.4.1 CONOCIMIENTO PROCEDURAL CONTRA DECLARATIVO 
Un procedimiento es un método paso a paso para obtener algún resultado en específico. Un 
procedimiento bien definido para una computadora es llamado un algoritmo. 
El conocimiento declarativo tiene que ver con relaciones lógicas o empíricas entre términos. 
En el procesamiento de datos convencional, se pensaría del conocimiento procedural como un 
programa, y al conocimiento declarativo como datos en una base de datos. 
El conocimiento de un procedimiento paso a paso es normalmente sencillo de definir. Eso es lo 
que hacen los programadores todo el tiempo cuanto tienen que desarrollar un algoritmo o un 
árbol de decisiones para describir una tarea. 
La toma de decisiones es más compleja y es caracterizada por el uso de inferencias. La forma 
más común de establecer relaciones inferenciales es a través de una regla, por ejemplo: 
22 
Regla 1 
SI animal_pone_huevos = verdadero Y 
animal_tiene_plumas = verdadero 
ENTONCES animal= ave 
Usando el principio lógico llamado modus ponens, si se declara que la regla 1 es correcta y 
entonces, en una instancia específica, si se determina que un animal en particular pone huevos y 
tiene plumas, se puede inferir que el animal es un ave. 
3.4.2 REPRESENTACIÓN DEL CONOCIMIENTO 
La mayoría de los sistemas de inteligencia artificial están compuestos de dos partes básicas: una 
base de conocimientos y una mecanismo (máquina) de inferencias[8]. 
La base de conocimientos contiene hechos acerca de objetos en un dominio elegido y sus 
relaciones. También puede contener conceptos, teorías, procedimientos prácticos y sus 
asociaciones. La base de conocimientos es la fuente de inteligencia del sistema y es usado por el 
mecanismo de inferencias para razonar y trazar conclusiones. 
El mecanismo de inferencias es un conjunto de procedimientos que son utilizados para examinar 
la base de conocimientos de forma que se puedan contestar preguntas, resolver problemas y 
tomar decisiones en un dominio. 
3.4.3 REPRESENTACIÓN EN LÓGICA 
La forma general de un proceso lógico es ilustrada en la Figura 2.1. Primero, se da la 
información, se hacen declaraciones, y se anotan observaciones. Estas forman la entrada del 
proceso lógico y son llamadas premisas. Las premisas son usadas por el proceso lógico para crear 
una salida, la cual consiste en conclusiones denominadas inferencias. Con este proceso, los 
hechos que son verdaderos pueden usarse para derivar nuevos hechos que también pueden ser 
verdaderos[8]. 
Entrada 
Premisas o 
hechos 
I Procesos • ~~~~~.i•~~-ló_a_ic_o_s~~~~~~-
Salida 
Inferencias o 
conclusiones 
23 
Figura 3.1 Forma general de un proceso lógico 
Para que una computadora realice razonamientos usando lógica, se necesita utilizar algún método 
para convertir las declaraciones y los procesos de razonamiento en una forma que la computadora 
pueda manipular. Esto se conoce como lógica simbólica. Las dos formas básicas de lógica 
computacional son la lógica proposicional ( o cálculo proposicional) y la lógica de predicados ( o 
cálculo de predicados). 
3.4.4 LÓGICA PROPOSICIONAL 
La razón de utilizar lógica proposicional en este proyecto cumple con la necesidad de representar 
el conocimiento que se utiliza en el sistema experto. En esta parte hablaremos de algunos 
conceptos de la lógica proposicional. 
Una proposición es una declaración que puede tomar dos valores: verdadero o falso. Una vez que 
conocemos su valor se vuelve una premisa que puede ser utilizada para derivar nuevas 
proposiciones o inferencias. Las declaraciones son denotadas con una letra en mayúscula. 
Simples proposiciones como P y Q son llamadas proposiciones atómicas o átomos. Los átomos 
pueden ser combinados con conectivos lógicos para formas proposiciones compuestas[9]. 
Por ejemplo, consideramos las proposiciones G y D con el siguiente significado: 
G = "La aorta es una arteria grande" 
D = "La aorta tiene un diámetro igual a 2.5 cm" 
entonces la proposición compuesta 
tiene el siguiente significado: 
"La aorta es una arteria grande y la aorta tiene un diámetro igual a 2.5 cm." 
Sin embargo, no todas las fórmulas consistentes de átomos y conectivos son proposiciones 
compuestas. Para distinguir sintácticamente las fórmulas correctas que representan proposiciones 
de las que no lo son, la noción de una fórmula bien formada se presenta en la siguiente 
definición: 
Una fórmula bien formada en lógica proposicional es una expresión que tiene una de las 
siguientes formas: 
Un átomo es una fórmula bien formada. 
Si F es una fórmula bien formada entonces .Fes una fórmula bien formada. 
Si F y G son fórmulas bien formadas, entonces (F" G),(F v G),(F ~ G) y (F ~ G) son 
fórmulas bien formadas. 
24 
Ninguna otra fórmula es una fórmula bien formada. 
Por ejemplo, (F /\ (G---+ H)) y (F v (.G)) son fórmulas bien formadas de acuerdo a la 
definición anterior, pero la fórmula (---+ H) no es una fórmula bien formada. 
La noción de una fórmula bien formada le concierne únicamente a la sintaxis de las fórmulas en 
lógica proposicional, no expresa que las fórmulas sean falsas o verdaderas. En otras palabras, no 
nos dice nada con respectoa la semántica de las fórmulas. La verdad o falsedad de una fórmula 
es llamada su valor de verdad. El significado de una fórmula en lógica proposicional es definido 
por el significado de una función 
w: PROP-+ (verdadero,falso) 
la cual asigna a cada proposición en el conjunto de proposiciones PROP un valor de verdad, 
verdadero o falso. Consecuentemente, la información que el átomo P tiene como valor de verdad 
verdadero es denotado por w{P) = verdadero y la información del átomo P tiene como valor de 
verdad falso es denotado por w(P) =falso. La función w es llamada función de interpretación si 
satisface las siguientes propiedades (asumiendo que F y G son fórmulas bien formadas): 
w(.F) = verdadero si w(F) =falso, y w(.F) = falso si w{F) =verdadero. 
w{F /\ G) = verdadero si w{F) = verdadero y w(G) =verdadero; de otra forma 
w{F /\ G) =falso. 
w{F v G) = falso si w{F) = falso y w(G) =falso; en todos los otros casos, es decir, si al menos 
uno de los valores de las funciones w{F) y w( G) es verdadero, entonces w{F v G) = verdadero . 
w(F ---+ G) = falso s1 w{F) = verdadero y w( G) = falso ; en todos los otros casos 
w( F ---+ G) = verdadero 
e w{F ~ G) = verdadero si w(F) = w( G); de otra forma w(F ~ G) = falso. 
En la tabla 3.1 se resumen estas propiedades. 
F G .F FAG FvG F--.+G F~G 
verdadero verdadero falso verdadero verdadero verdadero verdadero 
verdadero falso falso falso verdadero falso falso 
falso verdadero verdadero falso verdadero verdadero falso 
falso falso verdadero falso falso verdadero verdadero 
Tabla 3.1 Propiedades de satisfacibilidad 
Las primeras dos columnas en esta tabla listan todas las posibles combinaciones de los valores de 
verdad para las proposiciones atómicas F y G ; el resto de las columnas definen los significados 
de sus respectivos conectivos. Si w en una interpretación la cual asigna a una fórmula dada el 
valor de verdad verdadero , entonces w es llamado un modelo de F . En una fórmula que 
contenga n diferentes átomos, hay zn formas posibles de asignar valores de verdad a los átomos 
en la fórmula. 
25 
Una fórmula es llamada una fórmula válida si es verdadera bajo todas sus interpretaciones. Una 
fórmula válida también es llamada una tautología. Una fórmula es llamada inválida si no es 
válida. Entonces, una fórmula válida es verdadera a pesar de la veracidad o falsedad de sus 
átomos constituyentes. 
Una fórmula es llamada insatisfacible o inconsistente si la fórmula es falsa bajo todas sus 
interpretaciones. Una fórmula insatisfacible es también llamada una contradicción. Una fórmula 
es llamada satisfacible o consistente si no es insatisfacible. 
Note que una fórmula es válida precisamente cuando su negación es insatisfacible y viceversa. 
Válida 
Siempre 
verdadera 
Ejemplo: 
Pv-,P 
Inválida 
Algunas veces 
verdadera 
Algunas veces 
Falsa 
Ejemplo: 
PvQ 
Satisfacible 
Figura 3.2 Relación lógicas 
Siempre 
Falsa 
Ejemplo: 
p A ,P 
Insatisfacible 
La figura 3.2 muestra la relación entre las nociones de validez e invalidez, y satisfacibilidad e 
insatisfacibilidad. 
Dos fórmulas F y G son llamadas equivalentes, escritas como F = G, si los valores de verdad 
de F y G son los mismos bajo todas las posibles interpretaciones. 
Ejemplo: La Tabla 3.2 muestra que .(P A Q) = .P v -,Q. 
p Q -,(P A Q) -,Pv-,Q 
verdadero verdadero falso falso 
verdadero falso verdadero verdadero 
falso verdadero verdadero verdadero 
falso falso verdadero verdadero 
Tabla 3.2 Fórmulas equivalentes 
Usando tablas de verdad se pueden mostrar las equivalencias lógicas listadas en la Tabla 3.3. 
Estas equivalencias son llamadas leyes de equivalencia. La ley (a) es llamada la ley de la doble 
negación; las leyes (b) y ( c) son llamadas leyes de conmutatividad; ( d) y (e) son las llamadas 
leyes de asociatividad. Las leyes (j) y (k) son conocidas como leyes de De Margan. Estas leyes 
son utilizadas para transformar una fórmula bien formada en un equivalente lógico pero 
sintácticamente diferente. 
26 
Leyes de equivalencia 
(a)... .(.F)= F... . --~- --------
(b) 
(c) 
(d) 
(e) 
(f) 
(g) 
(h) 
FvG=GvF 
FAG=GAF 
(FA G)A H =FA (G AH) 
(FvG)vH=Fv(GvH) 
F v (G AH)= (F v G)A (F v H) 
F A(Gv H)=(F AG)v(F AH) 
F ~ G=(F ~ G)A(G~ F) 
(i) F ~ G = .F V G 
U) .(FA G) = .F v .G 
(k) .(F v G) = .F /\ .G 
Tabla 3.3 Leyes de equivalencia 
Un conjunto de fórmulas puede ser escrito como una fórmula donde sus elementos son tomados 
como subfórmulas de una fórmula dada. 
Las tablas de verdad pueden ser aplicadas para determinar si una fórmula dada sigue o no una 
secuencia lógica de un conjunto de fórmulas. En otras palabras, una fórmula sigue lógicamente 
un conjunto de fórmulas y si es satisfecha en todas sus interpretaciones satisface el conjunto de 
fórmulas dado. Decimos que es una consecuencia lógica de las fórmulas de un conjunto dado. 
Una fórmula G se dice que es consecuencia lógica de un conjunto de fórmulas 
F = {F¡ , ... , FJ, n ~ 1 , denotada por F H G , si para cada interpretación w de la cual 
w(F¡ /\ · · · /\ Fn) = verdadero , tenemos w( G) = verdadero . 
La fórmula Res consecuencia lógica del conjunto de fórmulas {P A .Q, P ~ R} . Podemos 
escribir esto como {P A -,Q, P ~ R} H R . 
Satisfacibilidad, validez, equivalencia y consecuencia lógica son nociones semánticas; estas 
propiedades son generalmente establecidas usando tablas de verdad. Sin embargo, es posible 
derivar consecuencias lógicas con operaciones sintácticas. Una fórmula que es derivada de un 
conjunto de fórmulas es garantizada como una secuencia lógica si el conjunto de operaciones 
sintácticas empleadas cumple ciertas condiciones. 
Los sistemas que utilizan operaciones sintácticas son llamados sistemas de deducción. Un 
ejemplo de un sistema de deducción es un sistema axiomático, que consiste de un lenguaje formal 
como un lenguaje de lógica proposicional, un grupo de reglas de inferencia (las operaciones 
sintácticas) y un conjunto de axiomas. 
27 
3.5 CLIPS 
Una vez discutida la noción de un sistema experto y sus formas de representación de 
conocimiento y de sistemas de soporte de decisiones, podemos conocer más a fondo sobre la 
herramienta que dará el soporte a decisiones del prototipo. 
3.5.1 ¿QUÉ ES CLIPS? 
CLIPS es una herramienta de sistemas expertos diseñada para facilitar el desarrollo de software 
para modelar el conocimiento humano o experiencia. Es un acrónimo de "C Language Integrated 
Production System". Es un sistema desarrollado en la NASA 1 con el propósito específico de 
proveer alta portabilidad, a bajo costo, y fácil integración con sistemas externos[ 1 O]. 
CLIPS está compuesto de: 
Lista de hechos. Contiene los datos sobre los que se derivan las inferencias. 
Base de conocimientos. Contiene todas las reglas. 
Máquina de inferencias: controla la ejecución de las reglas. 
CLIPS permite diseñar procedimientos con el uso exclusivo de reglas, objetos o una mezcla de 
reglas y objetos. Las reglas y objetos forman un sistema integral dado que las reglas pueden 
comparar patrones en hechos y objetos. Además dado que se puede usar como una herramienta 
"stand-alone" puede ser llamado desde un lenguaje procedural, realizar su función y regresar el 
control al programa que lo ejecutó. 
CLIPS es un lenguaje diseñado para escribir aplicaciones llamadas sistemas expertos. Un 
programa escrito en CLIPS puede contener reglas, hechos y objetos. La máquina de inferencias 
decide que reglas deben ser ejecutadas y cuando. Un sistema experto basado en reglas escrito en 
CLIPS es un programa manejador de datos donde los hechos y objetos son los datos que 
estimulan la ejecución de la máquina de inferencias. 
3.5.2 CLIPS COMO COMPLEMENTO DE EXPECT 
Con CLIPS podemos administrar el conoc1m1ento que contienen la información de 
procedimientos que será usada por Expect. Expect, como ya mencionamos, no tiene una forma de 
administrar el conocimiento que está incluido en el código de sus scripts. Es por esta razón que 
I National Aeronautics and Space Administration28 
CLIPS puede complementar el desarrollo de este prototipo para que el conocimiento de un 
procedimiento sea mucho más sencillo de utilizar en otros dispositivos o sistemas de cómputo. 
Expect puede consultar a CLIPS como un programa con el que tiene que interactuar para obtener 
información acerca del procedimiento que tiene que utilizar para monitorear cierto servicio o 
ejecutar cierta tarea en un sistema de cómputo. 
3.5.3 REGLAS 
Para poder otorgar la información que necesita Expect para el procedimiento, CLIPS debe 
reconocer la información de alguna forma para poder ser interpretada por Expect. 
Estas reglas son los pasos a seguir en un procedimiento que están codificadas de forma que 
CLIPS pueda utilizar como materia de razonamiento. De la forma en como están descritas estas 
reglas se hablará en el siguiente capítulo. 
3.6 CONCLUSIONES 
El uso de un sistema experto en este proyecto cubre la necesidad de administrar el conocimiento 
de los procedimientos que se aplicarán en las tareas de administración de un sistema de cómputo. 
Complementando de esta manera las limitantes de Expect de portabilidad del conocimiento. De 
esta forma se tiene una forma de administrar el conocimiento haciendo más sencilla la interfaz de 
comunicación con el administrador y/o usuario. 
La idea de incluir un sistema experto en este sistema de monitoreo y control no orienta al mismo 
a ser un proyecto de Inteligencia Artificial, sino que se usa como herramienta de apoyo para 
resolver el problema de la administración de sistemas de cómputo y su continua supervisión. 
29 
4 SISTEMA DE MONITOREO EXPERTO 
El sistema de monitoreo experto, propuesto en esta tesis, se diseñó utilizando dos herramientas: 
Expect y CLIPS. Expect juega un papel importante en nuestro sistema, dado que nos permite 
interactuar con programas de la misma formá· que lo haría cualquier usuario. CLIPS, por otra 
parte, sirve como administrador del conocimiento con la finalidad de que el conocimiento no esté 
mezclado con el código del script de Expect. Este conocimiento será utilizado por Expect para 
monitorear un sistema de cómputo. 
4.1 ARQUITECTURA DEL SISTEMA 
Nuestro sistema de monitoreo tiene una estructura modular y puede trabajar de forma separada 
con cada módulo. 
..... ...... 
Soporte de Decisiones .... .... Base de conocimientos 
CLIPS "'f-- ----
j ~ ---............... --1r --
Reportes ~ EJECUTOR 
1 
A;~;tador 
1 
.... 
j ~ ...... .,. .,. .,. .,. .,. 
n .,. .,. .,. .,. .,. .,. 
Sistema objetivo de 
.,. :..- .,. 
monitoreo 
Figura 4.1 Arquitectura del sistema 
30 
En la figura 4.1 se observa la estructura del sistema. Las líneas que conectan cada módulo indican 
si se requiere intervención humana (líneas punteadas) o no (líneas continuas). El módulo central 
"EJECUTOR" es el que realiza toda la ejecución de procedimientos de monitoreo hacia el 
sistema objetivo. El módulo ejecutor obtiene la información de una base de conocimientos que es 
administrada por el sistema de soporte de decisiones. La base de conocimientos es alimentada por 
el módulo "Alimentador". Este módulo obtiene la información directamente del usuario, quien 
proporciona todos los pasos de un procedimiento a ejecutarse en el sistema objetivo. El módulo 
ejecutor envía un reporte si el procedimiento que proporciona la base de conocimientos no 
incluye información para continuar con el proceso de monitoreo. 
Para comprender la arquitectura de nuestro sistema comenzaremos hablando del contenido de la 
base de conocimientos, donde se encuentra la información que se requiere para efectuar el 
monitoreo. 
4.1.1 BASE DE CONOCIMIENTOS 
La base de conocimientos es un repositorio que contiene información sobre un procedimiento 
cualquiera para monitorear un sistema de cómputo. Para que la información pueda ser 
administrada por el módulo de soporte de decisiones esta debe estar organizada en forma de 
reglas. Las reglas tienen la forma: 
a~b 
Donde a es un hecho y b contiene la información que servirá para ejecutar un paso de un 
procedimiento. El hecho a tiene la forma: 
(p) 
Donde p es un patrón previarr..ente reconocido y que es afirmado, o sea convertido er. un hecho, 
durante la secuencia de ejecución. b tiene la forma: 
(i) 
Donde i es la información del siguiente paso en un procedimiento cualquiera. i también contiene 
información de búsqueda para afirmar el siguiente hecho p' que a su vez devolverá información i ' 
con el que se enlazan los pasos de un procedimiento cualquiera formando un árbol de decisión. 
Si un hecho a es afirmado previamente por el módulo de soporte de decisiones, entonces el 
módulo de decisiones devolverá b para continuar con el procedimiento. 
Las reglas pueden incluir información que originen bifurcaciones en el árbol de decisión. Estas 
pueden ser de la forma: 
a~bvc 
Donde a es un hecho, y b y e son los siguientes pasos en el procedimiento. En este caso el árbol 
de decisiones tiene dos ramas, y el módulo de decisiones afirmará b ó e dependiendo de los 
31 
hechos afirmados previamente o de los hechos que se afirmen en el transcurso del procedimiento. 
Observe el ejemplo de la figura 4.2. 
(Sistema objetivo no responde) 7 (Reinicia sistema objetivo) 
Figura 4.2. Ejemplo de una regla. 
La regla de la figura 4.2 podemos interpretarla como "Si el sistema objetivo no responde, 
entonces reinicia sistema objetivo". Necesitamos entonces que el hecho "(Sistema objetivo no 
responde)" esté afirmado para que ésta regla se dispare y proporcione la información de la acción 
"(Reinicia sistema objetivo)". 
Estas reglas solo pueden ser interpretadas por el módulo de soporte de decisiones, quien las 
administra. 
4.1.2 MÓDULO DE SOPORTE DE DECISIONES 
El módulo de soporte de decisiones consiste de una máquina de inferencias, una serie de reglas 
que son diseñadas de forma que construyan un procedimiento para el módulo ejecutor y un 
conjunto de hechos que van a determinarse por el módulo ejecutor. La máquina de inferencias es 
CLIPS. 
La máquina de inferencias carga todas las reglas necesarias para un procedimiento definido por el 
módulo ejecutor. El módulo ejecutor determina los hechos de acuerdo a las respuestas adquiridas 
en su interacción con el sistema objetivo y estos hechos son afirmados para obtener los pasos del 
procedimiento. 
Las reglas que se obtienen de la base de conocimientos deben tener una sintaxis específica para 
que puedan ser interpretadas correctamente por la máquina de inferencias. 
4.1.2.1 Sintaxis de las reglas 
Las reglas deben presentar la siguiente sintaxis: 
( defrule <nombre de la regla> "Comentarios" 
(<hecho>) 
=> 
(printout t <información de la acción> crlf)) 
La regla completa debe estar encerrada entre paréntesis así como el <hecho> y la <información 
de la acción>. La regla se divide en cuatro partes: el encabezado, el patrón, la flecha y la 
información de la acción. 
Encabezado. El encabezado de la regla consiste de tres partes. La primera parte es la palabra 
reservada defrule. Esta palabra le indica a la máquina de inferencias que se está definiendo una 
nueva regla. La segunda parte es el <nombre de la regla>. El nombre que se le dé a la regla debe 
ser único ya que de otra forma una regla nueva reemplazará a una regla vieja. Recomendamos 
utilizar nombres como kdb.procedimiento.patron. para hacer referencia a un procedimiento y al 
patrón de búsqueda como objetivo de la regla. La tercera parte del encabezado es una cadena 
32 
opcional de comentarios encerrada entre comillas dobles. Este comentario puede utilizarse para 
describir el propósito de la regla. Esta cadena de comentarios sólo sirve para fines informativos y 
es opcional. 
Hecho. Enseguida del encabezado se encuentra el hecho con el que se va a activar esta regla. Este 
hecho fue anteriormente un patrón de búsqueda que ha sido encontrado y afirmado por el módulo 
ejecutor. Esto es la base que permite ligar un paso de un procedimiento con otro. El hecho debe 
estar encerrado entreparéntesis. 
Flecha. El símbolo"=>" que sigue al patrón de búsqueda es llamado flecha. Está formado por el 
signo de igual que, seguido por el signo de mayor que. La flecha representa el principio de la 
parte ENTONCES en una regla de tipo SI ... ENTONCES .... La parte de la regla anterior a la 
flecha se denomina LHS 1 y la parte posterior a la flecha se denomina RHS2. 
Información de la acción. La última parte de la regla, después de la flecha, contiene información 
de la acción que debe ejecutarse por el módulo ejecutor, cuando la regla se dispare. Además 
contiene información del patrón de búsqueda que servirá para disparar la siguiente regla. Observe 
el ejemplo de la figura 4.3: 
( defrule kdb.SistemaObjetivo.reiniciar "Regla para reiniciar al sistema objetivo" 
(Sistema objetivo no responde) 
=> 
(Reinicia sistema objetivo)) 
Figura 4.3. Ejemplo de una regla. 
En la figura 4.3 podemos observar el mismo ejemplo de la figura 4.2, pero incluyendo la sintaxis 
necesaria para entendimiento del módulo de soporte de decisiones. Esta regla sólo es un paso de 
un procedimiento más extenso para monitorear el sistema objet~vo. 
Además de la sintaxis que se ha presentado en esta sección, el módulo de soporte de decisiones 
requiere un comando especial para presentar la cadena de información al módulo ejecutor. Por lo 
tanto, la regla debe incluir las palabras reservadas printout t antes de la cadena de información 
de la acción y crlf después de la cadena. Las palabras printout t, que se anteponen a la cadena 
de información, son un comando del módulo de soporte de decisiones para desplegar la cadena 
que se encuentre entrecomillada enseguida de este comando. La palabra crlf, que se pospone a la 
cadena de información, le indica que después de desplegar la cadena haga un retomo de carro, 
con el propósito de que el módulo ejecutor identifique cada una de las reglas que despliegue el 
módulo de soporte de decisiones y no se traslapen. 
La sintaxis de las reglas define la forma en como las reglas serán interpretadas por el módulo de 
soporte de decisiones. El usuario debe escribir estas reglas siguiendo la sintaxis, ya que de lo 
contrario, no se puede saber que comportamiento tendrá el módulo de soporte de decisiones y por 
lo tanto el sistema de monitoreo completo. Para evitar errores en la sintaxis, nuestro sistema de 
I LHS (Left-Hand Side) por sus siglas en inglés. Parte Izquierda. 
2 RHS (Right-Hand Side) por sus siglas en inglés. Parte Derecha. 
33 
monitoreo provee un módulo con el que se pueden diseñar las reglas de un procedimiento. Este 
módulo registra la sesión del usuario con el sistema objetivo. De esto hablaremos más en la 
siguiente sección. 
4.1.3 MÓDULO ALIMENTADOR DE LA BASE DE CONOCIMIENTOS 
Para hacer más sencilla la forma de crear las reglas de la base de conocimientos, nuestro sistema 
de monitoreo cuenta con un módulo que permite crear las reglas de forma transparente. Este 
módulo, al correr, ejecuta todos los comandos que son ingresados por el usuario en una sesión 
interactiva con el sistema objetivo. 
Observe el diagrama de la figura 4.4. En este diagrama el usuario tiene una sesión con el sistema 
objetivo de forma interactiva, pero entre los dos se encuentra el módulo alimentador. En realidad 
el usuario interactúa con el módulo alimentador y el módulo alimentador interactúa con el 
sistema objetivo. 
Usuario .... ~ Módulo alimentador ~ ~ Sistema objetivo 
""" ... """ .... 
Figura 4.4 Operación del módulo alimentador. 
Lo que hace el módulo alimentador es registrar la sesión que tiene el usuario con el sistema 
objetivo y crear las reglas que van a ser utilizadas posteriormente por el módulo ejecutor. En una 
sesión con el módulo alimentador el usuario ingresa los comandos y los argumentos que van a ser 
enviados al sistema objetivo. El módulo alimentador los convierte en reglas utilizando la sintaxis 
definida en la sección 4.1.2.1. 
El módulo alimentador pregunta siempre si cada comando es correcto. En caso de el comando sea 
correcto el módulo alimentador registra la regla. En caso contrario el módulo alimentador espera 
a que el usuario ingrese un nuevo comando con sus respectivos argumentos. 
Además de los comandos y argumentos el usuario debe ingresar el patrón de búsqueda. Este 
patrón de búsqueda será interpretado por el módulo ejecutor y el módulo de soporte de decisiones 
para obtener la siguiente regla. También se debe incluir información adicional de soporte que será 
definida en la sección 4.1.4. Cada comando y argumento que ingresa el usuario así como los 
patrones de búsqueda son ingresados al módulo de soporte de decisiones para crear las reglas. Si 
el módulo de soporte de decisiones acepta las reglas, estas son almacenadas en la base de 
conocimientos. 
La sesión con el módulo alimentador puede incluir varias sesiones con el sistema objetivo o con 
varios sistemas objetivo. Para terminar la sesión con el módulo alimentador, se puede hacer con 
el comando salir. 
4.1.3.1 Formas alternas de alimentación de reglas a la base de conocimientos 
Existe otra forma de crear las reglas además de crearlas manualmente, que deben respetar la 
sintaxis necesaria para que el módulo de soporte de decisiones pueda interpretarlas. Para crear las 
reglas de una forma más sencilla, en un archivo de texto debe incluirse: nombre de la regla, 
34 
comando, argumentos, patrón de búsqueda, comentarios, información adicional, todo separado 
por comas y dejando una coma al final de cada regla. Cada regla debe ir en una sola línea. 
Observe el ejemplo de la figura 4.5. 
Kdb.SistemaObjetivo.telnet,telnet,sistemaobjetivo,login,Iniciando sesión con sistem. 
objetivo,ORANGE,30, 
Kdb.SistemaObjetivo.login,usuario,,Password,Dar el nombre del usuario,ORANGE,20, 
Figura 4.5. Ejemplo de un listado para ingresar reglas. 
Entre cada campo pueden haber espacios, de acuerdo a el significado de la regla. Una vez que el 
archivo contenga todas las reglas que se desean ingresar a la base de conocimientos, se corre un 
programa del módulo alimentador llamado "text2kdb" seguido del nombre del archivo. 
4.1.3.2 Limitantes del módulo alimentador 
El módulo alimentador únicamente sirve para iniciar una serie de reglas que permitan definir un 
procedimiento. Cuando es necesario editar o modificar una regla es necesario seguir la sintaxis 
vista en la sección 4.1.2.1 y editar la base de conocimientos con cualquier editor de texto. Esto se 
debe a que el módulo alimentador sólo registra la sesión que tiene el usuario con el sistema 
objetivo, pero no incluye opciones de edición o modificación de las reglas. 
El módulo alimentador genera las reglas de forma que puedan ser interpretadas tanto por el 
módulo de soporte de decisiones como por el módulo ejecutor. 
4.1.4 MÓDULO EJECUTOR 
El módulo ejecutor es la parte medular de nuestro sistema de monitoreo ya que es el módulo que 
ejecuta las acciones contenidas en la reglas para realizar el monitoreo y control sobre el sistema 
objetivo. Este módulo está diseñado con Expect. 
El módulo ejecutor tiene comunicación con el sistema objetivo, así como con el módulo de 
soporte de decisiones. Observe la figura 4.6. 
Módulo Ejecutor Módulo de soporte de 
decisiones 
Sistema objetivo 
Figura 4.6. Operación del módulo ejecutor 
Base de 
conocimientos 
35 
El módulo ejecutor se comporta como el usuario lo haría frente al sistema objetivo siguiendo los 
pasos de un procedimiento incluido, en este caso, en la base de conocimientos. Observe 
nuevamente la figura 4.3 y note la línea punteada. 
La comunicación entre el módulo ejecutor y el módulo de soporte de decisiones se realiza como 
cualquier otro programa con el que tiene que interactuar. La primera acción que realiza el módulo 
ejecutor en cualquier procedimiento es interactuar con el módulo de decisiones. En la sesión entre 
el módulo ejecutor y el módulo de soporte de decisiones se carga el procedimiento de monitoreo 
que se llevará a cabo con el sistema objetivo. 
Primeramenteel módulo ejecutor arranca el módulo de soporte de decisiones: 
>Clips 
CLIPS (V6.10 07/01/98) 
CLIPS> 
El primer comando que el módulo ejecutor le envía al módulo de soporte de decisiones es la 
carga de la base de conocimientos correspondiente al procedimiento que tiene que llevar a cabo 
sobre el sistema objetivo. Note que todos los comandos que se envían al módulo de soporte de 
decisiones van encerrados entre paréntesis: 
CLIPS> (load kdb.procedimiento) 
Es necesario que se afirme un hecho para que la máquina de inferencias pueda entregar 
información del siguiente paso del procedimiento de monitoreo. Recuerde que las reglas tienen la 
forma "Si pasa esto entonces haz esto otro". Al iniciarse la comunicación con el módulo de 
soporte de decisiones, el módulo ejecutor, después de cargar las reglas, afirma un hecho para que 
el módulo de soporte de decisiones entregue el primer paso del procedimiento: 
CLIPS> (assert (hacer)) 
El hecho "hacer" se denomina hecho inicial. Este hecho inicial sirve como detonador y principio 
del procedimiento a ejecutarse en el sistema objetivo. Este hecho inicial debe contenerse en la 
primera de las reglas del procedimiento para que las demás puedan ser interpretadas. Una vez que 
se afirma el hecho inicial, el módulo ejecutor procede a iniciar la máquina de inferencias: 
CLIPS> (run) 
~"Paso 1 de un procedimiento"<- >"argumentos"<->"Patrón de 
bósqueda"<->"Comentarios"<->"COLOR"<->"timeout"~ 
El módulo de soporte de decisiones entrega los pasos del procedimiento de acuerdo a las 
respuestas que entregue el módulo ejecutor obtenidas del sistema objetivo. En este caso se 
entrega el primer paso de un procedimiento. 
Para que el módulo ejecutor reconozca las acciones que debe realizar sobre el sistema objetivo, la 
información que obtiene del módulo de soporte de decisiones debe tener una forma o sintaxis. 
36 
4.1.4.1 Sintaxis de la información que recibe el ejecutor 
El ejecutor debe recibir la información de forma que pueda entender las acciones que debe 
realizar sobre el sistema objetivo. El módulo de soporte de decisiones entrega esta información 
con la siguiente sintaxis: 
?comando<->argumentos<->patrón de búsqueda<->comentarios<->COLOR<->timeout f-
El módulo ejecutor recibe la cadena y la interpreta separándola en sus componentes. El módulo 
ejecutor separa estos componentes utilizando símbolos de separación. Se utiliza el símbolo inicial 
"7", el cual indica el comienzo de la cadena de información. Cada componente está separado 
por un símbolo intermedio "<->". El símbolo de terminación "f-" indica el fin de la cadena. No 
deben incluirse en ningún campo símbolos de separación ya que pueden confundirse y afectar la 
operación del módulo ejecutor. 
comando contiene el comando o programa a ejecutarse en el sistema objetivo. Este valor 
debe ser sólo una palabra y no puede quedar vacío. Puede contener letras, números, guiones y 
caracteres que deban servir como comandos para el sistema objetivo. 
argumentos contiene los argumentos del comando a ejecutarse en el sistema objetivo. También 
puede servir para complementar palabras que no pudieron incluirse en la parte de comando, como 
banderas, subcomandos, etc., ya que en el campo de comando no puedo ponerse más de una 
palabra. El campo argumento puede contener letras, números, guiones, espacios, que deban servir 
como argumentos del comando hacia el sistema objetivo. Este campo puede estar vacío. 
patrón de búsqueda contiene el patrón de búsqueda o respuesta del comando cuando se ejecuta. 
Este patrón servirá para afirmarlo como hecho, cuando sea encontrado, para obtener la siguiente 
regla. Este campo puede tener letras, números, caracteres especiales, espacios, todo lo que se 
necesite para localizar el patrón de búsqueda. Este campo no puede estar vacío. Este campo 
puede incluir varios patrones de búsqueda, separados por":", con lo qut>: se da opción de bifurcar 
el procedimiento en el árbol de decisiones. Cada patrón dará origen a diferentes reglas. 
comentarios contiene una leyenda que servirá para enviar al módulo de reportes. Este campo es 
únicamente informativo y no afecta la interacción con el sistema objetivo. Este campo puede 
tener cualquier carácter y puede estar vacío. 
COLOR contiene el nombre de un color en mayúsculas y en idioma inglés. Por ejemplo: 
BLUE, ORANGE, RED, YELLOW, GREEN, etc. Este valor se envía al módulo de reportes para 
indicar el estado en que se encuentra el sistema objetivo. Esta cadena puede ser utilizada por una 
aplicación que pueda indicar gráficamente el estado del sistema objetivo. Por ejemplo, un 
programa puede obtener del módulo de reportes la cadena "GREEN" y colocar un foco verde en 
una página de web indicando que el procedimiento fue exitoso. Este campo puede estar vacío, 
pero se recomienda que siempre se indique un color, aunque no indique nada, para hacerlo 
compatible con las aplicaciones que grafiquen este campo. El módulo alimentador pregunta por 
el valor de este campo en la sesión con el usuario. 
timeout contiene un valor numérico mayor a cero para indicar el tiempo en segundos que 
el módulo ejecutor debe esperar para que el sistema objetivo retome el patrón de búsqueda. Si 
este tiempo expira, entonces el módulo ejecutor enviará un correo al usuario y un reporte al 
37 
módulo de reportes. Este valor debe ajustarse a las características del sistema objetivo, ya que si 
este tiempo es muy corto es probable que expire el tiempo antes de que aparezca el patrón 
buscado. Aconsejamos considerar el tiempo de respuesta de la red por donde se debe llegar al 
sistema objetivo sobre todo si no se está monitoreando en la red local. El módulo alimentador 
pregunta por el valor de este campo en la sesión con el usuario. 
En resumen las reglas almacenadas en la base de conocimientos, siguiendo la sintaxis necesaria 
tanto para el módulo de soporte de decisiones como para el módulo ejecutor, las podemos 
observar en el ejemplo de la figura 4.7. 
( defrule kdb.Sistemaübjetivo.reiniciar "Regla para reiniciar al sistema objetivo" 
(System down) 
=> 
(printout t "7shutdown<->-Fr<->SHUTDOWN PROGRAM<->Reiniciando sistema objetivo<-
>RED<-> 120~" crlt)) 
Figura 4.7. Ejemplo de una regla de la forma en como está almacenada en la base de 
conocimientos. 
El módulo ejecutor efectuará el procedimiento hacia el sistema objetivo de acuerdo a las reglas 
que le vaya presentando el módulo de soporte de decisiones. Para dar por terminado el 
procedimiento, se requiere de una regla especial que contenga la siguiente cadena: 
"?FIN<-> FIN<-> FIN<-> FIN<->COLOR<->timeout f-" 
Con esta regla se indica al módulo ejecutor que el procedimiento ha terminado. El módulo 
ejecutor termina su ejecución y envía al módulo de reportes la leyenda "FIN" y el color que se 
indiq•Je en la regla. En este punto no es necesario poner ningún valor en el campo timeout ya que 
no se está buscando un nuevo patrón, pero se queda para hacerlo compatible con las demás 
reglas. Puede haber varias reglas con este formato de terminación, todo depende de las decisiones 
que se hayan tomado previamente. 
Cuando el módulo ejecutor no encuentra alguna regla para continuar el procedimiento de 
monitoreo, envía un reporte al módulo de reportes y envía un correo al usuario para que atienda 
la petición de nueva regla. 
4.1.5 MÓDULO DE REPORTES 
El módulo de reportes es un archivo plano donde se registran todos los comandos que han sido 
realizados por el módulo ejecutor en forma de bitácora. También se registran los intentos de 
búsqueda de patrones que han sido fallidos, mismos que pueden ser revisados para generar 
nuevas reglas en caso de necesitarse. El módulo de reportes también incluye avisos por correo 
electrónico al administrador para que revise la bitácora y pueda corregir alguna regla en 
particular o generar una nueva si fuera necesario. 
Esta parte del sistema se muestra como un módulo para que pueda servir como interfaz hacía 
otros sistemas para generar reportes