🥇Маніторынг мёртвы? - Няхай жыве маніторынг

Наша кампанія з 2008 года займаецца пераважна кіраваннем інфраструктурамі і кругласутачнай тэхнічнай падтрымкай вэб-праектаў: у нас больш за 400 кліентаў, гэта каля 15% электроннай камерцыі Расіі. Адпаведна, на падтрымцы вельмі разнастайная архітэктура. Калі нешта падае, мы абавязаны на працягу 15 хвілін гэта паправіць. Але каб зразумець, што аварыя здарылася, трэба маніторыць праект і рэагаваць на інцыдэнты. А як гэта рабіць?

Я лічу, што ў арганізацыі правільнай сыстэмы маніторынгу адбываецца бяда. Калі б бяды не было, то мой спіч складаўся з адной тэзы: «Усталюйце, калі ласка, Prometheus + Grafana і плагіны 1, 2, 3». Нажаль, зараз так не працуе. І галоўная праблема ў тым, што ўсе працягваюць верыць у нешта такое, што існавала ў 2008 годзе, з пункту гледжання праграмных кампанентаў.

У стаўленні арганізацыі сістэмы маніторынгу я рызыкну сказаць, што… праектаў з пісьменным маніторынгам не існуе. І сітуацыя настолькі дрэнная, калі нешта ўпадзе, ёсць рызыка, што гэта застанецца незаўважаным - усё ж упэўненыя, што «ўсё маніторыцца».
Магчыма, усё маніторыцца. Але як?

Усе мы сутыкаліся з гісторыяй накшталт наступнай: працуе нейкі дэвопс, нейкі адмін, да іх прыходзіць каманда распрацоўшчыкаў і кажа - "мы зарэлізіліся, зараз заманітор". Што заманітор? Як гэта працуе?

Ок. Маніторым па даўніне. А яно ўжо змяняецца, і высвятляецца, што ты маніторыў сэрвіс А, які стаў сэрвісам B, які ўзаемадзейнічае з сэрвісам C. Але каманда распрацоўшчыкаў табе кажа: "Пастаў софт, ён жа павінен усё заманіторыць!"

Дык што змянілася? - Усё змянілася!

2008 год. Ўсё выдатна

Ёсць пара распрацоўшчыкаў, адзін сервер, адзін сервер БД. Адсюль усё і ідзе. У нас ёсць нейкая інфармацыя, мы ставім zabbix, Nagios, cacti. І далей выстаўляем зразумелыя алерты на ЦПУ, на працу дыскаў, на месца на дысках. Яшчэ робім пару ручных праверак, што сайт адказвае, што замовы ў базу прыходзяць. І ўсё - мы больш-менш абаронены.

Калі параўноўваць аб'ём працы, якую тады рабіў адмін для забеспячэння маніторынгу, то на 98% яна была аўтаматычнай: чалавек, які займаецца маніторынгам, павінен зразумець, як паставіць Zabbix, як яго наладзіць і настроіць алерты. І 2% - на знешнія праверкі: што сайт адказвае і робіць запыт у базу, што новыя заказы прыйшлі.

2010 год. Расце нагрузка

Мы пачынаем скейліць вэбы, дадаем пошукавы рухавічок. Мы хочам быць упэўнены, што каталог тавараў змяшчае ўсе тавары. І што пошук тавараў працуе. Што база працуе, што замовы робяцца, што сайт адказвае знешне і адказвае з двух сервераў і карыстальніка не выкідвае з сайта, пакуль ён перабалансуецца на іншы сервер, і г.д. Сутнасцяў становіцца больш.

Прычым сутнасць, звязаная з інфраструктурай, па-ранейшаму застаецца самай вялікай у галаве мэнэджара. Па-ранейшаму ў галаве сядзіць ідэя, што чалавек, які займаецца маніторынгам, - гэта чалавек, які паставіць zabbix і зможа яго канфігураваць.

Але пры гэтым з'яўляюцца працы па правядзенні знешніх праверак, па стварэнні набору скрыптоў запытаў індэксатара пошуку, набору скрыптоў для праверкі таго, што пошук мяняецца ў працэсе індэксацыі, набору скрыптоў, якія правяраюць, што службе дастаўцы перадаюцца тавары, і г.д. і да т.п.

Заўважце: я 3 разы напісаў "набор скрыптоў". Гэта значыць адказны за маніторынг - больш не той, хто проста ўсталёўвае zabbix. Гэта чалавек, які пачынае кадзіць. Але ў галовах у каманды пакуль нічога не мяняецца.

Затое мяняецца свет, ускладняючыся ўсё больш. Дадаюцца пласт віртуалізацыі, некалькі новых сістэм. Яны пачынаюць узаемадзейнічаць паміж сабой. Хто сказаў «пахвае мікрасэрвісамі?» Але кожны сэрвіс усё яшчэ паасобку выглядае як сайт. Мы можам да яго звярнуцца і зразумець, што ён выдае неабходную інфармацыю і сам па сабе працуе. І калі ты адмін, які пастаянна займаецца праектам, які развіваецца 5-7-10 гадоў, у цябе гэтыя веды назапашваюцца: з'яўляецца новы ўзровень - ты яго ўсвядоміў, з'яўляецца яшчэ адзін узровень - ты яго ўсвядоміў…

Але рэдка хто суправаджае праект 10 год.

Рэзюмэ маніторынгмэна

Выкажам здагадку, вы дашлі ў новы стартап, які адразу набраў 20 распрацоўнікаў, напісаў 15 мікрасэрвісаў, а вы — адмін, якому кажуць: «Пабудуй CI/CD. Калі аалуйста». Вы пабудавалі CI/CD і раптам чуеце: «Нам складана працаваць з прадакшнам у «кубіку», не разумеючы, як у ім будзе працаваць прыкладанне. Зрабі нам пясочніцу ў гэтым жа "кубіку".
Вы робіце пясочніцу ў гэтым кубіку. Вам тут жа кажуць: «Мы хочам stage базу дадзеных, якая абнаўляецца кожны дзень з прадакшна, каб разумець, што гэта працуе на базе дадзеных, але пры гэтым не сапсаваць прадакшн базу дадзеных».

Вы ў гэтым усім жывяце. Застаецца 2 тыдні да рэлізу, вам кажуць: "Цяпер бы гэта ўсё заманіторыць…" Г.зн. заманіторыць кластарную інфраструктуру, заманіторыць мікрасэрвісную архітэктуру, заманіторыць працу са знешнімі сэрвісамі…

А калегі дастаюць такія з галавы звыклую схему і гавораць: «Дык тут жа ўсё зразумела! Пастаў праграму, якая гэта ўсё заманіторыць». Так-так: Prometheus + Grafana + убудовы.
І дадаюць пры гэтым: "У цябе тыдні два, зрабі так, каб усё было надзейна".

У кучы праектаў, якія мы бачым, на маніторынг выдзяляюць аднаго чалавека. Прадстаўце, што мы жадаем на 2 тыдні наняць чалавека, які зоймецца маніторынгам, і мы складаем яму рэзюмэ. Якімі навыкамі павінен валодаць гэты чалавек - калі ўлічваць усё сказанае намі раней?

Ён мусіць разумець маніторынг і спецыфіку працы жалезнай інфраструктуры.
Ён павінен разумець спецыфіку маніторынгу Kubernetes (а ўсе хочуць у «кубік», таму што можна абстрагавацца ад усяго, схавацца, бо з астатнім разбярэцца адмін) – самога па сабе, яго інфраструктуры, і разумець, як маніторыць прыкладанні ўнутры.
Ён павінен разумець, што сэрвісы паміж сабой маюць зносіны адмысловымі спосабамі, і шляхта спецыфікі ўзаемадзеяння сэрвісаў паміж сабой. Суцэль рэальна ўбачыць праект, дзе частка сэрвісаў маюць зносіны сінхронна, таму што па-іншаму ніяк. Напрыклад, backend ідзе па REST, па gRPC да сэрвісу каталога, атрымлівае спіс тавараў і вяртае зваротна. Тут нельга чакаць. А з іншымі сэрвісамі ён працуе асінхронна. Перадаць замову ў службу дастаўкі, адправіць ліст і да т.п.
Вы, мусіць, ужо паплылі ад усяго гэтага? А адмін, якому трэба гэта маніторыць, паплыў яшчэ болей.
Ён павінен умець планаваць і планаваць правільна - паколькі працы становіцца ўсё больш і больш.
Ён павінен, такім чынам, стварыць стратэгію са створанага сэрвісу каб зразумець, як гэта канкрэтна заманіторыць. Яму трэба разуменне архітэктуры праекта і яго развіцця + разуменне тэхналогій, якія выкарыстоўваюцца ў распрацоўцы.

Успомнім абсалютна нармальны кейс: частка сэрвісаў на php, частка сэрвісаў на Go, частка сэрвісаў на JS. Яны неяк паміж сабой працуюць. Адсюль і ўзяўся тэрмін «мікрасэрвіс»: асобных сістэм стала так шмат, што распрацоўшчыкі не могуць зразумець праект у цэлым. Адна частка каманды піша сервісы на JS, якія працуюць самі па сабе і не ведаюць, як працуе астатняя сістэма. Іншая частка піша сэрвісы на Python і не лезе ў тое, як працуюць іншыя сэрвісы, яны ізаляваныя ў сваёй вобласці. Трэцяя - піша сэрвісы на php ці нечым яшчэ.
Усе гэтыя 20 чалавек падзелены на 15 сервісаў, і ёсць толькі адзін адмін, які павінен усё гэта зразумець. Стоп! мы толькі што разбілі сістэму на 15 мікрасэрвісаў, бо 20 чалавек усю сістэму зразумець не могуць.

Затое яе трэба неяк заманіторыць…

Што ў выніку? У выніку ёсць адзін чалавек, якому ў галаву ўваходзіць усё, што не можа зразумець цэлая каманда распрацоўшчыкаў, і пры гэтым ён яшчэ павінен ведаць і ўмець тое, што мы паказалі вышэй - жалезную інфраструктуру, інфраструктуру Kubernetes і г.д.

Што тут сказаць… Х'юстан, у нас праблемы.

Маніторынг сучаснага праграмнага праекта - гэта сам па сабе праграмны праект

З ілжывай упэўненасці, што маніторынг - гэта софт, у нас з'яўляецца вера ў цуды. А цудаў, нажаль, не бывае. Нельга паставіць zabbix і чакаць, што ўсё заробіць. Няма сэнсу паставіць Grafana і спадзявацца, што ўсё будзе ок. Большая частка часу пойдзе на арганізацыю праверак працы сэрвісаў і іх узаемадзеянні паміж сабой, праверак, як працуюць вонкавыя сістэмы. Фактычна 90% часу спатрэбіцца не на напісанне скрыптоў, а на распрацоўку праграмнага забеспячэння. І займацца ёю павінна каманда, якая разумее працу праекту.
Калі ў гэтай сітуацыі аднаго чалавека кінуць на маніторынг, то здарыцца бяда. Што і адбываецца паўсюдна.

Напрыклад, ёсць некалькі сэрвісаў, якія маюць зносіны паміж сабой праз Kafka. Прыйшоў заказ, мы паведамленне аб замове адправілі ў Kafka. Ёсць сэрвіс, які слухае інфармацыю аб замове і праводзіць адгрузку тавара. Ёсць сэрвіс, які слухае інфармацыю аб замове і дасылае ліст карыстачу. А затым з'яўляецца яшчэ куча сэрвісаў, і мы пачынаем блытацца.

А калі вы яшчэ аддасце гэта адміну і распрацоўшчыкам на этапе, калі да рэлізу застаўся кароткі час, чалавеку трэба будзе зразумець увесь гэты пратакол. Г.зн. праект падобнага маштабу займае значны час, і ў распрацоўцы сістэмы гэта мусіць быць закладзена.
Але вельмі часта, асабліва ў гарэнні, у стартапах, мы бачым, як маніторынг адкладаюць на потым. «Цяпер мы зробім Proof of Concept, з ім запусцімся, няхай ён падае - мы гатовыя ахвяраваць. А потым мы ўсё гэта заманіторым». Калі (ці калі) праект пачынае прыносіць грошы, бізнэс хоча пілаваць яшчэ больш фіч - таму што яно ж пачало працаваць, значыць трэба накручваць далей! А вы знаходзіцеся ў кропцы, дзе спачатку трэба заманіторыць усё папярэдняе, што займае не 1% часу, а значна болей. І дарэчы для маніторынгу патрэбны будуць распрацоўшчыкі, а іх прасцей пусціць на новыя фічы. У выніку пішуцца новыя фічы, усё накручваецца, і вы ў бясконцым deadlock.

Дык як жа заманіторыць праект, пачынаючы з пачатку, і што рабіць, калі вам дастаўся праект, які трэба заманіторыць, а вы не ведаеце, з чаго пачынаць?

Па-першае, трэба плянаваць.

Лірычны адступ: вельмі часта пачынаюць з маніторынгу інфраструктуры. Напрыклад, у нас Kubernetes. Пачнём з таго, што паставім Prometheus з Grafana, паставім убудовы пад маніторынг кубіка . Не толькі ў распрацоўнікаў, але і ў адмінаў ёсць сумная практыка: «Мы паставім вось гэты плягін, а плягін напэўна ведае як гэта зрабіць». Людзі любяць пачынаць з простых і зразумелых, а не з важных дзеянняў. І маніторынг інфраструктуры - гэта проста.

Для пачатку вырашыце, што і як жадаеце заманіторыць, а потым падбірайце прыладу, таму што іншыя людзі не могуць за вас падумаць. Ды і ці павінны? Іншыя людзі думалі пра сябе, пра ўніверсальную сістэму — ці ўвогуле не думалі, калі гэтую ўбудову пісалі. І тое, што ў гэтага плагіна 5 тысяч карыстальнікаў, не азначае, што ён нясе нейкую карысць. Магчыма, вы станеце 5001 проста таму, што там да гэтага ўжо было 5000 чалавек.

Калі вы пачалі маніторыць інфраструктуру і backend вашага прыкладання перастаў адказваць, усе карыстальнікі страцяць сувязь з мабільным дадаткам. Выляціць памылачка. Да вас прыйдуць і скажуць "Дадатак не працуе, чым вы тут займаецеся?" - "Мы маніторым". - "Як вы маніторыце, калі не бачыце, што прыкладанне не працуе?!"

Я лічу, што пачынаць маніторыць трэба менавіта з кропкі ўваходу карыстальніка. Калі карыстач не бачыць, што прыкладанне працуе – усё, гэта правал. І сістэма маніторынгу павінна папярэдзіць пра гэта найперш.
І толькі потым мы можам заманіторыць інфраструктуру. Або зрабіць гэта паралельна. З інфраструктурай прасцей – тут мы можам проста паставіць zabbix.
І зараз трэба ісці ў карані прыкладання, каб зразумець, дзе што не працуе.

Галоўная мая думка - маніторынг павінен ісці паралельна з працэсам распрацоўкі. Калі вы адарвалі каманду маніторынгу на іншыя задачы (стварэнне CI/CD, пясочніцы, рэарганізацыю інфраструктуры), маніторынг пачне адставаць і вы, магчыма, ужо ніколі не дагоніце распрацоўку (альбо рана ці позна давядзецца яе спыніць).

Усё па ўзроўнях

Вось як я бачу арганізацыю сістэмы маніторынгу.

1) Узровень прыкладання:

маніторынг бізнес-логіку прыкладання;
маніторынг health-метрыкі сэрвісаў;
інтэграцыйны маніторынг.

2) Узровень інфраструктуры:

маніторынг узроўню аркестрацыі;
маніторынг сістэмнага ПЗ;
маніторынг ўзроўню "жалеза".

3) Ізноў узровень прыкладання - але ўжо як інжынернага прадукта:

збор і назіранне часопісаў прыкладання;
APM;
tracing.

4) Алертынг:

арганізацыя сістэмы абвесткі;
арганізацыя сістэмы дзяжурстваў;
арганізацыя "базы ведаў" і workflow апрацоўкі інцыдэнтаў.

Важна: мы даходзім да алертынга не пасля, а адразу! Не трэба запускаць маніторынг і "як-небудзь потым" прыдумляць, каму будуць прыходзіць алерты. Бо ў чым задача маніторынгу: зразумець, дзе ў сістэме нешта працуе не так, і даць пра гэта ведаць патрэбным людзям. Калі гэта пакінуць на канец, то патрэбныя людзі даведаюцца аб тым, што нешта ідзе не так, толькі па званку "у нас нішто не працуе".

Узровень прыкладання - маніторынг бізнес-логікі

Тут гаворка ідзе аб праверках самога факту таго, што прыкладанне працуе для карыстальніка.

Гэты ўзровень павінен быць зроблены на этапе распрацоўкі. Напрыклад, у нас ёсць умоўны Prometheus: ён лезе да сервера, які займаецца праверкамі, тузае endpoint, і endpoint ідзе і правярае API.

Калі часта просяць заманіторыць галоўную старонку каб упэўніцца, што сайт працуе, праграмісты даюць ручку, якую можна тузаць кожны раз, калі трэба пераканацца, што API працуе. А праграмісты ў гэты момант яшчэ бяруць і пішуць /api/test/helloworld
Адзіны спосаб пераканацца, што ўсё працуе? - Не!

Стварэнне такіх праверак - па сутнасці, задача распрацоўшчыкаў. Unit-тэсты павінны пісаць праграмісты, якія пішуць код. Таму што, калі вы зліяце гэта на адміна «Чувак, вось табе спіс пратаколаў API усіх 25 функцый, калі ласка, заманітор усё!» - нічога не атрымаецца.
Калі вы зробіце print "hello world", ніхто не даведаецца ніколі аб тым, што API павінен і сапраўды працуе. Кожная змена API павінна весці за сабой змена праверак.
Калі ў вас ужо такая бяда - спыніце фічы і вылучыце распрацоўшчыкаў, якія напішуць гэтыя праверкі, або змірыцеся са стратамі, змірыцеся, што нічога не правяраецца і будзе падаць.

Тэхнічныя парады:

Абавязкова арганізуйце вонкавы сервер для арганізацыі праверак - вы павінны быць упэўненыя, што ваш праект даступны для навакольнага свету.
Арганізуйце праверку па ўсім пратаколе API, а не толькі па асобных endpoint-ах.
Стварыце prometheus-endpoint з вынікамі праверак.

Узровень прыкладання - маніторынг health-метрык

Цяпер гаворка ідзе аб знешніх health-метрыках сэрвісаў.

Мы вырашылі, што ўсе "ручкі" прыкладанні маніторым з дапамогай знешніх праверак, якія мы выклікаем з знешняй сістэмы маніторынгу. Але гэта менавіта "ручкі", якія "бачыць" карыстач. Мы ж хочам быць упэўнены, што ў нас працуюць самі сервісы. Тут гісторыя лепей: у K8s ёсць health-чэкі, каб хаця б сам «кубік» пераконваўся, што сэрвіс працуе. Але палова чэкаў, якія я бачыў, — гэта той самы print “hello world”. Г.зн. вось ён тузае адзін раз пасля дэплою, яму той адказаў, што ўсё добра - і ўсё. А ў сэрвісу, калі ён rest-ом выдае свой API, ёсць велізарная колькасць кропак уваходу таго самага API, які таксама трэба маніторыць, таму што мы жадаем ведаць, што ён працуе. І мы яго маніторым ужо ўнутры.

Як гэта правільна рэалізаваць тэхнічна: кожны сэрвіс выстаўляе endpoint аб сваёй бягучай працаздольнасці, а ў графіках Grafana (ці любога іншага прыкладання) мы бачым статут усіх сэрвісаў.

Кожная змена API павінна весці за сабой змена праверак.
Новы сэрвіс стварайце адразу з health-метрыкамі.
Адмін можа прыйсці да распрацоўшчыкаў і папрасіць "дапішыце мне пару фіч, каб я ўсё разумеў і ў сваю сістэму маніторынгу дадаў інфармацыю аб гэтым". Але распрацоўшчыкі звычайна адказваюць "За два тыдні да рэлізу мы нічога дапісваць не будзем".
Хай менеджэры распрацоўкі ведаюць, што будуць такія страты, няхай начальства менеджэраў распрацоўкі таксама ведае. Таму што, калі ўсё ўпадзе, хтосьці ўсё роўна патэлефануе і запатрабуе заманіторыць «пастаянна-падальны сэрвіс» (з)
Дарэчы, вылучыце распрацоўшчыкаў на напісанне плагінаў для Grafana-гэта будзе добрая дапамога для адмінаў.

Узровень прыкладання - Інтэграцыйны маніторынг

Інтэграцыйны маніторынг факусуюць на маніторынгу камунікацыі паміж крытычнымі для бізнесу сістэмамі.

Напрыклад, ёсць 15 сэрвісаў, якія камуніцыруюць паміж сабой. Гэта больш не асобныя сайты. Г.зн. мы не можам тузануць сэрвіс сам па сабе, атрымаць /helloworld і зразумець, што сэрвіс працуе. Таму што вэб-сэрвіс афармлення замовы павінен адправіць інфармацыю аб замове ў шыну - з шыны служба працы са складам павінна атрымаць гэтае паведамленне і працаваць з ім далей. А служба рассылання e-mail-аў павінна апрацаваць гэта неяк далей, і т.д.

Адпаведна, мы не можам зразумець, тыкаючыся ў кожны асобны сэрвіс, што гэта ўсё працуе. Таму што ў нас ёсць нейкая шына, праз якую ўсё мае зносіны і ўзаемадзейнічае.
Таму гэты этап павінен абазначаць сабой этап тэсціравання сэрвісаў па ўзаемадзеянні з іншымі сэрвісамі. Нельга, заманіторыўшы брокер паведамленняў, арганізаваць маніторынг камунікацыі. Калі ёсць сэрвіс, які выдае дадзеныя, і сэрвіс, які іх прымае, пры маніторынгу брокера мы ўбачым толькі дадзеныя, якія лётаюць з боку ў бок. Калі нават мы неяк прымудрыліся заманіторыць узаемадзеянне гэтых дадзеных унутры - што нейкі прадзюсар посціць дадзеныя, хтосьці іх чытае, гэты струмень працягвае ісці ў Kafka- гэта ўсё роўна не дасць нам інфармацыю, калі адзін сэрвіс аддаў паведамленне ў адной версіі, а іншы сэрвіс не чакаў гэтай версіі і прапусціў яго. Мы пра гэта не даведаемся, бо нам сэрвісы скажуць, што ўсё працуе.

Як я рэкамендую рабіць:

Для сінхроннай камунікацыі: endpoint выконвае запыты да злучаных сэрвісаў. Г.зн. мы бярэм гэты endpoint, тузаем скрыптык усярэдзіне сэрвісу, які ідзе па ўсіх кропках і кажа «я магу там тузануць, і там тузануць, магу там тузануць…»
Для асінхроннай камунікацыі: уваходныя паведамленні - endpoint правярае шыну на наяўнасць тэставых паведамленняў і выдае статут апрацоўкі.
Для асінхроннай камунікацыі: выходныя паведамленні - endpoint адпраўляе на шыну тэставыя паведамленні.

Як звычайна адбываецца: у нас ёсць сэрвіс, які кідае дадзеныя ў шыну. Мы прыходзім у гэты сэрвіс і просім расказаць пра яго інтэграцыйнае здароўе. І калі сэрвіс павінен запрадзюсіць нейкае паведамленне кудысьці далей (WebApp), то ён гэтае тэставае паведамленне прад'юсіць. А калі мы тузаем сэрвіс на баку OrderProcessing, ён спачатку посціць тое, што ён можа запосціць незалежнае, а калі ёсць нейкія залежныя штукі – то ён чытае з шыны набор тэставых паведамленняў, разумее, што ён можа апрацаваць іх, паведаміць пра гэта і , калі трэба, пасціць іх далей, і пра гэта ён кажа - усё ок, я жывы.

Вельмі часта мы чуем пытанне "як мы можам гэта тэсціраваць на баявых дадзеных?" Напрыклад, гаворка ідзе пра тую ж службу заказаў. Заказ адпраўляе паведамленні ў склад, дзе спісваюцца тавары: мы ж не можам пратэставаць гэта на баявых дадзеных, таму што "ў мяне тавары будуць спісвацца!" Вынахад: на пачатковым этапе запланаваць увесь гэты тэст. У вас жа ёсць unit-тэсты, якія робяць mock-і. Дык вось, зрабіце гэта на глыбейшым узроўні, дзе ў вас будзе праходзіць канал камунікацыі, які не пашкодзіць працы бізнэсу.

Узровень інфраструктуры

Маніторынг інфраструктуры - тое, што даўно лічыцца самім маніторынгам.

Маніторынг інфраструктуры можна і трэба запусціць як асобны працэс.
Не варта пачынаць з маніторынгу інфраструктуры на працуючым праекце, нават калі вельмі хочацца. Гэта болька для ўсіх дэвапсаў. "Спачатку заманіторы кластар, заманіторы інфраструктуру" - г.зн. спачатку заманіторыць тое, што ляжыць унізе, а ў дадатак не палезе. Таму што дадатак - незразумелая штука для дэвопсу. Яму гэта злілі, і ён не разумее, як гэта працуе. А інфраструктуру ён разумее і пачынае з яе. Але не - заўсёды спачатку трэба маніторыць прыкладанне.
Не перабераце з колькасцю абвестак. Улічваючы складанасць сучасных сістэм, алерты ляцяць увесь час, і з гэтай кучай алертаў трэба неяк жыць. І чалавек on-call, паглядзеўшы на сотню чарговых алертаў, вырашыць "не хачу пра гэта думаць". Алерты павінны апавяшчаць толькі пра крытычныя рэчы.

Узровень прыкладання як бізнес-адзінкі

Ключавыя моманты:

ELK. Гэта індустрыяльны стандарт. Калі па нейкай прычыне вы не агрэгуеце логі, тэрмінова пачніце гэта рабіць.
APM. Вонкавыя APM як спосаб хутка зачыніць маніторынг прыкладання (NewRelic, BlackFire, Datadog). Вы можаце часова паставіць гэтую штуку, каб хоць неяк зразумець, што ў вас адбываецца.
Tracing. У дзясятках мікрасэрвісаў вы павінны трэйсіць усё, таму што запыт ужо не жыве сам па сабе. Дапісаць пазней вельмі складана, таму лепш адразу запланаваць tracing у распрацоўцы - гэта праца і ўтыліта распрацоўшчыкаў. Калі яшчэ не ўкаранілі - укараняйце! Глядзіце Jaeger/Zipkin

Алертынг

Арганізацыя сістэмы абвестак: ва ўмовах маніторынгу кучы рэчаў павінна быць адзіная сістэма рассылання абвестак. Можна ў Grafana. На Захадзе ўсё выкарыстоўваюць PagerDuty. Абвесткі павінны быць зразумелымі (напрыклад, адкуль яны прыйшлі…). І пажадана кантраляваць, што абвесткі наогул даходзяць
Арганізацыя сістэмы дзяжурстваў: алерты не павінны прыходзіць усім (альбо будуць усё натоўпам рэагаваць, альбо ніхто не будзе рэагаваць). Oncall трэба быць і распрацоўшчыкам: абавязкова вызначыце зоны адказнасці, зрабіце дакладную інструкцыю і прапішыце ў ёй, каму канкрэтна тэлефанаваць у панядзелак і сераду, а каму - у аўторак і пятніцу (інакш не будуць нікому тэлефанаваць нават у выпадку вялікай бяды - пабаяцца абудзіць, патрывожыць : людзі ўвогуле не любяць тэлефанаваць і будзіць іншых людзей, асабліва ноччу). І растлумачце, што зварот за дапамогай - не паказчык некампетэнтнасці («я прашу дапамогі - значыць я дрэнны работнік»), заахвочвайце просьбы аб дапамозе.
Арганізацыя «базы ведаў» і workflow апрацоўкі інцыдэнтаў: па кожным сур'ёзным інцыдэнце павінен быць запланаваны постмортэм, у якасці часовай меры павінны быць зафіксаваны дзеянні, якія вырашаць інцыдэнт. І завядзіце практыку, што паўторныя алерты - гэта грэх; іх трэба фіксаваць у кодзе ці інфраструктурных працах.

Тэхналагічны стэк

Давайце ўявім, што стэк у нас наступны:

збор дадзеных - Prometheus + Grafana;
аналіз логаў - ELK;
для APM або Tracing - Jaeger (Zipkin).

Выбар варыянтаў некрытычны. Таму што, калі вы спачатку зразумелі, як заманіторыць сістэму і распісалі план, далей вы ўжо пачынаеце выбіраць інструментарый пад свае патрабаванні. Пытанне ў тым, што вы выбралі маніторыць спачатку. Таму што, магчыма, інструмент, які вы выбралі спачатку - ён наогул не падыходзіць пад вашыя патрабаванні.

Некалькі тэхнічных момантаў, якія я бачу ўсюды ў апошні час:

Prometheus пхаюць унутр Kubernetes - хто гэта прыдумаў?! Калі ў вас упадзе кластар, што вы будзеце рабіць? Калі ў вас складаны кластар ўнутры, то павінна працаваць нейкая сістэма маніторынгу ўнутры кластара, і нейкая - звонку, якая будзе збіраць дадзеныя знутры кластара.

Унутры кластара мы збіраем логі і ўсё астатняе. Але сістэма маніторынгу мусіць быць звонку. Вельмі часта ў кластары, дзе ёсць Promtheus, які паставілі ўнутр, там жа стаяць сістэмы, якія робяць вонкавыя праверкі працы сайта. А калі ў вас злучэнні ў знешні свет ўпалі і дадатак не працуе? Атрымліваецца, усярэдзіне ў вас усё добра, але карыстачам ад гэтага не лягчэй.

Высновы

Распрацоўка маніторынгу – не ўстаноўка ўтыліт, а распрацоўка праграмнага прадукта. 98% сённяшняга маніторынгу - гэта кодынг. Кодынг у сэрвісах, кодынг знешніх праверак, праверкі знешніх сэрвісаў, і ўсяго-усяго-усяго.
Не шкадуйце часу распрацоўшчыкаў на маніторынг: гэта можа заняць да 30% іх працы, але варта таго.
Дэвопсы, не хвалюйцеся, што ў вас не атрымліваецца нешта заманіторыць, таму што некаторыя рэчы - гэта наогул іншы склад розуму. Вы не былі праграмістам, а праца маніторынгу - менавіта іх праца.
Калі праект ужо працуе і не заманіторны (а вы менеджэр) - вылучыце рэсурсы на маніторынг.
Калі прадукт ужо ў прадакшне, а вы дэвопс, якому сказалі "наладзіць маніторынг" – паспрабуйце растлумачыць кіраўніцтву тое, пра што я ўсё гэта напісаў.

Гэта пашыраная версія даклада на канферэнцыі Saint Highload.

Калі вам цікавыя мае ідэі і разважанні на it і каля-таго-тэмы, то вось можна пачытаць канал ????

Крыніца: habr.com

Маніторынг мёртвы? - Няхай жыве маніторынг