[sisyphus] postfix traffic collector

[sisyphus] postfix traffic collector

[Pavel S. Khmelinsky]

Тут понадобилось считать пользовательский трафик на основании 
логов постфикса. Т.е. пришло собшение на адрес user@domain.net, 
мы user'у в трафик n-ое кол-во мегабайт добавили.
Проблема в том что после разделения входящего трафика по 
пользователям нужно еще его поделить по отправителям.
Т.е. локальный почтовый траффик считать не надо.
Постфикс в логи всю полезную информацию выдает отдельными 
строчками, которые идут не всегда подряд, что усложняет написание 
парсера логов. Может быть у кого-нибудь есть готовое решение? Или 
мысли по поводу того как это можно сделать проще? Может есть 
опция для постфикса чтобы он в лог более красивое описание 
входящих сообщений кидал?
Я в результате поиска нашел только это:
http://freshmeat.net/redir/pflogsumm/7822/url_homepage/postfix_contrib.html
только вот считает все подряд, без возможности разделения 
входящего трафика по пользователям на локальный и внешний.

Re: [sisyphus] postfix traffic collector

[Mike Lykov]

В сообщении от Четверг 22 Май 2003 08:18 Pavel S. Khmelinsky написал:

> Постфикс в логи всю полезную информацию выдает отдельными
> строчками, которые идут не всегда подряд, что усложняет написание
> парсера логов

я тоже так думал, когда писал парсер лога popa3d  ;)

но мне подсказали - в каждой строчке есть pid... соответственно можно 
суммировать записи об одном процессе  (получения конкретного письма) 
относительно его pid, который в разных строчках (даже разнесенных далеко) 
будет один и тот же.. если postfix конечно его пишет ;)

-- 
Mike

Re: [sisyphus] postfix traffic collector

[Igor Dobryninsky]

  Hello, Mike Lykov.

On Thu, 22 May 2003 09:31:15 +0500
Mike Lykov <combr@vesna.ru> wrote:

ML> но мне подсказали - в каждой строчке есть pid... соответственно можно 
ML> суммировать записи об одном процессе  (получения конкретного письма) 
ML> относительно его pid, который в разных строчках (даже разнесенных далеко) 
ML> будет один и тот же.. если postfix конечно его пишет ;)

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

  МessageId в логе постфикса указывается как раз после идентификатора
процесса программы-обработчика. Вот пример:

May 22 12:34:36 troitsky postfix/pickup[7125]: 747A710E4: uid=112 from=<community-admin@altlinux.ru>
                                               ^^^^^^^^^
May 22 12:34:36 troitsky postfix/cleanup[7160]: 747A710E4: message-id=<015d01c3203c$9f289770$3d01a8c0@plant.odescable.com.ua>
May 22 12:34:36 troitsky postfix/qmgr[6250]: 747A710E4: from=<community-admin@altlinux.ru>, size=3651, nrcpt=1 (queue active)
May 22 12:34:36 troitsky postfix/local[7167]: 747A710E4: to=<egor@atvc.ru>, relay=local, delay=0, status=sent ("|/usr/bin/procmail -a $DOMAI

  Однако, дело может осложнить, например, DrWeb, если он используется,
или SpamAssassin или ещё что-нибудь подобное.

-- 
  Best Regards, Igor Dobryninsky (egor@atvc.ru)
  ATK-Internet ISP, Arkhangelsk, Russia

Re: [sisyphus] postfix traffic collector

[Dmitry Lebkov]

On Thu, 22 May 2003 12:39:03 +0400
Igor Dobryninsky <egor@atvc.ru> wrote:

>   Hello, Mike Lykov.
> 
> On Thu, 22 May 2003 09:31:15 +0500
> Mike Lykov <combr@vesna.ru> wrote:
> 
> ML> но мне подсказали - в каждой строчке есть pid... соответственно
> ML> можно суммировать записи об одном процессе  (получения конкретного
> ML> письма) относительно его pid, который в разных строчках (даже
> ML> разнесенных далеко) будет один и тот же.. если postfix конечно его
> ML> пишет ;)
> 
>   Дело в том, что постфикс, по сути дела, это набор
> узкоспециализированных программ, которые последовательно запускаются
> менеджером для обработки письма. Поэтому pid тут не поможет. Тут
> поможет уникальный МessageId, который присваивается каждому письму.
> Вот по нему и надо фильтровать.
> 
>   МessageId в логе постфикса указывается как раз после идентификатора
> процесса программы-обработчика. Вот пример:

Это не message id - это mail-queue-id. А message-id идет
строчкой ниже - в сообщении от postfix/cleanup. Вот по
комбинации нескольких mail-queue-id и одного message-id
можно отследить весь цикл доставки сообщения, т.к. message-id
на всех этапах доставки(DrWeb, filters, etc) остается без
изменений, а mail-queue-id -- меняется.

> May 22 12:34:36 troitsky postfix/pickup[7125]: 747A710E4: uid=112
> from=<community-admin@altlinux.ru>
>                                                ^^^^^^^^^
> May 22 12:34:36 troitsky postfix/cleanup[7160]: 747A710E4:
> message-id=<015d01c3203c$9f289770$3d01a8c0@plant.odescable.com.ua> May
> 22 12:34:36 troitsky postfix/qmgr[6250]: 747A710E4:
> from=<community-admin@altlinux.ru>, size=3651, nrcpt=1 (queue active)
> May 22 12:34:36 troitsky postfix/local[7167]: 747A710E4:
> to=<egor@atvc.ru>, relay=local, delay=0, status=sent
> ("|/usr/bin/procmail -a $DOMAI
> 
>   Однако, дело может осложнить, например, DrWeb, если он используется,
> или SpamAssassin или ещё что-нибудь подобное.


--
WBR, Dmitry Lebkov

Re: [sisyphus] postfix traffic collector

[Pavel S. Khmelinsky]

Dmitry Lebkov wrote:
> On Thu, 22 May 2003 12:39:03 +0400
> Igor Dobryninsky <egor@atvc.ru> wrote:
> 
> 
>>  Hello, Mike Lykov.
>>
>>On Thu, 22 May 2003 09:31:15 +0500
>>Mike Lykov <combr@vesna.ru> wrote:
>>
>>ML> но мне подсказали - в каждой строчке есть pid... соответственно
>>ML> можно суммировать записи об одном процессе  (получения конкретного
>>ML> письма) относительно его pid, который в разных строчках (даже
>>ML> разнесенных далеко) будет один и тот же.. если postfix конечно его
>>ML> пишет ;)
>>
>>  Дело в том, что постфикс, по сути дела, это набор
>>узкоспециализированных программ, которые последовательно запускаются
>>менеджером для обработки письма. Поэтому pid тут не поможет. Тут
>>поможет уникальный МessageId, который присваивается каждому письму.
>>Вот по нему и надо фильтровать.
>>
>>  МessageId в логе постфикса указывается как раз после идентификатора
>>процесса программы-обработчика. Вот пример:
> 
> 
> Это не message id - это mail-queue-id. А message-id идет
> строчкой ниже - в сообщении от postfix/cleanup. Вот по
> комбинации нескольких mail-queue-id и одного message-id
> можно отследить весь цикл доставки сообщения, т.к. message-id
> на всех этапах доставки(DrWeb, filters, etc) остается без
> изменений, а mail-queue-id -- меняется.
> 
> 
>>May 22 12:34:36 troitsky postfix/pickup[7125]: 747A710E4: uid=112
>>from=<community-admin@altlinux.ru>
>>                                               ^^^^^^^^^
>>May 22 12:34:36 troitsky postfix/cleanup[7160]: 747A710E4:
>>message-id=<015d01c3203c$9f289770$3d01a8c0@plant.odescable.com.ua> May
>>22 12:34:36 troitsky postfix/qmgr[6250]: 747A710E4:
>>from=<community-admin@altlinux.ru>, size=3651, nrcpt=1 (queue active)
>>May 22 12:34:36 troitsky postfix/local[7167]: 747A710E4:
>>to=<egor@atvc.ru>, relay=local, delay=0, status=sent
>>("|/usr/bin/procmail -a $DOMAI
>>
>>  Однако, дело может осложнить, например, DrWeb, если он используется,
>>или SpamAssassin или ещё что-нибудь подобное.

Я так и знал. Готового решения никто не знает. Сейчас подумываю 
прикрутить как раз еще одну самописную програмку, которая будет 
подключатся также как DrWeb а потом уже сама передавать сообщение 
дальше.

Т.е. что-нибудь вроде

avcheck   unix  -       n       n       -       5       pipe 
flags=q user=email_traf argv=email_traff_log -p 1025

localhost:1025  inet n       -      n      -       - smtpd

в master.cf

Есть мысли о предстоящих трудностях? Или готовые куски кода для 
парсинга сообщения и подсчитывания его длинны в байтах?

Re: [sisyphus] postfix traffic collector

[Dmitry Lebkov]

On Thu, 22 May 2003 18:14:51 +0400
"Pavel S. Khmelinsky" <hmepas@yauza.ru> wrote:

> Dmitry Lebkov wrote:
> > On Thu, 22 May 2003 12:39:03 +0400
> > Igor Dobryninsky <egor@atvc.ru> wrote:
> > 
> > 
> >>  Hello, Mike Lykov.
> >>
> >>On Thu, 22 May 2003 09:31:15 +0500
> >>Mike Lykov <combr@vesna.ru> wrote:
> >>
> >>ML> но мне подсказали - в каждой строчке есть pid... соответственно
> >>ML> можно суммировать записи об одном процессе  (получения
> >конкретного>ML> письма) относительно его pid, который в разных
> >строчках (даже>ML> разнесенных далеко) будет один и тот же.. если
> >postfix конечно его>ML> пишет ;)
> >>
> >>  Дело в том, что постфикс, по сути дела, это набор
> >>узкоспециализированных программ, которые последовательно запускаются
> >>менеджером для обработки письма. Поэтому pid тут не поможет. Тут
> >>поможет уникальный МessageId, который присваивается каждому письму.
> >>Вот по нему и надо фильтровать.
> >>
> >>  МessageId в логе постфикса указывается как раз после
> >идентификатора>процесса программы-обработчика. Вот пример:
> > 
> > 
> > Это не message id - это mail-queue-id. А message-id идет
> > строчкой ниже - в сообщении от postfix/cleanup. Вот по
> > комбинации нескольких mail-queue-id и одного message-id
> > можно отследить весь цикл доставки сообщения, т.к. message-id
> > на всех этапах доставки(DrWeb, filters, etc) остается без
> > изменений, а mail-queue-id -- меняется.
> > 
> > 
> >>May 22 12:34:36 troitsky postfix/pickup[7125]: 747A710E4: uid=112
> >>from=<community-admin@altlinux.ru>
> >>                                               ^^^^^^^^^
> >>May 22 12:34:36 troitsky postfix/cleanup[7160]: 747A710E4:
> >>message-id=<015d01c3203c$9f289770$3d01a8c0@plant.odescable.com.ua>
> >May>22 12:34:36 troitsky postfix/qmgr[6250]: 747A710E4:
> >>from=<community-admin@altlinux.ru>, size=3651, nrcpt=1 (queue
> >active)>May 22 12:34:36 troitsky postfix/local[7167]: 747A710E4:
> >>to=<egor@atvc.ru>, relay=local, delay=0, status=sent
> >>("|/usr/bin/procmail -a $DOMAI
> >>
> >>  Однако, дело может осложнить, например, DrWeb, если он
> >используется,>или SpamAssassin или ещё что-нибудь подобное.
> 
> Я так и знал. Готового решения никто не знает. Сейчас подумываю 

Формат логов постфикса еще в процессе (до|раз)работки и до конца не
стабилизирован. И, в отличии от того же сендмыла, достаточно неудобен
для разбора.

> прикрутить как раз еще одну самописную програмку, которая будет 
> подключатся также как DrWeb а потом уже сама передавать сообщение 
> дальше.
> 
> Т.е. что-нибудь вроде
> 
> avcheck   unix  -       n       n       -       5       pipe 
> flags=q user=email_traf argv=email_traff_log -p 1025
> 
> localhost:1025  inet n       -      n      -       - smtpd
> 
> в master.cf
> 
> Есть мысли о предстоящих трудностях? Или готовые куски кода для 
> парсинга сообщения и подсчитывания его длинны в байтах?

Есть предположение, что после передачи сообщения через smtpd (а не
через pipe) может измениться message-id. Но это только предположение %)

Сейчас пишется парсер на перле, который _должен_ учесть все особенности
имеющегося в ALM постфикса. Задача - учет успешно доставленных сообщений
(для системы расчетов ISP). Данные складываются в MySQL. Если получится
что-нить приличное %) -- можно будет попытаться либо завернуть это в
пакет, либо добавить как contrib к постфиксу. 

--
WBR, Dmitry Lebkov

Re: [sisyphus] postfix traffic collector

[Pavel S. Khmelinsky]

Dmitry Lebkov wrote:
> On Thu, 22 May 2003 18:14:51 +0400
> "Pavel S. Khmelinsky" <hmepas@yauza.ru> wrote:
> 
> 
>>Dmitry Lebkov wrote:
>>
>>>On Thu, 22 May 2003 12:39:03 +0400
>>>Igor Dobryninsky <egor@atvc.ru> wrote:
>>>
>>>
>>>
>>>> Hello, Mike Lykov.
>>>>
>>>>On Thu, 22 May 2003 09:31:15 +0500
>>>>Mike Lykov <combr@vesna.ru> wrote:
>>>>
>>>>ML> но мне подсказали - в каждой строчке есть pid... соответственно
>>>>ML> можно суммировать записи об одном процессе  (получения
>>>
>>>конкретного>ML> письма) относительно его pid, который в разных
>>>строчках (даже>ML> разнесенных далеко) будет один и тот же.. если
>>>postfix конечно его>ML> пишет ;)
>>>
>>>> Дело в том, что постфикс, по сути дела, это набор
>>>>узкоспециализированных программ, которые последовательно запускаются
>>>>менеджером для обработки письма. Поэтому pid тут не поможет. Тут
>>>>поможет уникальный МessageId, который присваивается каждому письму.
>>>>Вот по нему и надо фильтровать.
>>>>
>>>> МessageId в логе постфикса указывается как раз после
>>>
>>>идентификатора>процесса программы-обработчика. Вот пример:
>>>
>>>
>>>Это не message id - это mail-queue-id. А message-id идет
>>>строчкой ниже - в сообщении от postfix/cleanup. Вот по
>>>комбинации нескольких mail-queue-id и одного message-id
>>>можно отследить весь цикл доставки сообщения, т.к. message-id
>>>на всех этапах доставки(DrWeb, filters, etc) остается без
>>>изменений, а mail-queue-id -- меняется.
>>>
>>>
>>>
>>>>May 22 12:34:36 troitsky postfix/pickup[7125]: 747A710E4: uid=112
>>>>from=<community-admin@altlinux.ru>
>>>>                                              ^^^^^^^^^
>>>>May 22 12:34:36 troitsky postfix/cleanup[7160]: 747A710E4:
>>>>message-id=<015d01c3203c$9f289770$3d01a8c0@plant.odescable.com.ua>
>>>
>>>May>22 12:34:36 troitsky postfix/qmgr[6250]: 747A710E4:
>>>
>>>>from=<community-admin@altlinux.ru>, size=3651, nrcpt=1 (queue
>>>
>>>active)>May 22 12:34:36 troitsky postfix/local[7167]: 747A710E4:
>>>
>>>>to=<egor@atvc.ru>, relay=local, delay=0, status=sent
>>>>("|/usr/bin/procmail -a $DOMAI
>>>>
>>>> Однако, дело может осложнить, например, DrWeb, если он
>>>
>>>используется,>или SpamAssassin или ещё что-нибудь подобное.
>>
>>Я так и знал. Готового решения никто не знает. Сейчас подумываю 
> 
> 
> Формат логов постфикса еще в процессе (до|раз)работки и до конца не
> стабилизирован. И, в отличии от того же сендмыла, достаточно неудобен
> для разбора.
Это я заметил %:)

> 
> Сейчас пишется парсер на перле, который _должен_ учесть все особенности
> имеющегося в ALM постфикса. Задача - учет успешно доставленных сообщений
> (для системы расчетов ISP). Данные складываются в MySQL. Если получится
> что-нить приличное %) -- можно будет попытаться либо завернуть это в
> пакет, либо добавить как contrib к постфиксу. 
Уже есть куски кода на которые можно взглянуть? Может мне их и 
хватит?

Re: [sisyphus] postfix traffic collector

[Dmitry Lebkov]

On Thu, 22 May 2003 22:53:38 +0400
"Pavel S. Khmelinsky" <hmepas@yauza.ru> wrote:

[skip]

> > Сейчас пишется парсер на перле, который _должен_ учесть все особенности
> > имеющегося в ALM постфикса. Задача - учет успешно доставленных сообщений
> > (для системы расчетов ISP). Данные складываются в MySQL. Если получится
> > что-нить приличное %) -- можно будет попытаться либо завернуть это в
> > пакет, либо добавить как contrib к постфиксу. 
> Уже есть куски кода на которые можно взглянуть? Может мне их и 
> хватит?

Писатель данного кода сей лист читает. Если сочтет возможным что-то подкинуть
-- думаю, подкинет ... %)

--
WBR, Dmitry Lebkov