Monitorización Web

En Pandora FMS el Web Server funciona en un servidor independiente, el Network Server. Este sistema opera bajo el principio de transacción web, donde cada transacción completa contra una o varias páginas WEB está definida por uno o más pasos consecutivos, que deben concluir satisfactoriamente para considerar que la transacción ha terminado con éxito.

El Network Server viene activo por defecto. En función del número de peticiones puede que se tenga que aumentar el número de hilos y el timeout por defecto:

network_threads 4
web_timeout 60

También cada módulo puede utilizar un tiempo de espera distinto.

/etc/pandora/pandora_server.conf

# Uncomment to perform web checks with LWP instead of CURL.
#web_engine lwp

Al reiniciar el Pandora FMS Server se utilizará LWP para llevar a cabo las comprobaciones web en vez del binario de Curl.

Luego de colocar un nombre al módulo se debe elegir el tipo de módulo a utilizar:

1. Remote HTTP module to check latency: Obtiene el tiempo de carga total que transcurre desde la primera petición hasta que se comprueba la última.
   
   
2. Remote HTTP module to check server response: Este tipo de módulo funciona de manera similar al anterior, solamente con la diferencia de que carece de umbrales. Los únicos valores que obtiene es 1 para estado normal y 0 para estado crítico.
   
   
3. Remote HTTP module to retrieve numeric data: Utilizando una expresión regular, este módulo la aplica sobre la respuesta HTTP para conseguir un valor numérico.
   
   
4. Remote HTTP module to retrieve string data: Usando una expresión regular, este módulo la compara sobre la respuesta HTTP para conseguir un valor de texto.
   
   
5. Remote HTTP module to check server status code: El chequeo básico de una página web consiste en obtener rápidamente su código de estado y conocer de antemano si se pueden realizar más chequeos.
   
   

Este cuadro de texto viene acompañado de tres botones prácticos:

• Botón Load basic.

Coloca siempre el siguiente código sin importar si funciona o es compatible con el tipo de módulo seleccionado:

task_begin
get https://demoweb.com/page/
check_string text string or HTML code to search (regexp)
task_end

El código anterior es meramente ilustrativo, cada tipo de módulo web tiene sus instrucciones específicas y/o apropiadas para ello.

• Botón Check.

Al pulsarlo se verificará la sintaxis de los comandos insertados, si son válidos, caso contrario mostrará un icono amarillo con un mensaje emergente al colocar el puntero sobre el mismo. Esencialmente se asegura que se comience con task_begin y de que al menos aparezca una etiqueta task_end (este siempre debe aparecer de último). Se deberá revisar, según el tipo de módulo, los parámetros apropiados para cada consulta web.

• Botón Debug.

Muchas veces se necesita determinar a detalle si la consulta web está recibiendo la respuesta esperada. Para poderlo utilizar el módulo debe estar en un estado distinto al estado desconocido. También se deberá guardar el módulo cada vez antes de utilizar este botón.

Con este botón lo primero que se comprueba es si se recibe una respuesta distinta de HTTP 200. Esto se realiza por medio del siguiente parámetro de curl para el parámetro get:

-w '%{http_code}'

En el caso benigno de las redirecciones HTTP 3xx bastará con colocar la dirección final luego de la redirección. El comando curl puede utilizar el parámetro --location para seguir la redirección recibida.
Téngase en cuenta que al usar --location-trusted obligará a entregar toda la información establecida a la URL redireccionada.

Recibir un código HTTP 200 no necesariamente significa que la página esté disponible en realidad ya que luego se puede redirigir mediante JavaScript.

Si se retiran los parámetros -s, -o y -w (y sus valores), dejando solamente la URL, se podrá analizar el código HTML en sí mismo, lo cual puede ser útil para descartar un redireccionamiento por JavaScript, un CAPTCHA de protección para determinar si es un humano quien consulta, etcétera.

--user-agent 'Mozilla/5.0 \ 
(Windows NT 10.0; Win64; x64) \ 
AppleWebKit/537.36 \
(KHTML, like Gecko) \ 
Chrome/99.0.4844.84 \ 
Safari/537.36' 'https://pandorafms.com/en/'

Con la opción header se pueden modificar campos de la cabecera HTTP o crear campos personalizados. Para cambiar el campo Host de la cabecera HTTP:

task_begin
get http://192.168.1.5/index.php
header Host 192.168.1.1
task_end

En cada uno de los tipos de módulo de chequeos web, pestaña Basic, aparecerán los siguientes campos necesarios para el uso de proxy:

Se pueden monitorizar API de tipo REST, exceptuando los tipos de API más complejas basadas en protocolos como SOAP o XMLRPC.

Mediante la comprobación de la salida con una expresión regular y utilizando un módulo web para obtener respuestas de texto se puede verificar que esté todo correcto:

task_begin
get http://127.0.0.1/pandora_console/include/api.php?info=version
get_content 786
debug /tmp/api
task_end

Para el caso anterior de la API 1.0 PFMS se espera que devuelva la versión 786 y para que se reporte como estado crítico se ha de colocar este valor en el umbral Critical threshold (Min / Max), marcando Inverse interval (cualquier valor distinto a 786 hará que cambie a estado crítico).

Para respuestas más complejas se deben usar otras expresiones regulares y el token get_content_advanced.

En el siguiente caso con una respuesta en formato JSON se busca el campo license_mode y a continuación con una expresión regular se extrae su contenido:

task_begin
get http://127.0.0.1/pandora_console/include/api.php?op=get&op2=license&return_type=json&apipass=1234&user=admin&pass=pandora
get_content_advanced "license_mode":"([A-Za-z ]+)"
debug /tmp/api_license
task_end

Para lo anterior se espera que la respuesta sea Perpetual en el umbral crítico con intervalo inverso activado: Cualquier otro tipo de licencia hará que cambie el estado del módulo.

Por defecto los chequeos web en PFMS Server se realizan sin autorización de usuario alguna (Anyauth en el campo Check type). Algunas páginas pueden requerir autenticación simple HTTP (u otros métodos históricamente normalizados). Generalmente es utilizada como una comprobación rápida, un saludo de seguridad mínima que permite acceder a comprobaciones de seguridad más avanzadas (cifrado, persistencia de datos, etcétera).

Considérese el siguiente fichero con código PHP alojado en raíz de un servidor web denominado https://example.com/:

your_file_name.php

<?php
# BASIC authentication
if (!isset($_SERVER['PHP_AUTH_USER'])) {
    header('WWW-Authenticate: Basic realm="My Realm"');
    header('HTTP/1.0 401 Unauthorized');
    exit;
} else {
    echo "<p>Hello {$_SERVER['PHP_AUTH_USER']}.</p>";
    echo "<p>You entered {$_SERVER['PHP_AUTH_PW']} as your password.</p>";
}
?>

1. El código HTML es el mínimo para la prueba.
2. Ninguna comprobación de identidad es realizada. Simplemente se espera que se suministre un nombre de usuario y contraseña según la norma de autenticación BASIC.
3. En el PFMS Server a un agente se le agregará un módulo Remote HTTP module to check server response (verificar que se ha escogido ese tipo de módulo) de esta manera:

task_begin
# BASIC authentication
get https://example.com/your_file_name.php
check_string Pandor4!
task_end

• En el campo Check type se debe seleccionar BASIC.
• En el campo HTTP auth (login) colocar cualquier usuario.
• En el campo HTTP auth (password) colocar Pandor4!.
• Guardar el módulo y forzar el chequeo.

El comando check_string verificará que las contraseñas ficticias de prueba coincidan y colocará el módulo en normal. Para probar y comprobar el estado crítico cambie el campo HTTP auth (password) a cualquier otro valor y repita el procedimiento.

De forma similar se puede cambiar el fichero PHP de prueba con otras normas de autenticación.

• DIGEST:

your_file_name.php

<?php
# DIGEST authentication
<?php
if (!isset($_SERVER['PHP_AUTH_DIGEST'])) {
    header('HTTP/1.1 401 Unauthorized');
    header('WWW-Authenticate: Digest realm="My Realm",
           qop="auth", nonce="' . uniqid() . '",
           opaque="' . md5('My Realm') . '"');
    exit;
}

// Process the digest authentication
echo $_SERVER['PHP_AUTH_DIGEST'];
?>

task_begin
# DIGEST authentication
get https://example.com/your_file_name.php
check_string admin
task_end

Una comprobación de formulario es mucho más compleja que la simple comprobación de un texto en una página web. Para poder realizar este tipo de comprobaciones (POST) se deben tener las credenciales y/o variables necesarias. Además, es necesario ir a la página y obtener el código HTML para obtener los nombres de las variables, y luego es preciso tener conocimientos mínimos de HTML para introducir la consulta para el Network Server.

Considérese el siguiente fichero con código PHP alojado en la raíz de un servidor web llamado https://example.com/:

your_file_name.php

<?php
   if( $_POST["name"] || $_POST["age"] ) {
      echo "Welcome <b>". $_POST['name']. "</b><br />";
      echo "You are <i>". $_POST['age']. "</i> years old.<br />";
      echo 'Now: '.time();
      exit();
   }
?>
<form action = "<?php $_PHP_SELF ?>" method = "POST">
   Name: <input type = "text" name = "name" />
   Age: <input type = "text" name = "age" />
   <input type = "submit" />
</form>

1. Por razones didácticas se omite estricto código HTML.
2. La primera visita muestra un simple formulario para colocar nombre y edad y se debe colocar al menos uno de ellos. Al enviar los datos vía POST se mostrará un mensaje mostrando dicho o dichos valores introducidos.
3. El comando $_PHP_SELF permite utilizar cualquier nombre válido de fichero.
4. El comando time() (tiempo UNIX) será utilizado en los ficheros (registros) de depuración en una ventana terminal aparte.

En el PFMS Server se escogerá un agente para agregar un módulo Remote HTTP module to check server response con el siguiente script:

task_begin
debug /tmp/post_variable
variable_name name
variable_value JIMMY
variable_name age
variable_value 99
post https://example.com/your_file_name.php
# Verify if exists "<b>Jimmy<b>":
check_string \<b\>Jimmy\<\/b\>
task_end

El comando post se encarga de realizar la consulta web. Nótese que luego el comando check_string comprueba mayúsculas o minúsculas de manera indiferente. Si se consigue la variable con el nombre reportará estado normal, de lo contrario el módulo pasará a estar en estado crítico. Se puede probar y comprobar esto último haciendo el siguiente cambio y forzando luego el chequeo en el agente:

variable_name name
variable_value Kevin

En los módulos para chequeos web se incluye por Consola web los campos Requests (pestaña Basic) y Retries (pestaña Data).

Pandora FMS repetirá la comprobación el número de veces que se indique en este parámetro. Si una de las comprobaciones falla, la comprobación se dará como errónea.
Dependiendo de la cantidad de comprobaciones en el módulo se obtendrá un número determinado de páginas. Es importante tener esto en cuenta para calcular el tiempo total que tardará el módulo en completar las operaciones.

El número de veces que realiza un Request hasta conseguir un resultado exitoso.

Campo Agent browser ID (pestaña Basic): Identificador de navegador web a utilizar, ya que determinadas páginas solamente aceptan algunos navegadores web (más información).

El timeout está definido por defecto en el token web_timeout a 60 segundos.

Si se necesita un tiempo de espera distinto en un módulo específico se puede configurar en el campo Timeout de la pestaña Data.

Marca el inicio de un bloque de código el cual debe finalizar con task_end.

Cada módulo web deberá contener como mínimo un bloque de código, con al menos una instrucción a ejecutar:

task_begin
head https:/example.com/
task_end

Se podrán agregar varios bloques de código cuando se necesite comprobar formularios o, en general, cuando se tengan que realizar varios pasos adicionales para llegar a un resultado concreto:

• El caso más común es la comprobación de formularios, ya sea para procesos de autentificación de usuarios o llenar una encuesta con uno o varios campos a rellenar.
• Otro caso sería consultar una página web concreta y de acuerdo a su respuesta continuar y realizar una segunda consulta. En este escenario el resultado del primer y segundo bloque de código deben ser exitosos para que el chequeo completo sea dado como positivo y pasar a comparar con los umbrales del módulo a fin de determinar si debe cambiar su estado.

Especifica (resource 1) si en un bloque de código serán descargados los elementos multimedia como imágenes, sonido, etcétera.

Si este comando no aparece en un bloque de código implícitamente se utiliza resource 0.

Especifica (cookie 1) si en un bloque de código serán almacenadas las cookies obtenidas para su posterior uso en otros bloques de código.

Si este comando no aparece en un bloque de código implícitamente se utiliza cookie 0.

Comando que, utilizando variable_name y variable_value, especifica la URL del chequeo web. Si se utiliza más de una vez en un bloque de código la URL a examinar será la especificada en su última aparición.

Comando que especifica la URL del chequeo web. Si se utiliza más de una vez en un bloque de código todas las URL serán examinadas, sin embargo la URL especificada en su última aparición será la que entregue los datos para el chequeo.

Comando especial que devuelve la respuesta de código específico de la cabecera HTTP en un chequeo web.

El formato de respuesta es HTTP/V XXX donde V es la versión y XXX el código. Algunas respuestas que se pueden obtener: HTTP/2 403, HTTP/1.1 200, HTTP/1 302, etcétera.

Generalmente utilizado como único comando en también un único bloque de código, véase “Comprobación de código de estado del servidor” para más información.

Comprueba que en el chequeo web que se esté realizando exista una cadena de texto específica. El resultado devuelto es una variable booleana (0 falso, cualquier otro valor es verdadero) y se debe almacenar en un tipo de módulo de comprobación de respuesta de servidor (tipo web_proc).

Los argumentos que toma la sintaxis de check_string no son cadenas de texto normales, son expresiones regulares. Cualquier carácter que no sea una letra o un número tendrá que ser escapado con \:

task_begin
get https://apache.org/
# Comment: Search "/images/oakleaf.svg" (including quotation marks)
check_string \"\/images\/oakleaf\.svg\"
debug /tmp/apache
task_end

El siguiente código “limpio” es igualmente válido aunque se haya cambiado el orden de aparición del comando get (y aunque el botón Check indique que hay error) en un mismo bloque de código task_begin…task_end:

task_begin
check_string \"\/images\/oakleaf.svg\"
get https://apache.org/
task_end

Comprueba que en el chequeo web que se esté realizando carezca de una cadena de texto específica. En el resto de su funcionamiento es igual que check_string.

Declara una variable cuyo valor será establecido por la siguiente instrucción variable_value. Para mayor claridad del código se recomienda utilizar por pares ordenados de líneas contiguas.

Este par (o pares) de instrucciones debe(n) ir acompañada de un comando post. En la consulta web el orden de aparición de las variables será primero de la última declarada, segunda la penúltima declarada y así sucesivamente.

Establece el valor de una variable declarada con variable_name.

Para mayor claridad del código (y para facilitar labores de depuración, si es el caso) se recomienda utilizar por pares ordenados de líneas contiguas, primero variable_name y luego variable_value.

Si bien se pueden colocar estas instrucciones en cualquier orden, esto puede ocasionar resultados impredecibles si por error se establecen comandos impares o huérfanos.

A diferencia de los comandos check_string y check_not_string, los cuales solamente devuelven un resultado verdadero o falso, el comando get_content es utilizado cuando se necesita obtener un valor numérico o una cadena de texto específica.

De manera similar estos tres comandos emplean expresiones regulares para realizar su trabajo con la diferencia fundamental de que get_content entrega de manera íntegra el resultado de su búsqueda.

Para obtener un valor numérico de una consulta tipo API se puede emplear el siguiente código
get_content \d+ en un bloque de código task_begin … task_end:

task_begin
get http://127.0.0.1/pandora_console/include/api.php?apipass=1234&user=admin&pass=pandora&op=get&op2=total_modules&id=0
get_content \d+
debug /tmp/num_of_modules
task_end

Permite extraer una cadena de texto en un elemento HTML. También se podrán extraer valores “numéricos”, según la expresión regular utilizada. Sintaxis:

task_begin
get <URL>
get_content_advanced <html_code>(regex)</html_code>
task_end

Se debe utilizar en conjunto con get para establecer la URL a chequear. Una vez obtenido su contenido HTML se buscará toda la página hasta conseguir una coincidencia de elemento HTML y devolverá el contenido del mismo. Véase “Obteniendo datos textuales de una página web”.

Permite agregar encabezados HTTP a la consulta web.

Por defecto se utiliza Curl para realizar los chequeos web y siempre se incluyen dos elementos:

1. -H 'Pragma: no-cache': Usado para omitir el cache de los CDN. Pragma es compatible con HTTP 1.0 (las versiones HTTP más utilizadas actualmente son 1.1 y 2.0).
2. -H 'Accept: text/html': Con esto se indica que se solicita el código HTML como primera respuesta.

Con header incluido en un bloque task_begin…task_end se pueden especificar pares de valores adicionales. En una consulta API 1.0 PFMS esto resulta de mucha utilidad cuando se hace autenticación por medio del Bearer token privado de un usuario y luego se comprueba un valor esperado de respuesta con check_string:

task_begin
header Authorization Bearer 05c43863bf76c54456837ea7c3008e56
get http://127.0.0.1/pandora_console/include/api.php?op=get&op2=test
debug /tmp/api
check_string 786
task_end

También podría ser de utilidad para solicitar explícitamente que se responda en un idioma específico:
header Accept-Language es-ES.

• El idioma header Accept-Language es-ES se consulta así con Curl:
  -H 'Accept-Language:es-ES'
• El referido (indica la página web visitada anteriormente) header Referer pandorafms.com:
  -H 'Referer:pandorafms.com'
• Si el servidor web consultado requiere de encabezados particulares estos deben comenzar con -X…. Se suele acompañar luego de uno o varios guiones y, eso sí, con el nombre y valor del encabezado en sí mismo.
  Tómese el caso de enviar el identificador de un cliente header X-Customer-ID “Ñ123”, se consulta:
  -H 'X-Customer-ID:"Ñ123"' (nótese el uso de comillas dobles para envolver Ñ123).

Véase también:

• Identificador de navegador web.
• cookie.

Se pueden depurar los chequeos web añadiendo la opción debug <path>/<file_name>.
Se crearán dos ficheros <path><file_name>.req y <path><file_name>.res con los contenidos de la petición HTTP y la respuesta, respectivamente:

task_begin
get http://192.168.1.5/index.php
debug /tmp/debug_file
task_end

Al forzar los chequeos para acelerar el trabajo de depuración siempre se deberá esperar por la respuesta del servidor o dispositivo al cual se está monitorizando. Existe, al menos, una manera de ver por línea de comando el contenido de dichos ficheros en tiempo real:

tail -f <path><file_name>.res --retry

Marca la finalización de un bloque de códigos. Véase task_begin.

Para comprobar el tiempo de respuesta en segundos (latencia) de una página web se selecciona el tipo de módulo Remote HTTP module to check latency.

En una prueba WEB puede existir una o varias peticiones intermedias que completan la transacción. De esta manera obtiene el tiempo total que transcurre desde la primera petición hasta que se comprueba la última.

task_begin
get https://pandorafms.com
task_end

• Si en la definición del chequeo se ha definido que la transacción se realice más de una vez (comando get), se utilizará la media del tiempo de cada petición.
• Los umbrales para los estados de advertencia y criticidad deben ser establecidos por el usuario.
• Para que el tiempo de descarga incluya todos los recursos (JavaScript, CSS, imágenes, etcétera) se debe añadir resource 1 en una línea antes de task_end.
• Los chequeos web también soportan el uso de servidores intermediarios, para ello de se deben completar los campos denominados Proxy que sean necesarios.
• EL parámetro debug es utilizado para llevar registro acumulado en sendos ficheros tanto de la consulta como de la respuesta de cada chequeo.

Con un módulo tipo Remote HTTP module to check server response se obtiene un 1 (OK) o un 0 (CRITICAL) como resultado de comprobar toda la transacción.

Si existen varios intentos pero al menos uno de ellos falla, se considera que la prueba en su conjunto, también falla. Precisamente, el número de intentos se utiliza en ocasiones para evitar falsos positivos, para ello utilice el campo Requests en opciones avanzadas.

En su sintaxis básica basta con agregar en el cuadro Web Checks:

task_begin
get <URL>
task_end

A diferencia de la comprobación de estado HTTP el chequeo anterior trae todo el código HTML lo que puede ser aprovechado para usos adicionales como el comprobar de que existe una cadena de texto en dicha web con check_string:

task_begin
get <URL>
check_string <text>
task_end

• Si la cadena de texto solicitada existe pasará a estado normal, de lo contrario pasará a crítico.
• Se puede utilizar check_not_string <text> para el caso contrario: Al no hallar el texto indicado pasará a estado normal, de lo contrario pasará a crítico.
• Aunque se pueden utilizar otros parámetros como resource para descargar todos los recursos (imágenes, etcétera) esto solamente recargará de trabajo innecesario al PFMS Server.
  Hay que sopesar bien el agregar otros parámetros, solamente se han de usar los realmente necesarios, sobre todo si es una consulta simple.
• De igual manera aplica para la descarga y guardado de cookies, a menos que se vayan a realizar otros pasos de chequeos web, se puede declarar explícitamente pasar de ellos:

task_begin
get https://apache.org/
# No save cookie
cookie 0
# Do not download images, etc
resource 0
check_string Jimmy
debug /tmp/apache
task_end

Para comprobar que una página web responde con un valor numérico, o contiene un valor específico, se utiliza el tipo de módulo Remote HTTP module to retrieve numeric data.

Para ello se puede usar la consulta básica get_content \d+ (la expresión regular agregada filtra solamente dígitos). El mecanismo es analizar toda la respuesta HTTP desde el principio y comenzar a comparar hasta que coincide con la expresión regular dada.

• Los umbrales para los estados de advertencia y criticidad deben ser establecidos por el usuario. Por defecto estos umbrales son cero así que cualquier chequeo numérico válido obtenido será clasificado como estado normal.
• Se pueden utilizar servidores intermediarios completando los campos denominados Proxy que sean necesarios.
• Agregando la instrucción debug se conservan las consultas y respuestas en sendos ficheros para ser depurados posteriormente.
• Para obligar a consultar de manera directa con Curl al servidor web (omitiendo así el cache de los CDN) PFMS incluye por defecto la orden header Pragma: no-cache.
  Se eligió Pragma vez de Cache-Control para mantener compatibilidad con HTTP 1.0 (las versiones más utilizadas actualmente son 1.1 y 2.0).
• Para una consulta avanzada y extraer un valor numérico de un elemento HTML cualquiera de la página, como un título nivel 3 o el primer párrafo que aparezca con un Atributo CSS específico, véase el parámetro get_content_advanced.

El tipo de módulo Remote HTTP module to retrieve string data funciona de manera parecida a su contraparte numérica sin el inconveniente proceso de filtrado para garantizar solamente cifras.

task_begin
get https://academy.pandorafms.com/
get_content_advanced <h3 class="h2-b">(.*)</h3>
task_end

Aquí get_content_advanced es el parámetro clave que permite escoger un elemento HTML (en este caso un título nivel tres h3, clase ha2-b) y luego, según una expresión regular (.*), extraer la cadena de caracteres allí ubicada.

Como para la condición normal no se pueden comparar valores pues se utiliza el umbral de advertencia o el umbral de criticidad con el intervalo inverso establecido con el texto esperado:

Terms & Important Notes (nótese el uso de entities en el código HTML recibido).

Para comprobar el código de estado de una página web, se selecciona el tipo de módulo Remote HTTP module to check server status code (tipo web_server_status_code_string) con el siguiente bloque de código task_begin … task_end:

task_begin
head https://pandorafms.com
task_end

• En la configuración del servidor se debe utilizar Curl.
• Es importante utilizar el parámetro head para obtener el código de estado.
• Para configurar el umbral crítico se puede colocar HTTP/X 200 OK (donde X es la versión del protocolo) y marcando el intervalo inverso:

De esta manera al recibir cualquier respuesta distinta cambiará el módulo al estado crítico:

Además de la funcionalidad que ofrece Web server PFMS existe otra maneras de realizar una monitorización transaccional: la Monitorización de Experiencia de Usuario WEB (WUX).

Volver al índice de documentación de Pandora FMS