Comments 4
Первой строкой в каждый крон ставлю set -e: скрипт останавливается на первом же падении, и статистика в конце уже не отдаст свой ноль всему прогону. Грабли следующего уровня знакомы тем, кто с этим пожил: set -e молчит внутри условий и цепочек с &&, поэтому критичный шаг проверяю на месте, сразу после команды. Самый надёжный сигнал всё равно приходит снаружи: файл появился, строки уехали, сообщение дошло до адресата.
Да, set -e вместе с set -o pipefail хорошая первая линия, и оговорку про условия и && стоит повторять почаще. Но в моей истории он спас бы только лог: скрипт упал бы честно, а крон все равно промолчал бы, и узнал бы я об этом только по пустому утру. Поэтому пришел к тому же, чем вы закончили. После главного шага скрипт проверяет, появился ли файл захода за сегодня, и если нет, шлет уведомление в Telegram. Смешно, что эта проверка сама три дня давала ложную тревогу: в пути к папке был пробел, и glob без кавычек рассыпался на слова. Проверку проверок тоже приходится проверять.
Тут остаётся случай, когда крон вообще не запустил скрипт: внутренняя проверка файла тоже не выполнится, и Telegram снова промолчит. Я бы проверял свежесть результата отдельным заданием, а для критичного процесса — с другой машины. Тогда тревога приходит и при падении шага, и при отсутствии самого запуска.
Да, этот случай внутренняя проверка не закрывает. Внешнему наблюдателю я бы задал срок появления результата с небольшим запасом и проверку самого артефакта: за нужную дату, непустой, в ожидаемом формате. Сигнал о старте процесса для этого недостаточен. Уведомление стоит отправлять при переходе в сбой и затем при восстановлении, чтобы один пропущенный запуск не превращался в поток одинаковых сообщений.
Крон три дня писал «код 0» и ничего не делал: пять форм тихого отказа в автоматизации