universidad de guayaquil - ugrepositorio.ug.edu.ec/bitstream/redug/6863/1/tesis... · el fallo en...

UNIVERSIDAD DE GUAYAQUIL

Facultad de Ciencias Matemáticas y Físicas

Carrera de Ingeniería en Sistemas Computacionales

“Aplicación para el Monitoreo de Servicios en Equipos Linux que proporcione el control y

administración de servidores en una red optimizando los recursos y mejorando los servicios.”

PROYECTO DE GRADO

Previo la Obtención del Titulo de:

INGENIERO EN SISTEMAS COMPUTACIONALES

Autor(es):

CHICA BERMUDEZ JOSE LUIS. VELEZ FERNANDEZ DARWIN. VILLAFUERTE NAVARRO FREDDY

GUAYAQUIL-ECUADOR

AÑO: 2005

AGRADECIMIENTO

A Dios por habernos concedido la vida y

el apoyo en los momentos más difíciles de

nuestra carrera.

A nuestros padres y demás familiares por

su preocupación y paciencia.

A nuestros amigos, por apoyarnos cada día.

A nuestro director de tesis, El Ing. Carlos

Carranza por compartir sus conocimientos

y ayudarnos en el desarrollo del proyecto

A toda la comunidad del software libre, por

las fantásticas herramientas que ponen a

disposición de la humanidad.

A todas las comunidades de foros que

encontramos en Internet, por prestar su

ayuda desinteresada a quién la necesite.

DEDICATORIA

JOSE LUIS CHICA: A mis padres

que son lo más maravilloso que me

ha regalado Dios. A mi esposa y

demás familiares que se sacrificaron

por mi a lo largo de mi carrera.

FREDDY VILLAFUERTE: A Dios que

ha iluminado mi vida. A mis padres

quienes con sus consejos y

comprensión han encaminado mis

pasos para ser un hombre de bien.

DARWIN VELEZ: A Dios por darme

la fortaleza para culminar este

proyecto y a mis padre por el apoyo

moral durante toda la carrera.

TRIBUNAL DE GRADUACION

Ing. Abel Alarcón Delegado de la CCG

Ing. Carlos Carranza Abg. Juan Chávez Profesor guía Secretario

Ing. José Luis Peralta Miembro del tribunal

DECLARACION EXPRESA

“La autoría de la tesis de grado nos corresponde

exclusivamente, y el patrimonio intelectual del mismo a la

Universidad de Guayaquil”

RESUMEN

El presente proyecto esta orientado al monitoreo de servidores y de

numerosos parámetros de una red en equipos Linux, controlando la

integridad y estado de los mismos. Proporcionando a los administradores de

sistemas de una herramienta altamente ampliable y personalizable, que

fácilmente pueda ser extendida para alcanzar los requisitos de cualquier

organización. Se ha optado por un arquitectura cliente/servidor en la que los

equipos a administrar tendrán instalada una aplicación cliente que se

encargará de monitorizar diversos parámetros, y una aplicación servidor que

es la encargada de recolectar estos parámetros y mostrarlos resultados de

manera gráfica.

El manejo del sistema se realiza desde interfaces Web. La persona que lo

maneja, es un usuario administrador. El motivo fundamental que nos lleva a

realizar este proyecto, es contribuir con los administradores y usuarios en el

manejo y control de la infraestructura tecnológica aplicable a pequeñas

organizaciones con pocos servidores y grandes compañías con una gran

cantidad de servidores.

Introducción

La administración de recursos de red, ha generado una enorme

responsabilidad para los administradores de centros de cómputo de las

empresas e instituciones de gran tamaño desde hace décadas. El problema

se acentuó más aún en los 90, con la fuerte descentralización que sufrieron

las infraestructuras informáticas gracias al crecimiento imparable de los PC.

En los últimos años la evolución de las tecnologías web y el procesamiento

distribuido ha llevado a centralizar de nuevo algunos sistemas; huyendo así

de la insostenible tela de araña de recursos infrautilizados en la que se

estaban convirtiendo las empresas. Pese a ello, la cantidad de recursos

distribuidos por las empresas sigue y seguirá siendo ingente, pues los PC

cliente están más que arraigados en el mundo empresarial y son muchas las

aplicaciones que precisan de una alta capacidad de procesamiento en el

cliente para realizar su labor.

Este problema no pertenece exclusivamente a las grandes corporaciones,

incluso en las pequeñas empresas, la administración de redes puede llegar a

ser todo un problema. El problema se agrava todavía más cuando el

administrador de redes tiene que lidiar con una red de sistemas

heterogéneos, lo que se está convirtiendo en algo muy habitual, ya que no es

difícil encontrar empresas, grandes y pequeñas, donde Linux, Windows,

UNIX y otros, conviven de forma amistosa, cada uno con su especialidad.

Por ello, creemos que surge la necesidad de disponer de sistemas de gestión

y monitorización de recursos informáticos. Sistemas que pongan a

disposición de las empresas e instituciones las características y capacidades

necesarias para llevar a cabo todas las tareas de administración de redes

que necesiten.

CAPITULO 1

1. APLICACIÓN PARA EL MONITOREO DE SERVICIOS EN EQUIPOS LINUX

1.1. Antecedentes

Actualmente, el manejo de la información de modo eficiente constituye

una de las principales preocupaciones dentro de cualquier organización,

por lo que se hace necesario manejar y emplear con mucho criterio, ya

que de ello podría depender en gran medida el éxito o fracaso de la

misma.

Las empresas e instituciones deben garantizar que sus recursos sean

utilizados con fines eminentemente productivos, por lo cual el manejo de

una red se ha convertido en un trabajo complejo, y resulta necesario

contar con herramientas de soporte que permitan conocer el estado de

los servidores, aplicaciones en una red y cualquier información que

permita optimizar recursos y mejorar los servicios.

Este proyecto se apoya en una herramienta Open Source llamada zabbix

aplicando el paradigma cliente /servidor, la misma que hemos utilizado

como una guía mejorando su ambiente de trabajo y con la opción de

poder administrarla desde cualquier sitio conectado a la red donde se

haya el sistema.

1.2. Situación conflicto

Para llevar a cabo el intercambio de información de manera exitosa se

han desarrollado diferentes reglas de comunicación, a las que conocemos

como protocolos, así como también al conjunto de estos llamados

arquitectura, entre las que resalta la TCP/IP que es la base de la gran red

de redes Internet.

Es importante llevar un rastreo de los diferentes procesos que se

ejecutan en los servidores, ya sean estos procesos de usuarios o tareas

propias del sistema Operativo. Además de definir normas y políticas a

seguir en caso de que el rendimiento del servidor disminuya. Esto hace al

sistema muy útil para la planificación sobre la capacidad de los

servidores.

1.3. Causas

La comunicación de datos se ha convertido en parte fundamental del

desarrollo tecnológico y de las actividades diarias de la fuerza laboral, en

consideración las siguientes causas en la elaboración de nuestro

proyecto:

La ausencia en nuestro medio de una herramienta de bajo costo,

que controle el estado y la integridad de los servidores.

Desconocer el estado de los servidores e información que permita

optimizar recurso y mejorar el servicio a los usuarios.

Sobrecarga de trabajo en los servidores, debido a la falta de

información.

Falta de medidas de precaución en la falla de servidores por parte

de los administradores de red.

1.4. Consecuencias

El rendimiento de los servidores disminuye, opacando el

desempeño de la red.

La falta de un esquema global de escalabilidad, de aquellos

servidores obsoletos.

El fallo en un servidor provocará una interrupción en toda la red.

Los administradores no podrán tomar decisiones que eviten un

fallo completo en la red.

1.5. Misión

La misión de este proyecto es contribuir, mediante una

herramienta de Administración, al manejo y control de los

servidores en una red.

Permitir al administrador el mantenimiento y configuración de toda

la Tecnología de información de la que dispone.

1.6. Visión

Proveer mecanismos capaces de ofrecer información sobre el uso

que se esta haciendo de los recursos. Información vital para

actualizar los recursos de los que dispone la organización.

La Visualización mediante graficas y tablas estadísticas la

situación real de la Tecnología de Información de la organización.

1.7. Objetivos

1.7.1. Objetivo general

El objetivo primordial es el de proveer un sistema capaz de mostrar el

estado de los servidores en una red.

Reflejando una administración eficiente y dando lugar a toma de

decisiones de manera óptima.

1.7.2. Objetivos específicos

Mejorar el proceso actual y facilitar la labor del Administrador

de red.

Aumentar la confiabilidad, solucionando rápidamente

problemas en los servidores.

Generar la información necesaria para cualquier cambio

futuro en cuanto a servidores.

Crear un entorno amigable para los usuarios.

Hacer un mejor uso de los recursos existente.

Obtener reportes consolidados del estado de los servidores.

1.8. Alcance

El sistema deberá ser capaz de monitorear el desempeño de servidores y

aplicaciones, sus tareas serán:

La carga de trabajo que tiene el procesador.

Número de procesos ejecutándose.

Actividad en disco duro.

Estado de la memoria virtual (Memoria SWAP).

Disponibilidad de memoria.

El sistema proporciona al Administrador información oportuna sobre el

desempeño de los servidores.

Tener Monitoreo de desempeño es bueno, pero es casi inútil sin un

mecanismo de notificación que identifique los posibles problemas que

ocurran en determinado lapso de tiempo. Por lo que el Sistema de

Monitoreo va ha contar con ALERTAS que serán enviadas por e-mail a

cualquier dirección definida por el Administrador.

El Sistema puede ser fácilmente usado para el monitoreo de integridad de

servidores. Todos los archivos de configuración críticos, binarios, kernel,

script y páginas HTML de servidores Web pueden ser monitoreados por el

sistema de esta forma el administrador puede estar sobre aviso a las

modificaciones efectuados sobre estos archivos. Todos los valores de los

parámetros monitoreados son almacenados en una Base De Datos Los

datos recolectados pueden ser usados después por el administrador para

futuras evaluaciones de los servidores.

1.8.1. Principales servicios a monitorear

TELNET: Aplicación que permite emular un terminal

remoto en el servidor que se establece la conexión,

haciendo uso de un usuario válido.

De esta manera el usuario puede ejecutar comandos y

aplicaciones en el servidor de manera remota como si

estuviese sentado frente al computador. El usuario tendrá

acceso a los comandos y directorios definidos por el

administrador del servidor. Hace uso del puerto 25.

FTP: Protocolo utilizado para la transmisión de archivos

entre equipos. Para poder descargar o colocar archivos en

el servidor FTP, es necesario poseer una cuenta de

usuario autorizado a este servicio.

En este tipo de transferencia de archivos, los datos no

viajan encriptados. Utiliza los puertos 20 para la

transmisión de datos y 21 para las tareas de control en el

envió o carga de datos.

SSH: Al igual que el telnet permite la emulación de una

terminal remota en el servidor al cual se conecta, la

diferencia es que en el SSH la información se transmite

encriptada, tanto la conexión del cliente como del servidor

son autentificadas usando un certificado digital. SSH

utiliza el puerto 22.

SENDMAIL: Es el agente de transporte de correo más

común de Internet (en los sistemas UNIX). Aunque actúa

principalmente como MTA, también puede ser usado

como MUA (aunque no posee interfaz de usuario) utiliza

el puerto 25.

APACHE: Es un servicio que levanta al servidor de

páginas Web, para su publicación. Dependiendo de los

módulos que posea permitirá o no la visualización de

páginas en código php, php3, etc.; esto depende de la

configuración que adopte. Apache escucha las peticiones

a menos que se especifique otro puerto, por le número 80.

1.9. Identificación de alternativas de solución

EL SOTFWARE PARA MONITOREO DE SERVICIOS EN EQUIPOS

LINUX es soporte para el administrador en el control y manejo de la red,

ya que permite una reacción inmediata ante cualquier problema en los

servidores.

Ofrece un excelente nivel de reportes y características de visualización

de datos, basados en información almacenada. Contribuyendo en la

planificación sobre la capacidad de los servidores, proporcionando un

mejor servicio y optimizando recursos.

1.9.1. Alternativas.

1.9.1.1. Alternativa “A”.

RECURSOS EXISTENTES:

CARACTERISTICAS PCA “CLIENTE”

PROCESADOR Intel Pentium III

MEMORIA RAM 256 MB.

CAPACIDAD DE DISCO DURO 40 GB.

ESPACIO DISPONIBLE 33 GB.

AMPLITUD DEL BUS 32 BITS

FRECUENCIA DE RELOJ 733 MHZ.

MONITOR SVGA DE 17”

SISTEMA OPERATIVO WINDOWS XP

OFFICE XP

INTERNET EXPLORER Navegador para Internet

L&POWER TRANSLATOR Traductor

WINZIP Empaquetador versión 8.1

LENGUAJE C Lenguaje de programación C++

PHP Versión 4.0

APACHE SERVER Servicio de paginas Web

MYSQL Base de Datos

CARACTERISTICAS PCB “SERVIDOR”

PROCESADOR Intel Pentium IV

MEMORIA RAM 256 MB.




FRECUENCIA DE RELOJ 1.7 GHZ.


SISTEMA OPERATIVO LINUX

OFFICE XP



WINZIP Empaquetador versión 8.1


PHP Versión 4.0


MYSQL Base de Datos

Conociendo los recursos que tenemos a disposición y analizando

la capacidad de cada equipo, recomendamos utilizar las

aplicaciones existentes para la construcción del Sistema de

MONITOREO DE SERVICIOS EN EQUIPOS LINUX utilizando

como herramientas C++, que es lenguajes de programación que

combina elementos de alto nivel con la funcionalidad de lenguaje

ensamblador permitiendo agregar como una de sus características

la portabilidad. Además PHP herramienta utilizada para la

creación de paginas Web interactivas mostrando una interfaz

dinámica, estas herramientas son gratuitas y útiles para mejorar la

calidad de trabajo de los administradores de redes y para

minimizar las fallas de los servidores. MYSQL motor de base de

datos OPEN SOURCE, base de dato veloz y administrada a nivel

de programación.

Con esto se logrará que los recursos de los que disponemos sean

utilizados, sin incurrir en ningún gasto adicional. Sin dejar de

recordar que los equipos actualmente funcionan de manera

independiente y para que el proyecto funcione habrá que

estructurar una red, generando costos de los que actualmente no

disponemos.

Por lo tanto esta alternativa se considera como provisional.

1.9.1.2. Alternativa “b”.

Utilizar los recursos que facilite la Universidad a través de sus

laboratorios, y de manera independiente los recursos de que

dispone el grupo de tesis para la elaboración del proyecto.

Recomendamos que para la implementación y pruebas del

SISTEMA DE MONITOREO DE SERVICIOS EN EQUIPOS

LINUX, se conceda la autorización necesaria para el uso de una

red con tecnología Lan:

Computadores clientes.

1 Hub o switch.

Conexiones de red

Es decir la infraestructura necesaria para culminar con éxito este

proyecto.

1.10. Aceptación de la propuesta.

Se hizo una presentación del anteproyecto, ante la “COMISION DE

CURSOS DE GRADUACION” dando a conocer las características de

nuestro proyectos y las recomendaciones necesarias para el mismo. En

base al estudio realizado se aprobó el tema, en relación con la

ALTERNATIVA “B”.

1.11. Recursos.

Se utilizarán los recursos físicos que facilite la Universidad por intermedio

de sus laboratorios, e independientemente los recursos de los que

dispongan los miembro de tesis.

1.11.1. Recursos hardware.

El equipo a usarse en el desarrollo de nuestro proyecto se detalla a

continuación:

El equipo ha usarse para la implementación y prueba del sistema se

describe a continuación

CARACTERISTICAS PC “A” PC “B”

PROCESADOR INTEL PENTIUM III INTEL PENTIUM IV

MAINBOARD PC CHIPS 133MHZ INTEL 133 MHZ

MEMORIA RAM 256 MB 256 MB.

CAPACIDAD DE DISCO DURO 40 GB. 80 GB.

AMPLITUD DEL BUS 32 BITS 32 BITS

MONITOR SVGA DE 17” SVGA DE 17”

FRECUENCIA DEL BUS 733 MHZ 1.7 GHZ

Red LAN con topología tipo estrella:

1 Servidor.


1 Hub o Switch.

Conexiones de red.

Es decir la tecnología necesaria para un funcionamiento óptimo de

nuestra aplicación.

1.11.2. Recurso humano.

Las personas que van ha encargarse del desarrollo del sistema son

los egresados:

José Luis Chica Bermúdez

Darwin Vélez Fernández

Freddy Villafuerte Navarro

Guiados por un director de proyecto

1.11.3. Recurso software.


E

l

s

o

f

t

w

a

r

e necesario para el desarrollo del sistema y que se encuentra

instalado en los equipos de los integrantes del proyecto es:

SISTEMA OPERATIVO

LINUX RED HAT 9.0 LINUX RED HAT 9.0

OFFICE XP XP

EXPLORADOR WEB INTERNET EXPLORER

INTERNET EXPLORER

LENGUAJE DE PROGRAMACION

C C++ PHP

C C++ PHP

SERVIDOR WEB APACHE SERVER APACHE SERVER

BASE DE DATOS MySQL MySQL

TRADUCTOR L&POWER TRANSLATOR

L&POWER TRANSLATOR

GESTOR DE PROYECTOS

PROJECT 2000 PROJECT 2000

EMPAQUETADOR WINZIP 8.1 WINZIP 8.1

1.12. Presupuesto.

1.12.1. Costo hardware.

El Costo total del Hardware es $ 0,00 debido a que se utilizará el

recurso existente perteneciente a los miembros del grupo de tesis.

DESCRIPCIÓN VALOR TOTAL

PC ”A” CLIENTE 0,00

PC ”B” CLIENTE 0,00

TECNOLOGIA LAN (LABORATORIO DEL CISC) 0,00

COSTO TOTAL $ 0,00

1.12.2. Costo software.

DESCRIPCIÓN VALOR TOTAL

Sistema Operativo Linux Distribución Red Hat 9.0 0,00

Lenguaje De Programación C, C++. 0,00

Web Server Apache. 0,00

Base De Datos MySQL 0,00

Php Como Modulo De MySQL 0,00

Navegador Web. 0,00

COSTO TOTAL $ 0,00

El Costo total del Software es $ 0,00 por cuanto se han considerado

para la elaboración de este proyecto herramientas de libre

distribución.

1.13. Plan del proyecto y cronograma. (Anexo 1)

1.14. Metodología.

Las actividades que van a efectuarse para alcanzar la culminación del

proyecto son:

1. Investigación Preliminar

1.1. Consultas Bibliográficas.

1.2. Consultas por Internet.

1.3. Consultas a Profesionales.

1.4. Ámbito de estudio.

1.5. Recursos de hardware y software disponible.

1.6. Revisión de documentación existente.

2. Análisis

2.1. Levantamiento de la información.

2.2. Análisis de los requerimientos.

2.2.1 Análisis de recursos humanos.

2.2.2 Análisis de recursos de hardware y software.

2.3 Estudio de factibilidad.

2.3.1 Análisis beneficio costo.

2.3.1.1 Factibilidad técnica.

2.3.1.2 Factibilidad económica.

2.3.1.3 Factibilidad operacional.

2.4 Diccionario de datos.

2.5 Diagrama entidad-relación.

2.6 Diagrama de Especificación de Objetos.

2.7 Diagrama de Flujo de Datos.

3. Diseño

3.1. Arquitectura del Sistema.

3.2. Limites de la información y el entorno del sistema.

3.2. Interfaz con el usuario

3.3. Procedimientos

3.3.1. Entradas

3.3.2. Salidas

3.3.3. Archivos

3.4. Interacción con la base de datos

3.4.1. Modelo Lógico

3.4.2. Modelo Físico

3.4.3. Instalación del Software

3.4.4. Creación de la base

3.4.5. Creación de la estructura de la base

4. Desarrollo, Implementación y Prueba

4.1. Desarrollo de Módulo

4.2. Implementación

4.3. Parametrización

4.4. Pruebas y evaluación

5. Documentación y manuales

6. Presentación

CAPITULO 2

2. ANALISIS

En este capitulo nos centraremos en llevar a cabo la fase de análisis de todo

el SISTEMA DE MONITOREO DE SERVICIOS EN EQUIPOS LINUX,

comenzando por las partes más generales del mismo, como puede ser la

especificación de requerimientos , para poco a poco ir centrándonos en

desarrollar en forma gradual los componentes de nuestro sistema.

2.1. Levantamiento de la información.

Este proceso se llevó a cabo utilizando dos formas de levantamiento de

información: las entrevistas y la revisión de documentos. En relación con

las entrevistas, éstas fueron preparadas para luego ser llevadas a cabo

con el personal que de alguna forma tiene inherencia con los procesos de

administración de redes.

Paralelamente se realizó la revisión e investigación de aquellos

aplicaciones que son utilizadas en el monitoreo de redes. Conociendo las

necesidades del cliente, y así poder mejorar la productividad y disminuir la

vulnerabilidad de la red a través del diseño e Implementación de la

seguridad.

2.2. Análisis de los requerimientos

2.2.1. Análisis de recursos humanos.

La persona que van a tener acceso al sistema de “Monitoreo de

Servicios en Equipos Linux”, serán usuarios, (Administrador con

privilegios distintos a los demás usuarios), que deben tener

conocimientos básicos de administración de red y de sistemas

operativos Linux.

2.2.2. Análisis de recursos de hardware y software.

Las características mínimas con las que debe cumplir nuestra

aplicación son:

Se debe considerar espacio extra en disco duro para almacenar

todos los eventos históricos en la Base de Datos. Cada proceso del

Sistema requiere una conexión al servidor de Base de Datos.

CARACTERISTICAS PC

PROCESADOR Intel 80486SX

MEMORIA RAM 64 MB.

SISTEMAS DE ARCHIVOS 32 BITS

MEMORIA VIRTUAL 32 BITS

MEMORIA CACHE 8KB.

FRECUENCIA DE CAHCE 3 MHZ




FRECUENCIA DEL BUS 12 MHZ.

SOTFWARE PC “A” CLIENTE PC “B” SERVIDOR

SISTEMA OPERATIVO WINDOWS XP WIN XP - LINUX

INTERNET EXPLORER X X

WINZIP 8.1 X X

LENGUAJE C++ X X

PHP X X

MYSQL X X

APACHE X X

2.3. Estudio de factibilidad.

El estudio de factibilidad requerido para efectos de nuestro SISTEMA DE

MONITOREO SERVICIOS EN EQUIPOS LINUX, se basa en 3 aspectos

o niveles: técnico, económico y operativo.

A continuación, evaluaremos cada una de estos aspectos en el análisis

de Beneficio Costo. Estimando el impacto financiero acumulado de lo que

queremos lograr.

2.3.1. Análisis beneficio costo.

El análisis de costo-beneficio de este proyecto es relativamente

simple. Ya que para su desarrollo se va a utilizar herramientas Open

Source alcanzando nuestros objetivos de manera económica.

2.3.1.1. Factibilidad técnica.

El proyecto es realizable desde el punto de vista técnico ya que

está a la disposición los laboratorios de la CISC, los cuales poseen

la infraestructura para la implementación y prueba del SISTEMA

DE MONITOREO SERVICIOS EN EQUIPOS LINUX.

Agregando la tecnología que posee el grupo de tesis de manera

independiente. Consideramos que es 100 % factible pues la

tecnología que se encuentra disponible es capaz de satisfacer las

peticiones.

2.3.1.2. Factibilidad económica.

Los recursos básicos a considerar son: el tiempo del equipo de

sistemas, el costo de hacer un estudio de sistemas completo, el

costo estimado de hardware y el costo estimado de software y/o

desarrolladores de software.

Cabe señalar que el costo que genera el diseño e implementación

del Software es económicamente factible, ya que las herramientas

de programación a utilizarse son de libre distribución.

RECURSO CANTIDAD TOTAL

Tiempo del equipo de sistemas 180 días laborables

Costo de estudio del sistema $100.00

$100.00

Costo estimado de hardware $0,00

Costo estimado de software $0,00

Software desarrollado Costo estimado $0,00

SUBTOTAL $0,00

TOTAL $100.00

2.3.1.3. Factibilidad operacional.

La factibilidad operacional del proyecto esta dada por los recursos

humanos disponibles para el proyecto, operación del sistema y el

uso que se le de una vez que sea instalado.

El software a desarrollarse esta calculado para proporcionar una

interfaz eficiente y accesible.

Por lo tanto se calcula que el Sistema de Monitoreo de Servicios

será utilizado en un 100%.

INDICADOR = FACTIBILIDAD TÉCNICA = 100 FACTIBILIDAD ECONOMICA 100.00

2.4. Diccionario de datos (Anexo 2)

El diccionario de datos es una gramática casi formal para describir el

contenido de los elementos de información, contiene las definiciones de

todos los datos del sistema.

A continuación mostramos el formato de nuestro diccionario de datos el

cual es anexo que se encuentra en el tomo 2 de este documento.

DE LA BASE DE DATOS

Tabla Users

Nombre: identificador

Alias: userid

Donde se usa: B. D. users

Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro ingresado.

Descripción: Número entero de 4 dígitos

2.5. Diagrama entidad-relación (Anexo 3).

Después de un estudio para el desarrollo de aplicación y los datos que

vamos procesar, nos hemos visto en la necesidad de utilizar algunas

entidades que van almacenar la información necesaria para el

funcionamiento de nuestro sistema de monitoreo, A continuación

detallaremos las entidades más importantes:

ACTIONS.- Listado de las acciones que se aplican cuando un trigger

cambia de estado.

ALARMS.- Registra el cambio de estado de los triggers, lo que

permite llevar un histórico de de estos cambios, al crear un nuevo

registro en la tabla, cada vez que un trigger cambia de estado.

ALERTS.- Contiene el listado de las acciones a tomar en caso de

que un trigger se active y el tipo de alerta enviadas a los usuarios.

CONFIG.- Contiene la definición de los parámetros globales de la

aplicación. Se especifica cual será el servidor de correo que permita

enviar las alertas a los usuarios de la aplicación cada vez que se

activen los triggers.

FUNCTIONS.- Listado de las funciones empleadas por las

expresiones a evaluar, utilizadas en los triggers.

GRAPHS.- Lista de los gráficos definidos por el usuario, de los

parámetros que desee visualizar gráficamente, entre ellos: carga del

procesador, número de procesos que se están ejecutando, número de

sesiones y el tráfico generado de los diferentes servidores

monitoreados.

GRAPHS_ITEMS.- Contiene la lista de los ítems monitoreados que

se representan en los gráficos.

HISTORY.- Histórico de los valores de los items.

HOST.- Contiene el listado de los equipos monitoreados.

ITEMS.- Guarda las definiciones de los ítems monitoreados.

MEDIA.- Mantiene el listado de los medios (correos) por los que se

notificarán las alertas a los usuarios.

RIGHTS.- Contiene la lista de los permisos asignados a los usuarios

de la aplicación.

SERVICES.- Listado de los servicios definidos por el usuario a ser

monitoreados en los diferentes servidores.

SERVICE_ALARMS.- En esta tabla se almacenan las alarmas

relacionadas a los diferentes servicios que están siendo

monitoreados.

SERVICES_LINKS.- En esta tabla están definidas las conexiones

entre los diferentes servicios.

SESSIONS.- Registro de las sesiones establecidas por los usuarios.

TRIGGERS.- Listado de los triggers, en esta tabla se almacena el

estado del trigger y la expresión que se evaluará al momento de

determinar el estado del trigger.

USERS.- Listado de los usuarios de la aplicación.

2.6. Diagrama de especificación de objetos (Anexo 4).

Diagrama entidad-relación (Anexo 3)

Diagrama de especificación de objetos (Anexo 4)

2.7. Diagramas de flujos de datos

Un diagrama de flujos de datos (DFD), es una técnica grafica que

describe el flujo de información y las transformaciones que se aplican a

los datos, conforme se mueven de la entrada a la salida.

Se puede utilizar un DFD para representar cualquier software a cualquier

nivel de abstracción.

El rectángulo se utiliza para representar una unidad

Externa.

Los procesos o transformación que se aplican a los

datos.

Flujo de los datos

La línea doble representa un almacén de información.

Cabe mencionar que el diagrama no proporciona ninguna secuencia

explícita de los procesos.

Nivel 0

DIAGRAMA DE FLUJO DE DATOS

MODULO DE INICIO

RECONECTAR USUARIO

SELECCION OPCION

DATOS DE

USUARIO VALIDACION DE USUARIO

USERS

PASSWORD

VISTO BUENO

DATOS

NOTIFICAR

ACTUALIZANDO BASE

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL MODULO DE INICIO

NOMBRE:

Modulo de Inicio

DESCRIPCION:

En este diagrama se describe todo los procesos en el cual el

administrador abre una sesión o cierra una sesión en el servidor

notificando o reconectando usuarios. Todos estos procesos deben

registrarse o actualizarse en la base de datos.

NOTAS:

El administrador puede notificar a través de una cuenta de correo

que haya sido configurada.

El administrador puede desconectarse o reconectarse a través de

un usuario y contraseña.

El usuario puede acceder al sistema desde cualquier equipo

conectado remotamente en la red.

Una vez activa la sesión el administrador o usuario podrá hacer

uso del menú de opciones, si durante 30 minutos no realiza

ninguna actividad el usuario se desconecta automáticamente.

Nivel 0


MODULO DE USUARIO

CREAR USUARIO NUEVO

SELECCION OPCION

DATOS

VERIFICAR

DATOS DE

USUARIO PASSWORD USUARIO

USERS

PASSWORD

VISTO BUENO

DATOS EDITAR

NOTIFICAR

ACTUALIZAR BASE

PASSWORD

USUARIO

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL MODULO DE USUARIO

NOMBRE:

Modulo de usuario

DESCRIPCION:

En este diagrama se describe todo los procesos que los usuarios

disponen una vez iniciada la sesión a través de nombre y una

contraseña. Indicando si desea crear un nuevo usuario, editar uno

que ya existe o configurar la notificación en el caso de una alerta.

Todos estos procesos deben registrarse o actualizarse en la base de

datos.

NOTAS:

El usuario puede ser notificado a través de una cuenta de correo

que haya sido configurada previamente.

El usuario para poder editarse debe existir.

Una vez activa la sesión el usuario podrá hacer uso del menú de

opciones, si durante 30 minutos no realiza ninguna actividad el

usuario se desconecta automáticamente.

Nivel 1


SUBMODULO CREAR UN NUEVO USUARIO

DATOS

VERIFICAR

USERS

DATOS DE USUARIO NUEVO

USUARIO

INGRESAR DATOS USUARIO

SELECCION OPCION

PASSWORD

DATOS

DATOS AGREGAR

SALIR

ACTUALIZANDO

BASE DE DATOS

PASSWORD

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO CREAR

NUEVOS USUARIOS

NOMBRE:

Submodulo crear nuevos usuarios

DESCRIPCION:

En este diagrama se describe todo los subprocesos que los usuarios


contraseña. Ingresando los datos del nuevo usuario el nombre el

apellido la descripción y la contraseña. Agregando este usuario a la

base de datos.

NOTAS:

Cuando se crea un usuario nuevo se le asigna un identificador que

lo distingue de los demás.

Nivel 1


SUBMODULO EDITAR USUARIO

RIGHTS

DATOS

VERIFICAR

USERS

DATOS DE

USUARIO EDITAR USUARIOS

NUEVO USUARIO

SELECCION OPCION

PASSWORD

VISTO BUENO

DATOS ACTUALIZAR

ELIMINAR

ACTUALIZANDO BASE DE DATOS

PASSWORD

PASSWORD

ASIGNAR PERMISOS

DATOS

VERIFICAR

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO EDITAR

USUARIO

NOMBRE:

Submodulo editar usuarios

DESCRIPCION:



contraseña. Editando los datos de los usuarios previamente

registrados. Asignado los permisos, actualizando o eliminando

usuarios. Todos estos procesos deben registrarse o actualizarse en la

base de datos.

NOTAS:

Cuando el Administrador o el usuario conectado desea editar un

usuario este debe contar con los permisos para realizar dicha

tarea.

Nivel 2


SUBMODULO ASIGNAR PERMISOS AL USUARIO

NUEVOS PERMISOS

DATOS

VERIFICAR

RIGHTS

DATOS DE

USUARIO PERMISOS USUARIO

SELECCION OPCION

PASSWORD

VISTO BUENO

DATOS ACTUALIZAR

ELIMINAR


PASSWORD

PASSWORD

PASSWORD

PASSWORD

AGREGAR RECURSOS

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO

ASIGNAR PERMISOS A LOS USUARIOS

NOMBRE:

Submodulo asignar permisos a los usuarios.

DESCRIPCION:

En este diagrama se describe todo los subprocesos que los

usuarios disponen una vez iniciada la sesión a través de

nombre y una contraseña. Asignando permisos de sólo

lectura o de lectura y escritura a un usuario administrador o un

usuario simple. Estos permisos deben ser agregados

confirmando su funcionalidad. Todos estos procesos deben


NOTAS:

Cuando un usuario dispone de permisos de solo lectura no

podrá editar ningún elemento del menú principal.

Un usuario administrador debe poseer todos los permisos

por defecto y deben ser agregados dichos permisos.

Nivel 1


SUBMODULO NOTIFICACION DE USUARIO

DATOS

VERIFICAR

MEDIA

DATOS DE

USUARIO NOTIFICAR USUARIO

NUEVA NOTIFICACION

SELECCION OPCION

PASSWORD

VISTO BUENO

DATOS ACTUALIZAR

ELIMINAR

ACTUALIZANDO

BASE DE DATOS

PASSWORD

PASSWORD

PASSWORD

PASSWORD


NOTIFICACION DE USUARIOS

NOMBRE:

Submodulo notificación de usuarios

DESCRIPCION:



contraseña. Notificando a los usuarios en caso de que alguna

actividad crítica deba ser alertada vía e-mail o a través de un script. Si

la notificación ya existe puede ser actualizada o eliminada.

NOTAS:

Cuando el Administrador o el usuario desea ser notificado debe

haber registrado una dirección de correo previamente configurada.

Nivel 0


MODULO DE HOST

DATOS DE

HOST

VERIFICAR

PASSWORD

PASSWORD

DATOS

HOSTS - ITEMS

CREAR HOST NUEVO

SELECCION OPCION

USUARIO AUTORIZADO

PASSWORD

VISTO BUENO

DATOS EDITAR

SERVICIOS A

MONITOREAR

ACTUALIZAR BASE

PASSWORD

PASSWORD

CAMBIAR

STATUS

GRUPOS DE HOST HOSTS-GROUPS

DATOS

VERIFICAR

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL MODULO DE HOSTS

(CLIENTES A MONITOREAR)

NOMBRE:

Modulo de hosts

DESCRIPCION:

En este diagrama se describe todo los procesos que los hosts

disponen una vez validado el usuario, Indicando si desea crear un

nuevo grupo de hosts, un nuevo hosts, cambiar el status del hosts,

editar uno que ya existe o configurar los servicios a monitorear. Todos

estos procesos deben registrarse o actualizarse en la base de datos.

NOTAS:

Un grupo de hosts por defecto aparece el cual encasilla a todos los

hosts creados.

No se puede monitorear un host que no se haya creado.

Nivel 1


SUBMODULO CREAR UN NUEVO HOST

DATOS

VERIFICAR

HOST

DATOS DE

HOST NUEVO HOST

INGRESO DE HOST MONITOR

SELECCION OPCION

PASSWORD

DATOS

DATOS AGREGAR

SALIR


PASSWORD

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO CREAR

NUEVOS HOSTS

NOMBRE:

Submodulo crear nuevos hosts

DESCRIPCION:

En este diagrama se describe todo los subprocesos que los hosts

disponen una vez validado el usuario. Ingresando los datos del

nuevo hosts a monitorear como: el nombre, el puerto, la dirección IP

el estado del hosts, los saltos que hay que realizar en caso de que el

host no forme parte de una red local. Agregando este host a la base

de datos.

NOTAS:

Se puede crear un hosts utilizando como plantilla uno que ya

exista esto es una funcionalidad valida en caso de que se necesite

monitorear servidores de respaldo.

Nivel 1


SUBMODULO CAMBIAR STATUS DE UN HOST

DATOS

VERIFICAR

HOST

DATOS DE

HOST STATUS HOST

NUEVO STATUS

SELECCION OPCION

PASSWORD

DATOS

DATOS MONITOREADO

NO

MONITOREADO


PASSWORD

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO CAMBIAR

STATUS DEL HOSTS

NOMBRE:

Submodulo cambiar el status del hosts

DESCRIPCION:


disponen una vez validado el usuario. Cambiando el status del hosts

de monitoreado o no monitoreado en caso de ser necesario. O

desconocido si el host no existe. Todos estos procesos deben


NOTAS:

Si un hosts no se a registrado y no es sensado por problemas en la

red este host esta en un estado desconocido.

Nivel 1


SUBMODULO GRUPOS DE HOSTS

DATOS

VERIFICAR

HOSTS-GROUPS

DATOS DE

HOST GRUPOS DE HOST

CREAR NUEVO GRUPO HOSTS

SELECCION OPCION

PASSWORD

DATOS

DATOS EDITAR

SALIR


PASSWORD

PASSWORD

PASSWORD

PASSWORD


CREAR NUEVOS GRUPOS DE HOSTS

NOMBRE:

Submodulo crear nuevos grupos de hosts

DESCRIPCION:


hosts disponen una vez validado el usuario. Ingresando los

datos del nuevo grupo de host como: el nombre y la

descripción. Inicialmente se ha creado por defecto un grupo

que contempla todos los hosts existentes. También nos brinda

la opción de editar dicho grupo. Agregando este grupos de

hosts a la base de datos.

NOTAS:

Se puede crear grupos de hosts de hasta por lo menos

dos clientes a monitorear o más.

Nivel 2


SUBMODULO EDITAR GRUPOS DE HOSTS

DATOS

VERIFICAR

HOSTS-GROUPS

DATOS DE

HOST EDITAR GRUPO

NUEVO GRUPO HOST

SELECCION OPCION

PASSWORD

VISTO BUENO

DATOS ACTUALIZAR

ELIMINAR


PASSWORD

PASSWORD

PASSWORD

PASSWORD


GRUPO DE HOSTS

NOMBRE:

Submodulo editar grupos de hosts

DESCRIPCION:

En este diagrama se describe todo los subprocesos que los grupos de

hosts disponen una vez validado el usuario. Editando los datos de los

grupos de hosts previamente registrados. Agregando nuevos hosts a

los grupos que ya existen o eliminando alguno. Todos estos procesos

deben registrarse o actualizarse en la base de datos.

NOTAS:

La creación de grupos de hosts ayuda al control jerárquico de la

red.

Nivel 1


SUBMODULO EDITAR HOST

DATOS

VERIFICAR

HOST

DATOS DE

HOST EDITAR HOST

NUEVO HOST

SELECCION OPCION

PASSWORD

VISTO BUENO

DATOS ACTUALIZAR

ELIMINAR


PASSWORD

PASSWORD

PASSWORD

PASSWORD


HOSTS

NOMBRE:

Submodulo editar hosts

DESCRIPCION:


disponen una vez validado el usuario. Editando los datos de los hosts

previamente creados. Agregando nuevas características a los que ya

existen o eliminando alguno. Todos estos procesos deben registrarse

o actualizarse en la base de datos.

NOTAS:

Las características de la máquina o hosts a monitorear deben

concordar con respecto a las sensadas por la aplicación.

Nivel 1


SUBMODULO SERVICIOS (ITEMS) A MONITOREAR

DATOS

VERIFICAR

HOST - ITEMS

DATOS DE

ITEMS ITEMS A MONITOR

NUEVO ITEMS

SELECCION OPCION

PASSWORD

DATOS

DATOS EDITAR ITEMS

SALIR


PASSWORD

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO SERVICIOS A

MONITOREAR EN EL HOSTS

NOMBRE:

Submodulo servicios a monitorear.

DESCRIPCION:


disponen una vez validado el usuario. Agregando los servicios que se

desean monitorear en el hosts. Editando los servicios previamente

registrados. Todos estos procesos deben registrarse o actualizarse en

la base de datos.

NOTAS:

Cuando se crea un hosts se le pueden asignar los servicios

usando como plantilla un hosts que ya exista.

Nivel 2


SUBMODULO EDITAR ITEMS


PASSWORD SALIR

DATOS DE

ITEMS

MODIFICAR ITEMS

SELECCION OPCION

ITEMS A MONITOR

PASSWORD

DATOS

DATOS

PASSWORD

PASSWORD

PASSWORD

HOST - ITEMS

SELECCIONAR ITEMS

ELIMINAR ITEM

ACTIVAR ITEMS

DESACTIVAR ITEMS

DATOS

DATOS

DATOS

PASSWORD

PASSWORD

PASSWORD

DATOS


ITEMS (SERVICIOS)

NOMBRE:

Submodulo editar items

DESCRIPCION:


disponen una vez validado el usuario. Modificando los items o

servicios a monitorear previamente creados. Podemos activar,

desactivar o eliminar un items. Todos estos procesos deben


NOTAS:

Los Items pueden ser editados desde el menú principal o desde

los hosts.

Nivel 0


MODULO DE ITEMS A MONITOREAR

PASSWORD

PASSWORD

PASSWORD

DATOS

ITEMS

VERIFICAR

AGREGAR ITEMS NUEVO

SELECCION OPCION

DATOS DE

ITEMS USUARIO AUTORIZADO

PASSWORD

VISTO BUENO

DATOS EDITAR

SELECCIONAR ITEMS

ACTUALIZAR BASE DE DATOS

PASSWORD

CAMBIAR

STATUS

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL MODULO DE ITEMS A

MONITOREAR

NOMBRE:

Modulo de items a monitorear

DESCRIPCION:

En este diagrama se describe todo los procesos que los items o

servicios disponen una vez validado el usuario, Indicando si desea

crear un nuevo items, cambiar el status del items, editar uno que ya

exista o seleccionar los servicios a monitorear. Todos estos procesos


NOTAS:

El items puede ser un servicio o cualquier parámetro de la red ya

establecido.

Nivel 1


SUBMODULO AGREGAR ITEMS AL HOST

DATOS

VERIFICAR

ITEMS

DATOS DE

ITEMS NUEVO ITEMS

DATOS DEL ITEMS

SELECCION OPCION

PASSWORD

DATOS

DATOS AGREGAR

SALIR


PASSWORD

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO AGREGAR UN

NUEVO ITEMS

NOMBRE:

Submodulo agregar un nuevo items

DESCRIPCION:

En este diagrama se describe todo los subprocesos que los items

disponen una vez validado el usuario. Ingresando los datos del nuevo

items a monitorear como: el nombre hosts, el tipo de agente, el estado

del items. Agregando este items a la base de datos.

NOTAS:

Al crear un items se debe especificar el hosts en caso de que se

quiera monitorear la misma maquina se determina un tipo de

agente de simple chequeo.

Nivel 1


SUBMODULO CAMBIAR STATUS DE UN ITEMS

DATOS

VERIFICAR

ITEMS

DATOS DE

ITEMS STATUS ITEMS

NUEVO STATUS

SELECCION OPCION

PASSWORD

DATOS

DATOS ACTIVO

NO ACTIVO


PASSWORD

PASSWORD

PASSWORD

PASSWORD


CAMBIAR STATUS DELITEMS

NOMBRE:

Submodulo cambiar el status del items

DESCRIPCION:


items disponen una vez validado el usuario. Cambiando el

status del items de activo a inactivo en caso de ser necesario.

O no soportado si el tipo de agente no es el adecuado. Todos

estos procesos deben registrarse o actualizarse en la base de

datos.

NOTAS:

Si un items no ha sido configurado correctamente

mantendrá un estado de no soportado. Debido al tipo de

agente que se le esta asignando.

Nivel 1




PASSWORD

SALIR

DATOS DE

ITEMS

MODIFICAR ITEMS

SELECCION OPCION

ITEMS A MONITOR

PASSWORD

DATOS

DATOS

PASSWORD

PASSWORD

PASSWORD

HOST - ITEMS

SELECCIONAR ITEMS

ELIMINAR ITEM

ACTIVAR ITEMS

DESACTIVAR ITEMS

DATOS

DATOS

DATOS

PASSWORD

PASSWORD

PASSWORD

DATOS


ITEMS

NOMBRE:

Submodulo editar items

DESCRIPCION:


disponen una vez validado el usuario. Editando los datos de los items


existen, podemos seleccionar el items para activarlo, desactivarlo ó

eliminarlo. Todos estos procesos deben registrarse o actualizarse en

la base de datos.

NOTAS:

El tipo de agente descrito en el items dependerá de lo que se

quiera monitorear.

Nivel 2


SUBMODULO MODIFICAR ITEMS

DATOS DE

ITEMS

ITEMS

MODIFICAR ITEMS

SELECCION OPCION

VISTO BUENO

DATOS ACTUALIZAR

AGREG AL HOST


PASSWORD

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO MODIFICAR

ITEMS

NOMBRE:

Submodulo modificar items

DESCRIPCION:


disponen una vez validado el usuario. Modificando los datos de los

items previamente creados. Agregando nuevas características a los

que ya existen o eliminando alguna de ellas. Todos estos procesos


NOTAS:

Todo items modificado debe ser actualizado para que los cambios

surtan efecto.

Nivel 0


MODULO CONFIGURACION

DATOS

VERIFICAR

MEDIA

DATOS DE

CONFIGURACION VALIDACION DE USUARIO

NUEVO CONFIG

SELECCION OPCION

PASSWORD

DATOS

DATOS EDITAR CONFIG

SALIR


PASSWORD

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL MODULO DE

CONFIGURACION

NOMBRE:

Modulo de configuración

DESCRIPCION:

En este diagrama se describe todo los procesos de configuración que

un usuario disponen una vez validado, Indicando si desea crear una

nueva configuración, editar uno que ya exista o salir de la misma.

Todos estos procesos deben registrarse o actualizarse en la base de

datos.

NOTAS:

En la configuración registra desde donde se van enviar las

notificaciones a los usuarios del sistema.

Nivel 1


SUBMODULO DE NUEVA CONFIGURACION

DATOS

VERIFICAR

MEDIA – MEDIA_TYPE

DATOS DE

CONFIGURACION NUEVA CONFIG

INGRESAR DATOS CONFIG

SELECCION OPCION

PASSWORD

DATOS

DATOS CONFIG DIAS DE ALERTAS

SALIR


PASSWORD

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO DE NUEVA

CONFIGURACION

NOMBRE:

Submodulo nueva configuración

DESCRIPCION:

En este diagrama se describe todo los subprocesos de configuración

una vez validado el usuario. Ingresando los datos del nuevo nueva

configuración como: el nombre del servidor SMTP de donde se va

enviar la alerta y la cuenta de correo, Además de especificar cuanto

tiempo se mantenga el histórico de las alertas que por defecto se

establece 365 días. Agregando este items a la base de datos.

NOTAS:

Al crear una nueva configuración se debe especificar la cuenta de

correo desde donde se esta enviando las alertas.

Nivel 1


SUBMODULO EDITAR CONFIGURACION

DATOS

VERIFICAR


DATOS DE

CONFIGURACION EDITAR CONFIG

NUEVO CONFIG

SELECCION OPCION

PASSWORD

VISTO BUENO

DATOS

ACTUALIZAR

ELIMINAR


PASSWORD

PASSWORD

PASSWORD

PASSWORD


CONFIGURACION

NOMBRE:

Submodulo editar configuración

DESCRIPCION:

En este diagrama se describe todo los subprocesos de configuración

una vez validado el usuario. Editando los datos de configuraciones


existen, ó eliminando alguna de ellas. Todos estos procesos deben


NOTAS:

Antes de realizar la configuraciones en el sistema, previamente se

debe crear una cuenta de correo en sendmail o el servidor smtp

desde donde se va ha generar las alertas.

Nivel 0


MODULO DE TRIGGERS

DATOS

VERIFICAR

TRIGGERS

DATOS DE

TRIGGERS VALIDACION DE USUARIO

NUEVO TRIGGERS

SELECCION OPCION

PASSWORD

VISTO BUENO

SALIR


PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL MODULO DE TRIGGERS

NOMBRE:

Modulo de triggers

DESCRIPCION:

En este diagrama se describe todo los procesos de triggers o

disparadores que se ejecutan cuando un evento ocurra una vez

validado el usuario, estableciendo si se dan nuevos eventos

generándose nuevos disparadores. Todos estos procesos deben


NOTAS:

Cada evento que ocurra en la aplicación va ha generar un nuevo

triggers o disparador.

Nivel 1


SUBMODULO SELECCIONAR TRIGGERS

TRIGGERS

DATOS DE

TRIGGERS SELECCIONTRIGGERS

HABILITAR TRIGGERS

SELECCION OPCION

PASSWORD

VISTO BUENO

DATOS

DESHABILITAR TRIGGERS

ELIMINAR TRIGGERS

ACTUALIZANDO

BASE DE DATOS

PASSWORD

PASSWORD

PASSWORD

PASSWORD

DATOS

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO DE

SELECCIONAR TRIGGERS

NOMBRE:

Submodulo de seleccionar triggers

DESCRIPCION:

En este diagrama se describe todo los subprocesos de triggers o

disparadores una vez validado el usuario, estableciendo si el triggers

esta deshabilitado, habilitado o en algún caso eliminado si el hosts a

monitorear no existe. Todos estos procesos deben registrarse o

actualizarse en la base de datos.

NOTAS:

Los triggers se habilitan o deshabilitan cada vez que un parámetro

o servicio monitoreado cambia su estado.

Nivel 2


SUBMODULO GRAFICA DE TRIGGERS

DATOS

GRAPHS-TRIGGERS

DATOS DE

TRIGGERS GRAFICA TRIGGERS

GRAFICA HISTORICA

SELECCION OPCION

PASSWORD

DATOS

DATOS

VALORES POR PERIODO

VALORES EN TEXTO


PASSWORD

PASSWORD

PASSWORD

PASSWORD

GRAFICA POR HORA

VALORES POR HORA

DATOS

DATOS

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO GRAFICA DEL

TRIGGERS

NOMBRE:

Submodulo grafica del triggers

DESCRIPCION:

En este diagrama se describe todo los subprocesos de triggers o

disparadores una vez validado el usuario, estableciendo una gráfica

por medio del triggers habilitado, mostrando un histórico por hora o por

día. Todos estos procesos deben registrarse o actualizarse en la

base de datos.

NOTAS:

Podemos acceder a la gráfica una vez que se ha generado el

evento.

También podemos acceder a la gráfica directamente desde el

menú principal la opción gráfica.

Nivel 2


SUBMODULO STATUS DEL TRIGGERS

ACTIVAR TRIGGERS

SELECCION

OPCION

DATOS DE TRIGGERS STATUS DEL

TRIGGERS

TRIGGERS

PASSWORD

VISTO BUENO

DATOS

DESACTIVAR TRIGGERS

ACTUALIZAR

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO STATUS DEL

TRIGGERS

NOMBRE:

Submodulo status del triggers

DESCRIPCION:

En este diagrama se describe todo los subprocesos que los triggers

disponen una vez validado el usuario. Cambiando el status del

triggers de activo a inactivo en caso de ser necesario cuando no

ocurre ningún cambio en el parámetro monitorizado. Todos estos

procesos deben registrarse o actualizarse en la base de datos.

NOTAS:

Si no se registra ningún cambio en el estado del parámetro

monitorizado, el triggers mantendrá su estado.

Nivel 0


MODULO ACERCA DEL MONITOR

USERS

PASSWORD DATOS DE LA APLICACION

SELECCION OPCION

DATOS GENERALES DE LA APLICACION ACERCA DE

APLICACION

VISTO

BUENO

DATOS

SALIR

ACTUALIZAR

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL MODULO DE ACERCA DEL

MONITOR

NOMBRE:

Modulo de acerca del monitor

DESCRIPCION:

En este diagrama se hace una presentación general de la aplicación

visualizada por usuario valido, Indicando el nombre del proyecto, los

participantes del mismo.

NOTAS:

Acerca del monitor muestra una información general del proyecto.

Nivel 0


MODULO DE GRAFICA

GRAPHS

MOSTRAR GRAFICA

DATOS DE

GRAFICA GENERACION DE GRAFICA

NUEVA GRAFICA

SELECCION OPCION

PASSWORD

VISTO BUENO

DATOS

SELECCIONAR GRAFICA

SALIR


PASSWORD

PASSWORD

PASSWORD

PASSWORD

DATOS

DATOS

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL MODULO DE GRAFICAS

(MONITOREO)

NOMBRE:

Modulo de graficas o monitoreo

DESCRIPCION:

En este diagrama se describe todos los procesos de configuración de

las gráficas o monitoreo que un usuario dispone una vez validado,

mostrando si existe una nueva gráfica o seleccionando la que desea

mostrar. Todos estos procesos deben registrarse o actualizarse en la

base de datos.

NOTAS:

En la opción de grafica o monitoreo se accede la visualización del

parámetro monitorizado de manera grafica, estableciendo una

relación directa entre el items, el evento o disparador que se

generó y la grafica.

Nivel 1


SUBMODULO NUEVA GRAFICA

PASSWORD

INGRESAR

DATOS

DATOS GRAFICA

NUEVA GRAFICA

DATOS

GRAPHS

ACTUALIZAR BASE

DATOS

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO DE NUEVA

GRAFICAS (MONITOREO)

NOMBRE:

Submodulo de nueva graficas o monitoreo

DESCRIPCION:

En este diagrama se describe todos los procesos de configuración de

las gráficas o monitoreo que un usuario dispone una vez validado,

por cada elemento monitoreado se generara una nueva grafica. Todos


NOTAS:

Cada servicio generará una gráfica a través de la cual visualicemos

los resultados.

Nivel 1


SUBMODULO MOSTRAR GRAFICA

GRAPHS-ITEMS

DATOS DE

GRAFICA MOSTRAR GRAFICA

MOSTRAR PARAMETROS

SELECCION OPCION

PASSWORD

DATOS

DATOS

GRAFICA UP

GRAFICA DOWN


PASSWORD

PASSWORD

PASSWORD

PASSWORD

AGREGAR NUEVO ITEMS

DATOS

DATOS

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO DE MOSTRAR

GRAFICAS (MONITOREO)

NOMBRE:

Submodulo de mostrar graficas o monitoreo

DESCRIPCION:

En este diagrama se describe todos los subprocesos de configuración

de las gráficas o monitoreo que un usuario dispone una vez validado,

por cada items a monitorear generará un gráfico, mostrando los

parámetros indicando si el servicio esta arriba o abajo. Todos estos


NOTAS:

Cada servicio generará una gráfica a través de la cual visualicemos

los resultados.

Nivel 1


SUBMODULO DE SELECCIONAR GRAFICA

DATOS

PASSWORD ESCOGER GRAFICA

SELECCION

OPCION

DATOS DE

PANTALLA MOSTRAR GRAFICA

GRAPHS

VISTO BUENO

SALIR

ACTUALIZAR BASE

PASSWORD

PASSWORD

PASSWORD


SELECCIONAR GRAFICAS (MONITOREO)

NOMBRE:

Submodulo de seleccionar graficas o monitoreo

DESCRIPCION:

En este diagrama se describe todos los subprocesos de configuración

de las gráficas o monitoreo que un usuario dispone una vez validado,

seleccionando el servicio que queremos visualizar la grafica. Todos


NOTAS:

Con esta función podemos elegir el servicio a monitorear de todos

los hosts.

Nivel 0


MODULO ALARMAS

DATOS

PASSWORD MOSTRAR ALARMAS

SELECCION

OPCION

DATOS DE

ALARMA ALARMAS

ALARMS

DATOS

DESCRIPCION DE ALARMAS

ACTUALIZAR BASE

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL MODULO DE ALARMAS

NOMBRE:

Modulo de alarmas

DESCRIPCION:

En este diagrama se describe todo los procesos de alarmas que se

ejecutan cuando un evento ocurra una vez validado el usuario,

mostrando las alarmas generadas por el evento y describiendo a

través de una expresión la misma. Todos estos procesos deben


NOTAS:

Cada evento que ocurra en la aplicación va ha generar un nueva

alarma.

Nivel 1


SUBMODULO DESCRIPCION DE ALARMAS

DATOS

PASSWORD DATOS DE ALARMAS

SELECCION

OPCION

DATOS DE

ALARMA DESCRIPCION DE ALARMAS

ALARMS

DATOS

ULTIMOS

VALORES

ACTUALIZAR BASE

PASSWORD

PASSWORD

PASSWORD


DESCRIPCION DE LAS ALARMAS

NOMBRE:

Modulo descripción de las alarmas

DESCRIPCION:

En este diagrama se describe todo los subprocesos de alarmas que se

ejecutan cuando un evento ocurra una vez validado el usuario,

mostrando una descripción de las alarmas a través de una expresión

lógica que puede tener un valor de verdadero si algo esta mal o falso

si todos los servicios están en correcto funcionamiento. Todos estos


NOTAS:

Cada alarma genera los valores de falso o verdadero.

Nivel 0


MODULO ALERTAS

PASSWORD MOSTRAR ALERTS

SELECCION

OPCION

DATOS DE

ALERTA ALERTAS

ALERTS

DATOS DATOS

DESCRIPCION DE ALERTS

ACTUALIZAR BASE

PASSWORD

PASSWORD

PASSWORD

ESPECIFICACIONES DEL DIAGRAMA DEL MODULO DE ALERTAS

NOMBRE:

Modulo de alertas

DESCRIPCION:

En este diagrama se describe todo los procesos de alertas que se

ejecutan como un mecanismo de notificación cuando un evento ocurra

una vez validado el usuario, mostrando las alertas generadas por el

evento y describiendo a través de un mensaje la misma. Todos estos


NOTAS:

Cada evento que ocurra en la aplicación va ha generar un nueva

alerta, la misma que se enviara a la cuenta de correo configurada

previamente si alguno de los servicios se encuentra abajo.

Nivel 1


SUBMODULO DESCRIPCION DE ALERTAS

DATOS

PASSWORD DATOS DE ALERTS

SELECCION

OPCION

DATOS DE

ALERTAS DESCRIPCION DE ALERTAS

ALERTS

DATOS

ULTIMOS VALORES

ACTUALIZAR BASE

PASSWORD

PASSWORD

PASSWORD


DESCRIPCION DE LAS ALERTAS

NOMBRE:

Modulo descripción de las alertas

DESCRIPCION:

En este diagrama se describe todo los subprocesos de alertas que se

ejecutan como un mecanismo de notificación, cuando un evento

ocurra una vez validado el usuario, mostrando un mensaje de la

alerta a través de un e-mail a todos los usuarios configurados. Todos


NOTAS:

Cada alerta genera un nuevo e-mail.

CAPITULO 3

3. Diseño del sistema

A lo largo de esta sección nos centraremos en llevar a cabo la fase de diseño

de todo el SISTEMA DE MONITOREO DE SERVICIOS EN EQUIPOS

LINUX, comenzando por las partes más generales del mismo, como puede

ser la arquitectura del sistema, para poco a poco ir centrándonos en aspectos

más detallados del diseño.

3.1. Arquitectura del sistema

El sistema de monitoreo de servicios en equipos Linux posee una

arquitectura CLIENTE-SERVIDOR. Bajo este esquema, la comunicación

de una máquina cliente que accede a un servicio en una máquina

servidora, se hace a través de un puerto de comunicación.

El hecho de que la comunicación se efectúe en puertos específicos es

explotada por nuestra herramienta de monitoreo, que realiza una prueba

de conexión, indicando si el servicio está disponible o no. Esta aplicación

es capaz de funcionar en modo de ejecución de inetd. Dependiendo del

método de la configuración y modo de la ejecución que se este

utilizando, el servidor y el cliente tiene varios procesos.

3.1.1. Esquema global de la descripción funcional y de datos.

La arquitectura funcional del SISTEMA DE MONITOREO DE

SERVICIOS EN EQUIPOS LINUX posee 4 componentes principales,

que trabajan en cascada, como se aprecia en la Fig. 1.

Cada uno de los módulos a su vez se implementa en uno o varios

procesos. Como interfaz de comunicación entre procesos se utilizan

ficheros, periódicamente escritos y leídos, con un formato predefinido.

Es de destacar el enfoque modular de la plataforma, el cual, junto con

la posibilidad de configurar cada uno de los módulos

independientemente, la dota de una gran flexibilidad.

El propósito del sistema, es ofrecer servicio de gestión y control

sobre distintos servidores de la red. Este servicio basado en una

interfaz Web, ofrece al usuario el acceso al sistema, y por lo tanto

acceso a la gestión y control de las entidades remotas, dentro de un

entorno de navegador.

El SISTEMA DE MONITOREO DE SERVICIOS EN EQUIPOS LINUX,

realiza las funciones de gestión/control mediante el intercambio de

mensajes del protocolo SNMPv1 y SNMPv2.

Los mensajes de requerimientos de SNMP son enviados por el

Servidor (monitor principal) a los agentes. Estos mensajes pueden ser

usados para obtener información de un agente o para instruir a un

agente para configurar un dispositivo de un host. Los agentes SNMP

deben decodificar apropiadamente los mensajes de requerimientos y

procesar los datos, según las opciones de configuración, para realizar

las acciones pertinentes, actualizando la presentación Web y

reenviando, según corresponda, la información mediante alertas.

Los usuarios (cliente) del sistema acceden al servicio de gestión de

dichos elementos en forma remota mediante la interfaz Web. Por su

parte, los usuarios de alertas que hayan sido configurados para que

les sean enviadas las señales de alarmas son notificados de los

eventos de gestión recibidos por el sistema.

El repositorio principal de los datos, tanto en lo que respecta a la

gestión como a la administración, se encuentra sustentado por una

Base de Datos MySql. Esta base es el más popular, rápido y confiable

en el entorno Open Source. La utilización de la misma brinda a este

sistema de gestión la posibilidad de escalar en magnitud según sea

necesario, además de proveer una interfaz para el intercambio masivo

de datos.

La Interfaz Web del sistema la maneja un servidor Web Apache. Esta

elección se basa también en las características de amplia difusión y

confiabilidad de este tipo de servidores. Desarrollado en el entorno

Open Source, posee el soporte necesario para el correcto

mantenimiento de sistemas complejos.

El software de funcionamiento se encuentra en su mayoría

implementado en C++. La elección de este lenguaje se basa en la

posibilidad de desarrollo multiplataforma y en el soporte gratuito que

incluye el código fuente, la librería estándar, los módulos opcionales

y toda la documentación relacionada., que mantiene e intercambia una

gran comunidad de usuarios.

El protocolo a utilizar es SNMP (SNMPv1 y SNMPv2) se utiliza como

una aplicación cliente/servidor sincrónica, lo que significa que tanto el

dispositivo administrador como el software servidor SNMP pueden

generar un mensaje para el otro y esperar una respuesta, en caso de

que haya que esperar una. SNMP utiliza TCP como un protocolo de

transporte de mensajes. Cada mensaje de SNMP se encapsula

completamente en un en un paquete TCP.

Usamos SNMP porque su diseño es simple, la información de gestión

que se necesita intercambiar ocupa pocos recursos de la red. Además,

permite al usuario elegir las variables que desea monitorizar. Además

se requiere poco código para su implementación y está ampliamente

difundido hoy en día.

DBSocket MySQL

SOCKETS TCP

SOCKETS TCP

SOCKETS TCP

IP

HTTP

TCP

IP

SNMP

TCP

EQUIPO 2

AGENTE

SNMP

EQUIPO 1

AGENTE

SNMP

EQUIPO N

AGENTE

SNMP

USUARIO

NAVEGADOR

CLIENTES

MENSAJE DE GESTION

MONITOR INTERMEDIO

SOCKETS TCP

ALERTAS

E-MAIL

E-MAIL

U

S

U

A

R

I

O

S

A

L

E

R

T

S

BASE

DE

DATOS

MySQL

MONITOR PRINCIPAL

DBSocket MySQL

Fig. 1

SERVIDOR WEB

WEB

AGENTES

GET REQUEST

3.1.2. Bloques del sistema de monitoreo en equipos Linux

A continuación se describen cada uno de los bloques y las

funcionalidades más destacadas del sistema que se aprecian en la

Fig. 2

3.1.2.1. Monitor principal

Que es el proceso principal de la aplicación. Realiza las siguientes

funciones:

Colecciona la información de los agentes nativos o SNMP.

Chequeos simples proceso ejecutado periódicamente.

Envío de alarmas generadas por el monitor principal y el

monitor intermediario.

El proceso se ejecuta como un demonio bajo un usuario no

privilegiado que reside en el servidor y periódicamente se

conecta a los agentes nativos o SNMP para obtener los

parámetros a ser supervisado.

Después de recibir estos valores previamente procesados por el

monitor intermediario envía las alarmas a los usuarios de ser

necesario. Las alarmas y alertas más antiguas son anuladas bajo

ciertos parámetros de tiempo, actualizándose con el archivo más

reciente.

3.1.2.2. Monitor intermediario

Es el que procesa la información enviada por los clientes a través

de los requerimientos. El objetivo de este modulo es coleccionar

información proporcionada por agentes activos, realizando 10

copias del mismo.

Esto es manejado por parámetros dando las facilidades de cambiar

el número de copias necesarias. Puede configurarse para que se

hagan conexiones a la base de datos por cada requerimiento

nuevo.

El proceso se corre como el demonio no privilegiado bajo el

account usuario. Es el encargado de recibir y pre-procesar los

eventos enviados por los servidores Gestionados vía SNMPv1,

Traps.

3.1.2.3. Base de datos

Todos los parámetros se guardan en una base de datos. En donde

se almacena un histórico de los valores que se están

monitoreando, tanto los de gestión como los de administración.

Como se explicó antes, nuestra aplicación se ha implementado

sobre un servidor de Base de datos MySQL por su versatilidad y

confiabilidad. Ya que el sistema depende exclusivamente de la

eficacia y la velocidad de la base de datos.

3.1.2.4. Interfaz grafica del usuario

Tras la gestión y control sobre distintos elementos supervisados,

se pueden realizar diferentes análisis sobre los resultados, la

mayor parte de estos análisis son de tipo estadístico, con el objeto

de presentar gráficas de los resultados en una página Web que es

consultada por los usuarios del SISTEMA DE MONITOREO DE

SERVICIOS EN EQUIPOS LINUX.

La función principal de este bloque es la de presentación de los

datos de Gestión a través de la Interfaz Web, usando PHP y

MySQL. Un sistema semejante, libre, para registrar el

comportamiento de los servidores.

Interfase del usuario (Nivel de

presentación)

Manejador de Base de Datos (Nivel de

almacenamiento),

Procesador de aplicaciones o reglas del negocio

(Nivel lógico)

BASE DE DATOS DEL MONITOR

DE SERVICIOS EN EQUIPOS

LINUX

WEB GUI

INTERFAZ GRAFICA

DE USUARIO

MONITOR PRINCIPAL

MONITOR INTERMEDIO

TRAP 1

TRAP 2

TRAP N

AGENTES NATIVOS

AGENTES SNMP

ALERTAS

Fig. 2

3.1.3. Diagrama de bloque del monitor principal

En este bloque el servidor del sistema, el monitor principal, comienza

las conexiones a los agentes (Clientes), que se encuentran

ejecutándose en los servidores que se van a monitorear,

(monitor_agentd).

El monitor principal solicita información muy diversa a los agentes

SNMP (la carga del procesador, la disponibilidad de memoria,

actividad en disco duro, etc.) El cliente proporciona la información

pedida. Para luego enviar las alarmas a los usuarios de ser necesario.

Con el propósito de ofrecer un servicio de gestión/control sobre los

servidores monitoreados, se recurre a la utilización del protocolo

SNMPv1 empleando mensajes básicos y el procesamiento de

alarmas de las variables de gestión. Las variables de gestión se

encuentran definidas en la Base de Información de Gestión (MIB) que

el sistema interpreta para poder incorporar sus variables a la gestión.

Como se observa, los módulos que componen este bloque son:

3.1.3.1. El monitor_agentd (agentes nativos modo inetd.)

Este proceso reside en el servidor a ser monitorizado. Se ejecuta

como un demonio en el modo inetd, su propósito es proporcionar la

información de la demanda al monitor principal.

3.1.3.2. Monitor intermediario ( monitor_suckerd )

Este bloque se encarga de decodificar apropiadamente los

mensajes de requerimientos, validándolas contra el manejador de

la información en la base de datos (MIB), procesar los datos y

almacenar los resultados dentro de la Base de Datos del sistema

de Monitoreo de Servicios en Equipos Linux. Es decir dirigir los

"traps" al sistema de gestión de red encargado de analizar y

presentarlos en formato gráfico.

3.1.4. Procesamiento de alertas

Después de recibir los valores, y analizar las variables este módulo

filtra los eventos previamente procesados por el módulo de Encuesta y

Modificación, según los criterios de configuración del sistema.

De esta forma los eventos que pasen por los filtros serán tratados

como alarmas, modificando los estados de la Gestión dentro de la

Base de Datos. Los filtros de eventos son configurados por el usuario

de sistema, indicándose en dicha configuración criterios de prioridad

para la severidad de las alarmas, y el mecanismo de alerta asociado a

la misma.

La Fig. 3 presenta un esquema del proceso de filtrado de eventos y su

transformación en alarmas.

Fig. 3

EVENTOS

FILTRO 2 FILTRO 1 FILTRO N A

LA

RM

A 1

AL

AR

MA

2

AL

AR

MA

S

N

ESTADO DE LA GESTION

AGENTE MONITOR

DE EVENTOS

3.1.5. Esquema del bloque interno del monitor principal

La puesta en funcionamiento del agente SNMP no consiste

únicamente en la instalación de los demonios y el software

correspondiente, sino que es necesario identificar la red (mediante un

identificador numérico similar a la IP, llamado OID) que la ubique

dentro del árbol SNMP (en concreto, seria una rama descendiente de

las redes private-enterprises). Así mismo, requiere la definición de

unas “cuentas de usuario” que indiquen los permisos de

lectura/escritura con que cuentan dentro de las estructuras de datos

definidas en SNMP (definición de la comunidad como private).

El servidor también puede enviar instrucciones al agente para

modificar las entradas de su base de datos MIB (Administrador de la

Información de la Base Datos). El servidor también puede enviar los

límites o las condiciones bajo las cuales el agente SNMP debe generar

un mensaje de interrupción para el servidor.

En este caso el sentido tradicional de cliente se ha invertido. El cliente

realmente es el servidor. Es decir que la conexión es hecha del

servidor del monitor principal al cliente el monitor_agentd, y por

consiguiente el cliente está actuando como un servidor tradicional

escuchando las conexiones y respondiendo; y el servidor el monitor

principal está actuando como un cliente tradicional comenzando una

conexión.

El monitor principal realiza los ping de ICMP cada cierto tiempo,

monitoreando ciertas tareas periódicamente anulando todos los

archivos de las alarmas más antiguos dependiendo de la

configuración. El intervalo de la actualización también se usa para

gráficos generados por la interfaz de usuario.

El funcionamiento interno del bloque del monitor principal responde al

esquema planteado en la Fig. 4.

BASE DE DATOS

MIB

SERVIDORES

MONITORIZADOS

DEMONIOS

MONITOR

AGENTD

Modo Inetd

MONITOR

AGENT

Modo Inetd

MONITOR

INTERMEDIARIO

PROCESAMIENTO

DE ALERTAS

SNMPv1

MyS

QL

MyS

QL

SNM

P

E-

MAI

L

BLOQUE DE

ALERTAS

SOCKET TCP

Fig. 4

MONITOR

SUCKERD

3.1.5.1. Diagrama de bloque del monitor intermediario

El monitor intermediario es un proceso que proporciona apoyo al

monitor principal. Constantemente espera por las conexiones de

agentes activos. Este bloque cuenta con dos bloques internos:

GESTOR DE CONTROL SNMP

Cuando una conexión del monitor_agentd es hecha, este proceso

determina si la conexión está viniendo de un servidor autorizado. El

Gestor de control contiene las listas de direcciones IP de esta

manera compara y rechaza las conexiones de otras direcciones

de IP. Este proceso se corre como un demonio no privilegiado bajo

el account de usuario.

MONITOR_SENDER.

Después de verificar la autenticidad de las conexiones de los

agentes SNMP, el monitor_sender a través de las funciones Get y

Set basadas en el intercambio de mensajes GetRequest-

GetResponse y SetRequest-GetResponse respectivamente,

provistos por el protocolo SNMP, manejan dichos mensajes e

interpretar los datos de las variables de gestión contenidos en ellos

recurriendo a la información de la MIB del sistema.

El monitor_sender. Esta diseñado para ser usado como un

demonio en el inetd. Contiene:

<el servidor> EL server es el nombre o IP del

servidor a conectarse.

<el puerto> El número de Puerto para conectar al

servidor.

<el host:key> Los host: key el host autenticado.

<el valor> El valor para el parámetro requerido por

“el host: key”

En cada caso un tipo de objeto definido en el MIB se identifica en

las operaciones SNMP por un nombre único llamado "nombre de

variable". En general, el nombre de una variable SNMP es un

identificador de objeto de la forma x.y, donde x es el nombre del

tipo de objeto no agregado definido en el MIB, e y es un fragmento

de un identificador de objeto que de forma única para dicho tipo

de objeto, identifica el caso deseado.

MONITOR

SENDER

BASE DE DATOS

MySQL

DBConnectOnEach.

GESTOR

SNMP

TRAPS

PUERTO Nª

PUERTO Nª

PUERTO Nª

Get-Request

Get-Response

Get-Next-Reqst

Get-Next-Respon

Set-Request

Get-Response

Fig. 5

3.1.6. Diagrama de bloque de la interfaz de usuario

La función principal de este bloque es la de presentación de los datos

de Gestión a través de la Interfaz Web. Para ello da el formato

adecuado a dichos datos y luego por intermedio del SERVIDOR WEB

APACHE los presenta al usuario del sistema.

El método principal de presentación de los datos de Gestión es el

formato Gráfico, a través de archivos PNG, que representan mapas

que agrupan distintos elementos de la red que se están

supervisándose. El estado de cada elemento de la red se encuentra

representado por un código de colores que simboliza las severidades

de las alarmas asociadas a él.

Los mapas a su vez también heredan el estado de la alarma de mayor

severidad de los elementos de la red que contenga.

EL MÓDULO GRÁFICO.- convierte la información de gestión en la

representación de mapas antes mencionada.

EL MÓDULO PHP DE GD.- es el encargado de generar

dinámicamente en el servidor las páginas HTML para ser presentadas

al usuario del sistema como archivos gráficos representativos del

estado de la Gestión. Además este módulo incluye la función de

consulta a la base de datos, tanto de gestión como de administración,

y presentación de resultados al usuario.

EL NAVEGADOR debe configurarse para aceptar las cookies y

JavaScript, EL MONITOREO DE SERVICIOS EN EQUIPOS LINUX,

usa los cookies para guardar la información relacionadas con la

sesiones.

A continuación se representa un diagrama interno de los distintos

módulos básicos que componen la interfaz con el usuario:

HTML

BASE DE DATOS

PHP

GD

GRAFICACION

MyS

QL

MyS

QL

PNG

Servidor

Web de Apache FLUJO

NAVEGADOR

Fig. 6

3.1.6.1. Login de usuarios

En este diagrama se especifica como el usuario hace el ingreso al

servidor donde se encuentra instalada la aplicación de monitoreo.

La aplicación proporciona a los usuarios 4 tipos de permisos:

READ, READ-ONLY. HIDE y ADD, por lo que dependiendo del tipo

de permiso otorgado el usuario tendrá acceso a las diferentes

secciones de la interfaz Web.

Ingreso de Usuario y Password

Servidor Apache

User /Passwd

Base de Datos

Restricciones y

permisos Select

Fig. 7

3.1.6.2. Configuración del servidor de aplicación

Este diagrama como se configura el servidor de monitoreo, el

servidor SMTP, el nombre de la cuenta a donde se enviará las

alertas, entre otros parámetros.

Usuario

Servidor Apache

Solicitud de

Configuración

Base de Datos

Servidor de

Monitoreo Actualizando Base

de Datos

Datos Configurados

Fig. 8

3.1.6.3. Ingreso de nuevos usuarios

En este diagrama se realiza el ingreso de nuevos usuarios y la

configuración de aquellos que ya existen y que van ha interactuar

con la aplicación; se definen tanto los perfiles como permisos a los

diferentes recursos, se establecen también el nombre del usuario,

descripción y contraseña.

Usuario

Servidor Apache

Base de

Datos

Servidor de

Monitoreo Actualizando Base

de Datos

Solicitud de Nuevo

Usuario

Flujo

Formulario de Solicitud

Validación de

Datos

Datos de

Usuario

Datos de

Nuevo

Usuario

Datos a Configurar de Usuario

Configuración de

Usuarios

Permisos y

Restricciones

Permisos y

Restricciones

Permisos y

Restricciones

Fig. 9

3.1.6.4. Ingreso y/o modificación de cuentas de correo

Este diagrama muestra el ingreso y/o modificación de la cuenta de

correo en la que el usuario va ha recibir los mensajes de alertas.

Solicitud de Nueva

Cuenta o cuenta a

modificar

Usuario

Servidor Apache

Base de Datos

Servidor de

Monitoreo Actualizando Base de

Datos

Flujo

Formulario Cuenta de Correo

Validación de Datos

Datos de

Usuario

Datos de la

cuenta de

Correo

Fig. 10

3.1.6.5. Ingreso y/o modificación de equipos a ser monitoreados

Se ingresan los datos de los equipos a ser monitoreados tales

como: Nombre del equipo, Dirección IP, puerto por el que el agente

estará escuchando los requerimientos del servidor, luego de ser

ingresado este equipo pasará a ser monitoreado, en este

diagrama también se verá la manera como modificar algunos datos

o datos que se hayan cambiados en los equipos ya registrados.

Actualizando Base de Datos

Usuario

Servidor Apache

Base de Datos

Servidor de

Monitoreo

Solicitud de Nuevo Host

Flujo



Datos del nuevo

equipo

Datos del

equipo

Datos del equipo a modificar

Modificación de Datos del

Equipo

Datos Modificados

Fig. 11

3.1.6.6. Ingreso de items (aplicaciones o servicios) a ser

monitoreados

En este diagrama usted podrá agregar Items a monitorear en el

servidor requerido, entre los parámetros a ingresar están: la

expresión a evaluar, el servidor en el que se evaluará el item, el

estado, el retardo, el tipo de valor retornado por la expresión que ha

sido ingresada para el item.

Usuario

Servidor Apache

Base de Datos

Servidor de

Monitoreo Actualizando Base de

Datos

Solicitud de Nuevo Items

Flujo



Datos de los

Items

Datos del

Nuevo Items

Fig. 12

3.1.6.7. Listar los items de determinado equipo monitoreado

Aquí se visualizan los items a monitorear en determinado servidor,

basta con seleccionar el servidor a monitorear, esto nos dará una

lista de los items definidos para ese equipo, su retardo y la

expresión que será evaluada.

Usuario

Servidor Apache

Base de Datos

Servidor de

Monitoreo


Equipo Monitoreado

Formulario que lista los items

Mostrar Lista de Items

Permisos y

Restricciones

Datos de los

Items

Fig. 13

3.1.6.8. Configurar datos de los items

Aquí se realiza cualquier modificación que sea necesaria para

verificar el estado de un ítem.

Usuario

Servidor Apache

Base de Datos

Servidor de

Monitoreo

Actualizando Base de

Datos

Items

Flujo

Datos del Items


Datos del

Items

Configuración de los

Items

Fig. 14

3.1.6.9. Ingreso de triggers

En este diagrama luego de definir los items a monitorear, es

necesario ingresar los triggers que se van a activar en caso de que

la expresión a evaluar definida en el item sea verdadera, al

acceder se podrá ingresar nuevos triggers ejecutándose al

momento de efectuarse algún evento.

Usuario Servidor Apache

Base de Datos

Servidor de Monitoreo


Solicitud de Nuevo Triggers

Flujo



Datos de los

Triggers

Datos del

Nuevo

Triggers

Fig. 15

3.1.7. Diagrama de bloque del reporte de alertas

Este Bloque permite a los usuarios configurar alarmas vía correo

electrónico o SNMP para cualquier evento que así lo requiera. Esto

permite una reacción rápida a los problemas del servidor.

El proceso consiste en tomar las alarmas y filtrar aquellas que se

encuentren asociadas a un método de alerta definido. Cuando las

alarmas pasan por estos filtros son convertidas en alertas, siendo

luego enviadas según el criterio establecido.

El sistema posee la capacidad de configurar múltiples destinos para

dichas alertas. Para ello se deben definir los distintos usuarios de

alerta y luego asignarles rangos de responsabilidad sobre las alarmas-

alertas. Los criterios utilizados pueden referirse a condiciones de

horarios, o zonas, distribuyéndose las alertas de acuerdo a los

mismos.

Se encuentran definidos dos posibles procedimientos de alerta:

Vía E-mail: El usuario de alerta será informado de la alarma

vía e-mail. Las especificaciones del mensaje incluyen la dirección

destino y la dirección fuente, el evento ocurrido, la severidad de la

alarma y la fecha.

Vía Scrip: El evento es redirigido tal cual fue recibido por el

módulo Reporte a un usuario de alerta que actúa de Agente

SNMP.

Proporcionará tres parámetros de línea de orden a la escritura: el

destinatario, Asunto y Mensaje.

A

L

E

R

T

A

1

ASIGNACIÓN

DE ALERTAS

USUARIOS DE ALERTAS

SNMP E-MAIL

F

L

U

J

O

S

E-MAIL

SCRIP

FILTROS 1…N

FILTROS 1…N

ALARMAS

A

L

E

R

T

A

2

A

L

E

R

T

A

N

A

L

E

R

T

A

1

A

L

E

R

T

A

N

A

L

E

R

T

A

2

AGENTE DE EVENTOS

Fig. 16

E-MAIL

3.2. Limites de la información y el entorno del sistema.

En el sistema de monitoreo de servicios en equipos Linux cada

proceso demonio requiere varias conexiones al servidor de base

de datos.

La cantidad de memoria asignada para la conexión depende de

la configuración de la base de datos de datos.

El monitor principal es incapaz de recibir un valor debido a fallos

fallo en los enlaces de comunicación representados en la

configuración del agente.

3.3 Diseño de Datos

La Base de datos escogida para dar soporte a la aplicación fue

MySQL debido a que consume pocos recursos del sistema, tanto de

CPU como memoria, se distribuye bajo los términos de GPL (General

Public License), posee un mejor y mayor número de utilidades de

administración, PHP consta con un conjunto de funciones para

trabajar con MySQL, No tiene limite en el tamaño de los registros y no

necesita ejecutar frecuentemente VACUUM.

El diccionario de datos está compuesto por todos los objetos

definidos para el desarrollo de la aplicación y esto incluye la base de

datos con sus tablas y usuarios de conexión.

El Nombre de la Base de Datos es ZABBIX y contiene tablas, índices,

relaciones, restricciones, permisos y usuarios.

3.3.1. Estructura de la Base de Datos

La Base de datos juega un papel importante al almacenar:

Usuarios de la Aplicación

Parámetros monitoreados.

Acciones a tomar por cada trigger que se active, y

Histórico de los valores de los parámetros monitoreados.

A Continuación se realiza una descripción de:

Tablas

Claves primarias

Claves Foráneas

3.3.2. Tablas

Conjunto de Campos almacenados que mantienen relación

entre sí. A continuación detallaremos cada una de las tablas:

3.3.2.1. ACTIONS

Listado de las acciones que se aplican cuando un trigger

cambia de estado.

actionid int(4) NOT NULL auto_increment

triggerid int(4) DEFAULT '0' NOT NULL

userid int(4) DEFAULT '0' NOT NULL

scope int(4) DEFAULT '0' NOT NULL

severity int(4) DEFAULT '0' NOT NULL

good int(4) DEFAULT '0' NOT NULL

delay int(4) DEFAULT '0' NOT NULL

subject varchar(255) DEFAULT '' NOT NULL

message blob DEFAULT '' NOT NULL

nextcheck int(4) DEFAULT '0' NOT NULL

recipient int(1) DEFAULT '0' NOT NULL

PRIMARY KEY (actionid)

KEY (triggerid)

3.3.2.2. ALARMS

Registra el cambio de estado de los triggers, lo que permite

llevar un histórico de de estos cambios, al crear un nuevo

registro en la tabla, cada vez que un trigger cambia de estado.

alarmid int(4) NOT NULL auto_increment


clock int(4) DEFAULT '0' NOT NULL

value int(4) DEFAULT '0' NOT NULL

PRIMARY KEY (alarmid)

KEY (triggerid,clock)

KEY (clock)

3.3.2.3. ALERTS

Contiene el listado de las acciones a tomar en caso de que un

trigger se active y el tipo de alerta enviadas a los usuarios.

alertid int(4) NOT NULL auto_increment,

actionid int(4) DEFAULT '0' NOT NULL


mediatypeid int(4) DEFAULT '0' NOT NULL

sendto varchar(100) DEFAULT '' NOT NULL

subject varchar(255) DEFAULT '' NOT NULL

message blob DEFAULT '' NOT NULL

status int(4) DEFAULT '0' NOT NULL

retries int(4) DEFAULT '0' NOT NULL

PRIMARY KEY (alertid)

INDEX (actionid)

KEY clock (clock)

KEY status_retries (status, retries)

KEY mediatypeid (mediatypeid)

3.3.2.4. CONFIG

Contiene la definición de los parámetros globales de la

aplicación. Se especifica cual será el servidor de correo que

permita enviar las alertas a los usuarios de la aplicación cada

vez que se activen los triggers.

smtp_server varchar(255) DEFAULT '' NOT NULL

smtp_helo varchar(255) DEFAULT '' NOT NULL

smtp_email varchar(255) DEFAULT '' NOT NULL

alert_history int(4) DEFAULT '0' NOT NULL

alarm_history int(4) DEFAULT '0' NOT NULL

3.3.2.5. FUNCTIONS

Listado de las funciones empleadas por las expresiones a

evaluar, utilizadas en los triggers.

functionid int(4) NOT NULL auto_increment

itemid int(4) DEFAULT '0' NOT NULL


lastvalue varchar(255)

function varchar(10) DEFAULT '' NOT NULL

parameter varchar(255) DEFAULT '0' NOT NULL

PRIMARY KEY (functionid)

KEY triggerid (triggerid)

KEY itemidfunctionparameter (itemidfunctionparameter)

3.3.2.6. GRAPHS

Lista de los gráficos definidos por el usuario, de los parámetros

que desee visualizar gráficamente, entre ellos: carga del

procesador, número de procesos que se están ejecutando,

número de sesiones y el tráfico generado de los diferentes

servidores monitoreados.

graphid int(4) NOT NULL auto_increment

name varchar(128) DEFAULT '' NOT NULL

width int(4) DEFAULT '0' NOT NULL

height int(4) DEFAULT '0' NOT NULL

PRIMARY KEY (graphid)

UNIQUE (name)

3.3.2.7. GRAPHS_ITEMS

Contiene la lista de los ítems monitoreados que se representan

en los gráficos.

gitemid int(4) NOT NULL auto_increment

graphid int(4) DEFAULT '0' NOT NULL


drawtype int(4) DEFAULT '0' NOT NULL

sortorder int(4) DEFAULT '0' NOT NULL

color varchar(32) DEFAULT 'Dark Green' NOT NULL

PRIMARY KEY (gitemid)

3.3.2.8. HISTORY

Histórico de los valores de los items.



value double(164) DEFAULT '0.0000' NOT NULL

3.3.2.9. HISTORY_STR



value varchar(255) DEFAULT '' NOT NULL

3.3.2.10. HOST

Contiene el listado de los equipos monitoreados.

hostid int(4) NOT NULL auto_increment

host varchar(64) DEFAULT '' NOT NULL

useip int(1) DEFAULT '1' NOT NULL

ip varchar(15) DEFAULT '127.0.0.1' NOT NULL

port int(4) DEFAULT '0' NOT NULL


disable_until int(4) DEFAULT '0' NOT NULL

network_errors int(4) DEFAULT '0' NOT NULL

PRIMARY KEY (hostid)

UNIQUE (host)

KEY (status)

3.3.2.11. ITEMS

Guarda las definiciones de los ítems monitoreados.

itemid int(4) NOT NULL auto_increment

type int(4) DEFAULT '0' NOT NULL

snmp_community varchar(64) DEFAULT '' NOT NULL

snmp_oid varchar(255) DEFAULT '' NOT NULL

snmp_port int(4) DEFAULT '161' NOT NULL

hostid int(4) NOT NULL

description varchar(255) DEFAULT '' NOT NULL

key_ varchar(64) DEFAULT '' NOT NULL

delay int(4) DEFAULT '0' NOT NULL

history int(4) DEFAULT '0' NOT NULL

lastdelete int(4) DEFAULT '0' NOT NULL

nextcheck int(4) DEFAULT '0' NOT NULL

lastvalue varchar(255) DEFAULT NULL

lastclock int(4) DEFAULT NULL

prevvalue varchar(255) DEFAULT NULL


value_type int(4) DEFAULT '0' NOT NULL

trapper_hosts varchar(255) DEFAULT '' NOT NULL

units varchar(10) DEFAULT '' NOT NULL

multiplier int(4) DEFAULT '0' NOT NULL

delta int(1) DEFAULT '0' NOT NULL

prevorgvalue double(164) DEFAULT NULL

PRIMARY KEY (itemid)

UNIQUE shortname (hostidkey_)

KEY (hostid)

KEY (nextcheck)

KEY (status)

3.3.2.12. MEDIA

Mantiene el listado de los medios (correos) por los que se

notificarán las alertas a los usuarios.

mediaid int(4) NOT NULL auto_increment

userid int(4) DEFAULT '0' NOT NULL

type varchar(10) DEFAULT '' NOT NULL

mediatypeid int(4) DEFAULT '0' NOT NULL

sendto varchar(100) DEFAULT '' NOT NULL

active int(4) DEFAULT '0' NOT NULL

severity int(4) DEFAULT '63' NOT NULL

PRIMARY KEY (mediaid)

KEY (userid)

KEY (mediatypeid)

3.3.2.13. RIGHTS

Contiene la lista de los permisos asignados a los usuarios de la

aplicación.

rightid int(4) NOT NULL auto_increment

userid int(4) DEFAULT '' NOT NULL

name char(255) DEFAULT '' NOT NULL

permission char(1) DEFAULT '' NOT NULL

id int(4)

PRIMARY KEY (rightid)

3.3.2.14. SERVICES

Listado de los servicios definidos por el usuario a ser

monitoreados en los diferentes servidores.

serviceid int(4) NOT NULL auto_increment



algorithm int(1) DEFAULT '0' NOT NULL

triggerid int(4)

showsla int(1) DEFAULT '0' NOT NULL

goodsla double(32) DEFAULT '99.9' NOT NULL

sortorder int(4) DEFAULT '0' NOT NULL

PRIMARY KEY (serviceid)

3.3.2.15. SERVICE_ALARMS

En esta tabla se almacenan las alarmas relacionadas a los

diferentes servicios que están siendo monitoreados.

servicealarmid int(4) NOT NULL auto_increment

serviceid int(4) DEFAULT '0' NOT NULL



PRIMARY KEY (servicealarmid)

KEY (serviceidclock)

KEY (clock)

3.3.2.16. SERVICES_LINKS

En esta tabla están definidas las conexiones entre los

diferentes servicios.

linkid int(4) NOT NULL auto_increment

serviceupid int(4) DEFAULT '0' NOT NULL

servicedownid int(4) DEFAULT '0' NOT NULL

soft int(1) DEFAULT '0' NOT NULL

PRIMARY KEY (linkid)

KEY (serviceupid)

KEY (servicedownid)

UNIQUE (serviceupidservicedownid)

3.3.2.17. SESSIONS

Registro de las sesiones establecidas por los usuarios.

sessionid varchar(32) NOT NULL DEFAULT ''

userid int(4) NOT NULL DEFAULT '0'

lastaccess int(4) NOT NULL DEFAULT '0'

PRIMARY KEY (sessionid)

3.3.2.18. TRIGGERS

Listado de los triggers, en esta tabla se almacena el estado del

trigger y la expresión que se evaluará al momento de

determinar el estado del trigger.

triggerid int(4) NOT NULL auto_increment

expression varchar(255) DEFAULT '' NOT NULL

description varchar(255) DEFAULT '' NOT NULL

url varchar(255) DEFAULT '' NOT NULL



priority int(2) DEFAULT '0' NOT NULL

lastchange int(4) DEFAULT '0' NOT NULL

dep_level int(2) DEFAULT '0' NOT NULL

comments blob

PRIMARY KEY (triggerid)

KEY (status)

KEY (value)

3.3.2.19. USERS

Listado de los usuarios de la aplicación.

userid int(4) NOT NULL auto_increment

alias varchar(100) DEFAULT '' NOT NULL


surname varchar(100) DEFAULT '' NOT NULL

passwd char(32) DEFAULT '' NOT NULL

PRIMARY KEY (userid)

UNIQUE (alias)

3.3.3. Claves Primarias

Se definen claves primarias para las tablas más importantes y

que necesitan un índice de búsqueda y control de duplicación.

A continuación definiremos las claves primarias de cada una de

las tablas.

ACTIONS

PRIMARY KEY (actionid)

ALARMS

PRIMARY KEY (alarmid)

ALERTS

PRIMARY KEY (alertid)

FUNCTIONS

PRIMARY KEY (functionid)

GRAPHS

PRIMARY KEY (graphid)

GRAPHS_ITEMS

PRIMARY KEY (gitemid)

HOST

PRIMARY KEY (hostid)

ITEMS

PRIMARY KEY (itemid)

MEDIA

PRIMARY KEY (mediaid)

RIGHTS

PRIMARY KEY (rightid)

SERVICES

PRIMARY KEY (serviceid)

SERVICE_ALARMS

PRIMARY KEY (servicealarmid)

SERVICES_LINKS

PRIMARY KEY (linkid)

SESSIONS

PRIMARY KEY (sessionid)

TRIGGERS

PRIMARY KEY (triggerid)

USERS

PRIMARY KEY (userid)

3.4. Diseño De Interfaz

3.4.1. Pagina De Autentificación

Permite ingresar el login y el password respectivo ad los usuarios autorizados

para manejar el sistema, ya sea usuarios de consultas o lectura y escritura.

3.4.2. Pagina De Configuración

Permite el ingreso tanto del servidor y cadena SMTP, nombre de la cuenta

desde donde se enviará las alertas configuradas a los usuarios.

3.4.3. Pagina De Usuarios

Se realiza el ingreso y la configuración de los usuarios que van ha interactuar

con la aplicación; se definen tanto perfiles como permisos a los usuarios a

los diferentes recursos.

Ingreso de usuario:

Se crea el usuario, se ingresa el nombre, la descripción, el perfil y la

contraseña que va ha utilizar

Modificación o Asignación de permisos

La asignación de recursos y los permisos de accesos concedidos se

modifican luego de haber creado el usuario.

Notificación de Cuenta de Correo

El ingreso y/o modificación de la cuenta de correo en la que el usuario va ha

recibir los mensajes de alerta.

3.4.4 Equipos

Permite el ingreso de un nuevo equipo a monitorear y un listado de los

equipos que están siendo monitoreados.

Modificación de Configuración de los equipos monitoreados

Se presenta una página para modificar los parámetros del equipo va ha ser

monitoreado.

3.4.5. Servicios

Ingreso de los servicios a monitorear de los diferentes servidores a

monitorear

Presentación de Servicios

Muestra una tabla con los servicios que va han monitorearse en determinado

servidor.

CAPITULO 4

4. DESARROLLO Y PRUEBA DEL SISTEMA

En esta etapa hemos realizado algunas actividades con el fin de verificar el

sistema de acuerdo al alcance planteado, así como su instalación y

funcionamiento en general.

4.1. La creación de bases de datos.

La creación de las bases de datos se inicia con la construcción del

modelo y el esquema conceptual de la base de datos:

4.1.1. El esquema conceptual.

El esquema conceptual puede definirse como una descripción

abstracta y general de la parte o sector del universo real que el

contenido de la base de datos va a representar, llamada en ocasiones

"universo del discurso".

En este nivel de análisis se está tratando con una descripción de la

realidad, no con datos, y suele contener listas de tipos de entidades,

de las relaciones existentes entre esas entidades y de las restricciones

de integridad que se aplican sobre ellas. El esquema conceptual de la

base de datos puede utilizarse para integrar los intereses de los

diferentes usuarios, como herramienta de representación y de

formación, así como para prever futuras modificaciones del sistema.

En el aspecto de la representación, lo más interesante es utilizar algún

tipo de especificación formal en sentido matemático, lo que facilita la

consistencia y los análisis lógicos de nuestros esquemas propuestos.

Del esquema conceptual formalizado pueden derivarse diferentes

sub.-esquemas conceptuales, que representan aquellas partes del

esquema conceptual de interés para un usuario o grupo de usuarios

finales.

4.1.2. El esquema de la base de datos.

Una vez construido el esquema conceptual, el diseño de bases de

datos obliga a realizar varias tareas previas a la construcción del

esquema lógico global del sistema, también llamado esquema de

bases de datos. Por el momento, basta saber que el esquema de la

base de datos representa la descripción de los datos, mientras que el

esquema conceptual representaba a la realidad. La primera de las

tareas necesarias es la identificación de los datos requeridos, para

obtener como resultado las partes del área de aplicación que deben

representarse mediante datos, y en que forma deben presentarse

éstos a los usuarios. El siguiente paso es el análisis de datos,

consistente en la definición y clasificación de esos datos, su

descripción, que suele presentarse en forma de diccionario de datos,

como una "metabase de datos". Por último, debe hacerse la

especificación de los paquetes de entrada y de salida,

correspondientes con los datos que deben introducir y obtener como

respuesta los usuarios, según sus necesidades. Las tres tareas

habrán permitido obtener tres documentos sobre descripción del área

de aplicación, definición y clasificación de los datos y especificación de

las características de los diversos paquetes, respectivamente.

Tomando como punto de partida estos tres elementos, se construye la

especificación de esquema de la base de datos, que responderá al

contenido total de la base de datos y las características de las vías de

acceso requeridas a través de estos datos. Frente al análisis de datos,

que es la definición y clasificación de los datos, el esquema se

encarga de la utilización de esos datos.

4.1.3. El diccionario de recursos de información

La gestión efectiva de los datos involucrados en la base de datos

implica necesariamente disponer de alguna herramienta que controle

las características y funciones de aquéllos. Esta función es cubierta

mediante el diccionario de recursos de información (DRI), que asegura

la integración de toda la información contenida en el sistema. Se habla

entonces de metadatos, como datos que definen y describen los datos

existentes en el sistema. En un primer momento, este tipo de

cuestiones eran resueltas a través de los diccionarios de datos, que

reunían información sobre los datos almacenados, sus descripciones,

significados, restricciones, usos, etc., y los directorios de datos,

subsistemas del sistema de gestión, encargados de describir dónde y

cómo se almacenaban los datos, Actualmente se aplica el concepto de

diccionario de recursos de información, que engloban todo lo señalado

anteriormente, dando lugar a lo que ha pasado a llamarse

"metabases".

4.1.4. El enfoque de tratamiento de los datos.

La construcción de los modelos conceptual y lógico de las bases de

datos requiere la adopción de un determinado enfoque para la

descripción y el tratamiento de los datos. Sin embargo, es necesario

insistir en que la modelización de datos se orienta al conocimiento en

profundidad de los datos que va a manejar la organización, para lograr

una implantación óptima. La unión del modelo de datos con el sistema

de gestión de base de datos dará como resultado la base de datos

real.

El modelo de datos será una representación gráfica orientada a la

obtención de las estructuras de datos de forma metódica y sencilla,

agrupando esos datos en entidades identificables e individualizables, y

será reflejo del sistema de información en estudio.

4.1.5. El enfoque entidad-relación

Por sus características, se ha seleccionado el enfoque entidad-

relación propuesto. Este modelo toma como punto de partida

considerar la existencia de entidades, que representan objetos,

personas, etc., sobre las que se quiere almacenar información

relevante. Las entidades con las mismas características forman un tipo

de entidad. A las características necesarias para describir

completamente a cada tipo de entidad se les denominará atributo.

Posteriormente, las entidades y sus atributos se representan

físicamente a través de tablas (transformación en un modelo

relacional) en las que los datos se almacenan en dos dimensiones.

Las filas de la tabla contienen los atributos de cada una de las

entidades, y las columnas el conjunto de atributos del mismo tipo de

cada entidad. El grado de la tabla corresponderá al número de

columnas de la tabla. En este momento estaremos trasladando el

modelo semántico entidad/relación al modelo clásico relacional, se

decir, la transformación entre el modelo conceptual y el lógico. El

principio fundamental en este modelado, que no puede obviarse de

ninguna forma, es que hechos distintos deben almacenarse en objetos

distintos.

4.1.6. La normalización.

El modelo conceptual de datos obtenido mediante la técnica de

entidad-relación será refinado y convertido en un modelo lógico

relacional, utilizando la normalización, lo que ofrecerá como resultado

el conjunto de tablas a implementar en la base de datos. Su finalidad

es reducir las inconsistencias y redundancias de los datos, facilitar el

mantenimiento y evitar las anomalías en las manipulaciones de datos.

El objetivo será obtener un modelo lógico normalizado que represente

las entidades normalizadas y las interrelaciones existentes entre ellas.

Para ello, se toma como punto teórico de partida el concepto de

dependencia funcional, que dice: "Un atributo B depende

funcionalmente de otro atributo A, de la misma entidad si a cada valor

de A le corresponde sólo un valor de B." Lo anterior se completa

mediante la dependencia funcional completa y la dependencia

transitiva.

A mayor nivel de normalización, mayor calidad en la organización de

los datos y menor peligro para la integridad de los datos. Este

procedimiento consiste en ir alcanzando formas normales

Todo el proceso se basa en que una primera relación universal

plantearía enormes problemas de redundancia, consistencia e

integridad de los datos, por lo que es necesario mejorar las relaciones.

Estas mejoras deben dar como resultado tablas equivalentes y

mejores que sus respectivas originales, y poseer siempre tres

propiedades: conservación de la información (de atributos y de tuplas),

conservación de dependencias y mínima redundancia de los datos.

Las mejoras introducidas obligan a plantear hasta que Forma Normal

es necesario llegar, es decir, a que nivel de depuración. Normalmente,

es recomendable alcanzar la máxima Forma Normal, aunque luego es

muy probable que restricciones existentes, de algún tipo, obliguen a

retroceder a un nivel inferior de normalización, o incluso a cierto nivel

de "desnormalización".

4.2. Creación de los componentes

Con los métodos que se han expuesto, el diseño de nuestra base de

datos relacional puede seguimos el siguiente camino:

Fase 1: Diseño conceptual de la base de datos

Esta fase se subdivide en otras dos. La Fase 1a corresponde al Diseño

del esquema conceptual, esquema de especificación del modelo de datos

a alto nivel, independiente de cualquier SGBD, que no puede utilizarse

para implementar directamente la estructura de la base de datos. Para

obtenerlo puede adoptarse un enfoque de esquema centralizado (en el

cual se unen previamente los diferentes requerimientos a la realización

del esquema), o un enfoque de integración de vistas (en el cual se unen

los esquemas de cada requerimiento en uno global realizado a posteriori).

La Fase 1b corresponde al diseño de transacciones, es decir, a aquellas

aplicaciones que van a manipular datos contenidos en la base de datos.

Se suelen identificar mediante el estudio de las entradas y salidas de

datos y su comportamiento funcional. De esta forma se identifican

transacciones de recuperación, de actualización y mixtas.

Fase 2: Elección de un SGBD.

Se consideran diferentes factores técnicos, económicos y de beneficio, de

servicio técnico y formación de usuarios, organizativos de rendimiento,

etc. Sin embargo, resulta difícil la medida y cuantificación ponderada de

los diferentes factores.

Fase 3: Transformación del modelo de datos (o fase de diseño lógico).

En esta fase creamos un esquema conceptual y los esquemas externos

necesarios en el modelo de datos del SGBD seleccionado, mediante la

transformación de los esquemas de modelo de datos a alto nivel

obtenidos en la Fase 1a, al modelo de datos ofrecido por el SGBD.

Fase 4: Diseño de la base de datos física.

Consiste en definir las estructuras de almacenamiento y de acceso para

alcanzar una rendimiento óptimo de las aplicaciones de la base de datos.

Los criterios adoptados suelen ser el tiempo de respuesta, la utilización

de espacio y el volumen de transacciones por minuto.

Fase 5: Implementación del sistema de base de datos.

En esta fase final se hace realidad la base de datos, mediante la creación

y la compilación del esquema de bases de datos y de los ficheros de

bases de datos, así como de las transacciones, a través de las

aplicaciones. La metodología expuesta, que puede servir como marco de

referencia general, puede modificarse según las características del

contexto en el que se diseña e implanta el sistema de bases de datos.

4.3. Migración de datos

Una sesión típica de migración comprende:

Análisis de las plataformas, aplicaciones e información que son el

objeto de la migración.

Formalización de reglas de conversión.

Uso del “aplacador de reglas”. La documentación generada sirve para

añadir nuevas reglas al sistema y puntualiza los sitios donde se deben

hacer las transformaciones semánticas.

Análisis de la información trasformada, utilizando herramientas para

garantizar una migración que aproveche mejor los recursos

disponibles en la nueva plataforma.

Pasos de la Migración

Paso 1: Limpiar la BD

Paso 2: Obtener una BD consistente

Paso 3: Realizar el mapeo de los campos

Paso 4: Transformar las reglas de catalogación

Paso 5: Incorporar registros de la BDU

Limpiar la BD:

Observar la FDT de la BD Original

Campos que se dejaron de usar

Campos que se utilizan en los últimos registros

Información que estaba en un campo y ahora está en otro.

4.4. Seguridad

Un sistema de monitoreo debe ser muy seguro. Los administradores de

redes tienen el control de toda la tecnología de información por lo que si

un atacante consigue tener acceso a sus herramientas, obtendrá el

control sobre todos los recursos.

Este requisito se cumplirá en el proyecto mediante el uso de la

autenticación.

4.4.1. Sistema operativo

El software que ejecutaran los servidores a monitorear funcionará

sobre un sistema operativo multitarea y multiusuario. En concreto, se

empleara una distribución de Linux (RendHat 9.0) que cuenta con la

suficiente estabilidad para un sistema de estas características críticas

de operación y facilita la programación de procesos de usuario y

drivers para cada uno de los periféricos a controlar.

La instalación de dicho sistema operativo cuenta con dos

consideraciones principales en nuestra aplicación: por un lado, es

necesario conseguir un sistema perfectamente funcional en 48 MB de

espacio (capacidad del disco); por otro lado, las peculiaridades de la

instalación de los agentes necesarios para monitorizar.

4.4.2. Del sistema

Nuestra aplicación ofrece privilegios a los usuarios debido a esto

deben autentificarse adecuadamente al iniciar una sesión. El usuario

proporciona su nombre de usuario y contraseña y el procedimiento de

inicio de sesión usa el nombre de usuario y la contraseña para

autentificar el inicio de sesión para verificar que el usuario es quien

dice ser.

4.5. Pruebas

4.5.1. La prueba de entrada

En este tipo de prueba hemos verificado si la estructura de

codificación cumple con las guías y especificaciones del diseño,

también hemos hecho una auto-prueba con los usuarios finales del

sistema para saber si están llenando correctamente los parámetros

necesarios para el correcto funcionamiento de la aplicación. Muchas

organizaciones contratan personas cuya única función es capturar

datos siendo de gran importancia una capacitación adecuada para la

captura de datos.

4.5.2. La prueba de salida

En esta etapa hemos probado las entradas a la base de datos

revisando la utilidad y exactitud de la salida resultante. Es decir la

generación de los reportes tanto en formato texto como en formato

gráfico. Esto lo hicimos en conjunto con nuestro director de tesis el

Ing. Carlos Carranza.

4.5.3. Prueba de la base de datos

Esta prueba nos permitió determinar si la base de datos satisface las

necesidades de la aplicación, comprobando que durante la misma se

ha mantenido estable asegurándonos que las bases de datos

contengan la información que satisfaga todas las demandas que se le

plantean.

4.5.4. Prueba de los controles

El propósito primordial de esta prueba es medir el nivel de seguridad

de nuestra aplicación, generando transacciones que puedan violar la

integridad del sistema. Como las verificaciones de límite y

racionalidad, pruebas aritméticas etc.

Algunas pruebas de control que realizamos son:

Tratar de leer o escribir en un archivo incorrecto.

Introducir varios campos con datos incompletos o faltantes.

Tratar de procesar una transacción delicada sin la autorización

apropiada y ver si el sistema lo rechaza.

Hacer verificaciones de caracteres numéricos, alfabéticos y

especiales.

Realizar verificaciones de validez de campos clave.

Introducir una clave inválida y ver como responde el sistema.

Además hemos realizado las pruebas de la Interfaz de cada modulo

para asegurarnos que la información fluya en forma adecuada hacia

y desde la unidad del programa que está siendo probada.

Se analizaron las estructuras de datos para asegurar que los datos

mantienen su integridad temporal durante todos los pasos de

ejecución, probando todos los caminos de manejo de errores.

4.6. Conclusión

Con este capitulo hemos participando en la planificación y diseño de las

pruebas del sistema para asegurarnos de que el software funciona en

forma adecuada y comprobando que se hayan integrado correctamente

cada uno de los elementos del sistema.

CAPITULO 5

5. IMPLEMENTACION DEL SISTEMA

El sistema de MONITOREO DE SERVICIOS EN EQUIPOS LINUX, funciona

plenamente, encontrando en él nuevos métodos y controles para la

administración de redes. El sistema se ha implantado de manera gradual,

aprovechando las ventajas de la modularidad, llevando a cabo la instalación

de una nueva etapa una vez que fue aceptada sin hacer uso necesario de

recursos extras.

5.1. Elementos físicos

Los elementos físicos que hemos utilizado para la implementación de

nuestro proyecto son dos equipos propiedad de los integrantes de la tesis,

que se detallan a continuación:


PROCESADOR INTEL PENTIUM III INTEL PENTIUM IV

MAINBOARD PC CHIPS 133MHZ INTEL 133 MHZ

MEMORIA RAM 256 MB 256 MB.

CAPACIDAD DE DISCO DURO 40 GB. 80 GB.

AMPLITUD DEL BUS 32 BITS 32 BITS

MONITOR SVGA DE 17” SVGA DE 17”

FRECUENCIA DEL BUS 733 MHZ 1.7 GHZ

CARACTERISTICAS PCA “CLIENTE”

PROCESADOR Intel Pentium III

MEMORIA RAM 256 MB.






SISTEMA OPERATIVO WINDOWS XP Y LINUX

OFFICE XP



WINZIP Empaquetador de archivos versión 8.1


PHP Lenguaje de programación Versión 4.0


MYSQL Base de Datos

CARACTERISTICAS PCB “SERVIDOR”

PROCESADOR Intel Pentium IV

MEMORIA RAM 256 MB.




FRECUENCIA DE RELOJ 1.7 GHZ.


SISTEMA OPERATIVO LINUX

OFFICE XP



WINZIP Empaquetador de archivos versión 8.1

LENGUAJE C Lenguaje de programación Borland C++

PHP Lenguaje de programación Versión 4.0

APACHE SERVER Servicio que levanta al servidor de paginas Web

MYSQL Base de Datos

Como se detalla en las características de cada equipo uno funciona como

cliente o equipo a ser monitoreado y el otro funciona como servidor en

donde encontramos la aplicación de monitoreo.

Además hemos hecho uso de la red de los laboratorios de civil de la

carrera con previa autorización que cuentan con:


1 Hub o switch.

Conexiones de red

Es decir la tecnología básica para un funcionamiento de nuestra

aplicación.

5.2. Elementos lógicos

El elemento lógico necesario para la implementación del sistema y que

se encuentra instalado en los equipos de los integrantes del proyecto es:


SISTEMA OPERATIVO LINUX RED HAT 9.0 LINUX RED HAT 9.0

EXPLORADOR WEB MOZILLA MOZILLA

LENGUAJE DE

PROGRAMACION

C

C++

PHP

C

C++

PHP

SERVIDOR WEB APACHE SERVER APACHE SERVER

BASE DE DATOS MySQL MySQL

5.3. Elementos humanos

Las personas encargadas de la implementación del sistema de

MONITOREO DE SERVICIOS EN EQUIPOS LINUX, se listas a

continuación:

José Luis Chica Bermúdez

Darwin Vélez Fernández

Freddy Villafuerte Navarro

Guiados por el director de proyectos el Ing. Carlos Carranza

5.4. Infraestructuras

Como infraestructura básica para la implementación de nuestro sistema

hemos utilizado una red LAN, temporalmente armada en nuestros

domicilios, además para las revisiones respectivas hemos empleado las

redes de los laboratorios de civil previa autorización de la carrera.

5.5. Capacitación de los usuarios

Los sistemas de las compañías más prestigio pueden tener éxito o

fracasar debido a la forma en que se operan y se usan. Como

consecuencia la calidad de capacitación recibida por el personal que

manipulará el sistema ayuda u obstruye, y puede llegar a impedir, la

implantación exitosa de un sistema de información.

Aquellas personas que se encuentren asociadas o afectadas por el

sistema deben conocer cuál es su papel, cómo pueden usar el sistema y

qué hará o no hará el sistema. Tanto operadores como los usuarios del

sistema requieren de capacitación.

5.5.1. Capacitación de operadores

El buen uso de nuestro sistema depende del personal de Centro de

Cómputo, y del Administrador en especial el cual se encarga de

mantener un control sobre toda la infraestructura en el centro de

cómputo, así como de proporcionar el apoyo necesario. La

capacitación que el personal reciba debe de asegurar que puedan

manejar todas las operaciones posibles, tanto rutinarias como

extraordinarias. Cabe mencionar que para poder manipular nuestra

aplicación debe tener conocimientos básicos en Linux.

La capacitación que reciba el operador también debe contemplar al

personal de captura de datos.

Si el sistema requiere de la instalación de equipos nuevos, el personal

debe ser capacitado en lo necesario así como conocimiento de lo que

es su operación y su uso normal. Como parte de la capacitación se

otorgará al personal una lista de formas de resolver los problemas y

sus posibles soluciones, así como datos personales de los entes a

quién buscar cuando surjan problemas inesperados.

5.5.2. Capacitación de usuarios

La capacitación de usuarios incluye la identificación de problemas,

determinando si el problema que surge es ocasionado por hardware o

por software, o por algo realizado por los mismos usuarios que

ocasione la falla del sistema.

No hay nada más desesperante que trabajar con un sistema y que

suceda un problema y no ser capaz de determinar si es falla del propio

sistema, del equipo o de los usuarios.

La mayor parte de la capacitación de los usuarios que manipulen

nuestros sistemas deben tener las pautas en la captura de datos

(Cómo modificar datos previamente almacenados), la formulación de

consultas (Cómo localizar información específica). La parte

fundamental de la capacitación cae sobre esta actividad dedicándose

la mayor parte del tiempo a esta área.

En algunos casos los usuarios tienen que tener conocimientos básicos

en Linux.

En la capacitación de usuarios hemos tomado en cuenta dos aspectos

importantes mencionados anteriormente los cuales consisten en la

familiarización con el sistema de procesamiento en sí (es decir, el

equipo usado para la captura y procesamiento de datos) y la

capacitación en el uso de la aplicación(es decir, el software que acepta

los datos, los procesa y produce los resultados). La debilidad de

cualquier aspecto de la capacitación puede ser una posibilidad para la

generación de errores.

5.6. Conclusiones

En este capitulo hemos participados en la implantación gradual del

sistema, dando un seguimiento a cada una de la etapas previniendo los

posibles errores e implantando planes de emergencia adecuados.

CAPITULO 6

6. Recomendaciones y conclusiones de la tesis

6.1. Recomendaciones de hardware

Requerimientos Recomendados de Instalación del Cliente

CARACTERISTICAS DESCRIPCION

Procesador: Pentium-class 200 MHz o superior

RAM: 192MB para modo gráfico

Disco Duro: 4.5GB para instalación completa

Monitor: SVGA (1024x768) para ambiente gráfico

CD –ROM: 32x con auto inicialización

Requerimientos Recomendados de Instalación del servidor


Procesador: Pentium-III 1,2 GHz o superior

RAM: 256 MB

Disco Duro: 80 GB para soporte de la base de datos



6.2. Recomendaciones del software

Recomendamos para el caso del servidor tener instalado todos los

paquetes de Linux RedHat 9.0 evitando problemas en lo posterior.

6.3. Recomendaciones de la infraestructura de comunicación

Recomendamos la utilización de un LAN con sus respectivas

características de cableado estructurado.

6.4. Recomendaciones de seguridades

La seguridad de un sistema no sólo está en dependencia de la calidad del

software o del hardware que se utiliza, es parte fundamental seguir ciertas

recomendaciones que garantizarán la verdadera seguridad de los

sistemas.

Para ello recomendamos se establezca una política de seguridad

construida con estas características como pautas:

Sencilla y no compleja

Fácil de mantener

Permitiéndonos:

Administración.

Evaluación de usuarios.

Evaluación de Passwords que cumplan con las normas de

seguridad.

Evaluación de Controles de acceso a la información

Procedimientos para control de virus.

Procedimientos de respaldo de la información.

Procedimientos de violación al sistema.

Bitácoras.

Procedimientos para hacer cumplir lo anterior

6.5. Conclusiones

José Luis Chica Bermúdez:

De acuerdo al conocimiento adquirido durante mi carrera puedo concluir

que el sistema presenta actualmente múltiples posibilidades de expansión

y mejora, quedando supeditadas a las necesidades del mercado y a los

adelantos de la tecnología. El sistema de MONITOREO DE SERVICIOS

EN EQUIPOS LINUX es una más de las múltiples soluciones que existen

actualmente para la gestión, pero que aspira desde su nucleo Open

Source a contribuir al conocimiento respecto de este tipo de aplicaciones.

Darwin Vélez Fernández:

En el análisis y desarrollo del sistema NetAdmin, hemos aplicado los

conocimientos adquiridos en los Seminarios de Graduación. Además, con

esta aplicación conocimos la diferencia del desarrollo de proyectos

académicos y proyectos laborales, que son totalmente distintos, ya que

en los buenos proyectos académicos obtenemos una evaluación

numérica y en el ámbito real laboral, la evaluación de estos se da como la

base del buen funcionamiento de toda una infraestructura organizacional,

en donde maduramos profesionalmente.

Freddy Villafuerte Navarro:

He tenido la oportunidad de ejercer el conocimiento, experiencia en el

medio real, esto se vive cuando uno egresa de la Ingeniería, por ello

considero que durante nuestra carrera aprendimos, aplicamos y

comprobamos académica y laboralmente nuestros estudios. En mi

opinión, las áreas de administración y la monitorización de sistemas son

complementarias. La administración precisa de la monitorización para

poder estudiar como afectan los cambios al comportamiento de los

sistemas, y la monitorización sirve de poco, si no podemos aprovechar la

información obtenida para mejorar nuestros sistemas.

REFERENCIAS.

[1] SNMP,SNMPv2, And CMIP. The practical Guide to Network-Management Standards, William Stallings, 1996.

[2] RFC821-SMTP. [3] RFC1155 – Structure and Identification of Management Information Base

for TCP/IP-Based Internets [5] RFC1213- MIB-II [6] RFC1157- Simple Network Management Protocol. [7] http://www.zabbix.com [8 http://www.apache.org [9] http://www.perl.org [10] http://www.mysql.com [11] http://www.gnu.org [12] http://www.linux.com [13] SNMP and SNMPv2. [14] SNMP-IMS (Simple Network Management Protocol Internet Management

System). [15] W. Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and

2, Addison-Wesley, 1999.

[16] A. S. Tanenbaum, Distributed systems : principles and paradigms, Prentice Hall, 2002.

[17] A. S. Tanenbaum, Redes de Computadoras, Prentice may

Hispanoamericana, 1997. [18] University of California at Davis, NET-SNMP Tutorial, 2001.

http://www.apache.org/

http://www.perl.org/

http://www.mysql.com/

http://www.gnu.org/

http://www.linux-mandrake.com/

GLOSARIO

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

A Administrador de la red

Persona responsable del funcionamiento, el mantenimiento y la gestión de una red.

Agente

1. En general, es el software que procesa consultas y devuelve respuestas en nombre de una aplicación.

2. En NMSs, es el proceso que reside en todos los dispositivos administrados, e informa los valores de variables especificadas a estaciones de gestión.

En la arquitectura de hardware Cisco, una tarjeta de procesador individual que provee una o más interfaces de medios.

Alarma

Mensaje que notifica a un operador o administrador sobre un problema de la red.

Arquitectura cliente-servidor

Término utilizado para describir los sistemas de red de informática distribuida en los cuales las responsabilidades de la transacción se dividen en dos partes: cliente (frontal) y servidor (nodo). Ambos términos (cliente y servidor) pueden aplicarse a programas de software o a dispositivos reales de computación. También llamado informática distribuida.

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#B

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#C

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#D

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#E

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#F

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#G

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#H

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#I

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#K

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#L

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#M

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#N

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#O

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#P

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#Q

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#R

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#S

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#T

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#U

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#V

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#W

http://medusa.unimet.edu.ve/electrica/fpie22/GLOSARIO_1.htm#X

B

BACKUP

Copia de seguridad. Se hace para prevenir una posible pérdida de información.

C

Checksum

Método para verificar la integridad de los datos transmitidos. Una checksum es un valor entero calculado a partir de una secuencia de octetos tomados por medio de una serie de operaciones aritméticas. El valor es recomputado en el extremo receptor y comparado para la verificación.

Cliente

Nodo o programa de software (dispositivo frontal) que solicita servicios a un servidor.

Comunidad

En SNMP, un grupo lógico de dispositivos gestionados y NMSs en el mismo dominio administrativo.

Comunidades SNMP

Sistema de autenticación que permite que un dispositivo de red inteligente valide las solicitudes SNMP de fuentes tales como el NMS.

Cookie.

Procedimiento ejecutado por el servidor que consiste en guardar información acerca del cliente para sus posterior recuperación En la práctica la información es proporcionada desde el visualizador al servidor del Word Wide Web vía una forma o un método interactivo que puede ser recuperado nuevamente cuando se acede al servidor en el futuro. Es utilizado por ejemplo para el registro a un servicio.

D

Dirección IP

1. Dirección de 32 bits asignada a los hosts que utilizan TCP/IP. Una dirección IP corresponde a una de cinco clases (A, B, C, D, o E) y se escribe en forma de 4 octetos separados con puntos (formato decimal con punto). Cada dirección consiste en un número de red, un número opcional de subred, y un número de host. Los números de red y de subred se utilizan conjuntamente para el enrutamiento, mientras que el número de host se utiliza para el direccionamiento a un host individual dentro de la red o de la subred. Para extraer la información de la red y de la subred de la dirección IP se utiliza una máscara de subred. También denominada dirección de Internet.

2. (IP address) Comando utilizado para establecer la dirección de red lógica de esta interfaz.

F FTP (File Transfer Protocol)

Protocolo de transferencia de archivos. Protocolo de aplicación, parte de la pila de protocolos TCP/IP, utilizado para transferir archivos entre nodos de red. FTP está definido en RFC 959.

H

HTTPS URL creada por Netscape Communications Corporation para designar documentos que llegan desde un servidor WWW seguro. Esta seguridad es dada por el protocolo SSL (Secure Sockets Layer) basado en la tecnología de encriptación y autentificación desarrollada por la RSA Data Security Inc.

Host

Sistema de computación en una red. Similar al término nodo excepto que el host usualmente implica un sistema de computación, mientras que un nodo generalmente se aplica a cualquier sistema en red, incluyendo los servidores de acceso y routers.

Hub (concentrador)

1. En forma general, un término utilizado para describir un dispositivo que sirve como centro de una red de topología en estrella.

2. Dispositivo de hardware o software que contiene múltiples módulos independientes pero conectados de equipo de red e internetwork. Los hubs pueden ser activos (cuando repiten señales enviadas a través de ellos) o pasivos (cuando no repiten, sino que meramente dividen las señales enviadas a través de ellos).

3. En Ethernet e IEEE 802.3, un repetidor Ethernet multipuerto, algunas veces denominado como concentrador.

I

ICMP (Internet Control Message Protocol)

Protocolo de mensajes de control en Internet. Protocolo Internet de capa de red que informa errores y brinda información relativa al procesamiento de paquetes IP. Documentado en RFC 792.

IMAP

Protocolo de Acceso a Mensajes de Internet (Internet Message Access Protocol). Protocolo diseñado para permitir la manipulación de mailboxes remotos como si fueran locales. IMAP requiere de un servidor que haga las funciones de oficina de correos pero en lugar de leer todo el mailbox y borrarlo, solicita sólo los encabezados de cada mensaje. Se pueden marcar mensajes como borrados sin suprimirlos completamente, pues estos permanecen en el mailbox hasta que el usuario confirma su eliminación.

Interfaz

1. Conexión entre dos sistemas o dispositivos. 2. En terminología de enrutamiento, una conexión de red. 3. En telefonía, un límite compartido definido por las características

comunes de interconexión física, las características de las señales y los significados de las señales que se intercambian.

Límite entre capas adyacentes del modelo OSI.

IP (Internet Protocol)

Protocolo Internet. Protocolo de capa de red de la pila TCP/IP que ofrece un servicio de internetwork sin conexión. El IP tiene prestaciones para direccionamiento, especificación del tipo de servicio, fragmentación y rearmado, y seguridad. Documentado en RFC 791.

L

LAN (Local Area Network)

Red de área local. Red de datos de alta velocidad y bajo nivel de error que cubre un área geográfica relativamente pequeña (hasta unos pocos miles de metros). Las LANs conectan estaciones de trabajo, periféricos, terminales y otros dispositivos en un único edificio u otra área geográficamente limitada. Los estándares de LAN especifican el cableado y señalización en las capas física y de enlace datos del modelo OSI. Ethernet, FDDI y Token Ring son tecnologías LAN ampliamente utilizadas.

M

MIB (Management Information Base)

Base de información de gestión. Base de datos de información de gestión de red, utilizada y mantenida por un protocolo de gestión de red como SNMP o CMIP. Se puede modificar o recuperar el valor de un objeto MIB al utilizar comandos SNMP o CMIP. Los objetos MIB están organizados en una estructura en árbol que comprende ramas privadas (propietarias) y públicas (estándares).

P

ping

Comando que utiliza el protocolo ICMP para verificar la conexión de hardware y la dirección lógica de la capa de red. Es un mecanismo de prueba muy básico.

POP. Protocolo de Oficina de Correos (Post Office Protocol) Programa cliente que se comunica con el servidor, identifica la presencia de nuevos mensajes, solicita la entre de los mismos y utiliza al servidor como oficina despachadora de correo electrónico cuando el usuario envía una carta.

Puerto

1. Interfaz en un dispositivo de internetworking (tal como un router). 2. En la terminología IP, un proceso de capa superior que está

recibiendo información de capas más bajas. 3. Re-escribir software o microcodificar, de forma tal que correrá en

una plataforma de hardware diferente o en un ambiente de software diferente para el que fue diseñado originalmente.

Un conector hembra en un patch panel que acepta un enchufe del mismo tamaño que una ficha RJ45. Los patch cords se utilizan en estos puertos para interconectar computadoras cableadas al patch panel. Es esta interconexión la que permite el funcionamiento de una LAN.

R RAM

Random Access Memory. Memoria de Acceso Aleatorio. Varios son los tipos de memoria que se usa en las computadoras. La más conocida son las RAM. Se les llama así porque es posible dirigirse directamente a la célula donde se encuentra almacenada la información. Su principal característica es que la información se almacena en ellas provisoriamente, pudiendo ser grabadas una y otra vez, al igual que un casette de sonido. La memoria RAM se puede comparar a un escritorio, donde se coloca los papeles con que se va a trabajar. Mientras más grande el escritorio más papeles soporta simultáneamente para ser procesados.

ROOT

Raíz. En sistemas de ficheros se refiere al directorio raíz. En Unix se refiere al usuario principal.

Recolección MIB

Técnica de sondeo utilizada por el protocolo SNMP para reunir información necesaria para monitorear la red.

Red

1. Conjunto de computadoras, impresoras, routers, switches, y otros dispositivos, que pueden comunicarse entre sí por algún medio de transmisión.

2. (network) Comando que asigna una dirección NIC con la cual el router está conectado directamente.

3. (network) Comando que especifica cualquier red conectada directamente que será incluída.

S Servidor

Nodo o programa de software que brinda servicios a los clientes.

Sesión

Conjunto relacionado de transacciones de comunicación entre dos o más dispositivos de red.

SMTP (Simple Mail Transfer Protocol)

Protocolo SMTP. Protocolo de Internet que brinda servicios de correo electrónico.

SNMP (Simple Network Management Protocol)

Protocolo simple de administración de redes. Protocolo de administración de redes utilizado casi con exclusividad en redes TCP/IP. El SNMP brinda una forma de monitorear y controlar los

dispositivos de red y de administrar configuraciones, recolección de estadísticas, desempeño y seguridad.

SNMP2

SNMP Versión 2. Versión 2 del popular protocolo de administración de redes. SNMP2 soporta estrategias de gestión de redes tanto centralizadas como distribuidas, e incluye mejoras al protocolo SMI, a las operaciones del protocolo, a la arquitectura de gestión y a la seguridad.

T

TCP (Transmission Control Protocol)

Protocolos de control de transmisión. Protocolo de la capa de transporte orientado a conexión que provee una confiable transmisión de datos full-duplex. TCP es parte del stack de protocolo TCP/IP.

TCP/IP (Transmission Control Protocol/Internet Protocol)

Protocolo de control de transmisión / Protocolo Internet. Nombre común para la suite de protocolos desarrollados por el DoD de EE.UU. en los años ’70 para soportar la construcción de internetworks a nivel mundial. TCP e IP son los dos protocolos más conocidos de la suite.

Telnet

Comando utilizado para verificar el software de la capa de aplicación entre las estaciones de origen y de destino. Éste es el mecanismo de prueba más completo disponible.

Terminal

Dispositivo simple donde se pueden ingresar o recuperar datos de una red. En general, las terminales tienen un monitor y un teclado, pero no tienen procesador ni unidad de disco local.

TFTP (Trivial File Transfer Protocol)

Versión simplificada de FTP que permite la transferencia de archivos de una computadora a otra por una red.

Trap

Mensaje enviado por un agente SNMP a un NMS, consola, o terminal, para indicar la ocurrencia de un evento significativo, como una condición definida específicamente, o un umbral que ha sido alcanzado.

U

UDP (User Datagram Protocol)

Protocolo de datagrama de usuario. Protocolo sin conexión de capa de transporte en el stack de protocolo TCP/IP. UDP es un protocolo simple que intercambia datagramas sin confirmación o garantía de entrega y que requiere que el procesamiento de errores y las retransmisiones sean manejados por otros protocolos. UDP se define en la RFC 768.

URL

Universal Resource Locator. Nombre genérico de la dirección en Internet, Indica al usuario dónde localizar un archivo HTML determinado, en la Web. UTILIDAD

W

WEB

Site. Sitio en el World Wide Web. Conjunto de páginas Web que forman una unidad de presentación, como una revista o libro. Un sitio está formado por una colección de páginas Web WWW (World Wide Web).

Servidor de información, desarrollado en el CERN (Laboratorio Europeo de Física de Partículas), buscando construir un sistema distribuido hipermedia e hipertexto. También llamado WEB y W3. Existen gran cantidad de clientes WWW para diferentes plataformas.

INDICE GENERAL

1. MODELO DE PROCESOS

1.1. Diagramas de Flujos de Datos 1

1.2. Diseño de Arquitectura 1

1.3. Procedimientos 56

2. DESCRIPCIÓN DE LA ESTRUCTURA DE DATOS

2.1. Diagramas de la Base de datos 70

2.2. Tablas 71

2.2.1. Generalidades de las Tablas 71

2.2.2. Detalle de los campos 95

3. ARCHIVO

3.1. Bitácora 94

3.2 Librería 94

3.3. Configuración 96

MANUAL TÉCNICO

1. MODELO DE PROCESOS

1.1 DIAGRAMA DE FLUJO DE DATOS

Un diagrama de flujos de datos (DFD), es una técnica grafica que describe el

flujo de información y las transformaciones que se aplican a los datos,

conforme se mueven de la entrada a la salida.

Se puede utilizar un DFD para representar cualquier software a cualquier nivel

de abstracción.

El rectángulo se utiliza para representar una unidad

Externa.

Los procesos o transformación que se aplican a los datos.

Flujo de los datos

La línea doble representa un almacén de información.

Cabe mencionar que el diagrama no proporciona ninguna secuencia explícita

de los procesos.

Nivel 0


MODULO DE INICIO

RECONECTAR USUARIO

SELECCION OPCION

DATOS DE

USUARIO VALIDACION DE USUARIO

USERS

PASSWORD

VISTO BUENO

DATOS

NOTIFICAR

ACTUALIZANDO BASE

PASSWORD

PASSWORD

PASSWORD

Nivel 0


MODULO DE USUARIO

CREAR USUARIO NUEVO

SELECCION OPCION

DATOS

VERIFICAR

DATOS DE

USUARIO PASSWORD USUARIO

USERS

PASSWORD

VISTO BUENO

DATOS EDITAR

NOTIFICAR

ACTUALIZAR BASE

PASSWORD

USUARIO

PASSWORD

PASSWORD

Nivel 1


SUBMODULO CREAR UN NUEVO USUARIO

DATOS

VERIFICAR

USERS

DATOS DE USUARIO NUEVO

USUARIO

INGRESAR DATOS USUARIO

SELECCION OPCION

PASSWORD

DATOS

DATOS AGREGAR

SALIR

ACTUALIZANDO

BASE DE DATOS

PASSWORD

PASSWORD

PASSWORD

PASSWORD

Nivel 1


SUBMODULO EDITAR USUARIO

RIGHTS

DATOS

VERIFICAR

USERS

DATOS DE

USUARIO EDITAR USUARIOS

NUEVO USUARIO

SELECCION OPCION

PASSWORD

VISTO BUENO

DATOS ACTUALIZAR

ELIMINAR


PASSWORD

PASSWORD

ASIGNAR PERMISOS

DATOS

VERIFICAR

PASSWORD

PASSWORD

PASSWORD


SUBMODULO ASIGNAR PERMISOS AL USUARIO

NUEVOS PERMISOS

DATOS

VERIFICAR

RIGHTS

DATOS DE USUARIO PERMISOS

USUARIO SELECCION

OPCION

PASSWORD

VISTO BUENO

DATOS ACTUALIZAR

ELIMINAR


PASSWORD

PASSWORD

PASSWORD

PASSWORD

AGREGAR RECURSOS