Логирование веб-приложений: syslog и stdout/stderr?

Question

[topuserman]

При разработке веб-проектов я обычно использую логирование двумя способами:

1. Для простых проектов - логи пишутся файл
2. Для крупных проектов - бизнесовые логи пишу в очередь (rabbitmq), а системные логи также в файл. Дальше эти логи забирает logstash и закидывает в elasticsearch.

Также все чаще встречаю два других способа (из всяких докладов и кейсов), которые мне интересны:

1. Логи писать в syslog (rsyslog, nxlog и прочие реализации).
Одно из известных мне преимуществ - производительность.

2. Логи писать в stdout/stder согласно 12 факторной архитектуре.
Как я понял, из преимуществ то, что если у нас много сервисов, то все они пишут лог по одному принципу, и из-за этого можно легко управлять логами всех сервисов.
Т.е. само приложение передает ответственность за управление логами выше.

Если что-то неправильно понял - прошу поправить.

У меня возникло несколько вопросов:

1. В каких случаях обычно пишут логи в syslog ? был ли у вас опыт ?
Какие есть минусы и плюсы ?

2. Честно говоря, мне не совсем понятен принцип отправки логов в stdout.
Во-первых, что значит в stdout ? если это веб-приложение (сайт), то лог сразу будет показан пользователю ?..
Во-вторых, как собирать потом эти логи, если проект не использует например контейнеризацию ?
Какие есть минусы и плюсы у этого подхода ? Какой у вас был опыт ?

Comments

[Василий Банников]

Во-первых, что значит в stdout ? если это веб-приложение (сайт), то лог сразу будет показан пользователю ?..

Наверно, это скорее пхпшная деформация.

Обычно, в языке есть какой-нибудь printf, который как раз и пишет текст в STDOUT, а для обработки http-запросов есть что-то отдельное.
В php, как я помню, есть echo, который при запуске в консоли через интерпретатор как раз и пишет в stdout, а при запуске через условный apache - echo будет писать в тело http-ответа.
Вот есть какая-то статья про распределённый php.
https://habr.com/ru/post/456676/

Во-вторых, как собирать потом эти логи, если проект не использует например контейнеризацию ?

12-factors подразумевает, что твои приложения контейнеризированы.

Логирование в stdout для распределённых приложений - это скорее необходимость, чем прихоть.
Тк при использовании всяких оркестраторов твоё приложение может запускаться на разных физических машинах, и неожиданно убиваться. В таких условиях, файловые логи становятся не очень удобными.
При этом все оркестраторы умеют собирать логи из stdout, а дальше их уже можно централизованно обработать.

В монолитных и нераспределённых приложениях никаких преимуществ такой подход не несёт.
Syslog позволяет скинуть с приложения ответсвенность за управление логами. При таком подходе не нужно в коде реализовывать логику, например, по ротированию логов на каждый день/ каждые N мбайт и тд.

[Adamos]

Василий Банников,

при запуске через условный apache - echo будет писать в тело http-ответа

Ну, если быть точным, echo-то так и будет писать туда же, просто апач перехватит этот stdout и отправит его обратно туда, откуда пришел запрос.
Аналогично и в приведенной методичке - предлагают переложить ответственность за расположение логов с самого приложения на то, что его запускает.

Answer 1

[Saboteur]

1. стандартная служба syslog умеет парсить логи по facility, следовательно можно настроить логирование разных компонентов в разные файлы на уровне syslog, управлять их ротацией.
Также syslog умеет работать с другими syslog, таким образом можно аггрегировать логи с разных машин и управлять ими централизованно.

2. логи отправленные в stdout обычно куда-то перенаправляют, в тот же файл, или сразу грабят в какой-то аггрегатор.
В современное время про stdout чаще всего говорят, когда вы запускаете что-то в контейнере, а контейнер крутится в оркестраторе типа kubernetes/openshift.
В этом случае настраивается внешний сборщик - тот же filebeat, fluentd, logstash или syslog, который собирает логи со всего кластера кубернетес/опенщифт, парсит их и кидает в аггрегатор.
Просто задеплоили новый компонент и по его имени можно фильтровать логи в той же Кибане, при этом нигде не нужно в системе логирования настраивать что-то под новый компонент, все тегируется автоматом.

Answer 2

[Валентин]

stdout - это стандартный вывод, обычно это консоль. Вот запустили вы в консоли приложение - и увидели, что оно вам написало, потому что оно выводит сообщения в stdout. И не зря тут std в названии - "стандартный". С ним умеет работать много чего. Вот возьмем допустим systemd: он запускает сервис, его stdout ловится и попадает в journald. Можно куда-нить еще завернуть. Системы управления контейнерами тоже так умеют.

Как собирать? Ну вот вы ж всё умеете, вы там про очереди, logstash пишите - вот, это оно. Вы берете filebeat, ну или там какие еще *beat'ы у него есть, ловите ими вывод ваших приложений и пихаете его в эластик. Ну или допустим fluentbit берёте и им шлете логи в очередь какую-нить, а оттуда уже в хранилку.

1. В каких случаях обычно пишут логи в syslog ?

ну syslog очень много лет, он был еще до всех этих контейнеров и 12-факторных приложений ;) Так что когда-то им пользовались практически все.