Aunque la supervisión de la aplicación de Looker no parezca obligatoria de manera estricta, es muy importante configurarla en instancias alojadas por el cliente. En el caso poco frecuente de que algo salga mal con tu servidor, suele ser mucho más difícil o imposible que Looker te ayude a solucionar el problema, a menos que puedas proporcionar la información de supervisión adecuada desde el momento del incidente.
Supervisión de la aplicación
URL
Existen dos formas sencillas de validar que tu instancia de Looker se esté ejecutando.
Agrega
/alive
a la URL de tu instancia de Looker de la siguiente manera:https://instance_name.looker.com/alive
Si tu instancia puede responder a una solicitud web, recibirás un código de estado HTTP 200 OK.
Agrega
/availability
a la URL de tu instancia de Looker de la siguiente manera:https://instance_name.looker.com/availability
Esta URL realiza una comprobación más completa de varios subsistemas subyacentes y, si todo funciona correctamente, responderá con un código de estado HTTP 200 OK.
JMX
La máquina virtual Java que ejecuta Looker se puede supervisar a través de JMX.
Muchas aplicaciones de supervisión, como Zabbix y Nagios, admiten JMX. Consulta la documentación de tu aplicación de supervisión para obtener más información.
Editar la secuencia de comandos de inicio de Looker
Para habilitar la supervisión de JMX, deberás editar tu secuencia de comandos de inicio de Looker. Su nombre predeterminado es el siguiente:
/home/looker/looker/looker
Busca los parámetros de inicio de Java:
java \
-XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
-Xms$JAVAMEM -Xmx$JAVAMEM \
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
-Xloggc:/tmp/gc.log ${JAVAARGS} \
-jar looker.jar start ${LOOKERARGS}
A partir de Looker 6.18, el archivo JAR de Looker se dividió en dos archivos JAR separados: el archivo JAR principal de Looker y un archivo JAR de dependencias de Looker. Al iniciarse, el archivo JAR principal iniciará automáticamente el archivo JAR de dependencias. Ambos archivos JAR deben estar en el mismo directorio para que el archivo JAR principal pueda encontrar e iniciar correctamente el archivo JAR de dependencias.
De forma predeterminada, la opción de inicio --no-daemonise
no está configurada. Si no estableciste la opción --no-daemonise
, agrega una sección después de la línea que comienza con -Xms$JAVAMEM
:
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.port=9910 \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.ssl=false \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.local.only=false \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.authenticate=true \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.access.file=${HOME}/.lookerjmx/jmxremote.access \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.password.file=${HOME}/.lookerjmx/jmxremote.password \
Si configuraste la opción de inicio --no-daemonise
, agrega una sección después de la línea que comienza con -Xms$JAVAMEM
:
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9910 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.local.only=false \
-Dcom.sun.management.jmxremote.authenticate=true \
-Dcom.sun.management.jmxremote.access.file=${HOME}/.lookerjmx/jmxremote.access \
-Dcom.sun.management.jmxremote.password.file=${HOME}/.lookerjmx/jmxremote.password \
Crea el directorio .lookerjmx
A continuación, crea el directorio .lookerjmx
en el directorio principal del usuario de Looker y establece los permisos:
sudo su - looker
mkdir ~/.lookerjmx
chmod 700 ~/.lookerjmx
cd ~/.lookerjmx
Crea los archivos JMX
Con tu editor de texto favorito, crea un archivo en el directorio nuevo llamado jmxremote.access
con el siguiente contenido (puedes personalizarlo para tu entorno):
monitorRole readonly
controlRole readwrite \
create javax.management.monitor.*,javax.management.timer.* \
unregister
A continuación, crea un archivo llamado jmxremote.password
en el mismo directorio con el siguiente contenido con tus propias contraseñas seguras:
monitorRole some_password_here
controlRole some_password_here
Configura los permisos
Asegúrate de que Java (y, por lo tanto, Looker) no se inicie si los permisos del archivo permiten que cualquier persona excepto el usuario de Looker pueda leer el archivo de contraseñas.
chmod 400 jmxremote.*
Reiniciar Looker
Se debe reiniciar Looker para habilitar JMX. Asegúrate de ejecutar esto *como usuario de Looker y no raíz*:
cd ~/looker
./looker restart
Tu instancia de Looker ya está configurada para la supervisión remota de JMX en el puerto 9910 con la contraseña que proporcionaste. Es posible que debas modificar la configuración del firewall o las LCA de la red para permitir que tu servidor de supervisión obtenga acceso a la red en este puerto.
Supervisión del host
Para cada host que ejecute la aplicación de Looker, te recomendamos que recopiles, grafiques y generes alertas sobre al menos las siguientes métricas de rendimiento:
- Uso de CPU: carga y porcentaje de CPU utilizado
- Uso de memoria: total utilizado y intercambio utilizado
- Uso del disco
Umbrales de alerta
Para establecer buenos umbrales de alerta, primero establece un modelo de referencia. Recopila datos de rendimiento con tu instancia de Looker que se ejecute con una carga normal. Observa los gráficos de rendimiento y los aumentos repentinos. El tiempo que necesitarás para establecer los modelos de referencia depende de tu empresa y tus patrones de uso de Looker. Algunas empresas pueden usar Looker en un patrón estable y repetible cada semana durante el horario de atención. Otras pueden usar Looker con más frecuencia en momentos específicos (como al final de cada mes).
En general, las alertas solo se deben enviar para eventos que son útiles. Enviar alertas cuando no es necesario hacer nada enmascara la importancia de las alertas críticas.
Los siguientes umbrales se pueden usar como punto de partida para las alertas. Si se superan los siguientes valores durante 15 minutos o más, es posible que se requiera una intervención manual.
Métrica | Con advertencias | Crítica | Comentarios |
---|---|---|---|
Carga de CPU | 2 | 4 | Por lo general, la carga debe ser de 1 o menos para un sistema de un solo núcleo. Una carga alta y constante genera un rendimiento deficiente. |
% de uso de CPU | 80 | 90 | El uso elevado de CPU genera un rendimiento deficiente. |
% de memoria utilizado | 60 | 70 | El alto uso de memoria puede indicar que se asignó demasiada memoria a Java. |
Porcentaje de disco usado | 80 | 90 | Asegúrate de que el disco no esté lleno. |
Notas adicionales:
- Los sistemas con más de un núcleo pueden manejar cargas altas de CPU sin reducir el rendimiento. La regla general es que la carga sostenida no debe ser mayor que la cantidad de núcleos del procesador.
- El porcentaje de tiempo de CPU total en uso antes de que un sistema experimente una degradación del rendimiento escala con la cantidad de núcleos de CPU en el sistema. En otras palabras, un sistema de núcleo único puede tener un rendimiento deficiente cuando se usa la CPU al 80%, mientras que un host de dieciséis núcleos se puede usar con una utilización del 95%.
- El alto uso de CPU sostenido se puede rectificar mediante la actualización del hardware del host o la actualización a una instancia más grande. A veces, pueden reducirse o ser más eficientes las grandes cantidades de vistas programadas o tablas derivadas de consultas largas para mejorar el rendimiento.
Próximos pasos
Después de configurar la supervisión, estará todo listo para configurar las copias de seguridad de Looker.