Комментарии 25
вовремя — у нас админ как раз, матерясь собирает пинбу =)
Хотелось бы поподробнее услышать, насколько ВТР добавляет нагрузки серваку
Хотелось бы поподробнее услышать, насколько ВТР добавляет нагрузки серваку
со стороны фронтенд-сервера, на котором крутятся скрипты, дополнительная нагрузка не ощущается вообще. отправляются только udp-пакеты
на стороне сервера, на котором крутится сам демон, нагрузка будет в разы меньше, чем пинба+rrdtools, но больше, чем если там крутится просто пинба. главным образом разница будет по дисковой активности — сама пинба данные не сохраняет, а rrdtools делают это неэффективно для данной задачи
на стороне сервера, на котором крутится сам демон, нагрузка будет в разы меньше, чем пинба+rrdtools, но больше, чем если там крутится просто пинба. главным образом разница будет по дисковой активности — сама пинба данные не сохраняет, а rrdtools делают это неэффективно для данной задачи
А что они у вас матерятся? Установка ведь очень проста, да и под популярные системы уже есть пакеты.
Попробую использовать в новом проекте. Есть пара вопросов:
1. Где увидеть полное api к демону?
2. При методе «put» можно ли указывать свое время? Тормозить процесс добавлением статистики не хочется, есть идея организовать очередь, которая и будет скидывать туда готовые данные, но встает проблема со временем самого события.
1. Где увидеть полное api к демону?
2. При методе «put» можно ли указывать свое время? Тормозить процесс добавлением статистики не хочется, есть идея организовать очередь, которая и будет скидывать туда готовые данные, но встает проблема со временем самого события.
в гитхабе: github.com/mambaru/btp-daemon/blob/master/README.md#%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA-%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%B9
Своё время указывать нельзя. Это связано с тем, что для подсчёта статистики необходимо знать время каждого конкретного запроса, иначе не подсчитать перцентили. Соответственно, подсчёт выполняется 1 раз (для каждого отсчёта/разрешения), и добавить туда что-то задним числом никак нельзя.
Но вы неправильно подходите к вопросу: в btp вы отправляете udp-пакеты, т.е. «записал — забыл». Это неблокирующая операция, и она очень быстрая. Очередь, организована ли она у вас на gearman/rabbitmq/чем-то ещё, будет работать в разы медленнее (потому что tcp и потому что — в зависимости от решения — может быть ещё и софтовое подтверждение доставки), если считать с её помощью статистику.
Своё время указывать нельзя. Это связано с тем, что для подсчёта статистики необходимо знать время каждого конкретного запроса, иначе не подсчитать перцентили. Соответственно, подсчёт выполняется 1 раз (для каждого отсчёта/разрешения), и добавить туда что-то задним числом никак нельзя.
Но вы неправильно подходите к вопросу: в btp вы отправляете udp-пакеты, т.е. «записал — забыл». Это неблокирующая операция, и она очень быстрая. Очередь, организована ли она у вас на gearman/rabbitmq/чем-то ещё, будет работать в разы медленнее (потому что tcp и потому что — в зависимости от решения — может быть ещё и софтовое подтверждение доставки), если считать с её помощью статистику.
Спасибо, нужно было сначала подробней изучить прежде чем задавать вопрос:)
ы отправляете udp-пакеты, т.е. «записал — забыл». Это неблокирующая операция, и она очень быстрая. Очередь, организована ли она у вас на gearman/rabbitmq/чем-то ещё, будет работать в разы медленнееЕсли исп rabbitmq то это будет медленнее за счет избыточности протокола AMQP
и реализации rabbitMq на блокируемых соединениях
мамба всегда рабовала своими решениями
спасибо за ценную информацию
спасибо за ценную информацию
сбор статистики всегда предполагает какой-то оверхед собственно на сам
в пинба это решено путем отправления пакета в демон сбора статистики уже по окончанию отработки скрипта в RSHUTDOWN
а какая схема используется у Вас и каковы накладки?
в пинба это решено путем отправления пакета в демон сбора статистики уже по окончанию отработки скрипта в RSHUTDOWN
а какая схема используется у Вас и каковы накладки?
отправка по ходу. каждые ~30 счётчиков, или раз в секунду, или в конце скрипта (это сделано для того, чтобы можно было правильно считать статистику в т.ч. долгоживущих крон-скриптов и обработчиков очередей)
разницы по скорости мы вообще никакой не ощутили. по ручным замерам/пинбе тоже разницы между «до btp» и «после btp» не видно. измерить же накладные расходы непосредственно — довольно сложно в нашем случае.
разницы по скорости мы вообще никакой не ощутили. по ручным замерам/пинбе тоже разницы между «до btp» и «после btp» не видно. измерить же накладные расходы непосредственно — довольно сложно в нашем случае.
курю исходники
все так сложно:
а зачем использовать динамические списки типов,
можно же JSON-RPC реализовать гораздо проще, используя фабрику.
есть готовые парсеры json.
а зачем использовать динамические списки типов,
можно же JSON-RPC реализовать гораздо проще, используя фабрику.
есть готовые парсеры json.
они не динамические, а статические. на мой взгляд, довольно просто всё. у нашего подхода среди преимуществ декларативность описания (т.е. можно брать хедер и копировать в документацию), скорость работы и разумная скорость разработки.
аналогичный подход используется в демоне поиска, про который мы уже писали, только там один список типов со всеми полями анкеты, а дальше на основании тэгов выбираются поля, которые нужно бэкапить, бэкапятся, поля, из которых нужно строить битмап, строятся. поэтому списки типов и такой подход для нас более-менее стандартный.
аналогичный подход используется в демоне поиска, про который мы уже писали, только там один список типов со всеми полями анкеты, а дальше на основании тэгов выбираются поля, которые нужно бэкапить, бэкапятся, поля, из которых нужно строить битмап, строятся. поэтому списки типов и такой подход для нас более-менее стандартный.
еще несколько более технических вопросов:
1) почему выбрали именно Kyoto? рассматриваемые альтернативы?
2) какие структуры используете для хранения, в Kyoto имеется несколько видов хранения, какой из них используется?
3)что берется за основу индекса?
4) производи ли ли исследования на наполнение БД статистики.
конкретно меня интересует: статистика копится-копится… система начинает притормаживать…
есть ли метрики, оптимальный размер хранилища?
5) используется ли хранилище Kyoto как промежуточное (на небольшой период день/неделя/месяц), или в нем хранится вся статистика со дня сбора.
5) если вчерашняя статистика становится не актуальной и мы ее чистим, то в этом случае интересует алгоритм/механизм чистки устаревших данных,
6) если при этом используются tree индексы, то необходимо осуществлять балансировку дерева,
как это влияет на производительность…
7) отдачу статистики производит тот же демон?
я так понимаю, тот же…
1) почему выбрали именно Kyoto? рассматриваемые альтернативы?
2) какие структуры используете для хранения, в Kyoto имеется несколько видов хранения, какой из них используется?
3)что берется за основу индекса?
4) производи ли ли исследования на наполнение БД статистики.
конкретно меня интересует: статистика копится-копится… система начинает притормаживать…
есть ли метрики, оптимальный размер хранилища?
5) используется ли хранилище Kyoto как промежуточное (на небольшой период день/неделя/месяц), или в нем хранится вся статистика со дня сбора.
5) если вчерашняя статистика становится не актуальной и мы ее чистим, то в этом случае интересует алгоритм/механизм чистки устаревших данных,
6) если при этом используются tree индексы, то необходимо осуществлять балансировку дерева,
как это влияет на производительность…
7) отдачу статистики производит тот же демон?
я так понимаю, тот же…
1) используем kyoto в продакшне, довольно успешно. плюс было желание использовать какой-то встраиваемый (не внешний) вариант
альтернативы — leveldb (но на тот момент мы с ним ещё никак не работали), теоретически может быть berkley, может быть велосипед
2, 3) kchash — каждому счётчику соответствует 2 записи, одна для данных и одна для метаданных. ключем является тройка (service,server,op) или (script,service,op)
4) если вы имеете в виду «копится» по времени но одним и тем же счётчикам — то статистика притормаживать не будет, т.к. структуры данных, нужные для хранения всего-всего изначально инициализируются с первыми данными
если будет очень много счётчиков, то это повышает нагрузку на диск. неиспользуемые счётчики (которые лежат «мертвым грузом») нагрузку повышают мало.
5) в киото хранится вся статистика
6) tree индексы не используются. но вообще у киото это происходит более-ли-менее в фоне. на время выполнения realtime-запросов это конечно всё равно влияет, но сохранение статистики всегда может немного подождать
7) ага
альтернативы — leveldb (но на тот момент мы с ним ещё никак не работали), теоретически может быть berkley, может быть велосипед
2, 3) kchash — каждому счётчику соответствует 2 записи, одна для данных и одна для метаданных. ключем является тройка (service,server,op) или (script,service,op)
4) если вы имеете в виду «копится» по времени но одним и тем же счётчикам — то статистика притормаживать не будет, т.к. структуры данных, нужные для хранения всего-всего изначально инициализируются с первыми данными
если будет очень много счётчиков, то это повышает нагрузку на диск. неиспользуемые счётчики (которые лежат «мертвым грузом») нагрузку повышают мало.
5) в киото хранится вся статистика
6) tree индексы не используются. но вообще у киото это происходит более-ли-менее в фоне. на время выполнения realtime-запросов это конечно всё равно влияет, но сохранение статистики всегда может немного подождать
7) ага
добавлю к п.2: каждая запись с данными — это блоб с 3к*6 значениями (что может показаться не оптимальным, обновлять туда ещё 6 значений для нового интервала, но на самом деле будет последовательная запись и размер записи не очень важен). киото используется только для хранения.
агрегация естественно работает в памяти.
к киото в целом есть претензии, примерно такие: github.com/mambaru/btp-daemon/blob/master/src/buffered_kc.hpp
агрегация естественно работает в памяти.
к киото в целом есть претензии, примерно такие: github.com/mambaru/btp-daemon/blob/master/src/buffered_kc.hpp
пo вопросам визуализации рекомендую к ознакомлению
d3js.org/
и
developers.google.com/chart/
по поводу хранения и выдачи данных couchdb.apache.org/
d3js.org/
и
developers.google.com/chart/
по поводу хранения и выдачи данных couchdb.apache.org/
графические библиотеки, которые вы указали, работают на SVG. это не подходит, потому что svg уже с несколькими тысячами точек работает очень медленно.
зачем нам вместо компактного бинарного in-process хранилища использовать какое-то стороннее с json, я тоже не понял. да, мы в курсе о существовании couchdb, mongo, postgresql и многих других технологий.
зачем нам вместо компактного бинарного in-process хранилища использовать какое-то стороннее с json, я тоже не понял. да, мы в курсе о существовании couchdb, mongo, postgresql и многих других технологий.
но в любом случае спасибо за помощь
с этой точки зрения я проблему не рассматривал, возникают вопросы:
зачем в график выводить больше 1к точек?
Я сейчас занимаюсь визуализацией аналитической информации. Конечная цель Ad-Hoc аналитическая платформа, где конечный пользователь может выбирать масштаб и различные сочетания срезов (dimention)
Систему сбора данных мы построили из нескольких компонент: raw data -> S3 через flume в виде JSON flat files
некоторые метрики при помощи sqoop прямо в hdfs. Все основные преобразования реализованы в hive на Amazon EMR
В качестве warhouse mysql c myisam. Сейчас первые отчеты мы выкладываем в Google Docs, теперь вот думаем над визуализацией.
зачем в график выводить больше 1к точек?
Я сейчас занимаюсь визуализацией аналитической информации. Конечная цель Ad-Hoc аналитическая платформа, где конечный пользователь может выбирать масштаб и различные сочетания срезов (dimention)
Систему сбора данных мы построили из нескольких компонент: raw data -> S3 через flume в виде JSON flat files
некоторые метрики при помощи sqoop прямо в hdfs. Все основные преобразования реализованы в hive на Amazon EMR
В качестве warhouse mysql c myisam. Сейчас первые отчеты мы выкладываем в Google Docs, теперь вот думаем над визуализацией.
в графике 1.5к точек, можно зумировать. но графиков на странице может быть много.
у вас довольно интересный подход, хотя и противоположный нашему. но вы вероятно это предоставляете клиентам. saas небось?
у вас отчёты сейчас только, или realtime данные тоже есть?
много ли самих данных/счётчиков/возможных различных срезов?
raw data -> S3 через flume — сильно много данных получается?
нашей визуализацией я если честно не очень доволен. самый красивый/удобный результат был бы с хайчартсом, если бы не было тормозов. если сможете общее число всех точек на странице уложить в 1к..1.5к где-то, то будет нормально.
у вас довольно интересный подход, хотя и противоположный нашему. но вы вероятно это предоставляете клиентам. saas небось?
у вас отчёты сейчас только, или realtime данные тоже есть?
много ли самих данных/счётчиков/возможных различных срезов?
raw data -> S3 через flume — сильно много данных получается?
нашей визуализацией я если честно не очень доволен. самый красивый/удобный результат был бы с хайчартсом, если бы не было тормозов. если сможете общее число всех точек на странице уложить в 1к..1.5к где-то, то будет нормально.
Добавлю к списку:
для явистов есть — metrics.codahale.com/
для рубистов есть — github.com/savonarola/pulse-meter, github.com/paulasmuth/fnordmetric(хотя он то-еще говно =)), оба зависят от редиса
есть опять же code.google.com/p/valz/ и прочие тулзы от Евгения Кирпичева — bit.ly/Lj1JLc
для явистов есть — metrics.codahale.com/
для рубистов есть — github.com/savonarola/pulse-meter, github.com/paulasmuth/fnordmetric(хотя он то-еще говно =)), оба зависят от редиса
есть опять же code.google.com/p/valz/ и прочие тулзы от Евгения Кирпичева — bit.ly/Lj1JLc
Раз стали собирать коллекцию, добавлю тоже пару продуктов калибра New Relic:
— www.appdynamics.com/ (Java, .NET) — платная и бесплатная версии. Тоже глубокий инсайт внутрь приложения и очень развитый root cause analysis.
— www.splunk.com/product — тоже бесплатный ограниченный вариант есть. Это был изначально агрегатор и визуализатор логов, но превратился в довольно большую мониторинговую штуку.
Оба продукта видел в бою на консалтинговых проектах, очень удобные штуки.
— www.appdynamics.com/ (Java, .NET) — платная и бесплатная версии. Тоже глубокий инсайт внутрь приложения и очень развитый root cause analysis.
— www.splunk.com/product — тоже бесплатный ограниченный вариант есть. Это был изначально агрегатор и визуализатор логов, но превратился в довольно большую мониторинговую штуку.
Оба продукта видел в бою на консалтинговых проектах, очень удобные штуки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В чем причина засора? Cтатистика веб-приложений