Мониторинг өлді ме? — Ұзақ уақыт бақылау

2008 жылдан бастап біздің компания негізінен инфрақұрылымды басқарумен және веб-жобаларға тәулік бойы техникалық қолдау көрсетумен айналысады: бізде 400-ден астам клиент бар, бұл ресейлік электрондық коммерцияның шамамен 15% құрайды. Тиісінше, өте әртүрлі архитектураға қолдау көрсетіледі. Бірдеңе құлап қалса, 15 минут ішінде жөндеуге міндеттіміз. Бірақ апат болғанын түсіну үшін жобаны бақылап, оқиғаларға жауап беру керек. Мұны қалай жасауға болады?

Тиісті мониторинг жүйесін ұйымдастыруда мәселе бар деп есептеймін. Егер ешқандай қиындық болмаса, менің сөзім бір тезистен тұрады: «Прометей + Grafana және 1, 2, 3 плагиндерін орнатыңыз». Өкінішке орай, ол енді осылай жұмыс істемейді. Ал басты мәселе, барлығы 2008 жылы бар нәрсеге, бағдарламалық жасақтаманың құрамдас бөліктеріне сенуді жалғастыруда.

Мониторинг жүйесін ұйымдастыруға қатысты айтарым... құзыретті мониторингі бар жобалар жоқ. Жағдайдың нашарлығы сонша, егер бірдеңе құлап кетсе, оның байқалмай қалу қаупі бар - бәрі де «бәрі бақыланатынына» сенімді.
Бәлкім, бәрі бақыланып жатқан шығар. Бірақ қалай?

Біз бәріміз келесідей оқиғаға тап болдық: белгілі бір әзірлеуші, белгілі бір әкімші жұмыс істейді, әзірлеушілер тобы оларға келіп, «біз босатылдық, енді бақылаңыз» дейді. Нені бақылау? Бұл қалай жұмыс істейді?

ЖАРАЙДЫ МА. Біз ескі әдісті бақылаймыз. Ол қазірдің өзінде өзгеріп жатыр және сіз C қызметімен өзара әрекеттесетін В қызметіне айналған А қызметін бақылағаныңыз белгілі болды. Бірақ әзірлеушілер тобы сізге: «Бағдарламалық құралды орнатыңыз, ол бәрін бақылауы керек!» дейді.

Сонымен не өзгерді? - Барлығы өзгерді!

2008 Бәрі керемет

Бірнеше әзірлеушілер, бір сервер, бір дерекқор сервері бар. Бәрі осы жерден шығады. Бізде біраз ақпарат бар, біз zabbix, Nagios, кактустарды орнатамыз. Содан кейін біз процессорға, диск жұмысына және дискілік кеңістікке нақты ескертулер орнатамыз. Сондай-ақ сайттың жауап беретініне және тапсырыстардың дерекқорға келіп түсуіне көз жеткізу үшін біз бірнеше қолмен тексереміз. Міне, біз азды-көпті қорғанамыз.

Әкімшінің бақылауды қамтамасыз ету үшін жасаған жұмыс көлемін салыстыратын болсақ, онда оның 98% автоматты түрде орындалды: бақылауды жүзеге асыратын адам Zabbix орнатуды, оны конфигурациялауды және ескертулерді конфигурациялауды түсінуі керек. Ал 2% - сыртқы тексерулер үшін: сайт жауап беріп, дерекқорға сұраныс жасайды, жаңа тапсырыстар келді.

2010 Жүктеме өсуде

Біз іздеу жүйесін қоса отырып, интернетті масштабтауға кірісеміз. Өнім каталогында барлық өнімдер бар екеніне көз жеткізгіміз келеді. Және бұл өнімді іздеу жұмыс істейді. Дерекқор жұмыс істеп тұрғаны, тапсырыстар жасалып жатқаны, сайттың сырттан жауап беретіні және екі серверден жауап беретіні және пайдаланушы басқа серверге қайта теңестірілген кезде сайттан шығарылмағаны және т.б. Бұдан да көп нысандар бар.

Оның үстіне, инфрақұрылыммен байланысты ұйым әлі де менеджердің ең үлкені болып қала береді. Менің басымда әлі де мониторинг жүргізетін адам zabbix орнататын және оны конфигурациялай алатын адам деген ой бар.

Бірақ сонымен бірге сыртқы тексерулер жүргізу, іздеу индекстерінің сұраныстары сценарийлерінің жинағын құру, индекстеу процесінде іздеудің өзгеретінін тексеру үшін сценарийлер жиынтығы, тауарлардың жіберілгенін тексеретін сценарийлер жиынтығы бойынша жұмыс пайда болады. жеткізу қызметі және т.б. және т.б.

Ескерту: Мен «сценарийлер жинағын» 3 рет жаздым. Яғни, бақылауға жауапты адам енді жай ғана zabbix орнататын адам емес. Бұл кодтауды бастаған адам. Бірақ команданың ойында әлі ештеңе өзгерген жоқ.

Бірақ әлем өзгеруде, барған сайын күрделене түсуде. Виртуализация қабаты және бірнеше жаңа жүйе қосылды. Олар бір-бірімен араласа бастайды. Кім айтты «микросервистердің иісі бар?» Бірақ әрбір қызмет жеке веб-сайт сияқты көрінеді. Біз оған жүгініп, оның қажетті ақпаратты беріп, өздігінен жұмыс істейтінін түсінуге болады. Ал егер сіз 5-7-10 жыл бойы дамып келе жатқан жобамен үнемі айналысатын әкімші болсаңыз, бұл білім жинақталады: жаңа деңгей пайда болады - сіз оны түсіндіңіз, басқа деңгей пайда болады - сіз оны түсіндіңіз...

Бірақ 10 жыл бойы жобаны сүйемелдейтін адам сирек.

Мониторингманның түйіндемесі

Сіз бірден 20 әзірлеушіні жалдаған, 15 микросервис жазған жаңа стартапқа келдіңіз делік және сіз: «CI/CD құрастырыңыз. Өтінемін.» Сіз CI/CD құрастырдыңыз және кенеттен мынаны естисіз: «Бізге қосымшаның ондағы қалай жұмыс істейтінін түсінбей, «текшедегі» өндіріспен жұмыс істеу қиын. Бізге сол «текшеде» құмсалғыш жасаңыз.
Сіз бұл текшеде құм жәшігін жасайсыз. Олар сізге бірден айтады: «Біз өндірістен күн сайын жаңартылатын сахналық мәліметтер базасын қалаймыз, осылайша оның дерекқорда жұмыс істейтінін түсінеміз, бірақ сонымен бірге өндірістік дерекқорды бұзбаймыз».

Осының бәрінде сіз өмір сүресіз. Шығаруға 2 апта қалды, олар сізге: «Енді осының бәрін бақылап көрейік...» Яғни. кластерлік инфрақұрылымды бақылау, микросервис архитектурасын бақылау, сыртқы қызметтермен жұмысты бақылау...

Ал менің әріптестерім кәдімгі схеманы бастарынан шығарып: «Міне, мұнда бәрі түсінікті! Осының бәрін бақылайтын бағдарламаны орнатыңыз». Иә, иә: Prometheus + Grafana + плагиндері.
Және олар: «Сізде екі апта бар, бәрі қауіпсіз екеніне көз жеткізіңіз».

Біз көріп жүрген көптеген жобаларда мониторингке бір адам бөлінеді. Елестетіп көріңізші, біз 2 апта бойы мониторинг жүргізетін адамды алғымыз келеді және біз оған түйіндеме жазамыз. Осы уақытқа дейін айтқанымыздың бәрін ескере отырып, бұл адам қандай дағдыларға ие болуы керек?

• Ол темір инфрақұрылымының жұмысының мониторингі мен ерекшеліктерін түсінуі керек.
• Ол Kubernetes мониторингінің ерекшеліктерін түсінуі керек (және барлығы «текшеге» барғысы келеді, өйткені сіз барлығынан дерексізденуге, жасыруға болады, өйткені әкімші қалғанымен айналысады) - өзін, оның инфрақұрылымын және қолданбаларды қалай бақылау керектігін түсінуі керек. ішінде.
• Ол қызметтердің бір-бірімен ерекше тәсілдермен байланысатынын түсінуі және қызметтердің бір-бірімен әрекеттесу ерекшеліктерін білуі керек. Кейбір қызметтер синхронды түрде байланысатын жобаны көру әбден мүмкін, өйткені басқа жол жоқ. Мысалы, сервер REST арқылы, gRPC арқылы каталог қызметіне өтеді, өнімдер тізімін алады және оны кері қайтарады. Сіз бұл жерде күте алмайсыз. Басқа қызметтермен ол асинхронды түрде жұмыс істейді. Тапсырысты жеткізу қызметіне аудару, хат жіберу және т.б.
  Сіз мұның бәрінен жүзіп кеткен шығарсыз? Ал осыны қадағалап отыру керек админ одан сайын абдырап қалды.
• Ол дұрыс жоспарлап, жоспарлай білуі керек – жұмыс барған сайын арта түседі.
• Сондықтан ол оны қалай арнайы бақылауға болатынын түсіну үшін құрылған қызметтен стратегия жасауы керек. Оған жобаның архитектурасы және оның дамуы туралы түсінік + әзірлеуде қолданылатын технологиялар туралы түсінік қажет.

Абсолютті қалыпты жағдайды еске түсірейік: кейбір қызметтер PHP-де, кейбір қызметтер Go-де, кейбір қызметтер JS-де. Олар әйтеуір бір-бірімен жұмыс істейді. «Микросервис» термині осы жерден шыққан: жеке жүйелердің көптігі сонша, әзірлеушілер жобаны тұтастай түсіне алмайды. Команданың бір бөлігі JS жүйесінде өздігінен жұмыс істейтін және қалған жүйенің қалай жұмыс істейтінін білмейтін қызметтерді жазады. Екінші бөлігі қызметтерді Python тілінде жазады және басқа қызметтердің жұмысына кедергі жасамайды; олар өз аймағында оқшауланған. Үшіншісі - PHP немесе басқа нәрседе қызметтерді жазу.
Осы 20 адамның барлығы 15 қызметке бөлінген, мұның бәрін түсінуі керек бір ғана админ бар. Тоқта! біз жай ғана жүйені 15 микросервиске бөлдік, өйткені 20 адам бүкіл жүйені түсіне алмайды.

Бірақ оны қандай да бір жолмен бақылау керек ...

Нәтиже қандай? Нәтижесінде, бүкіл әзірлеушілер тобы түсінбейтін нәрсені ойлап табатын бір адам бар және сонымен бірге ол жоғарыда біз көрсеткен нәрсені - аппараттық инфрақұрылымды, Кубернетес инфрақұрылымын және т.б. білуі және істей алуы керек.

Не айтайын... Хьюстон, бізде проблемалар бар.

Заманауи бағдарламалық қамтамасыз ету жобасын бақылау - бұл өз алдына бағдарламалық жоба

Мониторинг бағдарламалық құрал деген жалған сенімнен біз ғажайыптарға деген сенімімізді дамытамыз. Бірақ ғажайыптар, өкінішке орай, болмайды. Сіз zabbix орната алмайсыз және бәрі жұмыс істейді деп күте алмайсыз. Графананы орнатып, бәрі жақсы болады деп үміттенудің қажеті жоқ. Уақыттың көп бөлігі қызметтердің жұмысын және олардың бір-бірімен өзара әрекеттесуін тексеруді ұйымдастыруға, сыртқы жүйелердің қалай жұмыс істейтінін тексеруге жұмсалады. Шын мәнінде, уақыттың 90% сценарий жазуға емес, бағдарламалық жасақтаманы әзірлеуге жұмсалады. Ал онымен жобаның жұмысын түсінетін команда айналысуы керек.
Бұл жағдайда бір адам бақылауға алынса, апат болады. Бұл барлық жерде болатын нәрсе.

Мысалы, Кафка арқылы бір-бірімен байланысатын бірнеше қызмет бар. Тапсырыс келді, біз Кафкаға тапсырыс туралы хабарлама жібердік. Тапсырыс туралы ақпаратты тыңдап, тауарды жөнелтетін қызмет бар. Тапсырыс туралы ақпаратты тыңдап, пайдаланушыға хат жіберетін қызмет бар. Содан кейін тағы бірнеше қызметтер пайда болады және біз шатастыра бастаймыз.

Егер сіз оны шығаруға аз уақыт қалған кезеңде әкімші мен әзірлеушілерге де берсеңіз, адам осы хаттаманы толық түсінуі керек. Анау. Мұндай ауқымдағы жоба көп уақытты алады және бұл жүйені әзірлеуде ескерілуі керек.
Бірақ көбінесе, әсіресе стартаптарда, біз мониторингтің кейінге қалдырылатынын көреміз. «Енді біз тұжырымдаманың дәлелін жасаймыз, біз онымен бірге іске қосамыз, ол құлап кетсін - біз құрбандыққа дайынбыз. Содан кейін біз бәрін бақылайтын боламыз ». Жоба ақша таба бастағанда (немесе егер) бизнес одан да көп мүмкіндіктерді қосқысы келеді - өйткені ол жұмыс істей бастады, сондықтан оны одан әрі тарату керек! Ал сіз ең алдымен бұрынғының бәрін бақылауыңыз керек, бұл уақыттың 1% емес, одан да көп уақытты алады. Айтпақшы, әзірлеушілер мониторинг үшін қажет болады және оларға жаңа мүмкіндіктермен жұмыс істеуге мүмкіндік беру оңайырақ. Нәтижесінде жаңа мүмкіндіктер жазылады, бәрі бұзылады және сіз шексіз тығырыққа тірелесіз.

Сонымен, жобаны басынан бастап қалай бақылауға болады және бақылауды қажет ететін жобаны алсаңыз, бірақ неден бастау керектігін білмесеңіз не істеу керек?

Біріншіден, жоспарлау керек.

Лирикалық шегініс: олар көбінесе инфрақұрылымды бақылаудан басталады. Мысалы, бізде Kubernetes бар. Прометейді Grafana көмегімен орнатудан, «текшені» бақылауға арналған плагиндерді орнатудан бастайық. Әзірлеушілер ғана емес, әкімшілер де: «Біз бұл плагинді орнатамыз, бірақ плагин мұны қалай жасау керектігін білетін шығар» деген өкінішті тәжірибеге ие. Адамдар маңызды әрекеттерден емес, қарапайым және қарапайым нәрселерден бастағанды ​​ұнатады. Ал инфрақұрылымды бақылау оңай.

Алдымен нені және қалай бақылайтыныңызды шешіңіз, содан кейін құралды таңдаңыз, себебі басқа адамдар сіз үшін ойлай алмайды. Және олар керек пе? Басқа адамдар әмбебап жүйе туралы өздері ойлады - немесе бұл плагин жазылған кезде мүлде ойланбады. Бұл плагиннің 5 мың пайдаланушысы болуы оның ешқандай пайдасы жоқ дегенді білдірмейді. Мүмкін сіз 5001-ші боласыз, өйткені ол жерде бұрын 5000 адам болған.

Инфрақұрылымды бақылауды бастасаңыз және қолданбаңыздың сервері жауап беруді тоқтатса, барлық пайдаланушылар мобильді қолданбамен байланысын жоғалтады. Қате пайда болады. Олар сізге келіп, «Қолданба жұмыс істемейді, мұнда не істеп жүрсіз?» дейді. - «Біз бақылаудамыз». — «Қолданбаның жұмыс істемейтінін көрмесеңіз, қалай бақылайсыз?!»

1. Бақылауды пайдаланушының кіру нүктесінен бастау керек деп ойлаймын. Егер пайдаланушы қолданбаның жұмыс істеп тұрғанын көрмесе, бұл сәтсіздік. Ал мониторинг жүйесі бұл туралы алдымен ескертуі керек.
2. Сонда ғана инфрақұрылымды бақылай аламыз. Немесе оны параллель орындаңыз. Инфрақұрылыммен оңайырақ - мұнда біз zabbix-ті орната аламыз.
3. Ал енді қай жерде жұмыс істемейтінін түсіну үшін қолданбаның түпкі тамырына бару керек.

Менің негізгі ойым – мониторинг даму үдерісімен қатар жүруі керек. Мониторинг тобын басқа тапсырмаларға (CI/CD жасау, құмсалғышты құру, инфрақұрылымды қайта ұйымдастыру) алаңдататын болсаңыз, мониторинг артта қалады және сіз дамуды ешқашан қуып жете алмайсыз (немесе ерте ме, кеш пе оны тоқтатуға тура келеді).

Барлығы деңгейлер бойынша

Мониторинг жүйесін ұйымдастыруды мен осылай көремін.

1) Қолдану деңгейі:

• қолданбалы бизнес логикасын бақылау;
• қызметтердің денсаулық көрсеткіштерін бақылау;
• интеграциялық мониторинг.

2) Инфрақұрылым деңгейі:

• оркестр деңгейін бақылау;
• жүйелік бағдарламалық қамтамасыз ету мониторингі;
• темір деңгейін бақылау.

3) Тағы да қолданбалы деңгей – бірақ инженерлік өнім ретінде:

• қолданбалар журналдарын жинау және бақылау;
• APM;
• қадағалау.

4) Ескерту:

• ескерту жүйесін ұйымдастыру;
• кезекшілік жүйесін ұйымдастыру;
• оқиғаларды өңдеу үшін «білім базасын» және жұмыс процесін ұйымдастыру.

маңызды: біз ескертуге кейін емес, бірден келеміз! Мониторингті іске қосудың және «кейбір жағдайда» ескертулерді кім алатынын анықтаудың қажеті жоқ. Өйткені, бақылаудың міндеті қандай: жүйенің қай жерінде бірдеңе дұрыс жұмыс істемейтінін түсіну және бұл туралы тиісті адамдарға хабарлау. Егер сіз мұны соңына дейін қалдырсаңыз, онда дұрыс адамдар бірдеңе дұрыс емес екенін «бізге ештеңе істемейді» деп қоңырау шалу арқылы біледі.

Қолданбалы деңгей – Бизнес логикасын бақылау

Мұнда біз қолданбаның пайдаланушы үшін жұмыс істейтінін тексеру туралы айтып отырмыз.

Бұл деңгей даму кезеңінде жасалуы керек. Мысалы, бізде шартты Prometheus бар: ол тексерулерді орындайтын серверге барады, соңғы нүктені тартады және соңғы нүкте API интерфейсін тексереді.

Сайттың жұмыс істеп тұрғанына көз жеткізу үшін басты бетті бақылауды жиі сұрағанда, бағдарламашылар API жұмыс істеп тұрғанына көз жеткізу үшін қажет болған сайын тартуға болатын тұтқаны береді. Қазіргі уақытта бағдарламашылар әлі де /api/test/helloworld жазып алады
Барлығы жұмыс істейтініне көз жеткізудің жалғыз жолы? - Жоқ!

• Мұндай тексерулерді жасау негізінен әзірлеушілердің міндеті болып табылады. Бірлік сынақтарын кодты жазатын бағдарламашылар жазуы керек. Өйткені, егер сіз оны әкімшіге жіберсеңіз: «Жігіт, мұнда барлық 25 функцияға арналған API протоколдарының тізімі бар, бәрін бақылаңыз!» - ештеңе шықпайды.
• Егер сіз «сәлем әлемді» басып шығарсаңыз, API жұмыс істейтінін және жұмыс істейтінін ешкім ешқашан білмейді. Әрбір API өзгерісі тексерулердің өзгеруіне әкелуі керек.
• Егер сізде мұндай мәселе болса, мүмкіндіктерді тоқтатыңыз және осы тексерулерді жазатын әзірлеушілерді бөліңіз немесе шығындарды қабылдаңыз, ештеңе тексерілмегенін және сәтсіздікке ұшырайтынын қабылдаңыз.

Техникалық кеңестер:

• Тексеруді ұйымдастыру үшін сыртқы серверді ұйымдастыруды ұмытпаңыз - сіздің жобаңыз сыртқы әлем үшін қолжетімді екеніне сенімді болуыңыз керек.
• Тек жеке соңғы нүктелерді емес, бүкіл API протоколы бойынша тексерулерді ұйымдастырыңыз.
• Сынақ нәтижелерімен прометейдің соңғы нүктесін жасаңыз.

Қолданбалы деңгей – денсаулық көрсеткіштерін бақылау

Енді біз қызметтердің сыртқы денсаулық көрсеткіштері туралы айтып отырмыз.

Біз қосымшаның барлық «тұтқаларын» сыртқы бақылау жүйесінен шақыратын сыртқы тексерулер арқылы бақылаймыз деп шештік. Бірақ бұл пайдаланушы «көретін» «тұтқалар». Біздің қызметтеріміздің өзі жұмыс істейтініне сенімді болғымыз келеді. Мұнда жақсырақ әңгіме бар: K8s денсаулығын тексереді, сондықтан кем дегенде «текшенің» өзі қызметтің жұмыс істеп тұрғанына сенімді болуы мүмкін. Бірақ мен көрген чектердің жартысы бірдей баспа «сәлем әлем». Анау. Сондықтан ол орналастырғаннан кейін бір рет тартады, ол бәрі жақсы деп жауап берді - бұл бәрі. Қызметте, егер ол өзінің API қамтамасыз етсе, сол API үшін кіру нүктелерінің үлкен саны бар, олар да бақылауды қажет етеді, өйткені біз оның жұмыс істейтінін білгіміз келеді. Ал біз оны қазірдің өзінде іштей бақылап жатырмыз.

Мұны техникалық түрде қалай дұрыс енгізу керек: әрбір қызмет өзінің ағымдағы өнімділігі туралы соңғы нүктені көрсетеді және Grafana (немесе кез келген басқа қолданба) графиктерінде біз барлық қызметтердің күйін көреміз.

• Әрбір API өзгерісі тексерулердің өзгеруіне әкелуі керек.
• Денсаулық көрсеткіштерімен жаңа қызметті бірден жасаңыз.
• Әкімші әзірлеушілерге келіп, «бәрін түсінуім және бақылау жүйесіме бұл туралы ақпаратты қосу үшін маған бірнеше мүмкіндік қосыңыз» деп сұрауы мүмкін. Бірақ әзірлеушілер әдетте «Шығаруға екі апта қалғанда ештеңе қоспаймыз» деп жауап береді.
  Даму менеджерлері мұндай шығындардың болатынын білсін, даму менеджерлерінің басшылығы да білсін. Өйткені бәрі құлаған кезде, біреу әлі де қоңырау шалып, «үнемі құлдырайтын қызметті» бақылауды талап етеді (c)
• Айтпақшы, Grafana плагиндерін жазу үшін әзірлеушілерді бөліңіз - бұл әкімшілер үшін жақсы көмек болады.

Қолданбалы деңгей – Интеграция мониторингі

Интеграциялық мониторинг бизнес үшін маңызды жүйелер арасындағы байланысты бақылауға бағытталған.

Мысалы, бір-бірімен байланысатын 15 қызмет бар. Бұл енді бөлек сайттар емес. Анау. біз қызметті өз бетімен тарта алмаймыз, /helloworld аламыз және қызмет жұмыс істеп тұрғанын түсінеміз. Тапсырыс беруші веб-қызмет тапсырыс туралы ақпаратты автобусқа жіберуі керек болғандықтан - автобустан қойма қызметі бұл хабарламаны алып, онымен әрі қарай жұмыс істеуі керек. Электрондық поштаны тарату қызметі мұны одан әрі өңдеуі керек, т.б.

Тиісінше, біз әрбір жеке қызметке қарап, оның бәрі жұмыс істейтінін түсіне алмаймыз. Өйткені бізде белгілі бір автобус бар, ол арқылы бәрі байланысады және өзара әрекеттеседі.
Сондықтан бұл кезең басқа қызметтермен өзара әрекеттесу үшін қызметтерді тестілеу кезеңін белгілеуі керек. Хабарлама брокерін бақылау арқылы байланыс мониторингін ұйымдастыру мүмкін емес. Деректерді шығаратын қызмет және оны алатын қызмет болса, брокерді бақылаған кезде біз тек бір жағынан ұшатын деректерді көреміз. Егер біз қандай да бір түрде бұл деректердің өзара әрекеттесуін іштей бақылай алсақ та - белгілі бір өндіруші деректерді орналастырады, біреу оны оқиды, бұл ағын Кафкаға өтуді жалғастырады - егер бір қызмет хабарламаны бір нұсқада жіберсе, бұл бізге ақпарат бермейді. , бірақ басқа қызмет бұл нұсқаны күтпеді және оны өткізіп жіберді. Біз бұл туралы білмейміз, өйткені қызметтер бізге бәрі жұмыс істеп тұрғанын айтады.

Мен не істеуге кеңес беремін:

• Синхронды байланыс үшін: соңғы нүкте қатысты қызметтерге сұраулар жасайды. Анау. біз осы соңғы нүктені аламыз, қызметтің ішіне сценарийді тартамыз, ол барлық нүктелерге барады және «Мен сонда тарта аламын, сонда тарта аламын, мен сонда тарта аламын ...» дейді.
• Асинхронды байланыс үшін: кіріс хабарламалар - соңғы нүкте шинаны сынақ хабарламалары үшін тексереді және өңдеу күйін көрсетеді.
• Асинхронды байланыс үшін: шығыс хабарламалар - соңғы нүкте сынақ хабарламаларын шинаға жібереді.

Әдеттегідей: бізде деректерді автобусқа жіберетін қызмет бар. Біз осы қызметке келіп, оның интеграциялық денсаулығы туралы айтып беруіңізді сұраймыз. Ал егер қызмет басқа жерде (WebApp) хабарлама жасау қажет болса, ол осы сынақ хабарламасын шығарады. Ал егер біз OrderProcessing жағында қызметті іске қоссақ, ол алдымен нені тәуелсіз орналастыра алатынын жариялайды, ал егер кейбір тәуелді нәрселер болса, онда ол шинадан сынақ хабарламаларының жинағын оқиды, оларды өңдей алатынын түсінеді, ол туралы есеп береді және , қажет болса, оларды әрі қарай орналастырыңыз, бұл туралы ол айтады - бәрі жақсы, мен тірімін.

«Мұны жауынгерлік деректерде қалай тексеруге болады?» Деген сұрақты жиі естиміз. Мысалы, біз сол тапсырыс беру қызметі туралы айтып отырмыз. Бұйрық тауарлар есептен шығарылған қоймаға хабарламалар жібереді: біз оны жауынгерлік деректер бойынша тексере алмаймыз, өйткені «менің тауарларым есептен шығарылады!» Шешім: Осы сынақты ең басында жоспарлаңыз. Сізде күлкі жасайтын бірлік сынақтары да бар. Сонымен, бизнестің жұмысына зиян келтірмейтін байланыс арнасы бар тереңірек деңгейде жасаңыз.

Инфрақұрылым деңгейі

Инфрақұрылымдық мониторинг - бұл ұзақ уақыт бойы бақылаудың өзі болып саналатын нәрсе.

• Инфрақұрылымдық мониторинг жеке процесс ретінде іске қосылуы мүмкін және іске қосылуы керек.
• Сіз шынымен қаласаңыз да, іске қосылған жобада инфрақұрылымды бақылаудан бастамауыңыз керек. Бұл барлық девоптар үшін азап. «Алдымен кластерді бақылаймын, мен инфрақұрылымды бақылаймын» – т.б. Біріншіден, ол төменде не жатқанын бақылайды, бірақ қолданбаға кірмейді. Өйткені қолданба devops үшін түсініксіз нәрсе. Бұл оған ағып кетті және ол оның қалай жұмыс істейтінін түсінбейді. Ал инфрақұрылымды түсініп, содан бастайды. Бірақ жоқ - сіз әрқашан алдымен қолданбаны бақылауыңыз керек.
• Ескертулер санымен шектен шықпаңыз. Заманауи жүйелердің күрделілігін ескере отырып, ескертулер үнемі ұшады және сіз осы ескертулер жиынтығымен қандай да бір түрде өмір сүруіңіз керек. Шақырушы келесі жүздеген ескертулерді қарап шығып, «бұл туралы ойлағым келмейді» деп шешеді. Ескертулер тек маңызды нәрселер туралы хабарлауы керек.

Бизнес бірлігі ретінде қолданбалы деңгей

Негізгі мәселелер:

• ELK. Бұл салалық стандарт. Егер қандай да бір себептермен журналдарды біріктірмей жатсаңыз, мұны дереу бастаңыз.
• APM. Сыртқы APMs қолданба мониторингін жылдам жабу тәсілі ретінде (NewRelic, BlackFire, Datadog). Кем дегенде, сізбен не болып жатқанын түсіну үшін бұл нәрсені уақытша орнатуға болады.
• Бақылау. Ондаған микросервистерде барлығын қадағалау керек, себебі сұрау енді өздігінен өмір сүрмейді. Оны кейінірек қосу өте қиын, сондықтан әзірлеуде бақылауды дереу жоспарлау жақсы - бұл әзірлеушілердің жұмысы мен утилитасы. Егер сіз оны әлі іске асырмаған болсаңыз, оны іске асырыңыз! Jaeger/Zipkin қараңыз

Ескерту

• Хабарландыру жүйесін ұйымдастыру: көптеген нәрселерді бақылау жағдайында хабарламаларды жіберудің бірыңғай жүйесі болуы керек. Сіз Графанада аласыз. Батыста барлығы PagerDuty пайдаланады. Ескертулер анық болуы керек (мысалы, олар қайдан келді...). Және хабарламалардың мүлде қабылдануын бақылауға алған жөн
• Кезекшілік жүйесін ұйымдастыру: ескертулер барлығына жіберілмеуі керек (не барлығы топта әрекет етеді, не ешкім жауап бермейді). Әзірлеушілер де шақырулары керек: жауапкершілік салаларын анықтап, нақты нұсқаулар беріп, дүйсенбі мен сәрсенбіде кімге қоңырау шалу керектігін және сейсенбі мен жұмада кімге қоңырау шалу керектігін жазыңыз (әйтпесе олар ешкімге қоңырау шалмайды. үлкен мәселе болған жағдайда - олар сізді оятудан немесе алаңдатудан қорқады: адамдар әдетте басқа адамдарға қоңырау шалуды және оятуды ұнатпайды, әсіресе түнде). Көмек сұрау қабілетсіздіктің көрсеткіші емес екенін түсіндіріңіз («Мен көмек сұраймын, бұл мен нашар жұмысшымын»), көмек сұрауды ынталандыру.
• «Білім базасын» ұйымдастыру және инциденттерді өңдеуге арналған жұмыс үрдісі: әрбір ауыр оқиға үшін өлгеннен кейінгі іс-шаралар жоспарлануы керек және уақытша шара ретінде оқиғаны шешетін әрекеттер жазылуы керек. Және қайталап ескертудің күнә екенін әдетке айналдырыңыз; оларды кодта немесе инфрақұрылымдық жұмыста бекіту керек.

Технологиялық стек

Біздің стектің келесідей екенін елестетіп көрейік:

• деректер жинау - Prometheus + Grafana;
• журналды талдау - ELK;
• APM немесе Tracing үшін - Jaeger (Zipkin).

Опцияларды таңдау маңызды емес. Өйткені, егер сіз бастапқыда жүйені қалай бақылауға болатынын түсініп, жоспарды жазып алсаңыз, онда сіз өз талаптарыңызға сай құралдарды таңдай бастайсыз. Мәселе сіз бірінші кезекте нені бақылауды таңдадыңыз. Өйткені, сіз бастапқыда таңдаған құрал сіздің талаптарыңызға мүлдем сәйкес келмеуі мүмкін.

Мен соңғы уақытта барлық жерде көретін бірнеше техникалық тармақтар:

Прометейді Кубернетестің ішіне ығыстырып жатыр - мұны кім ойлап тапты?! Егер сіздің кластеріңіз бұзылса, сіз не істейсіз? Егер сізде күрделі кластер болса, кластердің ішінде бақылау жүйесінің қандай да бір түрі болуы керек, ал кластердің ішінен деректерді жинайтын кейбіреулері сыртында болуы керек.

Кластердің ішінде біз журналдарды және басқаларды жинаймыз. Бірақ бақылау жүйесі сыртта болуы керек. Көбінесе, ішінде Promtheus орнатылған кластерде сайттың жұмысын сыртқы тексеруді жүзеге асыратын жүйелер де бар. Сыртқы әлеммен байланысыңыз үзіліп, қолданба жұмыс істемесе ше? Ішінде бәрі жақсы екені белгілі болды, бірақ бұл пайдаланушылар үшін жағдайды жеңілдетпейді.

қорытындылар

• Әзірлеуді бақылау утилиталарды орнату емес, бағдарламалық өнімді әзірлеу болып табылады. Бүгінгі мониторингтің 98 пайызы кодтау. Қызметтерді кодтау, сыртқы тексерулерді кодтау, сыртқы қызметтерді тексеру және осының бәрі.
• Әзірлеушілердің уақытын бақылауға жұмсамаңыз: бұл олардың жұмысының 30% -ын алуы мүмкін, бірақ бұл тұрарлық.
• Девостар, бір нәрсені бақылай алмаймын деп уайымдамаңыз, өйткені кейбір нәрселер мүлдем басқа ойлау тәсілі. Сіз бағдарламашы емессіз, бақылау жұмысы дәл олардың жұмысы.
• Егер жоба әлдеқашан іске қосылған болса және бақыланбайтын болса (және сіз басқарушы болсаңыз), мониторинг үшін ресурстарды бөліңіз.
• Егер өнім қазірдің өзінде өндірісте болса және сіз «мониторинг орнатуды» бұйырған девопист болсаңыз - басшылыққа мұның барлығы туралы жазғанымды түсіндіріп көріңіз.

Бұл Saint Highload++ конференциясындағы есептің кеңейтілген нұсқасы.

Егер сізді оған қатысты идеяларым мен ойларым және оған қатысты тақырыптар қызықтырса, мұнда сіз аласыз арнаны оқыңыз 🙂

Ақпарат көзі: www.habr.com