Monitorizar o Looker

Embora a monitorização de aplicações do Looker possa não parecer estritamente necessária, é muito importante configurá-la em instâncias alojadas pelo cliente. No caso raro de algo correr mal com o seu servidor, é muitas vezes muito mais difícil ou impossível para o Looker ajudar a corrigir o problema, a menos que possa fornecer informações de monitorização adequadas a partir do momento do incidente.

Monitorização de aplicações

URL

Existem duas formas simples de validar se a sua instância do Looker está em execução.

1. Acrescente /alive ao URL da instância do Looker da seguinte forma:

   https://instance_name.looker.com/alive

   Se a sua instância conseguir responder a um pedido Web, recebe um código de estado HTTP 200 OK.

2. Acrescente /availability ao URL da instância do Looker da seguinte forma:

   https://instance_name.looker.com/availability

   Este URL realiza uma verificação mais completa de vários subsistemas subjacentes e também responde com um código de estado HTTP 200 OK se tudo estiver bem.

JMX

A máquina virtual Java que executa o Looker pode ser monitorizada através do JMX.

Muitas aplicações de monitorização, como o Zabbix e o Nagios, suportam o JMX. Consulte a documentação da sua aplicação de monitorização para mais informações.

Edite o script de arranque do Looker

Para ativar a monitorização JMX, tem de editar o script de arranque do Looker. Por predefinição, tem o nome:

/home/looker/looker/looker

Procure os parâmetros de arranque 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 ficheiro JAR do Looker foi dividido em dois ficheiros JAR separados: o ficheiro JAR principal do Looker e um ficheiro JAR de dependências do Looker. Após o início, o ficheiro JAR principal inicia automaticamente o ficheiro JAR de dependências. Ambos os ficheiros JAR têm de estar no mesmo diretório para que o ficheiro JAR principal possa encontrar e iniciar com êxito o ficheiro JAR de dependências.

Por predefinição, a --no-daemonise opção de arranque não está definida. Se não tiver definido a opção --no-daemonise, adicione uma secçã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 tiver definido a --no-daemonise opção de arranque, adicione uma secçã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 base do utilizador do Looker e defina as autorizações:

sudo su - looker
mkdir ~/.lookerjmx
chmod 700 ~/.lookerjmx
cd ~/.lookerjmx

Crie os ficheiros JMX

Com o seu editor de texto favorito, crie um ficheiro no novo diretório com o nome jmxremote.access e o seguinte conteúdo (pode personalizar para o seu ambiente):

monitorRole   readonly
controlRole   readwrite \
              create javax.management.monitor.*,javax.management.timer.* \
              unregister

Em seguida, crie um ficheiro denominado jmxremote.password no mesmo diretório com o seguinte conteúdo, usando as suas próprias palavras-passe seguras:

monitorRole   some_password_here
controlRole   some_password_here

Definir autorizações

Faça com que o Java (e, por conseguinte, o Looker) não seja iniciado se as autorizações de ficheiros permitirem que qualquer pessoa exceto o utilizador do Looker leia o ficheiro de palavra-passe.

chmod 400 jmxremote.*

Reinicie o Looker

O Looker tem de ser reiniciado para ativar o JMX. Certifique-se de que executa este comando *como utilizador do Looker e não como raiz*:

cd ~/looker
./looker restart

A sua instância do Looker está agora configurada para monitorização JMX remota na porta 9910, através da palavra-passe que indicou. Pode ter de modificar as definições da firewall ou as ACLs de rede para permitir que o servidor de monitorização tenha acesso à rede nesta porta.

Monitorização do anfitrião

Para cada anfitrião que execute a aplicação Looker, recomendamos que recolha, represente graficamente e emita alertas sobre, pelo menos, as seguintes métricas de desempenho:

• Utilização da CPU: carga e percentagem da CPU utilizada
• Utilização da memória: total usado e troca usada
• Utilização do disco

Limites de alerta

Para estabelecer bons limites de alerta, comece por estabelecer uma base de referência. Recolha dados de desempenho com a sua instância do Looker em execução sob uma carga normal. Consulte os gráficos de desempenho e observe os picos. O tempo necessário para estabelecer as linhas de base depende da sua empresa e dos seus padrões de utilização do Looker. Algumas empresas podem usar o Looker num padrão estável e repetível todas as semanas durante o horário de funcionamento. Outras pessoas podem usar o Looker com mais frequência em alturas específicas (como no final de cada mês).

Em geral, os alertas só devem ser enviados para eventos acionáveis. O envio de alertas quando não existe nada que precise de ser feito oculta a importância dos alertas críticos.

Os seguintes limites podem ser usados como ponto de partida para alertas. Quando os seguintes valores são excedidos durante 15 minutos ou mais, pode ser necessária uma intervenção manual.

Notas adicionais:

• Os sistemas com mais de um núcleo podem processar cargas elevadas da CPU sem reduzir o desempenho. A regra geral é que a carga sustentada não deve ser superior ao número de núcleos do processador.
• A percentagem do tempo total da CPU em utilização antes de um sistema sofrer uma degradação do desempenho varia consoante o número de núcleos da CPU no sistema. Por outras palavras, um sistema de núcleo único pode ter um desempenho fraco quando a CPU é utilizada a 80%, enquanto um anfitrião de dezasseis núcleos ainda pode ser utilizável a 95% de utilização.
• A utilização elevada e sustentada da CPU pode ser retificada atualizando o hardware do anfitrião ou fazendo uma atualização para uma instância maior. Por vezes, é possível reduzir ou tornar mais eficientes grandes números de Looks agendados ou tabelas derivadas de consultas longas para melhorar o desempenho.

Passos seguintes

Depois de configurar a monitorização, tem tudo pronto para configurar as cópias de segurança do Looker.