The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Тематический каталог: Обработка log-файла почтового сервера ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Тематический каталог: Обработка log-файла почтового сервера ..."  +/
Сообщение от auto_topic (??) on 04-Май-06, 17:50 
Обсуждение статьи тематического каталога: Обработка log-файла почтового сервера Postfix (postfix log statistic)

Ссылка на текст статьи: http://www.opennet.ru/base/net/postfix_log_parse.txt.html

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Skif (??) on 04-Май-06, 17:50 
Так, мелкие замечания:
month varchar(10), day char(2) -почему не заменить на тип date имхо, разумнее, тем более парсинг не займет много времени %hash даст спасенье. Да и процес сравнения для MySQL пойдет легче и быстрее.
При мелкой нагрузке - тоесть редких выборках - такая база нормально дышать будет. При большой - активное составление отчетов и прочая... Касательно ключей - даже не знаю что сказать. Скорее разумнее сделать индексацию по rcpt_to и mail_from + size писем, введя в качестве primary key что-то типа id поля, с auto encrement. Почему так? Потому что ключами(индексами) надо делать поля по которым выбираются данные, а не те которые выбираются. Если педположить, что интересует конкретно время прохождения письма от pupkin@domen к vasia@domen2, тогда это разумно...Но здесь претензии скользки по определению - надо решать на этапе проектирование БД, что с ней делать будут.
А так в принципе, ничего...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Vershinin Egor on 04-Май-06, 18:37 
Большое спасибо за замечания - учту в будущем!
Честно говоря это мой первый опыт самостоятельной работы с Perl-ом и MySQL-ем, к чему весьма способствовала Ваша статья:
http://www.opennet.ru/base/net/ng_billing_letter.txt.html
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Algor (??) on 05-Май-06, 07:10 
Чтобы опыту набраться, можно и такие скрипты писать, для реальных же задач даже незнаю.
У меня на релее около 50к писем в день и около 2к пользователей которые эти письма пишут, но задачи возникают как правило:
1.) посмотреть доставилось ли письмо от одного пользователя к другому (в основном за сегодняшний день, и раза три было посмотреть за неделю)
2.) какие письма были от такого то пользователя и кому
3.) сколько спама и вирусов отсеилось
4.) какой общий объем почты ушел и пришел.

1,2,3 решаются с помощью простых sh скриптов (4 строчки скрипт), время выполнения которых до 10 сек
3,4 решаются с помощью pflogsumm

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Сергей (??) on 05-Май-06, 07:33 
Согласен с Algor

Когда логи сервака занимают по 300-400 метров в день, особо с БД не поработаешь. Plain-text парсить гораздо эффективнее с точки зрения использования ресурсов системы.

Я даже не представляю, сколько perl отожрет памяти, если ему скормить достаточно большой лог.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Vershinin Egor on 05-Май-06, 08:06 
А может Вы проверите эту программу на своих логах и сообщите результат?

У меня такого трафика нет, к сожалению :)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Vershinin Egor on 05-Май-06, 08:11 
Я тестировал эту программу на логах в 2 Мб и 25 Мб. Без записи в БД, со сбросом информации в файл:
./maillogs > mail.txt эта программа отрабатывала лог за 2 секунды (увеличение размера лога в 10 раз на скорости не сказалось).

Был бы очень признателен, если ы кто-нибудь протестировал прогу на больших журналах.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Сергей (??) on 05-Май-06, 08:31 
to Vershinin Egor

Прогоню попробую...
Но смысла в этом нет. Для больших логов гораздо нужнее утилиты выбора конкретной информации (поиск следов конкретного письма).
Кстати, сколько занимает база для лога в 25 мегабайт?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Vershinin Egor on 05-Май-06, 08:34 
Примерно 450 кб
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Kuzmich email(??) on 05-Май-06, 08:49 
1. Интересно как поведет себя скрипт, если в конец файла /var/log/maillog будут дописываться данные, и смогут ли они туда вобще дописываться при открытом файле.
2. Выполнение скрипта лучше поставить в logrotate, а не в cron, и после того как журнал ротэйтнулся, тогда первый вопрос отпадает сразу.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Сергей (??) on 05-Май-06, 08:56 
to Vershinin Egor

ниче он у меня в логах не обнаружил:
21.03.2006 23:59:59 KRAT xxx.xxx.xxx [info] postfix/qmgr[11146]: [ID 197553 local1.info] 814DB24912: removed

пробежался по файлу и все

это все из-за split на самом деле, формат логов может разниться, поэтому нехорошо привязываться к своему логу

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Сергей (??) on 05-Май-06, 10:52 
прогнал я скрипт с большим логом (310Mб)

памяти сожрал во время выполнения 128Мб (благо отдал потом :))) )
работал 3 минуты, загрузив тазик на 90% (остальные 10% делили между собой иксы и gkrellm)

Итого:
чисто текстовые данные по письмам (дата, время, отправитель, адресат, размер) составили около 6.5Мб
если принять размер одной записи в БД за 500 байт (примерная взятая почти с потолка цифра, хотя всякое может быть), то занимать мой лог будет около 50Мб.

Теперь к основному... товарищ Vershinin Egor, основным недостатком Вашего скрипта является оторванность от postfix как ни странно.

Вот короткий пример:
$ tail -10000 ./postfix-2006-03-21 | grep 438B324958:
21.03.2006 23:59:38 KRAT xxx.xxx.xxx [info] postfix/smtpd[11195]: [ID 197553 local1.info] 438B324958: client=unknown[85.136.42.194]
21.03.2006 23:59:40 KRAT xxx.xxx.xxx [info] postfix/cleanup[11154]: [ID 197553 local1.info] 438B324958: message-id=<720101c64cf4$e689a770$be710e0a@knee>
21.03.2006 23:59:44 KRAT xxx.xxx.xxx [info] postfix/qmgr[11146]: [ID 197553 local1.info] 438B324958: from=<info@lopez.org>, size=10647, nrcpt=2 (queue active)
21.03.2006 23:59:44 KRAT xxx.xxx.xxx [info] postfix/smtp[13443]: [ID 197553 local1.info] 438B324958: to=<rel@domain>, relay=localhost[127.0.0.1], delay=7, status=sent (250 Ok: queued as 88E1124938)
21.03.2006 23:59:44 KRAT xxx.xxx.xxx [info] postfix/smtp[13443]: [ID 197553 local1.info] 438B324958: to=<ttv@domain>, relay=localhost[127.0.0.1], delay=7, status=sent (250 Ok: queued as 88E1124938)
21.03.2006 23:59:44 KRAT xxx.xxx.xxx [info] postfix/qmgr[11146]: [ID 197553 local1.info] 438B324958: removed

Не будем обращать на то, что отправлено было все на localhost. Посмотрим только на то, что письмо ушло 2 (двум!) адресатам... И что в этом случае скрипт посчитает?
$ tail -1000 ./log | grep 85.136.42.194
21.03.2006,23:59:38,85.136.42.194,info@lopez.org,ttv@domain,10647

Т.е. мы посчитали только письмо для последнего адресата... И даже если не вспоминать про такие важные вещи, как количество соединений с одного IP (подсети и пр.), количество попыток отправки почты - про все то, что данный скрипт игнорирует - все равно получается, что функции свои он не выполняет.

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

Короче, дорого, коряво и неэффективно.

P.S.
Vershinin Egor, мне самому приходилось писать подобные скрипты для анализа работы сервера. получалось немногим лучше (если не хуже в некоторых задачах).
Хранить статистику в БД разумно, логи - нет (у Вас получается хранение чего-то среднего). Опытным путем пришел к тому, что необходимо иметь набор шаблонов grep для фильтрации интересующей меня информации из лога и еще набора специализированных скриптов для ее анализа. Это позволяет решать как текущие задачи администрирования, так и получать статистику.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Skif (??) on 05-Май-06, 13:33 
>P.S.
>Vershinin Egor, мне самому приходилось писать подобные скрипты для анализа работы сервера.
>получалось немногим лучше (если не хуже в некоторых задачах).
>Хранить статистику в БД разумно, логи - нет (у Вас получается хранение
>чего-то среднего). Опытным путем пришел к тому, что необходимо иметь набор
>шаблонов grep для фильтрации интересующей меня информации из лога и еще
>набора специализированных скриптов для ее анализа. Это позволяет решать как текущие
>задачи администрирования, так и получать статистику.


Ну зачем же так человека расстраивать...:) Все же вектор напрвлености нужно задать правильный. Да и те скрипты и бинарники, которыми выпользуетесь начинались с такого же. Только разница в том, что они пользуют временные файлы, а не таблицы. Касательно же сабжа, то здесь гораздо важнее правильно организовать структуру БД и таблиц. То бишь, к чему я веду. Лог в случае его хранения в БД ни вкоем случае нельзя ложить в обну таблицу. Минимум две. Потому что при выборках из таблиц нарушается самый главный принцип БД. В одной ячейке находиться куча данных, которые повторяются. Кстати в этом плане показателен exim, который хранит свой лог в трех файлах. К чему бы это? :) (так наводящая шутка в сторону)
Второе. Для риалтайма статистики необходимо вешать pipe на лог или еще какой изврат придумывать. Объясню зачем - что бы уменьшить нагрузку на проц/память в процессе предварительного парсинга лога и раскидывании по таблицам. Многие данные надо просто банально продумать на начале проектирования. То есть сесть с логом типичным. Хотя бы на 50-100 строк. Посмотреть какие данные проходят. что надоть, что нет. Взять лист бумаги и нарисовать таблички. Потом связи между ними.  Взять еще один и снова. Но уже на основе предыдущего. И так до тех пор, пока у вас не окажетьсяв итоге несколько таблиц. в которых будут присутсвовать минимум данных. и минимум будет повторятся. Плюс доводите до того, что бы всякие varchar сводились тоже к минимуму. Например смысл присутствия имя hostname если его можно заменить на 1, введя дополнительно таблицу:
+--+---------+
|id| hostname|
+--+---------+
| 1|server.ua|
+--+---------+
| 2|server.ru|
+--+---------+

Даже в случае если используется только один сервер какой прирост, плюс уменьшение объема места, засчет использования не 4-х байт, а 2-х, например (точно размерность не вспомню для varchar  и того же smallint).
Введение правильных ключей при частых выборках, а не раз впятилетку, позволит добиться того, что если например при выполнении первого запроса выборка шла 5 минут, то второй пробежиться за минуту. На что я выше кстати уже указал.
Еще раз возвращаясь к структуре таблицы primary key(month,day,time) все же выбран неудачно, так как нагрузка у автора явно маленькая и письма ходят редко,  то ему оно подойдет, а вот на больших объемах нет - так как очень часто primary key будет повторятся, соответственно в базу данные попадать не будут (дублирование primary невозможно по определению).
ТО есть, Женя, Мысль у тебя хорошая. И даже нужная. Только еще сырая. Я сам такую гадость сейчас пишу. Только я пишу не единичную, а суммарную для нескольких серваков. Потому так и разжевываю, что и зачем. Касательно предыдущих ораторов, того же Сергея, могу сказать, что скорее всего статистику они генерят один раз и забывают об этом. Если тебе нужен именно такой вариант, то то, что ты написал, действительно не имеет смысла, если нужно, что-то более серьезное - тогда продолжай копать.
Для меня такая проблема встала, когда пришлось частенько парсить логи нескольких почтовиков, при чем у каждого он разросся от полутора до 2-х с половиной гигов. И просто статистика типа сколько от и до пользователя прошло писем мне была не нужна. Мне нужны были данные, как прошло конкретное письмо в конкретном интервале времени,возможность вернуть лог полностью и касательно одного письма, и т.д. А это уже слишком специфичные задачи и большинству они нафиг не нужны.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Skif (??) on 05-Май-06, 13:43 
Извини, не Женя, а Егор. :)
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Сергей (??) on 05-Май-06, 14:03 
>Касательно же сабжа, то здесь гораздо важнее правильно
>организовать структуру БД и таблиц.
Всеми руками-ногами присоединяюсь.

>Еще раз возвращаясь к структуре таблицы primary key(month,day,time) все же выбран неудачно,
>так как нагрузка у автора явно маленькая и письма ходят редко,
> то ему оно подойдет, а вот на больших объемах нет
>- так как очень часто primary key будет повторятся, соответственно в
>базу данные попадать не будут (дублирование primary невозможно по определению).
>ТО есть, Женя, Мысль у тебя хорошая. И даже нужная. Только еще
>сырая. Я сам такую гадость сейчас пишу. Только я пишу не
>единичную, а суммарную для нескольких серваков. Потому так и разжевываю, что
>и зачем. Касательно предыдущих ораторов, того же Сергея, могу сказать, что
>скорее всего статистику они генерят один раз и забывают об этом.
Конечно, почти так. Точнее, интересующую меня статистику можно получать другим путем. Так,  собрать данные о размерах писем проще в контент фильтре, если он это умеет, а если не умеет, но умеет со внешними модулями работать - то написать такой модуль. На эту тему можно долго говорить, но это будет все же немного офтоп.

>Для меня такая проблема встала, когда пришлось частенько парсить логи нескольких почтовиков,
>при чем у каждого он разросся от полутора до 2-х с
>половиной гигов. И просто статистика типа сколько от и до пользователя
>прошло писем мне была не нужна. Мне нужны были данные, как
>прошло конкретное письмо в конкретном интервале времени,возможность вернуть лог полностью и
>касательно одного письма, и т.д.
Ага, вот это как "прямое" назначение логов :))) я рад просто, что у меня они не по 2 гига,  и что это требуется не особо часто, иначе пришлось бы так же, как и Вы поступать. А так можно особо не напрягаясь скриптами управится.

>А это уже слишком специфичные задачи и большинству они нафиг не нужны.
Золотые слова. На задачу же и решалка :)

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

15. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Жириновский email on 07-Сен-08, 20:46 
Здравствуйте товарищи!

а как можно брать каждные 2 минуты и вставлять их в таблицу?

пример:
1) открывайт файло логов
2) блокируем файл для записи других прграмм
3) переносим в СУБД
4) очищаем файл
5) разблориуем файл

такая схема реализации подойдет?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Жириновский email on 07-Сен-08, 20:48 
или нужно синхронизировать с помощью XML ?

или еще как-то можно?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Жириновский email on 08-Сен-08, 16:26 
синхронизировасть с помощю дампа с Storable наверное надо...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Watcher (??) on 13-Янв-09, 08:44 
Я у себя сдела primary key
month  
day  
time  
mailfrom  
rcptto,
а то иначе теряются записи,(при вставке указывает на дублирующие записи), так как за секунду может быть несколько писем., Также в таблицу не вносятся записи, если письмо посылалось копией кому-либо еще.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Avolon email on 21-Янв-09, 13:01 
при обработке выдает
DBD::mysql::st execute failed: Column 'month' cannot be null at ./log.pl line 55.
Что делать то???
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Серга email on 20-Апр-10, 20:42 
to Avolon:
попробуй убери $rec{$id}->{'client'} ne '127.0.0.1'
вместо етого ип пропиши како-то левый...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Серга email on 19-Май-10, 19:00 
подскажите как етот скрипт изменить, что бы можно было и статус письма из логов получить?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Scales email on 20-Май-10, 12:24 
mail.log примерно 415 метров
отработал приблизительно за минуты 3
Спасибо!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Обработка log-файла почтового сервера Postfix (postfix log s..."  +/
Сообщение от Евгений email(??) on 27-Окт-15, 14:21 
как добавить год? нужно чтобы в базу писался в отдельную колонку год. Никак не могу разобраться.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру