Você está vendo a documentação do Looker 22.16. A documentação mais recente está disponível aqui.

Como monitorar o Looker

O monitoramento de aplicativos do Looker pode não ser estritamente necessário, mas é muito importante configurá-lo. No caso raro de algo der errado com seu servidor, geralmente é muito mais difícil ou impossível que o Looker ajude você a corrigir o problema, a menos que você possa fornecer informações de monitoramento adequadas no momento do incidente.

Monitoramento de aplicativos

URL

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

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

https://instance_name.looker.com/alive

Se a 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 desta maneira:

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

JMX (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 seu aplicativo de monitoramento para mais informações.

Editar o script de inicialização do Looker

Para ativar o monitoramento do JMX, é necessário editar o script de inicialização do Looker. Por padrão, ele é nomeado:

/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 encontrar 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 após 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ê definiu 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 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

Faça com que o Java (e 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

É necessário reiniciar o Looker para ativar o JMX. Execute o comando *como o usuário do Looker, e não a raiz*:

cd ~/looker
./looker restart

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

Monitoramento do host

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

Utilização da CPU: carga e percentual de CPU usada
Utilização de memória: uso total e troca usada
Uso do disco

Limites de alertas

Para estabelecer bons limites de alertas, defina um valor de referência. Colete dados de desempenho com sua instância do Looker em execução com uma carga normal. Observe os 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 seus padrões de uso do Looker. Algumas empresas podem usar o Looker em um padrão estável e repetível toda semana durante o horário comercial. Outros podem usar o Looker com mais intensidade em momentos específicos, como no final de cada mês.

De modo geral, os alertas só devem ser enviados para eventos acionáveis. Enviar alertas quando não há nada que precise ser feito mascara 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 forem excedidos por 15 minutos ou mais, poderá ser necessária uma intervenção manual.

Métrica	Alerta	Crítica	Comentários
Carga da CPU	2	4	Geralmente, a carga deve ser 1 ou menos para um sistema de um núcleo. Uma carga alta sustentada diminui o desempenho.
% de CPU usada	80	90	O alto uso da CPU resulta em baixo desempenho.
% de memória usada	60	70	O alto uso da memória pode indicar que a quantidade de memória é alocada para o Java.
% de disco usado	80	90	Certifique-se de que o disco não está cheio.

Observações adicionais:

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

Próximas etapas

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