Esta página se ha traducido con Cloud Translation API.

Monitoring Looker

Aunque la monitorización de la aplicación Looker no parezca estrictamente necesaria, es muy importante configurarla en las instancias alojadas por el cliente. En el caso poco probable de que algo vaya mal en tu servidor, a Looker le resultará mucho más difícil o imposible ayudarte a solucionar el problema a menos que puedas proporcionar la información de monitorización adecuada desde el momento del incidente.

Monitorización de aplicaciones

URL

Hay dos formas sencillas de comprobar que tu instancia de Looker está en funcionamiento.

Añade /alive a la URL de tu instancia de Looker de esta forma:

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.
Añade /availability a la URL de tu instancia de Looker de esta forma:

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 va bien.

JMX

La máquina virtual Java que ejecuta Looker se puede monitorizar mediante JMX.

Muchas aplicaciones de monitorización, como Zabbix y Nagios, admiten JMX. Para obtener más información, consulte la documentación de su aplicación de monitorización.

Editar la secuencia de comandos de inicio de Looker

Para habilitar la monitorización de JMX, tendrás que editar la secuencia de comandos de inicio de Looker. De forma predeterminada, se llama:

/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}

Desde Looker 6.18, el archivo JAR de Looker se ha dividido en dos archivos JAR independientes: el archivo JAR principal de Looker y el 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 --no-daemonise opción de inicio no está definida. Si no ha definido la opción --no-daemonise, añada una sección después de la línea que empieza por -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 has definido la --no-daemonise opción de inicio, añade una sección después de la línea que empieza por -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 de tu usuario de Looker y define los permisos:

sudo su - looker
mkdir ~/.lookerjmx
chmod 700 ~/.lookerjmx
cd ~/.lookerjmx

Crear los archivos JMX

Con el editor de texto que prefieras, crea un archivo en el nuevo directorio 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. Utiliza tus propias contraseñas seguras:

monitorRole   some_password_here
controlRole   some_password_here

Cómo configurar permisos

De esta forma, Java (y, por lo tanto, Looker) no se iniciará si los permisos del archivo permiten que cualquier usuario excepto el usuario de Looker lea el archivo de contraseñas.

chmod 400 jmxremote.*

Reiniciar Looker

Es necesario reiniciar Looker para habilitar JMX. Asegúrate de ejecutar este comando *como usuario de Looker y no como usuario raíz*:

cd ~/looker
./looker restart

Tu instancia de Looker ya está configurada para la monitorización remota de JMX en el puerto 9910 con la contraseña que has proporcionado. Es posible que tengas que modificar la configuración del cortafuegos o las ACLs de red para permitir que tu servidor de monitorización obtenga acceso a la red en este puerto.

Monitorización de hosts

En cada host que ejecute la aplicación Looker, le recomendamos que recoja, represente gráficamente y cree alertas sobre al menos las siguientes métricas de rendimiento:

Uso de CPU: carga y porcentaje de CPU utilizada.
Uso de memoria: memoria total usada y memoria de intercambio usada
Uso del disco

Umbrales de alerta

Para establecer umbrales de alerta adecuados, primero debes definir un valor de referencia. Recoge datos de rendimiento con tu instancia de Looker funcionando con una carga normal. Echa un vistazo a los gráficos de rendimiento y observa los picos. El tiempo que necesites para establecer las líneas de base dependerá de tu empresa y de tus patrones de uso de Looker. Algunas empresas pueden usar Looker de forma estable y repetible cada semana durante el horario de trabajo. Otros pueden usar Looker con más frecuencia en momentos concretos (por ejemplo, a final de mes).

Por lo general, las alertas solo deben enviarse para eventos en los que se puedan tomar medidas. Si se envían alertas cuando no hay nada que hacer, se oculta 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	Advertencia	Crítica	Comentarios
Carga de CPU	2	4	La carga suele ser de 1 o menos en los sistemas de un solo núcleo. Una carga alta y sostenida provoca un rendimiento deficiente.
CPU % usada	80	90	Un uso elevado de la CPU provoca un rendimiento deficiente.
% de memoria usada	60	70	Un uso elevado de la memoria puede indicar que se ha asignado demasiada memoria a Java.
% 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 gestionar cargas elevadas de CPU sin que se reduzca el rendimiento. Por lo general, la carga sostenida no debe ser superior al número de núcleos del procesador.
El porcentaje del tiempo total de CPU en uso antes de que el sistema experimente una degradación del rendimiento se escala en función del número de núcleos de CPU del sistema. Es decir, un sistema de un solo núcleo puede tener un rendimiento deficiente cuando la CPU se utiliza al 80 %, mientras que un host de 16 núcleos puede seguir siendo utilizable al 95 %.
El uso de CPU alto y sostenido se puede corregir actualizando el hardware del host o cambiando a una instancia más grande. A veces, se pueden reducir o hacer más eficientes grandes cantidades de Looks programados o tablas derivadas de consultas largas para mejorar el rendimiento.

Pasos siguientes

Una vez que hayas configurado la monitorización, podrás configurar copias de seguridad de Looker.

Monitoring Looker Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.