Анализ работы почтовой системы с помощью Mailgraph [2009]
Введение
Эта коротенькая заметка посвящена установке и настройке Mailgraph – простого в настройке и использовании,
но очень полезного, на мой взгляд, инструмента, позволяющего оценить величину
потока сообщений, проходящих через почтовую систему на базе
Postfix, в различные моменты времени. Отчет Mailgraph содержит четыре группы
графиков для таких интервалов времени, как Last Day (предыдущие
сутки), Last Week (предыдущая неделя), Last Month
(предыдущий месяц) и Last Year (предыдущий год). Каждая группа
состоит из двух графиков, первый из которых отображает количество
Sent (отправленных) и Received (принятых), а второй –
количество Bounced (не доставленных), Viruses
(содержащих вирусы), Spam (расцененных как СПАМ) и
Rejected (отвергнутых) сообщений. Для получения данных Mailgraph
использует лог Postfix, для хранения базы данных и отображения графиков – RRDtool, другими словами Mailgraph является
front-end’ом Postfix к RRDtool. Ниже показан пример
графиков за предыдущий месяц, полученный на одном из рабочих серверов:
Исходные данные
Имеется сервер с FreeBSD, на котором кроме всего прочего развернута почтовая
система на базе Postfix. Для просмотра отчета Mailgraph необходим сервер Apache
(процесс настройки сервера Apache не рассматривается в данной заметке за
исключением добавления возможности отображения отчетов Mailgraph). Все
программное обеспечение будет устанавливаться из портов, поэтому я рекомендую
Вам обновить их перед выполнением действий, описанных
ниже (я использовал FreeBSD 7.2 и последние версии портов для нее).
Установка и настройка Mailgraph
Установку Mailgraph необходимо выполнить из портов:
cd
/usr/ports/mail/mailgraph
make
CGIDIR=/usr/local/www/mailgraph-cgi WWWROOT=/usr/local/www install
clean
Значения переменных окружения CGIDIR (CGI-BIN-папка Web-сервера)
и WWWROOT (DocumentRoot-папка Web-сервера) изменены в связи с
использованием виртуальных хостов и нежеланием создавать беспорядок, сваливая
все устанавливаемое программное обеспечение в одну кучу – дефолтные папки
cgi-bin и data. Для того, чтобы демон Mailgraph
запускался при запуске операционной системы, необходимо выполнить требование
команды make install – добавить в файл /etc/rc.conf
строку:
mailgraph_enable="YES"
По умолчанию лог Postfix принадлежит root:wheel, имеет права
доступа 640 и не может быть прочитан Mailgraph, который работает от
имени www:www. Для исправления такого стечения обстоятельств
необходимо изменить группу, которой принадлежит лог Postfix, на
www:
chgrp www
/var/log/maillog
По умолчанию в процессе ротации логов, выполняемой newsyslog(8), владелец лога Postfix меняется на
root:wheel. Для исправления такого стечения обстоятельств
необходимо изменить значение поля [owner:group] в соответствующей
строке файла /etc/newsyslog.conf:
/var/log/maillog root:www 640 7 * @T00
JC
После выполнения перечисленных действий необходимо запустить демон Mailgraph
командой /usr/local/etc/rc.d/mailgraph start.
Настройка Apache для отображения отчетов
Для обеспечения возможности просмотра отчета Mailgraph в конфигурацию
соответствующего виртуального хоста нужно добавить строки:
Естественно, stat.company.com необходимо заменить на FQDN Вашего
виртуального хоста. Директива RedirectPermanent добавлена для
повышения удобства (по умолчанию для доступа к отчету Mailgraph в браузере
требуется ввести URL
http://stat.company.com/mailgraph-cgi/mailgraph.cgi, в нашем случае
– http://stat.company.com/postfixstat). Если виртуальный хост,
используемый для отображения отчета Mailgraph, доступен из Интернета, добавьте в
конфигурацию соответствующие ограничения доступа, подробно описанные в разделе
Authentication, Authorization, and Access Control
официальной документации Apache. Не забудьте, что после изменения конфигурации
необходимо перезапустить Apache командой apachectl restart. На этом
настройка Mailgraph завершается.
Заключение
Выполнив несложную последовательность действий, описанных в статье, Вы
получите возможность быстро и удобно оценивать нагрузку на почтовую систему,
определять моменты пиковых и минимальных нагрузок, оценивать результаты
предыдущих изменений конфигурации и делать выводы о необходимости дополнительной
оптимизации.