Комментарии 14
О, не знал про такой интерфейс. Очень круто выглядит.
Спасибо, добавил ссылку на pinba.org.
Спасибо, добавил ссылку на pinba.org.
Как удачно то! Я только подумал, что для нашего проекта не помешала бы какая-нибудь статистика. Буду пробовать! Спасибо за статью! :)
Только у меня вопрос один есть: а статистику по всем проектам, крутящимся на одном сервере, можно вывести всю сразу?? Или надо отдельный порт для каждого?
Только у меня вопрос один есть: а статистику по всем проектам, крутящимся на одном сервере, можно вывести всю сразу?? Или надо отдельный порт для каждого?
А что насчет ключевой функции пинбы?
Думаю это вопрос к разработчикам pinboard. Судя по скринам такой функции нет.
Судя по всему, muxx как раз один из разработчиков.
Вопрос к нему.
Вопрос к нему.
Да, сейчас действительно нет такой функции. Мы в первую очередь хотели отразить общую картину: время формирования и потребление памяти 90/95/99/100% страниц, а также выявить проблемные участки: медленные страницы, страницы с 500-тыми статусами.
С этим графиком есть такая проблема: он не работает в проектах с единой точкой входа. Ок, мы пишем request_uri вместо script_name (см github.com/intaro/pinboard/wiki/Configure-sending-of-readable-script-names-in-Pinba), но тогда уникальных адресов становится достаточно много и график не отражает того, что должен был отображать. С другой стороны request_uri удобен, т.к. pinboard логирует медленные, тяжелые и ошибочные страницы и уведомляем о них, это удобно.
С этим графиком есть такая проблема: он не работает в проектах с единой точкой входа. Ок, мы пишем request_uri вместо script_name (см github.com/intaro/pinboard/wiki/Configure-sending-of-readable-script-names-in-Pinba), но тогда уникальных адресов становится достаточно много и график не отражает того, что должен был отображать. С другой стороны request_uri удобен, т.к. pinboard логирует медленные, тяжелые и ошибочные страницы и уведомляем о них, это удобно.
Думаю, я не намного навру, если напишу, что 90% django проектов работают под uwsgi. А он имеет встроенный сервер статистики, с которого элементарно снимаются данные для ваших графиков и визуализируются при помощи munin. При этом не используется база данных и не добавляется лишний код в обработку каждого реквеста.
Поздравляю, вы изобрели велосипед! ;)
Что можно сделать. Привязываться к urls.py и вытаскивать оттуда точки входа. Тогда можно будет получить более-менее похожую картину.
Поздравляю, вы изобрели велосипед! ;)
Что можно сделать. Привязываться к urls.py и вытаскивать оттуда точки входа. Тогда можно будет получить более-менее похожую картину.
Pinba и соответственно Pinboard был изначально для PHP :)
И среднее время как раз не очень показательно. Мы у себя смотрим на 95% и отталкиваемся от того, что в эту цифру должны укладываться запросы, в которых срабатывает кеширование, а в остальные 5% — запросы, которые лезут в БД.
И среднее время как раз не очень показательно. Мы у себя смотрим на 95% и отталкиваемся от того, что в эту цифру должны укладываться запросы, в которых срабатывает кеширование, а в остальные 5% — запросы, которые лезут в БД.
Ильяс, а я правильно понял, что вы перекладываете из сырых данных в свои таблицы и потом строите по этому графики?
А можно узнать зачем?
Предполагалось, что существующие виды отчетов как раз вот такие случаи все должны решать.
Если не решают, то либо вы что-то не так делаете, либо вам не хватает какого-то функционала. Вопрос — какого?
Кстати, недавно добавились еще медиана, произвольные перцентили по времени запроса + т.н. «гистограмма» частот (т.е. можно посмотреть «внутрь» среднего числа и построить графики распределения времени запроса, например).
А можно узнать зачем?
Предполагалось, что существующие виды отчетов как раз вот такие случаи все должны решать.
Если не решают, то либо вы что-то не так делаете, либо вам не хватает какого-то функционала. Вопрос — какого?
Кстати, недавно добавились еще медиана, произвольные перцентили по времени запроса + т.н. «гистограмма» частот (т.е. можно посмотреть «внутрь» среднего числа и построить графики распределения времени запроса, например).
uWSGI Stats Server — это статистика одного сервера, которую он сам отдаёт.
Pinba изначально предназначалась для автоматического сбора и агрегации данных с множества серверов.
Плюс в неё с самого начала закладывались таймеры, который позволяют засекать время определённых участков кода и строить агрегированные отчеты уже по операциям, а не по запросам.
>При этом не используется база данных и не добавляется лишний код в обработку каждого реквеста.
Если не использовать таймеры, то ничего не добавляется, вся статистика собирается и отсылается автоматом (в PHP. Хотя и в других языках тоже наверняка).
Pinba изначально предназначалась для автоматического сбора и агрегации данных с множества серверов.
Плюс в неё с самого начала закладывались таймеры, который позволяют засекать время определённых участков кода и строить агрегированные отчеты уже по операциям, а не по запросам.
>При этом не используется база данных и не добавляется лишний код в обработку каждого реквеста.
Если не использовать таймеры, то ничего не добавляется, вся статистика собирается и отсылается автоматом (в PHP. Хотя и в других языках тоже наверняка).
Есть не только uWSGI. Мотивы описаны в начале топика.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторинг статистики Django проектов с помощью Pinba на Debian GNU/Linux