Менің атым Антон Бадерин. Мен жоғары технологиялар орталығында жұмыс істеймін және жүйелік әкімшілікпен айналысамын. Бір ай бұрын біздің корпоративтік конференциямыз аяқталды, онда біз қаламыздың IT қауымдастығымен жинақталған тәжірибемізбен бөлістік. Мен веб-қосымшаларды бақылау туралы айттым. Материал бұл процесті нөлден құрмаған кіші немесе орта деңгейге арналған.
Кез келген мониторинг жүйесінің негізі бизнес мәселелерін шешу болып табылады. Мониторинг үшін мониторинг ешкімді қызықтырмайды. Бизнес нені қалайды? Барлығы тез және қатесіз жұмыс істеуі үшін. Кәсіпорындар белсенді болғысы келеді, осылайша біз өзіміз қызметтегі ақауларды анықтап, оларды мүмкіндігінше тезірек түзетеміз. Бұл, шын мәнінде, мен өткен жылы біздің тұтынушыларымыздың біріне арналған жобада шешкен мәселелер.
Жоба жайлы
Жоба елдегі ең ірі адалдық бағдарламаларының бірі болып табылады. Біз бөлшек сауда желілеріне бонустық карталар сияқты әртүрлі маркетинг құралдары арқылы сату жиілігін арттыруға көмектесеміз. Барлығы жобаға он серверде жұмыс істейтін 14 қосымша кіреді.
Әңгімелесу барысында мен әкімшілер веб-қосымшаларды бақылауға әрқашан дұрыс қарай бермейтінін бірнеше рет байқадым: көпшілігі әлі де операциялық жүйе көрсеткіштеріне назар аударады және кейде қызметтерді бақылайды.
Менің жағдайда тұтынушының бақылау жүйесі бұрын Icinga-ға негізделген. Ол жоғарыда аталған мәселелерді ешбір жолмен шеше алмады. Көбінесе клиенттің өзі бізге проблемалар туралы хабардар етті, және көбінесе себептің түбіне жету үшін бізде деректер жеткіліксіз болды.
Сонымен қатар, оны одан әрі дамытудың пайдасыздығы туралы нақты түсінік болды. Айсингамен таныстар мені түсінеді деп ойлаймын. Осылайша, біз жоба үшін веб-қосымшаларды бақылау жүйесін толығымен қайта құруды шештік.
Прометей
Біз Прометейді үш негізгі көрсеткіш бойынша таңдадық:
- Қол жетімді көрсеткіштердің үлкен саны. Біздің жағдайда олардың 60 мыңы бар. Әрине, біз олардың басым көпшілігін (95% шамасында) қолданбайтынымызды атап өткен жөн. Екінші жағынан, олардың барлығы салыстырмалы түрде арзан. Біз үшін бұл бұрын қолданылған Icinga-мен салыстырғанда басқа экстремалды. Онда метрика қосу ерекше ауыртпалық болды: барлары қымбат болды (кез келген плагиннің бастапқы кодын қараңыз). Кез келген плагин Bash немесе Python тіліндегі сценарий болды, оны іске қосу тұтынылатын ресурстар тұрғысынан қымбат.
- Бұл жүйе ресурстардың салыстырмалы түрде аз мөлшерін тұтынады. 600 МБ жедел жады, бір ядроның 15% және бірнеше ондаған IOPS барлық көрсеткіштерімізге жеткілікті. Әрине, метрика экспорттаушыларын іске қосу керек, бірақ олардың барлығы Go бағдарламасында жазылған және сондай-ақ аса қуатты қажет етпейді. Мен қазіргі заманғы шындықта бұл проблема деп ойламаймын.
- Кубернетеске көшу мүмкіндігін береді. Тұтынушының жоспарын ескере отырып, таңдау анық.
ELK
Бұрын біз журналдарды жинамадық немесе өңдемедік. Кемшіліктер барлығына түсінікті. Біз ELK-ті таңдадық, өйткені бізде бұл жүйемен тәжірибе болды. Онда біз тек қолданба журналдарын сақтаймыз. Негізгі іріктеу критерийлері толық мәтінді іздеу және оның жылдамдығы болды.
Сликхаус
Бастапқыда таңдау InfluxDB-ге түсті. Біз Nginx журналдарын, pg_stat_statements статистикасын жинау және Prometheus тарихи деректерін сақтау қажеттілігін түсіндік. Influx бізге ұнамады, өйткені ол мезгіл-мезгіл жадтың үлкен көлемін тұтына бастады және бұзылды. Бұған қоса, мен сұрауларды remote_addr арқылы топтастырғым келді, бірақ бұл ДҚБЖ-да топтау тек тегтер арқылы жүзеге асырылады. Тегтер қымбат (жад), олардың саны шартты түрде шектеулі.
Біз іздеуді қайтадан бастадық. Ең аз ресурстарды тұтынуы бар аналитикалық деректер базасы қажет болды, мүмкіндігінше дискідегі деректерді қысу.
Clickhouse осы критерийлердің барлығына сәйкес келеді және біз таңдауымызға ешқашан өкінген емеспіз. Біз оған ешқандай ерекше көлемдегі деректерді жазбаймыз (енгізу саны минутына бес мыңға жуық).
NewRelic
NewRelic тарихи түрде бізбен бірге болды, өйткені бұл тапсырыс берушінің таңдауы болды. Біз оны APM ретінде қолданамыз.
Zabbix
Біз Zabbix-ті тек әртүрлі API интерфейстерінің қара жәшігін бақылау үшін пайдаланамыз.
Мониторинг тәсілін анықтау
Біз тапсырманы бөлшектеуге және сол арқылы мониторингке көзқарасты жүйелендіруді көздедік.
Ол үшін мен жүйемізді келесі деңгейлерге бөлдім:
- аппараттық құралдар және VMS;
- операциялық жүйе;
- жүйелік қызметтер, бағдарламалық қамтамасыз ету стегі;
- қолдану;
- іскерлік логика.
Неліктен бұл тәсіл ыңғайлы:
- біз әр деңгейдің жұмысына кім жауапты екенін білеміз және осының негізінде ескертулер жібере аламыз;
- біз ескертулерді басу кезінде құрылымды пайдалана аламыз - виртуалды машина тұтастай қолжетімсіз болған кезде дерекқордың қолжетімсіздігі туралы ескерту жіберу біртүрлі болар еді.
Біздің міндетіміз жүйенің жұмысындағы бұзушылықтарды анықтау болғандықтан, біз әр деңгейде ескерту ережелерін жазу кезінде назар аударуға тұрарлық көрсеткіштердің белгілі бір жинағын бөлектеуіміз керек. Әрі қарай, «VMS», «Операциялық жүйе» және «Жүйелік қызметтер, бағдарламалық қамтамасыз ету стегі» деңгейлеріне өтейік.
Виртуалды машиналар
Хостинг бізге процессорды, дискіні, жадты және желіні бөледі. Ал бізде алғашқы екеуінде қиындықтар болды. Сонымен, көрсеткіштер:
CPU ұрланған уақыты - сіз Amazon-да виртуалды машинаны сатып алған кезде (мысалы, t2.micro) сізге процессордың бүкіл ядросы емес, оның уақытының квотасы ғана бөлінгенін түсінуіңіз керек. Ал сіз оны таусылған кезде процессор сізден алынады.
Бұл көрсеткіш осындай сәттерді қадағалап, шешім қабылдауға мүмкіндік береді. Мысалы, қосымша тарифті алу немесе фондық тапсырмалар мен API сұрауларын өңдеуді әртүрлі серверлерге тарату қажет пе?
IOPS + CPU iowait уақыты - қандай да бір себептермен көптеген бұлттық хостингтер IOPS-ті жеткіліксіз қамтамасыз етпеу арқылы күнә жасайды. Сонымен қатар, төмен IOPS бар кесте олар үшін дәлел емес. Сондықтан CPU iowait жинауға тұрарлық. Осы жұп графиктермен - төмен IOPS және жоғары енгізу/шығару күтуімен - сіз хостингпен сөйлесіп, мәселені шеше аласыз.
Операциялық жүйе
Операциялық жүйе көрсеткіштері:
- бос жад көлемі %;
- свопты пайдалану әрекеті: vmstat swapin, swapout;
- қол жетімді инодтар саны және файлдық жүйедегі бос орын %
- орташа жүктеме;
- tw күйіндегі қосылымдар саны;
- кестені толтыру;
- Желінің сапасын ss утилитасы, iproute2 пакеті арқылы бақылауға болады - оның шығысынан RTT қосылымдарының көрсеткішін алыңыз және оны мақсатты порт бойынша топтаңыз.
Сондай-ақ операциялық жүйе деңгейінде бізде процестер сияқты нысан бар. Жүйеде оның жұмысында маңызды рөл атқаратын процестердің жиынтығын анықтау маңызды. Мысалы, сізде бірнеше pgpool болса, олардың әрқайсысы үшін ақпарат жинау керек.
Көрсеткіштер жиынтығы келесідей:
- ОРТАЛЫҚ ЕСЕПТЕУІШ БӨЛІМ;
- жады ең алдымен резидент болып табылады;
- IO - жақсырақ IOPS-те;
- FileFd – ашу және шектеу;
- маңызды бет ақаулары - осылайша сіз қандай процестің ауыстырылып жатқанын түсіне аласыз.
Біз барлық бақылауды Docker жүйесінде орналастырамыз және көрсеткіштер деректерін жинау үшін кеңесшіні пайдаланамыз. Басқа машиналарда біз процесс-экспорттауды қолданамыз.
Жүйелік қызметтер, бағдарламалық қамтамасыз ету стегі
Әрбір қолданбаның өзіндік ерекшеліктері бар және метриканың белгілі бір жинағын бөліп алу қиын.
Әмбебап жиынтық:
- сұраныс мөлшерлемесі;
- қателер саны;
- кідіріс;
- қанықтыру.
Бұл деңгейдегі бақылаудың ең жарқын мысалдары Nginx және PostgreSQL болып табылады.
Біздің жүйедегі ең көп жүктелген қызмет – бұл мәліметтер базасы. Бұрын біз дерекқордың не істеп жатқанын анықтауда жиі қиындықтарға тап болдық.
Біз дискілерде жоғары жүктемені көрдік, бірақ баяу журналдар шынымен ештеңе көрсетпеді. Біз бұл мәселені сұрау статистикасын жинайтын pg_stat_statements көрінісі арқылы шештік.
Админге керегі осы.
Біз оқу және жазу сұрауларының белсенділігінің графиктерін құрастырамыз:
Барлығы қарапайым және түсінікті, әр сұраныстың өзіндік түсі бар.
Бірдей жарқын мысал - Nginx журналдары. Аз адамдар оларды талдап немесе міндетті тізімде атап өтуі таңқаларлық емес. Стандартты формат өте ақпаратты емес және кеңейтуді қажет етеді.
Жеке өзім сұрау_уақыты, жоғары_жауап_уақыты, дене_байт_жіберілген, сұрау_ұзындығы, сұрау_идентификаторын қостым. Жауап беру уақыты мен қателер санын белгілейміз:
Біз жауап беру уақыты мен қателер санының графиктерін құрастырамыз. Есіңізде ме? Мен бизнес мақсаттары туралы айттым ба? Тез және қатесіз? Біз бұл мәселелерді екі диаграмма арқылы қарастырдық. Сіз оларды пайдаланып кезекші әкімшілерге қоңырау шала аласыз.
Бірақ тағы бір мәселе қалады - оқиғаның себептерін тез жоюды қамтамасыз ету.
Оқиғаны шешу
Мәселені анықтаудан бастап шешуге дейінгі бүкіл процесті бірнеше қадамдарға бөлуге болады:
- проблеманы анықтау;
- кезекші әкімшіге хабарлама;
- оқиғаға жауап беру;
- себептерін жою.
Мұны мүмкіндігінше тезірек жасау маңызды. Егер мәселені анықтау және хабарлама жіберу кезеңдерінде біз көп уақытты ұта алмасақ - кез келген жағдайда оларға екі минут жұмсалатын болса, одан кейінгілері жақсарту үшін жай ғана өңделмеген өріс болып табылады.
Кезекшінің телефоны шырылдады делік. Ол не істейді? Сұрақтарға жауап іздеңіз - не сынды, қай жерде сынды, қалай әрекет ету керек? Міне, біз бұл сұрақтарға қалай жауап береміз:
Біз бұл ақпараттың барлығын хабарландыру мәтініне жай ғана қосамыз, оған осы мәселеге қалай жауап беру, оны шешу және оны күшейту жолын сипаттайтын вики-парақшаға сілтеме береміз.
Мен қолданбалар деңгейі мен бизнес логикасы туралы әлі ештеңе айтқан жоқпын. Өкінішке орай, біздің қолданбалар әлі метрика жиынын енгізбейді. Бұл деңгейлерден кез келген ақпараттың жалғыз көзі журналдар болып табылады.
Бір-екі ұпай.
Алдымен құрылымдық журналдарды жазыңыз. Хабарлама мәтініне контекст қосудың қажеті жоқ. Бұл оларды топтастыруды және талдауды қиындатады. Logstash мұның бәрін қалыпқа келтіру үшін көп уақытты алады.
Екіншіден, ауырлық деңгейлерін дұрыс пайдаланыңыз. Әр тілдің өз стандарты бар. Мен өз басым төрт деңгейді ажыратамын:
- қате жоқ;
- клиенттік қате;
- қате өз тарапымызда, біз ақша жоғалтпаймыз, тәуекелге бармаймыз;
- Қате өз тарапымызда, біз ақша жоғалтамыз.
Қорытындылай кетейін. Бизнес логикасына негізделген мониторинг құруға тырысу керек. Қолданбаның өзін бақылап көріңіз және сатылымдар саны, жаңа пайдаланушы тіркеулерінің саны, ағымдағы белсенді пайдаланушылар саны және т.б. сияқты көрсеткіштермен жұмыс жасаңыз.
Егер сіздің бүкіл бизнесіңіз браузердегі бір түйме болса, оның басылып, дұрыс жұмыс істейтінін бақылауыңыз керек. Қалғанының бәрі маңызды емес.
Егер сізде бұл болмаса, оны біз сияқты қолданбалар журналдарында, Nginx журналдарында және т.б. Сіз қолданбаға мүмкіндігінше жақын болуыңыз керек.
Операциялық жүйе көрсеткіштері, әрине, маңызды, бірақ олар бизнесті қызықтырмайды, олар үшін бізге ақы төленбейді.
Ақпарат көзі: www.habr.com