Você está visualizando a documentação do Looker. Para conferir a documentação do Looker Studio, acesse https://support.google.com/looker-studio.

Como monitorar o Looker

Embora o monitoramento de aplicativos do Looker possa não parecer obrigatório, é muito importante configurá-lo. No caso raro de algo der errado com seu servidor, geralmente é muito mais difícil ou impossível para o Looker ajudar você a corrigir o problema, a menos que você forneça as informações de monitoramento apropriadas no momento do incidente.

Monitoramento de aplicativos

URL

Há duas maneiras simples de validar se sua instância do Looker está em execução.

Anexe /alive ao URL da instância do Looker assim:

https://instance_name.looker.com/alive

Se sua instância puder responder a uma solicitação da web, você receberá um código de status HTTP 200 OK.
Anexe /availability ao URL da instância do Looker assim:

https://instance_name.looker.com/availability

Esse URL realiza uma verificação mais completa de vários subsistemas subjacentes e também responde com um código de status HTTP 200 OK, se tudo estiver bem.

JMX

A máquina virtual Java que executa o Looker pode ser monitorada via JMX.

Muitos aplicativos de monitoramento, como Zabbix e Nagios, são compatíveis com JMX. Consulte a documentação do aplicativo de monitoramento para mais informações.

Editar o script de inicialização do Looker

Para ativar o monitoramento do JMX, edite seu script de inicialização do Looker. Por padrão, o nome dele é:

/home/looker/looker/looker

Procure os parâmetros de inicialização do 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 do Looker 6.18, o arquivo JAR do Looker foi dividido em dois arquivos JAR separados: o arquivo JAR principal do Looker e um arquivo JAR de dependências do Looker. Ao iniciar, o arquivo JAR principal iniciará automaticamente o arquivo JAR de dependências. Os dois arquivos JAR precisam estar no mesmo diretório para que o arquivo JAR principal possa localizar e iniciar o arquivo JAR de dependências.

Por padrão, a opção de inicialização --no-daemonise não está definida. Se você não definiu a opção --no-daemonise, adicione uma seção seguindo a linha que começa com -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 \

Se você tiver definido a opção de inicialização --no-daemonise, adicione uma seção seguindo a linha que começa com -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 \

Crie o diretório `.lookerjmx`

Em seguida, crie o diretório .lookerjmx no diretório inicial do usuário do Looker e defina as permissões:

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

Criar os arquivos JMX

Usando seu editor de texto favorito, crie um arquivo no novo diretório chamado jmxremote.access com o seguinte conteúdo (você pode personalizar para seu ambiente):

monitorRole   readonly
controlRole   readwrite \
              create javax.management.monitor.*,javax.management.timer.* \
              unregister

Em seguida, crie um arquivo chamado jmxremote.password no mesmo diretório com o seguinte conteúdo, usando suas próprias senhas seguras:

monitorRole   some_password_here
controlRole   some_password_here

Como definir permissões

Garanta que o Java (e, portanto, o Looker) não seja iniciado se as permissões do arquivo permitirem que qualquer pessoa exceto o usuário do Looker leia o arquivo da senha.

chmod 400 jmxremote.*

Reiniciar o Looker

O Looker precisa ser reiniciado para ativar o JMX. Execute isto *como usuário do Looker, não raiz*:

cd ~/looker
./looker restart

Sua instância do Looker agora está configurada para monitoramento remoto do JMX na porta 9910 usando a senha que você forneceu. Talvez seja necessário modificar as configurações de firewall ou as ACLs de rede para permitir que seu servidor de monitoramento tenha acesso à rede nessa porta.

Monitoramento de hosts

Para cada host que executa o aplicativo Looker, recomendamos que você colete, crie gráficos e alerte pelo menos as seguintes métricas de desempenho:

CPU Utilization:carga e porcentagem de uso da CPU
Uso de memória: total usado e troca usada
Uso do disco

Limites de alertas

Para estabelecer bons limites de alerta, primeiro estabeleça uma linha de base. Colete dados de desempenho com sua instância do Looker em execução com uma carga normal. Dê uma olhada nos gráficos de desempenho e observe os picos. O tempo necessário para estabelecer os valores de referência depende dos seus negócios e dos padrões de uso do Looker. Algumas empresas podem usar o Looker em um padrão estável e repetível todas as semanas durante o horário comercial. Outras podem usar o Looker com mais frequência em momentos específicos, como no final de cada mês.

Em geral, os alertas só devem ser enviados para eventos acionáveis. O envio de alertas quando não há nada que precisa ser feito oculta a importância dos alertas críticos.

Os limites a seguir podem ser usados como ponto de partida para alertas. Quando os valores a seguir são excedidos em 15 minutos ou mais, pode ser necessária uma intervenção manual.

Métrica	Alerta	Crítica	Comentários
Carga da CPU	2	4	Geralmente, a carga deve ser de 1 ou menos para um sistema de núcleo único. A alta carga sustentada prejudica o desempenho.
% de CPU usada	80	90	O alto uso de CPU leva a um desempenho insatisfatório.
% de memória usada	60	70	O alto uso de memória pode indicar quanta memória há alocada no Java.
Porcentagem usada do disco	80	90	Verifique se o disco não está cheio.

Observações adicionais:

Sistemas com mais de um núcleo podem lidar com altas cargas de CPU sem desempenho reduzido. A regra de ouro é que a carga sustentada não deve ser maior que o número de núcleos de processador.
O percentual do tempo total de CPU em uso antes que o sistema apresente degradação de desempenho é escalonado com o número de núcleos de CPU no sistema. Em outras palavras, um sistema de núcleo único pode ter um desempenho ruim quando a CPU é 80% utilizada, enquanto um host de 16 núcleos ainda pode ser usado com 95% de utilização.
A alta utilização de CPU sustentada pode ser retificada atualizando o hardware do host ou fazendo upgrade para uma instância maior. Às vezes, um grande número de visualizações programadas ou de tabelas derivadas de consulta longa pode ser reduzido ou mais eficiente para melhorar o desempenho.

Próximas etapas

Depois de configurar o monitoramento, você estará pronto para configurar backups do Looker.