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 revisar que 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 ello les 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 forma interactiva. 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 una herramienta ú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 respecto a 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 Administration

28

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 entre paré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.

Primeramente el 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 o estadísticas sobre el sistema objetivo. Estos sistemas

38

pueden revisar el archivo para convertir la información de salida de nuestro sistema a información de entrada para otros sistemas, sobre todo si se desea ver un gráfico sobre el comportamiento del sistema objetivo.

4.2 MAPAS DE CONOCIMIENTO

Un concepto importante que debe tomarse en cuenta al momento de crear las reglas de un procedimiento, es la portabilidad del conocimiento. Las reglas pueden crearse de forma que un procedimiento pueda ser tan específico como se desee. Sin embargo, puede ser que partes del procedimiento se puedan obviar de tal forma que se pueda reutilizar parte de otro procedimiento. Esto puede hacerse con procedimientos pequeños que incluyan tareas sencillas y sobre todo tareas muy específicas.

Es fácil ver este concepto creando primeramente un diagrama de flujo, donde se vaya partiendo el procedimiento general en tareas pequeñas a realizar. Estas tareas pequeñas, pueden estar o no creadas para facilitar su portabilidad. Una vez creadas estas pequeñas tareas es posible crear un procedimiento general como si fueran piezas preconstruidas. Cada pieza puede realizar la misma función de monitoreo de sistemas de cómputo en diferentes sistemas operativos, modelos, tipos, etc., teniendo un procedimiento específico para cada uno de ellos. Esto puede facilitar la construcción de procedimientos mucho más complejos y generales que funcionen en casi cualquier equipo, ya que solo habrá necesidad de "intercambiar" piezas del procedimiento para que funcione en otro equipo.

A su vez, estas piezas también pueden incluir pasos que tengan que ver con la seguridad del sistema objetivo. Por ejemplo: cuando en el procedimiento general se incluya un paso que requiera dar de baja al sistema objetivo, se mande llamar un procedimiento específico que revise los subsistemas del sistema objetivo para asegurar que ninguno de estos subsistemas sea afectado por la baja al sistema objetivo. Estos "mini-procedimientos" a su vez pueden ser tan sencillos como complicados, de acuerdo a la tarea que requieran efectuar.

La idea principal es compartir el conocimiento, ya que no sólo se necesita compartir el conocimiento general sino que aplique a cada sistema no importando el sistema operativo o modelo, tipo, etc., en el que se quiera aplicar.

4.3 CONCLUSIONES

Nuestro sistema de monitoreo y control hace uso de dos tecnologías que han sido utilizadas durante ya varios años. Por un lado Expect permite la construcción de scripts que permiten automatizar procesos e interactuar con ellos y por otro lado CLIPS permite administrar el conocimiento. Estas dos tecnologías se complementan para formar una herramienta que puede aliviar la carga de los administradores de sistemas de cómputo, así como de mantener sus servicios en operación continua.

Además las operaciones que se realizan sobre los sistemas de cómputo pueden ser fácilmente compartidas hacia otros sistemas de cómputo con poca o ninguna modificación por parte del usuario sobre las reglas que se van a ejecutar. Todo depende de que existan las reglas para un sistema de cómputo específico.

39

5 RESULTADOS

Para probar la efectividad de nuestro sistema experto, creamos dos bases de conocimiento que probamos en sistemas que se encuentran en operación y que requieren de constante monitoreo para garantizar su servicio. Para tal objetivo monitoreamos dos servicios que se ofrecen en la Rectoría Zona Sur del Tecnológico de Monterrey.

El primer caso es un servicio de Lotus Notes. El segundo caso es un servicio de correo. Ambos casos presentaron problemas de inestabilidad. Aplicamos nuestro sistema de monitoreo para probar su efectividad.

5.1 CASO l. SERVIDOR DE LOTUS NOTES PARA EL REDISEÑO DE LA RECTORÍA ZONA SUR

La Rectoría Zona Sur del Tecnológico de Monterrey ofrece un serv1c10 para alumnos y profesores como parte de un proyecto educativo. Este servicio se ofrece a través de un servidor de Lotus Notes que corre en un sistema IBM RS6000 S70, con sistema operativo AIX.

El problema que presentó el servicio de Lotus Notes al principio del semestre Enero-Mayo del 2000, fue de un promedio de 8 a 12 interrupciones del servicio diariamente. Cada interrupción duraba aproximadamente 30 minutos, lo que significa que el servidor, en el peor de los casos, interrumpía el servicio hasta 6 horas de cada día, o sea, el 25% del tiempo.

Sin operador que pudiera estar al tanto del servidor de Lotus Notes, las interrupciones duraban más de cuatro horas.

Nuestro sistema de monitoreo se aplicó la primera semana del mes de febrero del 2000. El promedio de fallas seguía siendo de 8 a 12 por día y llegó a aumentar hasta 18 fallas en un día. Pero el tiempo de cada interrupción disminuyó de 30 a sólo 4 minutos. Nuestro sistema de monitoreo permaneció revisando el servicio de Lotus Notes cada 2 minutos. Para levantar el

40

serv1c10 nuestro sistema debía apagar el servidor en una primera v1s1ta y levantarlo en la siguiente, de ahí los 4 minutos. Como nuestro sistema revisaba el servicio de manera constante, se podía saber de inmediato cuando el servicio de Lotus Notes dejaba de operar y el momento en que nuestro sistema lo ponía de nuevo en operación.

En las siguientes gráficas, de la 5.1 a la 5.8, se puede apreciar las fallas que había durante los primeros meses del semestre Enero-Mayo del 2000. En las primeras cuatro gráficas, de la 5.1 a la 5.4, se muestran las fallas del servicio en fechas de la última semana del mes de Enero. El segundo grupo de 4 gráficas, de la 5.5 a la 5.8, muestra las fallas del servicio en la primera semana del mes de Febrero. La diferencia que hay entre las gráficas del mes de Enero y del mes de febrero es el tiempo que el servidor permanece sin atender usuarios.

111 0 ;: .. :, 111 ::, .. ,, 0 :. E ,:, z

1600 ·

1400

1200 ·

1000

800

600

400 ·

200 ·

o.

Servidor RZSRZSH1 24/Ene/2000 sin ejecutor

Usuarios Usuarios en espera j

ID N ro V o ID N ro V o ID N ro V o ID N ro V o ID N ro V o ID N ro V o ID N ro V o ID N ro V M - V N O M - V N O M - V N O M - V N O M - V N O M - V N O M - V N O M - V N

.. 6 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 6 6 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 6 ~ ~ ~ ~ ~ ~00 · - - - - - - - - - - - - - - - - - N N N N N N

Hora del día

Gráfica 5 .1. 24 de Enero del 2000

Observe la gráfica 5.1 correspondiente al día 24 de Enero. En esta fecha no se aplicó ninguna acción de monitoreo automático. En el eje horizontal se muestran las horas del día desde las O horas hasta las 24 horas. En el eje vertical se observa el número de usuarios. La línea negra representa el número de usuarios que el servidor de Lotus Notes atiende y a los que da respuesta. La línea gris muestra el número de usuarios que el servidor deja de atender y que están en espera. En muchos casos los usuarios cortaban la sesión y abrían una nueva sin avisar al servidor lo que provocaba exceso de sesiones. En la primera gráfica (24 de Enero) puede verse como la línea gris sobre pasa los 1400 usuarios en espera, lo que indica sobrecarga para el servidor de Lotus Notes y mucha espera para los usuarios.

Como anteriormente se comentó, la línea negra representa el número de usuarios que fueron atendidos por el servidor de Lotus Notes en algún momento del día. Observe que en algunos momentos esta línea negra se precipita, por ejemplo, a las 8:50 de la mañana. Esto indica que el servicio dejó de otorgarse. El tiempo de espera para el reestablecimiento del servicio fue aproximadamente de 20 minutos, a las 9:20 de la mañana. Observe también que en algunas gráficas la línea gris se eleva al tiempo en que la línea negra se precipita. Esto quiere decir que el

41

servidor se congela dejando a todos los usuarios que está sirviendo en espera y poco a poco el sistema operativo va liberando las sesiones inhábiles.

Servidor RZSRZSH1 25/Ene/2000 sin ejecutor

Usuarios Usuarios en espera 1

1600

1400

1200

11) o 1000 -·;: t--. ni :, 11) 800 -::::, CI)

"O o 600 ... CI)

E 400 ,:,

z

Hora del día

Gráfica 5.2. 25 de Enero del 2000

Observe la gráfica 5.2 correspondiente al 25 de Enero del 2000. Observe que se presentan 6 interrupciones durante el día, donde el tiempo que duran estas interrupciones varían desde 5 a 30 minutos. En la caída de 5 minutos probablemente se dio de baja el sistema por parte del administrador para fines de mantenimiento. También observe el comportamiento anterior a cada caída, donde la línea gris aumenta conforme se acerca el derrumbe del sistema.

42

Servidor RZSRZSH1 26/Enero/2000 sin ejecutor

Usuarios Usuarios en espera 1

1800 ·

1600 -

1400 ·

111 1200 o ·;: ca 1000 ::::, 111

::::, G) 800 '0 o ...

600 G)

E ,::::, z 400

200

'SI' T"" CX) lO N O> (O C') o r-- 'SI' T"" CX) lO N O> (O C') o r-- 'SI' T"" CX) lO N O> (O C')

~ e:'! '? ~ ~ e:'! T"" '? ~ ~ e:'! T"" ~ ~ C') T"" o lO ~ e:'! T"" '? ~ ~ e:'! o lO ~ -200

T"" T"" T"" T"" T"" T"" T"" T"" T"" T"" T"" T"" T"" N N N N N

Hora del día

Gráfica 5.3 . 26 de Enero del 2000.

Observe la gráfica 5.3 correspondiente al 26 de Enero del 2000. Se puede observar que la primera caída del día tiene un tiempo de aproximadamente 30 minutos a las 8:30 de la mañana. A esa hora del día es cuando empieza a subir el número de accesos al servidor ( de las 7 a las 9 de la mañana) por lo que se vuelve crítico que el servidor esté operando.

Las tres gráficas anteriores muestran tiempos de caídas de entre 20 a 45 minutos. En todo caso el servicio era restaurado cuando el administrador notaba estaba suspendido y ejercía acciones para restablecerlo. La gráfica más impresionante es la gráfica 5.4 correspondiente al día 27 de Enero del 2000. En esta gráfica se observa que a partir de las 19:30 horas se suspende el servicio y se restablece a partir de las 22:20 horas, o sea, ¡casi 3 horas sin servicio! Claramente se puede notar que el servicio no se restableció porque no había nadie que pudiera restablecerlo.

43

Servidor RZSRZSH1 27/enero/2000 sin ejecutor

Usuarios Usuarios en espera 1

1600

1400

1200

U) 1000 o ·¡: ca ::,

800 U) ::::, QI "O o ... 600 QI

E ,~ ,. .. , ' --

,::, / ' z 400 ! /

;' ,

200 ·-..,-.~-

o .-.,_..,,.,,, ..... _ ......... ,ro • .,.,., •• ,., • ,.,,_-,, ....... ~ . · .. -·-·-····-, ...... ..... ,,¡'{\ ,

CI) ce (!) '<I" N o ce (!) '<I" N o ce (!) '<I" N o ce (!) '<I" CI) "'.'I: C') e:'! ..... ~ '<I" C') N ..... o '<I" C') N ..... o '<I" C') N

-2001i o ..... N C') '<I" ~ LO <O ~ ro ro oi o ..... N N ¿..; ~ ..... ..... ..... .....

N o ce <0 '<I" N o ce <0 ~ ..... o "'.'I: C') e:'! ..... ~ '<I" C') .....

LO <0 <0 ~ ce oi o o ..- ¿..; ~ ~ ~ ~ ~ ~ N N N N

Hora del día

Gráfica 5.4. 27 de Enero del 2000.

En algunos casos el tiempo de caída del servicio de Lotus Notes es corto dado que hay un operador que se da cuenta del problema e inmediatamente reanuda el sistema. Pero hay ocasiones por ejemplo en la noche o madrugada que el sistema permanece inoperativo hasta que hay personal humano que pueda restablecer el servicio nuevamente. La gráfica 5.4 del día 27 de Enero es un claro ejemplo de esto.

Ahora analicemos las gráficas del mes de Febrero, que son las gráficas 5.5 a la 5.8. Estas gráficas muestran el comportamiento del servidor de Lotus Notes cuando nuestro sistema de monitoreo estaba en operación sobre este servidor.

Observe la gráfica 5.5 correspondiente al día 1 de Febrero del 2000. En esta gráfica se aprecian que las interrupciones del servicio de Lotus Notes duraron aproximadamente de 10 a 15 minutos. Observe la primera interrupción, de las 13 :20 horas. El servicio se reanudó a las 13 :30 horas, es decir, duró 1 O minutos. En este caso nuestro sistema estaba monitoreando el servicio y ejecutó acciones para restaurarlo. Observe la caída de las 17 horas. Ésta duró aproximadamente 12 minutos. De igual forma nuestro sistema realizó acciones para restaurar el servicio.

La razón por la que nuestro sistema de monitoreo tarda aproximadamente 1 O minutos en levantar el servicio es porque, en este caso, cuando se queda "congelado" tarda 1 O minutos en liberar la memoria del sistema. Se necesita liberar la memoria para poder levantarlo nuevamente.

44

Servidor RZSRZSH1 01/Feb/2000 con ejecutor

--usuarios Usuarios en espera 1

250

200 en o ·;: CII :::, 150 en

:::> Q) 'C o .. Q)

E ,:::, z

.... o o o o o o o o o o o o o o o o o o o o o o o o 9 o 9 9 o 9 o o o o 9 o 9 o o o o <O N á::i '<I' o <O N á::i ~ o <O N á::i '<I' o <O ¿,.¡ o '<I' ~ .... o LO C") N o LO '<I' N .... LO '<I' C") .... o o o .... ¿,.¡ ¿.; ¿.; ~ in <O <O i:..: á::i cri cri o .... N ¿.;

o o o o 9 á::i ~ o <O N '<I' C") N o LO ¿.; ~ in <O <O .... .... .... .... .... .... .... .... ....

Hora del día

Gráfica 5.5. 1 de Febrero del 2000.

o o .... o o o o o á::i ~ o <O C") N .... LO i:..: á::i cri cri .... .... .... ....

o o o o ¿,.¡ á::i '<I' e:'! o .... N N

,..._ 9 '<I' .... ¿,.¡ N

o .... 9 o o <O o '<I' ¿.; ¿.; N N

Observe que en las gráficas 5.6, 5.7 y 5.8 las caídas del servicio de Lotus Notes no varían en tiempo, o sea, todas miden aproximadamente 1 O minutos. Esto demuestra la acción que ejerce el ejecutor ante las interrupciones del servicio. Sobre todo a horas en que no existe la presencia del administrador. Observe la gráfica 5.6 correspondiente al 2 de Febrero del 2000. Observe las caídas posteriores a las 18 horas. Aquí puede observarse que las caídas duran exactamente el mismo tiempo a pesar de que sean horas en que el administrador no se encuentre cerca de la consola del servidor de Lotus Notes. El mismo comportamiento puede verse en las gráficas 5.7 y 5.8.

45

Servidor RZSRZSH1 02/Feb/2000 con ejecutor

Usuarios Usuarios en espera /

250 ..------------------------------------------------~

200

., .g

150 .. :, ., ::, .. ,, e .. E ,:, z

Hora del día

Gráfica 5.6. 2 de Febrero del 2000.

Servidor RZSRZSH1 03/Feb/2000 con ejecutor

300

250

., 200

.g .. :, ., ::, .. 150 ,, e .. E ,:, z

100

~ ; ~ ~ ~ ~ ~ ffi oc NNMM

N <O <") 9 :..¡. LO

~ ~ ~ ~ LO(O(O,-...

Gráfica 5.7. 3 de Febrero del 2000.

suarios Usuarios en espera /

.~.! .... :·,;,J.-./'• ¡, ......

~ ~ ~ ~ ~ ~ ,-..coc,rnOO

Hora del día

~ 9 8 º ~ o OLOc:ilOoui 9 ~ ~ N ~

N N ~ ~ ~ ~

5=; ~ ~ m o o N N

~ ~ ~ ~ ~ N ~ ~ ~ ~

46

Como se podrá observar la acción del ejecutor en este caso fue relevante en el aspecto de mantener el servicio en operación por mucho más tiempo a pesar de todas las fallas que este tuviera. Y sobre todo ahorró mucho tiempo y recursos ya que no era necesario tener personal revisando la consola del servidor todo el tiempo y sobre todo en horarios donde no era posible regresar el servicio a la normalidad.

Servidor RZSRZSH1 04/Feb/2000 con ejecutor

Usuarios Usuarios en espera 1

250 -,---------------------------------,

200 1-------------.------------=------------------1 U) o

·¡: ns

150 ::J U) ::, Q) '0 o ... 100 Q)

E •::J z

.rf~\.:.:~1/'f.\.~\/.•.•~

o Ol co ,.... O '<t (") N é:i é:i ~ é--i

(O 1() '<t (") N ..... o Ol co ,.... (O 1() '<t (") N ..... o Ol co ,.... (O 1() '<t (") N ..... ..... o 1() '<t (") N ..... 1() '<t (") ~ ..... ~ 1() '<t (") N o 1() '<t (") N ..... o 1() '<t (") ~ ~ l!) CD r:..: ci:i ci:i ái o ..... é--i (") r,; ~ l!) CD r:..: ,.... ci:i ái é:i ..... N N r,; ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... N N N N N

Hora del día

Gráfica 5.8. 4 de Febrero del 2000.

5.2 CASO 2. SERVICIO DE CORREO ELECTRÓNICO

En agosto del año 2000 comenzó la migración del servicio de correo en todo el sistema tecnológico. Esto implicaba migrar cualquier servicio de correo que se estuviera utilizando en los Campus del sistema a un servicio de correo estándar y uniforme para todos. El nuevo servicio de correo es una aplicación llamada Internet Message Store (IMS) de Criticalpath.

A IMS se puede tener acceso a través de varios protocolos estándar, como POP (Post Office Protocol) versión 3, IMAP (Internet Mail Access Protocol) y http (Hyper Text Transfer Protocol).

En un principio IMS sólo corría en plataformas Solaris de SUN, pero para la primera semana de Agosto del 2000, Criticalpath ya tenía liberada su versión para AIX en máquinas IBM. En los primeros días de operación la aplicación presentó un problema de inestabilidad. El problema consintió en que cuando un usuario intentaba conectarse a IMS para revisar sus mensajes, por ejemplo a través de HTTP, el servidor tardaba, a veces, hasta 5 minutos en desplegarlos. El

47

CI) CI) e: o ·¡¡; CI) ti)

problema aumentaba hasta que el servicio de correo dejaba de responder. En la gráfica 5.9 podemos observar el comportamiento del servicio de correo cuando deja de responder a las peticiones de los usuarios, a través del protocolo HTTP.

Correo Personal 18 Sep HTIP

--SAHTIP SE HTIP I

50 ~-------------------------------------

45 -I------------------------------------------1

Hora del día

Figura 5.9 18 de Septiembre del 2000.

Observe la figura 5.9. En la gráfica se muestran dos líneas. Una línea oscura, donde se muestran las sesiones activas, denotadas por SA, del servidor en el protocolo HTTP, y una línea clara donde se muestran las sesiones en espera denotadas por SE.

La figura 5.9 muestra la operación del servicio de correo de las 4 a las 5 de la tarde del día 18 de septiembre del 2000. En la gráfica puede observarse que el servicio de correo comienza a degradar su operación desde las 16:09 horas y es hasta las 16:22 horas cuando se restablece. En este caso el servicio fue restablecido por un operador al darse cuenta de la interrupción. Como podemos observar pasaron más de 1 O minutos desde que el servicio comenzó a degradarse, antes de que operara de forma correcta nuevamente. También podemos observar que pasaron aproximadamente 5 minutos, a partir de las 16:17 horas, donde el servicio es casi nulo. De cualquier forma el comienzo de la degradación del servicio es perceptible por los usuarios.

Al día siguiente pusimos en operación nuestro sistema de monitoreo con una base de conocimiento específica para este servicio.

48

Correo Personal 20 Sep HTIP

SA HTTP · · · · · · · · · · SE HTTP 1

60 ,------------------------------------------,

40 +---------~-------;--,----•·

10 ;---------------~-------,..-'----'-~------------1--------1

o +-, -,---,--,--,--,---,--,--,--,--,--,---,--,--,--,--,--,---,--,--,---,--,--,---,-,--,--,-,--,--,-,--,--,-,--,--,-,--,--,--,--,--,--,---,--,--,--,-,--,--,-,---.---~

~ -~ -~ ~ -~ -~ -~ -~ -~ -~ -~o/ -~ -~~~ -~ -~~~ -~ -~-~ -~-~~~ ~ q ~ 0 · 0 · 0· 0 · 0 · 0 · ~ - ~ - 0 · 0 · 0· 0· 0 0 · 0· 0 · 0 · ~- 0 · 0· 0 · 0 0 0 · 0 · 0 · 0 · 0 · 0 0 · Hora del día

Gráfica 5.10. 20 de Septiembre del 2000.

En la gráfica 5.1 O se observa el comportamiento del servidor de correo durante una hora de operación del día 20 de Septiembre del año 2000. En la gráfica observamos el comportamiento del servidor de correo de las 11 de la mañana a las 12 de la tarde del día 20 de septiembre del año 2000.

Observe que aproximadamente a las 11 :46 horas el servicio se ve degradado por 4 minutos. Durante la degradación del servicio el servidor no responde a las nuevas sesiones y empieza a eliminar las sesiones activas. Cuando se restablece el servicio inmediatamente empiezan a verse nuevas sesiones y continúa el servicio de manera normal. En este caso el servicio fue activado automáticamente por nuestro sistema de monitoreo, utilizando un procedimiento de la base de conocimientos. Nuestro sistema se activó para que revisara automáticamente el servicio de correo cada 5 minutos. Si se observa en la gráfica 5 .1 O el servicio de correo se restablece a partir de las 11 :50, momento en el que nuestro sistema aplica un procedimiento para restablecerlo.

A partir de que nuestro sistema de monitoreo comenzó a monitorear el servicio de correo, este ha mejorado. Por un lado, el servicio de correo presentó menos fallas y por otro lado nuestro sistema al detectar fallas las corrigió inmediatamente. Se puede observar en la gráfica 5 .11 que ya no se presentan interrupciones del servicio para el día 22 de septiembre del 2000.

49

(/) CI) e:

Correo personal 22 Sep http

A HTIP • • • • • S E HTIP 1

.S! 60 +-------.------...-(/) CI)

"'

20

o O) co f',. (.0 l!) '<:!" ('I') N ..... o O) co f',. (.0 l!) '<:!" ('I') N ..... o O) co f',. (.0 l!) '<:!" ('I') N ..... o o "! l!) "! l!) "! l!) "! ~ "! l!) ..... ~ ..... ~ ..... ~ ..... ~ ..... ~ o ('I') o ('I') '? ('I') o ('I') o ('I')

¡;..: f',. f',. co co O) O) o o ..... ..... N N ('I') ('I') '<:!" '<:!" l!) l!) (.0 (.0 ¡;..: ¡;..: co co O) O) o o ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... N N N N

Hora del día

Gráfica 5 .11. 22 de Septiembre del 2000.

La gráfica 5 .11 presenta el número de sesiones vía web que se presentaron el día 22 de septiembre del 2000 de las 7:00 a las 22:00 horas. Este es un comportamiento normal del servicio y no se presentan fallas. El sistema de monitoreo experto sólo reporta que el servicio está operando de forma normal.

Este segundo caso no es tan impresionante como el primer caso, pero de cualquier forma hubo fallas que requirieron de intervención, tanto humanas como de nuestro sistema de monitoreo. El sistema de monitoreo experto mejoró en ambos casos el desempeño del servicio dado que las fallas duraron menos tiempo que cuando no esta siendo monitoreado por nuestro sistema.

50

O) l!)

..... N

5.3 CONCLUSIONES

Como se observó en los casos de este capítulo, el sistema de monitoreo experto tiene un buen desempeño ya que se utiliza el mismo procedimiento que realiza el administrador para restablecer los servicios en caso de fallas. Por ejemplo, si el administrador tiene que revisar el sistema conectándose al equipo y revisando los puertos de comunicación, esto puede hacerlo nuestro sistema de monitoreo, de la misma forma que lo haría un operador.

La ventaja es que nuestro sistema de monitoreo detecta inmediatamente algún problema con los servicios monitoreados a diferencia que lo haría una persona, que no está todo el tiempo revisando su sistema de cómputo.

El objetivo de nuestro sistema no es resolver el problema de las fallas del serv1c10, smo minimizar el tiempo que duran estas fallas al restablecerlo nuevamente de forma inmediata.

51

6 TRABAJO A FUTURO

El sistema de monitoreo y control ha estado operando por más de seis meses y sólo se ha probado con algunas reglas. Es necesario continuar su desarrollo ya que en estos momentos es apenas un prototipo.

Para administradores de equipos UNIX, esta herramienta puede usarse no sólo para tareas de monitoreo sino que puede realizar tareas cotidianas como instalaciones de software, alta de cuentas, mantenimiento, etc.

Por ejemplo: desde una interfaz de web se puede hacer que el sistema cree cuentas de forma automática, o que revise el estado de los servidores y despliegue la información de inmediato, o que instale software, etc.

En conclusión esta herramienta puede utilizarse para muchas aplicaciones y no sólo con servidores UNIX ó Windows sino con equipo de red y similares. Todo lo que necesita es una forma de poder realizar una sesión con el equipo administrado.

Por estas razones es necesario continuar con el desarrollo de nuestra herramienta para que pueda implementarse, no solamente en el Campus Estado de México del Sistema Tecnológico de Monterrey, sino en cualquier sistema de cómputo que tenga cualquier institución o empresa.

A continuación presentamos los módulos que pueden ser mejorados en algunos aspectos.

52

6.1 MÓDULO EJECUTOR

Cuando pusimos en operación al módulo ejecutor, surgió la necesidad, en algunos procedimientos, de incluir más información en las reglas, de forma que se definieran comandos que sean exclusivos del ejecutor, indicándole que haga pausas, que ejecute alguna acción en caso de que no encuentre una regla para continuar con el procedimiento, etc. La operación actual del ejecutor cuando no existe una regla es enviar un correo al usuario para que este intervenga. Una propuesta es que el ejecutor ejecute cierta acción o cierto programa cuando no encuentre una regla para continuar, por ejemplo: espera, vuelve a comenzar, intenta nuevamente, corre un programa, etc. Esas operaciones no pueden ejecutarse con las reglas que están definidas actualmente, por lo que sería necesario incluir algunas reglas especiales que le indicaran al ejecutor qué hacer en esos casos.

También surge la inquietud de trabajar en un ejecutor que, además de avisar cuando no encuentre una regla, también dé sugerencias de cómo solucionar el problema. Una idea que podría explorarse para resolver este problema sería utilizar una red neuronal. Si se entrena a la red neuronal con las reglas que se tienen de la base de conocimientos, podríamos generalizar las respuestas de forma que cuando el ejecutor no encuentre la regla para poder continuar con el procedimiento entonces determine que regla utilizar de las que ya se han ingresado anteriormente.

Esto puede ser peligroso si el proceso es delicado, dado que la respuesta o regla que aplique el ejecutor puede no se,r la correcta y hasta dañar el sistema. Por eso se limitaría a simplemente "sugerir" soluciones al administrador cuando esté ingresando las reglas necesarias para continuar con la operación.

6.2 BASE DE CONOCIMIENTOS

Se ha visto en muchos casos que las reglas se pueden repetir, es decir que hay varios hechos en diferentes reglas que conducen a la misma respuesta.

(positivo)=> ( 7exit<-><->closed<->Fin de la sesión<-><->20f-)

(negativo)=> ( 7exit<-><->closed<->Fin de la sesión<-><->20f-)

(closed) => ( 7FIN<->FIN<->FIN<->FIN<-><->f-)

Figura 6.1 Base de conocimientos

En la figura 6.1 se pueden observar dos reglas que tienen el mismo resultado (positivo) y (negativo) o sea que no importa si el resultado es uno u otro se tiene que ejecutar el mismo

53

comando. En este caso podemos observar que se trata de una disyunción. La máquina de inferencia de CLIPS puede trabajar con conjunciones y disyunciones, además de las inferencias con las que se ha trabajado.

a -+e

avb-+c

aAb-+c

En este caso las dos reglas de la figura 6.1 pueden rescribirse de la siguiente forma:

(positivo) v (negativo)=> ( 7exit<-><->closed<->Fin de la sesión<-><->20~)

( closed) => ( 7 FIN<->FIN<->FIN<->FIN<-><->~ )

Figura 6.2 Reglas de la base de conocimientos

Para nosotros es sencillo determinar qué reglas son las que tienen la misma respuesta para que podamos escribir nuevamente la regla en forma de disyunción. Pero el sistema tiene que lograr este proceso.

6.3 MÓDULO ALIMENTADOR

Una limitante que tiene el alimentador es que sólo puede trabajar con una secuencia por sesión. Cuando el administrador está generando las reglas, estas sólo pueden tener una terminación y no pueden tener opciones en cuanto a patrones de búsqueda. Esto se debe a la interacción que se tiene con el administrador, ya que se está registrando un procedimiento paso a paso. El administrador no puede, por lo tanto, ingresar opciones para mejorar la calidad del procedimiento, al momento de generar las reglas con el alimentador.

Suponga que desea revisar un archivo de bitácoras para conocer el estado en que se encuentra un servicio. Este archivo puede contener historial del proceso y varios estados como, por ejemplo: "Normal", "Critico", "Fatal", etc. Si desea que las reglas que está diseñando incluyan toda la gama de estados en los que se puede encontrar este servicio, necesitaría hacer varias sesiones con el alimentador y "cazar" todos los estados para poder incluirlos en su diseño de reglas.

Es claro notar que tomaría mucho tiempo poder encontrar todos los patrones de búsqueda necesarios para completar las reglas de un buen monitoreo, sobre todo si no se conocen estos patrones. En todo caso el ejecutor le indicaría que es necesaria su intervención para aplicar una nueva regla para un nuevo patrón. Sin embargo si el alimentador pudiera realizar simulaciones de una sesión con el proceso, sería sencillo poder construir todas las reglas para su buen funcionamiento, ya que en esta simulación podemos incluir todos los estados que presente el sistema que deseamos monitorear.

54

6.4 SEGURIDAD

Existe una inquietud en cuanto a la seguridad que ofrece nuestro sistema de monitoreo. Todo depende de cómo se diseñe el procedimiento de monitoreo. Por ejemplo, si en una regla se indica ejecutar un telnet para abrir una sesión con el sistema monitoreado, este método por sí solo presenta un problema de seguridad, dado que se manejan contraseñas que pueden ser vistas por un intruso en la red. En lugar de ejecutar el comando telnet se podría realizar la sesión con un comando más seguro, por ejemplo, ssh1 .

Otro problema es el manejo de contraseñas en la base de conocimientos. Si se requiere que el procedimiento de monitoreo corra de forma automática, es necesario guardar las contraseñas en la base de conocimientos o en algún sistema de encriptación. Si las contraseñas se guardan en la base de conocimientos estas pueden ser vistas con cualquier editor de texto. Por el contrario si se guardan en un sistema de encriptación de cualquier forma hay que proporcionar una contraseña para poder obtener las contraseñas que se usaran en el procedimiento.

El objetivo de nuestro sistema es que revise un sistema de cómputo de fomia automática. Una solución que proponemos para solucionar el problema de las contraseñas, es almacenar éstas en un sistema de encriptación y que al correr nuestro sistema de monitoreo se le pida una contraseña al usuario para iniciar el monitoreo. Una vez más, esto depende de cómo estén constituidas las reglas del procedimiento a aplicar, ya que nuestro sistema solo interpreta lo que en las reglas esté definido y si se requiere que revise un sistema de cómputo constantemente es necesario poner el sistema en un ciclo infinito.

6.5 CONCLUSIONES

El sistema de Monitoreo y Control puede estar operando en cualquier sistema de cómputo. Es importante observar que un sistema de esta magnitud no siempre abarca todas las necesidades que requiere cierto proceso o tarea, por lo que es necesario probarlo en diversos escenarios para que pueda ejecutarse de forma eficiente en los procesos que van a ser monitoreados y controlados. Es por esta razón que el sistema de monitoreo y control requiere de constante mantenimiento y desarrollo para solventar los problemas de diseño que se vayan presentando, así como las nuevas mejoras que se le vayan añadiendo, como sucede con la mayoría de software, sea privado o comercial.

I SSH: Secure Shell

55

7 CONCLUSIONES

La operación de un servicio de cómputo es sin duda un punto clave de cualquier empresa, sobre todo en estos tiempos. Es de vital importancia que este servicio se encuentre en la mayor parte del tiempo.

Como se pudo apreciar, no es posible que un sistema opere todo el tiempo sin falla alguna, por lo que es indispensable que el servicio cuente con una supervisión adecuada y se ejecuten acciones para poder mantenerlo en operación continua.

Con la ayuda de nuestro sistema de monitoreo y control se pudieron solucionar algunos problemas de supervisión, como el caso del servidor de Lotus Notes. Como se ha comentado nuestro sistema es un prototipo y requiere que se continúe su desarrollo para que pueda operar en la mayoría de los casos en cualquier servicio de cómputo.

7.1 SISTEMA DE MONITOREO EXPERTO APLICADO A SISTEMAS DE CÓMPUTO

Los resultados presentados en el capítulo 5 muestran que la utilización de nuestro sistema es útil para la supervisión de servicios de cómputo de vital importancia como el servicio de Lotus Notes del Campus Estado de México del Tecnológico de Monterrey. Es importante aclarar que no se solucionó el problema de las fallas ya que ese no es el propósito de este proyecto. El propósito de nuestro sistema es resolver el problema del monitoreo continuo y el retorno del servicio a su operación normal, cuando este se encuentre en un estado crítico.

56

7.2 UTILIZACIÓN DE EXPECT

La utilización de Expect en este prototipo es fundamental para resolver los problemas de interactividad que presentan algunos servicios, como la consola de un servidor de Lotus Notes. Sobre todo de realizar las funciones de monitoreo en la fonna como lo hace el administrador.

Un administrador de sistemas de cómputo no solo administra un equipo de cómputo sino que en ocasiones le toca administrar varios equipos. Esto complica un poco más su labor ya que tiene que revisar o monitorear varios servicios en lugar de uno solo. Para hacerlo se ayuda de sesiones remotas en una consola para poder revisar todos sus servicios. Expect ayuda en gran medida dado que simula las sesiones remotas que realiza el administrador.

7.3 UTILIZACIÓN DE UN SISTEMA EXPERTO

El propósito de utilizar un sistema experto en nuestro sistema es pennitir que el conocimiento del administrador de un sistema de cómputo se vea representado en reglas que puedan ser interpretadas y razonadas por una máquina de inferencias, para pennitir a otros administradores, que cuenten con nuestro sistema, aplicar las reglas orientadas a un servicio de fonna transparente y fácil de entender que otra clase de programas o scripts que realicen la misma operación.

De esta fonna podemos compartir no sólo los programas para la supervisión de sistemas de cómputo y ejecución de tareas de administración, sino el conocimiento de una fonna más sencilla para los mismos administradores. Ellos en lugar de estar analizando código para ajustarlo a sus propios sistemas estarán analizando conocimiento y experiencia de otros administradores.

7.4 PERSPECTIVAS

Nuestro sistema puede dar ventaja a los administradores de servicios de cómputo, ya que podrán confiar en una herramienta que refleje el conocimiento que ellos han adquirido con la experiencia en sus labores de monitoreo y en tareas constantes de administración. Esto puede ayudarles tener más tiempo para planificar, analizar, y mejorar sus servicios dado que la tarea de monitoreo se puede llevar a cabo de manera automática. Además de mejorar sus propios conocimientos con capacitación e investigación por cuenta propia. Esto último con el propósito de mejorar los servicios de cómputo que ellos mismos administran.

Una ventaja adicional, es que esto puede llevar a una mejor administración del conocimiento. Es como tener la documentación de los procesos en operación. En lugar de tener el procedimiento en papel, este puede estar en una base de conocimientos, no sólo como conocimiento inactivo, sino como procedimientos activos que ayudan a las labores de administración de los sistemas de cómputo.

57

8 REFERENCIAS Y BIBLIOGRAFÍA

[1] Libes, D., Exploring Expect: A Tc/-Based too/kit for automating interactive programs. O'Reilly, 1995. ISBN 1-56592-090-2 QA76.76.T49 L5

[2] Giarratano, J., Expert Systems, Principies and programming. Intemational Thomson Publishing, 1998. ISBN 0-534-95053-1 QA 76.76.E95 G53

[3] Giarratano, J., CLIPS User Guide. Versión 6.05

[4] Giarratano, J., CLIPS Basic Programming. Versió 6.05

[5] Jackson, P., Introduction to Expert Systems. Addison-Wesley, 1990. ISBN 0-201-17578-9 QA76.75.E95 J33

58

[6] Horman, P., Creating Expert Systems for Business and Industry. Wiley, 1990. ISBN 0-471-61495-5 HF5548.2 H37

[7] Turban, E., Decision Support and Expert Systems, Management support systems. Cuarta Edición, Prentice Hall, 1997. ISBN 0-02-421701-8 HD30.2.T87

[8] Lucas, P., Principies of Expert Systems. Addison Wesley, 1990. ISBN 2-201-41640-9 QA 76. 76.E95L83

[9] Kline, P., Designing Expert Systems. Wiley, 1989. ISBN 0-471-50484-X QA 76. 76.E95K54

59