Аннотация
- Докладчик
- Евгений Кирпичёв
Вероятно, каждому программисту или системному администратору приходилось анализировать качественные и количественные характеристики поведения своих систем по логам.
При отсутствии подходящего инструментария это часто превращается в довольно муторное и грязное занятие. Выстраиваются конвейеры из кучки утилит обработки текста и временных файлов, ищутся и забрасываются туториалы по gnuplot, R, hadoop, узкоспециализированным или тяжеловесным системам - и в итоге горе-исследователь просто машет рукой.
Мне надоела эта ситуация, и я написал для себя два простых инструмента, которые, к моему собственному удивлению, оказались чрезвычайно универсальны.
Цели:
- любая задача визуализации решается однострочником, который можно без раздумий набить прямо в командной строк,
- не делается почти никаких предположений о формате лога.
Вот несколько примеров задач, каждая из которых решается однострочником:
- посмотреть общую картину, чем когда какой узел кластера или нить занимались,
- посмотреть график того, сколько запросов приходит/уходит из системы в секунду,
- посмотреть график длительности обработки запросов (или их квантилей, вероятностей попадания в интервалы и т.п.),
- посмотреть, как меняется частота появления различных типов запросов к разным машинам или датацентрам во времени,
- посмотреть, какую долю времени обработки занимает обращение к базе; сравнить с графиком числа запросов к базе в секунду,
- посмотреть зависимость размера нескольких очередей в системе от времени (и понять, например, между какими очередями затык),
- сравнить распределение длительностей запросов к memcached с двух разных стоек.
Видео
Видео в HD-качестве, смотрите в полноэкранном режиме.
HTML-код включения <iframe src="http://player.vimeo.com/video/26100144?byline=0&portrait=0" width="720" height="405" frameborder="0"></iframe>
- Скачать
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 и эксперт по функциональному программированию.
