Скрипт мониторинга лога и проверка события по времени

Прогони по shellcheck и удивись

Он посоветовал мне операцию суммирования заменить на другую. Заменил, картина та же.

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

Но почему не

tail -f -n 1 /var/log/fetchmail.log | while read LINE; do ...; done

# Sources
source src { system(); internal(); unix-stream("/dev/log"); file("/proc/kmsg"); unix-stream("/chroot/dhcp/dev/log"); };

# Destinations
destination d_users { program('/usr/local/sbin/log2user'); };

# Filters
filter f_errors { level(err..emerg) or message ("error" flags(ignore-case)) or message ("failed" flags(ignore-case)) or message ("flood" flags(ignore-case)) or message ("invalid" flags(ignore-case)); };

# Rules
log { source(src); filter(f_errors); destination(d_users); };

Это разовое тестирование. А вот «почему не», это я не сообразил да. Подскажите, подобного рода тестирование в принципе имеет какой-то профит? Интересно просто мнение.

tail -f -n 1 /var/log/fetchmail.log > /tmp/fetch_check &

Не лучше ли проверять exit code fetchmail'а?

Так он не завершается. Он просто сообщает в лог, что таймаут на соединение с таким-то ящиком и идет дальше. Или, я не правильно вас понял?

Мда, я затупил и не догадался что он демоном работает.

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

А скрипт в терминале выполняется или как демон? Консоль у него есть? Если нет, то что делать бедному телнету? Алсо у nc есть режим проверки возможности подключения, мне кажется ты хотел использовать именно его.

Скрипт проверки в терминале отрабатывает. По сути, мне бы просто сам факт соединения и всё. Но, я смотрю на свой скрипт и понимаю, что он делает фигню. Поэтому, сначала надо додумать. Про netcat почитаю, спасибо.

Не так уж и фигню. Просто уж возврата telnet/netcat надо проверять и сохранять. Так ты будешь знать, что сбои связаны не с фетчмейлом, а с пропавшим интернетом (или яндекс закрылся, что по нынешним временам не так уж невероятно).

Подскажите, подобного рода тестирование в принципе имеет какой-то профит? Интересно просто мнение.

Обычно начинают с просмотров логов (того же fetchmail в данном случае), при необходимости повышают уровень логирования, то есть делают логи более детальными. Плюс смотрят другие логи, например, системные; ну, и систему мониторинга, если Enterprise. Как правило этого достаточно. То, что ты приводишь - потенциально может быть, если логов не хватает, проблема плавающая, краткосрочная и проявляется нечасто. Но это бывает очень редко. На моей памяти (over 10 лет) такое было один раз, при том на домашнем компьютере, притом причиной оказался битый SATA кабель, из-за чего глючил жесткий диск.

Меня смущала логика изначального скрипта. Переписал так, что изначально счетчик на ноль и предыдущая строка пустая. Затем мы сравниваем текущую строку и предыдущую и если они совпадают на протяжении 9 секунд, то на последней проверяем соединение. А если текущая строка и прошла отличаются, то сбрасываем счетчик. Изначально, было по моему не верно.

#!/usr/bin/env bash

i=0
old_line=""

tail -f -n 1 /var/log/fetchmail.log | while read line
do
    if [[ "$line" == "$old_line" ]]
    then
        _=$(( i++ ))
        if [ $i -eq 9 ]
        then
            nc -z -v imap.yandex.ru 993 » /tmp/test_connection
        fi
        sleep 1
    else
        i=0
    fi
    old_line="$line"
done

Для начала перепиши это с г-баша на уместный язык (пистон, пирл). Потом будет разбираться с тем, что напишешь.

Штука в том, что в лог fetchmail пишет банальные:

fetchmail: timeout after 10 seconds waiting for server imap.yandex.ru.
fetchmail: socket error while fetching from <user>@domain.ru@imap.yandex.ru
fetchmail: Query status=2 (SOCKET)

Такое бывало раньше, помогало сообщить в яндекс. В этот раз они предложили протестировать. Изучаю механизмы. А то начальство грешит, что яндекс ай-яй-яй и делает это специально. :)

А зачем проверять строки на совпадение, если можно просто грепать на предмет «timeout after 10 seconds waiting for server imap.yandex.ru»?

К следующему юзеру в списке fetchmail коннектится уже нормально. Т.е. нет такого, что он прошел подряд 10 человек и всем 10 выдал таймаут. Поэтому, пытаюсь попасть в окно когда fetchmail стучится до яндекса.

запустить tcpdump/tshark и посмотреть сессию и причину отваливания?

После каждого ротирования логов эта конструкция будет переставать работать.