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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

или

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

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

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

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

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

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

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

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

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

fetchmail -> procmail:: header filter -> script.pl

// thread

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

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

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

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

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

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

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

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

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

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

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

:0
*
/var/www/script.pl

спасибо