Pull to refresh

Comments 63

Макс =) привет, попробуйте графит =) штука очень клевая =) гораздо гибче чем RRDTool настраивается… единственное под ваш объем данных диски нужны хорошие…
Мне вообще вот эта штука нравится opentsdb.net/
Судя по презентации проект интересный, но на практике не пробовали
кстати, что насчет Nginx модуля? я правильно понимаю что аггрегации для данных собираемых с nginx надо поднимать отдельный Instance pinba?
Разные источники данных — разные инстансы, да.
Технически смешивать никто не мешает, но смысла в этом мало — получится «в среднем по больнице 36.6».
Поэтому у нас отдельные инстансы под FPM, CLI, nginx и еще по кластерам сервисов.
Фичереквесты принмаете? :)
Конечно. А фичереквесты с патчами — так вообще без проблем.
Спасибо за очередную отличную статью! Вы молодцы, что делитесь своими наработками.
Всегда пожалуйста. Кстати если есть пожелания, о чем бы вам было интересно прочитать, можете оставлять их здесь.
Расскажите про ваш внутренний php-framework: какие особенности, шаблоны проектирования, приёмы в нём используются, в целом про качество и тестируемость кода. Может быть уже где-то есть почитать даже?
Спасибо, подумаем.
Насчет качества и тестируемости кода. Недавно наш девелопер на www.itmozg.ru/high-performance-conference/ делал доклад о том как, мы расскладываем код. Частично эта тема затрагивает качество кода и тестируемость. Вроде бы в течение нескольких недель организаторы опубликуют видео докладов, так что следите за анонсами.
на Хайлоаде fisher говорил, что у них нет ни какого фреймворка.
уже что-то изменилось?
Возможно, у Фишера более строгие требования к тому, что называть фреймворком :)
Наверное просто по разному трактуем этот термин
На мастер-классе от fisher слышал именно в такой формулировке.
а можно с этого момента и поподробнее?
Больше мне ничего не известно, поэтому и спросил.
есть потребность мониторить Сишный модуль,
сейчас думаю над использованием pinba
Не знаю какой тупица минуснул, но не вижу принципиального различия, что мониторить РНР код или Сишный модуль.
Обмен идет по protobuf протоколу, который вполне может сформировать Сишный модуль.
Не вижу трудностей отправки его по UDP.
Модуль так же принимает разные урлы, производительность которых нужно промониторить, правда хост один…
Модуль обращается к мускульным базам, мемкешам и прочим демонам…
почему бы не использовать pinba-engine для приема и анализа статистики???
Можно использовать кольцевые (циклические) базы данных типа RRDtool или Graphite.

Ну, строго говоря, у Graphite кольцевая база называется Whisper. Сам Graphite — это несколько больше, чем просто база. Утрируя, можно сказать, что Graphite = Carbon + Whisper. Ну и еще graphite-web сбоку, конечно :)
Получается для анализа приложений с Front Controller не очень система пригодна? Или в script_name учитываются все include/require?
Я имел в виду «сбор общей статистики без внесения изменений в PHP-код», так-то сразу мысль мелькнула об использовании тэгов для этого.
Нет, без внесения изменений никак не выйдет. Если у вас работает один скрипт, то его вы везде и увидите, а как по-другому?
Вместо занесения $SERVER['SCRIPT_NAME'] заносить URL? Вернее даже не URL, а классифицировать URL'ы по маске (утрируя /company/*/blog/* /post/* и т. п.) и заносить маску.
это всё очень неочевидная магия которая будет работать далеко не всегда
Проще одну строчку кода добавить в то место где определяется, какой контроллер должен выполняться
Зачастую это определяется во внутренностях фреймворка, который далеко не все готовы «патчить». А насчёт не всегда — можно позаимствовать механизм определения location у nginx и заносить его имя. Ещё не встречал ситуаций, чтобы он не справился, вплоть до таких, наверное, экзотических как направление запроса /index.php?page=user&mode=view&id=* в обработчик рельсового приложения с приведением к /user/*
Ну, технически мы всё-таки профайлим не УРЛы, а скрипты.
И, соотв-но, результат index.php — совершенно верный. Это именно он выполняется N раз в секунду и именно его надо оптимизировать, а не /user/profile/view или тому подобное.
Просто для приложений с единой точкой входа время выполнения index.php может различаться на порядки для отдачи (псевдо)статической страницы и для страницы требующей, например, десятков, если не сотен обращений к БД. Без информации об урле время выполнения скрипта почти ничего не скажет — оно может отличаться на порядки.
Честно говоря, не понимаю о чем мы сейчас говорим =)
Вопрос решается одной строкой, не надо никаких location и т.п.
Одной строкой в коде фреймворка…
Зачастую в фреймворках предусмотрены механизмы вызова пользовательского кода на различных стадиях, надо лишь копнуть чуть глубже. Например в питоне это стандартизировано и делается с помощью middleware. В пхп стандарта нет и каждый фреймворк делает по-своему.

pinba_script_name_set() _необязательно_ вызывать в самом начале, можно и в конце скрипта
Ребята, а когда вы допилите пакеты на .deb? Оно вывается на debian 6 при попытке установиться, т.к. в dotdeb mysql 5.5, а у вас requirement 5.1. Я бы с удовольствеим использовал, но не хочу заниматься самостоятельной поддержкой компиляции и разворачивать компиляторы на боевых серверах.
битый:

root@web:~# apt-get install pinba-mysql-engine
Reading package lists… Done
Building dependency tree
Reading state information… Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
pinba-mysql-engine: Depends: mysql-server (= 5.1.62-1~dotdeb.0)
E: Broken packages
Так а что мешает отдельный сервер с Пинбой держать на 5.1? Это же зависимость только для сервера, клиентская библиотека зависимости от MySQL-сервер не имеет.
стоимость аренды серверов около ~800$ в месяц. До кучи, пакет 5.1.62-1~dotdeb.0 вообще уже из dotdeb выпилен, и поставить даже с 5.1 не представляется возможным.
Собрать MySQL и пинбу из исходников — это 10 минут времени от силы.
Вы больше времени на поиск .deb потратили.
… и 300 метров говна на сервере :)
Если вы можете сделать пакеты — сделайте, я поставлю на офиц. сайте ссылку на ваш репозиторий.
Я лично дебиан не использую и у меня такой необходимости нет.

>разворачивать компиляторы на боевых серверах

Непонятно зачем это делать. Соберите бинарник 1 раз и скопируйте его везде.
Одна проблема — версия пакета mysql должна быть везде идентична.
да, а я имею привычку ставить security update.
Простите, а зачем ставить security update на то, что никто кроме вас видеть не будет?
Отключите доступ по сети, оставьте только unix-сокет и используйте этот инстанс mysql только для сбора данных пинбы.
От кого тут защищаться надо?
Это одна из поддерживающих баз. На ней нет продакшена, но требуется 5.5.

Что за привычка объяснять «вам это не надо» на вопрос «как»?
я еще раз повторяю: используйте этот инстанс mysql только для сбора данных пинбы.
а у вас откуда привычка хамить тем, кто вам пытается помочь?
Это не хамство, с моей точки зрения, совет «а ты не обновляй» иногда звучит как «а ты, когда гости придут, закрой спальню чтобы не убираться лишний раз».
оно под 5.5 вообще компилится?
оно вообще под 5.5 компилится.
и под 5.6 тоже.
спасибо, что спросили.
Активно используем пинбу в течении последних 2х лет. Сразу как-то не понравилась зависимость от MySQLя, т.к. хотели хранить данные и иметь возможность мониторить работу в реальном времени.

В итоге был сделан свой демон: github.com/aryoh/pinba2zmq — слушает пинбу и отдает данные в zmq сокет раз в секунду. Теоретически можно и чаще, но нафига? :)

Написан на питоне, установка может показаться нетривиальной. Работает в продакшене на слабенькой vps'ке уже года полтора, сейчас держит нагрузку в 10к запросов к пхп в секунду, с 35-40к таймеров.

С него данные потом собираются и сохраняются в постоянное хранилище, плюс можно смотреть данные онлайн. Пример «клиента»:

#!/usr/bin/env python

from gevent_zeromq import zmq
import ujson

def pinba_slow():
    context = zmq.Context()
    sub = context.socket(zmq.SUB)
    sub.connect("tcp://[хост с pinba2zmq]:5000")
    sub.setsockopt(zmq.SUBSCRIBE, '')
    try:
        while True:
            ts, requests = ujson.decode(sub.recv())
            cnt = 0
            for info in requests:
                (hostname, server, script), (rps, request_size, request_time), timers = info
                cnt = cnt + rps
            print ts, 'requests per second:', cnt
    except KeyboardInterrupt:
        pass

if __name__ == '__main__':
    pinba_slow()


Буду рад если кому-то ещё он будет полезен :)
В дальнейшем надеюсь выложим в опенсорс и вывод графиков и остальные компоненты системы.
Сразу как-то не понравилась зависимость от MySQLя, т.к. хотели хранить данные и иметь возможность мониторить работу в реальном времени. Не понял вот эту фразу. Вы хотели хранить все данные за все время?
Да, хотим хранить данные за всё время.
Само собой архивные данные группируются за бОльший интервал, но цель была хранить данные за максимальный срок для анализа того как у нас меняются показатели с течением времени.
Например стали ли наши скрипты за год работать лучше или хуже.
мы для этих целей используем rrdtool
Храним там даннные отчетов за последние пол-года.
Если бы всё было так просто :) Пробовали, не подошло по кучи разных причин.
Но основной плюс данного демона — возможно посмотреть что происходит (тормозит) вот прям сейчас.
возможно посмотреть что происходит (тормозит) вот прям сейчас.
pinba ведь тоже это показывает. Или вы хотите агрегировать данные посекундно?
Да, посекундно. Пинба это да показывает, но не дает возможности по простому получать секундные среды, кроме как раз в секунду вычитывать новые записи из таблиц, что не очень удобно. Плюс не очень удобна работа с таймерами и «отчётами» по таймерам — нужно заранее сделать отчёты (и в случае с ррд графики по ним), в моем случае я всегда могу посмотреть что было пол-часа назад имея все данные и имея возможность делать какие угодно отчёты.
Не совсем понятно что вы понимаете под «прямо сейчас».
Пинба тоже хранит данные за «прямо сейчас и за N секунд до этого».
Чем меньше период хранения данных, тем меньше получается «инерция» графиков и тем более актуальны они на данный момент.
А чем ваш демон отличается?
Вот в первую очередь не хватает банального таймстемпа у запросов (его же нет, да?). Из-за этого я не могу получить точных секундных срезов. Во всяком случае по простому.
В моем случае я имею источник секундных «сырых» данных, которые потом как угодно используются. Хоть для реалтаймовых графиков, хоть для хранения с последующей агрегацией.
>Вот в первую очередь не хватает банального таймстемпа у запросов (его же нет, да?).
Да и вполне намеренно — я не смог найти ему ни одного применения.
К слову как раз смотрю в сторону OpenTSDB как более удобное хранилище.
Лушче посмотрите в сторону graphite + megacarbon
Одна из немногих статей которую я продолжил читать после первых двух предложений. Вот такое начало — лучшее начало для поста!
Sign up to leave a comment.