ProHoster > блог > адміністраванне > Статыстыка і маніторынг PHP скрыптоў у рэальным часе. ClickHouse і Grafana ідуць на дапамогу да Pinba
Статыстыка і маніторынг PHP скрыптоў у рэальным часе. ClickHouse і Grafana ідуць на дапамогу да Pinba
У гэтым артыкуле я раскажу, як выкарыстоўваць pinba сумесна з clickhouse і grafana замест pinba_engine і pinboard.
На php-праекце pinba - мабыць адзіны надзейны спосаб зразумець, што адбываецца з прадукцыйнасцю. Праўда звычайна pinba укараняецца толькі тады, калі ўжо назіраюцца праблемы і не зразумела "дзе капаць".
Часта ніхто паняцця не мае, колькі разоў у секунду/хвіліну выклікаецца той ці іншы скрыпт і пачынаюць аптымізаваць «на навобмацак», пачынаючы з тых месцаў, што здаюцца лагічна.
Нехта аналізуе логі nginx, а нехта павольныя запыты ў бд.
Вядома, pinba не была б лішняй, але ёсць некалькі прычын, чаму яна ёсць далёка не на кожным праекце.
І першая прычына гэта ўстаноўка.
Для таго, каб больш-менш атрымаць нейкі "выхлап" ад укаранення пінбы, вельмі пажадана бачыць метрыкі не толькі за апошнія хвіліны, але і на працяглым прамежку часу (ад дзён да месяцаў).
Для гэтага трэба:
усталяваць экстэншн для php (і магчыма вы захочаце модуль для nginx)
скампіляваць экстэншн для mysql
ўсталяваць pinboard і наладзіць cron
З-за невялікай колькасці інфармацыі аб пінбе шмат у каго склалася ўражанне, што яна працавала толькі на php5 і даўно засталася ў мінулым, але як мы ўбачым далей — гэта не так.
Першы крок - самы просты, усяго тое трэба выканаць каманду:
apt install php-pinba
У рэпазітарах гэты экстэншн ёсць аж да php 7.3 улучна і вам не трэба нічога кампіляваць.
Пасля выканання каманды ўстаноўкі мы адразу атрымліваем ужо якое працуе пашырэнне, якое збірае і шле метрыкі кожнага скрыпту (працягласць працы, памяць і т.д.) у фармаце protobuf па udp на 127.0.0.1:30002.
Гэтыя udp-пакеты пакуль што яшчэ ніхто не ловіць і не апрацоўвае, але гэта ніяк дрэнна не ўплывае на хуткасць ці стабільнасць працы вашых php-скрыптоў.
Да нядаўняга часу ў якасці дадатку, якое магло лавіць і апрацоўваць гэтыя udp-пакеты быў толькі pinba_engine. Апісанне «просты і лаканічнай» усталёўкі адбівае жаданне калі-небудзь яшчэ раз гэта чытаць і ўнікаць. У кіламетровых спісах залежнасцяў ёсць як назовы пакетаў, так і назовы праграм і спасылкі на асобныя старонкі з іх усталёўкай, а ў тых свае спасылкі на іншыя залежнасці. Разбірацца з гэтай лабудай ні ў кога не хапае ні часу, ні жадання.
Магчыма, калі-небудзь pinba10 можна будзе ўсталяваць адной-дзвюма камандамі і не чытаць кучу матэрыялу, каб зразумець як гэта зрабіць, але пакуль што гэта не так.
Калі вы ўсё ж такі ўсталявалі pinba_engine, то гэта толькі палова справы. Бо без Pinboard вам давядзецца абмежавацца дадзенымі толькі за апошнія некалькі хвілін або самастойна агрэгаваць, захоўваць і візуалізаваць дадзеныя. Добра, што pinboard дастаткова просты ў ўстаноўцы.
Здавалася б, навошта такія пакуты калі ўсе метрыкі з php ужо ідуць на udp-порт у фармаце protobuf і ўсё што трэба, гэта напісаць дадатак, якое іх будзе лавіць і складаць у якое-небудзь сховішча? Мабыць тым распрацоўшчыкам, каму прыходзіла гэтая думка ў галаву, адразу садзіліся за напісанне сваіх ровараў, частка якіх патрапіла на гітхаб.
Далей варта агляд з чатырох апенсурсных праектаў, якія захоўваюць метрыкі ў сховішчы, з якіх гэтыя дадзеныя лёгка дастаць і візуалізаваць, напрыклад, з дапамогай grafana.
udp сервер на go, які захоўвае метрыкі ў OpenTSDB. Магчыма, калі OpenTSDB у вас ужо выкарыстоўваецца на праекце, то вам такое рашэнне падыдзе інакш рэкамендую прайсці міма.
udp сервер на go, ад таго ж хабраюзера, які на гэты раз захоўвае метрыкі ў InfluxDB. На шматлікіх праектах для маніторынгу ўжо зараз выкарыстоўваецца InfluxDB, таму для іх такое рашэнне можа выдатна падысці.
Плюсы:
InfluxDB дазваляе агрэгаваць атрыманыя метрыкі, а арыгінал выдаляць праз зададзены час.
Мінусы:
гэтае рашэнне не захоўвае інфармацыю па таймерах.
InfluxDB будзе захоўваць адрасы старонак сайта як тэгі і калі ў вас шмат унікальных адрасоў старонак, то гэта будзе прыводзіць да падвышанай выдатку аператыўнай памяці. З пэўнага моманту ёнпачне жэрці памяць як не ў сябе“. (крыніца)
udp сервер на go, які захоўвае метрыкі ў ClickHouse. Гэтае рашэнне майго сябра. Менавіта пасля азнаямлення з ім я вырашыў, што час узяцца за пінбу і клікхаўс.
Плюсы:
клікхаўз ідэальна падыходзіць для такіх задач, ён дазваляе сціскаць дадзеныя настолькі, што вы можаце захоўваць усе сырыя дадзеныя нават без агрэгацый
калі патрабуецца, тыя вы можаце лёгка агрэгаваць атрыманыя метрыкі
udp сервер на php, які захоўвае метрыкі ў ClickHouse. Гэтае маё рашэнне, якое з'яўляецца вынікам знаёмства з pinba, ClickHouse і protobuf. Пакуль я разбіраўся з усім гэтым звязкам я напісаў «proof of concept», які нечакана для мяне не спажываў значныя рэсурсы (30 мегабайт аператыўнай памяці і менш за 1% ад аднаго з васьмі ядраў працэсара), таму я вырашыў падзяліцца ім з грамадскасцю.
Плюсы - тыя ж, што і ў папярэдняга рашэння, таксама я выкарыстаў звыклыя назвы з арыгінальнай pinba_engine. Яшчэ я дадаў канфіг, які дазваляе запусціць адразу некалькі інстансаў пінбасэрвера, каб захоўваць метрыкі ў розныя табліцы - гэта карысна, калі вы захочаце збіраць дадзеныя не толькі з php, але і з nginx.
Мінусы - "фатальны недахоп" і тыя дробязі, якія не задаволяць асабіста вас, але маё рашэнне - "простае як тапак" і складаецца ўсяго з каля 100 радкоў кода, так што любы php-распрацоўшчык зможа за пару хвілін памяняць што яму не спадабаецца.
Прынцып працы
Праслухоўваецца udp-порт 30002. Усе ўваходныя пакеты дэкадуюцца паводле protobuf-схемы і агрэгуюцца. Раз у хвіліну робіцца ўстаўка пачкі ў клікхаўс у табліцу pinba.requests. (усе параметры наладжваюцца ў канфігу)
Трохі пра клікхаўс
Clickhouse падтрымлівае розныя рухавічкі захоўвання дадзеных. Самы часта выкарыстоўваны - MergeTree.
Калі вы ў нейкі момант вырашыце, захоўваць агрэгаваныя дадзеныя за ўвесь час, а волкія - толькі за апошні, то можна стварыць materialized view з групоўкай, а асноўную табліцу pinba.requests перыядычна чысціць, пры гэтым усе дадзеныя будуць заставацца ў materialized view. Больш за тое пры стварэнні табліцы pinba.requests вы можаце паказаць «engine = Null», тады волкія дадзеныя наогул не будуць захаваюцца на дыск і пры гэтым яны ўсё роўна будуць трапляць у materialized view і захоўвацца агрэгаванымі. Такі схемай я карыстаюся для метрык nginx, таму што на nginx у мяне разоў у 50 больш запытаў, чым на php.
Такім чынам, вы прайшлі доўгі шлях і мне не хацелася б пакідаць вас на паўдарогі, так што далей будзе падрабязнае апісанне ўстаноўкі і наладкі майго рашэння і ўсяго, што вам спатрэбіцца, а таксама падводныя камяні, аб якія разбіўся не адзін карабель. Увесь працэс усталёўкі апісаны для Ubuntu 18.04 LTS і Centos 7, на іншых дыстрыбутывах і версіях працэс можа малаважна адрознівацца.
Ўстаноўка
Усе неабходныя каманды я вынес у Докер-файл для палягчэння ўзнаўляльнасці інструкцый. Ніжэй будуць апісаны толькі падводныя камяні.
php-pinba
Пасля ўстаноўкі пераканайцеся, што ў файле /etc/php/7.2/fpm/conf.d/20-pinba.ini у вас раскаментаваны ўсе опцыі. У некаторых дыстрыбутывах (напрыклад, centos) яны могуць быць закаментаваны.
Падчас усталёўкі clickhouse папросіць вас задаць пароль для карыстальніка default. Па-змаўчанні гэты карыстач даступны са ўсіх ip, таму калі ў вас няма на серверы фаервала, то абавязкова задайце яму пароль. Гэта можна таксама зрабіць ужо пасля ўсталёўкі ў файле /etc/clickhouse-server/users.xml.
Таксама варта звярнуць увагу, што clickhouse выкарыстоўвае некалькі портаў, у тым ліку, 9000. Гэты порт таксама выкарыстоўваецца для php-fpm у некаторых дыстрыбутывах (напрыклад, centos). Калі ў вас гэты порт ужо выкарыстоўваецца, тыя вы можаце яго змяніць на іншы ў файле /etc/clickhouse-server/config.xml.
grafana з убудовай для clickhouse
Пасля ўстаноўкі графаны выкарыстоўвайце лагін admin і пароль admin. Пры першым уваходзе графана папросіць вас задаць новы пароль.
Далей заходзім у меню «+» -> import і паказваем нумар дашборда для імпарту 10011. Гэты дашборд я падрыхтаваў і заліў, каб вам не трэба было рабіць яго самастойна яшчэ раз.
Графана падтрымлівае працу з клікхаўсам праз іншую ўбудову, але для іншых убудоваў у графаны не працуюць алерты (тыкет на гэта важыць ужо некалькі гадоў).
pinba-server
Усталёўка protobuf і libevent - не абавязковая, але паляпшае прадукцыйнасць pinba-server. Калі вы ўсталюеце pinba-server у тэчку адрозную ад /opt, то вам таксама трэба будзе падправіць systemd скрыпт файл.
pinba-модуль пад nginx
Для кампіляцыі модуля патрэбныя зыходнікі той жа версіі nginx, што ўжо ўсталявана ў вас на серверы, а таксама тыя ж самыя опцыі кампіляцыі інакш зборка пройдзе паспяхова, але пры падлучэнні модуля будзе выдавацца памылка, што "модуль бінарна не сумяшчальны". Опцыі кампіляцыі можна паглядзець з дапамогай каманды nginx -V
лайфхакі
У мяне ўсе сайты працуюць толькі па https. Поле schema становіцца бессэнсоўным, таму я выкарыстоўваю яго для падзелу web/console.
У скрыптах, якія даступныя з вэба я выкарыстоўваю:
if (ini_get('pinba.enabled')) {
pinba_schema_set('web');
}
А ў кансольных (напрыклад, крон-скрыпты):
if (ini_get('pinba.enabled')) {
pinba_schema_set('console');
}
У маім дашбордзе ў графане ёсць перамыкач web/console для прагляду статыстыкі асобна.
Таксама ў пінбу можна перадаваць свае тэгі, напрыклад:
pinba_tag_set('country', $countryCode);
На гэтым усё.
Вялікая просьба адказаць на апытанні пад артыкулам.
Традыцыйна папярэджваю, што я не кансультую і не дапамагаю праз асабістыя паведамленні Хабра і сацсеткі.