Esta página aborda práticas comuns para componentes específicos da arquitetura do Looker e descreve como fazer a configuração deles em uma implantação.
O Looker tem várias dependências para hospedar o servidor, atender cargas de trabalho ad hoc e programadas, acompanhar o desenvolvimento de modelos iterativos ou algo semelhante. Essas dependências são chamadas de componentes nesta página, e cada componente é abordado em detalhes nas seções a seguir:
- Configuração do host
- Configuração da JVM
- Opções de inicialização do Looker
- Banco de dados interno (back-end)
- Serviço do Git
- Rede
Configuração do host
SO e distribuição
O Looker funciona bem nas versões mais comuns do Linux: RedHat, SUSE e Debian/Ubuntu. Derivados dessas distribuições que são projetados e otimizados para execução em um ambiente específico geralmente são adequados. Por exemplo, as distribuições Google Cloud ou AWS do Linux são compatíveis com o Looker. O Debian/Ubuntu é a variedade de Linux mais usada na comunidade do Looker, e estas são as versões mais conhecidas do suporte do Looker. É mais fácil usar o Debian/Ubuntu ou um sistema operacional para um provedor de nuvem específico derivado do Debian/Ubuntu.
O Looker é executado na máquina virtual Java (JVM). Ao escolher uma distribuição, considere se as versões do OpenJDK 11 estão atualizadas. É possível que distribuições mais antigas do Linux consigam executar o Looker, mas a versão e as bibliotecas do Java necessárias para recursos específicos precisam estar atualizadas. Se a JVM não tiver todas as bibliotecas e versões recomendadas do Looker, ele não vai funcionar normalmente. O Looker requer o Java HotSpot 1.8 atualização 161 ou mais recente ou o Java OpenJDK 11.0.12 ou mais recente.
CPU e memória
Quatro nós de 16 (quatro CPUs e 16 GB de RAM) são suficientes para um sistema de desenvolvimento ou uma instância de teste básica do Looker usada por uma pequena equipe. No entanto, para uso em produção, isso geralmente não é suficiente. Na nossa experiência, nós descobrimos que 16x64 nós (16 CPUs e 64 GB de RAM) são um bom equilíbrio entre preço e desempenho. Mais de 64 GB de RAM podem afetar o desempenho, já que os eventos de coleta de lixo têm uma única linha de execução e interrompem todas as outras linhas de execução para serem executadas.
Armazenamento em disco
100 GB de espaço em disco geralmente é mais do que suficiente para um sistema de produção.
Considerações sobre clusters
O Looker é executado em uma JVM Java, e o Java pode ter dificuldade para gerenciar memórias maiores que 64 GB. Como regra geral, se for necessário mais capacidade, adicione outros nós de 16 x 64 ao cluster em vez de aumentar o tamanho dos nós além de 16 x 64. Também podemos preferir usar uma arquitetura em cluster para aumentar a disponibilidade.
Em um cluster, os nós do Looker precisam compartilhar determinadas partes do sistema de arquivos. Os dados compartilhados incluem o seguinte:
- Modelos do LookML
- Os modelos de LookML do desenvolvedor
- Conectividade do servidor do Git
Como o sistema de arquivos é compartilhado e hospeda vários repositórios do Git, o processamento de acesso simultâneo e travamento de arquivos é essencial. O sistema de arquivos precisa ser compatível com POSIX. O sistema de arquivos de rede (NFS) funciona e está disponível no Linux. Crie outra instância do Linux e configure o NFS para compartilhar o disco. O NFS padrão é potencialmente um ponto único de falha. Portanto, considere uma configuração de failover ou de alta disponibilidade.
Os metadados do Looker também precisam ser centralizados, então o banco de dados interno precisa ser migrado para o MySQL. Pode ser um serviço MySQL ou uma implantação MySQL dedicada. A seção Banco de dados interno (back-end) desta página contém mais detalhes.
Configuração da JVM
As configurações da JVM do Looker são definidas no script de inicialização do Looker. Depois de qualquer atualização, o Looker precisa ser reiniciado para que as mudanças sejam manifestadas. As configurações padrão são as seguintes:
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}
Recursos
As configurações de recursos são definidas no script de inicialização do Looker.
JAVAMEM="2300m" METAMEM="800m"
A alocação de memória para a JVM precisa considerar a sobrecarga do sistema operacional em que o Looker está sendo executado. A regra geral é que a JVM pode ser alocada em até 60% da memória total, mas há ressalvas dependendo do tamanho da máquina. Para máquinas com o mínimo de 8 GB de memória total, recomendamos uma alocação de 4 a 5 GB para Java e 800 MB para Meta. Para máquinas maiores, uma proporção menor de memória pode ser alocada para o sistema operacional. Por exemplo, para máquinas com 60 GB de memória total, recomendamos uma alocação de 36 GB para Java e 1 GB para Meta. É importante observar que a alocação de memória do Java normalmente é dimensionada com a memória total da máquina, mas o Meta deve ser suficiente com 1 GB.
Além disso, como o Looker compartilha recursos do sistema com outros processos, como o Chromium para renderização, a quantidade de memória alocada para Java precisa ser selecionada no contexto da carga de renderização esperada e do tamanho da máquina. Se a carga de renderização for baixa, o Java poderá receber uma parcela maior da memória total. Por exemplo, em uma máquina com 60 GB de memória total, o Java pode ser alocado com segurança em 46 GB, o que é maior do que a recomendação geral de 60%. As alocações de recursos exatas adequadas para cada implantação variam. Portanto, use 60% como valor de referência e ajuste conforme o uso.
Coleta de lixo
O Looker prefere usar o coletor de lixo mais moderno disponível para a versão Java. Por padrão, o tempo limite da coleta de lixo é de dois segundos, mas isso pode ser alterado editando a seguinte opção na configuração de inicialização:
-XX:MaxGCPauseMillis=2000
Em uma máquina maior com vários núcleos, o tempo limite de coleta de lixo pode ser reduzido.
Registros
Por padrão, os registros de coleta de lixo do Looker são armazenados em /tmp/gc.log. Para mudar isso, edite a seguinte opção na configuração de inicialização:
-Xloggc:/tmp/gc.log
JMX
O gerenciamento do Looker pode precisar de monitoramento para ajudar a refinar os recursos. Recomendamos o uso do JMX para monitorar o uso da memória da JVM.
Opções de inicialização do Looker
As opções de inicialização são armazenadas em um arquivo chamado lookerstart.cfg. Esse arquivo é gerado no script de shell que inicia o Looker.
Pools de linhas de execução
Como um aplicativo multithread, o Looker tem vários pools de threads. Esses pools de linhas de execução variam do servidor da Web principal a subserviços especializados, como programação, renderização e conexões de banco de dados externas. Dependendo dos fluxos de trabalho da sua empresa, talvez seja necessário modificar esses pools na configuração padrão. Há considerações especiais para as topologias de cluster mencionadas na página Práticas e padrões de arquitetura de infraestrutura hospedada pelo cliente.
Opções de alta capacidade de programação
Para todos os nós que não são de programação, adicione --scheduler-threads=0 à variável de ambiente LOOKERARGS em lookerstart.cfg. Sem as linhas de execução do programador, nenhum job programado será executado nesses nós.
Para todos os nós do programador dedicado, adicione --scheduler-threads=<n> à variável de ambiente LOOKERARGS em lookerstart.cfg. O Looker começa com 10 linhas de execução do programador por padrão, mas esse número pode ser aumentado para <n>. Com <n> linhas de execução do programador, cada nó poderá executar <n> trabalhos de programação simultâneos. Em geral, é recomendável manter <n> menor que o dobro do número de CPUs. O host recomendado maior é aquele com 16 CPUs e 64 GB de memória. Portanto, o limite máximo de linhas de execução do agendador precisa ser menor que 32.
Opções de alta capacidade de processamento de renderização
Para todos os nós que não são de renderização, adicione --concurrent-render-jobs=0 à variável de ambiente LOOKERARGS em lookerstart.cfg. Sem nós de renderização, nenhum job de renderização será executado nesses nós.
Para todos os nós de renderização dedicados, adicione --concurrent-render-jobs=<n> à variável de ambiente LOOKERARGS em lookerstart.cfg. O Looker começa com duas linhas de renderização por padrão, mas isso pode ser aumentado para <n>. Com <n> linhas de renderização, cada nó poderá executar <n> jobs de renderização simultâneos.
Cada job de renderização pode usar uma quantidade significativa de memória. Reserve cerca de 2 GB por job de renderização. Por exemplo, se o processo principal do Looker (Java) receber 60% da memória total e 20% da memória restante forem reservados para o sistema operacional, os últimos 20% serão usados para renderizações. Em uma máquina de 64 GB, isso deixa 12 GB, o que é suficiente para seis jobs de renderização simultâneos. Se um nó for dedicado à renderização e não estiver incluído no pool do balanceador de carga que processa jobs interativos, a memória do processo principal do Looker poderá ser reduzida para permitir mais jobs de renderização. Em uma máquina de 64 GB, é possível alocar aproximadamente 30% (20 GB) para o processo principal do Looker. Reservando 20% para uso geral do SO, isso deixa 50% (32 GB) para renderização, o que é suficiente para 16 jobs de renderização simultâneos.
Banco de dados interno (back-end)
O servidor do Looker mantém informações sobre a própria configuração, conexões de banco de dados, usuários, grupos e funções, pastas, Looks e painéis definidos pelo usuário e vários outros dados em um banco de dados interno.
Para uma instância autônoma do Looker de tamanho moderado, esses dados são armazenados em um banco de dados HyperSQL na memória incorporado ao próprio processo do Looker. Os dados desse banco de dados são armazenados no arquivo <looker install directory>/.db/looker.script. Embora conveniente e leve, esse banco de dados tem problemas de desempenho com uso intenso. Portanto, recomendamos começar com um banco de dados MySQL remoto. Se isso não for possível, recomendamos a migração para um banco de dados MySQL remoto quando o arquivo ~/looker/.db/looker.script atingir 600 MB. Os clusters precisam usar um banco de dados MySQL.
O servidor do Looker faz muitas leituras e gravações pequenas no banco de dados MySQL. Toda vez que um usuário executa uma Análise ou uma Análise detalhada, o Looker verifica no banco de dados se o usuário ainda está conectado, se tem privilégios para acessar os dados, se tem privilégios para executar a Análise ou a Análise detalhada e assim por diante. O Looker também grava dados no banco de dados MySQL, como o SQL que foi executado e o horário em que a solicitação começou e terminou. Uma única interação entre um usuário e o aplicativo Looker pode resultar em 15 ou 20 leituras e gravações pequenas no banco de dados MySQL.
MySQL
O servidor MySQL precisa ser a versão 8.0.x e ser configurado para usar a codificação utf8mb4. O mecanismo de armazenamento InnoDB precisa ser usado. As instruções de configuração do MySQL, bem como as instruções sobre como migrar dados de um banco de dados HyperSQL para o MySQL, estão disponíveis na página de documentação Migrar o banco de dados de back-end do Looker para o MySQL.
Ao configurar o Looker para usar o MySQL, é necessário criar um arquivo YAML com as informações de conexão. Nomeie o arquivo YAML como looker-db.yml e adicione a configuração -d looker-db.yml na seção LOOKERARGS do arquivo lookerstart.cfg.
MariaDB
O MySQL tem licença dupla, disponível como código aberto e como produto comercial. A Oracle continuou a melhorar o MySQL, que foi bifurcado como MariaDB. As versões equivalentes do MariaDB do MySQL funcionam com o Looker, mas não são desenvolvidas nem testadas pelas equipes de engenharia do Looker. Portanto, a funcionalidade não é garantida nem oferece suporte.
Versões do Cloud
Se você hospedar o Looker na sua infraestrutura de nuvem, será lógico hospedar o banco de dados MySQL na mesma infraestrutura. Os três principais fornecedores de nuvem: Amazon AWS, Microsoft Azure e Google Cloud. Os provedores de nuvem gerenciam grande parte da manutenção e configuração do banco de dados MySQL e oferecem serviços como ajuda para gerenciar backups e fornecer recuperação rápida. Esses produtos funcionam bem com o Looker.
Consultas de atividade do sistema
O banco de dados MySQL é usado para armazenar informações sobre como os usuários estão usando o Looker. Qualquer usuário do Looker que tenha permissão para acessar o modelo Atividade do sistema tem acesso a vários painéis predefinidos do Looker para analisar esses dados. Os usuários também podem acessar as Análises dos metadados do Looker para criar outras análises. O banco de dados MySQL é usado principalmente para consultas "operacionais" pequenas e rápidas. As consultas "analíticas" grandes e lentas geradas pelo modelo de atividade do sistema podem competir com essas consultas operacionais e diminuir a velocidade do Looker.
Nesses casos, o banco de dados MySQL pode ser replicado para outro. Tanto os sistemas autogerenciados quanto alguns sistemas gerenciados pela nuvem oferecem configuração básica de replicação para outros bancos de dados. A configuração da replicação está fora do escopo deste documento.
Para usar a réplica nas consultas de atividade do sistema, crie uma cópia do arquivo looker-db.yml, por exemplo, com o nome looker-usage-db.yml, modifique-a para apontar para a réplica e adicione a configuração --internal-analytics-connection-file looker-usage-db.yml
à seção LOOKERARGS do arquivo lookerstart.cfg.
As consultas de atividade do sistema podem ser executadas em uma instância do MySQL ou em um banco de dados do Google BigQuery. Eles não são testados em relação a outros bancos de dados.
Configuração de desempenho do MySQL
Além das configurações necessárias para migrar o banco de dados de back-end do Looker para o MySQL, os clusters altamente ativos podem se beneficiar de ajustes e configurações adicionais. Essas configurações podem ser feitas no arquivo /etc/my.cnf ou no console do Google Cloud para instâncias gerenciadas pela nuvem.
O arquivo de configuração my.cnf é dividido em várias partes. As mudanças de configuração a seguir, discutidas nesta seção, são feitas na parte [mysqld].
Definir o tamanho do pool de buffer do InnoDB
O tamanho do pool de buffer do InnoDB é a RAM total usada para armazenar o estado dos arquivos de dados do InnoDB na memória. Se o servidor for dedicado à execução do MySQL, o innodb_buffer_pool_size precisará ser definido como 50% a 70% da memória total do sistema.
Se o tamanho total do banco de dados for pequeno, é possível definir o pool de buffer do InnoDB como o tamanho do banco de dados em vez de 50% ou mais da memória.
Neste exemplo, um servidor tem 64 GB de memória. Portanto, o pool de buffer InnoDB precisa estar entre 32 GB e 45 GB. Quanto maior, melhor.
[mysqld] ... innodb_buffer_pool_size=45G
Definir as instâncias do pool de buffer do InnoDB
Quando várias linhas de execução tentam pesquisar um conjunto de buffer grande, elas podem entrar em conflito. Para evitar isso, o pool de buffer é dividido em unidades menores que podem ser acessadas por diferentes linhas de execução sem conflito. Por padrão, o pool de buffer é dividido em 8 instâncias. Isso cria o potencial de um gargalo de 8 linhas. Aumentar o número de instâncias do pool de buffer reduz a chance de gargalo. O innodb_buffer_pool_instances precisa ser definido para que cada pool de buffer receba pelo menos 1 GB de memória.
[mysqld] ... innodb_buffer_pool_instances=32
Otimizar o arquivo de registro do InnoDB
Quando uma transação é confirmada, o banco de dados tem a opção de atualizar os dados no arquivo real ou salvar detalhes sobre a transação no registro. Se o banco de dados falhar antes que os arquivos de dados sejam atualizados, o arquivo de registro poderá ser "reproduzido" para aplicar as alterações. A gravação no arquivo de registro é uma pequena operação de adição. É eficiente anexar ao registro no momento da confirmação, agrupar várias alterações nos arquivos de dados e gravá-las em uma única operação de E/S. Quando o arquivo de registro é preenchido, o banco de dados precisa pausar o processamento de novas transações e gravar todos os dados alterados no disco.
Como regra geral, o arquivo de registro do InnoDB precisa ser grande o suficiente para conter uma hora de transações.
Normalmente, há dois arquivos de registro InnoDB. Elas devem representar cerca de 25% do pool de buffer do InnoDB. Por exemplo, em um banco de dados com um pool de buffer de 32 GB, os arquivos de registro do InnoDB precisam totalizar 8 GB ou 4 GB por arquivo.
[mysqld] ... innodb_log_file_size=8GB
Configurar a capacidade de E/S do InnoDB
O MySQL limita a velocidade em que as gravações são registradas no disco para não sobrecarregar o servidor. Os valores padrão são conservadores para a maioria dos servidores. Para ter o melhor desempenho, use o utilitário sysbench para medir a velocidade de gravação aleatória no disco de dados e, em seguida, use esse valor para configurar a capacidade de E/S para que o MySQL grave dados mais rapidamente.
Em um sistema hospedado na nuvem, o fornecedor de nuvem precisa informar o desempenho dos discos usados para armazenamento de dados. Para um servidor MySQL auto-hospedado, meça a velocidade de gravações aleatórias no disco de dados em operações de E/S por segundo (IOPS). O utilitário sysbench do Linux é uma maneira de medir isso. Use esse valor para innodb_io_capacity_max e um valor de metade a três quartos dele para innodb_io_capacity. No exemplo a seguir, os valores seriam mostrados se medíssemos 800 IOPS.
[mysqld] ... innodb_io_capacity=500 innodb_io_capacity_max=800
Configurar as linhas de execução do InnoDB
O MySQL vai abrir pelo menos uma linha de execução para cada cliente que está sendo atendido. Se muitos clientes estiverem conectados ao mesmo tempo, isso pode levar a um grande número de linhas de execução sendo processadas. Isso pode fazer com que o sistema passe mais tempo trocando de lugar do que processando.
O comparativo de mercado precisa ser feito para determinar o número ideal de linhas de execução. Para testar, defina o número de linhas entre o número de CPUs (ou núcleos de CPU) no sistema e o número de CPUs multiplicado por quatro. Para um sistema de 16 núcleos, esse valor provavelmente está entre 16 e 64.
[mysqld] ... innodb_thread_concurrency=32
Durabilidade da transação
Um valor de transação de 1 força o MySQL a gravar no disco para cada transação. Se o servidor falhar, a transação não será perdida, mas o desempenho do banco de dados será afetado. Definir esse valor como 0 ou 2 pode melhorar o desempenho, mas há o risco de perder alguns segundos de transações de dados.
[mysqld] ... innodb_flush_log_at_trx_commit=1
Definir o método de limpeza
O sistema operacional normalmente faz o buffer de gravações no disco. Como o MySQL e o SO estão em buffer, há uma penalidade de desempenho. Reduzir o método de limpeza em uma camada de armazenamento em buffer pode melhorar o desempenho.
[mysqld] ... innodb_flush_method=O_DIRECT
Ativar um arquivo por tabela
Por padrão, o MySQL usa um único arquivo de dados para todos os dados. A configuração innodb_file_per_table cria um arquivo separado para cada tabela, o que melhora o desempenho e o gerenciamento de dados.
[mysqld] ... innodb_file_per_table=ON
Desativar estatísticas em metadados
Essa configuração desativa a coleta de estatísticas em tabelas de metadados internas, melhorando a performance de leitura.
[mysqld] ... innodb_stats_on_metadata=OFF
Desativar o cache de consulta
O cache de consulta foi descontinuado. Portanto, definir query_cache_size e query_cache_type como 0 desativa essa opção.
[mysqld] ... query_cache_size=0 query_cache_type=0
Ampliar o buffer de junção
O join_buffer é usado para realizar mesclagens na memória. Aumentar esse valor pode melhorar algumas operações.
[mysqld] ... join_buffer_size=512KB
Ampliar a tabela temporária e os tamanhos de heap máximos
O tmp_table_size e o max_heap_table_size definem padrões razoáveis para tabelas temporárias na memória antes de serem forçadas para o disco.
[mysqld ... tmp_table_size=32MB max_heap_table_size=32MB
Ajustar o cache aberto da tabela
A configuração table_open_cache determina o tamanho do cache que armazena os descritores de arquivo para tabelas abertas. A configuração table_open_cache_instances divide o cache em várias partes menores. Há uma possível contenção de linha de execução no table_open_cache. Portanto, dividi-lo em partes menores ajuda a aumentar a simultaneidade.
[mysqld] ... table_open_cache=2048 table_open_cache_instances=16
Serviço do Git
O Looker foi projetado para funcionar com um serviço do Git para fornecer gerenciamento de versões dos arquivos LookML. Os principais serviços de hospedagem do Git são compatíveis, incluindo GitHub, GitLab e Bitbucket. Os provedores de serviços do Git oferecem outros benefícios, como uma GUI para conferir as mudanças de código e suporte a fluxos de trabalho, como solicitações de envio e aprovações de mudanças. Se necessário, o Git pode ser executado em um servidor Linux simples.
Se um serviço de hospedagem do Git não for adequado para sua implantação devido a regras de segurança, muitos desses provedores de serviços oferecem versões que podem ser executadas no seu próprio ambiente. O GitLab, em particular, é geralmente auto-hospedado e pode ser usado como um produto de código aberto sem custo de licença ou como um produto licenciado com suporte. O GitHub Enterprise está disponível como um serviço auto-hospedado e é um produto comercial com suporte.
As seções a seguir listam as nuances dos provedores de serviços mais comuns.
GitHub/GitHub Enterprise
A página de documentação Como configurar e testar uma conexão do Git usa o GitHub como exemplo.
GitLab/gitlab.com
Consulte a postagem da Comunidade do Looker Usar o GitLab para controle de versão no Looker para conferir as etapas detalhadas de configuração do GitLab. Se o repositório estiver contido em subgrupos, eles poderão ser adicionados ao URL do repositório usando o formato HTTPS ou SSH:
https://gitlab.com/accountname/subgroup/reponame git@gitlab.com:accountname/subgroup/reponame.git
Além disso, há três maneiras diferentes de armazenar chaves SSH geradas pelo Looker no GitLab: como chave SSH do usuário, chave de implantação do repositório ou chave de implantação global compartilhada. Uma explicação mais detalhada pode ser encontrada na documentação do GitLab.
Google Cloud Origem
Consulte a postagem da comunidade Como usar o Cloud Source Repositories para controle de versões no Looker para saber como configurar o Git com o Cloud Source Repositories.
Bitbucket Cloud
Consulte a postagem da comunidade Como usar o Bitbucket para controle de versão no Looker para conferir as etapas de configuração do Git com o Bitbucket Cloud. Desde agosto de 2021, o Bitbucket Cloud não oferece suporte a segredos em webhooks de implantação.
Bitbucket Server
Para usar as solicitações de pull com o Bitbucket Server, talvez seja necessário seguir estas etapas:
- Quando você abre um pull request, o Looker usa automaticamente o número de porta padrão (7999) no URL. Se você estiver usando um número de porta personalizado, será necessário substituí-lo no URL manualmente.
- É necessário acessar o webhook de implantação do projeto para sincronizar a ramificação de produção no Looker com a ramificação principal do repositório.
Difusão de Phabricator
Consulte a postagem da comunidade Configurar o Phabricator e o Looker para controle de versão para saber como configurar o Git com o Phabricator.
Rede
Conexões de entrada
Aplicativo da Web do Looker
Por padrão, o Looker detecta solicitações HTTPS na porta 9999. O Looker usa um certificado autoassinado com um CN de self-signed.looker.com. O servidor do Looker pode ser configurado para fazer o seguinte:
- Aceite conexões HTTP de um balanceador de carga/proxy de terminação SSL com a flag de inicialização
--ssl-provided-externally-by=<s>. O valor precisa ser definido como o endereço IP do proxy ou como um nome de host que possa ser resolvido localmente para o endereço IP do proxy. O Looker só vai aceitar conexões HTTP desse endereço IP. - Use um certificado SSL fornecido pelo cliente com a flag de inicialização
--ssl-keystore=<s>.
API Looker
A API Looker detecta na porta 19999. Se a instalação exigir acesso à API, o balanceador de carga precisará ter as regras de encaminhamento necessárias. As mesmas considerações do SSL se aplicam ao aplicativo da Web principal. Recomendamos usar uma porta diferente do aplicativo da Web.
Balanceadores de carga
Um balanceador de carga é usado com frequência para aceitar uma solicitação HTTPS na porta 443 usando o certificado do cliente e encaminhar a solicitação para o nó do servidor do Looker na porta 9999 usando o certificado autoassinado ou o HTTP. Se os balanceadores de carga estiverem usando o certificado autoassinado do Looker, eles precisarão ser configurados para aceitar esse certificado.
Conexões inativas e tempos limite
Quando um usuário inicia uma solicitação grande no Looker, isso pode resultar em uma consulta que pode ser cara para executar no banco de dados. Se o usuário abandonar a solicitação de qualquer forma, por exemplo, fechando a tampa do laptop, desconectando da rede ou fechando a guia no navegador, a Looker vai saber e encerrar a consulta do banco de dados.
Para lidar com essa situação, quando o aplicativo da Web do cliente faz uma solicitação para executar uma consulta de banco de dados, o navegador abre uma conexão de soquete usando uma solicitação HTTP de longa duração para o servidor do Looker. Essa conexão vai ficar aberta e inativa. Esse socket será desconectado se o aplicativo da Web do cliente for encerrado ou desconectado de alguma forma. O servidor vai notar essa desconexão e cancelar todas as consultas de banco de dados relacionadas.
Os balanceadores de carga geralmente notam essas conexões ociosas abertas e as encerram. Para executar o Looker de maneira eficaz, o balanceador de carga precisa ser configurado para permitir que essa conexão permaneça aberta durante a consulta mais longa que um usuário possa executar. Sugerimos um tempo limite de pelo menos 60 minutos.
Conexões de saída
Os servidores do Looker podem ter acesso de saída irrestrito a todos os recursos, incluindo a Internet pública. Isso simplifica muitas tarefas, como a instalação do Chromium, que exige acesso aos repositórios de pacotes da distribuição do Linux.
Confira a seguir as conexões de saída que o Looker pode precisar fazer.
Conexão interna de banco de dados
Por padrão, o MySQL detecta conexões na porta 3306. Os nós do Looker precisam ser capazes de iniciar conexões com o MySQL nessa porta. Dependendo de como o repositório é hospedado, pode ser necessário atravessar um firewall.
Serviços externos
Os servidores de licenciamento e de telemetria do Looker estão disponíveis usando HTTPS na Internet pública. Talvez seja necessário adicionar o tráfego de um nó do Looker para ping.looker.com:443 e license.looker.com:443 a uma lista de permissões.
Conexões de data warehouse
Os bancos de dados hospedados na nuvem podem exigir uma conexão usando a Internet pública. Por exemplo, se você estiver usando o BigQuery, talvez seja necessário adicionar accounts.google.com:443 e www.googleapis.com:443 a uma lista de permissões. Se o banco de dados estiver fora da sua infraestrutura, consulte o host do banco de dados para saber os detalhes da rede.
Serviços SMTP
Por padrão, o Looker envia e-mails de saída usando o SendGrid. Isso pode exigir a adição de smtp.sendgrid.net:587 a uma lista de permissões. As configurações de SMTP podem ser alteradas na configuração para usar um gerenciador de e-mail diferente.
Hubs de ação, servidores de ação e webhooks
Muitos destinos do programador, em especial os webhooks e os que são ativados no painel de administrador do Looker, envolvem o envio de dados usando solicitações HTTPS.
- Para webhooks, esses destinos são especificados no momento da execução pelos usuários e podem ser contrários ao objetivo de bloquear as conexões de saída.
- No caso de um hub de ações, essas solicitações são enviadas para
actions.looker.com. Confira os detalhes na documentação de configuração do Looker Action Hub. - Para outros servidores de ação, essas solicitações são enviadas aos domínios especificados na configuração do servidor de ação pelos administradores no painel Administrador do Looker.
Servidor proxy
Se não for possível acessar a Internet pública diretamente, o Looker poderá ser configurado para usar um servidor proxy para solicitações HTTP(S) adicionando uma linha como esta a lookerstart.cfg:
JAVAARGS="-Dhttp.proxyHost=myproxy.example.com -Dhttp.proxyPort=8080 -Dhttp.nonProxyHosts=127.0.0.1|localhost -Dhttps.proxyHost=myproxy.example.com -Dhttps.proxyPort=8080"
A comunicação entre nós acontece por HTTPS. Portanto, se você usa um servidor proxy e sua instância está agrupada, geralmente é necessário adicionar os IPs/nomes de host de todos os nós do cluster ao argumento Dhttp.nonProxyHosts.
Comunicações entre nós
Identificador de host interno
Em um cluster, cada nó precisa ser capaz de se comunicar com os outros nós. Para permitir isso, o nome do host ou o endereço IP de cada nó é especificado na configuração de inicialização. Quando o nó for iniciado, esse valor será gravado no repositório do MySQL. Outros membros do cluster podem se referir a esses valores para se comunicar com esse nó. Para especificar o nome do host ou o endereço IP na configuração de inicialização, adicione -H node1.looker.example.com à variável de ambiente LOOKERARGS em lookerstart.cfg.
Como o nome do host precisa ser exclusivo para cada nó, o arquivo lookerstart.cfg precisa ser exclusivo em cada instância. Como alternativa à programação fixa do nome do host ou do endereço IP, o comando hostname -I ou hostname --fqdn pode ser usado para encontrá-los no momento da execução. Para implementar isso, adicione -H $(hostname -I) ou -H $(hostname --fqdn) à variável de ambiente LOOKERARGS em lookerstart.cfg.
Portas internas
Além das portas 9999 e 19999, usadas para os servidores da Web e da API, respectivamente, os nós do cluster vão se comunicar entre si por meio de um serviço de mediador de mensagens, que usa as portas 1551 e 61616. As portas 9999 e 19999 precisam estar abertas para o tráfego do usuário final, mas as portas 1551 e 61616 precisam estar abertas entre os nós do cluster.