Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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.
CAPACIDAD DE DISCO DURO 80 GB.
ESPACIO DISPONIBLE 40 GB.
AMPLITUD DEL BUS 32 BITS
FRECUENCIA DE RELOJ 1.7 GHZ.
MONITOR SVGA DE 17”
SISTEMA OPERATIVO LINUX
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
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.
Computadores clientes.
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.
CARACTERISTICAS PC “A” PC “B”
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 DE RELOJ 50 MHZ.
CAPACIDAD DE DISCO DURO 2 GB.
AMPLITUD DEL BUS 32 BITS
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
DIAGRAMA DE FLUJO DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
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
disponen una vez iniciada la sesión a través de nombre y una
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
DIAGRAMA DE FLUJO DE DATOS
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:
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. 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
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO ASIGNAR PERMISOS AL USUARIO
NUEVOS PERMISOS
DATOS
VERIFICAR
RIGHTS
DATOS DE
USUARIO PERMISOS USUARIO
SELECCION OPCION
PASSWORD
VISTO BUENO
DATOS ACTUALIZAR
ELIMINAR
ACTUALIZANDO BASE DE DATOS
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
registrarse o actualizarse en la base de datos.
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
DIAGRAMA DE FLUJO DE DATOS
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
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO
NOTIFICACION DE USUARIOS
NOMBRE:
Submodulo notificación de 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. 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
DIAGRAMA DE FLUJO DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO CREAR UN NUEVO HOST
DATOS
VERIFICAR
HOST
DATOS DE
HOST NUEVO HOST
INGRESO DE HOST MONITOR
SELECCION OPCION
PASSWORD
DATOS
DATOS AGREGAR
SALIR
ACTUALIZANDO BASE DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO CAMBIAR STATUS DE UN HOST
DATOS
VERIFICAR
HOST
DATOS DE
HOST STATUS HOST
NUEVO STATUS
SELECCION OPCION
PASSWORD
DATOS
DATOS MONITOREADO
NO
MONITOREADO
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO CAMBIAR
STATUS DEL HOSTS
NOMBRE:
Submodulo cambiar el status del hosts
DESCRIPCION:
En este diagrama se describe todo los subprocesos que los hosts
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
registrarse o actualizarse en la base de datos.
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
DIAGRAMA DE FLUJO DE DATOS
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
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO
CREAR NUEVOS GRUPOS DE HOSTS
NOMBRE:
Submodulo crear nuevos grupos de hosts
DESCRIPCION:
En este diagrama se describe todo los subprocesos que los
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
DIAGRAMA DE FLUJO DE DATOS
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
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO EDITAR
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
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO EDITAR HOST
DATOS
VERIFICAR
HOST
DATOS DE
HOST EDITAR HOST
NUEVO HOST
SELECCION OPCION
PASSWORD
VISTO BUENO
DATOS ACTUALIZAR
ELIMINAR
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO EDITAR
HOSTS
NOMBRE:
Submodulo editar hosts
DESCRIPCION:
En este diagrama se describe todo los subprocesos que los hosts
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
DIAGRAMA DE FLUJO DE DATOS
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
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO SERVICIOS A
MONITOREAR EN EL HOSTS
NOMBRE:
Submodulo servicios a monitorear.
DESCRIPCION:
En este diagrama se describe todo los subprocesos que los hosts
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
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO EDITAR ITEMS
ACTUALIZANDO BASE DE DATOS
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
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO EDITAR
ITEMS (SERVICIOS)
NOMBRE:
Submodulo editar items
DESCRIPCION:
En este diagrama se describe todo los subprocesos que los hosts
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
registrarse o actualizarse en la base de datos.
NOTAS:
Los Items pueden ser editados desde el menú principal o desde
los hosts.
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
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
deben registrarse o actualizarse en la base de datos.
NOTAS:
El items puede ser un servicio o cualquier parámetro de la red ya
establecido.
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO AGREGAR ITEMS AL HOST
DATOS
VERIFICAR
ITEMS
DATOS DE
ITEMS NUEVO ITEMS
DATOS DEL ITEMS
SELECCION OPCION
PASSWORD
DATOS
DATOS AGREGAR
SALIR
ACTUALIZANDO BASE DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO CAMBIAR STATUS DE UN ITEMS
DATOS
VERIFICAR
ITEMS
DATOS DE
ITEMS STATUS ITEMS
NUEVO STATUS
SELECCION OPCION
PASSWORD
DATOS
DATOS ACTIVO
NO ACTIVO
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO
CAMBIAR STATUS DELITEMS
NOMBRE:
Submodulo cambiar el status del items
DESCRIPCION:
En este diagrama se describe todo los subprocesos que los
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
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO EDITAR ITEMS
ACTUALIZANDO BASE DE DATOS
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
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO EDITAR
ITEMS
NOMBRE:
Submodulo editar items
DESCRIPCION:
En este diagrama se describe todo los subprocesos que los items
disponen una vez validado el usuario. Editando los datos de los items
previamente creados. Agregando nuevas características a los que ya
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
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO MODIFICAR ITEMS
DATOS DE
ITEMS
ITEMS
MODIFICAR ITEMS
SELECCION OPCION
VISTO BUENO
DATOS ACTUALIZAR
AGREG AL HOST
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO MODIFICAR
ITEMS
NOMBRE:
Submodulo modificar items
DESCRIPCION:
En este diagrama se describe todo los subprocesos que los items
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
deben registrarse o actualizarse en la base de datos.
NOTAS:
Todo items modificado debe ser actualizado para que los cambios
surtan efecto.
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
MODULO CONFIGURACION
DATOS
VERIFICAR
MEDIA
DATOS DE
CONFIGURACION VALIDACION DE USUARIO
NUEVO CONFIG
SELECCION OPCION
PASSWORD
DATOS
DATOS EDITAR CONFIG
SALIR
ACTUALIZANDO BASE DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
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
ACTUALIZANDO BASE DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO EDITAR CONFIGURACION
DATOS
VERIFICAR
MEDIA – MEDIA_TYPE
DATOS DE
CONFIGURACION EDITAR CONFIG
NUEVO CONFIG
SELECCION OPCION
PASSWORD
VISTO BUENO
DATOS
ACTUALIZAR
ELIMINAR
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO EDITAR
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
previamente creados. Agregando nuevas características a los que ya
existen, ó eliminando alguna de ellas. Todos estos procesos deben
registrarse o actualizarse en la base de datos.
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
DIAGRAMA DE FLUJO DE DATOS
MODULO DE TRIGGERS
DATOS
VERIFICAR
TRIGGERS
DATOS DE
TRIGGERS VALIDACION DE USUARIO
NUEVO TRIGGERS
SELECCION OPCION
PASSWORD
VISTO BUENO
SALIR
ACTUALIZANDO BASE DE DATOS
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
registrarse o actualizarse en la base de datos.
NOTAS:
Cada evento que ocurra en la aplicación va ha generar un nuevo
triggers o disparador.
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
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
ACTUALIZANDO BASE DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
MODULO DE GRAFICA
GRAPHS
MOSTRAR GRAFICA
DATOS DE
GRAFICA GENERACION DE GRAFICA
NUEVA GRAFICA
SELECCION OPCION
PASSWORD
VISTO BUENO
DATOS
SELECCIONAR GRAFICA
SALIR
ACTUALIZANDO BASE DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
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
estos procesos deben registrarse o actualizarse en la base de datos.
NOTAS:
Cada servicio generará una gráfica a través de la cual visualicemos
los resultados.
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO MOSTRAR GRAFICA
GRAPHS-ITEMS
DATOS DE
GRAFICA MOSTRAR GRAFICA
MOSTRAR PARAMETROS
SELECCION OPCION
PASSWORD
DATOS
DATOS
GRAFICA UP
GRAFICA DOWN
ACTUALIZANDO BASE DE DATOS
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
procesos deben registrarse o actualizarse en la base de datos.
NOTAS:
Cada servicio generará una gráfica a través de la cual visualicemos
los resultados.
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO DE SELECCIONAR GRAFICA
DATOS
PASSWORD ESCOGER GRAFICA
SELECCION
OPCION
DATOS DE
PANTALLA MOSTRAR GRAFICA
GRAPHS
VISTO BUENO
SALIR
ACTUALIZAR BASE
PASSWORD
PASSWORD
PASSWORD
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO DE
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
estos procesos deben registrarse o actualizarse en la base de datos.
NOTAS:
Con esta función podemos elegir el servicio a monitorear de todos
los hosts.
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
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
registrarse o actualizarse en la base de datos.
NOTAS:
Cada evento que ocurra en la aplicación va ha generar un nueva
alarma.
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
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
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO DE
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
procesos deben registrarse o actualizarse en la base de datos.
NOTAS:
Cada alarma genera los valores de falso o verdadero.
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
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
procesos deben registrarse o actualizarse en la base de datos.
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
DIAGRAMA DE FLUJO DE DATOS
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
ESPECIFICACIONES DEL DIAGRAMA DEL SUBMODULO DE
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
estos procesos deben registrarse o actualizarse en la base de datos.
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
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
Formulario de Solicitud
Validación de Datos
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
Formulario de Solicitud
Validación de Datos
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
Actualizando Base de Datos
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
Validación de Datos
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
Actualizando Base de Datos
Solicitud de Nuevo Triggers
Flujo
Formulario de Solicitud
Validación de Datos
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
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
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
triggerid int(4) DEFAULT '0' NOT NULL
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
clock 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
triggerid 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
itemid 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.
itemid int(4) DEFAULT '0' NOT NULL
clock int(4) DEFAULT '0' NOT NULL
value double(164) DEFAULT '0.0000' NOT NULL
3.3.2.9. HISTORY_STR
itemid int(4) DEFAULT '0' NOT NULL
clock int(4) DEFAULT '0' NOT NULL
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
status 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
status int(4) DEFAULT '0' NOT 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
name varchar(128) DEFAULT '' NOT NULL
status int(1) DEFAULT '0' NOT NULL
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
clock int(4) DEFAULT '0' NOT NULL
value 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
status int(4) DEFAULT '0' NOT NULL
value int(4) DEFAULT '0' 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
name 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:
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
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 Y LINUX
OFFICE XP
INTERNET EXPLORER Navegador para Internet
L&POWER TRANSLATOR Traductor
WINZIP Empaquetador de archivos versión 8.1
LENGUAJE C Lenguaje de programación C++
PHP Lenguaje de programación 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.
CAPACIDAD DE DISCO DURO 80 GB.
ESPACIO DISPONIBLE 40 GB.
AMPLITUD DEL BUS 32 BITS
FRECUENCIA DE RELOJ 1.7 GHZ.
MONITOR SVGA DE 17”
SISTEMA OPERATIVO LINUX
OFFICE XP
INTERNET EXPLORER Navegador para Internet
L&POWER TRANSLATOR Traductor
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:
Computadores clientes.
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:
CARACTERISTICAS PC “A” PC “B”
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
CARACTERISTICAS DESCRIPCION
Procesador: Pentium-III 1,2 GHz o superior
RAM: 256 MB
Disco Duro: 80 GB para soporte de la base de datos
Monitor: SVGA (1024x768) para ambiente gráfico
CD –ROM: 52x con auto inicialización
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.
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.
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
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
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
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
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO ASIGNAR PERMISOS AL USUARIO
NUEVOS PERMISOS
DATOS
VERIFICAR
RIGHTS
DATOS DE USUARIO PERMISOS
USUARIO SELECCION
OPCION
PASSWORD
VISTO BUENO
DATOS ACTUALIZAR
ELIMINAR
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
AGREGAR RECURSOS
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
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
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
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
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO CREAR UN NUEVO HOST
DATOS
VERIFICAR
HOST
DATOS DE
HOST NUEVO HOST
INGRESO DE HOST MONITOR
SELECCION OPCION
PASSWORD
DATOS
DATOS AGREGAR
SALIR
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO CAMBIAR STATUS DE UN HOST
DATOS
VERIFICAR
HOST
DATOS DE
HOST STATUS HOST
NUEVO STATUS
SELECCION OPCION
PASSWORD
DATOS
DATOS MONITOREADO
NO
MONITOREADO
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
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
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 2
DIAGRAMA DE FLUJO DE DATOS
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
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO EDITAR HOST
DATOS
VERIFICAR
HOST
DATOS DE
HOST EDITAR HOST
NUEVO HOST
SELECCION OPCION
PASSWORD
VISTO BUENO
DATOS ACTUALIZAR
ELIMINAR
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
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
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 2
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO EDITAR ITEMS
ACTUALIZANDO BASE DE DATOS
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
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
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
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO AGREGAR ITEMS AL HOST
DATOS
VERIFICAR
ITEMS
DATOS DE
ITEMS NUEVO ITEMS
DATOS DEL ITEMS
SELECCION OPCION
PASSWORD
DATOS
DATOS AGREGAR
SALIR
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO CAMBIAR STATUS DE UN ITEMS
DATOS
VERIFICAR
ITEMS
DATOS DE
ITEMS STATUS ITEMS
NUEVO STATUS
SELECCION OPCION
PASSWORD
DATOS
DATOS ACTIVO
NO ACTIVO
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO EDITAR ITEMS
ACTUALIZANDO BASE DE DATOS
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
Nivel 2
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO MODIFICAR ITEMS
DATOS DE
ITEMS
ITEMS
MODIFICAR ITEMS
SELECCION OPCION
VISTO BUENO
DATOS ACTUALIZAR
AGREG AL HOST
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
MODULO CONFIGURACION
DATOS
VERIFICAR
MEDIA
DATOS DE
CONFIGURACION VALIDACION DE USUARIO
NUEVO CONFIG
SELECCION OPCION
PASSWORD
DATOS
DATOS EDITAR CONFIG
SALIR
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
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
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO EDITAR CONFIGURACION
DATOS
VERIFICAR
MEDIA – MEDIA_TYPE
DATOS DE
CONFIGURACION EDITAR CONFIG
NUEVO CONFIG
SELECCION OPCION
PASSWORD
VISTO BUENO
DATOS
ACTUALIZAR
ELIMINAR
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
MODULO DE TRIGGERS
DATOS
VERIFICAR
TRIGGERS
DATOS DE
TRIGGERS VALIDACION DE USUARIO
NUEVO TRIGGERS
SELECCION OPCION
PASSWORD
VISTO BUENO
SALIR
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
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
Nivel 2
DIAGRAMA DE FLUJO DE DATOS
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
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
GRAFICA POR HORA
VALORES POR HORA
DATOS
DATOS
PASSWORD
PASSWORD
Nivel 2
DIAGRAMA DE FLUJO DE DATOS
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
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
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
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
MODULO DE GRAFICA
GRAPHS
MOSTRAR GRAFICA
DATOS DE
GRAFICA GENERACION DE GRAFICA
NUEVA GRAFICA
SELECCION OPCION
PASSWORD
VISTO BUENO
DATOS
SELECCIONAR GRAFICA
SALIR
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
DATOS
DATOS
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO NUEVA GRAFICA
PASSWORD
INGRESAR
DATOS
DATOS GRAFICA
NUEVA GRAFICA
DATOS
GRAPHS
ACTUALIZAR BASE
DATOS
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO MOSTRAR GRAFICA
GRAPHS-ITEMS
DATOS DE
GRAFICA MOSTRAR GRAFICA
MOSTRAR PARAMETROS
SELECCION OPCION
PASSWORD
DATOS
DATOS
GRAFICA UP
GRAFICA DOWN
ACTUALIZANDO BASE DE DATOS
PASSWORD
PASSWORD
PASSWORD
PASSWORD
AGREGAR NUEVO ITEMS
DATOS
DATOS
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
SUBMODULO DE SELECCIONAR GRAFICA
DATOS
PASSWORD ESCOGER GRAFICA
SELECCION
OPCION
DATOS DE
PANTALLA MOSTRAR GRAFICA
GRAPHS
VISTO BUENO
SALIR
ACTUALIZAR BASE
PASSWORD
PASSWORD
PASSWORD
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
MODULO ALARMAS
DATOS
PASSWORD MOSTRAR ALARMAS
SELECCION
OPCION
DATOS DE
ALARMA ALARMAS
ALARMS
DATOS
DESCRIPCION DE ALARMAS
ACTUALIZAR BASE
PASSWORD
PASSWORD
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
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
Nivel 0
DIAGRAMA DE FLUJO DE DATOS
MODULO ALERTAS
PASSWORD MOSTRAR ALERTS
SELECCION
OPCION
DATOS DE
ALERTA ALERTAS
ALERTS
DATOS DATOS
DESCRIPCION DE ALERTS
ACTUALIZAR BASE
PASSWORD
PASSWORD
PASSWORD
Nivel 1
DIAGRAMA DE FLUJO DE DATOS
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
1.2 DISEÑO DE ARQUITECTURA
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.
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.
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
SCRIP
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
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
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.
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.
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.
1.1.1.1. 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
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:
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.
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.
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
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
SN
MP
E-
MAI
L
BLOQUE DE
ALERTAS
SOCKET TCP
Fig. 4
MONITOR
SUCKERD
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
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
60
1.3 PROCEDIMIENTOS
DESCRIPCIÓN DE PROCEDIMIENTOS
function url_param($parameter)
Función que retorna lo que se define en el URL, caso contrario retorna "".
function getmicrotime()
Función que obtiene el valor de la función microtime()de php.
function convert_units($value,$units,$multiplier)
Esta función realiza las conversiones en segundos para definir el intervalo de
tiempo en el que va ha monitorear.
function get_media_count_by_userid($userid)
Función que obtiene los números de registros de la tabla media cuyo campo
userid sea igual al ingresado por teclado, el valor retornado es el número de
userid.
function get_action_count_by_triggerid($triggerid)
Función que obtiene los números de registros de la tabla actions cuyo
campo triggerid sea igual al ingresado por teclado y el campo scope =0, el
valor retornado es el número de triggerid .
61
function check_anyright($right,$permission)
Función que chequea los permisos de la tabla right cuyo campo triggerid sea
igual al ingresado por teclado y el campo scope =0, el valor retornado es el
número de triggerid .
function check_right_on_trigger($permission,$triggerid)
Función que chequea el identificador del host para verificar que permisos
tiene el host para ejecutar el trigger.
function get_scope_description($scope)
Función que obtiene la descripción del host.
function get_service_status_description($status)
Función que obtiene el estado del servicio y envía un mensaje si ocurrió un
problema..
function get_group_by_groupid($groupid)
Función que obtiene los grupos, que están el la base de datos mediante su
identificador de grupo.
62
function get_action_by_actionid($actionid)
Función que obtiene que acción se ha defino mediante comparación con la
base de datos.
function get_user_by_userid($userid)
Función que obtiene los usuarios que están en la base de datos y lo
compara con el ingresado.
function get_usergroup_by_usrgrpid($usrgrpid)
Función que obtiene los host que forman parte de un grupo, mediante su
identificador de grupo.
function get_function_by_functionid($functionid)
Función que obtiene las funciones que están en la base de datos y lo
compara con el ingresado.
function get_trigger_by_triggerid($triggerid)
Función que obtiene los triggers que están en la base de datos y lo compara
con el ingresado.
63
function select_config()
Función que indica que configuración se ha seleccionado en la base de
datos y lo compara con el ingresado.
function get_num_of_service_childs($serviceid)
Función que obtiene los números de servicios mediante la comparación del
identificador del servicio con el ingresado.
function get_service_by_serviceid($serviceid)
Función que obtiene los servicios mediante la comparación del identificador
del servicio con el ingresado.
function show_messages($bool,$msg,$errmsg)
Función que muestra los mensajes que indicaran si hubo error.
function validate_expression($expression)
Función que valida las expresiones enviadas por teclado.
function check_authorisation()
Función que chequea la autorización para los usuarios identificados.
64
function show_special_header($title,$refresh,$nomenu,$noauth)
función que contiene la presentación la cabecera del menú.
function implode_exp ($expression, $triggerid)
función que permite el ingreso de los parámetros dependiendo del estado.
function update_trigger_comments($triggerid,$comments)
función que permite la actualización del estado del trigger y la actualización
del estado del ítem, se considera el 5% de la carga del procesador.
function expand_trigger_description_simple($triggerid)
función que permite la descripción simple del trigger.
function expand_trigger_description($triggerid)
función que permite la descripción del trigger mediante uso de la función
anterior y obtiene la actualización del mismo.
function update_host_status($hostid,$status)
función que permite la actualización del estado del host.
65
Function_update_item($itemid,$description,$key,$hostid,$delay,$histor
y,$status,$type,$snmp_community,$snmp_oid,$value_type,$trapper_ho
sts,$snmp_port,$units,$multiplier,$delta)
función que permite la actualización del ítem manejando los errores de
permisos y definición de puerto snmp..
$message, $scope, $severity, $recipient, $usrgrpid)
función que permite adicionar una acción, retornando verdadero si el
triggerid es una razón por qué el servicio no es OK
function service_has_parent($serviceid)
función que verifica si un servicio tiene herencia mediante el serviceid que es
su clave primaria.
function service_has_no_this_parent($parentid,$serviceid)
función que verifica si un servicio no tiene herencia mediante el serviceid que
es su clave primaria.
function delete_service_link($linkid)
función que elimina el servicio enlazado mediante su clave primaria.
66
function delete_service($serviceid)
función que elimina el servicio mediante su clave primaria.
Function_update_service($serviceid,$name,$triggerid,$linktrigger,$algo
rithm,$showsla,$goodsla,$sortorder)
función que actualiza el servicio.
Function_add_service($serviceid,$name,$triggerid,$linktrigger,$algorit
hm,$showsla,$goodsla,$sortorder)
función que adiciona un servicio nuevo.
function add_host_to_services($hostid,$serviceid)
función que adiciona al host un servicio.
function add_service_link($servicedownid,$serviceupid,$softlink)
función que adiciona al enlace un servicio.
function update_action( $actionid, $triggerid, $userid, $good,
$delay, $subject, $message, $scope, $severity, $recipient, $usrgrpid)
función que actualiza la tabla acción.
67
function delete_graphs_item($gitemid)
función que elimina un grafico mediante su clave primaria(tabla padre).
function delete_graph($graphid)
función que elimina un grafico mediante su clave primaria (tabla hija)
function delete_sysmap( $sysmapid )
función que elimina un mapa mediante su clave primaria .
function delete_alert_by_actionid( $actionid )
función que elimina una alerta creada por acción .
function delete_actions_by_userid( $userid )
función que elimina una acción por medio de la clave primaria del usuario. .
function delete_action( $actionid )
función que elimina una acción por medio de su clave primaria .
68
function_add_item($description,$key,$hostid,$delay,$history,$status,$t
ype,$snmp_community,$snmp_oid,$value_type,$trapper_hosts,$snmp_
port,$units,$multiplier,$delta)
función que adiciona un item chequeando, si se tiene los permisos de
administrador , si el item no ha sido usado por un host siendo esta clave
primaria.
function delete_function_by_triggerid($triggerid)
función que elimina una función mediante la clave primaria de la tabla
trigger.
function delete_actions_by_triggerid($triggerid)
función que elimina una acción mediante la clave primaria de la tabla trigger.
function delete_alarms_by_triggerid($triggerid)
función que elimina una alarma mediante la clave primaria de la tabla trigger.
function delete_triggers_by_itemid($itemid)
función que elimina un trigger mediante la clave primaria de la tabla item.
function delete_services_by_triggerid($triggerid)
función que elimina un servicio mediante la clave primaria de la tabla trigger.
69
function activate_item($itemid)
función que actualiza un item mediante su clave primaria.
function disable_item($itemid)
función que desactiva un item mediante su clave primaria.
function delete_item($itemid)
función que elimina un item mediante su clave primaria.
function add_alarm($triggerid,$value)
función que adiciona una alarma mediante su clave primaria de la tabla
trigger y el campo valor de la tabla alarma.
Function_add_trigger($expression,$description,$priority,$status,$com
ments,$url)
función que adiciona un trigger .
function delete_trigger($triggerid)
función que elimina un trigger mediante su clave primaria.
70
Function_update_trigger($triggerid,$expression,$description,$priority,$
status,$comments,$url)
función que actualiza la tabla trigger.
function update_user($userid,$name,$surname,$alias,$passwd)
función que actualiza la tabla user .
function add_permission($userid,$right,$permission,$id)
función que adiciona permisos en la tabla right con todos sus campos.
function add_user($name,$surname,$alias,$passwd)
función que adiciona usuarios a la tabla user con todos sus campos.
function update_graph($graphid,$name,$width,$height)
función que actualiza la tabla graph con todos sus campos.
function update_sysmap($sysmapid,$name,$width,$height)
función que actualiza la tabla sysmap con todos sus campos.
71
function add_graph($name,$width,$height)
función que agrega a la tabla graph un nuevo registro con todos sus
campos.
Function_update_graph_item($gitemid,$itemid,$color,$drawtype,$sorto
rder)
función que actualiza la tabla graph_item.
Function_add_item_to_graph($graphid,$itemid,$color,$drawtype,$sorto
rder)
función que agrega a la tabla graph_item un nuevo registro con todos sus
campos.
function add_group_to_host($hostid,$newgroup)
función que agrega a la tabla group un nuevo grupo con su identificador de
host..
function update_user_groups($usrgrpid,$users)
función que actualiza a la tabla user_groups.
function update_host_groups_by_groupid($groupid,$hosts)
función que actualiza a la tabla host_groups.
72
function add_host_group($name,$hosts)
función que adiciona un nuevo registro a la tabla host_groups.
function add_user_group($name,$users)
función que adiciona un nuevo registro a la tabla user_groups.
function update_host_group($groupid,$name,$users)
función que actualiza la tabla host_groups.
function update_user_group($usrgrpid,$name,$users)
función que actualiza la tabla user_groups.
Function_add_host($host,$port,$status,$useip,$ip,$host_templateid,$n
ewgroup,$groups)
función que adiciona un nuevo registro a la tabla host.
Function_update_host($hostid,$host,$port,$status,$useip,$ip,$newgro
up,$groups)
función que actualiza la tabla host_groups.
73
function update_config($alarm_history,$alert_history)
función que actualiza un registro de la tabla config ,verificando los permisos
que tenga..
function delete_sysmaps_host($shostid)
Función que elimina un registro de la talbla sysmaps.
function delete_host($hostid)
Función que elimina un registro de la talbla host.
function delete_permission($rightid)
Función que elimina un registro de la talbla right cuando la clave primaria es
.igual a la ingresada.
function delete_host_group($groupid)
Función que elimina un registro de la tabla host_group cuando la clave
primaria es igual a la ingresada.
function delete_user($userid)
Función que elimina un registro de la talbla right cuando la clave primaria es
.igual a la ingresada.
74
function insert_item_form()
Función que permite insertar información del item
function insert_hostgroups_form($groupid)
Función que permite insertar información del hostgroups.
function insert_usergroups_form($usrgrpid)
Función que permite insertar información del usergroups.
function insert_permissions_form($userid)
Función que permite insertar permisos a los usuarios .
75
2 DESCRIPCIÓN DE LA ESTRUCTURA DE DATOS
2.1 DIAGRAMA DE DISEÑO DE LA BASE DE DATOS
76
2.2 TABLAS
2.2.1 GENERALIDADES DE LAS TABLAS
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.
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
77
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
TABLAS
Conjunto de Campos almacenados que mantienen relación entre sí. A
continuación detallaremos cada una de las tablas:
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.
78
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.
79
HISTORY_STR
Histórico de los valores de los items en un intervalo de tiempo.
HOST
Contiene el listado de los equipos monitoreados.
ITEMS
Guarda las definiciones de los posible valores que el usuario desee
monitorear.
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.
80
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.
81
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.
TABLA PRIMARY KEY
ACTIONS (actionid)
ALARMS (alarmid)
ALERTS (alertid)
FUNCTIONS (functionid)
GRAPHS (graphid)
GRAPHS_ITEMS (gitemid)
HOST (hostid)
ITEMS (itemid)
MEDIA (mediaid)
RIGHTS (rightid)
SERVICES (serviceid)
SERVICE_ALARMS (servicealarmid)
SERVICES_LINKS (linkid)
SESSIONS
(sessionid)
82
TABLA PRIMARY KEY
TRIGGERS (triggerid)
USERS (userid)
2.2.2 DETALLE DE LOS CAMPOS
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
Nombre: Apellido del Usuario
Alias: surname
Donde se usa: B. D. users
Como se usa: Corresponde al apellido del usuario del sistema
Descripción: Cadena de 100 caracteres alfabético
Nombre: Nombre del Usuario
Alias: name
Donde se usa:
B. D. users
Como se usa:
Corresponde al nombre del usuario del sistema de monitoreo
Descripción: Cadena de 100 caracteres alfabéticos
83
Nombre: Nombre corto del usuario
Alias: alias
Donde se usa: B. D. users
Como se usa: Corresponde a un nombre corto que se le puede asignar al usuario.
Descripción: Cadena de 100 caracteres alfanuméricos
Nombre: Contraseña del usuario
Alias: passwd
Donde se usa: B. D. users
Como se usa: Corresponde a la contraseña de los usuarios del sistema.
Descripción: Cadena de 32 caracteres alfanuméricos
Tabla Sessions
Nombre: identificador
Alias: sessionid
Donde se usa: B. D. sessions
Como se usa: Campo destinado a contener un identificador de sesión
Descripción: Cadena de 32 caracteres alfanuméricos
Nombre: Tiempo de sesión
Alias: lastaccess
Donde se usa: B. D. sessions
Como se usa: Campo que contiene el tiempo de duración de la sesión
Descripción: Número entero de 4 dígitos
84
Tabla Actions
Nombre: Identificador de eventos
Alias: actionid
Donde se usa: B. D. actions
Como se usa: Campo que contiene el identificador de eventos
Descripción: Número entero de 4 dígitos
Nombre: Siguiente chequeo
Alias: nextcheck
Donde se usa: B. D. actions
Como se usa: Campo que contiene el valor del tiempo en el que el mensaje de alerta debe enviarse la próxima vez.
Descripción: Número entero de 4 dígitos
Nombre: Indicador
Alias: good
Donde se usa: B. D. actions
Como se usa: Campo destinado a contener un número indicador de una acción optima
Descripción: Número entero de 2 dígitos.
Nombre: Asunto
Alias: subject
Donde se usa: B. D. actions
Como se usa: Campo que contiene el asunto del mensaje a ser enviado.
Descripción: Cadena de 255 caracteres alfabético
Nombre: Mensaje
Alias: message
Donde se usa: B. D. actions
Como se usa: Campo que contiene el mensaje a ser enviado.
Descripción: Cadena de caracteres alfabético
85
Tabla Media
Nombre: Identificador
Alias: mediaid
Donde se usa: B. D. media
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro ingresado.
Descripción: Número entero de 4 dígitos
Nombre: Activo
Alias: active
Donde se usa: B. D. media
Como se usa: Campo que contiene el estado del medio de alerta.
Descripción: Número entero de 4 dígitos
Nombre: Tipo
Alias: type
Donde se usa: B. D. media
Como se usa: Campo que contiene el tipo del medio de alerta, los tipos pueden ser vía E_mail y por Scrips
Descripción: Cadena de 10 caracteres alfanuméricos
Nombre: Enviando
Alias: sendto
Donde se usa: B. D. media
Como se usa: Campo que contiene el mensaje de alerta enviado.
Descripción: Cadena de 100 caracteres alfanuméricos.
86
Tabla Alerts
Nombre: Identificador
Alias: alertid
Donde se usa: B. D. alerts
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro enviado.
Descripción: Número entero de 4 dígitos
Nombre: Intentos
Alias: retries
Donde se usa: B. D. alerts
Como se usa: Número de intentos en el envió de las alertas.
Descripción: Número entero de 4 dígitos
Nombre: Tiempo
Alias: clock
Donde se usa: B. D. alerts
Como se usa: El tiempo en el que la alerta fue generado.
Descripción: Número entero de 4 dígitos
Nombre: Tipo de Alerta
Alias: type
Donde se usa: B. D. alerts
Como se usa: Campo que contiene el tipo de alerta a enviar
Descripción: Cadena de 10 caracteres alfanuméricos.
Nombre: Dirección
Alias: sendto
Donde se usa: B. D. alerts
Como se usa: Campo que contiene la dirección a donde va ha ser enviada la alerta
Descripción: Cadena de 100 caracteres alfanuméricos.
87
Nombre: Estado de la alerta
Alias: status
Donde se usa: B. D. alerts
Como se usa: Campo que contiene el estado de la alerta. 0 si no se envío y 1 si se envió con éxito
Descripción: Numero entero de 4 caracteres
Nombre: Asunto de la alerta
Alias: subject
Donde se usa: B. D. alerts
Como se usa: Campo que contiene el asunto de la alerta ha enviar.
Descripción: Cadena de 255 caracteres alfabético
Nombre: Mensaje de alerta
Alias: message
Donde se usa: B. D. alerts
Como se usa: Campo que contiene el mensaje de la alerta enviada.
Descripción: Cadena de caracteres alfabético
Tabla Triggers
Nombre: Identificador
Alias: triggerid
Donde se usa: B. D. triggers
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro procesado.
Descripción: Número entero de 4 dígitos
88
Nombre: Nivel de Dependencia
Alias: dep_level
Donde se usa: B. D. triggers
Como se usa: Contiene el nivel de dependencia de los eventos
Descripción: Número entero de 2 dígitos
Nombre: Expresión
Alias: expression
Donde se usa: B. D. triggers
Como se usa: Contiene la expresión del evento.
Descripción: Cadena de 255 caracteres alfanuméricos.
Nombre: Descripción
Alias: description
Donde se usa: B. D. triggers
Como se usa: Campo que contiene la descripción del evento
Descripción: Cadena de 255 caracteres alfanuméricos.
Nombre: URL
Alias: url
Donde se usa: B. D. triggers
Como se usa: Campo que contiene el URL del evento.
Descripción: Cadena de 255 caracteres alfanuméricos.
Nombre: Estado del evento
Alias: status
Donde se usa: B. D. triggers
Como se usa: Campo que contiene el estado del evento. 0 si esta deshabilitado, y 1 si esta habilitado.
Descripción: Numero entero de 4 caracteres
89
Nombre: Valor del evento
Alias: value
Donde se usa: B. D. triggers
Como se usa: Campo que contiene el valor del evento: 0 falso, 1 verdadero y 2 desconocido
Descripción: Numero entero de 4 caracteres
Nombre: Prioridad del evento
Alias: priority
Donde se usa: B. D. triggers
Como se usa: Campo que contiene la prioridad de los eventos.
Descripción: Numero entero de 2 caracteres
Nombre: Tiempo de cambio
Alias: lastchange
Donde se usa: B. D. triggers
Como se usa: Campo que contiene el tiempo en el que el evento cambia de valor.
Descripción: Numero entero de 4 caracteres
Tabla Hosts_Groups
Nombre: Identificador
Alias: hostid
Donde se usa: B. D. hosts
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro procesado.
Descripción: Número entero de 4 dígitos
90
Nombre: Identificador
Alias: groupid
Donde se usa: B. D. hosts
Como se usa: Contiene el numero de grupo de hosts
Descripción: Número entero de 4 dígitos
Tabla Hosts
Nombre: Identificador
Alias: hostid
Donde se usa: B. D. hosts
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro procesado.
Descripción: Número entero de 4 dígitos
Nombre: Nombre del Host
Alias: host
Donde se usa: B. D. hosts
Como se usa: Contiene el nombre del host o la dirección ip
Descripción: Cadena de 64 caracteres alfanuméricos.
Nombre: Estado del Host
Alias: status
Donde se usa: B. D. hosts
Como se usa: Campo que contiene el estado del Host. Los estados son monitoreado e inalcanzable
Descripción: Entero de 4 dígitos.
Nombre: Deshabilitar el estado
Alias: disable_until
Donde se usa: B. D. hosts
Como se usa: Campo que contiene información cuando el host esta en estado inalcanzable en este caso lo deshabilita.
Descripción: Entero de 4 dígitos.
91
Nombre: Error de Red
Alias: network_errors
Donde se usa: B. D. hosts
Como se usa: Campo que contiene información cuando ocurre un error en la red.
Descripción: Entero de 4 dígitos.
Nombre: Uso de la IP
Alias: useip
Donde se usa: B. D. hosts
Como se usa: Campo que contiene información del uso de la IP
Descripción: Entero de 1 dígitos.
Nombre: IP
Alias: ip
Donde se usa: B. D. hosts
Como se usa: Campo que contiene información de la IP
Descripción: Cadena de 15 caracteres alfanuméricos.
Nombre: Puerto
Alias: port
Donde se usa: B. D. hosts
Como se usa: Campo que contiene información del Puerto
Descripción: Entero de 4 dígitos.
92
Tabla Sysmaps_Hosts
Nombre: Identificador
Alias: shostid
Donde se usa: B. D. sysmaps_hosts
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro procesado.
Descripción: Número entero de 4 dígitos
Nombre: Etiqueta
Alias: label
Donde se usa: B. D. sysmaps_hosts
Como se usa: Contiene la etiqueta del host en el mapa de red.
Descripción: Cadena de 128 caracteres alfanuméricos.
Nombre: Valor de X
Alias: x
Donde se usa: B. D. sysmaps_hosts
Como se usa: Campo que contiene el nombre del tipo de objeto no agregado definido en el MIB (Manejador de la información de la base de datos).
Descripción: Número entero de 4 dígitos
Nombre: Valor de Y
Alias: y
Donde se usa: B. D. sysmaps_hosts
Como se usa: Campo que contiene un fragmento de un identificador de objeto que de forma única para dicho tipo de objeto, identifica el caso deseado.
Descripción: Número entero de 4 dígitos
Nombre: Icono
Alias: icon
Donde se usa: B. D. sysmaps_hosts
Como se usa: Campo que contiene el icono de host en la red.
Descripción: Cadena de 32 caracteres alfanuméricos
93
Tabla Sysmaps
Nombre: Identificador del mapa de red.
Alias: sysmapid
Donde se usa: B. D. sysmaps.
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro procesado.
Descripción: Número entero de 4 dígitos
Nombre: Nombre del mapa de red
Alias: name
Donde se usa: B. D. sysmaps
Como se usa: Campo que contiene el nombre del mapa de red.
Descripción: Cadena de 128 caracteres
Nombre: Ancho del mapa de red.
Alias: width
Donde se usa: B. D. sysmaps.
Como se usa: Campo que contiene el ancho del mapa red.
Descripción: Entero de 4 dígitos.
Nombre: Alto del mapa de red.
Alias: height
Donde se usa: B. D. sysmaps.
Como se usa: Campo que contiene el alto del mapa red.
Descripción: Entero de 4 dígitos.
94
Tabla Sysmaps_Links
Nombre: Identificador del enlace en el mapa de red.
Alias: linkid
Donde se usa: B. D. sysmaps_links
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro procesado.
Descripción: Número entero de 4 dígitos
Nombre: Identificador del primer host
Alias: shostid1
Donde se usa: B. D. sysmaps_links
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro procesado.
Descripción: Número entero de 4 dígitos
Nombre: Identificador del segundo host.
Alias: shostid2
Donde se usa: B. D. sysmaps_links
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro procesado.
Descripción: Número entero de 4 dígitos
Tabla Items
Nombre: Identificador del agente supervisado
Alias: itemid
Donde se usa: B. D. items
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro ingresado.
Descripción: Número entero de 4 dígitos
95
Nombre: Tipo
Alias: type
Donde se usa: B. D. items
Como se usa: Corresponde al tipo de agente a ser supervisado: 0 – agente principal, 1 – SNMPv1, 2 – procesos, 3 – Simple check, 4 – SNMPv2, 5 - Internal
Descripción: Número entero de 4 dígitos
Nombre: Tipo de valor
Alias: value_type
Donde se usa: B. D. items
Como se usa: Corresponde al tipo de valor recibido: 0 – flota, 1 – string
Descripción: Número entero de 4 dígitos
Nombre: Nombre del control SNMP
Alias: snmp_community
Donde se usa: B. D. items
Como se usa: Corresponde al nombre del control para la demanda SNMP.
Descripción: Cadena de 64 caracteres alfanuméricos
Nombre: Objeto SNMP
Alias: snmp_oid
Donde se usa: B. D. items
Como se usa: Corresponde al objeto de identificación para la demanda SNMP.
Descripción: Cadena de 255 caracteres alfanuméricos
Nombre: Descripción del agente.
Alias: description
Donde se usa: B. D. items
Como se usa: Corresponde a la descripción del agente.
Descripción: Cadena de 255 caracteres alfanuméricos
96
Nombre: Clave
Alias: key_
Donde se usa: B. D. items
Como se usa: Contiene el código a ser enviado al organizador.
Descripción: Cadena de 64 caracteres alfanuméricos
Nombre: Actualización.
Alias: delay
Donde se usa: B. D. items
Como se usa: Permite la actualización de los agentes.
Descripción: Número entero de 4 dígitos
Nombre: Histórico.
Alias: history
Donde se usa: B. D. items
Como se usa: Contiene un histórico en días de los agentes.
Descripción: Número entero de 4 dígitos
Nombre: Ultimo borrado
Alias: lastdelete
Donde se usa: B. D. items
Como se usa: Contiene el tiempo del último borrado en el histórico.
Descripción: Número entero de 4 dígitos
Nombre: Ultimo Chequeo.
Alias: nextcheck
Donde se usa: B. D. items
Como se usa: Contiene el tiempo del último agente supervisado.
Descripción: Número entero de 4 dígitos
97
Nombre: Ultimo Valor.
Alias: lastvalue
Donde se usa: B. D. items
Como se usa: Contiene el último valor del agente supervisado.
Descripción: Número double de 4 dígitos
Nombre: tiempo
Alias: lastclock
Donde se usa: B. D. items
Como se usa: Contiene el tiempo del último agente supervisado.
Descripción: Número entero de 4 dígitos
Nombre: Valor Previo
Alias: prevvalue
Donde se usa: B. D. items
Como se usa: Contiene el valor del último agente recuperado.
Descripción: Número double de 4 dígitos
Nombre: Lista de IP
Alias: trapper_hosts
Donde se usa: B. D. items
Como se usa: Contiene la lista de los ip de los agentes.
Descripción: Cadena de 255 caracteres alfanuméricos
Nombre: Estado
Alias: status
Donde se usa: B. D. items
Como se usa: Contiene el estado de los agentes: 0 – activo, 1 – deshabilitado, 3 – no soportado por el agente, 4 – eliminado.
Descripción: Número double de 4 dígitos
98
Tabla History
Nombre: Tiempo
Alias: clock
Donde se usa: B. D. history
Como se usa: El tiempo
Descripción: Número entero de 4 dígitos
Nombre: Valor
Alias: value
Donde se usa: B. D. history
Como se usa: El valor de los agentes a ser almacenados
Descripción: Número double de 16 dígitos
Tabla Functions
Nombre: identificador de la función
Alias: functionid
Donde se usa: B. D. functions
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro ingresado.
Descripción: Número entero de 4 dígitos
Nombre: Parámetro
Alias: parameter
Donde se usa: B. D. functions
Como se usa: Contiene los parámetros de la funciones
Descripción: Número entero de 4 dígitos
Nombre: Ultimo valor
Alias: lastvalue
Donde se usa: B. D. functions
Como se usa: Corresponde al ultimo valor de la función
Descripción: Número double de 4 dígitos
99
Nombre: Nombre de la función
Alias: function
Donde se usa: B. D. functions
Como se usa: Corresponde al nombre de la función
Descripción: Cadena de 10 caracteres alfanuméricos
Tabla alarms
Nombre: Identificador del cambio de estado.
Alias: alarmid
Donde se usa: B. D. alarms
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro procesado
Descripción: Número entero de 4 dígitos
Nombre: Tiempo
Alias: clock
Donde se usa: B. D. alarms
Como se usa: Contiene el tiempo cuando el evento cambia su estado.
Descripción: Número entero de 4 dígitos
Nombre: Valor del cambio de estado
Alias: value
Donde se usa: B. D. alarms
Como se usa: Corresponde al cambio de valor de los eventos : 0 cuando el evento se puso false, 1 cuando se pone true y 2 - 3 cuando es desconocido
Descripción: Número double de 4 dígitos
100
Tabla History_str
Nombre: Tiempo en el histórico
Alias: clock
Donde se usa: B. D. history_str
Como se usa: El tiempo en el que el agente es supervisado.
Descripción: Número entero de 4 dígitos
Nombre: Valor
Alias: value
Donde se usa: B. D. history_str
Como se usa: Contiene el valor del agente.
Descripción: Número entero de 4 dígitos
Tabla services
Nombre: identificador de servicios
Alias: serviceid
Donde se usa: B. D. services
Como se usa: Número secuencial, generado automáticamente, habrá uno por cada registro ingresado.
Descripción: Número entero de 4 dígitos
Nombre: Nombre del servicio
Alias: name
Donde se usa: B. D. services
Como se usa: Corresponde al nombre del servicio
Descripción: Cadena de 128 caracteres alfanuméricos
101
Nombre: Algoritmo
Alias: algorithm
Donde se usa: B. D. services
Como se usa: Contiene el algoritmo que calcula el estado de los servicios
Descripción: Número double de 1 dígitos
3. ARCHIVOS
3.1 BITACORA
En NetAdmin se consideran datos importantes para el administrador los
cuales serán almacenados para posteriores consultas y que serán muy útiles
para toma de decisiones por parte de los administradores.
graph.c
Se almacenan los datos históricos de los gráficos correspondientes de
determinado servicio para que el administrador mediante este dato histórico
de un rango de fecha indicado pueda establecer en que periodo de tiempo
Nombre: Estado de los servicios
Alias: Status
Donde se usa: B. D. services
Como se usa: Corresponde a los estados de los servicios.
Descripción: Número double de 1 dígitos
102
dicho servicio estuvo fuera de servicio y poder establecer los correctivos
necesarios para correcciones de este tipo.
alert_history
Aquí se consideran los datos de las alertas donde visualmente donde se
presentan las alertas generadas por NetAdmin para establecer de manera
lógica que sucedió con un servicio
3.2 LIBRERÍAS
NetAdmin hace uso de librerías de C para Linux para su funcionamiento,
además se han desarrollado las siguientes:
Cfg.c
Se define el parámetro a ser monitoreado por medo del agente suckerd.
Db.c
Se establece la conexión con la Base de datos MySQL, indicando desde que
puerto se hace contacto con la base de Datos, se establece los datos
históricos almacenados en la fecha que el administrador especifique el la
configuración inicial.
103
Expresión.c
Está librería se encarga en convertir cadena de caracteres en datos
numéricos evaluando la expresión para luego ese dato ser establecido para
elaboración de gráficas.
Fuciones.c
Está librería contiene las funciones matemáticas (count, sum, avg, time)
usada en la Base de Datos para luego hacer uso de ellas en lo que respecta
a datos históricos.
Es importante a la hora de recalcular los valores de los triggers y los
servicios a ser monitoreados por medio de la tabla identificada como ítems,
evaluar las notificaciones de las alarmas.
Log.c
Esta librería sirve para mantener los logs generados por la aplicación.
3.3 CONFIGURACIÓN
Todos los procesos del Sistema pueden ser configurados cambiando
apropiadamente los archivos de configuración. Después de que un cambio
fuera hecho, el reinicio del proceso es necesario.
/etc/agente/servidor.conf
104
El archivo contiene parámetros de configuración para el servidor. El archivo
debe existir y debe tener permisos de lectura para el usuario agente.
Parámetros posibles:
Requisitos del hardware
Los requisitos de memoria
NetAdmin requiere como mínimo 32 Mb de memoria física y 20 Mb de
espacio libre en disco duro estos requerimientos mínimos podrían ser un
buen punto de partida . Sin embargo, la cantidad de disco duro requerida
obviamente dependerá del número de host y parámetros o servicios que se
vayan a monitorear. Si el administrador está planeando guardar un historial
de los servicios supervisados, se debe estar pensando en por lo menos de 2
gigbyte en disco duro para guardar el historial en la base de datos.
Cada demonio de NetAdmin requiere varias conexiones con la base de
datos
La cantidad de memoria asignada para la conexión depende de la
configuración de la base de datos.
Plataformas soportadas
Debido a los requisitos de seguridad y la naturaleza misión-critica de
monitorear un servidor, UNIX es el único sistema operativo robusto, fuerte,
con tolerancia a fallos. NETADMIN opera en cualquiera de las versiones en
el mercado.
105
Requerimientos de software
NETADMIN necesita de: Apache Web Server, Base de Datos MySQL y el
PHP como Front End.
Software que NetAdmin para su ejecución:
- Apache
Versión 1.3.12 o superior. El apache puede encontrarse en:
http://www.apache.org
- MySQL
Versión 3.22 o superior. MySQL puede encontrarse a
http://www.mysql.com
- PHP
Versión 4.0 o superior. PHP y sus módulos pueden encontrarse a
http://www.php.net. PHP debe compilarse con el módulo apache.
- módulo GD de PHP
Este módulo se requiere por desplegar gráficos y mapas. Este módulo
Sirve para apoyar las imágenes en el formato de PNG.
- navegador Web en el lado del cliente
Soporte para HTML e imágenes de PNG, en Mozilla 1.x trabaja
perfectamente. Los cookies y JavaScript deben estar habilitados. Otros
navegadores también pueden trabajar con NETADMIN.
106
Estructura de distribución de NETADMIN
La distribución de NETADMIN:
- el src
El directorio contiene las fuentes para todos los procesos de NETADMIN
excepto el frontends.
- el src/NetAdmin_sucker
El directorio contiene Makefile y fuentes para el NetAdmin_suckerd.
- el src/NetAdmin_agent
El directorio contiene Makefile y fuentes para el NetAdmin_agent y
el NetAdmin_agentd.
- el src/NetAdmin_trapper
El directorio contiene Makefile y fuentes para el NetAdmin_trapperd.
- el src/NetAdmin_sender
El directorio contiene Makefile y fuentes para el NetAdmin_sender.
- include
El directorio contiene los archivos include de NETADMIN.
- frontends/php
El directorio contiene las fuentes para el frontend de PHP.
- create
El directorio contiene la escritura de SQL para la creación de la base de
datos inicial.
107
- create/mysql
El MySQL base de datos schema.
- create/data
Los datos iniciales para la creación la base de datos.
Procedimiento de la instalación
La instalación básica de NETADMIN normalmente no toma más de 15
minutos.
Lado del servidor
Crear cuenta de usuario NETADMIN
Éste es el usuario en el que el servidor correrá. Para el uso usted debe crear
una centa de usuario privilegiada (―el NetAdmin‖ normalmente se usa).
NETADMIN correrá en ―root,‖ ―bin,‖.
Use el comando para descomprimir el software:
gunzip NetAdmin.tar.gz; tar -xvf NetAdmin.tar
Crear la base de datos NETADMIN en MySQL.
mysql -u<username> -p<password>
>create database NetAdmin;
>quit;
cd create/mysql
cat schema.sql |mysql -u<username> -p<password> NetAdmin
cd ../data
108
cat data.sql |mysql -u<username> -p<password> NetAdmin
Configuración y compilación del código fuente para su sistema
Las fuentes deben compilarse para ambos el servidor (monitorizar equipos)
también como los clientes (equipo monitorizado).
Para configurar el código fuente en el servidor, usted debe especificar qué
base de datos será usada.
./configure—with-mysql –with-net-snmp # for MySQL
Luego ejecute los comandos:
./configure
/make
Cree una carpeta donde se copiaran el código PHP y copie los archivos.
mkdir /home/NetAdmin/html
cp -R frontends/php/* /home/NetAdmin/html/
Configure /etc/NetAdmin/NetAdmin_agent.conf
Usted necesita configurar este archivo para cada host que tendrá NetAdmin
para monitorear. El archivo debe contener la dirección IP del servidor de
NETADMIN.
Ejecute NetAdmin_suckerd y NetAdmin_trapperd en el lado del servidor.
cd bin
./NetAdmin_suckerd
./NetAdmin_suckerdEjecute a agentes
109
Ejecute el NetAdmin_agentd en los clientes..
cd bin
./NetAdmin_agentd
“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.”
MANUAL USUARIO
1
1. INSTALACIÓN
1.1 Requerimientos de la instalación
1.1.1. Requerimientos de Hardware
1.1.1.2 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
1.1.1.2. Requerimientos Recomendados de Instalación del
servidor
CARACTERISTICAS DESCRIPCION
Procesador: Pentium-III 1,2 GHz o superior
RAM: 256 MB
Disco Duro: 80 GB para soporte de la base de datos
Monitor: SVGA (1024x768) para ambiente gráfico
CD –ROM: 52x con auto inicialización
2
1.1.2 . Requerimientos de Software
Para la Instalación del Netadmin se necesita tener instalados
los siguientes recursos de software:
Apache.
MySQL
PHP compilado como modulo de apache
PHP GD módulo (para imágenes)
PHP como módulo de MySQL
GNU Make
Navegador WEB
1.2. Instalación del Servidor
1. Descomprimir los archivos fuentes:
#gunzip netadmin.tar.gz
#tar –xvf netadmin.tar
2. Crea la Base de Datos del servidor de monitoreo
#mysql
3
mysql>create database zabbix;
mysql>quit;
cd create/mysql
cat schema.sql \mysql zabbix
cd create/data
cat data.sql \mysql zabbix
Configurar y compilar los fuentes de acuerdo a sus necesidades. Los
fuentes deben ser compilados tanto en el lado servidor como en los
equipos monitoreados.
./configure --with-mysql
Make
Se copian los binarios en el directorio /usr/local/zabbix/bin/
Y los archivos de configuración *.conf en el directorio /etc/zabbix
4
3. Se configura la interface WEB
Como root cambie los siguientes valores archivo
frontends/php/include/Db.inc.php
$DB_TYPE=”MYSQL”;
$DB_SERVER=”localhost”;
$DB_DATABASE=”zabbix”;
$DB_USER=””;
$DB_PWD=””;
Copie los archivos de PHP a la ruta seleccionada para que el servidor
WEB los lea
mkdir /var/www/html/net@dmin
cp –R frontends/php/* /var/www/html/net@admin
5
4. Se ejecuta el demonio /usr/local/zabbix/zabbix_suckerd deben estar
ejecutándose los procesos de Base de Datos y el Servidor Web.
5. Una vez que la instalación del servidor esta completa, se necesita
configurar los parámetros del mismo de acuerdo con las necesidades de
nuestros servidores. Debemos apuntar el sitio:
http://locahost/net@dmin
Una vez que estamos en el sitio procedemos a la configuración de los
equipos y los parámetros que se van ha monitorear.
1.3. Instalación del Cliente
1. Descomprimir los archivos fuentes:
#gunzip netadmin.tar.gz
#tar –xvf netadmin.tar
2. Configurar y compilar los fuentes de acuerdo a sus necesidades. Los
fuentes deben ser compilados tanto en el lado servidor como en los
equipos monitoreados.
6
./configure
Make
Se copian los binarios en el directorio /usr/local/zabbix/bin/
3. Configurar el archivo /etc/services
Se debe adicionar la siguiente línea.
zabbix 10000/tcp
4. Se debe configurar el archivo /etc/zabbix/zabbix_agentd.conf
Ejecutar el demonio /usr/local/zabbix/zabbix_agentd
7
2. INFORMACION DEL DOCUMENTO
Este documento esta destinado al usuario final, ya sea este administrador de
la Red, Operador o un invitado, el cual le va ha enseñar a instalar, configurar,
administrar y a desplazarse a través de los diferentes menús de la interfaz
web de la aplicación.
8
3. INTRODUCCIÓN AL USUARIO
Los usuarios de la interfaz Web de la aplicación deberán tener
conocimientos de lo que es un navegador y la forma de desplazarse en el
mismo.
Asignar un nombre de usuario y clave de acceso único para cada usuario,
definiendo y restringiendo los accesos respectivos necesarios para cada uno.
El usuario puede tener diferentes permisos tales como:
Consulta
Ingreso
Actualización
Eliminación
Como también se le pueden denegar otros como:
Creación y/o Eliminación de usuarios de la base de datos.
Creación y/o Eliminación de tablas
Modificación de las Estructuras de las tablas.
9
4. ORGANIZACIÓN DE MENÚS
Luego de Ingresar a la aplicación, dependiendo de los permisos, el
usuario podrá navegar a través del siguiente menú:
Inicio
Configuración
Usuarios
Disparadores
Alertas
Alarmas
Monitoreo
Equipos
Servicios
Acerca de
10
5. PANTALLAS
El ingreso al servidor donde se encuentra instalada la aplicación de
monitoreo se realiza al acceder a la siguiente dirección:
http://localhost/net@admin
Le va ha presentar la pantalla de ingreso de usuario y clave, al ingresar
correctamente el nombre del usuario y la contraseña, aparecerá en la franja
11
azul inferior de la ventana, el nombre del usuario con el cual se encuentra
conectado a la aplicación.
Para salir de la aplicación o volver a ingresar con otro usuario, se debe
pulsar nuevamente la palabra aquí.
Al dar clic sobre cualquiera de las palabras del menú, obtendrá la información
correspondiente a cada página. Se detallará a continuación la información a
la que al usuario administrador y luego aquella a la que tienen acceso los
usuarios que tienen permiso de solo lectura.
12
5.1. CONFIGURACIÓN
Ingreso tanto del servidor y la cadena SMTP, nombre de la cuenta desde
la que se enviará las alertas configuradas a los usuarios.
13
5.2. USUARIOS
En este punto 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 diferentes recursos, se establecen también el nombre del
usuario, descripción y contraseña.
14
5.2.1. Ingreso de Usuario:
Al momento de crear un usuario, se ingresa: USERNAME, la descripción
de usuario, el perfil al que pertenece y la contraseña que va ha utilizar.
La asignación de recursos y los permisos de accesos concedidos se
modifican luego de haber creado el usuario, en una pantalla similar a la
siguiente:
15
5.2.2. Cuentas 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.
16
5.3. EQUIPOS
Los equipos a monitorear, serán ingresados en esta sección, los
parámetros necesarios a ingresar son: Nombre del equipo, Dirección IP,
puerto por el que el agente estará escuchando los requerimientos del
servidor, en esta parte se indica también si el equipo luego de ser
ingresado empezará a ser monitoreado y si los servicios a monitorear
serán aquellos que se cargan por defecto o utilizará como plantilla los
servicios monitoreados en otro servidor; este último caso se da, cuando el
servidor a monitorear es un servidor de backup y por lo tanto debe
mantener características similares de monitoreo que el servidor principal.
17
5.3.1. Modificación de Configuración de Equipos monitoreados
Luego de pulsar la palabra Editar en el servidor que se desea cambiar la
configuración de monitoreo, se presentará la siguiente pantalla:
18
5.4. SERVICIOS:
Al ingresar usted, podrá agregar servicios 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 servicio, el estado, el retardo, el tipo
de valor retornado por la expresión que ha sido ingresada para el servicio.
19
Para visualizar los servicios a monitorear en determinado servidor, basta
con dar clic en el nombre del servidor, esto nos mostrará una pantalla con
cada uno de los servicios definidos para ese equipo, su delay y la
expresión que será evaluada.
Al final del listado de servicios monitoreados, se presenta un formulario en
el que es posible modificar todos los parámetros del servicio; incluso la
expresión evaluada.
5.5. DISPARADORES
Luego de que se han definido los servicios a monitorear, es necesario
agregarles los disparadores que se van ha activar en caso de que la
expresión a evaluar definida en el servicio sea verdadera.
5.5.1. Ingreso
Al acceder usted podrá ingresar nuevos disparadores a ejecutarse al
momento de efectuarse algún evento.
20
5.5.2. Información
En este listado se muestra la descripción del servicio, la expresión que
será evaluada para verificar el estado del disparador, en esta pantalla
21
también se configuran las acciones a tomar al momentote activarse el
disparador.
5.6. INICIO
Este vínculo nos lleva a la página de inicio, donde el usuario podrá
desconectarse de la aplicación o conectarse como un usuario distinto.
5.7. ACERCA DE
Muestra información sobre la aplicación y el nombre de los autores.
22
5.8. MONITOREO
En esta sección se visualizan los últimos valores registrados para los
diferente servicios monitoreados, la visualización puede ser en texto o en
gráficos de tendencias ya sean en periodos de horas, en minutos o por
días, semanas, meses o años.
5.8.1. Ingreso
Al ingresar se presentan los servidores monitoreados y de los que está
disponible la información a visualizar. Para ingresar, se debe dar clic
sobre el nombre del servidor.
23
5.8.2. Información
Esta parte es donde realmente se visualiza el valor de cada uno d elos
servicios monitoreados , la información puede mostrarse ordenada ya
sea por: la descripción del servicio monitoreado, o por la fecha de los
últimos chequeos al servicio.
24
5.8.3. Graficos:
A esta sección se ingresa al seleccionar la palabra Grafico en la página
anteriormente descrita, la representación de los gráficos puede ser
basándose en el histórico o la tendencia seguida por los datos.
La representación del histórico puede ser de los valores actuales y de
cómo estos han cambiado en relación con valores anteriores.
25
La tendencia de los datos puede mostrarse a la seguida durante las
últimas 12 horas, 4 horas, 30 minutos, o 15 minutos; para visualizarla
basta con seleccionar la opción.
5.9. ALARMAS
Si se desea conocer las alertas generadas en los diferentes servidores, la
fecha en la que fue generada y el valor de la misma es necesario ingresar
en esta página.
26
Al dar clic sobre uno de las alarmas, se muestra los diferentes ítems
monitoreados y el estado actual de los disparadores relacionado con cada
servicio. Se puede hacer la visualización de todos los ítems, o se puede
seleccionar un servidor específico.
5.9.1 Ingreso:
Como se mencionó anteriormente, se pueden ver todos los servicios
asociados o se puede escoger un servidor especial. Por omisión se
muestra todos los servicios cuyos disparadores han sido activados. La
información a visualizar puede ser ordenada por: Descripción del Item,
Severidad y Ultimo Cambio de estado
27
5.10. ALERTAS
Al momento de activarse un disparador, si se ha definido que una de las
acciones a tomar sea el envío de mensajes de alertas al usuario, es en
esta sección donde se visualizará el listado de las alertas enviadas, el
usuario al que se envían, la fecha en que se produjeron, el título y el
cuerpo del mensaje; a continuación se muestra el contenido de una
pantalla de este tipo.