Oduvan’s Web Blog

Это продолжение моего общения с собой на тему логов.

Размышляя на тему логов, у которых нет конца – я пришел к выводу – что у записи конец обязан быть. Парсеру возможно это и не важно, но человеку надо знать, что эта запись полная.

Например у Вас такая часть лога


"date time,"log,"inc sum: 100


Парсер эту строку распарсит очень просто, а вот у человека не будет уверенности в цифре. А может там был мильен.

Именно по этому у записи должна быть точка. И пока кроме идеи – тупо добавлять ячейку с точкой мне ничего в голову не пришло.

Так что теперь наша запись в логах меняется на следующую:

"date time,"log,"inc sum: 100,".


В принципе можно заморочиться на том, чтоб записи, в которых реально только одна точка – заменять на 2, а 2 – на 3. Ну т.е. при парсе надо понимать, что если в записи – одни точки, то нужно уменьшить их кол на одну. Но чем дольше я об этом думаю, тем больше понимаю, что это уже перебор. И такую погрешность можно взять в учет.

Откуда вообще у меня тараканы в голове на тему логов.

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

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

Сегодня уже фиксы в текущие логи внести не получится, но завтра постараюсь выкроить время.

Ищу еще двух в комманду.

Если Вы читаете этот блог, ищите работу и что-то понимаете в питоне, то напишите мне support@lyabah.com, возможно Вы ее нашли.

Отличный вариант, если вы еще и с Днепропетровска, Украина.

Хотя знаете, даже если вам просто скучно и надо выговориться, то тоже пишите

Я уже когда-то писал и думал о системе логирования на основе csv формата. С начало идею, а потом первую версию для джанги.

Но в процессе пользования этой системы вылезло несколько недостатков.

1. В таком формате легко потерять целостность логов. Например скрипт ведения логов упал в момент из записи. Срока разорвалась в момент записи одно из полей и все. Вся БД логов потеряна
2. Надо заранее знать количество полей в логе

Поэтому я разработал другой формат – UCSV. И модуль для ведения логов на его основе python-ucsvlog.

В этом формате нет конца ни у записи ни у ячейки, есть только начало записи и начало ячейки. В этом случае конец ячейки — это просто начало следующей или начало следующей строки.

Начало записи — это перевод строки
а начало ячейки — это просто ”
ну и из csv формата — кавычка в данных ячейки заменяеться двумя

В этом случае нам не надо волноваться за целостность всех логов. В случае падения мы потеряем только одну строку

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

Класс импорта в SQLite — ReaderSqlite. Правда во время импорта данных у которых в записи неограниченное число ячеек столбцы добавляются по ходу.

Из csv логов я забрал идею древовидности логов. Когда у каждой записи есть ключ, привязанный ко времени создания и ключ парент записи. За это отвечают 2 первые ячейки в записи. А также авторендеринг — имя файла логов можно задавать в виде шаблона. Например ‘/logs/%(syear)s-%(month)s-%(day)s.ucsv’

Для джанги я создал отдельный пакет django-ucsvlog. Те кто пользовался django-csvlog смогут легко перескочить. Поддержку последнего я осуществлять более не буду.

По мере пользования этой системы логирования я буду собирать еще один компонент django-ucsvlog-analytics. В нем будут собраны скрипты для анализа логов. Например профилирование, оно очевидно из-за привязки ко времени логов. Можно сводить статистику — самые тяжелые страницы + самые часто запрашиваемые и получать то, что надо оптимизировать в первую очередь. Или например анализ юзабилити. Можно вычислять точки не возврата, страницы, которые пользователь посещал в последний раз, или на какую страницу переходят после указанной ( иногда только такая сухая статика может убедить клиента в неюзабельность предложенного им варианта ). Можно делать каунтеры посещений определенных страниц, сколько уникальных просмотров было на этом альбоме. Можно увидеть путь по сайту определенного пользователя.

Такие логи дают много возможностей, и список «можно» – можно продолжать бесконечно. Пробуйте.
python-ucsvlog, django-ucsvlog, django-ucsvlog-analytics