Мы используем 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.
Вот пример графика памяти: