Недавно на работе я сделал систему для мониторинга и анализа производительности. Примерно как известная многим пинба, но с человеческим лицом.
Получилось довольно приятная штука, которая мне самому нравится. Поэтому мы решили выложить её на гитхаб.
Пользуйтесь, если нужно. https://github.com/mambaru/btp-daemon
а что он умеет, по сравнению с тем же zabbix?
zabbix мониторит параметры серверов. а BTP мониторит счётчики производительности, которые отправляет само приложение. то есть «сколько времени занимает запрос к мемкэшу» или «сколько времени работает скрипт такой-то», или «какие скрипты дают основную нагрузку на такой-то сервис».
жаббикс мониторит все, что ему подсунешь. Но это так, к слову.
Прикольно.
если я этому вашему заббиксу буду с каждого аппсервера кластера слать на каждый запрос данные профайлера, он чуточку сдохнет. А если слать придется отличным от UDP способом, то сдохнет и кластер 🙂
А что у вас там на TT? Искалка по анкетам?
NetXMS, newrelic.
заббикс работает не так.
да и частота приема данных там настраивается.
а еще он умеет работать в разных инстансах, объединенных одной вебмордой.
заставьте меня уже замолчать в этом посте
ага, спасибо, вместо тупой udp-собиралки и простого агрегатора держать кластер говна с мысклем, спасибо 🙂
Если приходится слать данные с каждого аппсервера на каждый запрос — то проблема не в жаббикcе 🙂
лолшто, какой мыскль?
ладно, хули мы тут спорим.
ты молодец!
а, это не ты молодец
всё равно, все молодцы!
всем добра в этом чате!
счётчики всякие
NetXMS по-моему ближе к заббиксу-мунину.
с newrelic функционал пересекается сильно. я когда-то пытался её установить, но:
— нужно ставить непонятный php extension из бинарников и ещё джава агенты на каждую тачку
— на моей машине этот экстеншн вылетает с segfault
— 1 week истории на среднем тарифном плане — это мало, а $150 баксов на максимальном плане за сервер — много. ну то есть у нас несколько десятков appсерверов, например
ну вот эта наша штука именно для такого использования. с каждого сервера при каждом запросе в неё уходит куча счётчиков
А зачем?
Серьезно, я действительно не понимаю, нафига это нужно. Я знаю только один вид бизнеса, где подобная детализация оправдана — и это не датинг 🙂
ну например, возросло число запросов на каком-то определённом сервере с БД. (потому что какой-то криворукий прогер забыл про кэширование, скорее всего). как будешь искать проблему?
или, например, пользователи с партнёра, с которым у нас кросс-авторизация, жалуются, что медленно грузится главная. это у нас что-то не так или у партнёра?
мы (постоянно) меряем время этого внешнего запроса на проверку сессии (который выполняется, кстати, не каждый раз, а только если действительно нужно проверить), и записываем время. потом считаем перцентили, т.е. что «99% запросов укладываются за время … 80% укладываются за …, среднее время — …».
открываем график, смотрим есть ли проблема.
пфаааа. Я знал что мамба жлобская шарага, но блядь, чтоб жать денег на систему анализа производительности аппов, но при этом въебать живые ресурсы в разработку, а потом ещё и поддержку поделия которое не умеет и половины, то что они предлагают — пиздец. У вас там вообще TCO считают?
Потом, у них есть NR Enterprise, с очень гибкой ценовой политикой. Про какие Java агенты ты говоришь, я так и не понял. По крайней мере с руби мониторнгом там ничего такого не надо.
Смотреть — по статистике БД, по количеству коннектов в первую очередь.
Но вообще — у меня в голове сама ситуация — программер забыл — не укладывается. Код на продакшн выкладывается не централизовано? Контроля выкладки эксплуатацией нет?
В конце концов, тикет на выкладку как закрывается?
Во втором же случае — вцелом-то разумно, но! Локальная кратковременная проблема (например, опять кто-то по дороге лег, и маршруты 30 сек. перестраивались) приведет к пику на графике. При том, что вобщем-то это проблемой не является, и исследования не требует.
Я больше про то, что показательной статистика является только усредненная за достаточно большой промежуток времени. Скажем, минуту-две.
вот что за джава агент:
…
The agent has two parts, a PHP extension and a local proxy daemon.
вот этот последний это какая-то джавахерь, а первая херь распространяется в бинарниках и при запуске вылетает с сегфолтом и в техподдержке не знают, чем мне помочь.
что касается твоего наброса, то я вот не совсем понимаю, ты предлагаешь завязать критически важную штуку, который мы каждый день пользуеся, на каких-то левых чуваков, при этом нам вдруг потребуется функционал, которого у них нет, то мы ничего не сможем сделать. и установить какую-то closed-source херь, и джава агент.
и при всём при этом измеряться будет не то, что нужно нам, а то что решили измерять они. при этом попытаться не вылезти за их ограничения, «The limit for the total number of transactions should be less than 1000 unique transaction names» — учитывая, что у них плоская схема (вместо service->operation, как у нас), мы уже прямо сейчас вылазим.
ну ок, круто, жлобская контора.
я хз как там с точки зрения финансов, ибо я программер, но мы нюрелик юзаем на полную катушку. И срём им любые данные какие пожелаем. У нас вообще всё ебацо модульное — мы и им срём, и в нетхмс срём, и в бэкофис срём и в собственную тулзу для суппорт тима срём. И всё заебись с реликом. Я хз чё у вас с ним не контачит.
код на продакшн выкладывается централизованно, централизованный QA тоже есть. возможности контролировать каждую строчку каждого программиста — нет.
ну и вот выросло число коннектов. было, допустим, 200, стало 300. процесслист показывает какие-то запросы (все разные, меняются. подвисших, lock wait и прочей страшной фигни нет). как узнать, откуда проблема?
ну то есть локально ты проблему, наверное, решишь. посмотришь, что разложили, посмотришь на запросы и найдешь, в конечном итоге.
> Я больше про то, что показательной статистика является только усредненная за достаточно большой промежуток времени. Скажем, минуту–две.
тоже верно. но мы и усредняем.
> например, опять кто–то по дороге лег, и маршруты 30 сек. перестраивались
вот. или легло что-то у партнёров. или что-то у нас.
но партнёров много, ещё много всяких внутренних демонов, время реакции БД зависит от того, не делает ли в этот момент кто-то очень большой инсерт, время реакции поисковых серверов может увеличиваться во время индекскации, и в целом иметь какой-то способ контроля всего этого гораздо лучше, чем не иметь.
Называть New Relic каким-то там левыми чуваками, это как минимум глупо.
У них есть возможность собирать метрики. Считайте любые KPI, никто не мешает.
Про имена транзакций (метрик-сессий): «exceeding that is not recommended.». Это не ограничение, это рекомендация.
И ещё раз. Без расчёта TCO, начинать разработку нормальной метрикособиралки (которая как ты сам сказал критическая штука), это даже не смешно. А судя по твоей реакции, у вас тупо нет людей которые могли бы подумать о том, что внедрение или разработку любого продукта, даже инхауз тулзы, которая занимает больше пары человекодней, надо хоть как-то бюджетировать. Дальше логическую цепочку до слова «жлобская контора» можешь составить сам.
Охуеть просто, мне казалось что в мамбе внутри всё гораздо лучше.
Ну и да. Я в, можно сказать, рад что вы начали разработку своей тулзы и бросили её в опенсурс. Это хорошо что у вас есть какой-то R&D и вы готовы его результатами делится.
прости что я тебя подвёл.
у нас использовалось решение в виде готовой программы x и ещё кучи самописных костылей вокруг, чтобы как-то наши задачи решать. я предложил сделать что-то своё, оценил примерно время на это. мне сказали «ок. делай».
про существование new relic и tracelytics я конечно знал, даже кидал ссылки типа «а вот как ребята сделано такую-то статистику», но всерьёз предложить «а давайте не будем сами собирать статистику а делать это с помощью new relic» я если честно даже не задумался ни разу. мне кажется что чужой бинарный код это очень плохо, установка джава-агента на каждый сервер это плохо, и много десятков мегабит исходящего трафика с каждого сервера это тоже плохо, и плюс ко всему этому, возьмём со скидкой, $10к в месяц. 10к в месяц это один программист+налоги+сопутствующие расходы, а я даже во время разработки этой штуки занимался другими бизнес-задачами, поэтому 1 человек это много. поэтому я даже всерьёз о таком варианте не думал. но я-то простой программист, и в целом про необходимость какой-то нормальной оценки стоимости ты прав. но я спрошу завтра у itдиректора, что он об этом думает.
правильно все они сделали.
1) левые блобы хуйпойми какими индусами писанные. Хуй с ним если отдельными демонами — так еще и php extension закрытый. Знаешь как это весело, когда внезапно на аппсерверах сегфолтится php с хуйней типа «double free» в бэктрейсе, причем на тестовом стенде нихрена не проявляется? Пизданется-то тут не только собиралка а ваще всё.
2) ты сорцы смотрел? Это максимум человекомесяц включая тестирование и внедрение. Какое там TCO.
потому что по прямым показателям источник проблемы будет выявлен и исправлен быстрее, чем по косвенным
ну, тут ты немного перегибаешь. трудозатраты где-то 1.5 месяца (: из них 2-3 недели на сам демон и 3-4 на джаваскриптовый интерфейс с графиками.
а внедрение посчитать нельзя, потому что переключались с существующей штуки, которая уже была внедрена.
а, интерфейс — возможно, я его по картинке в аттаче оценивал, там 3-4 недель не вижу 🙂
переключались с первой (anight-овской) пинбы? 😉
ну и в этом контексте, месяц, полтора, какая в жопу разница