Monitorando o uso da memória no sistema Linux

Question

Nós usamos o WhatsUp Gold para monitorar todos os nossos servidores da web. Em nossos servidores Linux (e muito no mesmo grau, nossos servidores FreeBSD) estou tendo um pequeno problema com os monitores de memória. Estamos usando o SNMP com o WUG para capturar os dados dos servidores. O contador de memória que o daemon SNMP retorna nos servidores é o valor combinado (usado, em cache, buffers). Neste momento, um dos meus servidores é assim:

[admin@stgwww snmp]$ free -m
             total       used       free     shared    buffers     cached 
Mem:          7872       1656       6216          0        143      1107
-/+ buffers/cache:        404       7467 
Swap:         4867          0       4867

O valor que está sendo retornado via SNMP para WUG é 1656. Pelo que entendi, a RAM em cache é essencialmente RAM LIVRE com o benefício adicional de se prender a dados que anteriormente a ocupavam caso fosse necessário novamente. Então, para nossos propósitos de querer saber o quanto a RAM está realmente sendo usada ativamente, o valor que estamos recebendo de volta é enganoso. Se sairmos do que está sendo representado pelo WUG, estamos sendo levados a acreditar que mais RAM está sendo usada e menos disponível do que realmente existe.

Então, qual é a melhor maneira de monitorar isso? WUG permite-me escrever scripts SSH, que podem SSH no servidor a cada 5 minutos ou mais, executar um script e retornar o valor (desde que seja um valor numérico único). Com isso eu escrevi um script que puxa o número "404" do exemplo acima e o divide pela quantidade total me dando um valor percentual usado que eu retorno ao WUG e gráfico em um gráfico que escala de 0 a 100. Mas isso parece muito com um hack.

É melhor eu monitorar o free + buffers + valor em cache? Existe uma maneira melhor de fazer isso no WUG? Pensamentos?

    

Answer 1

Vá e dê uma olhada no linuxatemyram.com . O WUG está dizendo a você o que o Linux acha que é usado (usado + buffers + cache). O que você decidiu monitorar (usado / total) parece-me razoável, especialmente para um gráfico, pois não requer nenhum conhecimento dos detalhes do sistema.

    

Answer 2

Ram livre é ram livre e buffers são ram em cache que podem ser recuperados. A maioria das ferramentas de monitoração que usei apresenta essa diferença em um gráfico de área acumulativa que apresenta pelo menos memória em cache e inativa empilhada no nível de 100% e troca por elas. A única maneira de ter um conhecimento correto de como o servidor está funcionando é ver todos eles.

Se você puder apenas representar graficamente um valor, recomendarei que represente graficamente a memória usada e considere 'livre' o resto. Ah, e eu recomendo também mudar ferramentas de monitoramento. Mesmo munin com a configuração padrão tem um gráfico de memória decente.

    

Answer 3

Eu recomendo gânglios: link

Faz monitoramento de memória e divide em partes constituintes. Há quase zero configuração. Você instala um daemon em cada caixa linux e depois designa uma caixa central para gravar os RRDs.

Veja um exemplo de gráfico de memória:

    

Answer 4

Para aqueles (Renan) interessados em saber qual solução eu criei.

Eu tenho usado um script personalizado para recuperar a memória (Usado / Total) e convertê-lo em uma porcentagem.

#!/bin/bash                                                                                                                                                                                                                              

USED='free -m | grep "buffers/cache" | awk '{print $3}''
TOTAL='free -m | grep "Mem:" | awk '{print $2}''

VALUE='bc -l <<< "scale=2; (${USED}/${TOTAL})*100" | sed 's/\.[0-9][0-9]//''

exit $VALUE

Eu, então, uso um contador SNMP personalizado para executar esse script e retornar o valor. No arquivo snmpd.conf, é assim:

exec   check_mem /usr/share/snmp/check_mem.sh

Cada script exec retorna alguns OIDs com coisas como o nome do script, o status de saída, o valor de retorno e assim por diante. A parte desafortunada é que o valor de retorno é uma string e não um número inteiro, portanto, o WUG tem alguns problemas ao fazer o gráfico (ainda faz um gráfico, mas os gráficos em tempo real não funcionam). Portanto, nesse caso em que sabemos que o valor sempre estará abaixo de 100, eu o configurei para o status de saída e, em seguida, pesquisei esse OID.

Para monitorá-lo no WUG, crie um monitor de desempenho SNMP personalizado e monitore o OID do status de saída desse script exec. Você pode criar alertas personalizados e quais não.

Estamos usando há algum tempo e funciona muito bem. Espero que ajude!