Комментарии 3
Мне кажется, вместо сохранения в файл проще сразу отправлять, без лишнего сервиса. Ну и для контейнеров сейчас странно все это, хотя в некоторых случаях можно.
При сохранение в файл у вас только одна точка отказа - это место на жестком диске. А при отправке в удаленный сервис таких точек много.
Сразу менее надёжно, т.к. сервис хранения логов может быть где-то на другом сервере. Сетевые издержки, выше вероятность, что что-то может отломаться. А логи часто нужны именно когда что-то ломается.
Плюс вы жёстко завязываетесь в коде на конкретную хранилку.
Лучше всего из приложения логи кидать в самый быстрый и надёжный приемник. Кинули и забыли. А уже внешняя обвязка разберется, что с ними делать.
И я бы не в файл кидал логи, как автор, т.к. это тоже лишняя жёсткая привязка, особенность приложения, о котором все почему-то должны знать. Я бы кидал логи в stderr или stdout. И докеры, и кубы с этим форматом из коробки работают и, собственно, ожидают от вашего приложения логи именно там. И у них даже уже есть драйвера, которые позволяют эти логи маршрутизировать далее, например, драйвер с fluentd (аналог filebeat).
Если на вас или чистом железе разворачивание - такая же история. Плюёте логи в стандартный поток, а уже тот, кто разворачивает/запускает ваше приложение, решает, куда он его (поток логов) направит.
Если делаете пета и не очень в девопс, то можно и в файл писать. Если это коммерческая разработка, над которой работают много людей и приложение разворачивается в множестве различных окружений, да ещё и не одно (например, микросервисы), то совершенно точно не стоит писать в файл, а тем более через сеть в конкретную бд.
Symfony + Filebeat + Elasticsearch