Нормально ли печатать логи только на стандартный поток ошибок?

Да как-то пофиг, если честно. Умеет — будем юзать это умение. Не умеет — перенаправим. Это не то свойство программы, которое влияет на моё отношение к ней как к хорошей или плохой.

Тут можно обсудить скорее в каких случаях эта фича целесообразна, а в каких нет. Так, например, если это что-то единовременное, например компилляция проекта, тот же make какой-нибудь, то мне кажется, вполне достаточно выводить всё в stderr/stdout — если юзеру надо, он сам перенаправит. То же с каким-нибудь архивированием, компрессией, транскодингом аудио/видео, копированиям и т.д и т.п. Совсем другое дело, если программа висит как демон и ловит события какие-то, как, например, какой-нибудь nginx. В таком случае возможность ведения логов в виде файлов (причём вот например в случае с nginx можно, скажем, отдельно по поддоменам, отдельно подключения, отдельно ошибки, и т.д.) ожидаема и востребована — здесь выводом в stderr обойтись, конечно, возможно, но очень не хочется.

Какая программа? Пользовательская или серверное ПО? И если пользовательская, то с GUI или без него?

У каждого из этих случаев свои традиции.

Серверное.

Ок, уточнил.

Но имхо, это тема не для опроса, а для форума Development. Людей, которые пишут службы/демоны, у нас не так много, и гораздо интереснее, если они выскажутся словами.

И вообще, такие программы обычно пишут не просто в файл, а в системный журнал событий.

Пока я настроен перенести это в форум.

А там останется форма голосования или просто текст?

В моем случае hobbit заботливо сохранил пункты, сделав из них простой список. Как по мне, не надо переносить. Все-таки логи читать может и любой другой разработчик, и админ, и домохозяйка. И мнение у них вполне может быть. Допустим, системы инициализации, звуковые и графические серверы тут едва ли кто пишет, но высказаться готовы многие.

Я бы просто добавил вариант про сислог, но для этого придется переписать опрос. Впрочем, его и так придется переписать, чтобы на главной не было этого:

Нормально ли печатать логи только на стандартный поток ошибок?

• Да, хорошая программа обязана уметь писать логи в файл
• Нет, хорошей программе вполне достаточно уметь писать в stderr

«Хотите ли пряники?» – «Да, только чаю». – «Нет, хочу».

Придется исправить. После этого ответы перестанут сочетаться уже с описанием опроса, так что придется переписать и его.

Как по мне, не надо переносить.

Только тогда опрос ещё 2-3 месяца будет болтаться в неподтверждённых. Так ли уж важны ТСу циферки от тех, кто не готов написать своё мнение словами? Лучше меньше, да лучше, нет?

но высказаться готовы многие

Вот именно высказаться можно и на форуме. Я, в общем-то, не настаиваю, пусть ТС подумает…

Кстати, а что за Великий Опрос? Можно ссылку или название?

Я названия не помню, помню только, что он висел на главной ПОЛГОДА.

А хотя бы год? Я его тогда в архиве найду.

cast maxcom :)

Станет ли l.o.r лучше, если.... Висел на главной с 2003 по 2006.

Может оставить опрос пока висеть и сделать дубль на форуме? Сначала словесно, потом численно.

Хорошая программа должна использовать стандартные интерфейсы syslog, то есть /dev/log или утилиту logger. Писать напрямую в какой-то файл через 3>file (а не 2>, stderr тоже должен быть) допустимо в некоторых случаях.

Я бы предпочёл наоборот, перенести эту тему в форум (варианты ответов сохраню). Если у тебя после обсуждения в Development всё ещё останется желание делать анонимный вопрос — можно будет обсудить отдельно.

Давай.

Вне стадий отладки и разработки, никакие логи не нужны, нужно журналирование (см ниже) и телеметрия.

Журналирование это фиксация действий пользователя в системе, оно же - аудит. Действия записываются чаще всего сразу в базу, естественно с привязкой к пользователю.

Телеметрия это про сбор ошибок с привязкой к контексту выполнения и данными о рантайме.

Логи, тем более в файл это точка отказа и мусорка, из которой что-то вытащить при реально работающем сервере с кучей пользователей становится мало реально.

Это все если речь идет о чем-то большом и работающем, не о каком-то чисто техническом сервисе, без пользователей и нагрузки.

systemd отлично берёт стандартный вывод сервиса и складирует в journald.

В целом опция явного сохранения логов в файл приятная, но не критичная.

Пишу сервисы и демоны 10+ лет. По опыту:

1. Для чего-то что не демон (пусть даже выполнение будет N часов, например мат. расчеты) - stderr это то что нужно.

2. Если это демон - то всё зависит от того где будет крутиться. Если это ну только linux, то:

• Если это демон, что изредка делает что-то (например я написал себе демона что выгруженные в каталог с фотика фотки обрабатывает в формат и ставит вотермарку в углу) - то ок. Journald, syslog, в зависимости от системы (тут, кстати уже неудобно что зоопарк). Даже в этом случае иногда удобно 2> в файл, проще его раз в год потереть, чем писать подключение к системному логгеру.
• Если это демон, что получает ЛЮБОЙ запрос снаружи (начиная от сервера и кончая каким-нибудь обработчиком терминала (физического)) - ВСЕГДА есть шанс либо злого умысла и DDoS или ошибки пользователя и DoS. Тогда пойдёт такое количество логов, что любой journald сразу скажет Archived and active journals take up NNN TB, если не настроены лимиты. А если настроены - то потрет старые, где была первопричина ошибки. Поэтому в таком случае это запись в файл и или встроенный logrotate или внешний, разницы нет.

3. Если у нас кросплатформенность (что обычно и бывает в коммерческой разработке) - то это точно своя запись в файл и своя реализация logrotate внутри (это просто). Потому что писать две никак не похожие друг на друга обработки journald/syslog/windows event (последний вообще не предназначен для сколько-нибудь сильной нагрузки) - это удвоение расходов на разработку. Дополнительно см. пункт 2.

С учетом вышесказанного я не вижу особой нужды использовать системные логи в каком-то более-менее коммерческом или высоконагруженном проекте. А противоположный им тип (короткие одноразовые обработчики) можно заменить баш-портянкой, в которой echo > ххх ваш надежный друг и товарищ. Системные логи - для системных демонов, для всего остального есть /var/log

хорошая серверная должна уметь это всё с настройкой детализации

Структурированные логи в stdout/err, кому нужно — собирает, кому не нужно — не собирает или вообще отключает. Как и где его будут использовать, приложению знать незачем, его дело предоставить всю информацию, какую попросят (и если попросят), стандартным способом в стандартном формате.

все есть файл, stderr не исключение.

ненормально - когда программа _не умеет_ писать никуда кроме как в журналд и безальтернативно тащит весь системд по зависимостям.

и эмодзи в логах тоже не нормально.

и эмодзи в логах тоже не нормально

Я был категорически против, когда их вводили в Юникод, потому что для меня компьютерный шрифт всегда был наследником наборных шрифтов для высокой печати. Сейчас понимаю, насколько это удобно, когда у всех и везде одни и те же эмодзи, а не условные колобки, внезапно вырастающие посреди копипасты с кодом или не обработанные, потому что у тебя набор другой.

Чем они мешают в логах? Сам ни разу не видел, но, как по мне, с ними было бы удобнее ориентироваться. Минуса тут три: могут показываться как тофу, могут быть частично контурными, частично цветными, могут отвлекать от других сообщений. Но так ли это существенно?

Юникод помимо удобного бывает еще и страшным а его отладка может вообще превращаться в кошмар, если не знать. А некоторые вещи точно лучше не знать.

И всё-таки ты сферический архитектор в вакууме. :)

А ты очередное пополнение в игнор-лист, поздравляю.

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

Даже если ты трижды гений-эксперт с бесконечным стажем во всем.

Ой, после снега и двоения аналогового ТВ, рассыпания цифрового, заевших пластинок, порванных магнитных пленок, расплавленной кинопленки в проекторе, писка царапин на компакт-дисках, пш-пш-аудио, глюков переключалки языков в Xfce, мне показали странненький текст, намеренно сделанный странненьким.

По поводу сложности Юникода согласен, но это лишь следствие его концепции.

Меня не зоопарк пробелов бесит (он-то, как раз, нужен), а то, что предлагают и даже рекомендуют кодировать Й и Ё как И и Е с диакритиками. Потом одни насочиняют автоматическую конвертацию, потому что так великий консорциум завещал, а другие не осиливают наложение диакритик.

мне показали странненький текст, намеренно сделанный странненьким. Меня не зоопарк пробелов бесит

Ну мы же тут логи обсуждаем? Вот и представь все эти замечательные эффекты в логах. А появляются они там достаточно элементарно, достаточно вывода в лог данных от пользователя без фильтрации, что-то типа «вы ввели: %s» .

Я еще не упоминал что редакторы любят падать при попытке открыть файл с таким юникодом?

Добавь меня заодно.

Я серверные программы запускаю в kubernetes. Там stdout и stderr через containerd уходят во временные файлы. Их promtail постоянно шлёт в loki и они сохраняются в S3 хранилище централизованным образом. Через logctl или grafana их можно запрашивать с нужными фильтрами. Это всё очень удобно получается. Поэтому для меня очень важно, чтобы серверная программа могла писать логи в stdout. Я пока других не встречал. Писать логи в файл мне не нужно.

Раньше я серверные программы писал на Java и запускал в tomcat и IBM WebSphere. Там через log4j была настроена ротация логов, в каждой программе по-своему настраивалось всё. Работало на Windows 2003. Тогда были популярны такие библиотеки, для одной жавы их наверное с десяток наделали, если всякие адаптеры считать. А сейчас, имхо, это всё лишнее. Достаточно писать в стандартный вывод и всё.

Никто тебя не обсирает. Просто ты со своей чушью про клиентов/пользователей/базы и транзакции бесконечно далёк от любого серверного и не очень софта. Проще говоря от реальности. И подобные безапелляционные заявления от тебя в очередной раз выглядят смешно.

Уважаемый, оставь пожалуйста меня в покое, будь так добр. Я писал ТС и по делу, а не тебе и просто так.

Твое (как и чье-либо другое) мнение про меня лично и мой опыт в частности просто не интересно. Ты не мой работодатель, не коллега и не клиент чтобы о нем судить.

Смешно такие вещи объяснять модератору ей-богу. Ты же срачи должен останавливать а не разжигать.

А я и не разжигаю срач. Я высказываю своё мнение по поводу некоторых глупых советов, чтобы ТС мог оценить их адекватность.

Вот и представь все эти замечательные эффекты в логах.

Я еще не упоминал что редакторы любят падать при попытке открыть файл с таким юникодом?

Интересный вектор атаки вырисовывается. Пока админ или безопасник безуспешно пытается открыть логи или прочитать месиво, делаем что-то по-настоящему вредоносное.

«вы ввели: %s».

Пользователь сам себе выстрелил в ногу. Наверное, из него выйдет хороший тестировщик или безопасник.

Хорошая программа никуда ничего не пишет, пока ее об этом не попросят, но я таких не встречал.

Пользователь сам себе выстрелил в ногу.

Могу добавить что неистребимый как тараканы паттерн «писать в лог учетные данные» позволяет много чего узнать не залезая в систему и вообще никак ее не трогая.

В логи летят и сами пароли и логины и ФИО с адресами, часто бывает что пароль маскируется самом библиотекой автоматически, но в какой-то момент это перестает работать и все пишется в открытую.

Ротация может сломаться, поскольку старый кусок лога же еще обычно архивируют после переключения, если в этот момент кончается место на диске то все встает колом.

чтобы серверная программа могла писать логи в stdout.

может все-таки в stderr?

Мне без разницы, но зачем усложнять? Ну можно debug/info в stdout, warn/error в stderr.

Я просто не очень понимаю, что ещё кроме логов может писать серверная программа в stdout.

Давай все-таки проведем опрос, потому что тут разные люди высказывали разные точки зрения? Хочется узнать кто как считает численно.

А ты очередное пополнение в игнор-лист, поздравляю.

Модераторов нельзя игнорировать :-)

https://12factor.net/logs

никакая программа не должна писать логи в файл, тем более серверная.

Потому при выводе логов в stdout/stderr о них сможет позаботиться запустивший сервис менеджер, в котором у любого нормального админа уже настроены и отлажены ротация, архивация и т.п.

А вот при выводе в файл это все придется настраивать руками - и не факт что получится, потому что откуда ты как разработчик знаешь, что может понадобиться конечным пользователям?