Embora o monitoramento de aplicativos Looker possa não parecer estritamente necessário, é muito importante configurá-lo em instâncias hospedadas pelo cliente. Nos raros casos em que algo dá errado com o servidor, costuma ser muito mais difícil ou impossível para o Looker ajudar você a corrigir o problema, a menos que você possa fornecer as 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
/aliveao URL da instância do Looker desta forma:https://instance_name.looker.com/aliveSe sua instância for capaz de responder a uma solicitação da Web, você receberá um código de status HTTP 200 OK.
Anexe
/availabilityao URL da instância do Looker desta forma:https://instance_name.looker.com/availabilityEsse 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 via JMX.
Muitos aplicativos de monitoramento, como o Zabbix e o Nagios, oferecem suporte a 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 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. 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 --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ê definiu 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
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 sejam iniciados 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 *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 Looker, recomendamos coletar, criar gráficos e alertar sobre pelo menos as seguintes métricas de desempenho:
- 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 que você vai precisar para estabelecer os valores 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 usam o Looker com mais frequência em momentos específicos, como no fim de cada mês.
Em geral, os alertas só devem ser enviados para eventos acionáveis. Enviar 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 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. Uma carga alta sustentada leva a um desempenho ruim. |
| % de CPU usada | 80 | 90 | O uso elevado da CPU gera um desempenho ruim. |
| % de memória usada | 60 | 70 | O alto uso de memória pode indicar que muita memória está alocada para Java. |
| Porcentagem do disco usada | 80 | 90 | Verifique se o disco não está cheio. |
Observações adicionais:
- Sistemas com mais de um núcleo conseguem lidar com cargas altas de CPU sem redução de desempenho. Como regra geral, a carga sustentada não pode ser maior do que o número de núcleos de processador.
- A porcentagem do tempo total de CPU em uso antes da degradação do desempenho do sistema aumenta 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 Looks programados ou tabelas derivadas de consultas longas pode ser reduzido ou tornado mais eficiente para melhorar a performance.
Próximas etapas
Depois de configurar o monitoramento, você pode configurar backups do Looker.