syslog - классификация строк журнала

Question

Очень общий вопрос; в контексте программиста, имея в виду операционный аспект процесса (программы).

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

То, что я хочу знать, от некоторых из вас опытных людей; Какую разумную логику следует использовать здесь, чтобы мальчикам / девочкам было легко классифицировать эти сообщения и выявлять проблемы?

Answer 1

Всего три аспекта с точки зрения администратора и анализа журнала / классификации:

• Сделать поле тега / имя программы настраиваемым. Затем можно настроить несколько экземпляров для использования тегов журнала, таких как app/user_1, app/user_2 и т. Д., Что позволяет использовать быстрые и простые фильтры на уровне системного журнала.
• Структурируйте свои сообщения слева направо, чтобы можно было фильтровать различные категории строк журнала с помощью простых шаблонов поиска или регулярных выражений. Например. config error - cannot parse line 123 или runtime warning - lost connection to DB xyz
• Для очень структурированных журналов вы также можете взглянуть на поле «структурированные данные» в протоколе syslog . До сих пор он используется редко и без поддержки инструментов, но он допускает сообщения журнала приложений с пространствами имен и очень четкими атрибутами ключ-значение.

Answer 2

Большинство * nix процессов регистрируют журнал в системном журнале (или, по крайней мере, должны), используя полустандартный формат «Месяц, день, 24-часовой хост, имя_процесса [pid]: сообщение».В системном журнале есть способы указать серьезность сообщения, использовать их (хотя имейте в виду, что серьезность зависит от перспективы системы, а не от приложений).

Если сообщение является проблемой отладки, то обычно это «Имя_функции Имя_файла Line_No Error_CodeError_Desc ";в противном случае формат сообщения полностью зависит от программы.

Для мультитенантных систем довольно часто часть «сообщения» начинает с какой-либо формы идентификации арендатора, за которой следует фактическое сообщение журнала.

Answer 3

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

Я полагаю, вы соберете журналы с разных машин с их системным журналом на центральную машину, отвечающую за контроль / мониторинг.