LINUX.ORG.RU
ФорумAdmin

Анализатор почты

 , ,


0

2

Кто-нибудь сталкивался с решением позволяющим анализировать входящую почту и по определенным правилам строить отчеты.

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

Да, разумеется это можно сделать с помощью procmail и какой-то матери, но мне кажется, что кто-нибудь и раньше меня об этом думал.

★★★★

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

Ради интереса: зачем через почту, а не через сислог?

Alsvartr ★★★★★
()
Ответ на: комментарий от Alsvartr

Да исторически так сложилось. Бэкапы есть разные. В том числе и Oracle, а dba такие партянки отсылают, что у сислога рожа треснет.

zloelamo ★★★★
() автор топика

Зачем спамить в почту о успешных бекапах, когда интересуют неуспешные? Для этого нужен мониторинг(проверки, что последний бекап выполнялся не далее чем N часов назад и что он завершился успешно)

disarmer ★★★
()
Ответ на: комментарий от disarmer

Эх, дело гораздо сложнее чем может казаться: нужно проверять не только успешность/неуспешность, но и такие факторы как продолжительность и то что он завершился вовремя, а не просто «раз в сутки».

Т.е. успешные тоже интересуют.

zloelamo ★★★★
() автор топика
Последнее исправление: zloelamo (всего исправлений: 1)
Ответ на: комментарий от zloelamo

продолжительность и то что он завершился вовремя

Это по сути одно и то же при фиксированном расписании?

Это тоже может делать мониторинг, это как раз его задача - автоматизировать проверки, поддающиеся формализации.

disarmer ★★★
()
Ответ на: комментарий от disarmer

Зачем спамить в почту о успешных бекапах, когда интересуют неуспешные?

если бекап провалился и письмо не пришло, то ты будешь думать что все в порядке

sdio ★★★★★
()

procmail, передающий письмо в скрипт, проще не будет, твои письма в свободной форме никто кроме тебя парсить не будет, поэтому по-любому скрипт писать придется

sdio ★★★★★
()
Ответ на: комментарий от sdio

Мониторинг же, никакой почты с серверов. Если машина отвалилась - уведомления, если проверка провалилась - уведомления.

Уведомления рассылает аггрегатор, который живёт на отдельной машине. Аггрегатор или тоже мониторится отдельно, или аггрегаторов должно быть несколько, чтобы его падение не прошло незаметно.

disarmer ★★★
()
Ответ на: комментарий от sdio

procmail, передающий письмо в скрипт, проще не будет

ИМХО, проще забрать почту по pop3/imap. Не нужно думать о том, что параллельно может выполняться ещё одна копия.

router ★★★★★
()
Ответ на: комментарий от sdio

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

zloelamo ★★★★
() автор топика
Ответ на: комментарий от disarmer

Мониторинг же, никакой почты с серверов. Если машина отвалилась - уведомления, если проверка провалилась - уведомления.

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

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

Я не знаком с мониторингом, который умеет сверять событие с расписанием.

zloelamo ★★★★
() автор топика
Ответ на: комментарий от zloelamo

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

Для этих наших перлов, питонов и т.п. давно есть модули для работы с почтой и с pop3/imap. Будешь обращаться к отдельным заголовкам, а не работать с письмом как с куском текста

procmail хорошая вещь, но не нужно совать его куда попало

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от disarmer

никакой почты с серверов.

Тебе уже сказали, так у них сложилось — уведомления по почте, что ты как маленький заладил: «Нет, все сломайте и сделайте как я хочу»

sdio ★★★★★
()
Ответ на: комментарий от zloelamo

Я не знаком с мониторингом, который умеет сверять событие с расписанием

При желании можно прикрутить к любой системе мониторинга

router ★★★★★
()
Ответ на: комментарий от router

procmail хорошая вещь, но не нужно совать его куда попало

Тут сразу идет обработка (если нужна реакция), а не по расписанию. И не вижу особой разницы как скрипт получит письмо

1. MTA-->procmail-->script (parse) >> output.txt

или

2. MTA-->MDA-->script (pull mail)-->script (parse) >> output.txt

понятно что pull and parse могут быть в одном скрипте

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

sdio ★★★★★
()
Ответ на: комментарий от sdio

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

А с письмами легко может выйти, что будет еще куча подводных камней, «ну так сложилось». Это слабый аргумент поддерживать эту систему и дальше накручивать на неё функционал, который ещё надо писать и тестировать. Проверку дописать всяко легче чем разбирать письма с разнородными отчётами.

disarmer ★★★
()
Ответ на: комментарий от disarmer

Проверку дописать всяко легче чем разбирать письма с разнородными отчётами.

Проверку чего? Отчета программы бэкапа? Тот что присылается сейчас письмом, а в твоем случае будет файл на каждом сервере? И где здесь твое легче?

sdio ★★★★★
()
Ответ на: комментарий от sdio

Как минимум проверку размера и даты изменения самого свежего файла в директории с бекапами, если они хранятся локально. Если не хранятся - то в скрипте бекапа при успешном завершении создавать файл состояния и проверять его(так даже лучше, так как можно гарантировать что бекап прошёл до конца без сбоев). В любом случае несколько строк на баше.

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

disarmer ★★★
()
fetchmail -> procmail:: header filter -> script.pl

// thread

gh0stwizard ★★★★★
()
Ответ на: комментарий от zloelamo

Я не знаком с мониторингом, который умеет сверять событие с расписанием.

10 строчек на перле: дельта = <время события> - <время из лога кронтаба>

gh0stwizard ★★★★★
()
Ответ на: комментарий от disarmer

Как минимум проверку размера и даты изменения самого свежего файла в директории с бекапами, если они хранятся локально.

Ох святая простота :) В принципе проверка консистентости и успешности бэкапа это одна строка crosscheck backup, но выхлоп у неё дай боже. Именно этот выхлоп и направляется на почту. На самом деле некая предобработка уже есть, т.к. тема письма идет с fail/success, но это только пол дела.

zloelamo ★★★★
() автор топика
Ответ на: комментарий от sdio

Тебе уже сказали, так у них сложилось — уведомления по почте, что ты как маленький заладил: «Нет, все сломайте и сделайте как я хочу»

Да я готов сломать, но не вижу разумного метода событийной откидки. Т.е. кидать через syslog или через почту не велика разница. А активный мониторинг, который у нас есть, выворачивает ситуацию на изнанку, когда ты каждую минут проверяешь не случилось ли событие, которое в принципе совершается 5-6 раз в день. Особенно учитывая, что операция crosschek backup довольно затратна.

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

zloelamo ★★★★
() автор топика
Ответ на: комментарий от zloelamo

Т.е. то, что мне нужно это событийный мониторинг. Например zabbix это может

nagios может, через passive check, т. е. событие выставляет статус объекта в нагиосе, а нагиос уже реагирует соотв.

sdio ★★★★★
()
31 марта 2015 г.
Ответ на: комментарий от sdio

а как передать из procmail в perl скрипт

Подскажи пожалуйста, а как передать из procmail письмо в perl скрипт script.pl

:0
*
/var/www/script.pl

спасибо

evya
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.