Недавно на работе я сделал систему для мониторинга и анализа производительности. Примерно как известная многим пинба, но с человеческим лицом.

Получилось довольно приятная штука, которая мне самому нравится. Поэтому мы решили выложить её на гитхаб.
Пользуйтесь, если нужно. https://github.com/mambaru/btp-daemon

30 Responses to Аналог пинба

  1. HneZZ:

    а что он умеет, по сравнению с тем же zabbix?

  2. KipaTa:

    zabbix мониторит параметры серверов. а BTP мониторит счётчики производительности, которые отправляет само приложение. то есть «сколько времени занимает запрос к мемкэшу» или «сколько времени работает скрипт такой-то», или «какие скрипты дают основную нагрузку на такой-то сервис».

  3. Naref:

    жаббикс мониторит все, что ему подсунешь. Но это так, к слову.

    Прикольно.

  4. XibZZ:

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

  5. XibZZ:

    А что у вас там на TT? Искалка по анкетам?

  6. Xuagreen:

    NetXMS, newrelic.

  7. Xxxno:

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

  8. XibZZ:

    ага, спасибо, вместо тупой udp-собиралки и простого агрегатора держать кластер говна с мысклем, спасибо 🙂

  9. Naref:

    Если приходится слать данные с каждого аппсервера на каждый запрос — то проблема не в жаббикcе 🙂

  10. Xxxno:

    лолшто, какой мыскль?

  11. Xxxno:

    ладно, хули мы тут спорим.
    ты молодец!

  12. Xxxno:

    а, это не ты молодец
    всё равно, все молодцы!
    всем добра в этом чате!

  13. KipaTa:

    счётчики всякие

  14. KipaTa:

    NetXMS по-моему ближе к заббиксу-мунину.

    с newrelic функционал пересекается сильно. я когда-то пытался её установить, но:
    — нужно ставить непонятный php extension из бинарников и ещё джава агенты на каждую тачку
    — на моей машине этот экстеншн вылетает с segfault
    — 1 week истории на среднем тарифном плане — это мало, а $150 баксов на максимальном плане за сервер — много. ну то есть у нас несколько десятков appсерверов, например

  15. KipaTa:

    ну вот эта наша штука именно для такого использования. с каждого сервера при каждом запросе в неё уходит куча счётчиков

  16. Naref:

    А зачем?

    Серьезно, я действительно не понимаю, нафига это нужно. Я знаю только один вид бизнеса, где подобная детализация оправдана — и это не датинг 🙂

  17. KipaTa:

    ну например, возросло число запросов на каком-то определённом сервере с БД. (потому что какой-то криворукий прогер забыл про кэширование, скорее всего). как будешь искать проблему?

    или, например, пользователи с партнёра, с которым у нас кросс-авторизация, жалуются, что медленно грузится главная. это у нас что-то не так или у партнёра?
    мы (постоянно) меряем время этого внешнего запроса на проверку сессии (который выполняется, кстати, не каждый раз, а только если действительно нужно проверить), и записываем время. потом считаем перцентили, т.е. что «99% запросов укладываются за время … 80% укладываются за …, среднее время — …».
    открываем график, смотрим есть ли проблема.

  18. Ppoed:

    пфаааа. Я знал что мамба жлобская шарага, но блядь, чтоб жать денег на систему анализа производительности аппов, но при этом въебать живые ресурсы в разработку, а потом ещё и поддержку поделия которое не умеет и половины, то что они предлагают — пиздец. У вас там вообще TCO считают?

    Потом, у них есть NR Enterprise, с очень гибкой ценовой политикой. Про какие Java агенты ты говоришь, я так и не понял. По крайней мере с руби мониторнгом там ничего такого не надо.

  19. Naref:

    Смотреть — по статистике БД, по количеству коннектов в первую очередь.
    Но вообще — у меня в голове сама ситуация — программер забыл — не укладывается. Код на продакшн выкладывается не централизовано? Контроля выкладки эксплуатацией нет?
    В конце концов, тикет на выкладку как закрывается?

    Во втором же случае — вцелом-то разумно, но! Локальная кратковременная проблема (например, опять кто-то по дороге лег, и маршруты 30 сек. перестраивались) приведет к пику на графике. При том, что вобщем-то это проблемой не является, и исследования не требует.
    Я больше про то, что показательной статистика является только усредненная за достаточно большой промежуток времени. Скажем, минуту-две.

  20. KipaTa:

    вот что за джава агент:
    https://newrelic.com/docs/php/new-relic-
    The agent has two parts, a PHP extension and a local proxy daemon.

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

  21. KipaTa:

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

    и при всём при этом измеряться будет не то, что нужно нам, а то что решили измерять они. при этом попытаться не вылезти за их ограничения, «The limit for the total number of transactions should be less than 1000 unique transaction names» — учитывая, что у них плоская схема (вместо service->operation, как у нас), мы уже прямо сейчас вылазим.

    ну ок, круто, жлобская контора.

  22. Xuagreen:

    я хз как там с точки зрения финансов, ибо я программер, но мы нюрелик юзаем на полную катушку. И срём им любые данные какие пожелаем. У нас вообще всё ебацо модульное — мы и им срём, и в нетхмс срём, и в бэкофис срём и в собственную тулзу для суппорт тима срём. И всё заебись с реликом. Я хз чё у вас с ним не контачит.

  23. KipaTa:

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

    ну и вот выросло число коннектов. было, допустим, 200, стало 300. процесслист показывает какие-то запросы (все разные, меняются. подвисших, lock wait и прочей страшной фигни нет). как узнать, откуда проблема?
    ну то есть локально ты проблему, наверное, решишь. посмотришь, что разложили, посмотришь на запросы и найдешь, в конечном итоге.

    > Я больше про то, что показательной статистика является только усредненная за достаточно большой промежуток времени. Скажем, минуту–две.

    тоже верно. но мы и усредняем.

    > например, опять кто–то по дороге лег, и маршруты 30 сек. перестраивались

    вот. или легло что-то у партнёров. или что-то у нас.
    но партнёров много, ещё много всяких внутренних демонов, время реакции БД зависит от того, не делает ли в этот момент кто-то очень большой инсерт, время реакции поисковых серверов может увеличиваться во время индекскации, и в целом иметь какой-то способ контроля всего этого гораздо лучше, чем не иметь.

  24. Ppoed:

    Называть New Relic каким-то там левыми чуваками, это как минимум глупо.

    У них есть возможность собирать собственные метрики. Считайте любые KPI, никто не мешает.

    Про имена транзакций (метрик-сессий): «exceeding that is not recommended.». Это не ограничение, это рекомендация.

    И ещё раз. Без расчёта TCO, начинать разработку нормальной метрикособиралки (которая как ты сам сказал критическая штука), это даже не смешно. А судя по твоей реакции, у вас тупо нет людей которые могли бы подумать о том, что внедрение или разработку любого продукта, даже инхауз тулзы, которая занимает больше пары человекодней, надо хоть как-то бюджетировать. Дальше логическую цепочку до слова «жлобская контора» можешь составить сам.

    Охуеть просто, мне казалось что в мамбе внутри всё гораздо лучше.

    Ну и да. Я в, можно сказать, рад что вы начали разработку своей тулзы и бросили её в опенсурс. Это хорошо что у вас есть какой-то R&D и вы готовы его результатами делится.

  25. KipaTa:

    прости что я тебя подвёл.

    у нас использовалось решение в виде готовой программы x и ещё кучи самописных костылей вокруг, чтобы как-то наши задачи решать. я предложил сделать что-то своё, оценил примерно время на это. мне сказали «ок. делай».
    про существование new relic и tracelytics я конечно знал, даже кидал ссылки типа «а вот как ребята сделано такую-то статистику», но всерьёз предложить «а давайте не будем сами собирать статистику а делать это с помощью new relic» я если честно даже не задумался ни разу. мне кажется что чужой бинарный код это очень плохо, установка джава-агента на каждый сервер это плохо, и много десятков мегабит исходящего трафика с каждого сервера это тоже плохо, и плюс ко всему этому, возьмём со скидкой, $10к в месяц. 10к в месяц это один программист+налоги+сопутствующие расходы, а я даже во время разработки этой штуки занимался другими бизнес-задачами, поэтому 1 человек это много. поэтому я даже всерьёз о таком варианте не думал. но я-то простой программист, и в целом про необходимость какой-то нормальной оценки стоимости ты прав. но я спрошу завтра у itдиректора, что он об этом думает.

  26. XibZZ:

    правильно все они сделали.

    1) левые блобы хуйпойми какими индусами писанные. Хуй с ним если отдельными демонами — так еще и php extension закрытый. Знаешь как это весело, когда внезапно на аппсерверах сегфолтится php с хуйней типа «double free» в бэктрейсе, причем на тестовом стенде нихрена не проявляется? Пизданется-то тут не только собиралка а ваще всё.

    2) ты сорцы смотрел? Это максимум человекомесяц включая тестирование и внедрение. Какое там TCO.

  27. XibZZ:

    потому что по прямым показателям источник проблемы будет выявлен и исправлен быстрее, чем по косвенным

  28. KipaTa:

    ну, тут ты немного перегибаешь. трудозатраты где-то 1.5 месяца (: из них 2-3 недели на сам демон и 3-4 на джаваскриптовый интерфейс с графиками.

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

  29. XibZZ:

    а, интерфейс — возможно, я его по картинке в аттаче оценивал, там 3-4 недель не вижу 🙂

    переключались с первой (anight-овской) пинбы? 😉

  30. XibZZ:

    ну и в этом контексте, месяц, полтора, какая в жопу разница

Добавить комментарий