Вопросы Теги

Какова лучшая практика для форматирования журналов?

C в доме. (не уверенный, если Вы не хотели примера C здесь) 

bool IsPalindrome(char *s)
{
    int  i,d;
    int  length = strlen(s);
    char cf, cb;

    for(i=0, d=length-1 ; i < length && d >= 0 ; i++ , d--)
    {
        while(cf= toupper(s[i]), (cf < 'A' || cf >'Z') && i < length-1)i++;
        while(cb= toupper(s[d]), (cb < 'A' || cb >'Z') && d > 0       )d--;
        if(cf != cb && cf >= 'A' && cf <= 'Z' && cb >= 'A' && cb <='Z')
            return false;
    }
    return true;
}

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

кроме того, если Вам не нравится bool в "C" программе, он мог бы, очевидно, возвратить интервал, с возвратом 1 и возвратиться 0 для истины и лжи соответственно.

50
задан keepAlive 9 November 2018 в 02:37
поделиться

5 ответов

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

$ 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 . Обычно у меня есть файл в день, по одной папке на каждый месяц, по одной папке на каждый год. Вы получите огромные файлы журналов, которые в противном случае вы не сможете отредактировать должным образом. 

logs/
  2009/
    January/
     01012009.log
     02012009.log
     ...
    February/
     ...
  2008/
   ...
28
ответ дан 7 November 2019 в 11:07
поделиться

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

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

2
ответ дан 7 November 2019 в 11:07
поделиться

Обычно я просто передаю интерфейс классу фабрики.

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

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

0
ответ дан 7 November 2019 в 11:07
поделиться

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

  • Все в одном файле . Кажется, не вариант для вас.
  • Прокат фиксированного размера . Вы определяете размер, когда создается новый файл журнала, если текущий файл больше заданного значения. Обычно для этого есть готовая поддержка в большинстве пакетов log4anything .
  • Всего настраиваемая прокрутка . Я видел такие макеты
    • Каждый день получает собственный каталог с именем в формате ГГГГММДД . Если вы не публикуете свои журналы, рассмотрите расположение каталогов, например, ГГГГ \ ММ \ ГГГГММДД, как показано в других ответах.
    • Внутри этого каталога следует использовать фиксированный размер прокатки .
    • Каждый файл имеет имя logfile_yyyymmdd_ccc.log где ccc - возрастающее число. Добавление времени к имени файла также является хорошей идеей (например, чтобы легко определить, сколько журналов в минуту вы генерируете)
    • Для экономии места каждый журнал автоматически сжимается с помощью zip.
    • Последние 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

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

  • Всегда сохранять дату в имени файла журнала
  • Всегда добавлять имя к имени файла журнала. Это поможет вам в будущем различать файлы журналов из разных экземпляров вашей системы.
  • Всегда время и дата журнала (желательно с разрешением до миллисекунд) для каждого события журнала.
  • Всегда сохранять ваши дата в формате ГГГГММДД. Везде. В имени файла, внутри файла журнала. Это очень помогает при сортировке. Допускаются некоторые разделители (например, 29 ноября 2009 г.)
  • В общем, избегайте хранения журналов в базе данных. Это еще одна точка отказа в вашей схеме ведения журнала.
  • Если у вас многопоточная система, всегда записывайте идентификатор потока.
  • Если у вас многопроцессорная система, всегда записывайте идентификатор процесса.
  • Если у вас много компьютеров, всегда регистрируйте идентификатор компьютера .
  • Убедитесь, что вы сможете обрабатывать журналы позже. Просто попробуйте импортировать один файл журнала в базу данных или Excel . Если на это уходит больше 30 секунд, значит, ваш журнал неверен. Это включает в себя:
    • Выбор хорошего внутреннего формата ведения журнала. Я предпочитаю разделитель пробелами, так как он хорошо работает с текстовыми инструментами Unix и с Excel .
    • Выбор хорошего формата для даты / времени, чтобы вы могли легко импортировать в некоторую базу данных SQL или Excel для дальнейшая обработка.
19
ответ дан 7 November 2019 в 11:07
поделиться

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

Log4J @ Apache.Org
Log4Net @ Apache.Org

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

2
ответ дан 7 November 2019 в 11:07
поделиться
Другие вопросы по тегам:

Похожие вопросы: