> Так вот "текстовые логи" тем и хороши, что "дурь каждого становится видна". Я все-таки не понял: вы таки против гзипования логов? Файл то получается бинарный - в текстовом виде данные для LZ+Huffman не очень удобно передавать. Но я так понимаю что хранение лога в сжатом бинарном файле при всем этом претензий не вызывает? Т.е. по большому счету - это лишь вопрос доступности утилит для прозрачной работы с форматом. В том числе - возможности пайпинга в другие программы.
> В таком случае есть шансы, что человек сразу заметит, что что-то
> идёт не совсем так, если программа слишком много протоколирует.
Странный человек который сам лично окарауливает логи. Там где это кого-нибудь волнует - давно вкалывают автоматические системы мониторинга. Что вообще за мания - спихивать на человека рутинную работу? А машины для чего?
> Почему он неприемлимо много даёт нагрузки? Нет ли тут слишком сильной непродуманности
> системы протоколирования, которая записывает незначимые события? Помните
> "You mouse position has changed. Press OK to reboot."
Ну да, все можно довести до маразма. В таких случаях уместнее трассировщик, профайлер и деьагер. Но опять же - возможны варианты. Вот глючит сетевая утиля раз в неделю. Не будете же вы ее с дебагером караулить столько? А если просто бряк поставить - ну, она завалится туда. А вы допустим спали. Ну и отвалится ремота по таймауту, и вообще. И когда вы это увидите - картина будет уже не та которая привела к глюкам. В этом случае таки вариант заюзать вербозный логгинг, вплоть до packet-level tracing. Диски нынче большие.
Тем не менее, если хост отгружает допустим много мелких файлов, для него вообще нормально много писать в логи. Доходит до того что лог ведут по этому поводу на ремотном сервере. И как-то идея в несколько раз увеличивать объем записи на диск, сетевой траффик и прочая - достаточно спорные. Опять же, автоматические анализаторы потребуют более сложный и тормозной парсер.
Так что лично я ничего не имею против бинарных логов, если это дает плюсы. При одном условии. Должны быть описание формата + утилиты и библиотеки для работы с оным. Ну, как с gzip/deflate. Разумеется с исходниками. Тогда оно никаких проблем не вызывает.
> Всё-таки, программа должна выполнять, в основном, свою главную цель. А протоколирование
> выполнения в неё никак не входит. Может быть просто она откомпилирована не в release вариант, а в debug?
В совсем культурных программах это даже настраивается в рантайм. И намного хуже если надо понять что отвалилось а вербозности логов не хватило. Придется как минимум возиться с пересборкой, а если совсем не повезло - самому дописывать недостающие логи. Ну и гадостное же это занятие, скажу я вам. Приходилось несколько раз так делать - гемор конкретный. По уму это автор программы должен делать. Ему это в 20 раз проще - он уже кишки своей программы знает. А мне приходится "с места в карьер" вкуривать что и как.
Тем не менее, повторяю, например элементарный HTTP сервер, отдающий статику в нагруженном проекте - генерит прорву логов в совершенно штатном режиме. Это его нормальное состояние. И это вполне типовой юзкейс пингвинов, кроме всего прочего.
