Comments 8
Краткое содержание: много скучных картинок.
Стоит отметить, что не надо создавать записи уровня error в рабочих ситуациях. Например, не отвечает не запущенный еще сервис и т.п.. В одном проекте только при старте всей системы в логи писалось несколько тысяч ошибок с выброшенными исключениями и stack trace - и это самый обычный, нормальный старт. Естественно, что если среди этих тысяч "обычных" ошибок возникала вдруг реальная, то увидеть ее было крайне сложно. И за несколько лет работы там я так и не поборол эту ситуацию, хотя кричал много и громко.
Кстати, уж если систематизировать полностью, то не описан ещё один, очень частый способ исправления ошибок - кто-то видит ошибку в UI, сообщает разработчикам и они сразу лезут в код, минуя всякие логи.
спасибо за комментарий!
по первому пункту: на мой взгляд для устоявшихся сервисов несколько тысяч ошибок при старте это неправильное поведение. Не знаю какая архитектура использована, но на уровне нашего стека мы можем избежать такого вала ошибок следующими действиями:
а) на уровне инструкций в сервисе before_server_start дожидаться установки всех коннектов(база, брокер сообщений, редис и т д). Не продолжать старт пока не будут все предусловия выполнены
б) на уровне kubernetes в параметр initial(время до первого пинга) заложить время с небольшим запасом, чтобы первый же пинг попадал на полностью рабочий сервис и после этого туда можно было пускать трафик. если за initial сервис не стартанул - действительно повод повнимательнее посмотреть что случилось, значит условия изменились и нужно внести изменения либо в систему, либо в initial
так же стоит прогревать все кеши до первого пинга, тем самым увеличивая initial в кубе.
По второму пункту - полностью согласен, если релиз был недавно и пришло сообщение о нестандартном поведении системы - опытный программист может в голове понять какой из граничных случаев он не предусмотрел и сразу починить, без логов :)
Где баги — там напряги
Дави жуков