Сообщения об ошибках неинтерактивных программ

Anton Shepelev написал(а) к All в Aug 19 02:09:42 по местному времени:

From: Anton Shepelev <antonius@freeshell.de>

Всем доброго здоровья

Я вот пишу batch-скрипт для резервного копирования нашего
репозитария SVN. В случае ошибок он отправляет уведомление
по электронной почте через blat.exe. А как принято
поступать, если почту отправить не удалось? Должен же быть
у админов какой-то запасной и более надёжный канал для
сообщения об ошибках.

--
Антон Шепелёв
--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Anton Shepelev в Aug 19 08:30:35 по местному времени:

25 авг. 2019, воскресенье, в 02:09 NOVT, Anton Shepelev написал(а):

AS> Я вот пишу batch-скрипт для резервного копирования нашего
AS> репозитария SVN. В случае ошибок он отправляет уведомление
AS> по электронной почте через blat.exe. А как принято
AS> поступать, если почту отправить не удалось? Должен же быть
AS> у админов какой-то запасной и более надёжный канал для
AS> сообщения об ошибках.

Вообще скрипты не должны заботиться о доставке генерируемой почты.
Скрипт должен отдать почту локальному доставщику и уже его
забота доставить почту по адресу в том случае, если с первого раза
не получилось. На всех серверах есть либо локальный доставщик (MTA)
с его очередью, либо гарантированно доступный (скажем,
99.999% времени) близкий в местной сети.

Если у твоего хоста нету MTA - поставь. Можно не полноценный релей,
а какой-нибудь простенький пересыльщик на mail hub:
на провайдерский релей или почтовый сервер бесплатной почтовой
службы, который уже является полноценным MTA.
Лишь бы пересыльщик умел в почтовую очередь.

Какой конкретно MTA ставить - зависит от того, под какой операционкой
и версией её должен работать твой скрипт.

Eugene
--
И кого не любишь, в лицо не знать, и смотреть на звезды и жить спокойно.
--- slrn/1.0.3 (FreeBSD)

Eugene Grosbein написал(а) к Anton Shepelev в Aug 19 08:34:10 по местному времени:

25 авг. 2019, воскресенье, в 08:30 NOVT, Eugene Grosbein написал(а):

AS>> Я вот пишу batch-скрипт для резервного копирования нашего
AS>> репозитария SVN. В случае ошибок он отправляет уведомление
AS>> по электронной почте через blat.exe. А как принято
AS>> поступать, если почту отправить не удалось? Должен же быть
AS>> у админов какой-то запасной и более надёжный канал для
AS>> сообщения об ошибках.
EG> Вообще скрипты не должны заботиться о доставке генерируемой почты.
EG> Скрипт должен отдать почту локальному доставщику и уже его
EG> забота доставить почту по адресу в том случае, если с первого раза
EG> не получилось. На всех серверах есть либо локальный доставщик (MTA)
EG> с его очередью, либо гарантированно доступный (скажем,
EG> 99.999% времени) близкий в местной сети.
EG> Если у твоего хоста нету MTA - поставь. Можно не полноценный релей,
EG> а какой-нибудь простенький пересыльщик на mail hub:
EG> на провайдерский релей или почтовый сервер бесплатной почтовой
EG> службы, который уже является полноценным MTA.
EG> Лишь бы пересыльщик умел в почтовую очередь.
EG> Какой конкретно MTA ставить - зависит от того, под какой операционкой
EG> и версией её должен работать твой скрипт.

Менее предпочтительной альтернативой установке локального MTA
является организация заката Солнца вручную: реализовать самому
укладывание исходящей почты в очередь и запуск разгребальщика
очереди. И добавить его вызов ещё и в планировщик заданий,
чтобы он запускался периодически и если очередь не пуста -
выполнял очередную попытку скормить почту в mail hub.

Но реализовать такую софтинку корректно с точки зрения
интернет-стандартов не так чтобы слишком тривиально,
там хватает граблей, на которые можно понаступать больно.
Лучше найти и поставить готовое.

Eugene

--- slrn/1.0.3 (FreeBSD)

Andrew Kant написал(а) к Eugene Grosbein в Aug 19 10:32:40 по местному времени:

Нello Eugene!

Sunday August 25 2019 08:34, Eugene Grosbein wrote to Anton Shepelev:

EG> 25 авг. 2019, воскресенье, в 08:30 NOVT, Eugene Grosbein написал(а):

AS>>> Я вот пишу batch-скрипт для резервного копирования нашего
AS>>> репозитария SVN. В случае ошибок он отправляет уведомление
AS>>> по электронной почте через blat.exe. А как принято
AS>>> поступать, если почту отправить не удалось? Должен же быть
AS>>> у админов какой-то запасной и более надёжный канал для
AS>>> сообщения об ошибках.
EG>> Вообще скрипты не должны заботиться о доставке генерируемой почты.
EG>> Скрипт должен отдать почту локальному доставщику и уже его
EG>> забота доставить почту по адресу в том случае, если с первого раза
EG>> не получилось. На всех серверах есть либо локальный доставщик (MTA)
EG>> с его очередью, либо гарантированно доступный (скажем,
EG>> 99.999% времени) близкий в местной сети.
EG>> Если у твоего хоста нету MTA - поставь. Можно не полноценный релей,
EG>> а какой-нибудь простенький пересыльщик на mail hub:
EG>> на провайдерский релей или почтовый сервер бесплатной почтовой
EG>> службы, который уже является полноценным MTA.
EG>> Лишь бы пересыльщик умел в почтовую очередь.
EG>> Какой конкретно MTA ставить - зависит от того, под какой
EG>> операционкой и версией её должен работать твой скрипт.

EG> Менее предпочтительной альтернативой установке локального MTA
EG> является организация заката Солнца вручную: реализовать самому
EG> укладывание исходящей почты в очередь и запуск разгребальщика
EG> очереди. И добавить его вызов ещё и в планировщик заданий,
EG> чтобы он запускался периодически и если очередь не пуста -
EG> выполнял очередную попытку скормить почту в mail hub.

EG> Но реализовать такую софтинку корректно с точки зрения
EG> интернет-стандартов не так чтобы слишком тривиально,
EG> там хватает граблей, на которые можно понаступать больно.
EG> Лучше найти и поставить готовое.

Вообще-то стандартный способ сохранения сообщений об ошибках - системный журнал, применительно к данной эхе - event log. А вот отправка сообщений через smtp - вот это уже "закат Солнца вручную". Лучше поставить какие-нибудь стандартные анализаторы журналов и в них уже генерировать уведомления по почте, смс, пуш или что там еще есть.

Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Eugene Grosbein написал(а) к Andrew Kant в Aug 19 15:37:01 по местному времени:

27 авг. 2019, вторник, в 10:32 NOVT, Andrew Kant написал(а):

AK> Вообще-то стандартный способ сохранения сообщений об ошибках - системный
AK> журнал, применительно к данной эхе - event log. А вот отправка сообщений через
AK> smtp - вот это уже "закат Солнца вручную". Лучше поставить какие-нибудь
AK> стандартные анализаторы журналов и в них уже генерировать уведомления по почте,
AK> смс, пуш или что там еще есть.

Доставка текстовых сообщений по e-mail - общепринятый интернет-стандарт,
STD 10 и STD 11, а ведь контекст вопроса - надежность доставки,
насколько она возможна в сети без гарантий. Именно использование
стандартнов повышает надежность.

А какие плюсы даст дополнительная прослойка между скриптом и MTA
в виде event log и анализатора этого лога? Нет никакой гарантии,
что event log не сротируется между добавлением в него записи
и запуском анализатора лога, в результате чего анализатор сообщения
не увидит же? Это минус.

Eugene
--
http://www.grosbein.net/papirosn.mp3
http://dadv.livejournal.com/2006/03/11/
--- slrn/1.0.3 (FreeBSD)

Andrew Kant написал(а) к Eugene Grosbein в Aug 19 17:37:59 по местному времени:

Нello Eugene!

Tuesday August 27 2019 15:37, Eugene Grosbein wrote to Andrew Kant:

EG> 27 авг. 2019, вторник, в 10:32 NOVT, Andrew Kant написал(а):

AK>> Вообще-то стандартный способ сохранения сообщений об ошибках -
AK>> системный журнал, применительно к данной эхе - event log. А вот
AK>> отправка сообщений через smtp - вот это уже "закат Солнца вручную".
AK>> Лучше поставить какие-нибудь стандартные анализаторы журналов и в
AK>> них уже генерировать уведомления по почте, смс, пуш или что там еще
AK>> есть.

EG> Доставка текстовых сообщений по e-mail - общепринятый интернет-стандарт,
EG> STD 10 и STD 11, а ведь контекст вопроса - надежность доставки,
EG> насколько она возможна в сети без гарантий. Именно использование
EG> стандартнов повышает надежность.
Ну, во-первых, e-mail по определению не даёт гарантированную доставку. Во-вторых, есть много разных стандартов, но в данном случае речь идет о сообщениях об ошибках, а не о почтовых сообщениях, а для них стандарты - это системный лог.

EG> А какие плюсы даст дополнительная прослойка между скриптом и MTA
EG> в виде event log и анализатора этого лога? Нет никакой гарантии,
EG> что event log не сротируется между добавлением в него записи
EG> и запуском анализатора лога, в результате чего анализатор сообщения
EG> не увидит же? Это минус.
Конечно, можно придумать кучу разных проблем, которые не дадут возможности сохранить сообщения при любом способе. А если выключить питание, например? ;)

Но вопрос в другом. Как ты говорил, есть общепринятые стандарты, и если сообщение попало в сислог, то в нем эту ошибку можно найти и стандартными средствами, доступными в самой системе - мы не зависим от network-стека.
Ну и надёжность внутреннего журнала все-таки выше, чем связки локальный mta-сеть-почтовый сервер.

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

Готовых и более-менее известных (то есть тем, кому можно доверять) коллекторов логов довольно много, да и само использование подобного продукта - уже плюс для того, кто его внедрит, так что с этим проблем тоже быть не должно. Заодно получит контроль над всей инфраструктурой :)

А вот попытки написать свой собственный mta наверняка дадут очередной костыль, в котором о стандартах вряд-ли кто-то вообще будет вспоминать. Явно будет что-то типа echo 'EНLO', без всякой обработки ответов итп.


Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Eugene Grosbein написал(а) к Andrew Kant в Aug 19 02:14:56 по местному времени:

29 авг. 2019, четверг, в 17:37 NOVT, Andrew Kant написал(а):

AK>>> Вообще-то стандартный способ сохранения сообщений об ошибках -
AK>>> системный журнал, применительно к данной эхе - event log. А вот
AK>>> отправка сообщений через smtp - вот это уже "закат Солнца вручную".
AK>>> Лучше поставить какие-нибудь стандартные анализаторы журналов и в
AK>>> них уже генерировать уведомления по почте, смс, пуш или что там еще
AK>>> есть.
EG>> Доставка текстовых сообщений по e-mail - общепринятый интернет-стандарт,
EG>> STD 10 и STD 11, а ведь контекст вопроса - надежность доставки,
EG>> насколько она возможна в сети без гарантий. Именно использование
EG>> стандартнов повышает надежность.
AK> Ну, во-первых, e-mail по определению не даёт гарантированную доставку.

Это зависит от определения "гарантированной доставки" - в сети без гарантий
вообще ничего не даёт гарантированной доставки и протокол TCP тоже,
однако же TCP называют протоколом с гарантированной доставкой в том смысле,
что он либо доставит данные, либо сообщит о невозможности доставки:
данные не уйдут "в молоко". И в этом смысле SMTP таки гарантирует доставку:
письмо либо будет доставлено, либо вернётся отправителю с указанием
на невозможность доставки (и иногда с причиной).

AK> Во-вторых, есть много разных стандартов, но в данном случае речь идет о
AK> сообщениях об ошибках, а не о почтовых сообщениях, а для них стандарты - это
AK> системный лог.

Системный лог разве является стандартом доставки сообщения об ошибке
удалённому адресату? Тема именно про удалённую доставку.
В лог написать это правильно, но мы-то обсуждаем дополнительную
к этому доставку на другие системы.

EG>> А какие плюсы даст дополнительная прослойка между скриптом и MTA
EG>> в виде event log и анализатора этого лога? Нет никакой гарантии,
EG>> что event log не сротируется между добавлением в него записи
EG>> и запуском анализатора лога, в результате чего анализатор сообщения
EG>> не увидит же? Это минус.
AK> Конечно, можно придумать кучу разных проблем, которые не дадут возможности
AK> сохранить сообщения при любом способе. А если выключить питание, например? ;)

Выключение питания - аварийная ситуация, а ротация журнала - штатное
и даже запланированное событие. Не надо передергивать.

AK> Но вопрос в другом. Как ты говорил, есть общепринятые стандарты, и если
AK> сообщение попало в сислог, то в нем эту ошибку можно найти и стандартными
AK> средствами, доступными в самой системе - мы не зависим от network-стека.
AK> Ну и надёжность внутреннего журнала все-таки выше, чем связки локальный
AK> mta-сеть-почтовый сервер.

Да чем же она выше, если сообщение из eventlog может просто пропасть
через секунду после его записи из-за ротации? И eventlog решает другую
задачу - о локальной доставке.

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

Но у нас уже есть скрипт, который изначально это сообщение генерирует,
зачем нам сложная конструкция с дополнительными скриптами и шаблонами
для eventlog, если мы можем прямо сразу сделать то, что надо?

AK> А вот попытки написать свой собственный mta наверняка дадут очередной костыль,
AK> в котором о стандартах вряд-ли кто-то вообще будет вспоминать. Явно будет что-то
AK> типа echo 'EНLO', без всякой обработки ответов итп.

Поэтому-то я и не рекомендовал писать это самому,
лучше поставить готовый MTA для удалённой доставки.

Eugene
--
И знатную леди от Джуди О'Греди
Не сможет никто отличить.
--- slrn/1.0.3 (FreeBSD)