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

Esta página foi traduzida pela API Cloud Translation.

Looker de monitoramento

Embora o monitoramento do aplicativo do Looker não pareça ser estritamente necessário, é muito importante configurá-lo em instâncias hospedadas pelo cliente. Em casos raros, se algo der errado com seu servidor, o Looker pode ter dificuldade ou não conseguir ajudar a corrigir o problema, a menos que você forneça informações de monitoramento adequadas do 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 da seguinte maneira:

https://instance_name.looker.com/alive

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

https://instance_name.looker.com/availability

Esse URL realiza uma verificação mais completa de vários subsistemas 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 pelo JMX.

Muitos aplicativos de monitoramento, como o Zabbix e o Nagios, oferecem suporte a 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, edite o script de inicialização do Looker. Por padrão, ele é chamado de:

/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 inicia 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 do --no-daemonise não está definida. Se você não tiver definido 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ê tiver definido a opção de inicialização --no-daemonise, adicione uma seção após 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 principal 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

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

chmod 400 jmxremote.*

Reiniciar o Looker

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

cd ~/looker
./looker restart

A instância do Looker agora está configurada para monitoramento JMX remoto 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 do Looker, recomendamos que você colete, gere gráficos e emita alertas com base pelo menos nas seguintes métricas de performance:

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

Limites de alerta

Para estabelecer bons limites de alerta, primeiro estabeleça um valor de referência. Colete dados de performance com a instância do Looker em execução sob uma carga normal. Analise os gráficos de desempenho e observe os picos. O tempo necessário para estabelecer as bases de referência depende da sua empresa e dos padrões de uso do Looker. Algumas empresas podem usar o Looker de forma estável e repetível toda semana durante o horário comercial. Outros 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 que podem ser usados. Enviar alertas quando não há nada a 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 são excedidos por 15 minutos ou mais, pode ser necessária uma intervenção manual.

Métrica	Aviso	Crítico	Comentários
Carga da CPU	2	4	A carga geralmente precisa ser 1 ou menos para um sistema de núcleo único. A carga alta contínua resulta em um desempenho ruim.
% de CPU usada	80	90	O uso elevado da CPU resulta em um desempenho ruim.
% de memória usada	60	70	O uso de muita memória pode indicar que muita memória está alocada para Java.
Disco (%) usado	80	90	Verifique se o disco não está cheio.

Observações adicionais:

Sistemas com mais de um núcleo podem lidar com cargas de CPU altas sem redução de desempenho. A regra geral é que a carga sustentada não deve ser maior que o número de núcleos do processador.
A porcentagem do tempo total de CPU em uso antes que um sistema apresente degradação de desempenho varia de acordo 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 está 80% utilizada, enquanto um host de 16 núcleos ainda pode ser usado com 95% de utilização.
A alta utilização sustentada da CPU pode ser corrigida atualizando o hardware do 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 tornar-se mais eficiente para melhorar o desempenho.

Próximas etapas

Depois de configurar o monitoramento, você pode configurar backups do Looker.