Comportamento do Sistema de Monitoramento no Ambiente Monitorado

Uma característica importante de um sistema de gerência é a sua eficiência. Um sistema desse tipo não deve causar uma grande interferência no meio que está sendo monitorado sob pena de comprometer a análise dos dados de desempenho do sistema. Por este motivo os agentes, que são distribuídos por todas as máquinas monitora- das, foram desenvolvidos visando consumir o mínimo de recursos possível. Todas as funcionalidades de coleta específica de uma variável foram delegadas às rotinas pré- configuradas pela própria variável. Isso, além de contribuir muito para a flexibilidade do sistema, permite que o programa “MonitorAgent”, que é a parte do agente responsá- vel pela aquisição dos dados, seja somente um escalonador de tarefas. Este programa mais o “AgentProtocol”, responsável por tratar das conexões com as outras unidades, presentes em uma máquina monitorada representam o impacto do monitoramento na mesma.

de processamento limitado pelas rotinas de coleta que podem ser modificadas e oti- mizadas à medida das restrições dos componentes monitorados. As rotinas utilizadas hoje constituem em chamadas a um servidor WBEM, a um SNMP e além da chamada direta à alguns comandos. Utilizando 20 variáveis configuradas o processo gastou 21 segundos para coletar esse valores. Esses dados foram medidos em um Sempron 3300+ com 512MB de memória utilizando a distribuição Linux openSUSE 10.2.

Como visto o processo de coleta consome uma quantidade de processamento pe- quena mas exige cuidados em relação aos intervalos entre as coletas. Atualmente o menor intervalo entre as coletas é de 30 minutos, o que é suficiente para o processo de coleta causar muito impacto no desempenho da máquina monitorada.

Quanto à utilização de memória, os agentes precisaram ser compilados estatica- mente, para facilitar o processo de distribuição do sistema. Desta forma o mesmo executável pode ser instalado em sistemas Linux diferentes. Essa decisão foi tomada também pensando na estabilidade do sistema pois o executável não dependeria de nenhuma outra biblioteca.

Na mesma máquina utilizada na medida de processamento os dois programas que compõem o agente de monitoramento “MonitorAgent” e “AgentProtocol” consomem respectivamente 1031 KB e 1086 KB de memória ao serem inicializados. Estes dados foram obtidos observando o campo do total de memória gasto por meio do comando

size do Linux. Este consumo de memória permite que o agente seja executado sem

causar um grande impacto nas máquinas das escolas que têm em média 256 MB de memória principal.

As unidades intermediárias por terem um funcionamento bastante parecido com a central não serão analisadas com mais detalhes nessa seção. Estas unidades são exe- cutadas geralmente nos servidores que estão nas escolas, que possuem mais recursos computacionais que as estações, e recebem informações de um número pequeno de máquinas. Portanto essas unidades não é um gargalo no funcionamento do sistema e geram um impacto muito pequeno nessas máquinas.

A unidade central é encarregada principalmente de receber os dados enviados e determinar o local correto para inserí-los no banco de dados. A interface de gerên- cia, outro componente do sistema muito interligado com a central, também tem seu desempenho limitado pelas inserções e consultas ao banco de dados. A análise do de- sempenho das ferramentas que estão na central será concentrada no desempenho do banco de dados.

A central de monitoramento da SEEMG está instalada numa máquina Pentium D de 3 GHz com 2 GB de memória principal rodando a distribuição Linux openSUSE 10.2. Está instalado também nessa máquina o banco de dados MySQL 5.0.45 que arma- zena as informações do sistema. Esta máquina é dedicada exclusivamente ao sistema de monitoramento.

No início da instalação do sistema nas escolas o consumo de processamento na central de monitoramento estava muito alto, mesmo com um número pequeno de má- quinas enviando dados. Para 62 unidades enviando informações para a central a utili- zação da capacidade de processamento da máquina se mantinha em 95%.

Foram detectadas duas causas para este comportamento. A primeira foi o tama- nho da cache utilizada pelo MySQL. Por padrão nesse banco de dados este tamanho é configurado para utilizar 2 MB da memória principal. Mudando esse parâmetro e analisando as informações geradas pela ferramenta mysqlreport foi observado que para esta quantidade de unidades uma cache de 7 MB garantiria uma taxa de acertos na cachede 99%. Modificando o tamanho da cache para 16 MB, portanto acima dos 7 MB, a utilização do processador da máquina caiu para uma média de 50%.

A segunda causa da baixo desempenho da ferramenta no início da operação era o agrupamento dos dados coletados nos níveis superiores da hierarquia. Devido à um erro de configuração em uma das variáveis ela estava sendo coletado em intervalos de 3 segundos. Isso gerava uma grande quantidade de consultas e inserções no banco de dados quando essa variável era agrupada nos seis níveis na hierarquia de exibição da interface. Desabilitando essa funcionalidade dessa variável, a utilização da capacidade de processamento da central se estabilizou numa média de 4%. Essa experiência foi importante para detectar que essa operação seria um problema se aplicada a variáveis muito dinâmicas quando o sistema estiver operando com um quantidade maior de unidades.

Com relação a utilização de disco na central para armazenamento das informações foi implementado um mecanismo para evitar que informações repetidas fossem gra- vadas no banco de dados. Este mecanismo é descrito no código 4.1.1. Como não existe ainda um mecanismo de ajuste dinâmico dos intervalos de coleta de uma variável elas estão sendo superamostradas pelo sistema visando a detecção dos eventos mais rapi- damente.

Para analisar o comportamento desse mecanismo foram observados os valores de duas variáveis, uma dinâmica e outra estática, em uma máquina da Escola Estadual

Joseph Stalin Romano no dia 12/11/2007 às 21:30h. Essa escola começou a enviar informações no dia 03/11/2007. A variável estática que envia o nome do processador foi recebida pela central 34 vezes nesse período e foram gravados apenas 2 registros, que apesar de gerarem atualizações no banco de dados, possibilitaram uma economia de 94% de espaço.

A variável dinâmica que retorna a quantidade de memória livre disponível na má- quina monitorada foi recebida pela central 836 vezes, porém gerou apenas 536 registros no banco de dados. Neste caso a economia foi de 36%.