Looker de Monitoring

Si bien es posible que el monitoreo de la aplicación de Looker no parezca estrictamente necesario, es muy importante configurarlo en instancias alojadas por el cliente. En el caso poco probable 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.

1. 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.

2. 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 también responderá con un código de estado HTTP 200 OK si todo está bien.

JMX

Es posible que la máquina virtual de Java que ejecuta Looker se supervise 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. De forma predeterminada su nombre es:

/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. Después del inicio, 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 y, luego, iniciar correctamente el archivo JAR de dependencias.

De forma predeterminada, no se establece la opción de inicio --no-daemonise. Si no configuraste 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 de --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

Luego, crea el directorio .lookerjmx en el directorio principal de tu 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 y usa tus propias contraseñas seguras:

monitorRole   some_password_here
controlRole   some_password_here

Configura los permisos

Haz que Java (y, por lo tanto, Looker) no se inicie si los permisos de archivo permiten que cualquier persona excepto el usuario de Looker lea el archivo de contraseña.

chmod 400 jmxremote.*

Reiniciar Looker

Looker debe reiniciarse para habilitar JMX. Asegúrate de ejecutarlo *como usuario de Looker y no como raíz*:

cd ~/looker
./looker restart

Tu instancia de Looker ahora 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 de host

Para cada host que ejecute la aplicación de Looker, te recomendamos que recopiles, crees gráficos y generes alertas sobre, al menos, las siguientes métricas de rendimiento:

• Uso de CPU: carga y porcentaje de CPU utilizado
• Uso de memoria: Uso total 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 ejecutándose en una carga normal. Observa los gráficos de rendimiento y los picos. El tiempo que necesitarás para establecer los modelos de referencia dependerá de tu empresa y tus patrones de uso de Looker. Algunas empresas pueden usar Looker en un patrón estable y repetible todas las semanas durante el horario de atención. Otros pueden usar Looker con mayor frecuencia en momentos específicos (como al final de cada mes).

En general, las alertas solo se deben enviar para los eventos sobre los que se pueden realizar acciones. Enviar alertas cuando no hay nada que hacer enmascara la importancia de las alertas críticas.

Se pueden usar los siguientes umbrales como punto de partida para las alertas. Cuando se superan los siguientes valores durante 15 minutos o más, es posible que se requiera una intervención manual.

Notas adicionales:

• Los sistemas con más de un núcleo pueden manejar cargas de CPU elevadas sin disminuir el rendimiento. La regla general es que la carga sostenida no debe ser mayor que la cantidad de núcleos del procesador.
• El porcentaje del tiempo total de CPU en uso antes de que un sistema experimente una degradación del rendimiento se escala con la cantidad de núcleos de CPU en el sistema. En otras palabras, un sistema de un solo núcleo puede tener un rendimiento deficiente cuando se usa la CPU al 80%, mientras que un host de dieciséis núcleos aún puede usarse con un 95% de uso.
• Para corregir el alto uso sostenido de la CPU, actualiza el hardware del host o cambia a una instancia más grande. A veces, se pueden reducir grandes cantidades de vistas programadas o tablas derivadas de consultas largas, o bien aumentar la eficiencia 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.