Лог файлы Linux по порядку / Хабр

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

Журналирование является основным источником информации о работе системы и ее ошибках. В этом кратком руководстве рассмотрим основные аспекты журналирования операционной системы, структуру каталогов, программы для чтения и обзора логов.

Основные лог файлы

Все файлы журналов, можно отнести к одной из следующих категорий:

• приложения;
• события;
• службы;
• системный.

Большинство же лог файлов содержится в директории /var/log.

• /var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
• /var/log/auth.log или /var/log/secure — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
• /var/log/dmesg — драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ --level= можно отфильтровать вывод по критерию значимости.

Поддерживаемые уровни журналирования (приоритеты):
   emerg - система неиспользуемая
   alert - действие должно быть произведено немедленно
    crit - условия критичности
     err - условия ошибок
    warn - условия предупреждений
  notice - обычные, но значимые условия
    info - информационный
   debug - отладочные сообщения

(5:520)$ dmesg -l err
[1131424.604352] usb 1-1.1: 2:1: cannot get freq at ep 0x1
[1131424.666013] usb 1-1.1: 1:1: cannot get freq at ep 0x81
[1131424.749378] usb 1-1.1: 1:1: cannot get freq at ep 0x81
 

• /var/log/alternatives.log — Вывод программы update-alternatives, в котором находятся символические ссылки на команды или библиотеки по умолчанию.
• /var/log/anaconda.log — Записи, зарегистрированные во время установки системы.
• /var/log/audit — Записи, созданные службой аудита auditd.
• /var/log/boot.log — Информация, которая пишется при загрузке операционной системы.
• /var/log/cron — Отчет службы crond об исполняемых командах и сообщения от самих команд.
• /var/log/cups — Все, что связано с печатью и принтерами.
• /var/log/faillog — Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog.
• var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
• /var/log/maillog/ или /var/log/mail.log — Журнал почтового сервера, используемого на ОС.
• /var/log/pm-powersave.log — Сообщения службы экономии заряда батареи.
• /var/log/samba/ — Логи файлового сервера Samba, который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
• /var/log/spooler — Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
• /var/log/Xorg.0.log — Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.

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

• /var/log/yum.log — Для программ установленных с помощью Yum в RedHat Linux.
• /var/log/emerge.log — Для ebuild-ов установленных из Portage с помощью emerge в Gentoo Linux.
• /var/log/dpkg.log — Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.

И немного бинарных журналов учета пользовательских сессий.

• /var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой last.
• /var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2.
• /var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
• /var/log/utmp — Список входов пользователей в систему на данный момент.
• /var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump.

(5:535)$ sudo utmpdump /var/log/wtmp
[5] [02187] [l0  ] [        ] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:07 2015]
[1] [00000] [~~  ] [shutdown] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:08 2015]
[2] [00000] [~~  ] [reboot  ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[8] [00368] [rc  ] [        ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[1] [20019] [~~  ] [runlevel] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
 

И другие журналы

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

• /var/log/mysql/ — Лог базы данных MySQL.
• /var/log/httpd/ или /var/log/apache2/ — Лог веб сервера Apache, журнал доступа находится в access_log, а ошибки — в error_log.
• /var/log/lighthttpd/ — Лог веб сервера lighttpd.

В домашнем каталоге пользователя могут находится журналы графических приложений, DE.

• ~/.xsession-errors — Вывод stderr графических приложений X11.

Initializing  "kcm_input" :  "kcminit_mouse"
Initializing  "kcm_access" :  "kcminit_access"
Initializing  "kcm_kgamma" :  "kcminit_kgamma"
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
kf5.kcoreaddons.kaboutdata: Could not initialize the equivalent properties of Q*Application: no instance (yet) existing.
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
Qt: Session management error: networkIdsList argument is NULL

• ~/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

Чем просматривать — lnav

Почти все знают об утилите

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.

Установка пакета как обычно одной командой.

$ aptitude install lnav #Debian/Ubuntu/LinuxMint
$ yum install lnav #RedHat/CentOS
$ dnf install lnav #Fedora
$ emerge -av lnav #Gentoo, нужно добавить в файл package.accept_keywords
$ yaourt -S lnav #Arch 

Навигатор журналов lnav понимает ряд форматов файлов.

• Access_log веб сервера.
• CUPS page_log
• Syslog
• glog
• dpkg.log
• strace
• Произвольные записи с временными отметками
• gzip, bzip
• Журнал VMWare ESXi/vCenter

Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.

(5:471)$ sudo lnav /var/log/pm-powersave.log /var/log/pm-suspend.log

Программа умеет напрямую открывать архивный файл.

(5:471)$ lnav -r /var/log/Xorg.0.log.old.gz

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

Mon May 02 20:25:00        123 normal         3 errors         0 warnings         0 marks
Mon May 02 22:40:00          2 normal         0 errors         0 warnings         0 marks
Mon May 02 23:25:00         10 normal         0 errors         0 warnings         0 marks
Tue May 03 07:25:00         96 normal         3 errors         0 warnings         0 marks
Tue May 03 23:50:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 07:40:00         96 normal         3 errors         0 warnings         0 marks
Wed May 04 08:30:00          2 normal         0 errors         0 warnings         0 marks
Wed May 04 10:40:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 11:50:00        126 normal         2 errors         1 warnings         0 marks

Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь

Использованные материалы

1. lnav — An Advanced Log File viewer for Linux
2. What Are Linux Logs? How to View Them, Most Important Directories, and More
3. Как посмотреть логи в Linux

App log files как удалить

Эту короткую статью хочу посвятить наболевшей теме —

как почистить windows

Все больше людей задумывается, куда делось пространство на системном диске. Особенно остро это ощущают пользователи семерки.

Самый простой способ очистки свободного места – Это регулярное использование утилиты «Очистка диска»
Эта утилита поставляется вместе с системой и Вам не придется искать ее в сети.

Найти ее можно по следующему пути.
Пуск -> Все программы -> Стандартные -> Служебные -> Очистка диска.

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

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

Теперь немного о том, что можно смело очищать.

Downloaded Program Files – смело удаляйте, так как это вспомогательные файлы для просмотра web — страниц. Они загружаются каждый раз при просмотре страниц.

Временные файлы интернета – удаляем и стараемся делать это регулярно и почаще.

Автономные файлы – могут быть удалены без последствий.

Файлы находящиеся в корзине – удаляем, если уверенны, что не кинули в корзину, что-то нужное.

Временные файлы программ – если их возраст больше недели смело стираем.

Служба – WebClient/WebPublisher – файлы необходимые для увеличения быстродействия, а потому могут быть безболезненно удалены.

Одним из неплохих способов освободить место является сжатие свободного места.
При этом способе файлы не удаляются, а сжимаются. К таким файлам всегда можно вернуться для использования.

После выбора удаляемых файлов подтверждаем все настройки и ждем.
Программа удалит все ненужные файлы и закроется.

Есть еще две папки которые нужно почистить это:

1. Системный диск/windows (у Вас эта папка может называться по другому Win к примеру)/temp
   Все файлы этой папки можно смело удалять. Если при удалении какого-то файла появляется сообщение о невозможности удаления, не пугайтесь – это нормально, просто пропускайте их.
2. Системный диск/имя пользователя/appdata/temp
   appdata скрытая папка. Для быстрого перемещения откройте мой компьютер и в строке введите:
   %temp%

Все файлы можно удалить аналогично папки temp в системной директории. (пункт 1)

На этом все. Держите свой компьютер в чистоте и не забывайте чистить корзину.

Простой компьютерный блог для души)

Всем привет. Сегодня мы поговорим на тему лог-файлов, а вернее о том что такое Windows Log files. Значит сперва немного общей информации так бы сказать. Что такое лог-файлы? Это такие файлы, куда программа записывает свои действия — что у нее получилось сделать, а что нет, где произошла ошибка.. То есть можно сказать что лог-файл это типа отчета. Если вдруг случилась ошибка, то при помощи лог-файла можно попробовать понять где именно она появилась.

Но что такое Windows Log files? Ну логично что это лог-файлы винды. Может вы где-то нашли папку с названием Windows Log files? Если это папка, то удалять.. в принципе можно, но я думаю что не стоит.

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

Название Windows Log files может быть где угодно. Например это может быть папка, как я уже писал, а может быть еще пункт в проге по очистке системы, там может быть где-то галочка Windows Log files. И если эту галочку отметить, то будут в теории удалены лог-файлы.

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

Также забыл сказать, что вообще лог-файлы могут быть как у системы так и у любой программы, если в ней это заложено. Мне кажется что лог-файлы только для этого и придуманы — анализ работы программы, выявление ошибок. Другого на ум ничего не приходит =)

Вот давайте для примера я вам покажу лог-файлы. Самые обычные — они есть в каждой винде, я их даже искать не буду, я просто открою папку Windows. Итак, смотрите, зажимаем кнопки Win + R, потом пишем в окошку команду:

Нажали ОК и потом откроется самая важная и самая системная папка Windows, в ней сразу нажимаем на колонку Тип, чтобы отсортировать файлы по типам:

После этого все файлы с расширением log будут рядышком, стоит немного мышкой покрутить и вот они, у меня их тут всего четыре штуки, что-то даже как-то маловато:

Вот видите тут есть WindowsUpdate.log? Это лог-файл обновления винды, то есть в этом файле идет отчет об обновлениях, все ли там нормально, это просто пример, но я файл открыл и вот что внутри:

Вот здесь все как обычно — сначала идет дата, потом время, потом еще что-то.. даже не знаю что.. а потом идет описание события. Для примера я открыл еще файл setupact.log, здесь вот уже нет времени, даты, тут просто указана какая-то инфа:

Но все равно, традиционно лог-файл должен идти с датой и временем вначале каждой строки.

Так, а давайте поищем лог-файлы? Ну вообще посмотрим сколько их, в каких папках.. ребята, зажимаем Win + E, появится окно проводника, вы туда, а вернее в правом верхнем углу есть текстовое поле поиска, вот туда вставляете это:

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

Но видите там есть еще файлы с расширением LOG1? Я думаю что это не лог-файлы, то есть не отчеты, их даже открыть нельзя, типа нет проги которой можно открыть, выскакивает такое окошко:

Но я сделал вот что.. я выбрал второй пункт и там попробовал открыть при помощи блокнота, но увы, была ошибка и я кстати о ней писал, что такое может быть:

Ибо файл открыт системой для записи, а значит файл занят =) Но я попробовал другой. Это мы с вами пробовали открыть SYSTEM.LOG1, а я вот нашел другой файл COMPONENTS.LOG1 и его открыть я смог, но содержимое все равно непонятное:

Может это и лог файл, но как видим он идет в другой кодировке. Короче ладно.

Так, вернемся к Windows Log files.. а то я что-то прям очень увлекся лог-файлами. Я решил поискать картинки в интернете на тему Windows Log files, может что-то интересное найду.. вообще мало что есть интересного, но я нашел такую картинку, это чистилка CCleaner и тут как раз упоминается Windows Log files:

То есть на картинке мы видим что CCleaner может чистить комп от лог-файлов Windows =) Вот еще одна прога, тоже какая-то чистилка, но мне она незнакома, называется Sweepi и тут тоже есть пункт Windows Log files:

Видите, там еще есть Temporary Internet Files — это временные файлы интернета. Вообще везде где видите слово Temp, это все типа временное, поэтому его можно как бэ удалить типа для ускорения системы.

На всякий случай, мало что, я не знаю что там у вас — папка с названием Windows Log files или программа такая, или что-то еще.. Но перед любыми изменениями в винде я рекомендую создавать точку восстановления. И это не требует особых знаний. Вам нужно всего лишь зажать Win + R, вставить туда:

Потом там нужно выбрать системный диск и нажать кнопку Создать (но если нужно наоборот — то есть кнопка выше Восстановление):

Название точки советую задавать простое, например Удаление папки Windows Log files:

Процесс создания будет недолгим:

И все, потом будет написано что успешно:

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

На этом все друзья, надеюсь представленная информация для кого-то все таки оказалась полезной. Удачи вам и суперского настроения!

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

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

Использование командной строки вместо проводника

Хотя проводник и не обнаруживает все временные файлы (лишь их большую часть), он располагает замечательным интерфейсом, а возможность увидеть файлы перед удалением делает очистку значительно безопаснее, чем при использовании утилит командной строки. Все, что Вам требуется сделать после обнаружения временных файлов для их безвозвратного удаления из системы, — выделить и нажать клавиши Shift+Del.

Существует две утилиты командной строки, составляющие альтернативу проводнику — Del и Erase. Однако при их выполнении я рекомендую соблюдать осторожность. Убедитесь в наличии полной резервной копии системы и закройте как можно больше открытых приложений (по возможности оставьте только окно командной строки). Действуют утилиты Del и Erase одинаково, поэтому в качестве примера рассмотрим только утилиту Del. Чтобы удалить файл, введите в командной строке следующую команду:

Del имя_файла

Этот способ не предполагает возможности восстановления, поэтому Вы не обнаружите удаленные файлы в корзине. Ниже перечислены ключи утилиты Del.

• /А — удаляет файлы с заданным атрибутом. Атрибут указывается путем добавления идентифицирующей его буквы: А (архивный), Н (скрытый), R (только чтение) и S (системный). Атрибут может содержать знак — (минус), указывающий на то, что файлы с данным атрибутом, напротив, не следует удалять. Например, чтобы удалить файлы для чтения без системного атрибута, следует указать два ключа — /AR и /А-S.
• /F — удаляет файлы только для чтения. По умолчанию утилита Del игнорирует их, поскольку удаление таких файлов требует изменения их статуса. Никогда не используйте этот ключ при удалении временных файлов. При обнаружении временного файла с атрибутом «только чтение» выясните причину его установки. Возможно, это обусловлено проблемами в приложении, которое создало временный файл.
• /Р — предписывает утилите Del выводить запрос на подтверждение при удалении файла. Используйте этот ключ, если сомневаетесь в необходимости удаления всех файлов по заданному критерию. Хотя подобный метод займет у Вас некоторое время, это лучше, чем совершить ошибку, удалив полезные файлы.
• /Q — этот ключ самый опасный, поскольку отключает вывод на экран удаляемых файлов. Если Вы не желаете видеть файлы-, то более удачным решением является перенаправить вывод с экрана в файл. Например, чтобы удалить все файлы, начинающиеся с символа

(тильда), и перенаправить вывод в файл MyDeletions.TXT, введите команду:

Del /S > Удаленные_файлы.ТХТ

Список файлов не появится на экране, однако будет сохранен для последующего анализа.

• /S — удаляет все файлы, удовлетворяющие заданному критерию, в текущей папке и всех вложенных в нее папках. При использовании в корневой папке этот ключ позволяет удалить файлы определенного вида на всем замененном жестком диске. Следует пользоваться данной функцией с осторожностью — во вложенных папках могут оказаться файлы, соответствующие критерию удаления, которые, на самом деле, нужно сохранить.

Достоинства утилиты Del — ее высокое быстродействие и полнота. В отличие от проводника она не пропускает файлы и работает гораздо быстрее. С ее помощью можно очистить жесткий диск за считанные секунды, в то время как использование проводника занимает минуты.

Удаление файлов, начинающихся с тильды

Пожалуй, «самыми» временными файлами можно назвать те, чьи имена начинаются с символа

(тильда). Windows и многие приложения, используют файлы, начинающиеся с символа

(тильда) и не имеющие расширения, в основном, для хранения битов и фрагментов информации. При этом ни Word, ни другие приложения не прикладывают должных усилий к удалению этих файлов.

При наличии расширения (как, например, файлы, создаваемые Microsoft Word) временный файл представляет собой промежуточную форму документа, над которым Вы работаете. Тем не менее, если окно Word не открыто, а Вы видите подобные файлы на жестком диске, то это обычно указывает на некорректное завершение Word. В этом случае временные файлы могут быть использованы для восстановления потерянных данных документа. К сожалению, после восстановления временные файлы не удаляются, поэтому, возможно, имеет смысл удалить их вручную. Общая идея такова: файл с расширением, как правило, является временной версией документа, и ее не следует удалять, не приняв взвешенного решения.

Вне зависимости от того, сколько приложений Вы закроете при очистке жесткого диска, несколько файлов, начинающихся с символа

(тильда), все равно останутся открытыми. Как проводник, так и утилита Del выведут сообщения о том, что эти файлы используются, и откажутся удалять их при любых условиях. Просто оставьте эти файлы в покое.

Не удивляйтесь тому, что размер некоторых временных файлов равен 0 байт (другими словами, в них отсутствует информация). Часть этих файлов действительно пуста, а часть скрывает свою информацию при помощи так называемых потоков данных. Тем не менее, их следует удалить, чтобы освободить элементы каталога для других приложений. Иногда записей каталога не остается, что приводит к нестабильности системы.

Уничтожение ТМР и ВАК-файлов

Обычно удалить ТМР-файлы с жесткого диска можно, закрыв все приложения. Возможно, Windows оставит 1-2 файла открытыми, однако в ТМР-файле никогда не содержатся данные, которые пригодятся Вам в будущем. Удаление ТМР-файлов — дело вполне безопасное и безусловно полезное.

Аналогично ВАК файлы (резервные файлы) содержат старые копии документов, с которыми Вы работаете. После закрытия приложения ВАК-файл перестает использоваться, и Вы можете смело удалить его. Я, как правило, сохраняю ВАК-файлы до создания резервной копии жесткого диска, и удаляю их в процессе последующей очистки. ВАК-файл представляет собой временную резервную копию данных; Вы можете использовать его для восстановления данных, потерянных в результате сбоя приложения.

Не все приложения присваивают файлам расширение ВАК, например, Microsoft Word вместо ВАК использует расширение WBK. Назначение этих файлов то же самое, просто компания-разработчик делает все возможное, чтобы запутать пользователей. Расширения временных файлов должны быть указаны в руководстве пользователя приложения, однако иногда, чтобы определить их, необходимо создать файл и несколько раз сохранить его, а между сеансами сохранения обязательно модифицировать. Временный файл располагается в той же папке, что и исходный, имеет такое же имя, но использует расширение, выделенное приложением для резервных файлов.

Поиск LOG-файлов

LOG-файлы, как правило, представляют собой текстовые документы, описывающие результаты какой-либо процедуры, например, процедуры установки приложения. В случае ошибки LOG-файл сообщает о ней и иногда предлагает возможные варианты ее исправления. Windows создает LOG-файлы при обновлении, указывая в них имена обновленных файлов и описывая свои действия. Говоря кратко, LOG-файлы — это полезные протоколы системной деятельности.

К сожалению, ни Windows, ни приложения никогда не удаляют LOG-файлы, и в этом не следует обвинять компанию-поставщика или программиста, создавшего приложение. Предполагается, что Вы ознакомитесь с содержимым LOG- файла и, следуя соглашению с компанией, удалите или заархивируете его. Иногда само приложение уведомляет Вас о LOG-файле и действиях, которые следует предпринять. В большинстве же случаев приложение даже не сообщает о генерации LOG-файла. Узнать о моменте его создания и определить его местоположение — полностью ваша задача.

Любопытный факт заключается в том, что иногда Вы можете натолкнуться на приложения, использующие LOG-файлы постоянно. В этих случаях удалять LOG- файлы, разумеется, не следует. Например, UPS-приложения, которые я использую, пользуются LOG-файлом для вывода сообщений о событиях, связанных с питанием, например, скачках напряжения. В LOG-файле также содержится информация о времени последнего запуска процедуры диагностики и других выполненных действиях. Тем не менее, если я удалю этот файл, с UPS-приложением не произойдет ничего страшного — оно просто «забудет» прошлые события.

LOG-файлы, которые Вы можете безболезненно удалить, находятся в папках приложений и в папке Windows. Как правило, не следует удалять LOG-файлы из таких папок, как WindowsSystem32 и др. Вы можете начать с удаления LOG-файлов из папки Windows, предварительно прочитав или заархивировав их. После этого займитесь поиском остальных LOG-файлов системы. LOG-файлы, расположенные в папках приложений, следует прочитать, чтобы определить, используются ли они приложением. Если окажется, что нет, можете смело удалять их.

Рекомендуем к прочтению

Вертим логи как хотим ― анализ журналов в системах Windows / Блог компании Сервер Молл / Хабр

Пора поговорить про удобную работу с логами, тем более что в Windows есть масса неочевидных инструментов для этого. Например, Log Parser, который порой просто незаменим.

В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.

До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:

findstr "Fail" *.log >> fail.txt

Она позволяла получить в файле fail.txt все ошибки обмена. Но если было нужно что-то большее, вроде получения информации о предшествующей ошибке, то приходилось создавать монструозные скрипты с циклами for или использовать сторонние утилиты. По счастью, с появлением PowerShell эти проблемы ушли в прошлое.

Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:

Get-Content -Path 'C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log' | Out-Host -Paging

Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:

>Get-Content -Path "C:\Windows\WindowsUpdate.log" -Tail 5 -Wait

Смотрим за ходом обновления Windows.

Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:

Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern 'Drop' | Select-Object -Last 20 | Format-Table Line

Смотрим, кто пытается пролезть на наш дедик.

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

Select-String 'C:\Windows\Cluster\Reports\Cluster.log' -Pattern ' err ' ‑Context 3

Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:

Get-Content 'C:\Windows\debug\netlogon.log' | Select-Object -First 30 -Skip 45

Журналы системы ведутся в формате .evtx, и для работы с ними существуют отдельные командлеты. Для работы с классическими журналами («Приложение», «Система», и т.д.) используется Get-Eventlog. Этот командлет удобен, но не позволяет работать с остальными журналами приложений и служб. Для работы с любыми журналами, включая классические, существует более универсальный вариант ― Get-WinEvent. Остановимся на нем подробнее.

Для получения списка доступных системных журналов можно выполнить следующую команду:

Get-WinEvent -ListLog *

Вывод доступных журналов и информации о них.

Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:

Get-WinEvent -LogName 'System' -MaxEvents 20

Последние записи в журнале System.

Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.

Для примера получим все события из журнала System с кодом события 1 и 6013.

Get-WinEvent -FilterHashTable @{LogName='System';ID='1','6013'}

В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:

• 0 ― всегда записывать;
• 1 ― критический;
• 2 ― ошибка;
• 3 ― предупреждение;
• 4 ― информация;
• 5 ― подробный (Verbose).

Собрать хэш-таблицу с несколькими значениями важности одной командой так просто не получится. Если мы хотим получить ошибки и предупреждения из системного журнала, можно воспользоваться дополнительной фильтрацией при помощи Where-Object:

Get-WinEvent -FilterHashtable @{LogName='system'} | Where-Object -FilterScript {($_.Level -eq 2) -or ($_.Level -eq 3)}

Ошибки и предупреждения журнала System.

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

Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:

PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.

Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.

О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.

Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:

SELECT 
 extract_token(text, 0, ' ') as date, 
 extract_token(text, 1, ' ') as time,
 extract_token(text, 2, ' ') as action, 
 extract_token(text, 4, ' ') as src-ip,  
 extract_token(text, 7, ' ') as port 
FROM 'C:\Windows\System32\LogFiles\Firewall\pfirewall.log' 
WHERE action='DROP' AND port='3389'
ORDER BY date,time DESC

Посмотрим на результат:

Смотрим журнал Windows Firewall.

Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.

Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.

Работать будем с журналом TerminalServices-LocalSessionManager\Operational.

Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%\test.evtx.

Данные будем получать таким запросом:

SELECT
 timegenerated as Date, 
 extract_token(strings, 0, '|') as user,
 extract_token(strings, 2, '|') as sourceip 
FROM '%temp%\test.evtx'
WHERE EventID = 21
ORDER BY Date DESC

Смотрим, кто и когда подключался к нашему серверу терминалов.

Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.

В качестве примера посмотрим статистику количества писем по дням таким запросом:

SELECT
 TO_LOCALTIME(TO_TIMESTAMP(EXTRACT_PREFIX(TO_STRING([#Fields: date-time]),0,'T'), 'yyyy-MM-dd')) AS Date,
 COUNT(*) AS [Daily Email Traffic] 
FROM 'C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking\*.LOG'
WHERE (event-id='RECEIVE') GROUP BY Date ORDER BY Date ASC

Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.

Выполняем запрос и открываем получившуюся картинку…

Любуемся результатом.

Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.

$LogQuery = New-Object -ComObject "MSUtil.LogQuery"
$InputFormat = New-Object -ComObject "MSUtil.LogQuery.FileSystemInputFormat"
$InputFormat.Recurse = -1
$OutputFormat = New-Object -ComObject "MSUtil.LogQuery.CSVOutputFormat"
$SQLQuery = "SELECT Top 20 Path, Size INTO '%temp%\output.csv' FROM 'C:\*.*' ORDER BY Size DESC"
$LogQuery.ExecuteBatch($SQLQuery, $InputFormat, $OutputFormat)
$CSV = Import-Csv  $env:TEMP'\output.csv'
$CSV | fl 
Remove-Item $env:TEMP'\output.csv'
$LogQuery=$null
$InputFormat=$null
$OutputFormat=$null

Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.

Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для Log Parser. Платные рассматривать не буду, а вот бесплатную Log Parser Studio покажу.

Интерфейс Log Parser Studio.

Основной особенностью здесь является библиотека, которая позволяет держать все запросы в одном месте, без россыпи по папкам. Также сходу представлено множество готовых примеров, которые помогут разобраться с запросами.

Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.

В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:

Выборка наиболее активных ящиков.

При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.

Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.

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

Файл LOG – чем открыть, описание формата

Чем открыть, описание – 2 формата файла

1. Журнал событий — Текст, документы
2. Файл отчета Avira AntiVir — Файлы данных

Log File

Тип данных: Текстовый файл

Разработчик: Неизвестно

Подробное описание

Файл LOG — это файл регистрации событий, который может принадлежать различным программам, операционной системе или серверу. Такие файлы часто называют журналами или логами. Файл в текстовом формате содержит записи об определенных событиях программы или системы с указанием времени их наступления и дополнительных сведений, например, журнал авторизации пользователей, журнал ошибок операционной системы, журнал обновлений программы и т.д. Как правило, для просмотра LOG-файлов можно воспользоваться простым текстовым редактором, таким как Блокнот и Notepad++.

Как, чем открыть файл .log?

Инструкция — как выбрать программу из списка, скачать и использовать ее для открытия файла

Похожие форматы

AntiVir Report Log File

Тип данных: Текстовый файл

Разработчик: Avira Operations

Подробное описание

Отчет, созданный антивирусной программой Avira Antivirus. В простом текстовом формате файл LOG может содержать отчет о сканировании компьютера антивирусом либо обновлении программы и антивирусных баз. Список сохраненных отчетов можно просмотреть в разделе «Отчеты». Файл выбранного отчета будет открыт в текстовом редакторе, например, стандартном Блокноте Windows.

Как, чем открыть файл .log?

Инструкция — как выбрать программу из списка, скачать и использовать ее для открытия файла

Похожие форматы

Для более точного определения формата и программ для открытия файла используйте функцию определения формата файла по расширению и по данным (заголовку) файла.

Архитектура логирования / Хабр

Топик написан как продолжение к этой статье и будет полезен в первую очередь начинающим программистам.

Здесь я собираюсь осветить следующие вопросы:

• Внутреннее свойство логгера и примеры софта который его использует.
• Объемы, уровни и детализация сообщений лога.
• Общие правила конфигурации в разработке, в бою и в расследовании.

Итак, начну со своих дополнений к предыдущей статье.
Я как и автор пользуюсь NLog’ом и разумеется широко использую его особенности. Конечно, после
их реализации в любом другом логгере, нижеописанную практику можно применять и у них.

Кстати, log4net продолжает развиваться.

Собственно, требуемых дополнений к «Фичам добропорядочного логгера» всего два:

1. Наблюдение/перезагрузка файла конфигурации — это уже не просто полезное, а весьма необходимое умение.
2. Минимальное вмешательство в выключенном состоянии.

Под капотом NLog

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

Очевидно, что в боевом применении, даже выключенное подробное логирование, может мешать как скорости выполнения так и параллельности.

В NLog используются следующие приемы:

• Кэширование уровня логирования в volatile переменной. Это не требует блокировки или синхронизации потоков.
• Простой метод выяснения необходимости логирования. При некоторых условиях может приводить к inline-вставке кода в процессе jit-компиляции. А это превращает логику в простой условный пропуск участка кода и избавляет от копирования и передачи параметров функции логирования.
• Подробные перегрузки методов логирования. Минимизируют преобразование типов, а также берегут от напрасного боксинга, до того как мы выяснили о необходимости логирования.
• Отложенная генерация сообщения делегатом. Позволяет наглядно и легко задавать сложную генерацию сообщений.

Исходный код класса можно посмотреть тут.

Отлично! Для NLog можно быть уверенным, что ваши сколь угодно детальные сообщения могут быть отключены и это минимально скажется на производительности. Но, это не повод посвящать логированию половину кода.

Что и как логировать

Следует придерживаться правил:

• Вывод в лог следует размещать на отдельной строке.
• Сообщение должно быть максимально коротким и информативным.
• Локализовывать можно только редкие или фатальные сообщения.
• Аргументы желательно брать из локальных переменных метода или внутренних переменных класса данного метода.
• Не желательно использовать преобразования типов.

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

Простой пример (фрагмент некоторого класса):

private static Logger Log = LogManager.GetCurrentClassLogger();<br/>
 <br/>
public string Request(string cmd, string getParams)<br/>
{<br/>
    Uri uri = new Uri(_baseUri, cmd + "?" + getParams);<br/>
    Log.Debug("Request for uri:`{0}'", uri);<br/>
    HttpWebRequest webReq = (HttpWebRequest)WebRequest.Create(uri);<br/>
    webReq.Method = "GET";<br/>
    webReq.Timeout = _to;<br/>
 <br/>
    string respText;<br/>
    try<br/>
    {<br/>
        string page;<br/>
        using (WebResponse resp = webReq.GetResponse())<br/>
        using (Stream respS = resp.GetResponseStream())<br/>
        using (StreamReader sr = new StreamReader(respS))<br/>
            page = sr.ReadToEnd();<br/>
        Log.Trace("Response page:`{0}'", page);<br/>
        return page;<br/>
    }<br/>
    catch(Exception err)<br/>
    {<br/>
        Log.Warn("Request for uri:`{0}' exception: {1}", uri, err.Message);<br/>
        throw;<br/>
    }<br/>
}

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

Вообще, в текущем обработчике ошибок полезно детализировать контекст который к привел к исключению и специфичные особенности исключения. В примере было бы полезно вывести поле Status для случая WebException.

Гарантии сохранности лога

Несмотря на некоторые возможности NLog по авто записи логов, нет гарантии сохранности лога при завершении процесса.

Что интересно, попытка завершить запись обработкой события AppDomain.ProcessExit не совсем корректна. В конфигурации может быть настроено много разных способов записи в лог, в том числе и по сети. А обработчик этого события находится в ограниченном окружении. В .Net это время работы не более 2х секунд, а в Mono это остановленный ThreadPool. Поэтому, полезно позаботиться о завершении процесса в более дружественном окружении.

Первое, что следует сделать, это обработать событие AppDomain.UnhandledException. В нем следует записать в лог полную информацию об ошибке и вызвать LogManager.Flush(). Обработчик этого события использует тот же поток, который и вызвал исключение, а по окончании, немедленно выгружает приложение.

private static readonly Logger Log = LogManager.GetCurrentClassLogger();<br/>
 <br/>
public static void Main(string[] args)<br/>
{<br/>
    AppDomain.CurrentDomain.UnhandledException += OnUnhandledException;<br/>
    (...)<br/>
    LogManager.Flush();<br/>
}<br/>
 <br/>
static void OnUnhandledException(object sender, UnhandledExceptionEventArgs e)<br/>
{<br/>
    Log.Fatal("Unhandled exception: {0}", e.ExceptionObject);<br/>
    LogManager.Flush();<br/>
}

Кроме того, следует вызывать LogManager.Flush() везде, где потенциально возможно завершение процесса. В конце всех не фоновых потоков.

Если ваше приложение представляет собой win-service или Asp.Net, то следует обработать соответствующие события начала и завершения кода.

Сколько логировать

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

Вывод в лог это по сути комментарий. Логирование уровня Trace по большей части их и заменяет.
Уровни Trace и Debug читают разработчики, а все что выше — техподдержка и админы. Поэтому до уровня Info сообщения должны точно отвечать на вопросы: «Что произошло?», «Почему?» и по возможности «Как исправить?». Особенно это касается ошибок в файлах конфигурации.

Качественный состав уровней логирования уже разобран в предыдущей статье, здесь рассмотрим только количественный состав:

• Trace — вывод всего подряд. На тот случай, если Debug не позволяет локализовать ошибку. В нем полезно отмечать вызовы разнообразных блокирующих и асинхронных операций.
• Debug — журналирование моментов вызова «крупных» операций. Старт/остановка потока, запрос пользователя и т.п.
• Info — разовые операции, которые повторяются крайне редко, но не регулярно. (загрузка конфига, плагина, запуск бэкапа)
• Warning — неожиданные параметры вызова, странный формат запроса, использование дефолтных значений в замен не корректных. Вообще все, что может свидетельствовать о не штатном использовании.
• Error — повод для внимания разработчиков. Тут интересно окружение конкретного места ошибки.
• Fatal — тут и так понятно. Выводим все до чего дотянуться можем, так как дальше приложение работать не будет.

Боевое развертывание

Предположим, разработка дошла до внедрения.
Отложим вопросы ротации логов, размера файлов и глубины истории. Это все очень специфично для каждого проекта и настраивается в зависимости от реальной работы сервиса.

Остановлюсь только на смысловой организации файлов. Их следует разделить на 3 группы. Может потребуется развести логи модулей в разные файлы, но дальше я все равно буду говорить об одном файле для каждой группы.

1. Группа Info, с соответствующим уровнем для всех источников. Это информация для администратора. Здесь могут быть следующие вещи: когда приложение стартовало, правильно ли вычитаны конфиги, доступны ли требуемые сервисы, и т.д. Его основное свойство: файл изменяет размер только при перезагрузке приложения. В процессе работы, файл расти не должен. Это поможет обеспечить автоматизированный внешний контроль успешности запуска приложения. Достаточно проверить отсутствие в файле ключевых слов Error и Fatal. Проверка всегда будет занимать предсказуемо малое время.
2. Группа Warning. Это тоже информация для администратора. Этот файл при нормальной работе должен отсутствовать или быть пустым. Соответственно мониторинг его состояния сразу укажет на сбои в работе. Гибко настроив фильтры по разным источникам, можно подобрать достаточно точный критерий, когда вообще следует обратить внимание на сервис.
3. Группа Наблюдение. Как правило в ходе внедрения выделяются некоторые проблемные модули. Информация от них в детализации Debug как раз и направляется сюда.

Если приложение успешно внедрено, то в работе остаются только первые две группы.

Расследование сбоев

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

Вывод в лог желательно сделать асинхронным.
Пример, боевой настройки.

<nlog autoReload="true"><br/>
  <targets><br/>
    <target name="fileInfo" type="AsyncWrapper" queueLimit="5000" overflowAction="Block"><br/>
      <target type="File" fileName="${basedir}/logs/info.log" /><br/>
    </target><br/>
    <target name="fileWarn" type="AsyncWrapper" queueLimit="5000" overflowAction="Block"><br/>
      <target type="File" fileName="${basedir}/logs/warn.log" /><br/>
    </target><br/>
  </targets><br/>
 <br/>
  <rules><br/>
    <logger name="*" minlevel="Info" writeTo="fileInfo" /><br/>
    <logger name="*" minlevel="Warn" writeTo="fileWarn" /><br/>
  </rules><br/>
</nlog>

Чего с логгером делать не следует

Логгер должен быть простым и надежным как молоток. И у него должна быть четко очерчена область применения в конкретном проекте. К сожалению, разработчиков часто трудно удержать. Паттерны проектирования, это в основном полезно, но не этом случае. Достаточно часто стал замечать предложения выделить для логгера обобщенный интерфейс (пример) или реализовать обертку в проекте, чтобы отложить муки выбора NLog vs log4net на потом.

Что бы ни было тому причиной, надо точно помнить, что в первую очередь, такие удобства напрочь убивают компилятору возможность оптимизации.

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

Чего же мне еще не хватает в NLog?

• Дополнительные перегрузки методов логгера, для того чтобы избежать генерации классов лямбда-функций. Хочется иметь вызов вида
  Log.Trace<TArg1, TArg2>(Func<TArg1, TArg2, string> messageCreater, TArg1 arg1, TArg2 arg2)
  Но на текущий момент, самый короткий человекочитаемый вариант подразумевает скрытую генерацию класса:
  Log.Trace(() => MessageCreate(arg1, arg2))
• Бинарная совместимость. Помогает быстро тестировать сервисы на разных платформах. В NLog очень много инструкций условной компиляции в зависимости от платформы. Т.е. бинарник для Mono может неожиданно работь в DotNet. А очень желательна предсказуемость, хотя бы и в ограниченной комплектации.
• Условная расширяемость. Понятно, что с бинарной совместимостью придется жертвовать функционалом, но у нас уже есть удобный механизм расширений. Осталось только, чтобы он фильтровал расширения в зависимости от платформы. Вместе с предыдущей возможностью, это еще и дает простое развертывание через копирование директории с IL-бинарниками.
• Логгирование внутренних сообщений в общем контексте. Был бы полезен список создаваемых в системе логгеров. К сожалению, не уверен, что можно избежать рекурсии. Например, когда вывод в файл начнет писать ошибки вывода в себя же.

NLog, Log4Net, Enterprise Library, SmartInspect…

Разнообразные сравнения логгеров между собой, упускают одну важную деталь.
Важно сравнивать не только ограничения/возможности, но и возможность быстро добавить свои «хотелки».

Поэтому, буду пока дружить с NLog.
Чего и Вам желаю.

logfiles — Перевод на русский — примеры английский

На основании Вашего запроса эти примеры могут содержать грубую лексику.

На основании Вашего запроса эти примеры могут содержать разговорную лексику.

First look at your logfiles for hints.

First look at your logfiles for hints.

This is from Debian, we are using it for now Daniel Robbins, 5/15/99 First some standard logfiles.

import logging

import logging

logging.debug('This is a debug message')
logging.info('This is an info message')
logging.warning('This is a warning message')
logging.error('This is an error message')
logging.critical('This is a critical message')

WARNING:root:This is a warning message
ERROR:root:This is an error message
CRITICAL:root:This is a critical message

import logging

logging.basicConfig(level=logging.DEBUG)
logging.debug('This will get logged')

DEBUG:root:This will get logged

import logging

logging.basicConfig(filename='app.log', filemode='w', format='%(name)s - %(levelname)s - %(message)s')
logging.warning('This will get logged to a file')

root - ERROR - This will get logged to a file

import logging

logging.basicConfig(format='%(process)d-%(levelname)s-%(message)s')
logging.warning('This is a Warning')

18472-WARNING-This is a Warning

import logging

logging.basicConfig(format='%(asctime)s - %(message)s', level=logging.INFO)
logging.info('Admin logged in')

2018-07-11 20:12:06,288 - Admin logged in

import logging

logging.basicConfig(format='%(asctime)s - %(message)s', datefmt='%d-%b-%y %H:%M:%S')
logging.warning('Admin logged out')

12-Jul-18 20:53:19 - Admin logged out

import logging

name = 'John'

logging.error('%s raised an error', name)

ERROR:root:John raised an error

import logging

name = 'John'

logging.error(f'{name} raised an error')

ERROR:root:John raised an error

import logging

a = 5
b = 0

try:
  c = a / b
except Exception as e:
  logging.error("Exception occurred", exc_info=True)

ERROR:root:Exception occurred
Traceback (most recent call last):
  File "exceptions.py", line 6, in <module>
    c = a / b
ZeroDivisionError: division by zero
[Finished in 0.2s]

ERROR:root:Exception occurred

import logging

a = 5
b = 0
try:
  c = a / b
except Exception as e:
  logging.exception("Exception occurred")

ERROR:root:Exception occurred
Traceback (most recent call last):
  File "exceptions.py", line 6, in <module>
    c = a / b
ZeroDivisionError: division by zero
[Finished in 0.2s]

import logging

logger = logging.getLogger('example_logger')
logger.warning('This is a warning')

This is a warning

WARNING:example_logger:This is a warning

# logging_example.py

import logging

# Create a custom logger
logger = logging.getLogger(__name__)

# Create handlers
c_handler = logging.StreamHandler()
f_handler = logging.FileHandler('file.log')
c_handler.setLevel(logging.WARNING)
f_handler.setLevel(logging.ERROR)

# Create formatters and add it to handlers
c_format = logging.Formatter('%(name)s - %(levelname)s - %(message)s')
f_format = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
c_handler.setFormatter(c_format)
f_handler.setFormatter(f_format)

# Add handlers to the logger
logger.addHandler(c_handler)
logger.addHandler(f_handler)

logger.warning('This is a warning')
logger.error('This is an error')

__main__ - WARNING - This is a warning
__main__ - ERROR - This is an error

2018-08-03 16:12:21,723 - __main__ - ERROR - This is an error

# run.py

import logging_example

logging_example - WARNING - This is a warning
logging_example - ERROR - This is an error

[loggers]
keys=root,sampleLogger

[handlers]
keys=consoleHandler

[formatters]
keys=sampleFormatter

[logger_root]
level=DEBUG
handlers=consoleHandler

[logger_sampleLogger]
level=DEBUG
handlers=consoleHandler
qualname=sampleLogger
propagate=0

[handler_consoleHandler]
class=StreamHandler
level=DEBUG
formatter=sampleFormatter
args=(sys.stdout,)

[formatter_sampleFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s

import logging
import logging.config

logging.config.fileConfig(fname='file.conf', disable_existing_loggers=False)

# Get the logger specified in the file
logger = logging.getLogger(__name__)

logger.debug('This is a debug message')

2018-07-13 13:57:45,467 - __main__ - DEBUG - This is a debug message

version: 1
formatters:
  simple:
    format: '%(asctime)s - %(name)s - %(levelname)s - %(message)s'
handlers:
  console:
    class: logging.StreamHandler
    level: DEBUG
    formatter: simple
    stream: ext://sys.stdout
loggers:
  sampleLogger:
    level: DEBUG
    handlers: [console]
    propagate: no
root:
  level: DEBUG
  handlers: [console]

import logging
import logging.config
import yaml

with open('config.yaml', 'r') as f:
    config = yaml.safe_load(f.read())
    logging.config.dictConfig(config)

logger = logging.getLogger(__name__)

logger.debug('This is a debug message')

2018-07-13 14:05:03,766 - __main__ - DEBUG - This is a debug message