memIndex.0 = INTEGER: 0

memErrorName.0 = STRING: swap

memTotalSwap.0 = INTEGER: 216836

memAvailSwap.0 = INTEGER: 209784

memTotalReal.0 = INTEGER: 54156

memAvailReal.0 = INTEGER: 9320

memTotalFree.0 = INTEGER: 219104

memMinimumSwap.0 = INTEGER: 16000

memShared.0 = INTEGER: 0

memBuffer.0 = INTEGER: 5728

memCached.0 = INTEGER: 13832

memSwapError.0 = INTEGER: 0

memSwapErrorMsg.0 = STRING:

Наибольший интерес вызывают OID memTotalSwap mem AvailSwap, означающие общий размер свопа и его свободную часть. Затем стоит обратить внимание на memTotalReal и memAvailReal, указывающие на размер физической памяти. Перспективнее всего следить за memAvailReal и memAvailSwap. Но тут есть определенные проблемы. Дело в том, что исчерпание физической памяти еще не означает для системы каких-то ужасных последствий, все ненужное в данный момент будет складироваться в своп. Поэтому выводить предупреждения по поводу того, что физическая память закончилась, не стоит. Сервис, следящей за этим компонентом системы, должен выглядеть так:

define service{

 use    generic-service

 host_name   Linux

 service_description  Physical memory Free

 is_volatile   0

 check_period   24x7

check_command   check_snmp_oid!.1.3.6.1.4.1.2021.4.6.0!InK12345!""!""!kbytes!2c

 }

И соответственно мониторинг заполнения свопа можно реализовать так же. Но это решение, на мой взгляд, не очень изящно. Можно сделать гораздо лучше. Давайте будем следить за показателем memTotalFree, который показывает общее количество свободной памяти системы. Это весьма удобно, так как он равен сумме memAvailReal и memAvailSwap. Тут возникает некоторая проблема с нетривиальностью проверки. Обычно ситуация обстоит так, что чем больше проверяемая величина, тем ближе мы к критическому порогу, но сейчас все наоборот. Необходимо сказать модулю, что, чем больше памяти нам доступно, тем лучше. Поэтому сервис будет выглядеть так:

define service{

 use    generic-service

 host_name   Linux

 service_description  Total memory Free