Я думаю, что мне не хватает того, чтобы иметь структуру ведения журнала для вашего приложения. Во всех небольших приложениях я всегда писал небольшой класс «Ведение журнала» и просто передаю сообщения журнала методу, который записывается в файл.
Какова цель сторонней платформы ведения журналов, такой как log4net? Это потокобезопасность с операциями записи в журнал или мне что-то не хватает?





вы можете переключиться на ведение журнала в базу данных для какого-либо сообщения или систему предупреждений, которая отправляет бедному человеку сообщение о поддержке
Что еще более важно, большинство фреймворков ведения журналов позволяют вам указывать уровень журналирования для разных классов, поэтому вам не нужно вырезать новый двоичный файл каждый раз, когда вы хотите больше / меньше журнала (это подробное ведение журнала для ошибки, которую вы только что заметили в производстве)
Сайт Log4Net имеет более подробную информацию
В зависимости от того, насколько умна ваша собственная реализация системы регистрации.
В java, если вы хотите наследовать типы журналов и т. д., Это может быть слишком хлопотно, и вы бы предпочли сторонний инструмент, такой как Log4J. Я предполагаю, что для C# есть похожие вещи. Аналогично, если вы хотите определить уровень журнала из командной строки.
Если вы просто хотите маршрутизировать все ваши System.out и контролировать, будут ли они печататься при компиляции, ваш собственный регистратор подойдет.
Одним словом: гибкость. Log4xxx дает вам возможность выполнять разные уровни ведения журнала, записывать разные модули кода в разные файлы, и вы можете быть уверены, что он будет надежным, независимо от того, в какой странной ситуации он попадает (что будет делать ваш регистратор, если на диске нет места ?)
Что-то упущено в других комментариях: если уже есть библиотека, которая делает то, что вы хотите, это избавляет вас от необходимости писать код.
Возможно, вы здесь играете в семантику: для меня «фреймворк журналирования» обычно является немного больше, чем класс, который записывает сообщения журнала в файл ... так что вы написали свою собственную структуру журналирования. Учитывая, что вы это сделали, очевидно, что есть точка немного в «использовании фреймворка ведения журнала»!
В конечном итоге вам нужно будет убедиться, что он правильно обрабатывает одновременное ведение журнала (блокирует выходной поток), может вести журнал в файл, системный журнал и т. д., Может выполнять прокрутку журнала и т. д. Вы можете сэкономить эти усилия, используя чей-то хорошо протестированный код.
Фреймворки ведения журнала предлагают гибкость и не позволяют изобретать велосипед заново. Я знаю, что добавить к файлу на любом современном языке очень просто, но есть ли у вашего домашнего регистратора несколько целей? Можете ли вы включить и выключить вход во время выполнения? Зачем рисковать спущенной шиной, если эти колеса доступны бесплатно?
Отличный вопрос.
Первая причина - "почему бы и нет?" Если вы используете фреймворк для ведения журналов, вы сможете воспользоваться преимуществами ремонтопригодности от использования чего-то уже упакованного.
Вторая причина в том, что ведение журнала незаметно. Различные потоки, сеансы, классы и экземпляры объектов могут вступать в игру при ведении журнала, и вам не нужно решать эту проблему на лету.
Третья причина заключается в том, что вы можете обнаружить в своем коде узкое место в производительности. Выяснить, что ваш код работает медленно из-за того, что вы пишете в файл без буферизации или на жестком диске закончилось дисковое пространство, потому что регистратор не выполняет опрокидывание и не сжимает старые файлы, может быть головной болью.
Четвертая причина заключается в том, что вы можете захотеть добавить в системный журнал, или записать в базу данных, или в сокет, или в другие файлы. В фреймворки встроена эта функция.
Но на самом деле первый ответ - лучший; очень мало пользы от написания собственного текста и целый ряд недостатков.
Ради аргумента, почему бы не выращивать зрелый дом? который не идет с дополнительным багажом, и вы полностью контролируете его.
Большинство фреймворков логирования имеют слишком много функций, которые мы действительно не используем большинством из них, и, как было сказано, они идут с собственным багажом (это просто не класс, это фреймворк). Почему бы не реализовать простое домашнее ведение журнала, где все ваши приложения записывают журналы в очередь, а простая автономная служба (может быть служба Windows) считывает очередь и записывает ее в желаемое место (файл, базу данных и т. д.). Используя очередь, вы можете добиться асинхронной работы и без проблем с блокировкой.
Я хотел бы указать на старый метафор «не изобретайте колесо заново». Большинство фреймворков оптимизированы до такой степени, что почти не влияют на производительность. Такие компании, как Apache, имеют встроенные в свои приложения фреймворки для ведения журналов, потому что плюсы всегда взвешивают минусы.
Я не совсем понимаю, о чем вы здесь говорите и как это отвечает на вопрос. Вы предлагаете вместо использования сторонней платформы ведения журналов написать свою структуру своя. Вы предлагаете общую очередь между приложениями и всей службой для фиксации сообщений в хранилище; как это "просто"? Разве это не квалифицируется как большая и сложная «структура» сама по себе? Кроме того, возникает вопрос о том, как реализовать ведение журнала для «небольших приложений», но вы предлагаете связать небольшое приложение с большим механизмом ведения журнала?
«Безумно просто добавить в файл» - против многопоточности и особенно многоядерности, когда потоки действительно выполняются одновременно? ETW от Microsoft предлагает буферизацию записей ETW для каждого процессора, что, как мне кажется, является идеальным решением.