Правила ведения журнала

Question

При использовании средства ведения журнала, каковы общие "практические правила"? Э.Г.

• Ограничение скорости сообщения от X до Y сообщений в единицу времени Z?
• Ждать недавнего сообщения об успехе типа T, прежде чем регистрировать "новое" сообщение об ошибке того же типа?

Answer 1

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

1. Позволите ли вы событию случиться, если журнал события потерпит неудачу? Если да, у вас есть еще много вариантов, если нет, то вам нужно сделать свой журнал событий частью транзакционного блока, когда вы сохраняете событие
2. Будут ли очищены журналы или они сохраняются в течение всей жизни системы? Если да, еще раз у вас есть много вариантов. Если нет, тогда вы захотите поместить их в базу данных.
3. Сколько данных будет в журналах? Рассмотрите возможность индексации и / или разбиения таблицы. Также подумайте, как вы собираетесь получить доступ к журналам. Записывать события на родительский объект вместо каждого дочернего. Например, Журнал учета, со множеством подпрограмм, в котором перечислены транзакции. Вместо того, чтобы регистрировать идентификатор транзакции, в которой была подтверждена транзакция, зарегистрируйте журнал, чтобы транзакция была одобрена.

Это всего лишь несколько вопросов для размышления.

Answer 2

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

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

Answer 3

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

• При сбое запроса к БД рассмотрите возможность печати текста запроса с хорошим форматированием (например, ошибки Sybase обычно содержат только частичный запрос mangles)

• Используйте средство ведения журнала, которое имеет хорошее форматирование, включая возможность пометить INFO / WARN / ERROR (или уровень сообщения журнала), для упрощения поиска

• Используйте средство регистрации, которое имеет приличную возможность отметок времени.

• Как вы заметили, рассмотрите объем. Дроссельные или пакетные сообщения.

Answer 4

Если вам нужно отменить сообщения, откажитесь от неважных.

Если вы показываете важное сообщение, не хороните его в потоке неважных.

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

Позволяет узнать текущее состояние системы без необходимости читать каждое старое сообщение.

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

Рассмотрите возможность использования стандартного выходного формата / носителя (например, SNMP, <small> или журнал событий NT </small>), который можно просматривать и управлять с помощью полнофункциональных сторонних инструментов.

Answer 5

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

Answer 6

• Не регистрируйте пароли!
• Если это возможно, попытайтесь избежать повторения одного и того же сообщения, если ошибка вошел в систему много раз, пока система не восстанавливается из него. Просто запишите что-то вроде «ошибка типа x, произошла n раз от timestamp1 до timestamp2».
• Не храните свои журналы вечно, применяйте политики ротации (могут основываться на размерах файлов или периодах времени).
• Последовательно используйте разные уровни журнала для разных ситуаций.