Персональные инструменты
 

Швейцарский нож аналитика - визуализируем логи одной строкой! (Евгений Кирпичёв, ADD-2011)

Материал из CustisWiki

Перейти к: навигация, поиск

Аннотация

Докладчик
Евгений Кирпичёв

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

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

Мне надоела эта ситуация, и я написал для себя два простых инструмента, которые, к моему собственному удивлению, оказались чрезвычайно универсальны.

Цели:

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

Вот несколько примеров задач, каждая из которых решается однострочником:

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

Видео

Скачать
http://ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/1c5-tools-for-visualizing-logs-with-one-liners-kirpichyov.avs.avi


Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).


Примечания и отзывы

Рассказал и показал свою тулзу для визуализации логов. Жаль, не затронул тему того, как она писалась. Такие доклады хорошо потом в записи смотреть, наверное. Тулза хорошая. ©
Евгений Кирпичев рассказал о способе визуального анализа логов и показал офигенные картинки. Инфографика рулит. ©
После обеда заглянул на доклад Жени Кирпичева, где он рассказывал про хитрый инструмент собственной заточки для анализа и визуализации логов, который помогает анализировать профили загрузки на кластерах (основное его применение, как я понял). Доклад был ничего так, много любопытных графиков, из которых Евгений извлекал скрытую информацию и разъяснял остальным. Я рассчитывал поймать его после доклада, т.к. знаю что он адепт функционального программирования, редактор журнала fprog.ru, хаскеллист, знаток хайлоада и вообще незаурядная личность, но он, к сожалению, быстро раскланялся и удалился. Ну ладно, как-нибудь еще пересечемся. ©


Доклад был про анализ логов для диагностики поведения системы и собственный инструментарий для этого. Отчасти я это слышал на прошлом ADD в разговорах, потому пошел с середины доклада. Было много картинок и иллюстраций, что и как можно смотреть по логу в самых различных вариантах, как делать выводы. И какие графики для каких выводов подходят. Такая вот мозаика. Смысл же инструментария — в том, что можно смешивать самые различные логи, описывая формат, и рассматривать их композитно. И смотреть графики мониторинга в реальном времени, это важно. Среди интересных эффектов, которые дает такой инструмент — график duration, который строит инструмент, выделяя события начала и конца, причем эти события, в том числе, могут быть из разных тредов и разных машин. На то, чтобы работа шла в реальном времени, в том числе при большом объеме логов, и не мешала основным процессам, затрачено много усилий, однако в реальной жизни может потребоваться дополнительная настройка размеров буферов — которую можно детектировать по собственному логу инструмента, это тоже было показано. А вообще получился довольно универсальный инструмент, кто-то с его помощью показывал поведение детей-аутистов.

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

И в целом, я понимаю, что такое удобно сделанный под твою задачу инструмент, повышающий твою эффективность на порядки (хотя в зале указывали, что для визуализации жизни кластера давно есть крутое http://meta.rocksclusters.org/ganglia/ и возможно этот велосипед излишен). И что эффективный инструмент скорее всего будет не в парадигме «визивига», где надо тыкать кнопки, заполнять тыщи полей, и двигать мышью виджеты, а будет работать в парадигме «запрос—ответ» и «визуализации компактных требований», каковые удобно делать либо в командной строке, либо кратким предметным языком. Так вот, я просмотрел доклад в записи, которую же сам и смонтировал пользуясь изобретенным command-line видеоредактором, слушающим команды и спецификации для видеомонтажа.

Другое дело — все-таки очень ограничена предметная область, подлежащая визуализации этими тулами. Плоские графики с временной осью, серии или числовая ось... А преимущество «уанлайнера» несколько лукавое — «лайн» длиной в килобайт — это уже не лайн, line — это то, что можно набить за пару секунд, т.е. не больше пары десятков символов. А больше — это уже надо писать компактный dsl, который можно делать расширяемым, и таким же удобным и интерактивным — хороший, компактный DSL, без кучи «зюк и хрюк», скобок, кавычек двух типов, символов продолжения линий..., так вот, такой DSL, удобный и читаемый, ибо для читаемости можно и отступы использовать и переводы строк и пробелы — открыт в одном окне в редакторе, а в консоле происходит запуск тулы. Редактировать параметры и смотреть, как меняется картинка — гораздо быстрей и удобнее! И да — тут нет ограничений на отсутствия гуя — картинки то все равно надо смотреть!

В некотором смысле это проблема «уанлайн» подхода — сначала все кратко и красиво, а потом, с ростом задачи понимаешь, что к черту awk, лучше сразу perl, а то и python.

Забавно, что когда-то давно у нас и металогика алгоритмов учетных систем была «уанлайнером», с обвешанными семантикой символами «@!$», что знатно выносило мозг незнакомым с этой нотацией аналитикам, но потом это стало жать и самим разработчикам.

Т.е. если бы я начал решать эту задачу, это был бы python + matplotlib или pycairo (ну или другая библиотека визуализации), где все кишки бы я спрятал в отдельный модуль, а оставил лишь формулировку задачи компактной Python-функцией (что бы бы офигически и прозрачно расширяемо). Ну и если спектр графиков у меня получился бы совсем простым, я бы сделал простой DSL, то тоже редактируемый, с разбиением на строки, с максимальной читаемостью.

Я так и не придумал, чтобы мне можно было визуализировать этими тулами (полно всего просит визуализации, но там и графы и многомерность и динамика треба, на плоскость «время-серии» ничего не ложится), но вот что мне надо на самом деле — попрактиковаться в Haskell. И возможно для этого я и поковыряю исходники этих тулов, благо они опубликованы, да и писал их не какой-то ламер, а antilamer и эксперт по функциональному программированию.



Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».