Публикации с меткой «kyivpy»

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

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

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

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

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

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

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

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

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

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

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

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

python-ucsvlog

Формат

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CODE

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

 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

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

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

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

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

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

История

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

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

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

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

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

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

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

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

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

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

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

Идея

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

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

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

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

В следующей статье расскажу, как python-ucsvlog решает эту проблему

• «N ways of deploying your Python» — Валерий Замараев
• «N+1st way to deploy Python code» — Андрей Хаврюченко
• «Подробно о GIL» — Aндрей Светлов
• «Практическое применение zeromq в web-разработке» — Павел Коломиец

• Суббота, 25 июня, с 11:00 до 18:00
• г. Киев, ул. Амосова, 12. 2-я башня, 19-й этаж. (в 10.30 от м. Дворец Украина будет организован трансфер к офису).

• Андрей Светлов — взаимодействие формы с представлением и модели, олицетворяющей предметную область
• Андрей Хаврюченко — создание UI мокапов
• + open-space общение