Manage

O Manage é uma interface web de configuração e monitoramento que pode ser acessada em qualquer servidor Engine em execução utilizando a URL “<endereço_servidor>/manage”.

Ao acessar o Manage, serão solicitados um nome de usuário e uma senha. Por padrão, o usuário e a senha são “iengine”. Essa senha padrão deve ser alterada no primeiro acesso por meio dos campos “Administrator Username” e “Administrator Password” do menu “Configuration > General”.

As configurações e informações de monitoramento apresentadas no Manage dizem respeito apenas à instância do Engine acessada. Uma visão simplificada e consolidada de todos os Engines em execução pode ser obtida por meio do processo “Admin > Monitoramento > Engines”.

Para fins de monitoramento, podem ser observadas as seguintes opções do menu.

Requests

Exibe em tempo real as requisições HTTP que estão sendo atendidas pelo Engine. A opção “Profiler Enabled” deve estar ativa em “Configuration > General” para que sejam exibidos detalhes técnicos relevantes das requisições em execução.

As requisições HTTP podem ser dos usuários utilizando navegadores Web, dos Engines utilizando o protocolo IAP sobre HTTP ou de outros sistemas que estejam consumindo APIs HTTP. As informações exibidas são:

• ID/Thread: identificador interno da conexão e da thread utilizada para tratar a requisição.
• Running Time: tempo de execução do tratamento da requisição.
• Status: mensagem que o sistema atribui à requisição, identificando a que se refere.
• Client: endereço IP da estação de origem da requisição.
• Forwarded By: endereços de redirecionamento, presentes quando o Engine está sendo acessado por meio de elementos intermediários como balanceadores de carga ou servidores proxy.
• DB Name: quando a requisição realiza consultas ao banco de dados, essa coluna exibe o nome da base de dados.
• DB SID: quando a requisição realiza consultas ao banco de dados, essa coluna exibe o identificador da conexão no SGBD. Essa informação pode ser utilizada pelo administrador para consultar detalhes técnicos no SGBD.
• Workload: indica qual o tipo de comportamento configurado na aplicação no momento daquela requisição. Valores possíveis:
  • olap (Online analytical processing): indicado para relatórios ou processos de consulta. Normalmente, interagem com uma massa de dados média ou elevada. Prioridade de atendimento média;
  • oltp (Online transaction processing): indicado para processos que realizam a leitura ou gravação de poucos registros. Prioridade de atendimento alta;
  • dw (Data Warehouse): indicado para processos que consolidam grandes massas de dados para pesquisas posteriores. Prioridade de atendimento baixa;
• User: nome e chave do usuário responsável pela requisição.
• Referrer: identificador do processo que originou a requisição.

Na listagem das requisições em atendimento, também são exibidos os botões “Abort” e “Profile”, permitindo interromper a requisição em atendimento e obter detalhes técnicos sobre a execução, para fins de análise de desempenho. A interrupção de uma requisição pode não ser imediata, pois o sistema pode estar bloqueado aguardando a finalização de comandos enviados para sistemas de terceiros ou bibliotecas nativas externas.

Sessions

Relação das sessões JavaScript criadas no servidor. As informações exibidas são:

• Exp: indica se a sessão encontra-se expirada e será eliminada pelo sistema na próxima rotina de limpeza do gerenciador de sessões.
• Session ID/Thread ID: identificador da sessão javascript e da thread utilizada para atender a sessão. Caso ela não esteja em execução, o Thread Id será 0 (zero).
• Creation: data e hora de criação da sessão.
• Last access: última vez que foi processada uma requisição utilizando a sessão.
• MIT: tempo máximo de inatividade da sessão em segundos.
• MLT: tempo máximo de vida da sessão em segundos. O valor 0 (zero) indicará que a sessão não tem um tempo máximo de vida configurado e a sessão será eliminada apenas se for atingido o tempo máximo de inatividade.
• Type: as sessões podem ser de 3 tipos:
  • Stateful: sessões que preservam o estado durante múltiplas execuções e que normalmente são utilizadas nas interfaces com o usuário final, como aquelas construídas utilizando o Web Framework. Devido à preservação do estado, elas normalmente consomem uma quantidade elevada de memória e deve-se evitar que haja mais de 25 sessões stateful simultâneas em um Engine.
  • Stateless: sessões que não garantem a preservação do estado durante múltiplas execuções. São utilizadas pelas rotas HTTP, pelo Scheduler e para executar scripts internos do Engine.
  • Standalone: sessões que não são compartilhadas e que têm um controle de vida manual. Utilizadas pela API ScriptRunner, pela IDE embarcada do Engine e por scripts de execução única.
• Mem: memória alocada pela sessão em KB.
• DS: quantidade de DataSets ativos na sessão.
• Profile: perfil da sessão. Os perfis de sessões com acesso ao SGBD são nomeados com o nome da base de dados ou utilizam esse nome como sufixo.
• Realm: o “realm” de uma sessão determina as características comuns das sessões quem atendem uma determinada aplicação, como a preservação do estado (stateful ou stateless), tempo de vida e de inatividade. Um realm pode ser associado a um caminho da Virtual File System ou a um conjunto de rotas HTTP. Sessões de um “realm” são isoladas das demais, garantindo que as aplicações distintas não compartilhem informações de usuários. Os realms são configurados no diretório “/Configurações/Realms” e o realm “wf-data” é o mais comum, pois é o utilizado pelas sessões de usuários do Web Framework.
• User key: chave do usuário responsável pela sessão.
• Ip: endereço IP de onde o Engine recebeu a requisição. Se o Engine estiver sendo acessado por meio de um balanceador de carga, esse IP será o do balanceador.
• Forwarded for: exibe o valor do cabeçalho “X-Forwarded-For” da requisição HTTP recebida. Quando o Engine é acessado por meio de um balanceador de carga, o IP da estação de origem da requisição fica registrado nesse cabeçalho HTTP.

Na listagem das sessões, também são exibidos os botões “Drop” e “Profile”, permitindo expirar sessões de modo forçado ou obter detalhes técnicos sobre as requisições atualmente em processamento na sessão.

Memory

Detalhes do consumo de memória do Engine e do sistema operacional do servidor. Deve-se ter atenção para que a memória consumida pelo sistema esteja sendo preferencialmente atendida pela memória física do servidor. O uso de memória paginada em disco prejudica de forma significativa o desempenho do sistema, principalmente em ambientes em nuvem onde o disco é um storage externo.

Caso ainda esteja sendo utilizada a versão 32 bits do Engine, deve-se ter cuidado do consumo de memória não ultrapassar o limite imposto pelo sistema operacional de 3GB ou 4GB. Ao atingir esse limite, o Engine poderá ser interrompido de forma forçada, podendo provocar a corrupção do cache local. Esse limite não existe na arquitetura 64 bits e, por esse motivo, a versão 32 bits não deve ser mais utilizada.

As informações exibidas são:

• Sessions Count: quantidade das sessões por tipo.
• Virtual memory in use: memória virtual que de fato está sendo utilizada pelo Engine. Este valor desconsidera a memória virtual reservada para as bibliotecas compartilhadas e as páginas de memória que foram reservadas, mas que não foram confirmadas. No Windows, é considerada memória virtual em uso o tamanho de confirmação do processo (commit charge) e, no Linux, a soma da memória residente e da paginada em disco (RSS + Swap).
  • Current: quantidade de memória virtual atualmente alocada pelo processo do Engine.
  • Peak: quantidade máxima de memória já requisitada pelo Engine ao sistema operacional.
• Physical memory in use (Current | Peak): quantidade de memória física do sistema operacional utilizada pelo Engine e o total já requisitado. No Windows, será igual ao conjunto de trabalho do processo (working set) e essa métrica pode incluir memória de bibliotecas compartilhadas com outros processos. Por esse motivo, o seu valor pode ser superior à memória virtual em uso. No Linux, será apresentado o tamanho da memória residente (RSS).
• OS physical memory (Total | In use | Available): tamanho total, em uso e disponível da memória física do sistema operacional.
• OS page file (Total | In use | Available): tamanho total, em uso e disponível do arquivo de paginação do sistema operacional. No Windows, o tamanho do arquivo de paginação também considera a memória física disponível. No Linux, essa informação é relativa apenas ao tamanho do Swap. A paginação de memória em disco pode degradar o desempenho do sistema, portanto deve-se considerar aumentar a memória física instalada caso o percentual de memória paginada em disco seja alto em relação à memória física disponível.
• IDO cache size: quantidade de memória reservada para cache do banco de dados IDO, utilizado pelos DataSets temporários e pelo cache local da base de dados.

As informações de memória apresentadas no Manage também pode ser obtidas por meio da API SystemMonitor.

Logs

Arquivos de logs gerados pelo sistema contendo informações técnicas emitidas pelo Engine, como também dos processos e relatórios executados no sistema. Em sua configuração padrão, o sistema gera os seguintes arquivos de log:

• main.log: arquivo de log principal do sistema que registra as informações escritas por meio da variável global log ou por instâncias da classe Logger.
• engine.log: informações relacionadas ao funcionamento do Engine, como inicialização e encerramento do sistema.
• dbCache.log: informações relacionadas à inicialização e ao sincronismo do cache local do Engine.
• scheduler.log: detalhes da execução dos scripts agendados pela classe Scheduler ou pelo processo “Admin > Agendador de scripts”.
• profiler.log: registros de desempenho dos scripts executados no Engine, gerados apenas quando a opção “Profiler Enabled” está ativa no menu “Configuration > General”. As informações contidas nesse arquivo podem ser analisadas utilizando o processo “Desenvolvimento > Análise do log do profiler”.
• httpAccess.log: requisições HTTP atendidas pelo sistema. Os registros de log gerados seguem o padrão Combined Log Format e podem ser processados por ferramentas de monitoramento de acesso que suportem esse formato.
• email.log: registros dos e-mails enviados pelo Engine.
• sql.log: por padrão, são registradas as seguintes informações:
  • Comandos DDL executados via Database.prototype.executeDDL.
  • Comandos SQL enviados por conexões configuradas com workloadType do tipo 'oltp' e com duração superior ao valor da configuração MaxOltpQueryExecutionTime em “Configuration > Others”.
  • Erros nas execução de comandos no SGBD.
• supervisor.log: informações sobre o consumo de recursos do sistema, gerados de forma periódica enquanto o Engine está em execução.
• java.log: registros relacionados a integração com o Java e os valores capturados da saída padrão e de erro do Java.
• crash.log: registros dos encerramentos forçados que foram detectados pelo Engine.

Esses e outros arquivos de logs podem ser configurados por meio da opção “Configuration” exibida na interface de “Logs” do Manage. As configurações devem ser realizadas em um formato similar ao adotado pelo log4j, sendo recomendado seguir os padrões adotados na configuração padrão do sistema.

Para uma análise mais produtiva dos logs, é recomendado que os logs do servidor sejam descarregados em um computador local e sejam utilizadas ferramentas como o VS Code ou o Notepad++ para realizar a pesquisa no diretório extraído. Dessa forma, evita-se a navegação e pesquisa diretamente no navegador, que não trata adequadamente grandes arquivos de textos.