LOGs para nuestros desarrollos de Software

LOGs PARA NUESTROS DESARROLLOS DE SOFTWARE

Registrando sucesos a nuestro criterio

::[INTRO]::

El registro de eventos en un sistema de información no es algo nuevo. Para los expertos en Windows habrán notado que a partir de Windows 2000, el registro de eventos es una característica presente en el Sistema Operativo. ¿A ver cuántos de ustedes saben donde ubicar el registro de eventos de Windows?. Quizá aquellos que operan con Linux estarán más acostumbrados al registro de eventos de este Sistema Operativo ya que es una constante para los que administramos grandes sistemas de información en esta plataforma tecnológica.

Hoy, venimos a la escena a aprender "de que va la película con este tema de los LOGs", no para Windows, no para Linux, ni para ningún otro sistema operativo, sino para nuestras propios desarrollos de software.

Conozco desarrolladores de Software que optan por desarrollar su propio sistema de LOGs, es decir, deciden por ejemplo crear o mantener una tabla de la base de datos de su aplicación, o un archivo en disco para registrar algunas actividades de los usuarios y del propio sistema en particular. Personalmente no veo ningún problema con ello, pero ¿porque no utilizar soluciones ya creadas para ello, que nos faciliten el arduo trabajo de andar registrando eventos, sucesos, acciones de nuestros propios desarrollos y más aún que nos faciliten la vida al momento de tener que sumergirse entre grandes archivos de LOGs para encontrar un registro en particular?

Exactamente es lo que traigo hoy para ustedes. Aprenderemos a registrar información de LOG de nuestros desarrollos utilizando un servidor de LOG (SYSLOG) freeware disponible para Windows.

::[A TODAS ESTAS, ¿QUÉ ES UN LOG?]::

Un LOG es una bitácora de sucesos, un registro de todo lo que va sucediendo en un sistema, generalmente un LOG registra: acciones asociadas del usuario con el sistema, por ejemplo: "el usuario fulano, acaba de borrar el registro 10" ó "el usuario fulano acaba de iniciar sesión en la aplicación" ó bien "el usuario fulano no logra actualizar el registro 20 porque no tiene los suficientes derechos para hacerlo", etc. En un LOG también se registran acciones del propio sistema, por ejemplo: "el proceso programado xyz acaba de ejecutarse" ó "el proceso programado xyz acaba de finalizar satisfactoriamente", ó bien, "el sistema no logra conectarse con el servidor de base de datos especificado", etc. En general en un LOG podemos registrar lo que nos venga en gusto, simpre y cuando tengamos presentes dos objetivos principales:

A parte de nuestros propios mensajes personalizados, podemos dentro de la aplicación que desarrollamos, capturar las diferentes condiciones de error (una división por cero, por ejemplo) para registrarlas en un LOG y así ubicar la solución a un problema lo más pronto posible. En fin, todo queda a nuestro amaño.

::[BUENO, YA TENGO CLARO LO DEL LOG, ¿QUÉ MÁS NECESITO SABER?]::

Para los propósitos de este artículo, necesitamos saber que significa el término SYSLOG. SYSLOG es un estándar de facto para dirigir los mensajes de LOG en una red basada en el protocolo IP (no se asuste, no lo voy a enredar). Según Wikipedia:

---

El término SYSLOG es utilizado para definir el actual protocolo "syslog" como para definir la aplicación o la librería que envía mensajes SYSLOG.

---

Algo abstracto ¿no?. Vamos a ver que no. Pongámolo así: SYSLOG es un estándar que define el formato y la estructura de los mensajes que serán registrados en un LOG, entre muchas otras cosas. Mas claro ¿cierto?. En fin, el protocolo SYSLOG es un protocolo bastante simple de implementar:

El receptor de los mensajes de SYSLOG es comunmente denominado "servidor de SYSLOG", "demonio de SYSLOG" ó "servicio de SYSLOG".

Los mensajes de SYSLOG son enviados utilizando el protocolo de nivel de transporte en la redes IP, denominado UDP (no es necesario asustarnos, no los voy a enredar). UDP es un protocolo de comunicaciones "no orientado a la conexión", por eso es que cuando un servidor de SYSLOG recibe un mensaje, no es necesario devolver una respuesta al emisor del mismo. No voy a entrar en más detalle de lo que es UDP, pués no es el objetivo de este artículo.

Los servidores, demonios o servicios de SYSLOG generalmente ponen a la escucha un socket en UDP y puerto 514 (eso dice el estándar que define el protocolo SYSLOG). Recordemos que al mencionar las palabra servidores, servicios o demonios estoy haciendo referencia a simples programas de computadora que se comportan de manera especial, se comportan como servicios, es decir, siempre están activos esperando que alguién los ponga a trabajar.

::[¿CÓMO ES EL ESQUEMA?]

Antes de comenzar con el desarrollo, tengamos claro la integración del esquema general de todos los componentes que acabamos de revisar.

Un esquema en donde mi aplicación y el servidor de SYSLOG están instalados en la misma máquina

Recordemos que los puertos son una puerta de entrada para comunicarnos con las aplicaciones que los implementan. En el caso del servidor SYSLOG, éste cuenta con la puerta marcada como "UDP - 514". Es a esta puerta de entrada a donde vamos a mandar los mensaje que queremos registrar en el LOG, el servidor de SYSLOG se encargará de irlos registrando en un archivo.

Hay otros esquemas más elaborados en donde podemos colocar nuestro servidor de SYSLOG en otra máquina distinta de nuestras aplicaciones y comunicarnos con ella por algún medio específico. Estos esquemas se adoptan por seguridad, pero por ahora nos basta con la ilustración anterior.

Como mencioné en la introducción de este artículo, el componente relacionado al servidor de SYSLOG será Kiwi Syslog Daemon. Un servidor de SYSLOG Freeware disponible para Windows.

::[AHORA SI, A TOCAR]::

They call me Cuban Pete
I'm the king of the Rumba beat
When I play the maracas I go
Chick-chicky-boom Chick-chicky-boom

Lo primero que vamos hacer es descargarnos el servidor de SYSLOG que utilizaremos (Kiwi Syslog Daemon - http://www.kiwisyslog.com).

Los detalles de la instalación son triviales, lo único que se me ocure apuntar es que cuando el proceso de instalación pregunte en que modo deseamos instalar el servidor de SYSLOG, seleccionemos la opción que dice Install Kiwi Syslog Daemon as Service.

Una vez hayamos completado el proceso de instalación, lancemos la ejecución de Kiwi Syslog Daemon. En la ventana de la aplicación vayamos al menú Manage y seleccionamos la opción Install the syslogd service. Si todo funcionó bien, Kiwi Syslog Daemon nos avisará con un mensaje que dice The Syslog Daemon Service has been installed succesfully...

Luego, hacemos nuevamente clic en el menú Manage y seleccionamos la opción Start the syslogd Service CRTL+F1. Veremos en la barra de estado de la ventana de Kiwi Syslog Service Manager, un mensaje que dice: The Syslogd Service has been started.

Para corroborar lo anterior, vamos a verificar si en nuestra máquina, en donde acabamos de instalar el servidor de SYSLOG, tenemos un puerto a la escucha en UDP puerto 514. Para ello abrimos una ventana de MS-DOS (ó de símbolo de sistema, como prefieran llamarla), escribimos el comando netstat -a -n y pulsamos enter.

La salida del comando anterior debe verse de manera similar a la siguiente:

C:\>netstat -an

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:3306           0.0.0.0:0              LISTENING
  TCP    10.100.0.11:139        0.0.0.0:0              LISTENING
  TCP    10.100.0.11:1465       10.100.0.8:445         ESTABLISHED
  TCP    10.100.0.11:1470       217.112.37.36:80       TIME_WAIT
  TCP    10.100.0.11:1476       217.112.37.29:80       TIME_WAIT
  TCP    10.100.0.11:1477       217.112.37.36:80       ESTABLISHED
  TCP    10.100.0.11:1478       222.124.34.58:443      ESTABLISHED
  TCP    127.0.0.1:1028         0.0.0.0:0              LISTENING
  TCP    127.0.0.1:1033         127.0.0.1:1034         ESTABLISHED
  TCP    127.0.0.1:1034         127.0.0.1:1033         ESTABLISHED
  UDP    0.0.0.0:445            *:*
  UDP    0.0.0.0:500            *:*
  UDP    0.0.0.0:514            *:*
  UDP    0.0.0.0:1035           *:*
  UDP    0.0.0.0:1036           *:*
  UDP    0.0.0.0:1045           *:*
  UDP    0.0.0.0:1046           *:*
  UDP    0.0.0.0:1130           *:*
  UDP    0.0.0.0:1131           *:*
  UDP    0.0.0.0:4500           *:*
  UDP    10.100.0.11:123        *:*

De especial interés la línea que tengo señalada en color rojo y en negtrita. Esto nos confirma que tenemos a la escucha el servidor SYSLOG a la espera de nuestros mensajes.

La versión Freeware de Kiwi Syslog Daemon tiene las siguientes características que exhorto al lector para que las explore:

• Interface de administración gráfica.
• Los mensajes son mostrados en tiempo real a medida que se van recibiendo.
• 10 Displays virtuales para la organización de los mensajes de SYSLOG.
• Almacenamiento y redirección de todos los mensajes de LOG o de solo aquellos basados en la prioridad o en la hora.
• Auto fragmentación de los archivos en donde son registrados los mensajes de LOG por prioridad o por hora.
• Recepción de mensajes vía UDP, TCP y SNMP.
• Reenvío de mensajes vía UDP ó TCP.
• Almacenamiento automático de los mensajes de LOG basado en una programación personalizada.
• Alarmas audibles o por e-mail cada hora de los mensajes.
• Alarma sonora o por e-mail del tamaño del archivo de LOG.
• Envío diario de e-mail con las estadísticas del servidor SYSLOG.
• Minimización de su interface administrativa a la bandeja del sistema.
• Mantenimiento de la dirección IP fuente en el reenvío de los mensajes a otros servidores SYSLOG.
• Estadísticas de las tendencias del servidor de SYSLOG (cada 60 min ó cada 24 horas).
• Buffering de los mensajes de SYSLOG que aseguran que ningún mensaje se pierda bajo condiciones de carga pesada para el sistema.
• Resolución DNS del emisor de los mensajes de SYSLOG con opción para remover el componente del dominio en la resolución.
• DNS caché de hasta 100 entradas.
• Resolución preventiva de DNS de hasta 10 hilos.
• 5 Skins disponibles para cambiar la apariencia de la interface administrartiva.
• Posibilidad de seleccionar la fuente, el color del display y el wallpaper.
• Disponible como servicio de NT.
• Compatible con las opciones de envío y recepción especificadas en el RFC 3164.
• Ayuda basada en el contexto.
• Freeware.

Hasta este punto ya tenemos listo el componente que nos va a escuchar y registrar los mensajes de LOG de nuestra aplicación, si miramos la ilustración del esquema, tenemos hasta aquí el componente ilustrado con el circulo verde. Nos falta entonces el componente de nuestra aplicación, que por opciones de comprensibilidad vamos a desarrollarla en Microsoft Visual Basic 6.0. Aclaro que, no solo desde Visual Basic se puede hacer lo que vamos hacer en este artículo, los expertos en otros lenguajes, como C, C++, Phyton, PHP, Java, etc. seguro tendrán que hechar mano del API Sockets (en cualquier sistema operativo) para lograr la comunicación con el servidor SYSLOG y así transmitir los correspondientes mensajes de LOG.

La idea detrás de la aplicación (Opera Huevos) que va a registrar los mensajes en el servidor de SYSLOG, será una pantalla de inicio de sesión básica, en donde un usuario deberá autenticarse de manera muy simple. Una vez autenticado el usuario, será llevado a una pantalla en donde podrá realizar las cuatro operaciones básicas entre dos operandos distintos. Los mensajes que vamos a registrar en el LOG serán los siguientes:

• Inicio de la aplicación.
• Intentos de LOGIN fallidos (con tres intentos fallidos, la aplicación deberá finalizar).
• Intentos de LOGIN exitosos.
• Al menos una condición de error.

Como tampoco es el objetivo, no voy a profundizar sobre los aspectos de programación de Visual Basic 6.0, solo en los que yo crea necesario hacer claridad, la haré.

Las siguientes figuras ilustran el Look-n-Feel de nuestra aplicación (Opera Huevos).

Look-n-Feel de la pantalla de Login

Look-n-Feel de la pantalla de operaciones

Vamos en este punto a insertar el control Winsock a nuestro proyecto de Visual Basic. Para los que no sabemos que es el control Winsok, aquí hay una definición que tomo textualmente del MSDN.

---

El control WinSock permite conectarse a un equipo remoto e intercambiar datos con el Protocolo de datagramas de usuario (UDP) o con el Protocolo de control de transmisión (TCP). Ambos protocolos se pueden usar para crear aplicaciones cliente-servidor. Al igual que el control Timer, el control WinSock no tiene una interfaz visible en tiempo de ejecución.

---

Yo diría que el control Winsock no solo permite conectarse a un equipo remoto, también permite conectarse a aplicaciones locales que estén escuchando un puerto en los protocolos TCP y/o UDP. Este es nuestro caso, ya que necesitamos comunicarnos con el servidor de SYSLOG para que registre los mensajes de nuestra aplicación en un LOG. Recordemos que la comunicación con el servidor de SYSLOG se hace a través del protocolo UDP puerto 514.

Para insertar el control Winsock a nuestro formulario de Login, procedemos de la siguiente manera: clic en el menú Proyecto/Project seleccionamos la opción Componentes/Components. En el cuadro de diálogo de componentes buscamos en la pestaña de Controles/Controls, el control Microsoft Winsock Control 6.0 (SP5) y lo marcamos. Para finalizar hacemos clicl sobre el botón Aceptar/OK.

En la barra de controles de formulario se nos ha insertado el control Winsock el cual tiene la siguiente apariencia:

Apariencia del control Winsock

El siguiente paso consiste en que, con el mouse seleccionamos el control Winsock y luego lo añadimos al formulario de Login. No importa donde se coloque, el control no es visible en tiempo de ejecución de la aplicación.

Vamos a configurar el control Winsock para que cuando lo usemos, le envíe los mensajes el servidor SYSLOG. Para ello, establecemos las propiedades del control Winsock de la siguiente manera:

• Name: WS
• Protocol: 1-sckUDPProtocol
• RemoteHost: 127.0.0.1
• RemotePort: 514

La primera propiedad especifica el nombre del control y nos sisrve para que ustedes y yo nos entendamos y hagamos referencia al mismo control. Como lo habrán notado, la segunda propiedad especifica el protocolo que vamos a utilizar, como ya lo he repetido varias veces, la comunicación con el servidor SYSLOG se realiza a través del protocolo UDP. La tercera propiedad especifica en donde está la contraparte que completa la comunicación, es decir, en donde está el servidor SYSLOG, el valor de 127.0.0.1 se denomina dirección IP LoopBack, esta dirección IP hace referencia a nuestra propia máquina.

Recordemos que para comunicarme con una aplicación a través de un puerto, yo debo especificar la dirección IP y número de puerto en donde está la aplicación con la que deseo comunicarme. Por ejemplo, si mi servidor SYSLOG estuviera residente en la máquina cuya dirección IP es 192.168.0.1, entonces el valor de la propiedad RemoteHost sería esta dirección IP. La cuarta propiedad indica el número de puerto a donde nos vamos a conectar. ¿Porqué 514?, lineas más arriba lo he dicho en varias ocasiones.

Bien, pero antes de ponernos a enviar mensajes al servidor SYSLOG como locos, es necesario saber que dice el estándar SYSLOG (por cierto, el protocolo SYSLOG está definido en el RFC 3164) frente a la composición de los mensajes, es decir, debemos saber como debe organizarse un mensaje de LOG antes de enviarlo al servidor de LOG.

Retomamos nuestra aplicación más adelante.

::[COMPONENTES DE UN MENSAJE SYSLOG]::

Un mensaje SYSLOG está compuesto de tres partes principales:

Estructura de un mensaje SYSLOG

El componente PRI

---

NOTA 1: Diferentes sistemas operativos utilizan las facilidades 4, 10, 13 y 14 con propósitos de seguridad, autorización, auditoria y mensajes de alerta.

NOTA 2: Diferentes sistemas operativos utilizan las facilidades 9 y 15 para registrar mensajes del subsistema del reloj y taread programadas

---

Por ejemplo un mensaje del kernel (facilidad = 0) con una severidad de emergencia (severidad = 0) tendrá un valor de prioridad 0. Un mensaje de uso local (facilidad = 20) con una severidad de aviso (severidad 5) generará un valor de prioridad de 165.

El valor de prioridad deberá ir encerrado entre los cractéres "<" y ">" como se mencionó anteriormente.

El componente HEADER

Acabamos de ver el componente PRI de un mensaje SYSLOG, ahora concentrémonos en el componente HEADER del mensaje SYSLOG.

Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec

• dd corresponde al dia del mes de 1 a 31, si el numero de mes es de un solo caractér debe ajustarse un espacio en blanco.
• hh:mm:ss corresponde a la hora local: hh especifica la hora en formato de 24 horas de 00 a 23, mm y ss corresponden a los minutos y segundos respectivamente, de 00 a 59.
• El campo HOSTNAME debe contener solo el nombre de host ó su dirección IPv4 ó IPv6.
• El campo TIMESTAMP se separa del campo HOSTNAME con un espacio sencillo.

Revisando la estructura del mensaje SYSLOG hasta este punto, tenemos entonces:

El componente MSG

Hasta este punto veríamos la estructura del mensaje SYSLOG de la siguiente manera:

No puede ser mas simple, miremos el siguiente ejemplo:

<34>Oct 11 22:14:34 localhost [mi_proceso]: no se olvide que usted tiene que comer para poder escribir

Analizando la estructura del ejemplo anterior, encontramos todos los componentes de un mensaje SYSLOG en él:

Si ven que simple es componer un mensaje SYSLOG.

Tarea siguiente: Diseñar una función en Visual Basic que pasada una cadena de caractéres como parámetro y un código de severidad, ésta nos devuelva el correspondiente mensaje SYSLOG para enviar al servidor de SYSLOG.

::[DISEÑO DE LA FUNCIÓN]::

• Primero, obtener MES, DIA, HORA, MINUTOS y SEGUNDOS:

      MES = Month(Date)
      DIA = Trim(Str(Day(Date)))
      HORA = Trim(Str(Hour(Time)))
      MIN = Trim(Str(Minute(Time)))
      SEG = Trim(Str(Second(Time)))
  
    

• Segundo, evaluamos el número de Mes para convertirlo al formato Mdd y guardamos la conversión en un variable para usarla luego:

  Select Case MES
        Case 1
            CAD_MES = "Jan"
        Case 2
            CAD_MES = "Feb"
        Case 3
            CAD_MES = "Mar"
        Case 4
            CAD_MES = "Apr"
        Case 5
            CAD_MES = "May"
        Case 6
            CAD_MES = "Jun"
        Case 7
            CAD_MES = "Jul"
        Case 8
            CAD_MES = "Aug"
        Case 9
            CAD_MES = "Sep"
        Case 10
            CAD_MES = "Oct"
        Case 11
            CAD_MES = "Nov"
        Case 12
            CAD_MES = "Dec"
    End Select

• Tercero, hacemos los respectivos ajustes en caso de obtener numeros de día, hora, minutos y segundos inferiores a 10, es decir, valores inferiores a dos caractéres de logitud.

    If Len(DIA) <> 2 Then
        DIA = " " & DIA
    End If
    
    If Len(HORA) <> 2 Then
        HORA = "0" & HORA
    End If
    
    If Len(MINUTOS) <> 2 Then
        MINUTOS = "0" & MINUTOS
    End If
	
    If Len(SEGUNDOS) <> 2 Then
        SEGUNDOS = "0" & SEGUNDOS
    End If
  

• Cuarto, calculamos la prioridad del mensaje SYSLOG basados en un código de "facilidad" pre-establecido. Para nuestro ejemplo utilizaremos el código de "facilidad" 16, es decir "Local Use 0":

  SYSLOG_FACILITY = 16
  SLOG_PRI = (SYSLOG_FACILITY * 8) + SEVERIDAD
  

• Armamos el mensaje SYSLOG con valor del campo HOSTNAME igual a "localhost" y el campo TAG igual "[OPERA_HUEVOS]:"

  SYSLOG_TAG = "[OPERA_HUEVOS]:"
  HOSTNAME = "localhost"
  SLOG_MENS = "<" & SLOG_PRI & ">" & CAD_MES & " " & DIA & " " & HORA & ":" & MINUTOS & ":" & SEGUNDOS & " " & HOSTNAME & " " & SYSLOG_TAG & " " & MSG

Ahora veamos el código completo de la funcion MensajeLog()

Private Function MensajeLog(MSG As String, SEVERIDAD As Integer) As String
    Dim HORA As String
    Dim MIN As String
    Dim SEG As String
    Dim MES As Integer
    Dim CAD_MES As String
    Dim DIA As String
    Dim SLOG_MENS As String
    Dim SLOG_PRI As Integer
    Dim SYSLOG_FACILITY As Integer
    Dim HOSTNAME As String
    Dim SYSLOG_TAG As String
    
    
    MES = Month(Date)
    DIA = Trim(Str(Day(Date)))
    HORA = Trim(Str(Hour(Time)))
    MIN = Trim(Str(Minute(Time)))
    SEG = Trim(Str(Second(Time)))

    
    Select Case MES
        Case 1
            CAD_MES = "Jan"
        Case 2
            CAD_MES = "Feb"
        Case 3
            CAD_MES = "Mar"
        Case 4
            CAD_MES = "Apr"
        Case 5
            CAD_MES = "May"
        Case 6
            CAD_MES = "Jun"
        Case 7
            CAD_MES = "Jul"
        Case 8
            CAD_MES = "Aug"
        Case 9
            CAD_MES = "Sep"
        Case 10
            CAD_MES = "Oct"
        Case 11
            CAD_MES = "Nov"
        Case 12
            CAD_MES = "Dec"
    End Select        
    
    If Len(DIA) <> 2 Then
        DIA = " " & DIA
    End If
    
    If Len(HORA) <> 2 Then
        HORA = "0" & HORA
    End If
    
    If Len(MINUTOS) <> 2 Then
        MINUTOS = "0" & MINUTOS
    End If
	
    If Len(SEGUNDOS) <> 2 Then
        SEGUNDOS = "0" & SEGUNDOS
    End If

    
    SYSLOG_FACILITY = 16
    SYSLOG_TAG="[OPERA_HUEVOS]:"
    SLOG_PRI = (SYSLOG_FACILITY * 8) + SEVERIDAD
  
    HOSTNAME = "localhost"
    SLOG_MENS = "<" & SLOG_PRI & ">" & CAD_MES & " " & DIA & " " & HORA & ":" & MINUTOS & ":" & SEGUNDOS & " " & HOSTNAME & " " & SYSLOG_TAG & " " & MSG
    MensajeLog = SLOG_MENS
End Function

Sencillo. Ya tenemos la función que pasados como parámetros una cadena de caractéres y un código de severidad, arma un mensaje SYSLOG para nosotros, ahora es nuestra tarea usar la función en la aplicación que venimos desarrollando. Es importante aclarar que esta función nos arma un mensaje SYSLOG de acuerdo al RFC3164 (en donde se define el protocolo SYSLOG) es nuestra tarea enviar el mensaje que ella arma haciendo uso del control Winsock.

::[EL MENSAJE EN UNA BOTELLA]::

El código anterior lo seleccionamos, copiamos y pegamos en el código del formulario de Login de nuestra aplicación para poder usarlo. Vamos a comenzar a cumplirle a lo que más arriba dijimos que ibamos a registrar en LOG:

• Inicio de la aplicación: agrego al evento Load() del formulario de Login el siguiente código:

  WS.SendData WS.SendData MensajeLog("La aplicacion acaba de iniciarse", 6)

El método SendData del control Winsock es el que nos permite enviar un mensaje al servidor de SYSLOG. El método SenData recibe como parámetro el mensaje o lo datos que deseamos enviar, para ello llamamos a la función MensajeLog() pasándole como parámetro la cadena "La aplicación acaba de iniciarse" con el código de severidad igual a 6. Cuando la función retorna, retorna con una cadena de caractéres que sigue la estructura de los mensajes SYSLOG, esta cadena es la que recibe el método SendData para enviarla al servidor de SYSLOG.

Al iniciar la aplicación lo que sucede es lo siguiente en el servidor Kiwi Syslog Daemon:

El mensaje es recibido por el servidor tal cual lo enviamos desde la aplicación .

• Intentos de Login fallidos:

He aquí toda la lógica del botón Login de nuestra aplicación, no voy a explicar nada, creo que está lo suficientemente bien comentado:

Private Sub cmdLogin_Click()
    Const USUARIO = "operahuevos"
    Const CONTRASENA = "agoodcalc"
    Const MAX_INTENTOS = 3
    
    'Para almacenar la respuesta del usuario cuando se equivoca haciendo Login
    Dim RESPUESTA As Integer
    
    'Si lo introducido en txtUsuario y lo introducido en txtContrasena
    'son iguales a los valores de las constantes USUARIO y CONTRASENA
    'respectivamente, descargamos el formulario actual y mostramos el
    'formulario de operaciones
    If txtUsuario.Text = USUARIO And txtContrasena.Text = CONTRASENA Then
        
        'Registro en el LOG el acceso exitoso a la aplicación"
        WS.SendData MensajeLog("El usuario acaba de iniciar sesión en la aplicación con los siguentes datos: USUARIO = '" & txtUsuario & "' CONTRASENA = '" & txtContrasena, 6)
        
        Unload Me
        frmOperaciones.Show

    Else
        
        'Si la información de Login es incorrecta, mostramos un mensaje de error y
        'le damos la oportunidad al usuario de volverlo a intentar una vez más, hasta
        'el valor de la constante MAX_INTENTOS
        RESPUESTA = MsgBox("Login incorrecto, intente nuevamente", vbOKCancel Or vbCritical, "Login incorrecto")
        
        'Si el usuario hace clic sobre el botón Cancelar del mensaje de error,
        'finalizamos la aplicación
        Select Case RESPUESTA
            Case vbCancel
                End
        End Select
        
        'Sino hizo clic en el botón Cancelar es porque hizo clic en el botón
        'Aceptar, entonces contamos un intento de Login
        NUM_INTENTOS = NUM_INTENTOS + 1
        
        'Registro en el LOG el evento con una severidad de 1 (Alert)
        WS.SendData MensajeLog("Intento de login fallido: USUARIO = '" & txtUsuario & "' CONTRASENA = '" & txtContrasena & "' INTENTO = '" & NUM_INTENTOS & "'", 1)
        
        'Si el numero de intentos llega al valor especificado por la constante
        'MAX_INTENTOS entonces finalizamos la aplicación
        If NUM_INTENTOS = MAX_INTENTOS Then
            End
        End If
    End If    
End Sub

Entonces esto es lo que se ve en el servidor Kiwi Syslog Daemon:

Note como en este caso he alterado la severidad de Informational (6) a Alert(1) recordemos que un LOG sirve para dos propósitos escenciales, encontrar posibles causas a los problemas y auditar las acciones de los usuarios. Un mensaje de Alerta en un intento de Login fallido puede decirle varias cosas al administrador del sistema:

1. Un usuario válido ha olvidado la contraseña o el nombre del usuario.
2. Un usuario inválido está intentado entrar al sistema por fuerza bruta, es decir, probando usuarios y contraseñas hasta que algun par de éstos le permita el acceso.

• Condición de error : Para generar la condición de error, en el formulario de Operaciones, permitiremos la división por Cero, capturamos el error que genera Visual Basic y lo mandamos al servidor de SYSLOG. Para lograr esto, añadamos otro control Winsock con el mismo nombre y las mismas propiedades que el control anterior al formulario de Operaciones, de igual forma, añadimos al código del formulario el código de la función SYSLOG.

El siguiente, es el flamante mensaje de error que nos retorna Visual Basic en caso de divisón por cero:

Con la captura del error, evitaremos esto, dando la oportunidad de que la aplicación "no casque" sino que le permita al usuario rectificar el valor de los operandos.

El siguiente es el código del botón "Ver Resultado", en donde capturamos el error y lo registramos en el servidor de SYSLOG:

Private Sub cmdResultado_Click()

'En caso de error vaya a la rutina que controla el error
On Error GoTo Error_cmdResultado_Click
    Select Case OPERADOR
        Case "/"
            txtResultado = txtOperando1 / txtOperando2
    End Select
Exit Sub

'Rutina que controla el error
Error_cmdResultado_Click:
    
    'Registro en el LOG la condición de error
    WS.SendData MensajeLog("Se ha generado el siguiente error: " & "Numero: " & "'" & Err.Number & "' Descripcion: '" & Err.Description & "'", 6)
    
    'Notifico la condición de error al usuario
    MsgBox "Se encontró un error, notifique al administrador del sistema o rectifique los valores de los operandos", vbCritical
    Resume Next
End Sub

Esto es lo que ve el usuario:

Esto es lo que queda registrado en el servidor de LOG:

En este punto ya estoy cansado de escribir. ¿Ven ahora si, la utilidad de un LOG?.

Cuando instalamos Kiwi Syslog Daemon y dejamos su configuración por defecto, éste guarda todo lo que recibe en la siguiente ruta:

C:\Archivos de programa\Syslogd\Logs\SyslogCatchAll.txt

El archivo SyslogCatchAll.txt tendrá todo lo que el servidor SYSLOG reciba. Cuando iniciamos Kiwi Syslog Daemon por primera vez, le dijimos que se instalara como servicio, de esta manera cada vez que se inicia Windows, éste estará trabajando en segundo plano, es decir, no lo vemos, pero ahí estará a la espera de que le enviemos algún mensaje para que lo registre.

::[FINALIZANDO]::

Aunque el ejemplo es demasiado simple, creo que sirve para ilustrar la utilidad que un servidor de SYSLOG aporta a nuestras aplicaciones. Imaginen no más la situación en donde el usuario le dice a uno: "Yo no borré eso, seguro que no lo borré, eso demás que lo borró el sistema", si claro, busquemos en el LOG a ver si es verdad lo que me estás diciendo. Seguro que ese usuario jamás volverá a hacer algo sin antes preguntárnoslo.

Nuevamente exhorto al lector a que explore algunas de las características que Kiwi Syslog Daemon nos facilita en su versión Freeware.

Los archivos del proyecto de Visual Basic se pueden descargar de AQUÍ.

El Kiwi Syslog Daemon lo pueden descargar de AQUÍ .

Ya saben, si me quieren dar duro con sus opiniones lo pueden hacer a mi dirección de correo: juanfelipe ::[AT]:: juanfelipe ::[DOT]:: net. No duden en escribir y exponer sus opiniones. Cada opinión la publicaré como comentario del artículo en la parte inferior del mismo.

::[REFERENCIAS]::

• RFC 3164: http://www.faqs.org/rfcs/rfc3164.html
• MSDN de Microsoft Visual Studio

::[PENDIENTES]::

• Hablar de las ventajas y deventajas del protocolo SYSLOG.
• Analizar alternativas que aseguren el tráfico del protocolo SYSLOG.

Juan Felipe Muñoz - Fernández