Что полезного можно найти в системных логах


Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Пользовательская рабочая станция — самое уязвимое место инфраструктуры по части информационной безопасности. Пользователям может прийти на рабочую почту письмо вроде бы из безопасного источника, но со ссылкой на заражённый сайт. Возможно, кто-то скачает полезную для работы утилиту из неизвестно какого места. Да можно придумать не один десяток кейсов, как через пользователей вредоносное ПО может внедриться на внутрикорпоративные ресурсы. Поэтому рабочие станции требуют повышенного внимания, и в статье мы расскажем, откуда и какие события брать для отслеживания атак.



Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.

Журнал событий безопасности (Security Log)


Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.

Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.

Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.

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

Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.

Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.

Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.

Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.

Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:

Logon/Logoff

  • Logon;
  • Logoff;
  • Account Lockout;
  • Other Logon/Logoff Events.

Account Management
  • User Account Management;
  • Security Group Management.

Policy Change
  • Audit Policy Change;
  • Authentication Policy Change;
  • Authorization Policy Change.

Системный монитор (Sysmon)


Sysmon — встроенная в Windows утилита, которая умеет записывать события в системный журнал. Обычно требуется его устанавливать отдельно.

Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?

Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.

Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.

Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.

Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.

А теперь то, чего в политиках Security Log нет, но есть в Sysmon:

Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.

Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.

Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.

События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.

Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.

Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.

Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.

Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).

Журналы Power Shell


Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.
Windows PowerShell log

Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.

Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.

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

Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.

11.7.Настройка системного журнала

11.7.Настройка системного журнала

Предоставлено Никласом Цейзингом.

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

FreeBSD предоставляет системный журнал, syslogd, чтобы управлять ведением журнала. По по умолчанию syslogd запускается, когда система загружается. Это контролируется переменной syslogd_enable в /etc/rc.conf . Есть множество аргументы приложения, которые могут быть установлены с помощью syslogd_flags в /etc/rc.conf . Обратитесь к syslogd (8) для больше информации о доступных аргументах.

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

11.7.1. Настройка локальной регистрации

Файл конфигурации, /etc/syslog.conf , что контролирует syslogd делает с записями журнала как они получены. Есть несколько параметров для управления обработка входящих событий. В Объект описывает, какая подсистема сгенерировал сообщение, например ядро ​​или демон, и уровень описывает серьезность событие, которое произошло. Это позволяет настроить, если и где регистрируется сообщение журнала, в зависимости от объекта и уровень.Также возможно принять меры в зависимости от приложение, отправившее сообщение, и в случае удаленное ведение журнала, имя хоста машины, генерирующей событие регистрации.

Этот файл конфигурации содержит одну строку для каждого действия, где синтаксис для каждой строки - это поле выбора, за которым следует поле действия. Синтаксис поля селектора: объект.уровень который будет соответствовать журналу сообщения от объекта на уровне уровень и выше.Это также можно добавить необязательный флаг сравнения перед уровнем чтобы точнее указать, что регистрируется. Множественный селектор поля могут использоваться для одного и того же действия и разделяются точка с запятой (; ). С помощью * все подойдет. Поле действия обозначает, куда отправить сообщение журнала, например, в файл или удаленный хост журнала. Например, по умолчанию syslog.conf из FreeBSD:

 # $ FreeBSD $ # # Пробелы ЯВЛЯЮТСЯ допустимыми разделителями полей в этом файле.Тем не мение, # другие * nix-подобные системы по-прежнему настаивают на использовании вкладок в качестве поля # разделители. Если вы делитесь этим файлом между системами, вы # может захотеть использовать здесь только табуляции в качестве разделителей полей. # См. Справочную страницу syslog.conf (5). * .err; kern.warning; auth.notice; mail.crit / dev / console * .notice; authpriv.none; kern.debug; lpr.info; mail.crit; news.err / var / log / messages безопасность. * / var / log / security auth.info; authpriv.info / var / log / auth.журнал mail.info / var / log / maillog lpr.info / var / log / lpd-errs ftp.info / var / log / xferlog cron. * / var / журнал / cron ! -devd *. = отладка /var/log/debug.log * .emerg * # раскомментируйте это, чтобы записывать все записи в / dev / console в /var/log/console.log # console.info / var / log / console.журнал # раскомментируйте это, чтобы разрешить запись всех сообщений журнала в /var/log/all.log # коснитесь /var/log/all.log и измените его до режима 600, прежде чем он заработает # *. * /var/log/all.log # раскомментируйте это, чтобы разрешить ведение журнала на удаленный хост с именем loghost # *. * @loghost # раскомментируйте их, если вы управляете гостиницей # news.crit /var/log/news/news.crit # news.err / var / log / news / news.ошибаться # news.notice /var/log/news/news.notice # Раскомментируйте это, если хотите видеть сообщения, созданные devd #! devd # *.> = информация ! ppp *. * /var/log/ppp.log ! * 

В этом примере:

  • Строка 8 соответствует всем сообщениям с уровнем err или выше, а также kern.warning , авториз. Извещение и mail.crit , и отправляет эти сообщения журнала к консоли ( / dev / console ).

  • Строка 12 соответствует всем сообщениям от почта объект на уровне info или выше и регистрирует сообщения в / var / журнал / maillog .

  • Строка 17 использует флаг сравнения ( = ) для соответствия сообщениям только на уровне отладка и записывает их в /var/log/debug.log .

  • Строка 33 - пример использования программы. Технические характеристики. Это делает правила, следующие за ним только действительно для указанной программы.В этом случае только сообщения, генерируемые ppp, зарегистрирован в /var/log/ppp.log .

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

Объекты, в произвольном порядке, находятся auth , authpriv , консоль , cron , демон , ftp , керн , лпр , почта , марка , новости , безопасность , syslog , пользователь , uucp и local0 через местный7 .Имейте в виду, что другие операционные системы могут иметь разные возможности.

Для регистрации всего уровня , уведомления и выше до /var/log/daemon.log , добавьте следующая запись:

 daemon.notice /var/log/daemon.log 

Для получения дополнительной информации о различных уровнях и См. syslog (3) и syslogd (8). Для получения дополнительной информации о /etc/syslog.conf , его синтаксис и др. дополнительные примеры использования см. в системном журнале.conf (5).

11.7.2. Управление журналами и их ротация

Файлы журналов могут быстро увеличиваться, занимая место на диске и затрудняет поиск полезной информации. Журнал руководство пытается смягчить это. В FreeBSD, newsyslog используется для управления журналом файлы. Эта встроенная программа периодически вращается и сжимает файлы журналов и при необходимости создает отсутствующие файлы журналов и сигнализирует программам о перемещении файлов журнала. Файлы журнала может быть сгенерирован syslogd или любая другая программа, которая генерирует файлы журнала.Пока newsyslog обычно запускается из cron (8), это не системный демон. По умолчанию конфигурации, запускается каждый час.

Чтобы узнать, какие действия предпринять, newsyslog читает его конфигурацию файл, /etc/newsyslog.conf . Этот файл содержит одну строку для каждого файла журнала, который newsyslog управляет. Каждая строка указывает владельца файла, разрешения, когда повернуть этот файл, необязательные флаги, влияющие на ротацию журналов, такие как сжатие, и программы, сигнализирующие о повороте бревна.Здесь конфигурация по умолчанию в FreeBSD:

 # конфигурационный файл для newsyslog # $ FreeBSD $ # # Записи, в которых не указано поле '/ pid_file', вызовут # Процесс syslogd будет сигнализирован при ротации этого файла журнала. это # действие подходит только для файлов журнала, которые записываются # процесс syslogd (т.е. файлы, перечисленные в /etc/syslog.conf). Если здесь # нет процесса, о котором нужно сигнализировать, когда данный файл журнала # повернут, то запись для этого файла должна включать флаг "N".# # Поле 'flags' состоит из одной или нескольких букв: BCDGJNUXZ или '-'. # # Примечание: некоторые сайты захотят выбрать более строгие меры защиты, чем # значения по умолчанию. В частности, может быть желательно переключить многие из 644 # записей до 640 или 600. Например, некоторые сайты будут рассматривать # содержимое почтовых журналов, сообщений и lpd-errs должно быть конфиденциальным. в # В будущем эти значения по умолчанию могут измениться на более консервативные. # # logfilename [owner: group] размер счетчика режима при флагах [/ pid_file] [sig_num] / var / log / все.log 600 7 * @ T00 Дж /var/log/amd.log 644 7 100 * Дж /var/log/auth.log 600 7 100 @ 0101T JC /var/log/console.log 600 5100 * Дж / var / log / cron 600 3 100 * JC /var/log/daily.log 640 7 * @ T00 JN /var/log/debug.log 600 7 100 * JC /var/log/kerberos.log 600 7 100 * Дж / var / log / lpd-errs 644 7 100 * JC / var / log / maillog 640 7 * @ T00 JC / var / log / messages 644 5100 @ 0101T JC / var / log / ежемесячно.журнал 640 12 * $ M1D0 JN / var / log / pflog 600 3100 * JB /var/run/pflogd.pid /var/log/ppp.log корень: сеть 640 3 100 * JC /var/log/devd.log 644 3 100 * JC / var / log / security 600 10 100 * JC /var/log/sendmail.st 640 10 * 168 Б /var/log/utx.log 644 3 * @ 01T05 B /var/log/weekly.log 640 5 1 $ W6D0 JN / var / log / xferlog 600 7 100 * JC 

Каждая строка начинается с имени журнала для ротации, необязательно, за которым следуют владелец и группа для повернутых и вновь созданные файлы.Поле mode устанавливает разрешения на файл журнала и счетчик обозначает, сколько ротационных файлов журнала следует сохранить. В размер и при полей сообщить Newsyslog, когда нужно повернуть файл. Файл журнала поворачивается, если его размер больше чем поле размера или когда время в после прохождения поля . Звездочка ( * ) означает, что это поле игнорируется. В flags поле дает дальше инструкции, например, как сжать повернутый файл или как создайте файл журнала, если он отсутствует.Последние два поля необязательно и укажите имя идентификатора процесса (PID) файл процесса и номер сигнала для отправки этому процессу при повороте файла.

Для получения дополнительной информации обо всех полях, допустимых флагах и способах чтобы указать время вращения, обратитесь к newsyslog.conf (5). Поскольку журнал новостей запускается из cron (8), он не может вращать файлы чаще, чем планируется запускать из cron (8).

11.7.3. Настройка удаленного ведения журнала

Предоставлено Tom Rhodes.

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

В FreeBSD централизованное агрегирование файлов журнала, слияние и вращение можно настроить с помощью syslogd и newsyslog. Эта секция демонстрирует пример конфигурации, где хост A , названный logserv.example.com , будет собирать информацию журналов для локальной сети.Хост B , названный logclient.example.com , будет настроен для передачи информации журнала в журнал сервер.

11.7.3.1.Конфигурация сервера журнала

Сервер журнала - это система, настроенная для принимать информацию журнала от других хостов. Перед при настройке сервера журналов проверьте следующее:

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

  • Сервер регистрации и все клиентские машины должны иметь прямую и обратную записи в локальном DNS. Если в сети нет DNS-сервер, создайте записи в каждом системы / etc / hosts . Правильное имя требуется разрешение, чтобы записи журнала не отклонено сервером ведения журнала.

На сервере журнала отредактируйте /etc/syslog.conf , чтобы указать имя клиент, от которого будут поступать записи журнала, средство ведения журнала для использования, и имя журнала для хранения журнала хоста записи.В этом примере добавляется имя хоста B , регистрирует все объекты и магазины записи журнала в /var/log/logclient.log .

Пример 11.1. Пример конфигурации сервера журнала

 + logclient.example.com *. * /var/log/logclient.log 

При добавлении нескольких клиентов журнала добавьте аналогичные двухстрочные запись для каждого клиента. Подробнее о доступных средства можно найти в syslog.conf (5).

Далее настраиваем / etc / rc.conf :

 syslogd_enable = "ДА" syslogd_flags = "- a logclient.example.com -v -v" 

Начинается первая запись syslogd при загрузке системы. В вторая запись разрешает записи журнала от указанного клиента. -v -v увеличивает степень детализации регистрируемых Сообщения. Это полезно для настройки объектов, так как администраторы могут видеть, какие сообщения регистрируется под каждым объектом.

Несколько опций -a могут быть указаны для разрешить ведение журнала от нескольких клиентов.IP также могут быть указаны адреса и целые сетевые блоки. Обратитесь в syslogd (8) для получения полного списка возможных параметры.

Наконец, создайте файл журнала:

  #    touch /var/log/logclient.log   

На этом этапе syslogd должен будет перезапущен и проверен:

  #    service syslogd restart    #    pgrep syslog   

Если PID возвращается, сервер перезапущен успешно, и можно начинать настройку клиента.Если сервер не перезагружался, обратитесь к / var / log / messages для ошибки.

11.7.3.2.Конфигурация клиента журнала

Клиент журнала отправляет записи журнала на сервер журналов в сети. Клиент также сохраняет локальную копию своего собственные журналы.

После настройки сервера журналов отредактируйте /etc/rc.conf на лог клиент:

 syslogd_enable = "ДА" syslogd_flags = "- s -v -v" 

Первая запись включает syslogd при загрузке.Второй запись предотвращает прием журналов этим клиентом от другие хосты ( -s ) и увеличивает многословность регистрируемых сообщений.

Затем определите сервер регистрации в клиентском /etc/syslog.conf . В этом примере все зарегистрированные объекты отправляются в удаленную систему, обозначенную символ @ , с указанным имя хоста:

 *. * @ logserv.example.com 

После сохранения изменений перезапустите syslogd для внесения изменений эффект:

  #    service syslogd restart   

Чтобы проверить, что сообщения журнала отправляются через сеть, используйте регистратор (1) на клиенте для отправки сообщения to syslogd:

  #    logger "  Тестовое сообщение от logclient  "   

Это сообщение теперь должно существовать как в / var / log / messages на клиенте и / вар / журнал / logclient.журнал по журналу сервер.

11.7.3.3. Отладка серверов журналов

Если на сервер журналов не поступают сообщения, причиной, скорее всего, является проблема с сетевым подключением, проблема с разрешением имени хоста или опечатка в конфигурации файл. Чтобы изолировать причину, убедитесь, что оба журнала сервер и клиент регистрации могут пингуют друг друга, используя имя хоста указано в их /etc/rc.conf . Если это не удается, проверьте сетевые кабели, набор правил брандмауэра, и записи имени хоста в DNS server или / etc / hosts на обоих сервер регистрации и клиенты.Повторяйте до тех пор, пока ping успешно с обоих хосты.

Если ping успешно на обоих хостах но сообщения журнала все еще не принимаются, временно увеличить подробность ведения журнала, чтобы сузить конфигурацию вопрос. В следующем примере /var/log/logclient.log на лог сервер пуст и / var / log / messages на клиенте ведения журнала не указывает причину неудача. Чтобы увеличить вывод отладки, отредактируйте syslogd_flags запись на сервере журналов и выполните перезапуск:

 syslogd_flags = "- d -a logclient.example.com -v -v "
  #    service syslogd restart   

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

 logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: перезапущен logmsg: pri 6, flags 4, из logserv.example.com, msg syslogd: загрузочный файл ядра находится в / boot / kernel / kernel Запись в ФАЙЛ / var / log / messages syslogd: загрузочный файл ядра - / boot / kernel / kernel cvthname (192.168.1.10) проверить: dgram с IP 192.168.1.10, порт 514, имя logclient.example.com; отклонено в правиле 0 из-за несоответствия имени. 

В этом примере сообщения журнала отклоняются из-за к опечатке, которая приводит к несоответствию имени хоста. В имя хоста клиента должно быть logclient , не logclien . Исправьте опечатку, выпустите перезапустите и проверьте результаты:

  #    service syslogd restart   logmsg: pri 56, flags 4, из logserv.example.com, msg syslogd: перезапуск syslogd: перезапущен logmsg: pri 6, flags 4, из logserv.example.com, msg syslogd: загрузочный файл ядра находится в / boot / kernel / kernel syslogd: загрузочный файл ядра - / boot / kernel / kernel logmsg: pri 166, flags 17, с logserv.example.com, msg 10 декабря 20:55:02  logserv.example.com syslogd: выход по сигналу 2 cvthname (192.168.1.10) проверить: dgram с IP 192.168.1.10, порт 514, имя logclient.example.com; принято в правиле 0. logmsg: pri 15, flags 0, из logclient.example.com, msg 11 декабря 02:01:28 trhodes: Тестовое сообщение 2 Запись в ФАЙЛ /var/log/logclient.log Запись в ФАЙЛ / var / log / messages 

На этом этапе сообщения принимаются правильно и помещен в правильный файл.

11.7.3.4. Вопросы безопасности

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

Локальная безопасность также является проблемой. Файлы журнала не зашифрованы во время использования или после ротации журнала. Местные пользователи могут доступ к файлам журналов для получения дополнительных сведений о системе конфигурация. Установка правильных разрешений для файлов журнала критический.Встроенный ротатор бревен, newsyslog, поддерживает настройку разрешения для вновь созданных и измененных файлов журнала. Настройка файлы журнала в режим 600 должны предотвратить нежелательный доступ локальных пользователей. Ссылаться на newsyslog.conf (5) для получения дополнительной информации.

.

10 файлов журнала, о которых администраторы WordPress должны знать

Каждая служба, работающая на веб-сервере, на котором размещен ваш веб-сайт WordPress, имеет файл журнала. Файлы журнала используются для записи того, что выполняла служба или программное обеспечение, или какие ошибки возникли при работе. Следовательно, журналы являются жизненно важным инструментом для администраторов, веб-мастеров, разработчиков, тестировщиков и всех, кто работает с программным обеспечением (включая WordPress) или обслуживает ИТ-систему.

Как правило, мы сосредотачиваемся на журналах активности WordPress , потому что это делает журнал активности WP - он хранит в журнале активности все, что происходит на вашем веб-сайте WordPress и многосайтовой сети.

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

Журналы веб-сервера

Начнем с самого очевидного - файлов журнала веб-сервера.WordPress написан на PHP, поэтому он обычно размещается на веб-сервере Apache или Nginx. WordPress также может быть размещен на веб-сервере Microsoft IIS, но это не так распространено. Итак, в этом разделе мы сосредоточимся на веб-серверах на базе * nix.

У веб-серверов Apache и Nginx есть два файла журнала, которые нас интересуют, журнал доступа (access.log) и журнал ошибок (error.log). Модули регистрации на обоих веб-серверах очень обширны. Веб-серверы можно настроить для создания более подробных журналов и файлов журналов, их разделения и т. Д.

Журнал доступа к веб-серверу

Журнал доступа - это то место, где служба веб-сервера хранит журнал всех обработанных HTTP-запросов. Поэтому в нем вы найдете информацию о:

  • IP-адрес устройства, с которого был отправлен HTTP-запрос
  • ID пользователя в случае аутентификации пользователя через HTTP
  • Дата и время, когда веб-сервер завершил обработку запроса
  • Строка запроса (включает метод HTTP, запрашиваемый объект, протокол)
  • Код ответа HTTP на этот запрос
  • Размер объекта, отправленного в качестве ответа в байтах
  • Другая общая информация, такая как строка пользовательского агента запрашивающей стороны.

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

Когда мне нужно обращаться к файлу журнала веб-сервера?

До появления таких сервисов, как Google Analytics, файлы журнала доступа к веб-серверу использовались для создания отчетов о посетителях веб-сайтов.Хотя в настоящее время они в основном используются для устранения проблем с подключением и доступом.

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

Журнал ошибок веб-сервера

В журнале ошибок служба веб-сервера сохраняет все диагностические данные, которые она генерирует во время нормальной работы, например, при запуске или инициализации модуля.В том же файле журнала веб-сервер также сохраняет ошибки, с которыми он сталкивается при обработке HTTP-запросов, которые он получает, когда посетители просматривают или атакуют ваш веб-сайт WordPress. Итак, в файле журнала ошибок вы можете найти такую ​​информацию, как:

  • Дата и время возникновения проблемы
  • Уровень серьезности ошибки
  • IP-адрес клиента, вызвавшего ошибку
  • Сама ошибка.
Когда мне нужно обращаться к файлу журнала веб-сервера?

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

Что касается вашей работы с WordPress, файл журнала ошибок веб-сервера может предоставить вам жизненно важную информацию, когда, например, вы устраняете ошибку HTTP 500, проблему с правами доступа к файлам или проблему с плагином, который напрямую взаимодействует с веб-сервером и операционная система, например плагин кеширования. Некоторые плагины или пользовательские веб-приложения также могут отправлять информацию в журнал ошибок веб-сервера.

СОВЕТ: См. Документацию по журналам Apache и документацию по ведению журнала Nginx для получения дополнительной информации о том, как настроить ведение журнала на веб-сервере.

Файл журнала ошибок PHP

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

Когда мне нужно обращаться к файлу журнала ошибок PHP?

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

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

Файл журнала отладки WordPress

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

Когда мне нужно обращаться к файлу журнала отладки WordPress?

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

Журналы MySQL

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

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

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

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

Когда вам нужно обращаться к журналам сервера базы данных MySQL?

Журналы сервера MySQL полезны для администраторов веб-серверов, чтобы помочь им устранить проблемы с демонами (службами) и подключением.

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

СОВЕТ: Обратитесь к документации журналов MySQL для получения более подробной информации о том, как настроить ведение журнала на сервере.

Журналы SMTP-сервера

Роль SMTP-сервера на веб-сервере заключается в отправке электронной почты. Существует довольно много популярных SMTP-серверов для Linux, таких как Postfix, Sendmail и QMail. Каждый сервер имеет свои собственные файлы журналов и форматы журналов, поэтому приведенное ниже объяснение является скорее общим руководством. Если вы хотите узнать больше о точном формате файла журнала и соглашении об именах, которое использует ваш SMTP-сервер, обратитесь к его документации.

Файл журнала Mail.log

В файле mail.log вы найдете информацию обо всех электронных письмах, отправленных сервером. В нем вы также найдете информацию об ответе, полученном от удаленного сервера. Итак, в файле mail.log вы можете увидеть:

  • Дата и время создания записи в журнале,
  • Имя демона (службы) и идентификатор процесса,
  • Команды SMTP и информация заголовка (например, объявление адресов электронной почты отправителя и получателя),
  • Статус письма (отправлено, поставлено в очередь и т. Д.).

Ниже приведена выдержка из файла журнала mail.log:

postfix / pickup [5072]: CF89B3F0EA: uid = 33 from = постфикс / очистка [6063]: CF89B3F0EA: message-id = <7417355cde64e37195bc7a66c6719aef@www.wpwhitesecurity.net> postfix / qmgr [1785]: CF89B3F0EA: from = , size = 1263, nrcpt = 1 (активная очередь) postfix / smtp [6065]: CF89B3F0EA: to = , relay = smtp.sendgrid.net [146.131.234.26]: 587, задержка = 0,02, задержки = 0/0 / 0,01 / 0,01, dsn = 2.0.0, статус = отправлено (250 Ok: в очереди как 7M1TBD6xSfGYOu00qaczcA) postfix / qmgr [1785]: CF89B3F0EA: удалено

постфикс / перехват [5072]: CF89B3F0EA: uid = 33 from =

постфикс / очистка [6063]: CF89B3F0EA: message-id = <7417355cde64e37195bc7a66c6719aef@www.wpr000 / qsecurity postfix>

postfix [1785]: CF89B3F0EA: from = , size = 1263, nrcpt = 1 (очередь активна)

postfix / smtp [6065]: CF89B3F0EA: to = , relay = smtp.sendgrid.net [146.131.234.26]: 587, delay = 0,02, задержки = 0/0 / 0,01 / 0,01, dsn = 2.0.0, статус = отправлено (250 Ok: в очереди как 7M1TBD6xSfGYOu00qaczcA)

postfix / qmgr [1785]: CF89B3F0EA: удалено

Когда мне нужно обратиться к файлу mail.log?

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

Журнал ошибок SMTP-сервера

На вашем SMTP-сервере также есть файл журнала ошибок. Разные серверы используют разные соглашения об именах для своих файлов журналов, но чаще всего имя файла журнала ошибок SMTP-сервера - mail.ошибка

В файле журнала ошибок SMTP-сервера вы найдете информацию о любых проблемах, с которыми служба столкнулась при запуске, запуске или остановке. В этом файле журнала ошибок вы не найдете информацию об обработке и отправке электронных писем.

Когда мне нужно обращаться к файлу журнала ошибок SMTP-сервера?

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

Файл журнала системного журнала

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

Формат сообщений системного журнала

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

.
  • 0 = аварийный
  • 1 = предупреждение
  • 2 = критическое
  • 3 = ошибка
  • 4 = предупреждение
  • 5 = уведомление
  • 6 = информация
  • 7 = отладка

Когда мне нужно обращаться к файлу системного журнала?

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

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

Другие файлы журналов, которые вы можете найти на своем веб-сервере WordPress

Выше представлен обзор информации, которую вы можете найти в файлах журналов некоторых из наиболее распространенных служб, работающих на веб-сервере WordPress.На вашем веб-сервере может быть несколько других файлов журнала, которые могут быть вам полезны. Все зависит от ваших настроек и от того, какие другие службы вы используете, например, брандмауэр, DNS-сервер, DHCP-сервер и т. Д.

Понимание журналов активности и файлов журналов для лучшего управления веб-сайтом WordPress и веб-сервером

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

Файлы журнала

также позволяют узнать, как система используется (или как злоупотребляют в случае злонамеренных атак), чтобы вы могли ее улучшить. Если это случилось, зарегистрируйте! Я расскажу более подробно об этом на следующем вебинаре, который совместно проводили WP White Security (мы) и Sucuri:

.

4 способа определить, кто вошел в вашу систему Linux

Эта статья написана Хари Хараном.

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

1. Получите запущенные процессы вошедшего в систему пользователя с помощью w

Команда w используется для отображения имен пользователей, вошедших в систему, и того, что они делают.Информация будет считана из файла / var / run / utmp. Вывод команды w содержит следующие столбцы:

  • Имя пользователя
  • Номер компьютера пользователя или номер tty
  • Адрес удаленной машины
  • Время входа пользователя
  • Время простоя (неиспользуемое время)
  • Время, используемое всеми процессами, подключенными к tty (время JCPU)
  • Время, используемое текущим процессом (время PCPU)
  • Команда в настоящее время выполняется пользователями


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

  • -h Игнорировать информацию заголовка
  • -u Отображение средней нагрузки (вывод времени работы)
  • -s Удалите JCPU, PCPU и время входа в систему.

 $  w  23:04:27 до 29 дней, 7:51, 3 пользователя, средняя нагрузка: 0,04, 0,06, 0,02 ПОЛЬЗОВАТЕЛЬСКИЙ TTY ИЗ ЛОГИНА @ IDLE JCPU PCPU ЧТО ramesh pts / 0 dev-db-server 22:57 8,00 с 0,05 с 0,01 с sshd: ramesh [priv] jason pts / 1 dev-db-server 23:01 2:53 0,01 с 0,01 с -bash john pts / 2 dev-db-server 23:04 0,00 с 0,00 с 0,00 с в $  ш-в  ramesh pts / 0 dev-db-server 22:57 17:43 2.52 с 0,01 с sshd: ramesh [priv] jason pts / 1 dev-db-server 23:01 20:28 0,01 с 0,01 с -bash john pts / 2 dev-db-server 23:04 0,00 с 0,03 с 0,00 с w -h $  нед.  23:22:06 до 29 дней, 8:08, 3 пользователя, средняя нагрузка: 0,00, 0,00, 0,00 ПОЛЬЗОВАТЕЛЬСКИЙ TTY ИЗ ЛОГИНА @ IDLE JCPU PCPU ЧТО ramesh pts / 0 dev-db-server 22:57 17:47 2.52s 2.49s наверх Джейсон ПЦ / 1 dev-db-сервер 23:01 20:32 0.01s 0.01s -bash john pts / 2 dev-db-server 23:04 0,00 с 0,03 с 0,00 с w -u $  по сравнению с  23:22:10 до 29 дней, 8:08, 3 пользователя, средняя нагрузка: 0,00, 0,00, 0,00 ПОЛЬЗОВАТЕЛЬСКИЙ TTY ОТ IDLE ЧТО ramesh pts / 0 dev-db-server 17:51 sshd: ramesh [приват] Джейсон ПТС / 1 Дев-БД-сервер 20:36 -баш Джон pts / 2 dev-db-server 1.00s w -s 

2. Получите имя пользователя и процесс авторизованного пользователя с помощью команды who и users

.

who Команда используется для получения списка имен пользователей, которые в настоящее время вошли в систему.Вывод команды who содержит следующие столбцы: имя пользователя, номер tty, дату и время, адрес машины.

 $  кто  ramesh pts / 0 28-03-2009, 22:57 (dev-db-server) Джейсон ПТС / 1 2009-03-28 23:01 (dev-db-server) John pts / 2 28-03-2009, 23:04 (dev-db-server) 


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

 $  кто | вырезать -d '' -f1 | сортировать | uniq  Джон Джейсон Рамеш 

Команда пользователя

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

 $  пользователей  Джон Джейсон Рамеш 

3. Получите имя пользователя, в которое вы сейчас вошли, используя whoami

.

Команда whoami используется для печати имени пользователя, вошедшего в систему.

 $  whoami  Джон 


Команда whoami дает тот же результат, что и id -un , как показано ниже:

 $  id -un  Джон 


who am i Команда отобразит имя вошедшего в систему пользователя и сведения о текущем tty.Вывод этой команды содержит следующие столбцы: имя вошедшего в систему пользователя, имя терминала, текущее время с датой и IP-адрес, с которого этот пользователь инициировал соединение.

 $  кто я  john pts / 2 28-03-2009, 23:04 (dev-db-server) $  кому нравится мама  john pts / 2 28-03-2009, 23:04 (dev-db-server)  Предупреждение:  Не пытайтесь выполнить команду « кто мама ненавидит ». 

Также, если вы выполните su для другого пользователя, эта команда предоставит информацию об имени пользователя, вошедшего в систему.

4. Получить историю входа в систему в любое время

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

  • Имя пользователя
  • Tty номер устройства
  • Дата и время входа в систему
  • Время выхода
  • Общее рабочее время
 $  последний Джейсон  jason pts / 0 dev-db-server Пт, 27 мар, 22:57 все еще авторизован jason pts / 0 dev-db-server пт 27 марта 22:09 - 22:54 (00:45) jason pts / 0 dev-db-server Ср 25 мар, 19:58 - 22:26 (02:28) jason pts / 1 dev-db-server пн 16 мар 20:10 - 21:44 (01:33) Яковлевич / 0 192.168.201.11 пт 13 мар, 08:35 - 16:46 (08:11) jason pts / 1 192.168.201.12 Чт, 12 марта, 09:03 - 09:19 (00:15) jason pts / 0 dev-db-server 11 мар, среда, 20:11 - 20:50 (00:39 


Эта статья написана Хари Хараном. Он работает в bk Systems (p) Ltd и заинтересован в разработке открытого исходного кода. Geek Stuff приветствует ваши советы и гостевые статьи.

Если вам понравилась эта статья, вам тоже может понравиться..



.Ведение журнала

- средство ведения журнала для Python - документация Python 3.8.5

Исходный код: Lib / logging / __ init__.py


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

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

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

Основные классы, определенные модулем, вместе с их функциями: перечислено ниже.

  • Регистраторы предоставляют интерфейс, который напрямую использует код приложения.

  • Обработчики отправляют записи журнала (созданные регистраторами) в соответствующие место назначения.

  • Фильтры обеспечивают более детальное средство для определения записей журнала. для вывода.

  • Устройства форматирования определяют структуру записей журнала в окончательном выводе.

Объекты регистратора

Регистраторы

имеют следующие атрибуты и методы. Обратите внимание, что регистраторы должны НИКОГДА не создавайте экземпляр напрямую, но всегда через функцию уровня модуля logging.getLogger (имя) . Несколько вызовов getLogger () с одним и тем же name всегда будет возвращать ссылку на один и тот же объект Logger.

Имя потенциально является иерархическим значением, разделенным точками, например foo.bar.baz (хотя это также может быть просто foo , например). Регистраторы, расположенные ниже в иерархическом списке, являются потомками регистраторов. выше в списке. Например, для регистратора с именем foo , регистраторы с именами foo.bar , foo.bar.baz и foo.bam - все потомки foo . Иерархия имени логгера аналогична Python иерархия пакетов, и идентична ей, если вы организуете свои регистраторы на помодульное основание с использованием рекомендованной конструкции лесозаготовка.getLogger (__ имя__) . Это потому, что в модуле __name__ - имя модуля в пространстве имен пакета Python.

класс лесозаготовка. Регистратор
размножить

Если значение этого атрибута истинно, события, регистрируемые в этом регистраторе, будут передается обработчикам регистраторов более высокого уровня (предков), в дополнение к любые обработчики, прикрепленные к этому регистратору. Сообщения передаются непосредственно в обработчики регистраторов предков - ни уровень, ни фильтры предка Рассмотрены рассматриваемые регистраторы.

Если это ложно, сообщения журнала не передаются обработчикам предков регистраторов.

Конструктор устанавливает для этого атрибута значение True .

Примечание

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

Набор Уровень ( уровень )

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

Когда создается регистратор, устанавливается уровень NOTSET (что вызывает все сообщения, которые будут обрабатываться, когда регистратор является корневым регистратором или делегированием родительскому, когда регистратор не является корневым регистратором). Обратите внимание, что корневой регистратор создается с уровнем ПРЕДУПРЕЖДЕНИЕ .

Термин «делегирование родителю» означает, что если регистратор имеет уровень NOTSET, его цепочка регистраторов предков просматривается до тех пор, пока предок с найден уровень, отличный от NOTSET, или достигнут корень.

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

Если корень достигнут, и он имеет уровень NOTSET, то все сообщения будут обработанный. В противном случае уровень корня будет использоваться в качестве эффективного уровня.

Список уровней см. В разделе «Уровни ведения журнала».

Изменено в версии 3.2: параметр level теперь принимает строковое представление уровень, такой как «INFO» в качестве альтернативы целочисленным константам например ИНФОРМАЦИЯ .Обратите внимание, однако, что уровни хранятся внутри как целые числа и методы, например, getEffectiveLevel () и isEnabledFor () будет возвращать / ожидать передачи целых чисел.

isEnabled для ( уровень )

Указывает, будет ли обработано этим регистратором сообщение с уровнем серьезности . Этот метод сначала проверяет уровень модуля, установленный logging.disable (level) , а затем эффективный уровень регистратора, как определено по getEffectiveLevel () .

getEffectiveLevel ()

Указывает эффективный уровень для этого регистратора. Если значение, отличное от NOTSET был установлен с помощью setLevel () , он возвращается. В противном случае, иерархия перемещается к корню до тех пор, пока значение, отличное от NOTSET найдено, и это значение возвращается. Возвращенное значение целое число, обычно одно из протоколов .EBUG , протоколирование .INFO пр.

getChild (суффикс )

Возвращает регистратор, который является потомком этого регистратора, как определено суффиксом.Таким образом, logging.getLogger ('abc'). GetChild ('def.ghi') вернет то же самое logger, как будет возвращено logging.getLogger ('abc.def.ghi') . Это удобный метод, полезный, когда родительский регистратор назван с использованием, например, __name__ а не буквальную строку.

Отладка ( сообщение , * args , ** kwargs )

Регистрирует сообщение с уровнем DEBUG в этом регистраторе. msg - это строка формата сообщения, а args - это аргументы, которые объединяются в msg с использованием оператора форматирования строки. (Обратите внимание, это означает, что вы можете используйте ключевые слова в строке формата вместе с одним аргументом словаря.) Операция% форматирования не выполняется для msg , если не предоставлено args .

В kwargs проверяются четыре аргумента ключевого слова: exc_info , stack_info , stacklevel и extra .

Если exc_info не оценивается как ложь, это вызывает информацию об исключении. добавлен в сообщение журнала. Если кортеж исключения (в формате, возвращаемом sys.exc_info () ) или экземпляр исключения предоставляется, он используется; в противном случае вызывается sys.exc_info () для получения информации об исключении.

Второй необязательный аргумент ключевого слова - stack_info , wh

.

Смотрите также