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.