Oduvan's Web Blog

Некрасивая девочка

Oduvan — Tue, 24 Apr 2012 08:22:01 +0000

Перепост отсюда. http://web-brains.com/2010/04/08/kak-krasivo/ Как красиво

Среди других играющих детей
Она напоминает лягушонка.
Заправлена в трусы худая рубашонка,
Колечки рыжеватые кудрей
Рассыпаны, рот длинен, зубки кривы,
Черты лица остры и некрасивы.
Двум мальчуганам, сверстникам её,
Отцы купили по велосипеду.
Сегодня мальчики, не торопясь к обеду,
Гоняют по двору, забывши про неё,
Она ж за ними бегает по следу.
Чужая радость так же, как своя,
Томит её и вон из сердца рвётся,
И девочка ликует и смеётся,
Охваченная счастьем бытия.

Ни тени зависти, ни умысла худого
Ещё не знает это существо.
Ей всё на свете так безмерно ново,
Так живо всё, что для иных мертво!
И не хочу я думать, наблюдая,
Что будет день, когда она, рыдая,
Увидит с ужасом, что посреди подруг
Она всего лишь бедная дурнушка!
Мне верить хочется, что сердце не игрушка,
Сломать его едва ли можно вдруг!
Мне верить хочется, что чистый этот пламень,
Который в глубине её горит,
Всю боль свою один переболит
И перетопит самый тяжкий камень!
И пусть черты её нехороши
И нечем ей прельстить воображенье,-
Младенческая грация души
Уже сквозит в любом её движенье.
А если это так, то что есть красота
И почему её обожествляют люди?
Сосуд она, в котором пустота,
Или огонь, мерцающий в сосуде?

Разыскивается Python Developer в команду

Oduvan — Thu, 12 Apr 2012 20:45:29 +0000

Желательно в офис на полную, Днепропетровск. Но можно и удаленка. Работа над проектом CheckIO.org

Можно писать сюда support@lyabah.com или звонить сюда +380503625288

OneToOne

Oduvan — Wed, 11 Apr 2012 16:46:22 +0000

Мыль, коротка, убейте критикой.

Ксательно орм и бд.

Если У Вас есть один обхект данных – например пользователь, который имеет различные свойтства, например имя, баланс, статистика.

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

Что скажите? Не понятно?

UCSVLOG and GitHub продолжение

Oduvan — Sun, 08 Apr 2012 15:40:52 +0000

django-ucsvlog и django-ucsvlog-analytics также перехали на github. Код там не сильно грязный, но за усердную отчистку и покрытие тестами еще не садился.

у python-ucsvlog небольшое обновлени в формате логов. Т.к. формат строки через “%” – это прошлый век, и format рулит – темлпейт для имен файлов поменялся, так что теперь файл лога с дневным рендерингом будет выглядить примерно так /var/log/django/{year}-{month}-{day}.ucsv

UCSVLOG съехал на GitHub

Oduvan — Fri, 06 Apr 2012 22:29:20 +0000

По многочисленным заявкам python-ucsvlog переехал на github https://github.com/oduvan/python-ucsvlog

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

Рассчитываю на вашу критику.

ПС: Вот так вот выглядит дифф в пеп8

Ищу модератора / контент-медежера для проекта CheckIO связаного с python-разработкой

Oduvan — Thu, 05 Apr 2012 11:00:41 +0000

Главное, чтоб был хороший и добрый

Знания ангийского – ОК, знания python – ОК. Но главное чтобы был хороший…. и добрый…

Оплата договорная после собеседования. Рабоать можно как удаленно, так и в офисе Днепропетровск, Украина, так и парттайм

Можно писать, а можно звонить +380503625288

UCSVLOG

Oduvan — Tue, 03 Apr 2012 22:44:48 +0000

1ого апреля в Киеве в офисе Ciklum состаялась 6ая KyivPy конференция. На которую я “пролез” со своими UCSVLOG. После конфы и общения с людьми я ушел с полной уверенностью в том, что это нужно, и что люди устали от мусора и бесполезности своих логов. Поэтому уже дома я подготовил серию из трех статей о моем докладе на KyivPy

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

Часть 2. Решение – чуть более детально про принципы ведения UCSVLOG

Часть 3. Плюшки – Какая функциональная база для аналитики уже голова у нас, и как вы ее можете расширять и использовать.

Видео Видео, за которое спасибо @Andrew Bananos – где-то минут 20 сам доклад, и 15 мин ответы на вопросы

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

Из проектов в сети по схожей теме стоим обратить внимание не splunk.com – спасибо Максу за наводку. loggly.com и Solr от Apache – спасибо Василию за наводку.

Кста. Харьков, Одесса и Донецк уже организивали свои Py и не по одному разу. Почему Днепр отстает. Если организовывать подобное действо у нас в Днепре – желающие прийти послушать / рассказать / поглядеть будут?

UCSVLOG kyivpy#6 – Как облегчают жизнь качественные логи. Часть 3. Плюшки

Oduvan — Tue, 03 Apr 2012 22:07:30 +0000

Продолжаем о UCSVLOG. Начало читайте тут – Часть 1. Проблема и Идея, потом тут мы продолжили – Часть 2. Решение , ну а сейчас о плюхах

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

django-ucsvlog

Проект лежит на bitbucket.org

Первым для себя применением ucsvlog я нашел в как апой к Django. Он был создан за долго до того, как у Django появились свои логи. И пока миграцию на них я не планирую, а думаю, как объеденить и взять что-то хорошее с джанговских и сделать процесс миграции с джанговских на UCSVLOG более простым.

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

Первая ‘djucsvlog.middleware.LogRequestInfo‘ идет как самой первой в Вашем списке мидлварь,а значит должна запускаться еще до того, как какая-либо из них начнет работать.

Она открывает блок, в который кладется информация о запросе, а в settings задается список полей которые мы хотим записываться, например имя домена, путь, гет, пост параметры, файлы или BROWSER_UUID_COOKIE.

BROWSER_UUID_COOKIE – это простой механизм, который по средствам кук следит за действиями пользователя. Когда приходит пользователь и у нег нет нашей куки – мы ему создаем ее и при каждом его запросе кладет ее в лог. Далее это позволит сводить свою аналитику.
Как дополнительная возможность – это вести лог файлов, которые аплоадит пользователей. Т.е. мы в отдельное место сохраняем все аплоады пользователей, а в логах отмечаем – что и куда мы сохранено.

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

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

Во время работы сам объект логера лежит в глобальной области видимости. Т.е. воспользоваться им можно в любой момент.

За время работы с django-ucsvlog у нас накопилось много настроек для кастомизации этих логов. Все они лежат в djucsvlog.settings.py немного документированные, в лучших традициях опенсорса, с указанием дефолтных значений. Такие как – правило формирования отчет об ексепшене, буферизация, правило определение IP пользователя, возможность сохранять отдельно загружаемые файлы, а в лог класть инфу о том, куда мы сохранили текущий загруженый файл.
+ UCSVLOG_CHANGE_MODEL в этом дикте можно указать – за изменением каких моделей вы хотите следить ( предварительно указав ‘djucsvlog.components.change_model’ в списке компонентов UCSVLOG_COMPONENTS ), и какие поля этих моделей вы хотите класть в лог файл в момент их изменения. Т.е. теперь благодаря логам вы можете связывать изменения любой модели с определенным пользователем – ваще мечта.

Пример settings.py вашего приложения:

MIDDLEWARE_CLASSES = (
'djucsvlog.middleware.LogRequestInfo', ##первый
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.transaction.TransactionMiddleware',
'djucsvlog.middleware.LogViewInfo', ## Второй
)
UCSVLOG_COMPONENTS = (
'djucsvlog.components.change_model',
) # указываем список компонентов ( расширений )
UCSVLOG_FILE_VERSION = 'v3' # о смысле такого хука мы расскажем позже
UCSVLOG_FILE = '/var/log/django/console-%(year)s-%(month)s-%(day)s-'+UCSVLOG_FILE_VERSION+'.ucsv'
# По умолчанию False тоже, но если мы хотим, чтоб логи не велись, а выводились в консоль то делаем тру
UCSVLOG_PRINT = False
# Эти поля будут класться в лог в момент закрытия блока запроса, т.е. в самом конце
UCSVLOG_RESPONSE_FIELDS = ['status','ctype','content']
# кастомные пользовательские функции для логирования
def server_ip(request,*args,**kwargs):
return request.META.get('REMOTE_ADDR', '0.0.0.0')
def ucsvlog_last_login(request,*args,**kwargs):
return request.session.get('last_login','')
# поля, которые мы созраняем при открытии реквеста ( в первой мидлвари )
UCSVLOG_REQUEST_FIELDS = ['http_host','browser_uuid','remote_addr',server_ip,\
'path','get','post','save_files','http_user_agent',\
'http_referer','http_accept_language']
UCSVLOG_VIEW_OPEN_FIELDS = ['userid',ucsvlog_last_login] # во второй мидлвари
UCSVLOG_RESPONSE_FIELDS = ['ctype','content','status','headers'] #при закрытии
UCSVLOG_REQUEST_REQ_REMOTE_ADDR_REAL_IP = 'HTTP_X_REAL_IP'
# каталог с исходниками, относительно него будет писаться инфа о вызове функций
UCSVLOG_RELATED_FOLDER = PRJ_ROOT

Большая часть этих настроек имеют значения по умолчанию, поэтому заведется и с такими вот:

MIDDLEWARE_CLASSES = (
'djucsvlog.middleware.LogRequestInfo', ##первый
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.transaction.TransactionMiddleware',
'djucsvlog.middleware.LogViewInfo', ## Второй
)
UCSVLOG_FILE = '/var/log/django/console-%(year)s-%(month)s-%(day)s.ucsv'

django-ucsvlog-analytics

Проект лежит на bitbucket.org

Но все самое вкусное для этих логов, благодаря их хорошей структуризации – должно лежать в аналитике.
Аналитике представленна набором базовых коммнад, которые расширяются исходя из нужд конкретной задачи.
Приятной особенностью в написании логов является то, что на вход функций анализа приходят не массивы, а объекты класса Row , у которого есть множество свойтсв, заполеныне исходя из настроек django-ucsvlog. Т.к. к примеру, когда приходит row из первого индекса реквеста то у него уже есть к примеру аттрибуты row.data_path или row.data_ip
Но этот бонус также накладывает и свои ограничения, о которых я расскажу позже.

BaseSimpleAnalyticCommand – простой анализатор

Это самый простой метод анализа. Подходит в случае если вы своим логам хотите задать все один и довольно конктерный вопрос. “Дай мне количество хитов за период?” или “Дай мне топ стран”. В этом случае команде кормится набор логфайлов, а в вашу функцию collect_row передаются объекты строк, где вы можете проводить анализ и выдавать пользователю. Тут в принципе ничего сверхествественного не происходит.

Вот пример команды, которая собирает из Ваших логов топ accepted languages

from djucsvlog_analytics.analytic_commands import BaseSimpleAnalyticCommand
class Command(BaseSimpleAnalyticCommand):
data = {}
# переопределяя эту функцию – вы указываете,
# какие записи вы ходите видеть в анализе
# в нашем случае мы хотим видеть только
# первые записи блока реквеста,
# потому что только в них есть инфа о
# браузере пользователя
def filter_row(self,row):
return row.is_a_req
# собственно функция анализа тех записей, которые
# прошли через фильтер
def collect_row(self,row):
al = row.data_http_accept_language.\
split(';')[0].split(',')[0].split('-')[0]
if al in self.data:
self.data[al]+=1
else:
self.data[al] = 1
# и вывод результатов
def output_results(self):
for item in sorted(self.data.items(),\
key=lambda a:a[1]):
print item[0], item[1]

Если это сохранить как команду djucsvlog_test_simple_analytics то запуск будет выглядить следующим образом:

$ python manage.py djucsvlog_test_simple_analytics /var/log/django/stats-2012-3-21-v3.ucsv –settings=settings.analytics

djucsvlog_user_path_convertor

Это уже команда на основе базового класса BaseAnalyticCommand ( наследник от BaseSimpleAnalyticCommand ).

Очень полезна, когда для одних логов вы хотите провести более детальный анализ. Когда Вам нужен не просто маленький отчет, а когда Вам надо разобраться дельано со сложившейся проблемой с трафиком. Это очень похоже на то, когда трафик есть а продаже нет. Почему?

Идея проста convertor собирает из логов sqlite3 БД и кладет в один файл, при этом может дополнить его информацией о браузере, оси и стране пользователя. Таблици внутри него не просто набор строк, а связные таблицы. Хосты имеют много пользователей, пользователи имеют много реквестов, а реквес имеет много лог записей. Сам этот файл уже по сути часть анализа можно просто зайти в нее и на уровне SQL получать необходимые выборки и сводить статистику.

djucsvlog_user_path_convertor – это именно наша идея конвертации в такую вот струкруту БД. Если вы заходите сделать свой конвертато в БД, то просто пишите команду, наследник от BaseAnalyticCommand.

Ниже несколько примеров запуска такой команды в наших проектах

$ python manage.py djucsvlog_user_path_convertor /var/log/django/* \
–out=/tmp/django.userpath.db

Это мы просто конвертим все файлы из папки /var/log/django/ в базу

$ python manage.py djucsvlog_user_path_convertor /var/log/django/* \
–out=/tmp/django.userpath.db –force-new

Указываем, что если БД уже есть, то в нее не дописывать а создавать заново

$ python manage.py djucsvlog_user_path_convertor /var/log/django/* \
–out=/tmp/django.userpath.db –force-new\
–geoip-db=/var/geodb/2012-04-01.db

Передаем ссылку на базу GEO IP для добавления дополнительного поля со страной

djucsvlog_user_path_analytics

Но мы очень быстро поняли, что очень много задач не решаются просто SQL командой, поэтому мы к sqlite3 базе начали дописывать скриптики для ее анализа, и все это свернули в отдельную команды, на вход которой передается один или несколько sqlite файлов и параметры для анализа. Причем параметры разделаются на задачи и на условия. Т.е. мы при вызове команды можем передать ей на вход несколько задач например топ браузеров или топ стран, и условия например пользователи, которые зашли на определенную страницу, пользователи, которые сделали больше определенного количества шагов. Или как связка – дай мне следующий шаг после переданного.

Сама команда является наследником от BaseAnalyticReadCommand, а задачи являются наследниками от BaseAnalyticElement, список условий передаются при создании элемента задачи

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

$ python manage.py djucsvlog_user_path_analytics \
/tmp/django.userpath.db –get-entry-points

Получаем ТОП точек входа на сайт

$ python manage.py djucsvlog_user_path_analytics \
/tmp/django.userpath.db /tmp/django_2.userpath.db \
–get-entry-points

Для анализа можно указывать не один файл

$ python manage.py djucsvlog_user_path_analytics \
/tmp/django.userpath.db /tmp/django_2.userpath.db \
–get-entry-points –after-path=/

Какой был следующий шаг после /

$ python manage.py djucsvlog_user_path_analytics \
/tmp/django.userpath.db
–top-404

Невероятно полезная команда после переверстки

$ python manage.py djucsvlog_user_path_analytics \
/tmp/django.userpath.db
–get-country-ip

Дай топ стран

$ python manage.py djucsvlog_user_path_analytics \
/tmp/django.userpath.db
–get-country-ip –get-os

топ стран и топ осей

$ python manage.py djucsvlog_user_path_analytics \
/tmp/django.userpath.db
–get-country-ip –get-os –after-steps=3

топ стран и топ осей пользователей которые сделали на сайте больше 3х шагов

Тут мне даже сложно будет перечеслить все возможности которые есть у этой команды, а сколько всего Вы еще можете дописать!!!

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

BaseStreamCommand – отложеная статистика

Раньше, для сбора онлайн статистики о ваших пользователях – Вам надо было в момент захода этого пользователя раскидывать записи по таблицам и возможно совершать какие-то дополнительные расчеты. Причем это надо было делать максимально быстро, чтоб пользователь не видел никаких задержек. С четко структурированными логами, такими как ucsvlog, нет необходимости делать это в момент захода пользователя. Достаточно просто дочитывать периодически логи, которые пишутся, и уже в момент чтений, уже раскидывать статистику. При этом ваши расчеты уже никого не задерживают. Я назвал это “отложенная статистика”, т.к. мы откладывает всю работу по ее расчет в отдельную команду.

Вы пишите команду на вход которой подаются новые записи из каталога с логами. Причем подаются эти записи именно в хронологии возникновения их в логах. Т.е. если ваш сервис пишет 10 различных лог файлов одновременно и команда в момент запуска определила, что все они выросли с момента последнего запуска, то она будет выдавать к вам на вход записи с разных файлов в разброс в зависимости от того, где записи появляются раньше. Чтоб аналитика в этом случае была максимально четкой.

Особенности работы такой команды является индексный файл ( sqlite3 ), в котором она держит данные которые используются между ее вызовами, например такие как – последние размеры лог файлов

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

Наследника BaseStreamBlockCommand, передает анализу не одну строку,а уже собранный блок.

BaseConvertBlockCommand – конвертация логов.

Последней плюшкой анализатора, которая нами в данным момент обкатывается еще – это конвертатор.

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

Но я не хочу удалять все логи, я хочу удалять из логов только ненужное. Мне через месяц будет неважен call_info т.е. место, где были вызваны эти логи. Мне будет все также все равно на заходы пользователя на всякие информационные страници, или к примеру стуки всяких мониторингов меня тоже будут не волновать. Но я хочу держать как можно дольше процесс совершения покупки и процессинга карты. Для этого и делается конвертатор, который перегоняет логи из толстых, в которых часть инфы актуальна только несколько дней, в тонкие, в которых остается инфа, актуальность которой максимально долгая.

Ваша команда наследник от BaseConvertBlockCommand легко может с этим справляться.

Вот пример команды, которая делает это у меня:

class Command(BaseConvertBlockCommand):
def filter_convert_row(self,row):
if not row.is_a_req:
return True
return not(row.data_path.startswith('/info') \
or row.data_path.startswith('/test-exception') \
or row.data_path.startswith('/check-back') \
or row.data_path.startswith('/calculate-statistics') \
or row.data_path.startswith('/captcha') \
or row.data_path.startswith('/media') \
or row.data_path.startswith('/favicon'))

Тут указывается фильтр – какие строки надо оставить. Какие столбци надо оставить указывается в сетингсах. Детали смотрите в сетингсах, там под это выделен подраздел.

Самое приятное в стриминге и конверторе – это то, что абсолютно не важно – сколько сервисов ведут свой лог. У Вас может быть ucsvlog на твистеде, отдельный на Django, еще отдельные логи ведут кроновские команды. А вот стриминг с конвертором берут и объединяют их в один поток, в один файл, где вы в хронологии сможете посмотреть события каждого из них. ( Да и не только питон, сам формат логов очень простой )

Версионность логов.

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

Например, когда я только подключил ucsvlog к системе имена всех файлов логов оканчиваются на v1.ucsv. Потом я добавил дополнительные поля в строку открытия реквеста, и изменил формат файлов на v2.ucsv, но также создал файл analytics/v1.py в которую положил настройки для первой версии логов. Теперь когда я буду парсить логи из первой версии я буду использовать этот сетингс.

$ python manage.py djucsvlog_user_path_convertor \
/var/logs/django/*-v1.ucsv \
–settings=analytics.v1

Тоже самое с каждой следующей версией

Заключение

Как видите логи могут стать мощным средством для аналитики процессов системы и ее пользователей. Они могут даже стать часть коммуникации между вашими сервисами. С помощью них вы можете выделять самые главное и хранить это веками. И еще много чего они могут делать, чего я и сам еще не знаю

Вобщем подключайтесь, Вам понравится, я уверен

UCSVLOG kyivpy#6 – Как облегчают жизнь качественные логи. Часть 2. Решение

Oduvan — Mon, 02 Apr 2012 16:48:37 +0000

Продолжаем о UCSVLOG. Начало читайте тут – Часть 1. Проблема и Идея

Давайте, для начала, сформируем еще раз требования к логам.

* Легко писать / читать. – никто не хочет тратить ресурсы на такую пустяковую операцию, как логи. Они должны быть читабельны глазами без тулсов. И они должны быть простыми – чем проще механизм, тем он надежнее. Соответственно парсинг таких логов не должен быть сильно тяжелым.

* Shit Happens – отказоустойчивость. Я не хочу сломать структуру логов в момент сбоя. Если в момент записи случится какой-нибудь сбой, то может не дописаться часть записи, и я хочу, чтоб структура такого лога осталась неизменной.

* Индексы – о них и о их преимуществах мы уже успели рассказать ( Мне не надо про Свету каждый раз рассказывать, достаточно познакомиться один раз )

python-ucsvlog

Формат

Общий формат логов выглядит так:

Каждая запись должна начинаться с новой строки ( \n ) …

… а каждая ячейчка должна начинаться с кавычки ( “ ).

Ячейки должны быть разделены запятыми ( , ) …

… а кавычка внутри ячейки экранируется двумя кавычками ( “” )

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

Парсить такие логи очень просто, они парсятся потоково, можно начинать их парсинг с любой точки файла и без использования регекспов. На CheckIO, кстати, лежит задачка на эту тему, попробуйте решить, может у Вас получится лучше чем у меня

Формат данных

Теперь я расскажу – какие поля и в каком порядке кладутся запись лога

Index – это индек, который дает нам древовидность и недублируемость данных. Он представляет собой запись времени и рандомный дополнительный параметр. Под индекс выделены первые 2 ячейки. Первая ячейка это твой индекс, вторая – индекс твоего родителя.

call_info – Опциональна. Информация о месте вызова функции логирования, например имя файла, срока, имя функции, класс, модуль. Список этих данных кастомизируется в момент создания объекта логера.

log_info – сюда мы кладем классический элемент важности логов dev, err, imp, log. Например при создании логера на продакшене мы можем указать, что не хотим записывать dev-логи.

log_data – передается уже в момент вызова. Причем вызывать функцию записи логов можно не только со строковым аргументом но и с массивом, чтоб в одну запись уместить несколько значений. Это очень удобно для того, чтоб в последствии организовать поиск по ним, либо использовать эти данные для анализа.

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

CODE

Теперь давайте посмотрим, как это выглядит в коде.

glog.a_log(‘REQ’,’log_data1’)
glog(‘Hi all’)
glog.log([‘Payment’,’CardNumber’,'4111 *** **** ****’])
glog.a_log(‘IN’,[‘UserID’,98])
glog.imp([‘UserBalance’,1500])
glog.c_log(‘REQ’)

1 a_log – мы открываем индекс. При открытии можно указывать имя, что-то типа метки, которую можно будет использовать как ссылку в коде. Вообще это не обязательно. Можно им пользоваться как структурированным линейным логом, без открытия индекса. Но я считаю древовидность – большим бонусом, которым надо пользоваться.

"I1,","a_log,"REQ,"log_data1

2 log – записываем строковые данные. Т.е. запись одной ячейки. Т.к. у нас есть открытый индекс, то все остальные записи идут как его чаилды. А если мы логер используем как функцию, то он автоматом пишет логи с приоритетом log

"I1,","a_log,"REQ,"log_data1
"I2,"I1,"log,"Hi all

3 log – запись еще 3х ячеек. Теперь мы явно указали, что приоритетность у нас log, и аргументом передали массив ячеек, которые надо записать

"I1,","a_log,"REQ,"log_data1
"I2,"I1,"log,"Hi all
"I3,"I1,"log,"Payment,"CardNumber,"4111 *** **** ****

4 a_log – открытие еще одного индекса. Все верно, уровень вложенности может быть бесконечный. И при открытии мы также можем указать не только строку, но и массив ячеек

"I1,","a_log,"REQ,"log_data1
"I2,"I1,"log,"Hi all
"I3,"I1,"log,"Payment,"CardNumber,"4111 *** **** ****
"I4,"I1,"a_log,"IN,"UserID,"98

&emps; 5 imp – запись еще 2х ячеек теперь уже в четвертый индекс, тот, который мы открыли последним. И приоритетность у него img

"I1,","a_log,"REQ,"log_data1
"I2,"I1,"log,"Hi all
"I3,"I1,"log,"Payment,"CardNumber,"4111 *** **** ****
"I4,"I1,"a_log,"IN,"UserID,"98
"I5,"I4,"imp,"UserBalance,"1500

&emps; 6 c_log – закрытия индекса. Тут закроются сразу 2 открытых индекса и REQ и IN, потому что мы при закрытии сказали метку открытия индекса. Индекс можно закрывать с записью в лог а можно и без. В закрытие лога как правило кладут результат выполнения этого блока. После закрытия всех индексов ведение записей будет идти без указания родителя, точно так-же как это происходило с первой строкой. А в записи закрытия родителем будет указана тот, кого закрывают, в нашем случае – первый

"I1,","a_log,"REQ,"log_data1
"I2,"I1,"log,"Hi all
"I3,"I1,"log,"Payment,"CardNumber,"4111 *** **** ****
"I4,"I1,"a_log,"IN,"UserID,"98
"I5,"I4,"imp,"UserBalance,"1500
"I6,"I1,"c_log,"REQ

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

glog = Logger(‘/var/log/%(year)s-%(month)s-%(day)s.ucsv’)

На этом все про ucsvlog как формат, дальше я просто пройдусь по плюшкам, которые мы используем постоянно при работе с ними. Единственное хочу отметить,последнюю идею по этим логам. Как вы помните вначале я рассказал про то, что и строки и записи только открываются, но не закрываются, но это накладывает определенную ответственность на ячейку которая идет вконце записи. Например обратите внимание на 5ую строку.

Если случится проблема с записью на последней ячейке, которая не допишет пару последних нулей – то это будет большая проблема, т.к. тогда мы будем полностью уверены в том, что у пользователя баланс в 100 раз меньше, поэтому мы ввели дополнительный параметр close_row в котором можно передать значение последней ячейки в каждой записи. И теперь вы можете принимать запись как валидную только в том случае, если ее последним значением является закрывающий символ. Т.е. в нашем случае мы просто скажем что 5ая запись невалидна.

Репозитарий python-ucsvlog на bitbucket

и на pypi.python.org Т.е. себе можно поставить pip install python-ucsvlog

А теперь… плюшки… плюшки….. плюшки…

UCSVLOG kyivpy#6 – Как облегчают жизнь качественные логи. Часть 1. Проблема и Идея

Oduvan — Mon, 02 Apr 2012 12:21:13 +0000

Первое, о чем сразу хочется сказать – это то, что никогда не делайте презентаху в последний день, если Вы при этом предыдущую ночь сдавали проект. Можно потом утром в МакДаке возле Киевского вокзала сидеть и исправлять в фотошопе презинтаху

История

В моей жизни уже было 2 проекта, в которых логи и их анализ занимали одну из ключевых ролей.

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

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

Проблемы линейных логов

Под линейными логами я понимаю классические логи, например syslog. Т.е. когда независимой информационной единицей является строка – есть сохраненный факт и время, которое и связывает его с другими такими-же фактами.

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

Формат ведения этих логов будет простой:

После того, как Света выйдет из дома, станет на остановке и сядет в автобус, а Вова выйдет из дома – мы будем иметь следующую картину

Первая проблема. Это избыточность. Мы со Светой познакомились еще в 7 утра, зачем нам рассказывать про нее каждый раз одно и тоже?

Вторая вытекает из первой. Сложность ведения таких логов. Да, именно так, не смотря на кажущуюся простоту. Я говорю о том, что в момент записи логов у Вас в окружении должны быть все данные необходимые для формирования строки, а возвращаясь к нашему примеру – Света и Вова должны у себя на видном месте прицепить свидетельство о рождении, паспорт папы с разворотом прописки и дневник, чтоб на каждом пропускном пункте видели – кто прошел и что надо записать. (Можно ксерокопии, заверенную нотариусом. )

Третья. И вобщем-то основная – это сложность анализа. Потому что, когда мы будем сводить статистику, к примеру по возрасту детей – из-за мальчика, родившегося на улице с двумя словами в ее названии мы получим 77ти летнего мальчика и его отца со звонким именем 13.

Идея

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

Т.е. ввести какой-то индекс, по которому можно найти обратную инфу, а не дублировать ее, т.е. свете и Вове можено предаствить всю эту информацию на входе, а не таскать все это на себе.

Из явных проблем можно выделить то, что логи сморят в момент возникновения проблемы, и именно проблема является отправной точкой Вашего анализа, дальше по логам как правило надо идти вверх. Т.е. если Света опоздает на автобус, то мы быстро найдет ее домашний адрес, но если она опоздает в школу, то поиск адреса может занять чуть больше времени, чем для простых линейных логов, где все инфа сразу хранится в одной линии. Поэтому группировать данные лучше на коротких дистанциях, для сохранения читабельности в момент возникновения проблемы. ( Хотя надо сказать, что и в линейных логах в момент возникновения ексепшена – надо брать и подниматься вверх по логам, чтобы собрать больше информации о возникшей проблеме )

Ну и конечно-же то, что 77летний Вова никуда не делся, а значит проблема со структурой также еще актуальна.

Во второй части статьи расскажу, как python-ucsvlog решает эту проблему