Какова ваша стратегия записи журналов в вашем программном обеспечении для обработки ОГРОМНОГО количества сообщений журнала?

Question

Спасибо за ваше время и извините за это длинное сообщение!

Моя рабочая среда

Linux C / C ++ (но я новичок в платформе Linux)

Мой вопрос вкратце

В программном обеспечении, над которым я работаю, мы пишем ЛОТ сообщений журнала в локальные файлы , которые позволяют быстро увеличивать размер файла и, наконец, используют весь диск пространство (уч!). Нам нужны эти сообщения журнала для устранения неполадок , особенно после выпуска программного обеспечения на сайт клиента. Я считаю, что, конечно, недопустимо занимать все дисковое пространство компьютера клиента, , но я не знаю, как с этим справиться . Так что Мне интересно , есть ли у кого-нибудь хорошая идея здесь Более подробная информация приведена ниже.

Что я НЕ спрашиваю

1). Я НЕ запрашиваю рекомендованную библиотеку журналов C ++. Мы сами написали регистратор.

2). Я НЕ спрашиваю о том, какие детали (такие как отметка времени, идентификатор потока, имя функции и т. Д.) Должны быть записаны в сообщении журнала. Некоторые предложения можно найти здесь .

Что я сделал в своем программном обеспечении

Я разделяю сообщения журнала на 3 категории:

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

• ОШИБКА: не регистрируется только ошибка, например, идентификатор не найден. Обычно не так много таких сообщений.

• ИНФОРМАЦИЯ: Зарегистрируйте подробные шаги, выполняемые в моем программном обеспечении. Например, когда вызывается метод интерфейса, сообщение журнала SYSTEM записывается, как упомянуто выше, и вся процедура вызова во внутренние модули в методе интерфейса будет записываться с сообщениями INFO. Идея заключается в том, что эти сообщения могут помочь нам определить подробный стек вызовов для устранения неполадок или отладки. Это источник проблемы использования дискового пространства : всегда есть SO MANY INFO сообщений, когда программное обеспечение работает нормально.

Мои попытки и мысли

1). Я пытался не записывать никаких сообщений журнала INFO. Это решает проблему с дисковым пространством, но я также терял много информации для отладки. Подумайте об этом : мой клиент находится в другом городе, и часто туда ездить дорого. Кроме того, они используют интранет, который на 100% недоступен извне. Поэтому: мы не всегда можем отправить инженеров на место, как только они столкнутся с проблемами; мы не можем начать сеанс удаленной отладки. Таким образом, файлы журнала, я думаю, являются единственным способом, который мы могли бы использовать, чтобы выяснить причину проблемы.

2). Может быть, я мог бы сделать стратегию ведения журнала настраиваемой во время выполнения (в настоящее время это до запуска программного обеспечения), то есть: при обычном времени выполнения программа записывает только журналы SYSTEM и ERROR; когда возникает проблема, кто-то может изменить конфигурацию ведения журнала, чтобы можно было регистрировать сообщения INFO. Но все же: кто может изменить конфигурацию во время выполнения? Может быть, мы должны обучить администратора программного обеспечения?

3). Может быть, я всегда смогу включить регистрацию сообщений INFO, но периодически упаковывать файлы журналов в сжатый пакет? Хмм ...

Наконец-то ...

Каков ваш опыт в ваших проектах / работе? Любые мысли / идеи / комментарии приветствуются!

EDIT

СПАСИБО за все ваши усилия !!! Вот краткое изложение ключевых моментов из всех ответов ниже (и я дам им попытку):

1). Не используйте большие файлы журнала. Используйте относительно маленькие.

2). Периодически обрабатывайте самые старые из них (либо удалите их, либо заархивируйте и поместите в большее хранилище).

3). Реализуйте настраиваемую стратегию ведения журнала.

Answer 1

Ваш (3) является стандартной практикой в ​​мире системного журналирования UNIX.

1. Когда файл журнала достигает определенного возраста или максимального размера, запустите новый
2. Zip илив противном случае сжимайте старый
3. , выбрасывайте n-й самый старый сжатый журнал

Answer 2

Необходимо обратить внимание на две важные вещи:

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

По моему опыту, простой способ справиться с этим:

• Только запись маленьких файлов: запуск нового файла для нового сеанса или когда текущий файл превышает заданный предел (я считаю, что 50 МБ достаточно эффективны),Чтобы помочь найти файл, в который были записаны журналы, сделайте дату и время создания частью имени файла.
• Сжатие журналов, либо в автономном режиме (после завершения файла), либо в сети (вfly).
• Поставьте на место процедуру очистки, удалите все файлы старше X дней или, если вы наберете более 10, 20 или 50 файлов, удалите самые старые.

Если вы хотите хранить журналы System и Error дольше, вы можете продублировать их в определенном вращающемся файле, который только отслеживает их.

Поместите вместе, это даст следующий журналпапка:

 Log/
   info.120229.081643.log.gz // <-- older file (to be purged soon)
   info.120306.080423.log // <-- complete (50 MB) file started at log in
                                 (to be compressed soon)
   info.120306.131743.log // <-- current file

   mon.120102.080417.log.gz // <-- older mon file
   mon.120229.081643.log.gz // <-- older mon file
   mon.120306.080423.log // <-- current mon file (System + Error only)

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

Примечание: из опыта 50 МБ в результате сжатия наfly и менее 5 МБ при сжатии в автономном режиме (на лету менее эффективно).

Answer 3

Один из способов справиться с этим - вращать файлы журнала.

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

У вас не будет всей возможной информации, но у вас будет по крайней мере кое-что, что может привести к проблеме.

Стратегия ведения журнала звучит необычно, но у вас есть свои причины.

Answer 4

Я бы

a) Сделайте уровень детализации в сообщениях журнала настраиваемым во время выполнения. б) Создать новый файл журнала для каждого дня. Затем вы можете заставить cron либо сжать их и / или удалить их, либо, возможно, перенести в другое хранилище.

Answer 5

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

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

У нас была программа на каждом из наших настольных компьютеров, которая показывала список (обновленный F5) проблем, которые мы могли назначить себе и отметить как обработанные. Но теперь я увлекаюсь:)

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

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

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

Answer 6

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

Сжимайте их ежедневно - но держите их в течение недели