Итак, поздравляю вас с окончанием трудовой недели. Лично для меня неделя была не из простых, но с большинством задач я справился, так что через пару часов уйду на заслуженные выходные.
Но пост мой не об этом. Я уже когда писал о своей реализации ведение логов для перла . Сейчас хочу поделится своей новой идеей ведения логов. Как вариант — пост может быть не дописан. Т.к. очень часто, когда ты начинаешь описывать свою идею на бумаге , то начинаешь задумываться над подробностями и над кажущимися, по началу, мелочами, приводить в порядок мысли и оказывается, что это уже не такая уж и гениальная идея. Кроме того полезно почитать сторонние отзывы, а возможно это подтолкнет читателя на написание чего то большего или развитию идеи в иное русло.
Итак немного предыстории и введение в проблематику.
Я веду один из банковских проектов — написания и сопровождения CashPay терминалов. И изначально решение предназначалось именно для них, хотя и для других моих проектов — это тоже будет хорошим дополнением.
От слов к делу. Как выглядит лог, например, лайти. Вот одна запись:
10.55.6.59 10.55.6.57 – [19/Jan/2009:15:56:39 +0200] “POST /index.cgi HTTP/1.1″ 200 31 “-” “libwww-perl/5.812″
Что какое поле тут означает – я распинатся не будут. Просто скажу, что для этих логов, и для многих других как правило все сводится к определённому формату.
1.Всегда есть время. И даже если его нет, то как правило — это ПОКА нет. Т.к. вообще теряется сам смысл ведения логов.
2.Есть какая то служебная инфа, присутствующая во всех записях. Это может быть айди процесса, который сейчас пишет лог, или айди пользователя, который сейчас совершает действия.
3.Собственно данные которые вы хотите сохранить для потомков, которые будут разгребать ваши баги. Иногда их подписывают фразами (error, debug, info) Это необходимо для некой группировки логов.
Кажется ничего не забыл. Как правило — этого достаточно. Для чего?
Случилась ошибка, сервер вам о ней отрапортовал, вы выкачали логи, нашли запись о этой ошибке и пошли смотреть хронологию событий. В случае если у вас один процесс, который пишет данные, то этого достаточно, и именно так оно происходит. Если идет взаимодействие двух служб процессов, разные логи, открываем оба, в оба смотрим. Больше сервисов, больше логов, больше мониторов. Тенденция ясна. Но с другой стороны логи должны вестись просто. Открыл файл, плюнул в файл данные, закрыл файл.
Мое решение — логи в CSV формате. Идея реально не нова. Я ее подсмотрел в постгрисе, если его не привязывать к syslog, то свои логи он пишет именно так. Плюс, один мой друг, высказывал идею ведения логов в базе. По окончанию получился некий сембиоз идей.
Итого, ведя логи в CSV — можно вести их легко и быстро + для анализа можно ипортировать их в любую удобную для вас БД.
В PostgreSQL это делается одной командой.
COPY tables_for_log FROM ‘/full/path/to/logfile.csv’ WITH csv;
На самом деле уже это дает очень много плюсов. Хотя бы то, что теперь процесс анализа логов может сводится к простому пользовательскому интерфейсу, в котором вы на первом шаге выбираете даты и возможно сервисы, по которым вам необходимо искать данные. На следующем этапе находятся необходимые логи, распаковываются при необходимости, импортируются в БД и выводится инфа и совершенном импорте. Далее у вас просто текстовое поле, в котором вы оперируете SQL командами для выдачи результатов по логам. Это текстовое поле вам необходимо будет только для начала, чтоб понимать какого рода выборки вам необходим будет делать для решения проблем. После все можно будет свести уже к более удобным интерфейсам. Но это уже будет для каждого проекта своё и глубже я заходить не буду.
Ещё одним неоспоримым плюсом является то, что если две системы друг с другом взаимодействуют и пишут логи в одинаковых ( или сходных друг с другом ) форматах, то вы можете импортировать эти логи в одну таблицу вашей БД. И уже в одном сплошном листинге наблюдать процесс взаимодействие двух сервизов друг с другом. Мне кажется это очень удобным, т.к. в одном из моих проектов таких взаимодействующих систем 4. И процедура поиска ошибки просто выматывает. Да и можно проводить автоматическое тестирование работы систему уже по её результатам ( но про это я рассказывать не буду, потому что подходов много, а решений ещё больше)
Далее, если развивать идею ведения логов, то очевидно, что в любой системе, либо сервисе — есть событие и есть реакция системы на это событие. Запрос урла к вашему серверу — есть событием, а то, что ваш сервер начал делать выборки из базы, изменять её, формировать ответ и выдавать пользователю результат — это уже реакция системы на произошедшее событие. Таким образом я предлагаю разделать на два лога (два CSV файла), и связывать их как один ко многим. Как поле связи можно использовать время, когда было получено событие в миллисекундах. Итого в первую таблицу мы кладем события. Для веб сайтов это может быть время, урл, куки, пост данные, айди пользователя. Вторая таблица уже куда более привязана к конкретному проекту, туда мы сбрасываем все трейсы переменных, возможно ошибки, короче все, что вы до этого писали в логи. Но обязательно должно быть время события ( для связи), время лога. Дальше можно разделить код на компоненты и в логах записывать название компонентов в которых они ведутся, можно просто записывать имя модуля и имя функции. На самом деле вариантов масса. Но я бы всегда разбивал логи по степени важности (debug, info, error)
Все, идеи по логам кончились. Примеров реализации пока не выкладываю, ну просто потому, что там реально будет строк 20 кода. А вообще как вам идея?
Спонсор поста Вывоз мусора в Москве ( у них я взял картинку )
