журнал логирования что это
Лог: что это, зачем нужен и где его найти?
Зачем нужны лог файлы?
В некоторых ситуациях каждому пользователю ПК или сервера требуется проверить логи. Рассмотрим зачем именно нужны лог файлы.
1. Логи могут понадобится, если нужно узнать статистику по сайту. Например, логи сайтов отображают следующую информацию:
а) статистику посещаемости
б) точки входа и выхода с сайта
в) поисковые запросы, по которым приходят посетители, и наиболее популярные страницы сайта
г) поисковики, страны и браузеры посетителей
д) уровень конверсии и страницы сайта, которые никто не посещает
е) сайты, которые ссылаются на этот ресурс.
2. В случае вирусов или Дддос атаки на сайт, логи помогут быстрее выяснить причину и соответственно помочь устранить ее.
3. Для восстановления доступов испольузются логи авторизации, которые собирают данные о попытках входа.
4. В случае ошибок в работе определенного ПО, устройства или ОС, когда необходимо определить источник проблемы.
Логи (server logs) помогают контролировать работу серверной машины и в случае возникновения ошибок быстро их находить и устранять. Логи используются практически везде, где ведется запись и прослеживание истории программного процесса. В первую очередь это необходимо в целях безопасности. Для того, чтобы найти и проанализировать логи, используют специально предназначенное для этого ПО. Некоторые логи могут обладать очень большим размером, поэтому время от времени их нужно очищать. Лог файл показывает события и его непосредственный источник. Причиной события может быть:
Какие есть виды логов?
На практике видов логов может быть несколько. Рассмотрим каждый из них.
Как найти логи?
Место, где находятся логи зависит от используемого ПО, заданных настроек и пути, который заведомо установил администратор сервера.
Если вам нужно найти лог файлы сервера или хостинга, вы можете обратится и получить подробную консультацию у вашего хостинг-провайдера, где размещается ваш сайт.
Названия файлов: журнал ошибок – error.log; журнал доступов – log; основной журнал – syslog; журнал загрузки системы – dmesg.
В ОС Windows свой способ структуризации логов, в котором выделяют уровни событий: подробности; сведения; предупреждение; ошибка; критический. Пользователь может сортировать и фильтровать записи, в зависимости от того, что именно ему нужно.
Что делать с логами?
Лог файлы могут понадобится во многих ситуациях при работе с сайтов, ПК или сервером. Но обратите внимания, что логи не хранятся вечно, поэтому если появилась необходимость проверить их, то следует это делать своевременно. Например, часто хостинг-провайдеры хранят логи до 14 дней, а далее они удаляются и записываются новые. Поэтому если ваш сайт взломали более нескольких недель назад, то установить причину по логам не получится, если логи уже удалены.
Даже беглый анализ логов может помочь выяснить причины чрезмерной нагрузки на сайт, поэтому если вам нужна помощь, чтобы разобраться с логами и исправить возникшие ошибки работы сервера, обращайтесь в техническую поддержку ГиперХост.
Включение и выключение записей логов на сервере происходит в панели управления. В большинстве случаев эта функция доступна в разделе панели Журнал или Логи. Более детально об этом вы можете уточнить непосредственно у вашего хостера.
Давайте поговорим о ведении логов
Этот пост вдохновлен темой в форуме Go Forum, начатой Nate Finch. Этот пост сконцентрирован на языке Go, но если пройти мимо этого, я думаю, идеи представленные тут широко применимы.
Почему нет любви?
Пакет log в Go не имеет уровней для логов, вы можете сами вручную добавить приставки DEBUG, INFO, WARN, и ERROR. Также logger тип в Go не имеет возможности включить или выключить эти уровни отдельно для выбранных пакетов. Для сравнения давайте глянем на несколько его замен от сторонних разработчиков.
glog от Google имеет уровни:
Перед вами два примера, явно созданных под влиянием других библиотек для логирования на других языках.
Фактически их происхождение можно проследить до syslog(3), возможно, даже раньше. И я думаю, что они не правы.
Я хочу занять противоречивую позицию. Я думаю, что все библиотеки журналов плохи, потому что предлагают слишком много функций; ошеломляющий набор возможностей, который ошеломляет программиста прямо в тот момент, когда он должен ясно думать о том, как общаться с читателем из будущего, с тем, кто будет просматривать эти журналы.
Я утверждаю, что для успешных пакетов логов требуется гораздо меньше возможностей и, конечно, меньше уровней.
Давайте поговорим о предупреждениях (WARNING)
Давайте начнем с самого простого. Никому не нужен уровень журнала WARNING (предупреждение).
Никто не читает предупреждения, потому что по определению ничего плохого не произошло. Возможно, что-то может пойти не так в будущем, но это звучит как чья-то, a не моя проблема.
Кроме того, если вы используете какое-то многоуровневое логирование, зачем вам устанавливать уровень WARNING? Вы установили бы уровень INFO или ERROR. Установка уровня WARNING означает, что вы, вероятно, регистрируете ошибки на уровне WARNING.
Исключите уровень warning — это или информационное сообщение, или ошибка.
Давайте поговорим об уровне невосстановимой ошибки (fatal)
Уровень FATAL фактически заносит сообщение в лог, а затем вызывает os.Exit(1). В принципе это означает:
Общепринято, что библиотеки не должны использовать panic1, но если вызов log.Fatal2 имеет тот же эффект, он также должен быть запрещен.
Предположения, что эта проблема очистки может быть решена путем регистрации обработчиков завершения работы в логгере, обеспечивает тесную связь между используемым логгером и каждым местом, где происходят операции очистки. Это также нарушает разделение интересов.
Не записывайте сообщения с уровнем FATAL, предпочтите вместо этого вернуть ошибку вызывающей стороне. Если ошибка доходит до main.main, то это правильное место для выполнения любых действий по очистке перед завершением программы.
Давайте поговорим об ошибке (уровень ERROR)
Обработка ошибок и ведение журнала (лога) тесно связаны, поэтому, на первый взгляд, регистрация на уровне ошибок (ERROR) должна быть легко оправданной. Я не согласен.
В Go, если вызов функции или метода возвращает значение ошибки, то реально у вас есть два варианта:
Позвольте мне убедить вас с помощью этого фрагмента кода:
Вы никогда не должны регистрировать что-либо на уровне ошибки, потому что вы должны либо обработать ошибку, либо передать ее вызывающей стороне.
Нужно четко понимать, я не говорю, что вы не должны записывать в лог, что произошла смена состояния:
Но в действительности log.Info и log.Error имеют одну и ту же цель.
Я не говорю «не регистрируйте ошибки»! Вместо этого я ставлю вопрос, что является наименьшим возможным API для ведения журнала (логирования)? И когда дело доходит до ошибок, я считаю, что подавляющая часть вещей, записанных на уровне ERROR, просто делается так, потому что они связаны с ошибкой. На самом деле они просто информационные, поэтому мы можем удалить логирование на уровне ошибок (ERROR) из нашего API.
Что осталось?
Мы исключили предупреждения (WARNING), аргументировали, что ничего не должно регистрироваться на уровне ошибок (ERROR), и показали, что только верхний уровень приложения должен иметь своего рода log.Fatal поведение. Что осталось?
Я считаю, что есть только две вещи, которые вы должны заносить в лог:
log.Info должен просто записать эту строку в вывод журнала. Не должно быть возможности отключить его, так как пользователю следует рассказывать только то, что ему полезно. Если возникает ошибка, которая не может быть обработана, она должна появиться в main.main там, где программа завершается. Незначительные неудобства, связанные с необходимостью вставки префикса FATAL перед окончательным сообщением журнала или записи непосредственно в os.Stderr с помощью fmt.Fprintf, не является достаточным основанием для расширения пакета матодом log.Fatal.
log.Debug, это совсем другое дело. Он нужен разработчику или инженера поддержки для контроля работы программы. Во время разработки выражения отладки (debug) должны быть многочисленными, не прибегая к уровню трассировки (trace) или debug2 (ты знаешь кто ты). Пакет ведения логов должен поддерживать детализированное управление для включения или отключения выражений отладки, для нужных пакетов пакете или, возможно, даже в более узкой области видимости.
Заключение
Если бы это был опрос в Твиттере, я бы попросил вас выбрать между
Как вы думаете? Это достаточно сумасбродно, чтобы работать, или просто сумасбродно?
Примечания
Некоторые библиотеки могут использовать panic/recover в качестве механизма внутреннего потока управления, но основная мантра заключается в том, что они не должны допускать утечки этих операций потока управления за границу пакета.
По иронии судьбы, хотя в нем отсутствует уровень вывода DEBUG, стандартный пакет логирования Go имеет функции Fatal и Panic. В этом пакете количество функций, которые приводят к внезапному завершению работы программы, превышает число тех, которые этого не делают.
Об авторе
Автор данной статьи, Дейв Чини, является автором многих популярных пакетов для Go, например github.com/pkg/errors и github.com/davecheney/httpstat. Авторитет и опыт автора вы можете оценить самостоятельно.
От переводчика
Насчет ведения логов обеспокоено достаточно много разработчиков, некоторые обсуждали внесение Logger интерфейса в стандартную библиотеку Go, чтобы упорядочить ведение логов в библиотеках и так стимулировать их разработчиков. Ребята даже оформили свое предложение и выставили документ на обсуждение.
Плюс презентация размышление Нужен ли нам новый логер и каким он должен быть? от Chris Hines.
Есть несколько реализаций идей Дейва go-log и немного отходящий в вопросе уровня ERROR и более тщательно продуманный пакет logr.
Какие виды лог-файлов бывают
Вебмастерам нужно получать информацию о том, как работает их сайт и сервер. Это можно узнать из log-файлов.
На виртуальном хостинге владельцы сайтов работают с логами web-сервера, доступ к которым предоставляет провайдер.
На VPS/VDS и выделенных серверах можно работать с самыми разнообразными логами, которые записывают все работающие на сервере службы.
Информация, хранящаяся в лог-файлах, служит основой для диагностики работы различных системных служб, а также для разнообразной аналитики, например, о посещаемости сайта или о попытках взлома системы.
На платформе Windows также имеется служба журналирования событий, но там информация записывается не в текстовые файлы, а в журналы специального формата, доступ к информации которых возможен через службу Event Viewer.
Log-файлы и виртуальный хостинг
Провайдер хостинга обеспечивает доступ к лог-файлам web-сервера через панель управления. Например, у провайдера Beget это выглядит так.
Также доступ к лог-файлам конкретного сайта можно получить через файл-менеджер (или по протоколу FTP).
У провайдера Beget в менеджере файлов их можно найти здесь.
При использовании популярной панели ISPmanager log-файлы доступны пользователю и располагаются в каталоге /log. Для каждого из сайтов присутствуют два лог-файла:
Виды лог-файлов
Все программы и сервисы Linux ведут log-файлы.
Log-файлы на сервере хранятся в специальном каталоге /var/log, внутри которого создаются отдельные файлы и папки для того или иного сервиса.
Различие в хранении log-файлов по версиям Linux
Дистрибутивы Linux имеют разный набор программного обеспечения и различные правила хранении log-файлов. В настоящее время наибольшее распространение получили два семейства дистрибутивов Linux:
Конкретная версия операционной системы для VPS/VDS выбирается у провайдера в личном кабинете пользователя перед заказом виртуального сервера.
Общие принципы для всех систем Linux одинаковы: log-файлы хранятся в папке /var/log. Разница проявляется лишь в наименовании отдельных файлов и каталогов для определенных подсистем, что зависит не только от версии Linux, но и от используемой панели управления хостингом.
Системные log-файлы
Опишем наиболее важные системные лог-файлы, хранящиеся в каталоге /var/log.
1. Общий системный журнал, в зависимости от версии Linux, записывается в файлы /var/log/syslog (Debian) или /var/log/messages (Redhat). В него пишется информация, начиная от старта системы:
2. Логи авторизации: /var/log/auth.log (Debian) или /var/log/secure (Redhat). Сюда записывается информация об авторизации пользователей, включая неудачные попытки входа в систему.
3. /var/log/dmesg и /var/log/kern.log— сообщения ядра и драйверов устройств.
Логи web-сервера
Как правило, сайты на сервере работают под управлением web-сервера Apache или Nginx. Также их можно применять на сервере вместе, что позволит использовать сильные стороны каждой программы.
Также к логам веб-сервера относятся лог-файлы интерпретатора PHP (php-fpm) и файлы ошибок PHP.
Логи web-сервера Apache
Web-сервер Apache создает два лог-файла:
Для удобства эти файлы могут создаваться по отдельности для каждого сайта, размещенного на сервере. Тогда они имеют названия “domain.name_access.log” и “domain.name_error.log”.
На Linux-системах семейства Debian логи Apache хранятся в каталоге /var/log/apache2, для систем, основанных на RedHat в /var/log/httpd.
Для чтения информации из log-файла можно использовать команду “cat имя-лог-файла” или “tail имя-log-файла”.
В зависимости от конкретной панели управления файлами, внутри этого каталога могут находиться папки domains или domlogs, в которых будут записываться лог-файлы отдельно для каждого сайта.
Логи web-сервера Nginx
Если Nginx настроен для обслуживания нескольких сайтов, то его лог-файлы записываются отдельно для каждого сайта.
Пример: вывод командой “ls *.log” списка log-файлов web-сервера nginx в папке /var/log/nginx/domains (на снимке экрана видно, что там хранятся файлы сразу нескольких сайтов)
Логи интерпретатора PHP
Если интерпретатор PHP работает отдельно в виде сервера PHP-FPM, то его логи хранятся на сервере также отдельно в каталоге /var/log/php-fpm. Если PHP используется как модуль Apache или через подсистему CGI, то его сообщения об ошибках записываются в лог Apache (error.log).
Ротация log-файлов
Для посещаемого сайта размеры лог-файлов могут достигать сотен мегабайт. Рано или поздно они начинают занимать много дискового пространства, поэтому на серверах Linux используется механизм ротации log-файлов.
Как это работает?
1. Данные о посетителях (или ошибках) сайта записываются в файл с обычным названием, например, access.log.
2. Раз в сутки (обычно в ночное время) этот файл автоматически переименовывается в “access.log.1” и сжимается архиватором Gzip.
3. Имя файла становится вида “access.log1.gz”.
4. Вместо этого файла web-сервер начинает записывать информацию в новый файл access.log.
5. Еще через сутки архивный файл “access.log.1.gz” переименовывается в “access.log.2.gz”, и вместо него создается новый архив “access.log.1.gz” из текущего log-файла web-сервера и так далее.
Всего на сервере хранятся сжатые log-файлы за последний месяц.
Пример: на снимке экрана виден список log-файлов web-сервера. Среди них присутствуют как текущие файлы access.log и error.log за сегодняшний день, так и файлы за предыдущие дни access.log.1, error.log.1 и так далее.
Таким образом, ротация файлов помогает сохранять место на диске. Зная общий принцип, по которому именуются сжатые лог-файлы, системный администратор может найти нужную информацию за конкретный период времени.
Log-файлы почтовой системы
Log-файлы FTP-сервера
Вариантов программного обеспечения для FTP Linux много, но принцип хранения log-файлов примерно одинаковый. В папке /var/log создаются log-файлы FTP-сервера, например, vsftpd.log или proftpd.log. Также практически всеми FTP-серверами создается файл xferlog, в котором записывается информация о файлах, скачанных с сервера или закачанных на сервер по протоколу FTP.
Log-файлы сервера базы данных
Популярный сервер базы данных MySQL также ведет log-файл “mysqld.log”. Он располагается в папке /var/log/mysql или /var/log/mariadb, в зависимости от используемой версии MySQL.
Также сервер MySQL может создавать в этой папке файл отладки медленных запросов к базе данных. Обычно он называется “mysql_slow.log”.
Пример: содержимое файла медленных запросов MySQL. Вывод содержимого log-файла командой “tail mysql_slow.log”
Использование log-файлов для отладки работы web-сайтов
Web-сервер Apache (также и Nginx) создают файл, который может называться просто error.log (error_log). В случае большого количества web-сайтов на сервере он будет иметь вид domain.ru.error.log.
Если, например, конкретный web-сайт показывает в браузере ошибку 500, то можно зайти в этот файл и посмотреть, что именно происходит на сервере.
Пример: просмотр лог-файла ошибок web-сервера из панели провайдера Beget через файл-менеджер
После открытия log-файла пользователь видит, что в исходном коде скрипта PHP допущена ошибка, которую надо исправить.
Например, если пользователь применяет панель VestaCP на своем виртуальном сервере, то для просмотра лог-файлов для сайта mysite.ru ему необходимо в командной строке сервера зайти в каталог /home/admin/web/mysite.ru/logs.
Пример: содержимое рабочего каталога панели VestaCP. Виден каталог logs, в котором хранятся log-файлы
Последние строки лог-файла будут содержать сообщение об ошибке, например:
Пример: просмотр сообщения об ошибках в файлах error.log с помощью команды tail: В этом конкретном примере пользователь видит в записях log-файла, что происходит ошибка интерпретатора PHP при обращении к базе данных MySQL.
Использование log-файлов для аналитики
Любому владельцу сайта нужно знать аудиторию своих посетителей. Эта информация содержится в лог-файлах посещений web-сервера (access.log). Для удобной обработки информации провайдеры хостинга, а также панели управления предлагают такие системы: Webalizer и AWStats.
Пример: аналитика посещений web-сайта с использованием системы AWStats
Также на основе лог-файлов можно получить представление о распределении нагрузки на сайт по времени суток, следить за ошибками ненайденных страниц, вести мониторинг безопасности.
Логирование. NLog Platform. Зачем нужны логи в приложении
Здесь мы затронем тему логирования в нашем приложении, что такое логи, и как правильно вести логи, насколько это необходимо и полезно. Рассмотрим систему логирования NLog Platform.
Ведение логов помогает разработчику в процессе создания и последующего сопровождения приложения, при поиске ошибок в коде и в разрешении непонятных ситуаций, когда наше приложение в момент работы ведет себя странным образом, и нам нужно найти причину такого поведения.
Любой разработчик сталкивается с подобными ситуациями, когда какой-то компонент приложения отрабатывает странным образом, выдает не тот результат или вообще перестает работать. Использование логов поможет нам в подобных ситуациях. Время поиска проблемных мест в нашем коде сократится в разы, и мы быстрее сможем решить ту или иную проблему.
Вообще, на сегодняшний момент ни одно более или менее серьезное приложение не обходится без написания логов.
Под таким журналом можно понимать и записи в обычный текстовый файл, и записи в базу данных, и записи на удаленный веб-сервис, и даже email-письма на определенный адрес о тех или иных состояниях нашего приложения.
Какие записи делать в этот журнал, то есть, какую конкретно информацию записывать, определяет сам разработчик. Это могут быть сведения о том, что все работает в штатном режиме, то есть просто ежедневный мониторинг нашего приложения, или что произошла какая-то ошибка, на которую нужно максимально срочно отреагировать и устранить, и так далее.
Всего существует шесть уровней логирования, каждый из которых предназначен для сообщений того или иного типа, той или иной важности:
Trace – максимально детальная информация о том, что происходит с целевым участком кода, по шагам. Например: Попытка открыть подключение к БД, успешно\неуспешно. Сколько времени заняла эта операция. Сколько времени выполнялась выборка из БД, успешно\неуспешно. Сколько записей извлечено. Какая была нагрузка на систему, сколько использовано памяти. Сколько записей прошло нужную фильтрацию. Сколько записей оказалось в результирующей выборке, куда эти записи отправились дальше. Проверка нужных значений в каждой записи.
Debug – это информация для отладки. Логирование крупных операций, менее детально, чем в Trace. Здесь мы не так подробно описываем весь процесс операции, но, тем не менее, заносим в журнал основные операции. Например: Совершено обращение к БД. Из базы выбрано N записей. Записи успешно обработаны и отправлены клиенту.
Info – это более общие информационные сообщения о текущей работе приложения, что происходит с системой в процессе ее использования. Например: Была выгрузка студентов в Excel-файл. На сайте зарегистрирован новый студент. Студент добавил новый отчет. Студент перемещен в другую группу.
Warn – сообщения о странной или подозрительной работе приложения. Это еще не серьезная ошибка, но следует обратить внимание на такое поведение системы. Например: Добавлен студент с возрастом 2 года. Студент получил отрицательный балл. Преподаватель завершил курс, в котором училось 0 студентов. В группе находится больше студентов, чем максимально возможно.
Error – сообщения об ошибках в приложении. Подобные сообщения – это уже большая проблема, которую нужно решить для дальнейшей правильной работы системы. Например: Ошибка сохранения нового студента в БД. Невозможно загрузить студентов в данной группе. Ошибка при входе в личный кабинет студента.
Fatal – сообщения об очень серьезных ошибках в системе. Чаще всего это связано с работоспособностью всего приложения или его окружения на сервере. На такие сообщения следует реагировать МАКСИМАЛЬНО оперативно. Например: Приложение постоянно перезагружается из-за нехватки памяти или места на жестком диске. Приложение завершило работу по неизвестной причине. Нет доступа к базе данных. Нет доступа к сети. Заблокирован какой-то порт.
То есть, прежде чем отправить какое-то сообщение в лог, нам нужно отнести его к той или иной группе.
Например, мы написали новый функционал и хотим его протестировать, как правильно и быстро он работает. Для этого мы будем использовать тип сообщений Trace, то есть все наши сообщения в логе будут помечены как Trace.
Подобным образом мы можем описать, как работает наше приложение в целом, сообщения будут с пометкой Info.
Если же в опасных участках кода мы генерируем исключение, то теперь мы также добавим запись в лог с пометкой Error.
К какой группе отнести то или иное сообщение решает сам разработчик. К данному вопросу следует подойти с максимальной серьезностью. Очевидно, что ошибки не следует помечать как Info, не следует игнорировать ошибки и просто не записывать их в лог. От правильно настроенной системы логирования будет зависеть простота сопровождения всей системы, оперативность реагирования на ошибки и время, затраченное на устранение проблемы.
Иногда разработчики ленятся писать логи, не хотят тратить на это время. В дальнейшем оказывается, что время, затраченное на поиск и исправление ошибок, в разы больше времени, которое потребовалось бы на создание системы логов.
Естественно, многое зависит от сложности проекта. Если вы создаете простейший трехстраничный сайт-визитку или консольное приложение для собственных нужд у себя на локальном компьютере, то написание сложной системы логирования может быть дольше, чем создание самого проекта. В таком случае в логи можно записывать только сообщения об ошибках или почему упал сайт. Но если вы работаете над сложным проектом в команде с другими разработчиками, то грамотное ведение логов просто обязательно.
Для того, чтобы начать логирование, мы подключим в наш проект платформу NLog. Это можно легко сделать посредством менеджера NuGet (прямо из Visual Studio).
Обратите внимание на конфигурационный файл NLog.config. В этом файле находятся настройки логгера (куда будут выводиться логи, формат записи логов и т.д.). Давайте настроим файл следующим образом:
Далее уже в коде объявим новый логгер (здесь код проекта приводится в сокращенном виде, исходный код всего проекта можно скачать в конце статьи):
Чаще всего следует объявлять один статичный логгер в пределах всего класса. Здесь мы посредством класса-менеджера LogManager объявили новый логгер, с которым будем работать.
Начнем логирование с уровня Trace. В методе, где мы выбираем студента по его идентификатору, давайте максимально подробно опишем как это происходит:
Теперь давайте добавим несколько сообщений уровня Debug. Как мы помним, это тоже отладочная информация, но менее детальная. Данный подход мы используем в другом методе, для наглядности:
Идем далее. На уровне Info мы описываем регулярные операции в нашем приложении, то есть поднимаемся еще на уровень выше. Предположим, что мы работаем над ASP.NET MVC приложением, и у нас есть действие в контроллере, которое обращается к ранее описанному методу GetStudentById():
Теперь добавим в логи сообщения уровня Warn. Как мы помним, на этом уровне логирования мы описываем все потенциально опасные ситуации, странное и нелогичное поведение компонентов. Будем заносить в лог запись, если студенту меньше 15 лет:
Далее обработаем ошибку в нашем коде и запишем в лог сообщение уровня Error:
Теперь определим, что же нам записать на уровне Fatal. В нашем простейшем примере просто смоделируем подобную ситуацию:
Мы рассмотрели все шесть уровней логирования и описали процесс работы нашего приложения максимально подробно. Теперь мы можем сразу проанализировать работу сайта, просто изучив логи, и не заглядывать в исходный код.
Подобным образом происходит логирование. В нашем простейшем примере, где мы моделируем работу со студентами, все предельно ясно и прозрачно даже без логов. Но в сложных проектах ведение логов является неотъемлемой частью разработки.
Конечно, это далеко не полные возможности настройки платформы NLog. В конфигурационном файле можно настроить запись логов в другие места, например, в базу данных, на консоль, в оперативную память, отправлять как емаил-сообщение, отправлять сообщения по сети и так далее. Также можно настроить фильтрацию сообщений, более сложный шаблон сообщений. Если вас не устраивает стандартный функционал логгера, то можно написать свое собственное расширение и подключить.
На этом здесь все, давайте подведем небольшой итог. Мы изучили тему логирования в приложении. Посмотрели как правильно логировать те или иные участки кода, а также познакомились с одной из самых популярных платформ логирования – это NLog Platform, также рассмотрели ее возможности и как можно настроить генерацию логов на этой платформе.