Через пару дней (!!!!) юзера начали жаловаться "у нас данные не сохраняются". Заходим проверяем - все сохраняется. На следующи день они поять приходят и говорят - "смотрите, нет данных, а вчера были".
а в действительнсти, серсис радостно писал свои данные на локалхост, где их периодически затирало тестовое окружение :)
Но обычно логи вообще в сислог пишут или отдельный грейлог/елк
о чем и речь, что это когда один чел что-то ковыряет, то ему удобно все под руками, но когда сервис разворачивается, то возникает куча нюансов, например, а не упадет ли все на забитом диске, если у нас негенерится гигабайты логов
о чем и речь, что это когда один чел что-то ковыряет, то ему удобно все под руками, но когда сервис разворачивается, то возникает куча нюансов, например, а не упадет ли все на забитом диске, если у нас негенерится гигабайты логов
Тут возникает вопрос мониторинга и адекватности логов )
а например, глюк с двойным запуском может вообще ничего не ломать, но генерить дофига стектрейсов в секунду просто про то, что он не смог второй раз на порт забайндиться
а например, глюк с двойным запуском может вообще ничего не ломать, но генерить дофига стектрейсов в секунду просто про то, что он не смог второй раз на порт забайндиться
Я честно скажу единственные логи которые я теперь пишу в файлы - это логи GC. Сейчас ведь контейнеры, кубики, микросервисы. Вот это вот все. И там хочешь не хочешь будешь собирать логи в отдельном месте
Я честно скажу единственные логи которые я теперь пишу в файлы - это логи GC. Сейчас ведь контейнеры, кубики, микросервисы. Вот это вот все. И там хочешь не хочешь будешь собирать логи в отдельном месте
структурированные логи используешь? ну в смысле это когда мессидж + структура вида {парам1:2,парам2:43453} и чтобы потом по этим параметрам фильтровать логи
структурированные логи используешь? ну в смысле это когда мессидж + структура вида {парам1:2,парам2:43453} и чтобы потом по этим параметрам фильтровать логи
Сейчас gelf. Раньше на прошлой работе через grok парсил