Logfiles что это: Что такое логи logs файл(ы) сайта и зачем они нужны?

Содержание

Лог файлы 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

Почти все знают об утилите less и команде tail -f. Также для этих целей сгодится редактор vim и файловый менеджер Midnight Commander. У всех есть свои недостатки: less неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор

vim понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью <:view /path/to/file>.

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — 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

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

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

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


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

  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 1. Журнал событий

Log File

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

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

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

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

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

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

Похожие форматы
.avi - Видеозапись AVI.avl - Файл легенды ArcView.avp - Файл проекта Avid.vdc - Описание данных векторного изображения IDRISI.vip - Файл аудиопроекта Samplitude Music Studio Иконка формата файла log 2. Файл отчета Avira AntiVir

AntiVir Report Log File

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

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

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

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

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

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

Похожие форматы
.log1 - Журнал изменений реестра Windows.hvc - Коллекция переменных HotDocs

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

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

Мой опыт разработки в основном строится вокруг разнообразных сетевых cервисов под Windows и Linux. Я обычно стремлюсь добиться максимальной кроссплатформенности вплоть до бинарной совместимости. И конечно, накопилось некоторое количество стабильных решений связанных с логированием.

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

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

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

Итак, начну со своих дополнений к предыдущей статье.
Я как и автор пользуюсь 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>


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

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

Логгер должен быть простым и надежным как молоток. И у него должна быть четко очерчена область применения в конкретном проекте. К сожалению, разработчиков часто трудно удержать. Паттерны проектирования, это в основном полезно, но не этом случае. Достаточно часто стал замечать предложения выделить для логгера обобщенный интерфейс (пример) или реализовать обертку в проекте, чтобы отложить муки выбора 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 - Перевод на русский - примеры английский

Предложения: logfile

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

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

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.

Взято из Debian, пока пользуемся им Daniel Robbins, 5/15/99 Сначала стандартные файлы журналов.

By default, this process runs as user 'log2mail', which is a member of group 'adm' (which has access to read system logfiles).

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

For instance, let us look at the Exchange 2003 logs, available by default in the folder C:\WINDOWS\system32\LogFiles\SMTPSVC1 (some fields were truncated for better reading).

Например, давайте посмотрим на логи Exchange 2003, которые по умолчанию расположены в C:\WINDOWS\system32\LogFiles\SMTPSVC1 (некоторые поля были сокращены для более удобного чтения).

By default, IAS logs to local files (%systemroot%\LogFiles\IAS\ ) though it can be configured to log to SQL as well (or in place of).

По умолчанию, IAS регистрирует разрешения к локальным файлам (%systemroot %\LogFiles\IAS\ ), однако его можно настраивать и для регистрации разрешений на SQL.

partition contains a lot of state information specific to Debian in addition to its regular contents, like logfiles.

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

Notice that saving logfiles will save whole file

Unix and Linux have an excellent history of logging capabilities - if you want you can log everything that happens on your system in logfiles.

У Unix и Linux превосходная история развития журналирования - при желании в файлах журналов можно регистрировать любой чих, происходящий в вашей системе.

Логирование в Python - Еще один блог веб разработчика

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

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

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

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

Модуль Logging

Модуль logging в Python — это готовый к использованию, мощный модуль, предназначенный для удовлетворения потребностей как начинающих, так и корпоративных команд. Он используется большинством сторонних библиотек Python, поэтому вы можете интегрировать ваши логи с сообщениями из этих библиотек для создания единого журнала логов в вашего приложении.

Добавить logging в вашу программу на Python так же просто, как написать эту строчку:

import logging

С импортированным модулем logging вы можете использовать то, что называется «logger», для логирования сообщений, которые вы хотите видеть. По умолчанию существует 5 стандартных уровней severity, указывающих на важность событий. У каждого есть соответствующий метод, который можно использовать для логирования событий на выбранном уровне severity. Список уровней в порядке увеличения важности:

  • DEBUG
  • INFO
  • WARNING
  • ERROR
  • CRITICAL

Модуль 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

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

Обратите внимание, что сообщения debug() и info() не были отображены. Это связано с тем, что по умолчанию модуль ведения журнала регистрирует сообщения только с уровнем WARNING или выше. Вы можете изменить это, сконфигурировав модуль logging для регистрации событий всех уровней. Вы также можете определить свои собственные уровни, изменив конфигурации, но, как правило, это не рекомендуется, так как это может привести к путанице с журналами некоторых сторонних библиотек, которые вы можете использовать.

Базовая конфигурация

Вы можете использовать метод basicConfig (**kwargs) для настройки ведения логов:

«Вы можете заметить, что модуль logging нарушает руководство по стилю PEP8 и использует соглашения camelCase в именнование переменных. Это потому, что он был адоптирован из пакета Log4j (утилиты ведения логов в Java). Это известная проблема в пакете, но к тому времени, когда было решено добавить ее в стандартную библиотеку, она уже была принята пользователями, и изменение ее в соответствии с требованиями PEP8 вызовет проблемы обратной совместимости ». (Источник)

Вот некоторые из часто используемых параметров для basicConfig():

  • level: Корневой логер с установленным указанным уровнем важности (severity).
  • filename: Указание файла логов
  • filemode: Режим открытия файла. По умолчанию это a, что означает добавление.
  • format: Формат сообщений.

Используя параметр level, вы можете установить, какой уровень сообщений журнала вы хотите записать. Это можно сделать, передав одну из констант, доступных в классе, и это позволило бы регистрировать все вызовы logging на этом уровне или выше. Вот пример:

import logging

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

Теперь будут регистрироваться все события на уровне DEBUG или выше.

Аналогично, для записи логов в файл, а не в консоль, можно использовать filename и filemode, и вы можете выбрать формат сообщения, используя format. В следующем примере показано использование всех трех переменных:

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

Сообщение будет записано в файл с именем app.log вместо вывода в консоль. Для filemode значение w означает, что файл журнала открывается в «режиме записи» каждый раз, когда вызывается basicConfig(), и при каждом запуске программы файл перезаписывается. Конфигурацией по умолчанию для filemode является a, которое является добавлением.

Вы можете настроить корневой logger еще больше, используя дополнительные параметры для basicConfig(), которые можно найти здесь.

Следует отметить, что вызов basicConfig() для настройки корневого logger работает, только если корневой logger не был настроен ранее. По сути, эта функция может быть вызвана только один раз.

debug(), info(), warning(), error() и crit() также автоматически вызывают basicConfig() без аргументов, если он ранее не вызывался. Это означает, что после первого вызова одной из вышеперечисленных функций вы больше не сможете изменить настройки корневого logger.

Формат вывода

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

import logging

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

format может принимать строку с атрибутами LogRecord в любом порядке. Весь список доступных атрибутов можно найти здесь.

Вот еще один пример, где вы можете добавить информацию о дате и времени:

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

%(asctime)s добавляет время создания LogRecord. Формат можно изменить с помощью атрибута datefmt, который использует тот же язык форматирования, что и функции форматирования в модуле datetime, например time.strftime():

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

Вы можете найти больше информации о формате datetime в этом руководстве.

Логирование переменных

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

import logging

name = 'John'

logging.error('%s raised an error', name)
ERROR:root:John raised an error

Аргументы, передаваемые методу, будут включены в сообщение в качестве переменных.

Хотя вы можете использовать любой стиль форматирования, f-строки, представленные в Python 3.6, являются лучшим способом форматирования строк, поскольку они могут помочь сделать форматирование коротким и легким для чтения:

import logging

name = 'John'

logging.error(f'{name} raised an error')
ERROR:root:John raised an error

Вывод стека

Модуль регистрации также позволяет вам захватывать стек выполнения в приложении. Информация об исключении может быть получена, если параметр exc_info передан как True, а функции ведения журнала вызываются таким образом:

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]

Если для exc_info не задано значение True, выходные данные вышеприведенной программы не сообщат нам ничего об исключении, которое в реальном сценарии может быть не таким простым, как ZeroDivisionError. Представьте, что вы пытаетесь отладить ошибку в сложной кодовой базе с помощью журнала, который показывает только это:

ERROR:root:Exception occurred

Совет: если вы логируете в обработчике исключений (try..except…), используйте метод logging.exception(), который регистрирует сообщение с уровнем ERROR и добавляет в сообщение информацию об исключении. Проще говоря, вызов logging.exception() похож на вызов logging.error (exc_info = True). Но поскольку этот метод всегда выводит информацию об исключении, его следует вызывать только в обработчике исключений. Взгляните на этот пример:

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]

Использование logging.exception() покажет лог на уровне ERROR. Если вы не хотите этого, вы можете вызвать любой из других методов ведения журнала от debug() до critical() и передать параметр exc_info как True.

Классы и функции

До сих пор мы видели logger по умолчанию с именем root, который используется модулем logging всякий раз, когда его функции вызываются непосредственно таким образом: logging.debug(). Вы можете (и должны) определить свой собственный logger, создав объект класса Logger, особенно если ваше приложение имеет несколько модулей. Давайте посмотрим на некоторые классы и функции в модуле.

Наиболее часто используемые классы, определенные в модуле logging, следующие:

  • Logger: Это класс, чьи объекты будут использоваться в коде приложения напрямую для вызова функций.
  • LogRecord: Logger автоматически создает объект LogRecord, в котором находиться вся информация, относящаяся к регистрируемому событию, например, имя логера, функции, номер строки, сообщение и т. д. 
  • Handler: Обработчики отправляют LogRecord в требуемое место назначения вывода, такое как консоль или файл. Обработчик является основой для подклассов, таких как StreamHandler, FileHandler, SMTPHandler, HTTPHandler и других. Эти подклассы отправляют выходные данные журнала соответствующим адресатам, таким как sys.stdout или файл на диске.
  • Formatter: Здесь вы указываете формат вывода, задавая строковый формат, в котором перечислены атрибуты, которые должны содержать выходные данные.

Из всего перечисленного мы в основном имеем дело с объектами класса Logger, которые создаются с помощью функции уровня модуля logging.getLogger(name). Многократные вызовы getLogger() с одним и тем же именем возвращают ссылку на один и тот же объект Logger, что избавляет нас от передачи объектов logger в каждую часть, где это необходимо. Вот пример:

import logging

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

Этот код создает пользовательский logger с именем example_logger, но в отличие от корневого logger, имя настраиваемого регистратора не является частью выходного формата по умолчанию и должна быть добавлена в конфигурацию. Конфигурирование его в формате для отображения имени logger даст вывод, подобный этому:

WARNING:example_logger:This is a warning

Опять же, в отличие от корневого logger, пользовательский logger нельзя настроить с помощью basicConfig(). Вы должны настроить его с помощью Handlers и Formatters:

Использование Handlers

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

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

Подобно logger, вы также можете установить уровень severity в обработчиках. Это полезно, если вы хотите установить несколько обработчиков для одного и того же logger, но хотите иметь разные уровни severity для каждого из них. Например, вы можете захотеть, чтобы журналы с уровнем WARNING и выше регистрировались на консоли, но все с уровнем ERROR и выше также должно быть сохранены в файл. Вот пример кода, который делает это:

# 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

Здесь logger.warning() создает LogRecord, который содержит всю информацию о событии, и передает ее всем имеющимся обработчикам: c_handler и f_handler.

c_handler является StreamHandler с уровнем WARNING и берет информацию из LogRecord для генерации вывода в указанном формате и выводит его на консоль. f_handler — это FileHandler с уровнем ERROR, и он игнорирует LogRecord, так как его уровень — WARNING.

Когда вызывается logger.error(), c_handler ведет себя точно так же, как и раньше, а f_handler получает LogRecord на уровне ERROR, поэтому он продолжает генерировать вывод точно так же, как c_handler, но вместо вывода на консоль, он записывает сообщение в указанный файл в этом формате:

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

Имя logger, соответствующее переменной __name__, записывается как __main__, то есть имя, которое Python присваивает модулю, с которого начинается выполнение. Если этот файл импортируется каким-либо другим модулем, то переменная __name__ будет соответствовать его имени logging_example. Вот как это будет выглядеть:

# run.py

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

Другие методы настройки

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

Вот пример файла конфигурации:

[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

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

Чтобы загрузить этот файл конфигурации, вы должны использовать fileConfig():

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

Путь к файлу конфигурации передается в качестве параметра методу fileConfig(), а параметр disable_existing_loggers используется для сохранения или отключения logger, которые присутствуют при вызове функции. По умолчанию установлено значение True, если не упомянуто.

Вот та же конфигурация в формате YAML для подхода с dictionary:

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]

Пример, который показывает, как загрузить конфигурацию из файла yaml:

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

Заключение

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

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

Оригинальная статья: Abhinav Ajitsaria  Logging in Python

Была ли вам полезна эта статья?

[16 / 5]

.net - Для чего нужен csilogfile?

Переполнение стека
  1. Товары
  2. Клиенты
  3. Случаи использования
  1. Переполнение стека Общественные вопросы и ответы
  2. Команды Частные вопросы и ответы для вашей команды
  3. предприятие Частные вопросы и ответы для вашего предприятия
  4. работы Программирование и связанные с ним возможности технической карьеры
  5. Талант Нанять технических талантов
  6. реклама Обратитесь к разработчикам по всему миру
,

новейших вопросов "анализ файла журнала" - qaru Переполнение стека
  1. Товары
  2. Клиенты
  3. Случаи использования
  1. Переполнение стека Общественные вопросы и ответы
  2. Команды Частные вопросы и ответы для вашей команды
  3. предприятие Частные вопросы и ответы для вашего предприятия
  4. работы Программирование и связанные с ним возможности технической карьеры
  5. Талант Нанять технических талантов
  6. реклама Обратитесь к разработчикам по всему миру
,

windows 7 - Как просмотреть дамп файла журнала NTFS $?

Переполнение стека
  1. Товары
  2. Клиенты
  3. Случаи использования
  1. Переполнение стека Общественные вопросы и ответы
  2. Команды Частные вопросы и ответы для вашей команды
  3. предприятие Частные вопросы и ответы для вашего предприятия
  4. работы Программирование и связанные с ним возможности технической карьеры
  5. Талант Нанять технических талантов
  6. реклама Обратитесь к разработчикам по всему миру
,

c # - альтернативные файлы журнала - qaru. Переполнение стека
  1. Товары
  2. Клиенты
  3. Случаи использования
  1. Переполнение стека Общественные вопросы и ответы
  2. Команды Частные вопросы и ответы для вашей команды
  3. предприятие Частные вопросы и ответы для вашего предприятия
  4. работы Программирование и связанные с ним возможности технической карьеры
  5. Талант Нанять технических талантов
  6. реклама Обратитесь к разработчикам по всему миру
,

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *