Home » Мониторинг » Zabbix » Мониторинг postfix в zabbix

Мониторинг postfix в zabbix

В данной статье я расскажу о том, как настроить мониторинг почтового сервера postfix с помощью zabbix. В сети есть много советов и готовых инструкций, и моя в этом плане не будет какой-то уникальной. Я вначале хотел придумать что-то свое, но потом плюнул и воспользовался готовым скриптом, просто потому, что он полностью отвечает на вопрос. Но добавил к нему несколько дополнительных проверок и метрик. Я попробую более подробно раскрыть тему и дать несколько своих советов и рекомендаций.

Онлайн-курс по устройству компьютерных сетей

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Введение

Если у вас еще нет почтового сервера, то читайте как установить и настроить почтовый сервер postfix, а если нет сервера мониторинга, то соответственно вот это - установка и настройка zabbix на centos или то же самое на debian. Для мониторинга я буду использовать известную утилиту pflogsumm, которая анализирует почтовый лог postfix. В разных системах он может называться по-разному:

  • /var/log/mail.log в debian и ubuntu
  • /var/log/maillog в centos и freebsd

Само содержание будет одно и то же, поэтому статья будет актуальна для любого сервера с postfix и любой версией мониторинга zabbix. Я за основу возьму bash скрипт, который чаще всего попадается, если в поисковике поискать что-то на тему мониторинга postfix в заббиксе. Не знаю, кто у кого его скопировал изначально, поэтому автора указывать не буду. Сам скрипт достаточно простой, я расскажу подробно что он делает и как работает, чтобы вы понимали и по возможности могли его изменить так, как вам потребуется.

Я буду показывать на примере системы CentOS. Нам понадобится установить утилиту pflogsumm. Делается это просто.

# yum install postfix-pflogsumm

Подготовка сервера к мониторингу

Выполним некоторые подготовительные действия на сервере. Для начала настроим ротацию лога postfix.

Настройка ротации лога maillog

По-умолчанию, за ротацию почтового лога отвечает конфигурационный файл /etc/logrotate.d/syslog. В нем не указан интервал, как часто происходит ротация, поэтому используется значение по-умолчанию из общего конфигурационного файла logrotate - /etc/logrotate.conf. Там интервал указан равный неделе.

Если вы посмотрите на время ротации, то сходу не будет понятно, почему используется именно это время. В разных системах оно будет разным. Различия будут даже в разных версиях centos. Например, в 5-й версии ротация будет запускаться следующим скриптом для cron - /etc/cron.daily/logrotate. Запускаться этот скрипт будет в соответствии с расписанием, указанным в файле /etc/crontab.

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

Таким образом, в CentOS 5 ротация лога maillog будет происходить раз в неделю в 4:02. Не самый удобный расклад.  Теперь посмотрим, в какое время эта же операция производится в CentOS 7 и как ее изменить. Здесь в /etc/crontab уже пусто, но есть другой файл /etc/cron.d/0hourly, в котором указано расписание запуска скриптов hourly

01 * * * * root run-parts /etc/cron.hourly

То есть каждую минуту. Теперь посмотрим, что в директории /etc/cron.hourly. Там есть файл 0anacron, который отвечает за запуск anacron, который, в свою очередь, отвечает за запуск ежедневных, еженедельных и ежемесячных задач. Интересующая нас задача лежит в /etc/cron.daily/logrotate. Посмотреть, когда она выполняется, можно в конфиге anacron - /etc/anacrontab.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days delay in minutes job-identifier command
1<----->5<----->cron.daily<----><------>nice run-parts /etc/cron.daily
7<----->25<---->cron.weekly<---><------>nice run-parts /etc/cron.weekly
@monthly 45<--->cron.monthly<--><------>nice run-parts /etc/cron.monthly

С такими данными получается, что ротация логов запускается, начиная с 3-х часов ночи, с максимальным сдвигом до 3:45 каждый день. То есть в любое время в этом промежутке. Ну а так как в самом logrotate указано, что ротация maillog происходит раз в неделю, она, соответственно, раз в неделю и происходит примерно в это время.

Для тех, кто будет настраивать мониторинг postfix в debian, сразу скажу, что там ротация логов настроена точно так же, как в CentOS 7 через anacron. Но запускается он по-другому. Время его запуска явно указано в файле /etc/cron.d/anacron, без лишних перенаправлений.

Я на распутывание этих клубков с ротацией логов тратил больше времени, чем на саму настройку мониторинга. Весь смысл в том, что мне кажется такая схема ротации неудобной. Особенно в нагруженных серверах. За неделю там такой лог огромный получается, что его невозможно быстро обработать. Мне больше нравится, когда логи ротируются раз в сутки примерно в 00:00. Так и статистику снимать удобнее, и анализировать логи. Настроим это.

Первым делом надо подправить конфиг logrotate и указать для maillog отдельные настройки с ежедневной ротацией. Делаем это.

# mcedit /etc/logrotate.d/syslog
/var/log/cron
/var/log/messages
/var/log/secure
/var/log/spooler
{
    missingok
    sharedscripts
    postrotate
	/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

/var/log/maillog
{
    daily
    missingok
    sharedscripts
    postrotate
	/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

Тут ничего придумывать не надо. Просто копируем в отдельный раздел настройки для /var/log/maillog и добавляем туда параметр daily. В разных системах стандартный конфиг для syslog будет разный. Нам его не обязательно менять, одного дополнительного параметра достаточно.

Теперь нужно настроить запуск anacron в полночь. В CentOS 7 редактируем конфиг /etc/anacrontab. Меняем 2 параметра:

RANDOM_DELAY=1
START_HOURS_RANGE=0-1

Параметры для cron.daily не трогаем. В итоге anacron будет запускать скрипты cron.daily в интервале с 0 до 1 часа, с задержкой 5 минут от полуночи и с максимальным разбросом этой задержки в 1 минуту. То есть примерно в 0:04-0:06.

В Debian 7 и 8 для такого же результата достаточно просто изменить время запуска anacron в файле /etc/cron.d/anacron.

0 0    * * *   root test -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d anacron start >/dev/null

Все. Настроили нормальную ротацию логов. Теперь можно обрабатывать эти логи и снимать статистику. Описанные выше настройки не обязательны, все будет работать и без них. Но так удобнее.

Проверка работы pflogsumm

Снимать параметры системы мы будем с помощью pflogsumm, поэтому для начала проверим, как она работает и какую информацию выводит. Для этого запускаем ее с такими ключами:

# pflogsumm -d yesterday -h 0 -u 0 --bounce_detail=0 --deferral_detail=0 --reject_detail=0 --smtpd_warning_detail=0 --no_no_msg_size /var/log/maillog

Если получите ошибки на некоторые ключи, попробуйте вариант для более старой версии:

pflogsumm -d yesterday -h 0 -u 0 --no_bounce_detail --no_deferral_detail --no_reject_detail --no_smtpd_warnings --no_no_msg_size /var/log/maillog

Вы должны получить примерно такой вывод:

Вывод pflogsumm на почтовом сервере postfix

Я использую параметр yesterday, так как проверяю в системе, где еще не настроена ротация логов, и в maillog находится информация за последние несколько дней. Если у вас ночью была ротация файлов, то информации за вчера там уже нет, получите на выходе нули. Так что правильно указывайте либо параметр, либо лог файл.

Значения из первой части отчета мы и будем передавать в zabbix для сбора статистики. Если у вас нормально отрабатывает pflogsumm, можно дальше переходить к настройке мониторинга в zabbix.

Сразу сделаю важное замечание. Значения полученных и доставленных писем не будут соответствовать реальному количеству писем, если у вас есть какие-либо дополнительные обработчики писем, работа которых приводит к повторному появлению упоминания о письме в почте. К этому могут приводить антиспам системы, антивирусы, может быть что-то еще. У вас будут задваиваться или затраиваться упоминания в логе об одном и том же письме.

Эти значения имеют смысл, только если вам нужны абсолютные значения для статистики. Для мониторинга это не принципиально, так как важна будет динамика изменений, а не точные цифры. Мониторинг должен будет отреагировать на существенное увеличение количества писем относительно средних параметров за прошлые периоды. Каковы же были эти значения, не принципиально.

Настройка zabbix агента

Теперь напишем скрипт, который будет парсить вывод pflogsumm и передавать его в zabbix. Создадим папку для скриптов, если у вас ее нет и положим туда скрипт.

# mkdir /etc/zabbix/scripts
# mcedit /etc/zabbix/scripts/postfix.sh
#!/bin/bash

export LC_ALL=""
export LANG="en_US.UTF-8"
#
if [[ -z "$1" ]]; then
  exit 1
fi
##### PARAMETERS #####
MAILQ=$(which mailq)
PFLOGSUMM=$(which pflogsumm)
MAILLOG="/var/log/maillog"
METRIC="$1"
CACHE_TTL="1740"
CACHE_FILE="/tmp/zabbix.postfix.cache"
EXEC_TIMEOUT="4"
NOW_TIME=`date '+%s'`
##### RUN #####
if [ "$METRIC" = "queue" ]; then
  TEMP_DATA=`${MAILQ} 2>&1 | tail -n1`
  if echo "${TEMP_DATA}" | grep -iq "Mail queue is empty"; then
    echo 0
  elif echo "${TEMP_DATA}" | grep -iPq "in\s+\d+\s+request"; then
    echo "${TEMP_DATA}" | sed -e 's/.*in\s\+\([0-9]\+\)\s\+request.*/\1/gI' 2> /dev/null | head -n1
  else
    # Error
    echo 65535
  fi
  exit 0
else
  if [ -s "${CACHE_FILE}" ]; then
    CACHE_TIME=`stat -c"%Y" "${CACHE_FILE}"`
    DELTA_TIME=$((${NOW_TIME} - ${CACHE_TIME}))
    if [ ${DELTA_TIME} -lt ${EXEC_TIMEOUT} ]; then
      sleep $((${EXEC_TIMEOUT} - ${DELTA_TIME}))
    elif [ ${DELTA_TIME} -gt ${CACHE_TTL} ]; then
      echo "" >> "${CACHE_FILE}" # !!!
      DATE_TO=`date +%d\ %H:%M:%S`
      DATE_FROM=`date -d @${CACHE_TIME} +%d\ %H:%M:%S`
      DATA_CACHE=`sudo cat ${MAILLOG} | sed -e 's/^\([a-zA-Z]\{3\}\s\)\s\([0-9]\s\)/\10\2/g' | awk '$2" "$3>=from && $2" "$3<=to' from="${DATE_FROM}" to="${DATE_TO}" | ${PFLOGSUMM} -h 0 -u 0 --bounce_detail=0 --deferral_detail=0 --reject_detail=0 --smtpd_warning_detail=0 --no_no_msg_size 2>&1`
      echo "${DATA_CACHE}" > ${CACHE_FILE} # !!!
      chmod 640 ${CACHE_FILE}
    fi
  else
    echo "" > ${CACHE_FILE} # !!!
    exit 0
  fi
  awk "BEGIN{IGNORECASE=1} /${METRIC}/ {print \$1}" ${CACHE_FILE} | awk '{print $1}' | awk '/k|m/{p = /k/?1:2}{printf "%d\n", int($1) * 1024 ^ p}' | head -n1
fi
exit 0
# chown root:zabbix /etc/zabbix/scripts/postfix.sh
# chmod 750 /etc/zabbix/scripts/postfix.sh

Данный скрипт берет текущее время, проверяет время последнего запуска скрипта, выделяет из почтового лога только тот интервал, что попадает в этот отрезок времени и анализирует его. Очень удобная задумка и простая реализация. Я изначально до такого не додумался и анализировал весь лог. Когда увидел этот скрипт, решил взять за основу для своего мониторинга.

Позволяем пользователю zabbix, от которого работает мониторинг, запускать команды из скрипта. Для этого запускаем visudo и добавляем следующие строки в /etc/sudoers.

zabbix ALL=(ALL) NOPASSWD: /bin/cat /var/log/maillog
zabbix ALL=(ALL) NOPASSWD: /usr/sbin/pflogsumm
zabbix ALL=(ALL) NOPASSWD: /usr/bin/mailq

Далее создадим кэш файл для проверки работы скрипта с заведомо старой датой

# sudo -u zabbix touch /tmp/zabbix.postfix.cache
# echo "" >> /tmp/zabbix.postfix.cache
# sudo -u zabbix touch -m -d '2010-01-01 22:22' /tmp/zabbix.postfix.cache

Остановлюсь подробнее на этом кэше. В скрипте есть параметр CACHE_TTL, установленный в 1740 секунд = 29 минут. Это чуть меньше, чем интервал обновления элементов данных на сервере zabbix - 30 минут. Кэш нужен для того, чтобы лишний раз не выполнять работу скрипта в тех ситуациях, когда по какой-то причине, например во время отладки, вы постоянно проверяете значения. Если еще не прошло 29 минут с момента последнего запуска скрипта, данные будут взяты из кэш файла zabbix.postfix.cache. Имейте это ввиду. Если вы заходите изменить интервал обновления с 30 минут, на 15, то не забудьте изменить время кэша на 14,5 минут.

Сразу расскажу о куче подводных камней и нюансах при использовании данного скрипта на разных системах. Вам в любом случае необходимо будет все проверить, прежде чем запускать сбор статистики в zabbix. Первым делом проверьте вывод команды mailq. Например, в CentOS 7 и Debian 7 в случае пустой очереди он будет таким:

# mailq
Mail queue is empty

Под такой вывод настроен текущий пример скрипта. А, к примеру, в CentOS 5 у меня вывод такой:

# mailq
/var/spool/mqueue is empty
Total requests: 0

Скрипт в текущем виде уже не подходит. Ту часть, что отвечает за проверку очереди сообщений, нужно изменить и привести к такому виду:

TEMP_DATA=`${MAILQ} 2>&1`
if echo "${TEMP_DATA}" | grep -q "/var/spool/mqueue is empty"; then

Остальное не трогаем. Дальше может такая проблема возникнуть. В той же CentOS 5 mailq никак не хочет запускаться под пользователем zabbix. Получаю ошибку, даже если настраиваю права в sudoers.

# sudo -u zabbix mailq
can not chdir(/var/spool/mqueue/): Permission denied
Program mode requires special privileges, e.g., root or TrustedUser.

Не стал долго разбираться, как это исправить, так как сходу решения не придумал. Пришлось запускать zabbix-agent под пользователем root. Для этого в /etc/zabbix/zabbix_agentd.conf укажите параметры:

AllowRoot=1
User=root

И перезапустите агент.

Вместо mailq можно использовать команду:

# postqueue -p

Я не разбирался подробно, в чем разница, но на некоторых системах mailq мне показывала пустую очередь, а postqueue корректно отображала ее. В общем, в каждом конкретном случае нужно разобраться отдельно и убедиться, что все корректно работает.

Так же рекомендую установить параметр в zabbix Timeout в максимальное значение 30. Обработка почтового лога pflogsumm может длиться несколько секунд. По-умолчанию, zabbix ждет 3 секунды ответа скрипта. Если за это время pflogsumm не обработает лог, заббикс получит ошибку. Обязательно время ожидания надо увеличить, так как 3 секунды очень мало.

Нужно это сделать и на агенте, и на сервере. Я иногда забываю отредактировать конфиг сервера, а потом долго разбираюсь, почему не работает. В явном виде вы нигде не увидите ошибки ожидания по таймауту. Вместо этого хост будет уходить в оффлайн во время проверки длинных метрик, а потом сразу же возвращаться.

Если у вас будут ошибки вот на эти конструкции:

MAILQ=$(which mailq)
PFLOGSUMM=$(which pflogsumm)

то укажите пути к программам явно сами, например вот так:

MAILQ="/usr/bin/mailq"
PFLOGSUMM="/usr/sbin/pflogsumm"

И проверьте имя лог файла:

MAILLOG="/var/log/maillog"

В разных системах он имеет разное имя. Проверить работу скрипта можно следующим образом:

# sudo -u zabbix /etc/zabbix/scripts/postfix.sh queue
# sudo -u zabbix /etc/zabbix/scripts/postfix.sh received

В выводе вы должны видеть цифры, либо 0. Если в выводе пусто, разбирайтесь, в чем проблема. Посмотрите содержимое кэш файла /tmp/zabbix.postfix.cache. Если в pflogsumm есть какие-то ошибки, вы увидите вывод команды в файле. Если под пользователем zabbix никак не хочет работать, проверьте сначала под root, просто запуская команды:

/etc/zabbix/scripts/postfix.sh queue
/etc/zabbix/scripts/postfix.sh received

После того, как убедитесь, что все работает, добавляем новые метрики в zabbix-agent. Для этого создаем файл с userparameters.

# mcedit /etc/zabbix/zabbix_agentd.d/userparameter_postfix.conf
UserParameter=postfix.received-full,pflogsumm -h 0 -u 0 --bounce_detail=0 --deferral_detail=0 --reject_detail=0 --smtpd_warning_detail=0 --no_no_msg_size /var/log/maillog | grep received | awk 'NF == 2' | awk '{print $1}'
UserParameter=postfix.delivered-full,pflogsumm -h 0 -u 0 --bounce_detail=0 --deferral_detail=0 --reject_detail=0 --smtpd_warning_detail=0 --no_no_msg_size /var/log/maillog | grep delivered | awk 'NF == 2' | awk '{print $1}'
UserParameter=postfix[*],/etc/zabbix/scripts/postfix.sh "$1"

Первые 2 ключа это просто накапливающиеся в течении всего дня значения полученных и доставленных писем. Значения получаю напрямую, выполняя подходящий запрос. Эти запросы будут актуальны в таком виде, только если вы настроите ротацию почтового лога раз в сутки в полночь. Если это не так, то используйте ключ -d today. Третий параметр собирает раз в 30 минут метрики от скрипта, показывая значения за последние 30 минут.

Перезапускайте агент и проверяйте, как он отдает значения.

# zabbix_agentd -t postfix[rejected]
 postfix[rejected] [t|3]
 # zabbix_agentd -t postfix.delivered-full
 postfix.delivered-all [t|15528]
 # zabbix_agentd -t postfix.received-full
 postfix.received-all [t|9511]
 # zabbix_agentd -t postfix[queue]
 postfix[queue] [t|0]
 # zabbix_agentd -t postfix[rejected]
 postfix[rejected] [t|3]

Только после того, как убедитесь, что все значения корректно возвращаются, можно переходить к настройке на zabbix сервере.

Настройка мониторинга postfix на zabbix сервере

Тут вам ничего настраивать не придется, так как я уже сделал готовый шаблон, который просто нужно будет импортировать и назначить нужным хостам. Вот сам шаблон - template_postfix.xml

Расскажу подробнее об элементах данных и триггерах в этом шаблоне. Во-первых, в шаблоне в триггерах используются макросы для определения максимальной длины очереди и отклоненных писем. После превышения, указанных в макросе значений, высылаются уведомления. Задать значения макросов можно либо в самом шаблоне, тогда значения для всех хостов будут одинаковые, либо в каждом отдельном хосте указываете свои значения. Я советую выставлять значения макросов на каждом хосте отдельно, подбирая оптимальное значения для каждого сервера. Делается это в свойствах хоста, в разделе Макросы.

Настройка макросов для мониторинга postfix

В моем примере я установил значения макросов {$MAIL_DEFERRED} и {$MAIL_QUEUE} равными 10. Эти значения подобрал экспериментальным путем после нескольких дней работы мониторинга. Вообще, настроить сразу мониторинг почтового сервера не получится. Он требует длительной калибровки. Везде будут разные средние и максимально допустимые значения.

Вот список элементов данных в шаблоне:

Список элементов данных в шаблоне

Список настроенных триггеров:

Триггеры для мониторинга postfix

Расскажу подробнее об активных триггерах. Этот список состоит из всего полезного, что я нашел в интернете, плюс несколько моих триггеров. В существующих шаблонах, что мне попадались, я исправил некоторые условия, так как в них были ошибки и ложные срабатывания. Получилась моя собственная калькуляция, которую я некоторое время тестировал на живом активном сервере, прежде чем написать статью и поделиться с вами.

Триггеры проверки работы сервисов:

  • Postfix: IMAP service is unreachable on {HOST.NAME} - стандартная проверка работы сервиса на определенном tcp порту. В данном случае это imap сервис и 143 порт.
  • Postfix: SMTP service is unreachable on {HOST.NAME} - то же самое, только smtp порт 25.
  • Postfix: Mail queue is much on {HOST.NAME} - проверка количества писем в почтовой очереди. Если минимальное значение за последние 3 минуты выше заданного в макросе $MAIL_QUEUE, то срабатывает триггер. Сам элемент данных проверяется каждую минуту. Сделаны 3 разных триггера с разными порогами срабатывания. В принципе, тут может быть достаточно и одного триггера, но я для примера оставил все три.
  • Postfix: Mail deferred is much on {HOST.NAME} - триггер срабатывает, если количество отклоненных писем превышает значение, установленное в макросе $MAIL_DEFERRED. Это значение подбирается опытным путем. Проверка отклоненных писем и почтовой очереди самые эффективные для определения массовой рассылки спам писем с вашего сервера. Это может случиться, если пароль одного из ящиков уйдет к злоумышленникам. Ситуация эта достаточно частая. Во время отладки этого мониторинга, я как раз столкнулся с такой ситуацией и убедился, что рост значения deferred однозначно указывает на наличие какой-то проблемы. Когда вас взломают, вы получите примерно такую картинку. Динамика параметра deffered при взломе сервераАдминистратор указал при создании тестового ящика пароль 123456 и ночью его подобрали. Утром я встал и сразу все понял, просто посмотрев мониторинг.
  • Postfix: pickup is not running on {HOST.NAME} - данный триггер контроллирует стандартный элемент данных, который получает информацию о работающем процессе на линукс сервере. Везде, где я видел шаблоны для мониторинга postfix, использовалась стандартная проверка работы сервиса - 0 или 1 в последнем полученном значении. Опытным путем я выяснил, что такая проверка дает много ложных срабатываний со службой pickup. Она запускается и работает ограниченное кол-во времени, потом завершается и запускается новый экземпляр. В мониторинг время от времени попадает информация о том, что сервис не работает, но в этом нет ошибки. Я сделал проверку трех последних состояний сервиса, и только в том случае, если все 3 проверки выявили неработающую службу, то будет оповещение. Остальные службы мониторятся просто последним значением. Они всегда должны быть запущены.
  • Postfix: Mail delivered is much on {HOST.NAME} - этот триггер следит за количеством доставленных писем за последний час. Если их будет в 5 раз больше, чем часом ранее, то сработает оповещение. Этот триггер помогает следить за тем, что происходит на сервере. Если писем стало слишком много, стоит обратить на это внимание. Значение в 5 раз подобрано опытным путем. Возможно, в вашем случае будет уместно использовать другое значение. Тут только нужно понимать, что это за письма. Pflogsumm просто анализирует лог файл postfix. Значение delivered может расти, к примеру, если будут массовые рассылки. Кто-то сделает пару рассылок на весь офис, в котором 100 человек и вы сразу получите значение delivered 200. Если в предыдущем часе массовых рассылок не было, то значение delivered может быть в районе 20-30. Сразу получите сработавший триггер, который по сути не указывает на какую-то проблему. Так что калибруйте этот параметр в зависимости от ваших условий. В принципе, триггеры на queue и deferred достаточно четко фиксируют проблему на сервере, так что от этого триггера можно и отказаться. Привожу для примера, сами подумайте, как его использовать. Возможно, удобнее было бы использовать значение received для триггера, либо использовать и то и другое.

Описал ключевые значения мониторинга, на которые стоит реагировать. Возможно, я что-то упустил или сделал лишнее. Буду рад любым полезным и информативным замечаниям в комментариях. Вместе мы сможем более эффективно настроить мониторинг postfix. Может кто-то знает более информативные и удобные шаблоны, которые просто мне не попадались.

При написании триггеров, использовал описание функций триггеров из оригинальной документации.

Заключение

Мониторинг почтового сервера postfix нетривиальная и ответственная задача. Почтовые сервера постоянно находятся в зоне повышенного внимания со стороны злоумышленников, которые непрерывно пытаются найти уязвимые места и использовать ваш сервер для рассылки спама.

Ко всему прочему, сервис почтовых сообщений является критически важным сервисом, на который завязана работа многих организаций. Все это накладывает особую ответственность на администраторов почтовых серверов. Без хорошего мониторинга тут никак не обойтись.

Надеюсь, моя статья поможет вам повысить эффективность администрирования почтового сервера. Буду рад замечаниям, советам и информации о собственном опыте в мониторинге почты, в частности postfix. Хотя опыт других серверов тут тоже применим. Zabbix универсальный инструмент, на котором можно реализовать практически любые проверки.

Онлайн-курс по устройству компьютерных сетей.

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

47 комментариев

  1. Александр

    CentOS 8, Zabbix server 6.2.0 - настроил, под свои задачи адаптировал, все замечательно.
    Владимир, спасибо большое!

  2. Александр

    Благодарю за статью!
    CentOS 8, после ротации maillog ведется в старый переименованный/удаленный файл, новый maillog пустой. После перезапуска службы syslog (systemctl restart syslog.service) лог начинает вестись. Вообщем, как выяснилось, вставил из статьи блок касающийся ротации maillog целиком и не глядя. Закоментированная строка причина некорректной работы
    -------
    cat /etc/logrotate.d/syslog

    /var/log/cron
    /var/log/messages
    /var/log/secure
    /var/log/spooler
    {
    missingok
    sharedscripts
    postrotate
    /usr/bin/systemctl -s HUP kill rsyslog.service >/dev/null 2>&1 || true
    endscript
    }
    /var/log/maillog
    {
    daily
    missingok
    sharedscripts
    rotate 10
    compress
    postrotate
    # для CentOS8
    /usr/bin/systemctl -s HUP kill rsyslog.service >/dev/null 2>&1 || true
    # для CentOS7
    # /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
    }

  3. Василий

    Добрый день!
    Только начал изучать zabbix, решаю небольшие задачи. Сервер Ubuntu на нем сайт с формой обратной связи, данные с нее приходят на почтовый ящик, установлен postfix. Zabbix должен будет проверять наличие почты, отправленной через форму обратной связи. Записывать её в файл и загружать на FTP. Нашел вашу статью, но пока для меня сложно. Направьте в нужном направлении. Спасибо!

  4. Замечательная статья, автору респект.
    Пробую прикрутить на openSUSE. Проблема в том, что логи пишет journalctl.
    Пробую реализовать journalctl --since=today -u postfix | pflogsumm -h 0 -u 0 --bounce_detail=0 …….
    Есть вопрос к автору. Pflogsumm считает одно письмо за 3. т.к. к постфиксу прикручен spamassassin и amavis. НЕ могу придумать как это побороть.

    • Сталкивался с проблемой задваивания и затраивания писем из-за дополнительных обработчиков. В свое время так ее и не решил. Простого способа не знаю. Каким-то образом предобработку на bash надо делать, а потом уже обработанный лог отдавать pflogsumm.

  5. Сергей

    Спасибо за статью.
    При реализации столкнулся с такой проблемой:
    # zabbix_agentd -t postfix.delivered-full
    postfix.delivered-full [t|Unknown option: bounce_detail
    Unknown option: deferral_detail
    Unknown option: reject_detail
    Unknown option: smtpd_warning_detail
    usage: pflogsumm.pl -[eq] [-d ] [-h ] [-u ]
    [--verp_mung[=]] [--verbose_msg_detail] [--iso_date_time]
    [-m|--uucp_mung] [-i|--ignore_case] [--smtpd_stats] [--mailq]
    [--problems_first] [--rej_add_from] [--no_bounce_detail]
    [--no_deferral_detail] [--no_reject_detail] [--no_no_msg_size]
    [--no_smtpd_warnings] [--zero_fill] [--syslog_name=name]
    [file1 [filen]]

    Не подскажете в чем может быть проблема?

    • Так трудно сказать. Что-то напутано в настройках или скриптах. Попробуйте все отладить сначала без zabbix, в bash. А потом уже в мониторинг переносить.

  6. Статья актуальна. Только что по ней настроил мониторинг почтового сервера на Centos 8.

  7. Практичней испльзовать https://github.com/aadz/mlogtail который работает в реальном времени и не надо постоянно запускать pflogsum, чтобы вычитать хвост лога.

  8. Хорошая статья, все получилось кроме пары нюансов.
    Тригеры которые отвечаю за проверку работы smtp и imap в ответ на запрос получают 0 тем самым вылазит проблемачтоэти сервисы не запущенны.
    Вот что я получаю если делаю запрос с zabbix сервера:
    # zabbix_get -s agent.host -k net.tcp.service[smtp]
    0
    # zabbix_get -s agent.host -k net.tcp.service[imap]
    0
    SELinux на сервер почты отключен. срабатывает только если заменить service на listen и соответственно вместо [smtp] писать порт [465]:
    # zabbix_get -s agent.host -k net.tcp.listen[465]
    1
    Подскажите куда копать?

    • Оставьте так, как работает. Я не помню точно, какие порты в Zabbix указаны в качестве smtp и imap порта. Скорее всего 25 и 143. Если у вас другие порты, то укажите их вручную, как вы и сделали.

      • То что порт другие это не проблема. Меня куда больше интересует почему на запрос допустим (порты неважно какие):
        # zabbix_get -s agent.host -k net.tcp.service[465]
        Возвращает 0
        А вот при запросе (тут тоже неважно какие порты):
        # zabbix_get -s agent.host -k net.tcp.listen[465]
        Возвращает 1
        Сделал проверку работы https:
        # zabbix_get -s 195.54.14.68 -k net.tcp.service[https]
        Возвращает 1
        Т.е. конструкция net.tcp.service не срабатывает как для smtp и imap. А вот конструкция net.tcp.listen работает.

        • Правильно проверку на нестандартном порту в общем случае делать вот так:
          zabbix_get -s agent.host -k net.tcp.service[smtp,,465]
          Подробнее тут - https://www.zabbix.com/documentation/4.0/ru/manual/config/items/itemtypes/simple_checks
          Там же по ссылке есть пометка:

          "Проверка шифрованных протоколов (таких как IMAP на 993 порту или POP на 995 порту) в настоящее время не поддерживается. Как решение, пожалуйста, для подобных проверок используйте net.tcp.service[tcp,,порт]."

          Подозреваю, что для шифрованного smtp проверка тоже не будет работать. Проверять надо так:
          zabbix_get -s agent.host -k net.tcp.service[tcp,,465]

          В случае локальных проверок через агента на том же сервере, я так понимаю, что разницы между net.tcp.service[tcp,,465] и net.tcp.listen[tcp,,465] не будет.

          • После безуспешных попыток докопаться до истины, решил для обоих проверок запросы для imap и smtp написать так:
            net.tcp.listen[993]
            net.tcp.listen[465]
            Еще раз огромное спасибо за статью!

  9. Лучше просто лог тэйлить и считать/показывать счетчики, которые насчитались - https://github.com/aadz/mlogtail

    • Можно и так, но сходу не могу оценить, как будет удобнее. Это совсем другой подход. Разные метрики получаются. Можно комбинировать.

      • Те же метрики получаются, что и у pflogsumm, плюс еще и трафик входящих/доставленных байтов считается так же. на pflogsumm и тестировалось, хотя подход и регулярные выражения - разные. Это да. Просто файл не дергают постоянно, порождая кучу процессов, а просто читают и отдают счпетчикию

      • А вот комбинировать - я бы вряд ли стал. :)

  10. Андрей

    Спасибо. Отличная статья. Настроил без особых проблем. Debian 8.

  11. Приветствую, отличная статья. сделал все как написано затык случился на скрипте. при параметре queue выдает 65535. это я так понимаю ошибка. подскажите как исправить? centos 7/ zabbix 4/

    • Смотреть скрипт надо и проверять команду напрямую в консоли, которая очередь показывает, смотреть, что выводит.

  12. Сегодня вот осенила у меня одна мысль) А можно ли заставить zabbix мониторить размер писем. Никто не озадачивался?

    • В каком виде это должно быть в заббиксе? А главное, зачем это? Через почтовый сервер проходят тысячи и десятки тысяч писем в сутки. Если информацию о них хранить в заббиксе, то его база будет огромных размеров и для нормальной работы понадобятся большие мощности. Заббикс для этой задачи не подходит совершенно. А так, конечно, это реально.

      Можно написать скрипт, который будет проверять размер каждого письма, а затем передавать эту информацию в ELK Stack - https://serveradmin.ru/ustanovka-i-nastroyka-elasticsearch-logstash-kibana-elk-stack/
      В таком виде это имеет право на жизнь.

      • У меня идет война с моими юзверами(( Не хотят почту чистить, сервер забит в ноль. Устал уже ругаться в кабинете директора со всеми. Хочу более развернуто мониторить почтовик, во первых статистику по получателям и адресатам, т.е. куда и откуда более всего по конкретному пользователю ходит почта. Так же вчера подумал, а можно ли ткнуть их носом в размер писем, т.е. сколько за день у каждого забивается почтовик. Можно сделать скрипт который будет каждый день срезать размер директории с письмами и собирать ее, но это не совсем то. В общем думаю что еще можно накрутить в мониторинг что бы было чем заставить их чистить почтовик

        • Странная ситуация. У вас что, директор неадекват? Первый раз такое вижу. Если места для почты нет, то надо что-то сделать. У меня никогда не было ситуации, когда нельзя убедить руководителя в проблеме. Если только вы сами что-то недоговариваете. И ругаться, конечно, нет смысла, это неконструктивно.

          Статистику по переписке можно получить с помощью pflogsumm. Посмотрите на него внимательно, он даст почти всю информацию, которую вы хотите получить.

          Я, в принципе, вижу проблему и она у вас не технического характера. Вам зачем-то нужно убеждать руководство, пользователей, делая для этого отдельный мониторинг. Не для себя, а для того, чтобы других убеждать. По какой-то причине ваши слова пустое место для всех остальных. Просто советую подумать об этом и сделать выводы.

          • У меня Гос.унитарное предприятие и экономим на всем, в общем на железо денег не дают. А вот с пользователями из-за нового директора стало совсем худо. Как он говорит ему надо чтобы сотрудникам было удобно работать и если что-то надо то я должен делать, даже если это физически не реально. В общем он полный бардак у нас навел. У нас тех службу и хоз службу держат за пустое место и это вина руководства, при предыдущем директоре таких проблем не было.

            pflogsumm действительно дает, но визуализировать надо, он же в текст пишет в основном.

            • Те данные, что дает pflogsumm, можно передавать в zabbix для визуализации. Текущая статья как раз об этом. Но реально, это все пустое. Вы заморочитесь, но физическую проблему с местом это не решит.

              Я бы поступил так в вашем случае:
              1. Первым делом ограничил бы максимальный размер письма 20-ю мегабайтами. Это нормальная, общераспространенная практика. По-моему опыту без этого невозможно ограничить почтовые архивы разумными рамками. Пользователи начинают пересылать большие файлы и это не остановить.
              2. Написал понятную инструкцию с картинками по очистке почтового ящика самим пользователем. В инструкции бы обратил внимание на сортировку писем с вложениями по объему. Рассказал бы, как сохранить вложение на сетевой диск, где оно будет в полной сохранности, так как диски бэкапятся, в отличии от почтового ящик (маленькая хитрость).
              3. Собрал размер всех ящиков и посмотрел на самых больших. Что занимает больше всего места. Настроил бы еженедельную проверку размера ящиков, чтобы следить за динамикой, а так же чтобы понимать, кто больше всего занимает места.
              4. Настроил на сервере регулярную автоочистку папок для спама и корзин. У меня тоже есть статья на эту тему.
              5. Написал бы письменно директору с обозначением проблемы и списком мер для решения проблемы (очистка ящиков, ограничение на размер ящика, покупка дисков и т.д.). Если меры приняты не будут, то ты не можешь гарантировать стабильную работу почтового сервера

              В общем, тут надо подходить комплексно и с головой, а не воевать с пользователями. Худой мир лучше доброй войны. Можно разок плановый коллапс устроить и ручками аккуратно поломать почту, а потом сказать, что это будет происходить регулярно, если ничего не предприянть.

  13. Светлана

    Добрый день. Не могу шаблон загрузить.
    Детали
    Не удалось прочитать XML: (68) StartTag: invalid element name [Строка: 939 | Колонка: 62].

  14. С заббикс-сервера возвращает ноль:
    $ zabbix_get -s postfix -k postfix.received-full
    0
    копаю дальше

  15. Template Postfix: Postfix: Received Day postfix.received-full 600 90d 365d Zabbix агент Postfix Активировано
    Template Postfix: Postfix: Delivered Day postfix.delivered-full 600 90d 365d Zabbix агент Postfix Активировано

  16. В какую сторону копать, если

    $ zabbix_agentd -t postfix.received-full
    postfix.received-full [t|2543]
    $ zabbix_agentd -t postfix.delivered-full
    postfix.delivered-full [t|5365]

    а в заббиксе в Последних данных Postfix: Received Day и Postfix: Delivered Day нулевые?

    • Начать с того, что посмотреть на сами итемы в узле сети. В каком они состоянии. Возможно, там будет указано, что итем не активен и сама ошибка будет названа.

  17. Один триггер криво работает в шаблоне и вроде я понял почему)
    {post:postfix[delivered].sum(3605)} > {post:postfix[delivered].sum(3605,3605)}*5

    Если я правильно понял, то правая часть считает кол-во писем за предыдущий час, т.е. отматывает 3605 секунда назад и считает кол-во за 3605 секунд (предыдущий час). И всё бы хорошо, но если писем было ноль в предыдущем часу, то помноженный он на 5 - это никак не в 5 раз больше писем за прошедший час, в котором, к примеру, было только одно письмо.

    • Да, верно, я это не учел. У меня нет почтовых серверов, где за час не было ни одного письма :) Все никак не прикручу мониторинг, который будет раз в 5 минут отправлять реальное письмо и проверять, появилось ли оно в папке. А то уже не раз бывали ситуации, когда по мониторингу все ОК, но почта не ходит по какой-то причине. Увидеть это можно только, если отправляешь живое письмо. Тогда наверняка будешь знать, работает почта или нет. Все остальное не так надежно. Тогда проблемы с нулем писем в этом триггере не будет, так как мониторинг сам писем наотправляет.

      • Проверять в папке "Отправленных" имеется в виду?
        Можно сделать триггер аналогично, если отправленных писем в принципе не будет за какое-то время.

        • Не обязательно в отправленные. Оно может отправиться, но не прийти на сервер по какой-то причине. Нужно отправлять и проверять письмо именно во входящих адресата. Тогда точно можно знать, что почта доходит. Хотя можно отдельно прием и отправку проверять. В принципе, это два разных процесса и они могут независимо друг от друга сломаться. Имеет смысл и то и другое проверять.

  18. Шаблон сделан для zabbix версии 3.2 в 3.0 не импортируется уже. Есть вариант добавления для более старых версий или надо всё вручную вбивать?

    • Не могу ничего посоветовать. Не осталось версий, ниже 3.2. Проще всего, мне кажется, обновиться. Там нет никаких проблем с обновлением.

  19. Ребят, помогите, может кто сталкивался. Пытаюсь настроить все по мануалу, но в итоге в логах вижу следующее:
    1410:20170826:075731.827 item "elektron:postfix[queue]" became not supported: Unsupported item key.
    1409:20170826:080322.103 item "elektron:postfix.delivered-full" became not supported: Unsupported item key.
    И т.д.

    В самом Заббиксе, в последних данных все параметры типа Postfix: bytes delivered серого цвет и данных нет.

    Подскажите, куда глянуть, что может быть причиной.

    • Скрипт не отрабатывает по какой-то причине. Нужно пробовать его запускать от пользователя zabbix, смотреть, чтобы прав на все хватало. Либо в самом скрипте ошибка и в выводе не цифры, а что-то другое.

      В общем случае эта ошибка означает, что сервер заббикса получает не цифровые значения, а что-то другое. Нужно разбираться, что конкретно.

  20. Отличная статья.
    Все по полкам разложил.
    Настроил на своем сервере под Centos 6.4.
    Затык произошел при настройке доступа пользователя, от которого запускается Zabbix к лог файлу Postfix'а:

    zabbix ALL=(ALL) NOPASSWD: /bin/cat /var/log/maillog - это через sudoers не заработало.

    Немного поискав, сделал через доп настройку в logrotate:
    postrotate
    /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    /bin/chmod 640 /var/log/maillog
    /bin/chown :zabbix /var/log/maillog
    endscript

    Таким образом у юзера zabbix есть права на чтение лога.

    Плюс ко всему, при проверке скрипта, postfix.sh результат выдавал только с ключом queue, остальные ключи [received/rejected/...] ничего не возвращали.
    Разобрал скрипт и выполнив его покомандно в баше нашел, что строка:

    DATA_CACHE=`sudo cat ${MAILLOG} | sed -e 's/^\([a-zA-Z]\{3\}\s\)\s\([0-9]\s\)/\10\2/g' | awk '$2" "$3>=from && $2" "$3&1`

    возвращает:
    -bash: /usr/sbin/pflogsumm: Нет такого файла или каталога

    решилось удалением символа "\" перед ${PFLOGSUMM} -h 0 ...

    • Да, нюансов может быть много. Я сам постоянно разбираюсь с разными ситуациями на разных серверах. Поэтому постарался расписать все подробно, чтобы можно было самостоятельно дебажить работу. В готовом виде универсальный инструмент тут не подготовить, надо на месте разбираться.

  21. Аноним

    Неплохо, может есть аналог настройки мониторинга для exim ?

    • Надо смотреть, какой там формат лога, и парсить его. Я не знаком с Exim совсем. Триггеры для примера можно взять из этой статьи, мониторинг сервисов и служб тоже. Статистику только переделывать придется.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar