Análise

Parte da análise do ConManager é implementada pelo Zabbix. O mecanismo de disparo dos gatilhos no Zabbix é combinado com a definição status de utilização de cada servidor no ConManager e dessa forma é provida à fase de planejamento as informações necessárias para a tomada de decisão. Os gatilhos devem ser definidos junto com uma action, esta configurada para notificar o ConManager via script, pelo administrador do ambiente no Zabbix. Com isso, a ferramenta de monitoramento está apta a notificar o módulo de análise nos instantes que os recursos atingem níveis acima dos valores configurados, dando assim a sua ativação. Cada ativação de Triggers no Zabbix vira um alarme no ConManager 2 _{Uma Action é um conceito do Zabbix, seu papel é dar encaminhamento da notificação enviando-a por}

Capítulo 4. Projeto ConManager 49

e a partir dele o planejamento é ativado. São dois os momentos que o Zabbix notifica o ConManager sobre uma sobrecarga. O primeiro é quando a sobrecarga é percebida e é enviada uma mensagem com o status (problem), juntamente com dados que identificam a origem, o horário, a quantidade de recurso disponível, etc. A segunda mensagem é enviada quando o ambiente não está mais sobrecarregado, com isso é enviada uma mensagem com o status (ok). O ciclo de vida de um alerta no ConManager está relacionado com o recebimento dessas mensagens. O alerta aciona o módulo planejamento e só é encerrado quando o Zabbix notifica a resolução.

Os limites de utilização dos recursos para disparar um gatilho foram definidos baseando-se na experiência da equipe que administra o ambiente, que elencou os parâmetros monitorados e quais as condições necessárias para que seja considerada sobrecarga. Além disso, existe um cronograma para cada disciplina ao longo do semestre, no qual os horários e datas de cada aula são armazenados no Google Agenda. O módulo de análise usa a API do Google agenda para obter os horários das aulas de cada laboratório. Quando uma situação de sobrecarga é detectada pelo Zabbix, o módulo de análise é ativado coletando informações acerca do estado atual do ambiente, tabela de horários e aciona o módulo de planejamento.

4.3.2.1 Definição de gatilhos

Através da definição dos limites de cada recurso monitorado é possível interpretar os dados coletados e avisar o ConManager que há a necessidade de uma intervenção no ambiente. A configuração das triggers foram implementadas apenas nos agentes que monitoram os servidores de aplicação que atendem os laboratórios (sejam de aula ou de uso geral). Quais recursos que disparam os gatilhos e os valores limites que são entendidos como sobrecarregados foram definidos com base na experiência da equipe de TI que acompanha o comportamento dos laboratórios, tem contato com os professores que os utilizam para ministrar aulas e até mesmo visitas nos laboratórios para sentir o desempenho das máquinas de acordo com o nível de utilização dos recursos.

As triggers disparam um aviso ao ConManager quando algum dos recursos configu- rados ultrapassa o limite estipulado, persistindo por um intervalo de tempo que caracteriza a sobrecarga. É possível que exista mais de uma trigger por recurso (como é o caso da CPU). A necessidade de criar mais de um gatilho por recurso é a existência de diferentes parâmetros que indicam a sobrecarga na CPU, como o nível de utilização por processos de usuário, processos do sistema, tempo de espera para operações de entrada e saída (I/O) e carga de processamento. A Tabela 2 exibe a relação de triggers configuradas.

Capítulo 4. Projeto ConManager 50

Nome da Trigger

Cpu system time (processos do sistema) acima dos 50% por mais de 5 minutos Cpu user time (processos de usuários acima

dos 70% por mais de 5 minutos Cpu Iowait (operações de entrada e saída)

maior que 20% por mais de 5 minutos Memória RAM menor que 20% por mais

de 5 minutos

Cpu load (carga de processamento) acima de 5 por mais de 5 minutos

Espaço em disco menor que 20% do volume Tabela 2 – Configuração de Triggers

4.3.2.2 Status de utilização dos servidores

O módulo de análise também tem a responsabilidade de organizar os dados coletados para facilitar a tomada de decisão no módulo de planejamento. Pensando nisso, foram criados os status de utilização dos servidores de aplicação e hardware. Os status representam o nível de utilização dos laboratórios de acordo com os dados coletados pelo Zabbix. O ConManager faz uma consulta ao banco do Zabbix através de sua API, coleta os dados, compara com os intervalos configurados pelo administrador do ConManager e assim consegue indicar se os laboratórios estão sobrecarregados ou subutilizados. Com base nesses status será possível criar regras para auxiliar o módulo de planejamento na tomada de decisão.

Assim como a configuração dos gatilhos, os parâmetros que indicam os status foram definidos de acordo com a experiência da equipe no gerenciamento desse ambiente. Cada status leva em consideração mais de um tipo de recurso para apontar o resultado. Na Tabela 3 são exibidos os status criados, contendo os nomes de cada um e as condições necessárias para o ConManager identificar o nível de utilização dos laboratórios. Em cada expressão são utilizados operadores lógicos como && (quando as duas expressões forem verdadeiras), < (menor que),> (maior que),<= (menor ou igual que),>= (maior ou igual que),|| (quando uma ou outra expressão for verdadeira) e as representações dos parâmetros monitorados como sessões de usuários (usuarios), tempo ocioso do Cpu (Cpu_idle_time), memória RAM livre (ram_livre), carga de CPU (Cpu_load), tempo de CPU utilizado por processos de usuários (Cpu_user_time), quantidade de espaço em disco (disco_livre).

O módulo de planejamento do ConManager precisa levar em consideração antes de fazer qualquer tipo de redimensionamento de recursos entre contêineres o estado do servidor Hardware. Diante dessa necessidade, foram criados exclusivamente para o Hardware mais três tipos de status (exibidos na Tabela 4), porém, ao invés de como foi implementado nos servidores de aplicação, no hardware os recursos de CPU, RAM e disco possuem

Capítulo 4. Projeto ConManager 51

Nome do status Condição

Subutilizado

(usuarios <5 && Cpu_idle_time >90% && ram_livre >= 90% && Cpu_load <1)

por mais de 15 minutos

Pouco uso

( (usuarios >= 5 && usuarios <= 15) ||

(Cpu_user_time >= 10% && Cpu_user_time <= 40%) || (Cpu_load >= 1 && Cpu_load <= 2) ||

(ram_livre >= 60% && ram_livre <90%) || (disco_livre >= 50% && disco_livre <65%) )

por mais de 5 minutos

Bem utilizado

( (usuarios >15 && usuarios <= 30) ||

(Cpu_user_time >40% && Cpu_user_time <= 70%) || (Cpu_load >2 && Cpu_load <= 6 ) ||

(ram_livre >= 20% && ram_livre <60%) || (disco_livre >20% && disco_livre <50%) )

por mais de 5 minutos

Sobrecarregado ( (usuarios >30%) || (Cpu_user_time >70%) || (Cpu_system_time >50%) || (Cpu_iowait_time >20%) || (ram_livre <20%) || (Cpu_load >6) || (disco_livre <20%) ) por mais de 5 minutos

Tabela 3 – Status de utilização dos servidores de aplicacao

três possíveis status. O "verde"indica que o nível de utilização do recurso está baixo no hardware (mesmo que para um laboratório esse recurso esteja sobrecarregado), o status "amarelo"indica que o nível de utilização desse recurso está razoavelmente bem utilizado e

por fim, o status "vermelho"indica que esse recurso está sobrecarregado.