Ten en cuenta que estás viendo la documentación de Looker. Para obtener documentación de Looker Studio, visita https://support.google.com/looker-studio.

Supervisión de Looker

Aunque la supervisión de la aplicación de Looker puede no parecer obligatoria, es muy importante su configuración. En el caso poco frecuente de que se produzca un error en tu servidor, a menudo es mucho más difícil o imposible que Looker te ayude a solucionar el problema, a menos que puedas proporcionar información de supervisión adecuada desde el momento en que ocurrió el incidente.

Supervisión de la aplicación

URL

Existen dos maneras sencillas de validar que tu instancia de Looker está en ejecución.

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 verificación más completa de varios subsistemas subyacentes y, además, responderá con un código de estado HTTP 200 OK si todo está bien.

JMX

La máquina virtual de 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, debes editar tu 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}

A partir de Looker 6.18, el archivo JAR de Looker se dividió en dos archivos JAR independientes: el archivo JAR principal de Looker y un archivo JAR de dependencias de Looker. Cuando se inicie, 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 buscar y comenzar correctamente el archivo JAR de dependencias.

De forma predeterminada, la opción de inicio --no-daemonise no está configurada. Si no configuraste la opción --no-daemonise, agrega una sección que siga 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 que siga 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, lea el archivo de contraseña.

chmod 400 jmxremote.*

Reinicia 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

Se configuró tu instancia de Looker para la supervisión remota de JMX en el puerto 9910 con la contraseña que proporcionaste. Es posible que deba modificar la configuración de su firewall o de las LCA de la red para permitir que el servidor de supervisión obtenga acceso a la red en este puerto.

Supervisión del organizador

Para cada host que ejecute la aplicación de Looker, le recomendamos que recopile, genere gráficos y genere alertas en, al menos, las siguientes métricas de rendimiento:

Uso de CPU: carga y porcentaje de uso de CPU
Uso de memoria: total utilizado y de intercambio
Uso del disco

Umbrales de alerta

Para establecer buenos umbrales de alertas, primero establezca un modelo de referencia. Recopila datos de rendimiento con tu instancia de Looker ejecutándose bajo una carga normal. Observe los gráficos de rendimiento y observe los aumentos repentinos. 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 de forma estable y repetible todas las semanas durante el horario de atención. Otros pueden usar Looker de manera más intensiva en momentos específicos (como al final de cada mes).

En general, las alertas solo se deben enviar para eventos que se puedan procesar. El envío de alertas cuando no hay nada que hacer oculta la importancia de las alertas críticas.

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

Métrica	Advertencia	Crítica	Comentarios
Carga de CPU	2	4	Por lo general, la carga debe ser 1 o menos para un sistema de un núcleo. La sostenibilidad de la carga alta genera un rendimiento deficiente.
Porcentaje de CPU utilizado	80	90	El uso elevado de CPU genera un rendimiento deficiente.
Porcentaje de memoria utilizado	60	70	El uso elevado de memoria puede indicar que se asigna 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 controlar cargas de CPU altas 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 de CPU total en uso antes de que un sistema experimente escalamientos de degradación del rendimiento 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 la CPU tiene un 80% de uso, mientras que un host de núcleo de dieciséis pueden seguir utilizándose con un 95% de uso.
Para corregir el uso elevado de CPU, se puede actualizar el hardware del host o actualizar a una instancia más grande. A veces, se puede reducir o hacer más eficiente una gran cantidad de apariencias programadas o tablas derivadas de consultas largas para mejorar el rendimiento.

Próximos pasos

Después de configurar la supervisión, estarás listo para configurar las copias de seguridad de Looker.