Pull to refresh

Comments 50

Скорее всего вы не знали, когда выбирали название, но pinboard — крутая отладочная плата от dihalt. Мне интересно, как он отреагирует на такое название.
Да мне, честно говоря, пофигу. К электронике данный проект не имеет отношения.

Но для вас, как по мне, название неудачное. Попробуйте нагуглить свой проект по этому названию. Будет попадаться что угодно, только не он :) Мне со своим проектом это на руку, а вот как вам не знаю.
Вы знаете, это слово означает и коммутационную панель как таковую, и доску (например, пробковую) на которую булавками прикрепляют заметки/объявления.

Думаю, тут отношение примерно то же, как к названию некой ОС — «Окна». Уверен, что спора не возникнет, да и комментарий DIHALT совершенно верен, особенно в части невозможности нагуглить проект по названию.

Хоть какое-то веб-два-нольное имя подобрать, на тот же www.dotomator.com/web20.html зайти, и понажимать «Generate Name!» )
По поводу окон вы заблуждаетесь, прецедент есть.

А вообще, я считаю, что суд не прав (microsoft отсудил себе домен windows.ru). Различные продукты в не пересекающихся областях вполне могут иметь одинаковое название, особенно если названием является общеупотребляемое слово.
Об этом и писал ) — патентовать общеупотребимое понятие или слово — некомильфо.

На фоне истории со смайликами и с авторскими правами на звуки речи (не найду сейчас, чем там закончилось — «по рублю за каждую букву А» — вот уж маразм из маразмов!)

Или как там, «деньги не пахнут»?
Всем минусующим — подобная тулза, которая будет показывать, что проблемы всегда в index.php не даёт особого профита; если же будет группировка скриптов лишь по URL — то при достаточно большом кол-ве параметров вы тоже не сможете выявить нормально проблему.
Поддержка MVC — наверное выразился неправильно, но «правильная» фраза поддержка фреймворков, ещё менее информативна.
И да, посмотрите на new relic хотя бы в траильном «про» аккаунте — поймёте о чём я толкую
Поддержка фронт-контроллеров или единой точки входа.
В методе pinba_flush (если я не ошибаюсь), у Вас есть возможность передать в качестве аргумента script_name, т.ч. можете туда URI + QUERY_STRING передавать, чтобы видеть нормальную статистку по компонентам.
Ниже привел ссылку на доку, где есть примеры настройки.
В Pinboard адреса требуются, чтобы видеть, где у нас скрипт долго думает или присутствует просадка по памяти, или присутствует ошибка. На этот случай мы привели в документации примеры настройки отдачи URL вместо script_name github.com/intaro/pinboard/wiki/Configure-sending-of-readable-script-names-in-Pinba.

Как Pinboard влияет на производительность сервера?
Исходя из описания — никак, она должна запускаться на отдельной машине и собирать данные из пинбы. Сама пинба оказывает минимальное влияние на производительность благодаря тому, что отправляет собранные данные через UDP (не требуется ожидание подтверждения, как в TCP/IP).
Да, указали верно — Pinba отправляет информацию по скрипту после того, как он выполнился и отдал результат веб-серверу, поэтому отрицательного влияния на производительность нет.
А после того как он выполнился, что нам другие реквесты выполнять не надо?
Или CPU и Net после выполнения конкретных пхп скриптов становятся «бесплатными» ресурсами?
Минимально, как написал youROCK выше — это да, но так категорично «отрицательного влияния на производительность нет» это извините даже близко не верно.
Здесть коммент по этому поводу от автора пинбы tony2001. Хотя я с ним, скажем так, не во всем согласен — т.е. что мерять бенчмарком тяжко, но все же можно.
У меня есть похожий мониторинг, только для python'а и tcl'я, тоже по udp, на сях и таймерах, вообщем похож очень, только я отправляю структуру поменьше (скрипт идентификатор + старт + конец). Так вот, на высоконагруженом сервере, который практически не простаивает, результат видно даже на load average (пример для 8-ми cpu и 1000Mbit):
Мониторинг OFF:
  load average: 8.20, 8.02, 7.94
Мониторинг ON:
  load average: 8.80, 8.48, 8.34

Но главное даже не это, главное среднее время за request (отработав одни и те же тест-кейсы):
Мониторинг OFF:
  32154.380 microseconds per request
Мониторинг ON:
  37447.352 microseconds per request

Т.е. время отклика выросло на 16 с гаком процентов.
Хотя, должен признаться, я php никогда так не грузил — не знаю, как оно поведет себя там.
Другое дело, если наши реквесты выполняются секунды — нагрузку просто не видно (не померять) за погрешностью измерений.

Мой вывод для себя — влияет минимально, пока есть простои. Однако при высоком load average «паразитное» влияние имеет место быть и весьма ощутимо.
Рискну предположить, что рожденный чтобы умереть должен априори иметь больше накладных расходов даже с оптимизаторами, так что скорее всего на пхп нагрузка будет заметно меньше в процентном отношении. Но да, надо тестировать.
Чуть более удобный — сервис New Relic, но он стоит каких-то бешеных денег. Есть средства мониторинга munin, nagios и т.д., которые могут дать часть этого функционала. У pinba/Pinboard плюс в детализации, возможности просмотра realtime данных и заточенности под PHP.
Не бешеных, до 2 ppm дают скидки, с ними просто нужно уметь общаться. У нас около 70$ за инстанс (Pro). Поддержка у них хорошая, и статистических данных выше крыши, ну и оповещения об ошибках.
Мне кажется все же неверно писать о мониторинге PHP-скриптов, т.к. мониторится не конкретный скрипт, а отработка URL-запроса, в котором могут быть задействованы десятки скриптов
Наиболее полезно как раз на production. Мониторинг скриптов на production под реальной нагрузкой.
Спасибо за live-режим! Смотрю и радуюсь :-)
Вопрос в студию — почему при заходе на my-pinba.ru/server/mysite.ru/all/mem-usage (закладка «Memory peak usage») вываливается:

Sorry, the page you are looking for could not be found.

Аналогично в /all/statuses («Statuses»).
P.S. Желаю всяческих успехов вашему проекту.
Спасибо! Ловите плюс в карму! Блин, хотел ещё коммент плюсануть — промазал.
Пофиксили, в master.
Ещё один вопрос. У меня pinba стоит за Nat. Порт 3300 пробросил через роутер. Соответственно у сервера 3 IP: внешний, локальный и 127.0.0.1 Когда тестировал с 127.0.0.1 всё было хорошо, данные в pinboard live были. Поменял IP на внешний — данные поступать перестали. Поменял и на сервере и на клиенте. Как думаете, в чём косяк может быть?
Может быть, вы не учли, что Pinba работает по UDP и открыли только TCP/IP порты :)?
Это было первое, на что я подумал. Но разгадка была в другом.

pinba_address - IP address to listen at (leave it empty if you want to listen at any IP).

Сделал вот так:

pinba_address=#127.0.0.1

потом перезагрузил MySQL… и после этого всё равно не заработало (но это я так думал). Надо было просто подождить 15 минут (таймаут агрегации данных, задаваемый при установке pinboard) — и всё в порядке, новые сайты появились в списке!
Если что, мгновенную проверку можно сделать, зайдя в раздел Live. Там всегда realtime данные.
Ну так то да, но это если домен уже есть в списке. А то он у меня в списке не появлялся и я отслеживал по Live других доменов.
Спасибо! Поставил, радуюсь.

Вопрос по встроенной аутентификации:
В доках сказано что в конфиг нужно положить SHA-512 хеш пароля, после 1000 итераций хеширования.
У меня так не заработало.
Я посмотрел код vendor/symfony/security/Symfony/Component/Security/Core/Encoder/MessageDigestPasswordEncoder.php — там, как я понял, 5000 итераций и преобразование в Base 64.
Посмотрите раздел Security в Wiki, есть команда для добавления нового пользователя.
А по поводу PasswordEncoder вы правы — там 5000 итераций и base64. Поправили в документации.
Спасибо за морду! Давно хотел визуализировать пинбу,

Только не до конца понял, как поставить его на хост monitoring-server/pinboard, то есть не нашёл где прописывается base url.
Вот это проблематично. Для нее требуется отдельный хост. Разместите на поддомене.
Классная штука, траварищи! Неделю юзаю, не нарадуюсь.
Отлично! А можно реквестировать ещё добавление круговой диаграммы или гистограммы по процентному соотношению бекендов (хостов) для домена?
Что за соотношение, по какому значению?
Пусть один сайт обслуживает несколько хостов (A, B, C). Круговая диаграмма строится по соотношению количества запросов, обработанных i-ым хостом к общему количеству запросов по всем хостам). Это в статике за всё время.

А второй график — то же соотношение, но в динамике по определенным временным интервалам. Скажем каждые 5 минут берется срез за 5 предыдущих минут и определяется это соотношение, а потом по этим соотношениям строится гистограмма. Аналогично гистограмме браузеров в Liveinternet.
А в чем смысл этого графика? Как правило, делают n равноправных машин, по которым идет распределение через nginx/upstream либо dns/roundrobin.
Не обязательно, бекэнды можно настраивать по приоритетам например. Или если группа машин в разных ДЦ, и нужно занть их rps.
А вариант сделать доставку логов Pinba через Logstash в ElasticSearch для просмотра в Kibana не рассматривался? Как бы удобнее иметь один интерфейс и для просмотра логов, статистики итд. итп. Вот и тут такой же был подход избран — github.com/box/Anemometer/wiki, а жаль…
Pinba уже хранит и агрегирует данные в MySQL со множества проектов. Было удобнее там же формировать отчеты, добавив необходимую функциональность.
Немного не понял по детализации и группировке данных -доступны ли данные отдельно для каждого сайта или только для всего сервера? То есть, допустим, мне надо статистику по каждому сайту отдельно, а на сервере крутится ХХХ-сайтов.
Неплохо было бы уще какое-то демо, чтобы посмотреть, покликать :-).
На втором скриншоте видно, что в заголовке адрес сайта, а рядом фильтр по серверам. Т.е. вы видите отчеты по сайту в целом, но если он крутится на нескольких серверах, то можете посмотреть отчеты по работе сайта на каждом отдельном сервере.
Only those users with full accounts are able to leave comments. Log in, please.

Please pay attention