Бүгінгі таңда біздің жобамыз монолитті кодтан басқа ондаған микросервистерді қамтиды. Олардың әрқайсысы бақылауды қажет етеді. Мұны DevOps инженерлерінің көмегімен осындай ауқымда жасау қиын. Біз әзірлеушілерге қызмет көрсету ретінде жұмыс істейтін мониторинг жүйесін әзірледік. Олар мониторинг жүйесіне метрикаларды дербес жаза алады, оларды пайдалана алады, олардың негізінде бақылау тақталарын құра алады және шекті мәндерге жеткенде іске қосылатын ескертулерді қоса алады. DevOps инженерлері үшін тек инфрақұрылым мен құжаттама.
Бұл пост біздің әңгімемнің стенограммасы RIT++ жүйесінде. Көптеген адамдар бізден есептердің мәтіндік нұсқасын жасауды сұрады. Егер сіз конференцияда болсаңыз немесе бейнені қарасаңыз, жаңа ештеңе таба алмайсыз. Ал қалғандары - мысыққа қош келдіңіздер. Мен сізге мұндай жүйеге қалай келгенімізді, оның қалай жұмыс істейтінін және оны қалай жаңартуды жоспарлап отырғанымызды айтып беремін.
Өткен: схемалар мен жоспарлар
Қазіргі мониторинг жүйесіне қалай келдік? Бұл сұраққа жауап беру үшін 2015 жылға бару керек. Ол кездегідей болды:
Бізде бақылауға жауапты 24-ке жуық түйін болды. Бір нәрсені бақылайтын, хабарламалар жіберетін және функцияларды орындайтын әртүрлі тәждердің, сценарийлердің, демондардың толық жиынтығы бар. Неғұрлым әрі қарай жүрсек, мұндай жүйенің өміршеңдігі азаяды деп ойладық. Оны дамытудың қажеті жоқ: бұл тым ауыр.
Біз сақтайтын және дамытатын және біз бас тартатын бақылау элементтерін таңдауды шештік. Олардың саны 19. Тек графиттер, агрегаторлар және бақылау тақтасы ретінде Графана ғана қалды. Бірақ жаңа жүйе қандай болмақ? Бұл сияқты:
Бізде метрика қоймасы бар: бұл жылдам SSD дискілеріне негізделген графиттер, бұл метрикаға арналған белгілі агрегаторлар. Келесі - бақылау тақталарын көрсету үшін Grafana және ескерту үшін Moira. Біз сондай-ақ аномалияларды іздеу жүйесін дамытқымыз келді.
Стандарт: Мониторинг 2.0
2015 жылы жоспарлар осылай болды. Бірақ біз тек инфрақұрылым мен қызметтің өзін ғана емес, сонымен бірге оған құжаттаманы да дайындауымыз керек еді. Біз өзіміз үшін корпоративтік стандарт әзірледік, оны мониторинг 2.0 деп атаймыз. Жүйеге қандай талаптар қойылды?
- тұрақты қолжетімділік;
- метриканы сақтау аралығы = 10 секунд;
- метриканы және бақылау тақтасын құрылымдық сақтау;
- SLA > 99,99%
- UDP (!) арқылы оқиға көрсеткіштерін жинау.
Бізге UDP қажет болды, өйткені бізде трафиктің және метрика жасайтын оқиғалардың үлкен ағыны бар. Егер сіз олардың барлығын бірден графитке жазсаңыз, жад жойылады. Біз сондай-ақ барлық көрсеткіштер үшін бірінші деңгейлі префикстерді таңдадық.
Префикстердің әрқайсысының белгілі бір қасиеті бар. Серверлерге, желілерге, контейнерлерге, ресурстарға, қолданбаларға және т.б. арналған көрсеткіштер бар. Таза, қатаң, терілген сүзгілеу енгізілді, мұнда біз бірінші деңгейдегі көрсеткіштерді қабылдаймыз, ал қалғандарын жай ғана тастаймыз. Біз бұл жүйені 2015 жылы осылай жоспарладық. Қазіргі уақытта не бар?
Презентация: мониторинг компоненттерінің өзара әрекеттесу диаграммасы
Ең алдымен, біз қолданбаларды бақылаймыз: біздің PHP кодымыз, қолданбаларымыз және микросервистер - қысқасы, әзірлеушілеріміз жазған барлық нәрсе. Барлық қолданбалар көрсеткіштерді UDP арқылы Brubeck агрегаторына жібереді (statsd, C тілінде қайта жазылған). Бұл синтетикалық сынақтарда ең жылдам болып шықты. Ол қазірдің өзінде жинақталған көрсеткіштерді TCP арқылы Graphite-ге жібереді.
Оның таймерлер деп аталатын көрсеткіштері бар. Бұл өте ыңғайлы нәрсе. Мысалы, қызметке әрбір пайдаланушы қосылымы үшін жауап уақыты бар метриканы Брюбекке жібересіз. Миллион жауап келді, бірақ агрегатор тек 10 көрсеткішті қайтарды. Сізде келген адамдар саны, максималды, минималды және орташа жауап беру уақыты, медиана және 4 процентиль бар. Содан кейін деректер Graphite-ге тасымалданады және біз оның барлығын тірі көреміз.
Сондай-ақ бізде аппараттық, бағдарламалық қамтамасыз ету, жүйелік көрсеткіштер және ескі Мунин бақылау жүйеміздегі көрсеткіштерді біріктіру бар (ол біз үшін 2015 жылға дейін жұмыс істеді). Біз мұның бәрін C's CollectD демоны арқылы жинаймыз (оның ішінде әртүрлі плагиндер бар, ол орнатылған хост жүйесінің барлық ресурстарын сұрай алады, конфигурацияда деректерді қай жерде жазу керектігін көрсетіңіз) және ол арқылы Graphite-ге деректерді жазыңыз. Ол сонымен қатар python плагиндері мен қабық сценарийлерін қолдайды, осылайша сіз өзіңіздің жеке шешімдеріңізді жаза аласыз: CollectD бұл деректерді жергілікті немесе қашықтағы хосттан (Curl деп есептегенде) жинайды және оны Graphite қызметіне жібереді.
Содан кейін біз жинаған барлық көрсеткіштерді Carbon-c-relay-ге жібереміз. Бұл C тілінде өзгертілген Graphite ұсынған Carbon Relay шешімі. Бұл агрегаторларымыздан жіберетін барлық көрсеткіштерді жинайтын және оларды түйіндерге бағыттайтын маршрутизатор. Сондай-ақ, маршруттау кезеңінде ол көрсеткіштердің жарамдылығын тексереді. Біріншіден, олар мен бұрын көрсеткен префикс схемасына сәйкес келуі керек, екіншіден, олар графит үшін жарамды. Әйтпесе олар құлап кетеді.
Carbon-c-relay содан кейін көрсеткіштерді Графит кластеріне жібереді. Біз метриканың негізгі сақтау орны ретінде Go бағдарламасында қайта жазылған Carbon-кэшті қолданамыз. Go-carbon өзінің көп ағындылығының арқасында Carbon-кэштен әлдеқайда асып түседі. Ол деректерді қабылдайды және оны Whisper бумасының көмегімен дискілерге жазады (стандартты, python тілінде жазылған). Біздің қоймалардан деректерді оқу үшін біз Graphite API пайдаланамыз. Бұл стандартты Graphite WEB-тен әлдеқайда жылдам. Бұдан әрі деректермен не болады?
Олар Графанаға барады. Біз графиттік кластерлерді деректердің негізгі көзі ретінде пайдаланамыз, сонымен қатар бізде метриканы көрсетуге және бақылау тақталарын құруға арналған веб-интерфейс ретінде Grafana бар. Әрбір қызмет үшін әзірлеушілер өздерінің бақылау тақтасын жасайды. Содан кейін олар өз қолданбаларынан жазған метрикаларды көрсететін олардың негізінде графиктер құрастырады. Графанадан басқа бізде SLAM да бар. Бұл графит деректері негізінде SLA есептейтін питон демоны. Жоғарыда айтқанымдай, бізде бірнеше ондаған микросервис бар, олардың әрқайсысының өз талаптары бар. SLAM көмегімен біз құжаттамаға өтіп, оны Graphite ішіндегімен салыстырамыз және талаптардың біздің қызметтеріміздің қолжетімділігіне қаншалықты сәйкес келетінін салыстырамыз.
Әрі қарай жүрейік: ескерту. Ол күшті жүйе - Moira арқылы ұйымдастырылған. Ол тәуелсіз, өйткені оның астында өз Графиті бар. «Контур» СКБ жігіттері әзірлеген, python және Go тілдерінде жазылған, толығымен ашық. Мойра графиттерге түсетін ағынды алады. Егер қандай да бір себептермен жад өліп қалса, ескертуіңіз жұмыс істей береді.
Біз Moira-ны Kubernetes-те орналастырдық; ол негізгі дерекқор ретінде Redis серверлерінің кластерін пайдаланады. Нәтижесінде ақауларға төзімді жүйе болды. Ол көрсеткіштер ағынын триггерлер тізімімен салыстырады: егер онда ешқандай ескертулер болмаса, ол көрсеткішті түсіреді. Осылайша ол минутына гигабайт метриканы қорыта алады.
Біз сондай-ақ оған корпоративтік LDAP қостық, оның көмегімен корпоративтік жүйенің әрбір пайдаланушысы бар (немесе жаңадан жасалған) триггерлер негізінде өздері үшін хабарландырулар жасай алады. Moira құрамында Графит бар болғандықтан, ол оның барлық мүмкіндіктерін қолдайды. Сондықтан сіз алдымен сызықты алып, оны Grafana-ға көшіріңіз. Деректердің графиктерде қалай көрсетілетінін қараңыз. Содан кейін сіз сол жолды алып, оны Мойраға көшіресіз. Сіз оны шектеулермен іліп, шығысында ескерту аласыз. Мұның бәрін жасау үшін сізге арнайы білім қажет емес. Moira SMS, электрондық пошта, Jira, Slack арқылы ескертеді... Ол сондай-ақ пайдаланушы сценарийлерінің орындалуын қолдайды. Оған триггер орын алғанда және ол реттелетін сценарийге немесе екілік файлға жазылғанда, ол оны іске қосады және осы екілік үшін stdin жүйесіне JSON жібереді. Сәйкесінше, сіздің бағдарламаңыз оны талдауы керек. Бұл JSON-мен не істеу сізге байланысты. Қаласаңыз, Telegram-ға жіберіңіз, қаласаңыз, Jira-да тапсырмаларды ашыңыз, бәрін жасаңыз.
Біз сондай-ақ ескерту үшін өз әзірлеуімізді пайдаланамыз - Imagotag. Әдетте дүкендердегі электронды баға белгілері үшін қолданылатын панельді қажеттіліктерімізге сай етіп бейімдедік. Біз оған Мойрадан триггерлер әкелдік. Ол олардың қандай күйде және қашан пайда болғанын көрсетеді. Кейбір әзірлеушілер осы панельдің пайдасына Slack және электрондық пошта хабарландыруларынан бас тартты.
Біз прогрессивті компания болғандықтан, біз Кубернеттерді де осы жүйеде бақылап отырдық. Біз оны кластерге орнатқан Heapster көмегімен жүйеге енгіздік, ол деректерді жинайды және оны Graphite-ге жібереді. Нәтижесінде диаграмма келесідей болады:
Мониторинг компоненттері
Міне, осы тапсырма үшін біз пайдаланған компоненттерге сілтемелер тізімі. Олардың барлығы ашық бастапқы код болып табылады.
Графит:
- көміртек:
- сыбырлап:
- графит-апи:
Көміртек-с-релесі:
Брубек:
Жиналған:
Моира:
Графана:
Үйінді:
Статистика
Міне, жүйенің біз үшін қалай жұмыс істейтіні туралы кейбір сандар.
Агрегатор (брюбек)
Көрсеткіштер саны: ~300 000/сек
Графитке метрика жіберу аралығы: 30 сек
Сервер ресурстарын пайдалану: ~ 6% CPU (біз толыққанды серверлер туралы айтып отырмыз); ~ 1 Гб жедел жады; ~3 Мбит/с LAN
Графит (көміртек)
Көрсеткіштер саны: ~ 1/мин
Көрсеткіштерді жаңарту аралығы: 30 сек
Метрикаларды сақтау схемасы: 30сек 35d, 5min 90d, 10min 365d (ұзақ уақыт ішінде қызметке не болатынын түсінуге мүмкіндік береді)
Сервер ресурстарын пайдалану: ~10% CPU; ~ 20 Гб жедел жады; ~30 Мбит/с LAN
Икемділік
Біз Avito-да бақылау қызметіндегі икемділікті бағалаймыз. Неліктен ол шынымен осылай болды? Біріншіден, оның құрамдас бөліктері бір-бірін алмастырады: компоненттердің өзі де, олардың нұсқалары да. Екіншіден, қолдау мүмкіндігі. Бүкіл жоба ашық бастапқы код болғандықтан, кодты өзіңіз өңдей аласыз, өзгертулер енгізе аласыз және қорапта жоқ функцияларды жүзеге асыра аласыз. Әдетте Go және Python стектері қолданылады, сондықтан бұл өте қарапайым.
Міне, нақты мәселенің мысалы. Графиттегі көрсеткіш файл болып табылады. Оның аты бар. Файл аты = метрика аты. Ал оған жетудің жолы бар. Linux жүйесіндегі файл атаулары 255 таңбамен шектелген. Ал бізде («ішкі тұтынушылар» ретінде) деректер базасы бөлімінің жігіттері бар. Олар бізге: «Біз SQL сұрауларымызды бақылағымыз келеді. Және олар 255 таңба емес, әрқайсысы 8 МБ. Біз оларды Grafana-да көрсеткіміз келеді, осы сұраудың параметрлерін көргіміз келеді және одан да жақсысы, мұндай сұраулардың жоғарғы жағын көргіміз келеді. Нақты уақытта көрсетілсе, тамаша болады. Оларды ескертуге қою өте жақсы болар еді ».
Мысал ретінде SQL сұрауы алынған
Біз Redis серверін орнаттық және Postgres-ке баратын және барлық деректерді сол жерден алып, Graphite-ге көрсеткіштерді жіберетін Collectd плагиндерімізді қолданамыз. Бірақ біз метрикалық атауды хэштермен ауыстырамыз. Біз бір уақытта бірдей хэшті Redis-ке кілт ретінде және бүкіл SQL сұрауын мән ретінде жібереміз. Бізге тек Графананың Редиске барып, осы ақпаратты ала алатынына көз жеткізу керек. Біз Graphite API ашамыз, себебі... бұл барлық бақылау компоненттерінің графитпен өзара әрекеттесуінің негізгі интерфейсі және біз оған aliasByHash() деп аталатын жаңа функцияны енгіземіз - Grafana-дан біз метриканың атын аламыз және оны Redis-ке кілт ретінде сұрауда қолданамыз. жауап ретінде біз кілттің мәнін аламыз, ол біздің «SQL сұрауымыз» « Осылайша, біз Grafana-да ондағы статистикамен (қоңыраулар, жолдар, жалпы_уақыт, ...) теориялық түрде көрсету мүмкін емес SQL сұрауының дисплейін көрсеттік.
Нәтижелері
Қол жетімділік. Біздің бақылау қызметіміз кез келген қолданбадан және кез келген кодтан тәулік бойы қол жетімді. Сақтау құралдарына рұқсатыңыз болса, деректерді қызметке жаза аласыз. Тіл маңызды емес, шешімдер маңызды емес. Сізге тек розетканы қалай ашу керектігін білу керек, онда метриканы қойып, розетканы жабу керек.
Сенімділік. Барлық құрамдас бөліктер ақауларға төзімді және жүктемелерімізді жақсы көтереді.
Кіру үшін төмен кедергі. Бұл жүйені пайдалану үшін сізге Grafana-да бағдарламалау тілдері мен сұрауларды үйренудің қажеті жоқ. Қолданбаңызды ашыңыз, оған көрсеткіштерді Graphite-ге жіберетін ұяшықты енгізіңіз, оны жабыңыз, Grafana бағдарламасын ашыңыз, сол жерде бақылау тақталарын жасаңыз және Moira арқылы хабарландырулар алып, көрсеткіштеріңіздің әрекетін қараңыз.
Тәуелсіздік. Мұның бәрін DevOps инженерлерінің көмегінсіз өзіңіз жасай аласыз. Және бұл артықшылық, өйткені сіз өз жобаңызды дәл қазір бақылай аласыз, ешкімнен сұраудың қажеті жоқ - жұмысты бастау немесе өзгертулер енгізу.
Біз нені мақсат етіп отырмыз?
Төменде келтірілгендердің бәрі жай ғана дерексіз ойлар емес, ең болмағанда алғашқы қадамдар жасалған нәрсе.
- Аномалия детекторы. Біз Graphite қоймаларына баратын және әр метриканы әртүрлі алгоритмдер арқылы тексеретін қызметті жасағымыз келеді. Қазірдің өзінде біз көргіміз келетін алгоритмдер бар, деректер бар, біз онымен қалай жұмыс істеу керектігін білеміз.
- Метадеректер. Бізде көптеген қызметтер бар, олар уақыт өте келе өзгереді, олармен жұмыс істейтін адамдар сияқты. Құжаттаманы үнемі қолмен жүргізу опция емес. Сондықтан біз қазір метадеректерді микросервисімізге ендіреміз. Онда оны кім әзірлегені, оның өзара әрекеттесетін тілдері, SLA талаптары, хабарландырулар қайда және кімге жіберілетіні көрсетілген. Қызметті қолдану кезінде барлық нысан деректері дербес жасалады. Нәтижесінде сіз екі сілтеме аласыз - біреуі триггерлерге, екіншісі Grafana-дағы бақылау тақталарына.
- Әр үйде бақылау. Барлық әзірлеушілер мұндай жүйені пайдалануы керек деп есептейміз. Бұл жағдайда сіз өзіңіздің трафикіңіздің қай жерде екенін, оған не болатынын, қай жерде құлап жатқанын, оның әлсіз жақтары қай жерде екенін әрқашан түсінесіз. Егер, мысалы, бірдеңе келіп, қызметіңізді бұзса, онда сіз бұл туралы менеджердің қоңырауы кезінде емес, ескертуден біле аласыз және сіз бірден соңғы журналдарды ашып, онда не болғанын көре аласыз.
- Жоғары өнімділік. Біздің жоба үнемі өсіп келеді және бүгінгі күні ол минутына 2 000 000 метрикалық мәнді өңдейді. Бір жыл бұрын бұл көрсеткіш 500 000 болды.Ал өсу жалғасуда, бұл біраз уақыттан кейін Графит (сыбырлау) дискінің ішкі жүйесін қатты жүктей бастайды дегенді білдіреді. Жоғарыда айтқанымдай, бұл бақылау жүйесі компоненттердің өзара алмасуына байланысты әмбебап болып табылады. Біреу Graphite үшін арнайы инфрақұрылымын сақтайды және үнемі кеңейтеді, бірақ біз басқа жолмен жүруді шештік: пайдалану метрикамыздың репозиторийі ретінде. Бұл өтпелі кезең дерлік аяқталды және жақын арада мен сізге мұның қалай жасалғанын егжей-тегжейлі айтып беремін: қандай қиындықтар болды және олар қалай еңсерілді, көші-қон процесі қалай өтті, мен байланыстыру ретінде таңдалған компоненттерді және олардың конфигурацияларын сипаттаймын.
Назарларыңызға рахмет! Тақырып бойынша сұрақтарыңызды қойыңыз, мен осында немесе келесі посттарда жауап беруге тырысамын. Мүмкін біреудің ұқсас бақылау жүйесін құру немесе ұқсас жағдайда Clickhouse-ға ауысу тәжірибесі бар - оны түсініктемелерде бөлісіңіз.
Ақпарат көзі: www.habr.com