Как мне отформатировать журналы?

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

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

Формат каждой строки, есть ли у меня один стандартный разделитель, который является whater, *, -, +, что-нибудь? Существует ли какой-либо стандарт в любом месте (мой поисковик не принес много).

Спасибо!

Ответ 1

Мне нравится этот формат для файлов журнала:

$ python simple_logging_module.py
2005-03-19 15:10:26,618 - simple_example - DEBUG - debug message
2005-03-19 15:10:26,620 - simple_example - INFO - info message
2005-03-19 15:10:26,695 - simple_example - WARNING - warn message
2005-03-19 15:10:26,697 - simple_example - ERROR - error message
2005-03-19 15:10:26,773 - simple_example - CRITICAL - critical message

Это из python

Ответ 2

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

Все в одном файле. Кажется, это не вариант для вас.
Фиксированный размер. Вы определяете размер, когда новый файл журнала создается после того, как текущий файл больше определенного значения. Обычно в большинстве пакетов log4anything есть поддержка из коробки.
Общая пользовательская перемотка. Я видел такие макеты, как это
- Каждый день получает свой собственный каталог, названный в формате YYYYMMDD. Если вы не ставите свои журналы, рассмотрите макет каталога, такой как YYYY\MM\YYYYMMDD, как показано в других ответах.
- Внутри этого каталога должен использоваться фиксированный размер.
- Каждый файл имеет имя logfile_yyyymmdd_ccc.log, где ccc увеличивается число. Добавление времени к имени файла также является хорошей идеей (например, чтобы легко судить, сколько журналов в минуту вы генерируете).
- Для экономии места каждый журнал автоматически сжимается почтой.
- Последние 3 дня всегда сохраняются несжатыми, поэтому вы можете иметь быстрый доступ с текстовыми инструментами UNIX.

Этот обычай выглядел так:

logs/
  20090101/
     logfile_20090101_001.zip
     logfile_20090101_002.zip
     ...
  20090102/
     logfile_20090102_001.zip
     logfile_20090102_002.zip
   logfile_20090101_001.log
   logfile_20090101_002.log
   logfile_20090102_001.log
   logfile_20090102_002.log

Существует также несколько хороших практик для хорошего ведения журнала:

Всегда сохранить дату в имени файла журнала
Всегда добавить имя вашего имени файла журнала. Это поможет вам в будущем отличать файлы журналов от разных экземпляров вашей системы.
Всегда регистрировать время и дату (предпочтительно до миллисекундного разрешения) для каждого события журнала.
Всегда хранить дату как YYYYMMDD. Везде. В имени файла внутри файла журнала. Это очень помогает при сортировке. Разрешены некоторые разделители (например, 2009-11-29).
В общем случае избегайте хранения журналов в базе данных. In - еще одна точка отказа в вашей схеме ведения журнала.
Если у вас многопоточная система всегда регистрирует поток id.
Если у вас есть многопроцессная система, всегда регистрируйте идентификатор процесса.
Если у вас много компьютеров, всегда регистрируйте идентификатор компьютера.
Убедитесь, что вы можете обрабатывать журналы позже. Просто попробуйте импортировать один файл журнала в базу данных или Excel. Если это занимает больше 30 секунд, это означает, что ваш журнал неправильный. Это включает:
- Выбор хорошего внутреннего формата ведения журнала. Я предпочитаю пробел, поскольку он отлично работает с текстовыми инструментами UNIX и с Excel.
- Выбор хорошего формата для даты/времени, чтобы вы могли легко импортировать в SQL файл SQL или Excel для дальнейшей обработки.

Ответ 3

Чтобы разбить ваши файлы журналов, вы можете использовать внешнее приложение, например logrotate, и пусть оно позаботится о грязной работе.

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

Ответ 4

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

Это для системы honeypot (и если злоумышленники действительно не удаляют приложение/сайт), вы можете рассмотреть возможность дополнительного времени для входа в базу данных вместо.

Это упростит анализ и использование журналов и в режиме реального времени (т.е. вам не нужно проходить процесс ETL до анализа/просмотра журналов.

Это указано в таблице (-ях) БД или в файле (-ах), это не исключает необходимости определить формат. Ориентировочно вы можете иметь "полиморфный" формат с несколькими общими атрибутами (ID, IP-адрес, отметка времени, Cookie/ID, "уровень" [важность/срочность]), за которым следует короткий мнемонический код, определяющий конкретный тип события ( скажем, "LIA" = попытка входа в систему, "GURL" = угаданный url, "SQLI" попытка SQL Injection и т.д.), за которым следуют несколько числовых полей и несколько строковых полей, семантика которых будет меняться в зависимости от мнемоники. Подводя итог:

 - Id
 - TimeStamp  (maybe split in date and time)
 - IP_Address
 - UserID_of_sorts
 - // other generic/common fields that you may think of
 - EventCode   (LIA, GURL, SQLI...)
 - Message   Text message (varies with particular event instance)
 - Int1      // Numbers...
 - Int2
 - Str1      // ...and text which meaning varies with the EventCode
 - Str2
 - //... ?

Теперь... независимо от того, что это происходит с плоским файлом или с базой данных SQL (и, возможно, особенно при переходе в БД), вы можете/должны использовать стандартную библиотеку ведения журнала. Может быть, log4j, как было предложено в других ответах (хотя я не уверен, что он легко привязан к Python, и в любом случае стандартный модуль протоколирования Python +/- тот же...) или даже Модуль протоколирования стандартной библиотеки Python, вероятно, может быть адаптирован для ваших нужд.

Ответ 5

Я рекомендую вам использовать известную библиотеку протоколирования. Большинство журнальных библиотек поддерживают опрокидывание для вас. Log4Net (.net)/Log4J (java) - особенно хорошая библиотека регистрации, и у нее есть много вариантов, которые могут оказаться полезными. Используйте любой интервал опроса, который лучше всего подходит для вас. Для приложения honeypot, я думаю, вы найдете ежедневный или ежедневный оборот для лучшей работы. Вы также можете использовать фиксированный лимит, например 256 МБ, чтобы гарантировать, что ваши усилия в журналах не перекрывают доступное свободное место на диске. Log4Net/Log4J также поддерживает это.

Log4J @Apache.Org
Log4Net @Apache.Org

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

Ответ 6

На мой взгляд, самое важное:

Начать записи (строки) с датой/временем, отформатированными после профиля W3Cs ISO 8601
Используйте вкладку в качестве разделителя полей в записях