Monitoreo y control de salud
EJBCA incluye un servicio de comprobación de estado que permite la monitorización remota del estado. Esto es esencial si se ejecuta EJBCA en una instalación en clúster, ya que permite determinar si un nodo puede permanecer en el clúster o debe ser eliminado.
El propósito de un control de salud es notificar si algo no es como se esperaba para permitir que un sistema de monitoreo envíe alarmas y desconecte los nodos del clúster.
Un ejemplo, y fuente de un malentendido común, es que desconectar una CA (estado del servicio de la CA) es algo normal y no genera advertencias de HealthCheck. Esto se debe a que, si se ha desactivado una CA, esto se ha hecho deliberadamente; es decir, todo está como debería, y HealthCheck no debería emitir advertencias. Esto contrasta con lo que ocurre cuando se tiene la CA activada, pero el token criptográfico se desconecta. En ese caso, se espera que la CA esté conectada, pero no puede serlo porque el token criptográfico está desconectado y, por lo tanto, HealthCheck debería emitir una advertencia.
Tenga en cuenta que una configuración como en el siguiente ejemplo no generará advertencias de Healthcheck.
URL del servlet
El servlet se encuentra en la URL: http://localhost:8080/ejbca/publicweb/healthcheck/ejbcahealth
Tenga en cuenta que el cliente (por ejemplo, el balanceador de carga) es responsable de cerrar la conexión con el servidor de aplicaciones. De lo contrario, podría producirse una denegación de servicio , lo que impediría que otros clientes se conectaran a EJBCA.
Configuración
Las CA que verifica el servicio de verificación de estado se pueden configurar en la página Activación de CA del sitio web de administración, así como también en la página Editar CA.
Cumplimiento de criterios comunes
Para cumplir totalmente con los Criterios Comunes, se debe utilizar una clave diferente para las pruebas de firma que para la firma del certificado en la configuración del token HSM de la CA (el alias "testKey" debe apuntar a una clave sin otros usos).
El comportamiento del servlet se puede modificar configurando los siguientes valores en conf/ejbca.properties .
Configuración general
Se pueden establecer los siguientes parámetros de configuración para configurar la autorización y lo que verifica el servicio:
Llave | Por defecto | Descripción |
comprobación de salud.cantidadlibremem | 1 | La cantidad de memoria que debe estar libre en el servidor, en megabytes. |
consulta de comprobación de estado | seleccione 1 | Parámetro que indica la cadena que se debe utilizar para realizar una comprobación mínima de que la base de datos está funcionando. |
control de salud.ips autorizados | 127.0.0.1 | Especifica las IP remotas que pueden llamar a este servlet de comprobación de estado. Se pueden separar varias IP con punto y coma. |
comprobación de salud.prueba de firma de token de gato | FALSO | Establézcalo como verdadero para ejecutar una firma de prueba en cada token de CA durante la verificación. De lo contrario, solo verifica que el estado del token esté activo. |
comprobación de estado.conexiones del editor | FALSO | Establezca como verdadero para realizar una prueba de estado en todas las conexiones de editores activos. |
Propiedades del archivo de mantenimiento
Llave | Por defecto | Descripción |
archivo de mantenimiento de comprobación de salud | Ubicación del archivo que contiene información sobre el mantenimiento. | |
chequeo de salud.nombrepropiedaddemantenimiento | FUERA DE SERVICIO POR MANTENIMIENTO | La clave del valor de la propiedad en el mantenimiento, debe tener el siguiente formato: DOWN_FOR_MAINTENANCE=true . |
Configuración de servlets
Los siguientes parámetros configuran qué mensaje o código de error HTTP devuelve el servicio de salud.
Llave | Por defecto | Descripción |
mensaje de control de salud | OK | Cadena de texto que indica que todo está correcto en este nodo. Cualquier valor de propiedad definido se puede usar aquí insertándolo como propiedad, por ejemplo: |
comprobación de estado.sendservererror | verdadero | Establezca como verdadero el código de error HTTP 500 que se debe enviar en caso de error. |
comprobación de estado.mensaje de error personalizado | nulo | Permite configurar un mensaje de error personalizado. |
Mensajes de error
Si se detecta un error, se notificará uno o varios de los siguientes mensajes. Todos los errores se enviarán con el código de respuesta 500.
Error | Descripción |
MEM: Error La memoria virtual está a punto de agotarse, memoria libre actualmente: número | La JVM está a punto de quedarse sin memoria |
DB: Error al crear la conexión a la base de datos | La conexión JDBC a la base de datos falló, esto puede ocurrir si la base de datos falla o la red no funciona. |
CA: Error El token de CA está desconectado: CAName | Esto es una señal de problemas de hardware con uno o varios de los tokens de hardware del nodo. |
MANTENIMIENTO: INACTIVO POR MANTENIMIENTO | Esto se informa cuando se utiliza el archivo healthcheck.maintenancefile y el nodo está configurado para estar fuera de línea. |
Error al probar la conexión con el editor: PublisherName | Esto se informa cuando falla una conexión de prueba con uno de los publicadores. |
No se pudo realizar una firma de prueba en el registro de auditoría. | Se informa cuando el registro de auditoría no se pudo firmar (si la protección de la base de datos está habilitada) |