Назад | Перейти на главную страницу

Мониторинг использования памяти в системе Linux

Мы используем WhatsUp Gold для мониторинга всех наших веб-серверов. На наших серверах Linux (и в той же степени на наших серверах FreeBSD) у меня небольшая проблема с мониторами памяти. Мы используем SNMP с WUG для получения данных с серверов. Счетчик памяти, который демон SNMP возвращает на серверах, представляет собой комбинированное значение (используется, кэшируется, буферы). Прямо сейчас один из моих серверов выглядит так:

[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

Значение, возвращаемое через SNMP в WUG, равно 1656. Насколько я понимаю, кэшированная оперативная память - это, по сути, БЕСПЛАТНАЯ оперативная память с дополнительным преимуществом, заключающимся в том, что данные, которые ранее занимали ее, на случай, если они понадобятся снова. Поэтому для наших целей узнать, сколько оперативной памяти фактически активно используется, значение, которое мы возвращаем, вводит в заблуждение. Если мы отойдем от того, что рисует WUG, нас заставят поверить, что используется больше оперативной памяти, а доступно меньше, чем есть на самом деле.

Итак, как лучше всего следить за этим? WUG позволяет мне писать сценарии SSH, которые могут подключаться по SSH к серверу каждые 5 минут или около того, выполнять сценарий и возвращать значение (если это одно числовое значение). С этим я написал сценарий, который извлекает число «404» из приведенного выше примера и делит его на общую сумму, давая мне процент использованного значения, которое я возвращаю в WUG и рисую на диаграмме, которая масштабируется от 0 до 100. Но это похоже на большую часть взлома.

Могу ли я лучше контролировать свободные + буферы + кешированное значение? Есть ли лучший способ сделать это в WUG? Мысли?

Иди и взгляни на linuxatemyram.com. WUG сообщает вам, что, по мнению Linux, используется (используется + буферы + кеш). То, что вы решили отслеживать (использованное / общее), мне кажется разумным, особенно для графика, поскольку он не требует знания специфики системы.

Свободный RAM - это свободный RAM, а буферы - это кэшированный RAM, который можно восстановить. Большинство инструментов мониторинга, которые я использовал, представляют эту разницу в графике совокупной площади, который представляет по крайней мере используемую, кэшированную и неактивную память, сложенную под 100% -ным уровнем и заменяющую их. Единственный способ получить правильное представление о том, как работает сервер, - это просмотреть их все.

Если вы можете изобразить только значение, я порекомендую вам изобразить используемую память, а остальное считаю «свободным». О, и я рекомендую также переключить инструменты мониторинга. Даже munin со стандартной конфигурацией имеет приличный график памяти.

Для тех (Ренан), которым интересно узнать, какое решение я придумал.

Я использовал собственный сценарий bash для извлечения памяти (использовано / всего), а затем конвертировал ее в процент.

#!/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

Затем я использую настраиваемый счетчик SNMP для выполнения этого сценария и возврата значения. В файле snmpd.conf это выглядит так:

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

Каждый сценарий exec возвращает несколько OID с такими вещами, как имя сценария, статус выхода, возвращаемое значение и так далее. К сожалению, возвращаемое значение является строкой, а не целым числом, поэтому у WUG есть некоторые проблемы с его графическим отображением (он по-прежнему отображает его, но графики в реальном времени не работают). Итак, в этом случае, когда мы знаем, что значение всегда будет меньше 100, я устанавливаю для него статус выхода, а затем опрашиваю этот OID.

Чтобы отслеживать это в WUG, создайте настраиваемый монитор производительности SNMP и отслеживайте OID статуса выхода этого сценария выполнения. Затем вы можете создавать собственные оповещения, а что нет.

Мы используем его уже некоторое время, и он отлично работает. Надеюсь, это поможет!

Я рекомендую ганглии: http://ganglia.sourceforge.net/

Он выполняет мониторинг памяти и делит ее на составные части. Конфигурации практически нулевая. Вы устанавливаете демон на каждый Linux-сервер, а затем назначаете один центральный ящик для записи RRD.

Вот пример графика памяти: