Усіх з пятніцай! Сябры, сёння мы працягваем серыю публікацый прысвечаных курсу , таму як заняткі ў новай групе па курсе стартуюць ужо ў канцы наступнага тыдня. Такім чынам, пачнем!
Маніторынг - гэта проста. Гэта вядомы факт. Падніміце Nagios, запусціце NRPE на выдаленай сістэме, наладзьце Nagios на порт NRPE TCP 5666 і ў вас ёсць маніторынг.
Гэта так лёгка, што нецікава. Цяпер у вас ёсць асноўныя метрыкі па працэсарным часе, дыскавай падсістэме, аператыўнай памяці, якія паступаюць па змаўчанні ў Nagios і NRPE. Але насамрэч гэта не «маніторынг» як такой. Гэта толькі пачатак.
(Звычайна ставяць PNP4Nagios, RRDtool і Thruk, наладжваюць апавяшчэння ў Slack і ідуць прама на nagiosexchange, але пакуль што апусцім гэта).
Добры маніторынг на самой справе даволі складаны, вам сапраўды трэба ведаць вантробы прыкладання, за якім вы назіраеце.
Маніторынг - гэта складана?
Любы сервер, няхай гэта будзе Linux або Windows, па вызначэнні будзе служыць нейкай мэты. Apache, Samba, Tomcat, сховішча файлаў, LDAP – усе гэтыя сэрвісы больш-менш унікальныя ў адным ці некалькіх адносінах. У кожнага ёсць свая функцыя, свае асаблівасці. Ёсць розныя спосабы атрымання метрык, KPI (ключавых паказчыкаў эфектыўнасці), цікавых вам, калі сервер будзе пад нагрузкай.
Аўтар фота на
( хацелася б, каб мае дашборды былі афарбаваныя ў неонава-сінія колеры — летуценна ўздыхаючы —… хм…)
Любое праграмнае забеспячэнне, якое прадстаўляе паслугі, павінна мець механізм для збору метрык. У Apache ёсць модуль mod-status, які адлюстроўвае старонку стану сервера. У Nginx - stub_status. Tomcat мае JMX або спецыяльныя вэб-прыкладанні, якія паказваюць ключавыя метрыкі. У MySQL ёсць каманда "show global status" і т. д.
Дык чаму ж распрацоўшчыкі не ўбудоўваюць падобныя механізмы ў прыкладанні, якія яны ствараюць?
Ці толькі распрацоўшчыкі робяць гэта?
Пэўны ўзровень абыякавасці да ўбудавання метрык не абмяжоўваецца распрацоўшчыкамі. Я працаваў у кампаніях, дзе распрацоўвалі прыкладанні з выкарыстаннем Tomcat і не выдавалі ніякіх сваіх метрык, ніякіх логаў актыўнасці сэрвісу, акрамя агульных часопісаў памылак Tomcat. Некаторыя распрацоўнікі генеруюць багацце логаў, нічога не значных для сістэмнага адміністратара, якому не павезла іх чытаць у 3:15 раніцы.
Аўтар фота на
Сістэмныя інжынеры, якія дазваляюць такім прадуктам выходзіць у рэліз, таксама павінны несці пэўную адказнасць за сітуацыю. Нямногія сістэмныя інжынеры маюць час і клапоцяцца аб тым, каб паспрабаваць атрымаць значныя метрыкі з логаў, без кантэксту гэтых метрык і магчымасці інтэрпрэтаваць іх у святле актыўнасці прыкладання. Некаторыя не разумеюць, якую карысць яны могуць атрымаць ад гэтага, акрамя паказчыкаў тыпу "нешта ў цяперашні час (ці будзе хутка) не так".
Змена мыслення ў стаўленні неабходнасці метрык павінна адбывацца не толькі сярод распрацоўнікаў, але і сярод сістэмных інжынераў.
Для любога сістэмнага інжынера, якому неабходна не толькі рэагаваць на крытычныя падзеі, але і гарантаваць іх адсутнасць, адсутнасць метрык звычайна з'яўляецца перашкодай для гэтага.
Аднак сістэмныя інжынеры звычайна не капаюцца ў кодзе, зарабляючы грошы для сваёй кампаніі. Ім патрэбныя кіроўныя распрацоўнікі, якія разумеюць важнасць адказнасці сістэмнага інжынера ў выяўленні праблем, падвышэнні дасведчанасці аб праблемах прадукцыйнасці і таму падобным.
Гэтая devops штука
Менталітэт devops апісвае сінэргію мыслення распрацоўнікаў (dev) і эксплуатацыі (ops). Любая кампанія, якая заяўляе, што яны "робяць devops", павінна:
- казаць тое, што яны, верагодна, не робяць (намёк на мем з фільма «Прынцэса-Нявеста» - «Я не думаю, што гэта значыць тое, што ты думаеш, што гэта значыць!»)
- заахвочваць пазіцыю пастаяннага ўдасканалення прадукта.
Вы не можаце палепшыць прадукт і ведаць, што ён быў палепшаны, калі вы не ведаеце, як ён працуе ў цяперашні час. Вы не зможаце пазнаць, як працуе прадукт, калі не разумееце, як працуюць яго кампаненты, сэрвісы, ад якіх ён залежыць, яго асноўныя болевыя кропкі і вузкія месцы.
Калі вы не назіраеце за патэнцыйна вузкімі месцамі, вы не зможаце прытрымлівацца тэхніцы "Пяць чаму" пры напісанні Postmortem'а. Вы не зможаце сабраць усё на адным экране, каб убачыць, як працуе прадукт ці даведацца, як ён выглядае "нармальна і шчасліва".
Зрух налева, НАЛЕВА, Я СКАЗАЎ, ЛЕЯЕЕЯЕ-
Для мяне адным з ключавых прынцыпаў Devops з'яўляецца Зрух налева (shift left). Зрух налева ў гэтым кантэксце азначае зрушэнне магчымасці (не адказнасці, а толькі магчымасці) рабіць тое, пра што клапоцяцца звычайна сістэмныя інжынеры, напрыклад, ствараць метрыкі прадукцыйнасці, больш эфектыўна выкарыстоўваць логі і т. д., налева ў жыццёвым цыкле дастаўкі праграмнага забеспячэння (Software Delivery Life Cycle).
Аўтар фота на
Распрацоўнікі праграмнага забеспячэння павінны мець магчымасць выкарыстоўваць і ведаць сродкі маніторынгу, якія выкарыстоўвае кампанія, каб ажыццяўляць маніторынг ва ўсіх яго формах, метрыках, лагаванні, інтэрфейсах маніторынгу і, што самае важнае, назіраць як іх прадукт працуе ў прадакшэне. Вы не можаце wпрымусіць распрацоўшчыкаў ўкласці сілы і час у маніторынг, пакуль яны не змогуць бачыць метрыкі і ўплываць на тое, як яны выглядаюць, як уладальнік прадукта прадставіць іх CTO на наступным брыфінгу і г. д.
Карацей кажучы
- Прывядзіце каня да вады. Пакажыце распрацоўнікам колькі праблем яны змогуць пазбегнуць для сябе, дапамажыце ім вылучыць правільныя KPI і метрыкі для сваіх прыкладанняў, каб было менш крыку ад уладальніка прадукта, на якога крычыць тэхнічны дырэктар (CTO). Выведзіце іх на свет, мякка і спакойна. Калі гэта не атрымацца, то падкупіце, пагражайце і ўгаворвайце альбо іх, альбо ўладальніка прадукта, каб як мага хутчэй рэалізаваць атрыманне гэтых метрык з прыкладанняў, а затым намалюйце дыяграмы. Гэта будзе складана, паколькі гэта не будзе разглядацца ў якасці прыярытэту, і ў дарожнай карце прадукта будзе шмат якія чакаюць рэалізацыі праектаў, якія прыносяць прыбытак. Таму вам спатрэбіцца эканамічнае абгрунтаванне, каб апраўдаць час і сродкі, патрачаныя на ўкараненне маніторынгу ў прадукт.
- Дапамажыце сістэмным інжынерам выспацца. Пакажыце ім, што ўжыванне чэк-ліста «выпускаем рэліз» для любога які выпускаецца прадукта гэта добра. І праверка таго, што ўсе прыкладанні ў прадакшэне пакрыты метрыкамі, дапаможа дамагчыся здаровага сну па начах, дазваляючы распрацоўнікам бачыць, што і дзе працуе не так. Тым не менш, правільны спосаб раздражняць і хваляваць любога распрацоўніка, уладальніка прадукта і тэхнічнага дырэктара – гэта настойліва ўстаўляць палкі ў колы і супраціўляцца. Такія паводзіны паўплываюць на дату рэлізу любога прадукта, калі зноў чакаць да апошняй хвіліны, так што ізноў выканаеце зрух налева і як мага хутчэй уключыце гэтыя пытанні ў план праекту. Калі неабходна прабярыцеся на сустрэчы, прысвечаныя прадукту. Носіце падробленыя вусы і фетр ці нешта ў гэтым родзе, гэта ніколі не падвядзе. Паведаміце аб сваіх праблемах, пакажыце відавочныя перавагі і евангелізуйце.
- Пераканайцеся, што як распрацоўшчыкі (dev), так і эксплуатацыя (ops) разумеюць значэнне і наступства пераходу метрык прадукта ў "чырвоную зону". Не пакідайце эксплуатацыю ў якасці адзінага вартавога працаздольнасці прадукта, пераканаецеся, што распрацоўнікі таксама ўдзельнічаюць у гэтым (#productsquads).
- Логі - выдатная штука, але метрыкі таксама. Аб'яднайце іх і не дазваляйце вашым логам стаць смеццем у велізарным палаючым шары бескарыснасці. Растлумачце і пакажыце распрацоўшчыкам, чаму ніхто акрамя іх не разбярэцца ў іх логах, пакажыце ім, як гэта глядзець на бескарысныя логі ў 3:15 раніцы.
Аўтар фота на
На гэтым усё. Новы матэрыял выйдзе на наступным тыдні. Калі вы жадаеце падрабязней даведацца аб курсе, запрашаем на , які пройдзе ўжо ў панядзелак А зараз мы традыцыйна чакаем вашыя каментары.
Крыніца: habr.com