Мяне клічуць Антон Бадзерын. Я працую ў Цэнтры высокіх тэхналогій і займаюся сістэмным адміністраваннем. Месяц таму завяршылася наша карпаратыўная канферэнцыя, дзе мы дзяліліся назапашаным досведам з IT-супольнасцю нашага горада. Я расказваў пра маніторынг вэб-прыкладанняў. Матэрыял прызначаўся для ўзроўня junior ці middle, якія не выбудоўвалі гэты працэс з нуля.
Краевугольны камень, які ляжыць у аснове любой сістэмы маніторынгу - рашэнне задач бізнесу. Маніторынг дзеля маніторынгу нікому не цікавы. А чаго жадае бізнэс? Каб усё працавала хутка і без памылак. Бізнес хоча праактыўнасці, каб мы самі выяўлялі праблемы ў рабоце сэрвісу і максімальна хутка іх устаранялі. Гэта, па сутнасці, і ёсць задачы, якія я вырашаў увесь мінулы год на праекце аднаго з нашых замоўцаў.
Аб праекце
Праект - адна з найбуйнейшых у краіне праграм лаяльнасці. Мы дапамагаем раздробным сеткам павялічваць частату продажаў за кошт розных маркетынгавых інструментаў накшталт бонусных карт. У агульнай складанасці ў праект уваходзяць 14 прыкладанняў, якія працуюць на дзесяці серверах.
У працэсе вядзення сумоўяў я неаднаразова заўважаў, што адміны далёка не заўсёды правільна падыходзяць да маніторынгу вэб-прыкладанняў: да гэтага часу многія спыняюцца на метрыках аперацыйнай сістэмы, зрэдку маніторыць сэрвісы.
У маім выпадкам перш у аснове сістэмы маніторынгу заказчыка ляжала Icinga. Яна ніяк не вырашала ўказаныя вышэй задачы. Часта кліент сам паведамляў нам аб праблемах і не радзей нам проста не хапала даных, каб дакапацца да прычыны.
Акрамя таго, было дакладнае разуменне бесперспектыўнасці яе далейшага развіцця. Я думаю, тыя хто знаёмы з Icinga мяне зразумеюць. Такім чынам, мы вырашылі поўнасцю перапрацаваць сістэму маніторынгу вэб-прыкладанняў на праекце.
Праметэй
Мы выбралі Prometheus, зыходзячы з трох асноўных паказчыкаў:
- Вялікая колькасць даступных метрык. У нашым выпадку іх 60 тысяч. Вядома, варта адзначыць, што пераважная большасць з іх мы не выкарыстоўваем (напэўна, каля 95%). З іншага боку, яны ўсё адносна танныя. Для нас гэтая іншая крайнасць, у параўнанні з раней якая выкарыстоўвалася Icinga. У ёй даданне метрык дастаўляла адмысловы боль: наяўныя даставаліся дорага (досыць паглядзець на зыходнікі любога плагіна). Любая ўбудова ўяўляла сабою скрыпт на Bash ці Python, запуск якіх нятанны з пункта гледжання спажываных рэсурсаў.
- Гэтая сістэма спажывае адносна невялікая колькасць рэсурсаў. На ўсе нашы метрыкі хапае 600 Мб аператыўнай памяці, 15% аднаго ядра і пары дзясяткаў IOPS. Вядома, даводзіцца запускаць экспарцёры метрык, але ўсе яны напісаны на Go і таксама не адрозніваюцца пражэрлівасцю. Ня думаю, што ў сучасных рэаліях гэта праблема.
- Дае магчымасць пераходу ў Kubernetes. Улічваючы планы заказчыка - выбар відавочны.
ELK
Раней мы логі не збіралі і не апрацоўвалі. Недахопы ясныя ўсім. Мы абралі ELK, паколькі досвед працы з гэтай сістэмай у нас ужо быў. Захоўваем тамака толькі логі прыкладанняў. Асноўнымі крытэрыямі выбару сталі паўнатэкставы пошук і яго хуткасць.
Сlickhouse
Першапачаткова выбар упаў на InfluxDB. Мы ўсведамлялі неабходнасць збору логаў Nginx, статыстыкі з pg_stat_statements, захоўванні гістарычных дадзеных Prometheus. Influx нам не спадабаўся, бо ён перыядычна пачынаў спажываць вялікую колькасць памяці і падаў. Акрамя таго, хацелася групаваць запыты па remote_addr, а групоўка ў гэтай СКБД толькі па тэгах. Тэгі дарогі (памяць), іх колькасць умоўна абмежавана.
Мы пачалі пошукі нанова. Патрэбна была аналітычная база з мінімальным спажываннем рэсурсаў, пажадана са сціскам дадзеных на дыску.
Clickhouse задавальняе ўсім гэтым крытэрам, і аб выбары мы ні разу не пашкадавалі. Мы не пішам у яго нейкіх выбітных аб'ёмаў дадзеных (колькасць уставак усяго каля пяці тысяч у хвіліну).
NewRelic
NewRelic гістарычна быў з намі, бо гэта быў выбар замоўца. У нас ён выкарыстоўваецца ў якасці APM.
Zabbix
Мы выкарыстоўваем Zabbix выключна для маніторынгу Black Box розных API.
Вызначэнне падыходу да маніторынгу
Нам хацелася дэкампазіраваць задачу і тым самым сістэматызаваць падыход да маніторынгу.
Для гэтага я падзяліў нашу сістэму на наступныя ўзроўні:
- "жалеза" і VMS;
- аперацыйная сістэма;
- сістэмныя сэрвісы, стэк ПЗ;
- дадатак;
- бізнес-логіка.
Чым зручны такі падыход:
- мы ведаем, хто адказны за працу кожнага з узроўняў і, зыходзячы з гэтага, можам высылаць алертаў;
- мы можам выкарыстоўваць структуру пры падаўленні алертаў - было б дзіўна адсылаць алерт аб недаступнасці базы дадзеных, калі ў цэлым віртуальная машына недаступная.
Бо наша задача выяўляць парушэнні ў працы сістэмы, мы павінны на кожным узроўні вылучыць нейкі набор метрык, на якія варта зважаць пры напісанні правіл алертынгу. Далей пройдземся па ўзроўнях "VMS", "Аперацыйная сістэма" і "Сістэмныя сэрвісы, стэк ПЗ".
Віртуальныя машыны
Хостынг вылучае нам працэсар, дыск, памяць і сетку. І з першымі двума ў нас былі праблемы. Такім чынам, метрыкі:
CPU stolen time – калі вы купляеце віртуалку на Amazon (t2.micro, да прыкладу), варта разумець, што вам вылучаецца не цэлае ядро працэсара, а толькі квота яго часу. І калі вы яе вычарпаеце, працэсар у вас пачнуць забіраць.
Гэтая метрыка дазваляе адсочваць такія моманты і прымаць рашэнні. Напрыклад, ці трэба ўзяць тарыф таўсцейшы або разнесці апрацоўку фонавых задач і запытаў у API на розныя сервера.
IOPS + CPU iowait time – чамусьці многія хмарныя хостынгі грашаць тым, што недадаюць IOPS. Больш за тое, графік з нізкімі IOPS для іх не аргумент. Таму трэба збіраць і CPU iowait. З гэтай парай графікаў – з нізкімі IOPS і высокім чаканнем уводу-вываду – ужо можна размаўляць з хостынгам і вырашаць праблему.
Аперацыйная сістэма
Метрыкі аперацыйнай сістэмы:
- колькасць даступнай памяці ў%;
- актыўнасць выкарыстання swap: vmstat swapin, swapout;
- колькасць даступных inode і вольнага месца на файлавай сістэме ў %
- сярэдняя загрузка;
- колькасць злучэнняў у стане tw;
- запоўненасць табліцы conntrack;
- якасць працы сеткі можна маніторыць з дапамогай утыліты ss, пакетам iproute2 - атрымліваць з яе вываду паказчык RTT-злучэнняў і групаваць па dest-порту.
Таксама на ўзроўні аперацыйнай сістэмы ў нас узнікае такая сутнасць, як працэсы. Важна вылучыць у сістэме набор працэсаў, якія гуляюць важную ролю ў яе працы. Калі, да прыкладу, у вас есць некалькі pgpool, то неабходна збіраць інфармацыю па кожным з іх.
Набор метрык наступны:
- ЦЭНТРАЛЬНЫ ПРАЦЭСАР;
- памяць - у першую чаргу, рэзідэнтная;
- IO - пажадана ў IOPS;
- FileFd - адкрытыя і ліміт;
- істотныя адмовы старонкі - так вы зможаце зразумець, які працэс свапаецца.
Увесь маніторынг у нас разгорнуты ў Docker, для збору дадзеных метрык мы выкарыстоўваем Сadvisor. На астатніх машынах ужывальны process-exporter.
Сістэмныя сэрвісы, стэк ПЗ
У кожнага дадатку ёсць свая спецыфіка, і складана вылучыць нейкі набор метрык.
Універсальным наборам з'яўляюцца:
- рэйт запытаў;
- колькасць памылак;
- латэнтнасць;
- насычэнне.
Найбольш яркія прыклады маніторынгу дадзенага ўзроўню ў нас – Nginx і PostgreSQL.
Самы нагружаны сэрвіс у нашай сістэме - база дадзеных. Раней у нас дастаткова часта ўзнікалі праблемы з тым, каб высветліць, чым займаецца база даных.
Мы бачылі высокую нагрузку на дыскі, але слоулоги нічога толкам не паказвалі. Гэтую праблему мы вырашылі з дапамогай pg_stat_statements, уяўленні, у якім збіраецца статыстыка па запытах.
Гэта ўсё, што патрэбна адміну.
Які будуецца графікі актыўнасці запытаў на чытанне і запіс:
Усё проста і зразумела, кожнаму запыту - свой колер.
Не менш яркі прыклад – Nginx-лагі. Не дзіўна, што мала хто іх парсіць ці ўзгадвае ў спісе абавязковых. Стандартны фармат не вельмі інфарматыўны і яго трэба пашыраць.
Асабіста я дадаў request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Будуем графікі часу адказу і колькасці памылак:
Які будуецца графікі часу адказу і колькасці памылак. Памятаеце? я казаў пра задачы бізнэсу? Каб хутка і без памылак? Мы ўжо двума графікамі гэтыя пытанні закрылі. І па іх ужо можна тэлефанаваць дзяжурным адмінам.
Але засталася яшчэ адна праблема - забяспечыць хуткае ліквідацыю прычын інцыдэнту.
Устараненне інцыдэнтаў
Увесь працэс ад выяўлення да рашэння праблемы можна разбіць на шэраг крокаў:
- выяўленне праблемы;
- апавяшчэнне дзяжурнага адміністратара;
- рэакцыя на інцыдэнт;
- ухіленне прычын.
Важна, што мы мусім гэта рабіць максімальна хутка. І калі на этапах выяўлення праблемы і адпраўкі апавяшчэння мы асабліва часу выйграць не можам - дзве хвіліны на іх сыдуць у любым выпадку, то наступныя - проста неаранае поле для паляпшэнняў.
Давайце проста ўявім, што ў дзяжурнага зазваніў тэлефон. Што ён будзе рабіць? Шукаць адказы на пытанні - што зламалася, дзе зламалася, як рэагаваць? Вось якім чынам мы адказваем на гэтыя пытанні:
Мы проста ўключаем усю гэтую інфармацыю ў тэкст апавяшчэння, даем у ім спасылку на старонку ў вікі, дзе апісана, як на гэтую праблему рэагаваць, як яе вырашаць і эскалаваць.
Я да гэтага часу нічога не сказаў пра ўзровень прыкладання і бізнес логікі. Нажаль, у нашых прыкладаннях пакуль не рэалізаваны збор метрык. Адзіная крыніца любой інфармацыі з гэтых узроўняў - логі.
Пары момантаў.
Па-першае, пішыце структураваныя логі. Не трэба ўключаць кантэкст у тэкст паведамлення. Гэта ўскладняе іх групоўку і аналіз. Logstash патрабуе шмат часу, каб усё гэта нармалізаваць.
Па-другое, правільна выкарыстоўвайце severity-ўзроўні. У кожнай мовы свой стандарт. Асабіста я вылучаю чатыры ўзроўні:
- памылкі няма;
- памылка на баку кліента;
- памылка на нашым баку, не губляем грошай, не нясем рызыкі;
- памылка на нашым баку, губляем грошы.
Рэзюмую. Трэба імкнуцца выбудоўваць маніторынг менавіта ад бізнэс-логікі. Імкнуцца заманіторыць само прыкладанне і апераваць ужо такімі метрыкамі, як колькасць продажаў, колькасць новых рэгістрацый карыстальнікаў, колькасць актыўных у дадзены момант карыстальнікаў і гэтак далей.
Калі ўвесь ваш бізнэс - адна кнопка ў браўзэры, неабходна маніторыць, ці праціскаецца яна, ці працуе належным чынам. Усё астатняе не важна.
Калі ў вас гэтага няма, вы можаце паспрабаваць гэта нагнаць у логах прыкладання, Nginx-логах і гэтак далей, як гэта зрабілі мы. Вы павінны быць як мага бліжэй да дадатку.
Метрыкі аперацыйнай сістэмы вядома ж важныя, але бізнэсу яны не цікавыя, нам плацяць не за іх.
Крыніца: habr.com