Раз в пару недель ловлю одно и то же: приложение держит пул соединений
к базе, а между ними стоит балансировщик со своим idle-таймаутом. Пул считает
соединение живым, балансировщик его уже выбросил. Первый запрос после паузы
падает, второй проходит.
Лечится не ретраями, а согласованием чисел: таймаут на клиенте должен быть
заметно меньше, чем на промежуточном узле.
ss -tno state established '( dport = :5432 )'
Колонка timer: сразу показывает, у кого keepalive реально
тикает, а кто просто ждёт.
Логи, которые никто не читает
Долго держал журнал в режиме «пишем всё, разберёмся потом». Разбираться
потом не выходит: в момент аварии в логе тонны отладочного шума, а нужной
строки нет, потому что её уровень посчитали слишком низким.
Сейчас правило простое. В журнал идёт то, по чему можно принять решение:
вход в обработчик с идентификатором запроса, внешний вызов с длительностью,
и ошибка с причиной. Всё остальное — за флагом, выключенным по умолчанию.
Место на диске кончается не там, где смотришь
df говорит, что диск полон, du по корню
показывает половину. Обычно виноват процесс, который держит открытым уже
удалённый файл — место не вернётся, пока он жив.
Второй по частоте вариант — кончились иноды, а не байты:
df -i.
Про резервные копии, которые не проверяли
Копия, которую ни разу не разворачивали, — это не копия, а надежда.
Раз в квартал беру последний архив и поднимаю из него отдельный экземпляр,
без доступа к рабочим данным. За два года так нашлось три поломки:
дважды не хватало прав на каталог, один раз дамп обрывался на середине,
потому что скрипт не проверял код возврата.