Esta é a documentação do Looker. Para acessar a documentação do Looker Studio, acesse https://support.google.com/looker-studio.

Como monitorar o Looker

O monitoramento de aplicativos Looker pode não parecer obrigatório, mas é muito importante configurá-lo em instâncias hospedadas pelo cliente. No caso raro de algo dar errado com seu servidor, muitas vezes é muito mais difícil ou impossível para o Looker ajudar você a corrigir o problema, a menos que você forneça informações de monitoramento adequadas a partir do 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 da seguinte forma:

https://instance_name.looker.com/alive

Se a instância 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 forma:

https://instance_name.looker.com/availability

Esse URL executa 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

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

Muitos aplicativos de monitoramento, como Zabbix e Nagios, oferecem suporte ao 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, é 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}

No Looker 6.18 e versões mais recentes, 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 é 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 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

Faça com 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 de senha.

chmod 400 jmxremote.*

Reiniciar o Looker

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

cd ~/looker
./looker restart

Sua instância do Looker agora está configurada para monitoramento remoto do JMX na porta 9910 com a senha que você forneceu. Talvez seja necessário modificar as configurações de 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 coletar, criar gráficos e alertar sobre pelo menos as seguintes métricas de desempenho:

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

Limites de alertas

Para estabelecer bons limites de alertas, primeiro defina um valor de referência. Colete dados de desempenho com sua instância do Looker em execução sob 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 da sua empresa e dos seus padrões de uso do Looker. Algumas empresas usam o Looker em um padrão estável e repetível todas as semanas durante o horário comercial. Outras podem usar mais o Looker em momentos específicos, como no fim de cada mês.

Em geral, os alertas devem ser enviados somente para eventos acionáveis. O envio de alertas quando não há nada que precisa 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	Aviso	Crítica	Comentários
Carga da CPU	2	4	A carga geralmente precisa ser de 1 ou menos para um sistema de núcleo único. Uma carga alta sustentada leva a um desempenho ruim.
% de CPU usada	80	90	O uso elevado da CPU leva a um desempenho ruim.
% de memória usada	60	70	O uso elevado da memória pode indicar que há muita memória alocada para o Java.
Porcentagem do disco usada	80	90	Verifique se o disco não está cheio.

Outras observações:

Sistemas com mais de um núcleo podem lidar com altas cargas de CPU sem redução de desempenho. A regra prática é que a carga sustentada não pode ser maior que o número de núcleos de processador.
A porcentagem do tempo total de CPU em uso antes que o sistema sofre degradação do desempenho aumenta 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 é usada em 80%, enquanto um host com 16 núcleos ainda pode ser usado com 95% de uso.
A alta utilização sustentada da CPU pode ser retificada com a atualização do hardware do host ou com o upgrade para uma instância maior. Às vezes, para melhorar a performance, é possível reduzir ou aumentar a eficiência de um grande número de Looks programados ou de tabelas derivadas de consultas longas.

Próximas etapas

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