Prometheus + Grafana коммерциялық APM-ның орнына: метрикалар, алерттер, SLO

Неліктен компаниялар коммерциялық APM-нан бас тартады

Көбіне коммерциялық APM-дан бас тартуға итермелейтін қарапайым себеп — шығындар пайдадан жылдам өседі. Лицензиялар, хосттар немесе телеметрия көлемі үшін төлем, жаңа модульдер үшін қосымша ақылар — және мониторинг күтпеген жерден IT‑бюджеттің ең қымбат тармақтарының біріне айналады.

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

Үшінші себеп — деректерге бақылау. Барлығына телеметрияны сыртқы бұлтқа жіберу жарамайды, әсіресе мемлекеттік және қаржы ұйымдары үшін.

Prometheus пен Grafana-ға көшу таныс тәртіпті өзгертеді. Әзірлеушілер «нені өлшейміз» және «қандай SLI сапаны көрсетеді» туралы ойлай бастайды, APM-дегі «қандай батырманы басу керек» емес. Операция бөлімі жинау, сақтау және агрегация ережелерін түсінікті әрі версияланатын деп санайды. Қолдау үшін де әдетте оңайырақ болады, егер алерттер мен дашбордтар ішкі техникалық оқиғалар емес, қолданушыға ауырсыну тудыратын заттарды (қателер, кешігулер, қолжетімсіздік) сипаттаса.

2–4 апта ішінде, жұмыс көлемі қалыпты болса, айқын нәтиже алуға болады: сервис пен инфрақұрылым бойынша базалық дашбордтар (қателер, кешігулер, жүктеме, ресурстар қанығуы), алғашқы пайдалы алерттер шуасыз және бизнеспен қарапайым SLO арқылы ортақ тіл (мысалы, қолжетімділік және кілттік операциялардың жылдамдығы).

Шекараларды түсіну маңызды. Prometheus пен Grafana — анық метрикалар, өз алерт ережелері және деректерге бақылау қажет болғанда керемет таңдау. Олар Kubernetes-ке де, классикалық инфрақұрылымға да (серверлер, дерекқорлар, API) жақсы үйлеседі.

Егер сізге «қораптан» терең таратылған трассировка, кодты профайлинг, автоматты root cause анализі және бай аналитика қажет болса, басқа шешім керек болуы мүмкін. Осындай жағдайда open source стек көбіне трассировкалар мен логтар үшін қосымша құралдармен толықтырылады, ал Prometheus + Grafana метрикалар мен SLO негізі ретінде қалады.

APM-сыз не жоғалады және оны қалай жабуға болады

Prometheus + Grafana-ны коммерциялық APM-ның орнына таңдасаңыз, метрикалар бойынша мықты база аласыз, бірақ кейбір таныс мүмкіндіктер жоғалады. Бұл апат емес, егер ол саңылауларды алдын ала түсініп, қарапайым қоспалармен жабсаңыз.

APM‑да көбіне жетіспейтіндер:

• Сұраныстың бойлық трассасы (қай жерде уақыт жоғалып жатқанын көрсету)
• Профайлинг (код ішінде нені CPU немесе жады ауырлатып жатқанын көрсету)
• Қателерді нақты сұраулар мен қолданушылар деңгейінде талдау
• Логтар, метрикалар және трассировкаларды бір экранға автоматты түрде біріктіру

Алайда бизнес көбіне трассировкалар үшін келмейді. Алғашқы сұрақтар практикалық болады: жүйе қолжетімді ме, қаншалықты баяу, қанша қате болды, қанша уақытқа түсіп қалды және мәселені бірінші кім байқап қалды.

APM-ның кейбір мүмкіндіктерін стекке тым ауырлатпай толтыруға болады: метрикалар, логтар және минималды трассировкаларға көңіл бөліңіз.

Прачтикалық бастапқы жинақ:

• Метрикалар: қолданбаның бірнеше кілт көрсеткіштерін қосыңыз (кешігулер, қателер жиілігі, жүктеме) инфрақұрылымдық көрсеткіштер үстіне.
• Логтар: бірыңғай формат енгізіңіз (уақыты, сервис, request_id, деңгей, хабарлама) және қате дегенде не саналатынын келісіңіз.
• Базалық трассировкалар: бір критикалық сценариден бастаңыз (мысалы, аутентификация немесе өтініш беру) және сервистер арасында бір корреляция (request_id).
• Инцидент контексті: алертте пайдаланушыға нақты не "сыртылғанын" көрсетіңіз (мысалы, 5xx өскен және p95 кешігу шектен жоғары).

Мониторинг жауапкершілігінің шекарасын келісу де маңызды. Мониторинг ерте анықтауға және анық сигнал беруге жауапты (не, қай жерде, қаншалықты нашар). Ол автоматты түрде код жолына дейінгі біртіндеп басты себепті түсіндірмейді. Негізгі себептер үшін адамдар, логтар, кейде профайлер және бөлек диагностика қажет.

Реализмді тексерудің жақсы көрсеткіші: алерт бойынша 5 минут ішінде үш сұраққа жауап бере аласыз ба — бұл клиентке әсер етеді ме, жаңа мәселе ме әлде қайталама ма, және кім жөндеуге барады (сервис, дерекқор, желі, темір). Егер иә болса, APM-ның жоқтығы ұйықтауға кедергі болмайды.

Алғашқы метрикалар: максимум пайда беретін 4 сигнал

Prometheus + Grafana мониторингі үшін бастапқыда төрт сигналдан бастау ыңғайлы: кешігулер (latency), трафик, қателер және қанығу (saturation). Олар дежурныйдың негізгі сұрағына жауап береді: проблема қосымшада ма, тәуелділікте ме немесе ресурста ма.

Ең алдымен не өлшеу керек

Latency (кешігу). Пайдаланушының шын сезетін жерінде өлшеңіз: API кіруінде (HTTP/gRPC), фондық тапсырма орындауында және негізгі сыртқы шақыруларда (ДҚ, кезек, сыртқы сервис). Орташа көрсеткіш алдауы мүмкін, сондықтан перцентилдерді қараңыз: p50 (әдет), p95 (көптеген проблемалар), p99 (ең ауыр хвосттар). Егер бір endpoint баяу, ал қалғандары тез болса, барлық сервис бойынша жинақталған метрика бұл баяуны жасыра алады.

Traffic (жүктеме). «Пакеттер» немесе CPU емес, іскерлік жүктемені санап отырыңыз: сұраныстар/сек (RPS), орындалған тапсырмалар саны, өңделген құжаттар, транзакциялар. Жалпы ағым мен кілттік маршруттар/тапсырмалар бойынша тікелей бөлініс болуы маңызды — бір жерде болатын жарылыс «бәрі жақсы» сияқты көрініп қалмас үшін.

Errors (қателер). Қате деген тек 500 емес. 4xx-ті бөлек есептеңіз (көбіне бұл өнімдік немесе интеграция мәселесі), таймауттар, отменалар, ретраи, қолданбадағы ерекшеліктер, ДҚ қатесі. Түрлері бойынша бөліңіз, жай ғана «error=true» десеңіз, нақты не істен шыққанын түсінбейсіз.

Saturation (қанығу). Ресурстың шегі жеткен бе — бірақ ол әлі құлап кетпеген кезең туралы. Очередь ұзындығы, байланыс пулдарының толуы, кезекте күту уақыты, CPU steal (виртуализацияда), iowait, жұмысшы-нутектердің жүктемесі сияқты көрсеткіштерге қараңыз. Мысалы, S200 деңгейіндегі стойкада сервис RPS‑ты ұстап тұруы мүмкін, бірақ кезектің өсуі және ДҚ пулындағы күту таймауттардың жақында болатынын көрсетеді.

Меткалар — кардиналдықты жарылтпау үшін минималды жиын

Метрикалар пайдалы әрі Prometheus‑ты «қарқынды етпеуі» үшін меткаларды минималды және тұрақты ұстаңыз. Жақсы базалық жиын әдетте:

• service (сервис атауы)
• endpoint немесе route (id-сіз жол шаблоны)
• method (GET/POST)
• status_class (2xx/4xx/5xx) немесе егер кодтар аз болса, нақты код
• dependency (сыртқы тәуелділіктің атауы: db, queue, auth)

Жоғары бірегейлікке ие меткалардан аулақ болыңыз: user_id, request_id, толық URL, қате мәтіні, файл атаулары — олардың орны логтар мен трассировкаларда.

Инфрақұрылым: серверлер мен орта үшін базалық метрикалар

Коммерциялық APM жоқ кезде инфрақұрылымдық метрикалар ең алғаш болып не болып жатқанын көрсетеді: нақты жүктеменің өрлеуі, қоршаған ортадағы ақау немесе баяу деградация. Инцидент кезінде көмектесетін минимум жинау маңызды, тек графикте әдемі көріну емес.

Төрт аймақтан бастаңыз: CPU, жад, диск және желі. Әр аймақ үшін «жалпы пайыз» емес, пайдаланушыға тікелей әсер ететін қанығу мен кешігулерді қараған жөн.

• CPU: ядролар бойынша жүктеме, iowait (диск күтуі), тапсырма кезегі (load). Жоғары % CPU әрқашан мәселе емес, ал жоғары iowait көбіне диск проблемасын көрсетеді.
• Жад: қолжетімді жад, swap (пайдалану және белсенділік), major page faults. Кэштен туындаған «аз бос жад» қалыпты болуы мүмкін, ал swap пен faults өсуі жады ағызылуын немесе RAM жетіспеушілігін білдіреді.
• Диск: бос орын, оқу/жазу жылдамдығы, кешігулер (latency), диск жүктемесінің уақыты (util), қателер саны. Инциденттер көбіне «0% орын» емес, кешігулердің өсуімен басталады.
• Желі: кіріс және шығыс трафик, қателер мен дроптар, қайта жіберулер (бар болса), маңызды тораптарға дейінгі кешігулер. Тек «қанша Мбит» емес, сапаны көру пайдалы.

Қалыпты жүктеме өсуін қалай ажыратуға болады? Сұраныс пен қанығуды салыстырыңыз. Егер трафик пен CPU өсіп, бірақ диск кешігулері мен қателер болмаса — бұл қалыпты пик. Егер жүктеме тұрақты, ал диск latency, swap немесе желі дроптары біртіндеп өсіп жатса — бұл деградация. Жады ағызылуы үшін біртіндеп өсіп отыратын тұтыну және swap/рестарттар тән.

VM және Kubernetes үшін «тар жерді» көрсетуге арналған қабат қосыңыз. Виртуализацияда steal time, сақтау қысымы және көршілерден шу маңызды. Kubernetes-та node метрикаларымен қатар requests/limits, перезапустар, CPU throttling және PVC астындағы диск жағдайын қараңыз. Олай болмаған жағдайда «ресурс аз» пен «қосымша лимиттерді жеп қойды» жайлы ұзақ талас болады.

Егер датчиктерге қолжетімділік болса, қуат пен температура метрикалары ерте сигнал береді. Қызу, вентилятор деградациясы немесе қуаттағы ақаулар кейде сервис құлаудан бұрын көрінеді. Бұл стойкадағы серверлер мен СХД үшін өте пайдалы.

Әртүрлі орындар мен командалар бір нәрсені қарасын десеңіз, дашбордтардың бірыңғай форматын келісіңіз: панелдердің бірдей атаулары, бірдей шекті мәндер және бірдей лейблдар (орын, рөл, сервис). Содан кейін дата‑центрлерді салыстыру минуттар емес, тек минуттар алады.

Қосымшалар мен деректер метрикалары: аппарат үстіне не қосу керек

CPU мен жады «сервер неге нашар» дегенге жауап береді. Бірақ көбіне сұрақ басқа: «пайдаланушы неліктен баяу» және «шылбырдың қай жері сынған». Оны түсіну үшін аппараттан үстіне қосымша мен тәуелділіктердің метрикаларын жинаңыз.

Минималды жиын қабаттар бойынша жинауды жеңілдетеді — себебі себепті табу оңай.

• HTTP/gRPC қабаты: сұраныстар жиілігі (RPS), қателер үлесі (код/статус бойынша), перцентильдер бойынша кешігулер (p95/p99), таймауттар, жауаптардың өлшемі.
• Кезектер және фондық тапсырмалар: кезек ұзындығы, тапсырманың басталуына дейінгі күту уақыты, ретраи саны, қатеге түскен тапсырмалар үлесі.
• Дерекқор: белсенді қосылыстар және қосылыстар кезегі, баяу сұраныстар (ең ұзақтар тізімі), блокировкалар және күту, репликация лагы (бар болса).
• Кэш: hit rate, оқу/жазу кешігуі, толуы, eviction (шығарулар).
• Іскерлік метрикалар: инженер емес адамдарға түсінікті 1–2 көрсеткіш. Мысалы, «минутына сәтті төлемдер» немесе «өтініш өңдеу уақыты».

Кішкентай мысал: өтініштерді өңдеу жүйесінде API жауап уақыты p99 = 5 секундке дейін өсті. Инфрақұрылым қалыпты. Метрикалар фондық тексеріс кезектерінің өскенін және ретрайлдардың көбеюін, ал ДҚ‑да блокировкалардың және репликация лагының артқанын көрсетеді. Тізбек анық: фондық тапсырмалар жиналып, деректерді қайта оқыған сайын ДҚ блокталып, пайдаланушылар күтуге мәжбүр.

Метрикалар шулы болмауы үшін оларды «таза» ұстаңыз:

• кешігу гистограммаларымен өлшенсін және p95/p99 қаралсын, тек орташа емес;
• меткаларды шектеңіз (user_id, order_id сияқты бірегей мәндерді қоспаңыз);
• 4xx (пайдаланушы қателері) мен 5xx (сервис қателері) бөлінсін;
• тәуелділіктерді бөлек өлшеңіз (ДҚ, кэш, сыртқы API), тек жалпы уақытты ғана емес.

Осындай жиын диагностикаға және болашақ SLO үшін өлшеуге жеткілікті көрсеткіш береді: сіз «пайдаланушыға сәтті және тез» қалай екенін өлшей аласыз, тек «сервер қосулы ме» де емес.

Қадам-қадам баптау: Prometheus және Grafana үшін минималды конфигурация

Көп графиктен емес, түсінікті минимумнан бастаңыз. Бірінші аптаның мақсаты — ең маңызды сервистердің денсаулығын сенімді түрде көру және анық ақауларды тез табу.

Алдымен 5–15 компоненттен тұратын шағын мақсат жиынтығын таңдаңыз: әдетте бизнес үшін «тоқтаса» маңызды кіру API, кезек, дерекқор, негізгі воркерлер, балансировщик және бірнеше критикалық сервер жеткілікті.

1) Метрикаларды жинау: жұмыс істейтін минимум

Жинауды жеңіл ұстап, оны қолдау оңай болатындай ұйымдастырыңыз:

• Жедел нәтиже беретін жерде exporters қойыңыз: серверлер үшін node_exporter, дерекқор үшін сәйкес exporter (мысалы, Postgres exporter) және қосымша метрикалары (HTTP, қателер, жауап уақыты).
• Мүмкін жерде service discovery баптаңыз (Kubernetes, Consul, cloud‑тагтар). Егер жоқ болса, статикалық тізімнен бастаңыз, бірақ оны кім жаңартайтынын айқындап қойыңыз.
• Scrape жиілігін мағыналы таңдаңыз: пайдаланушы API үшін 15–30 секунд, инфрақұрылым үшін 30–60 секунд, «баяу» жүйелер үшін сирек.
• Бірдей меткалар жиынтығын келісіңіз: service, instance, environment, team. Осысыз дашбордтар мен алерттер тез хаосқа айналады.

Сақтау туралы: Prometheus-пен бастау оңай — retention 7–15 күннен бастаңыз, кейін көлемді бағалаңыз. Ұзақ тарих үшін әдетте remote storage қосылады, бірақ бастау кезінде «мәңгі сақтау» емес, тұрақты жинау және деректерді түсіну маңызды.

2) Алғашқы дашбордтар және сапа бақылауы

Төрт қарапайым экран жинаңыз: жалпы шолу (барлық сервистер), сервис бойынша (бір сервиске егжей‑тегжейлі), инфрақұрылым (CPU, RAM, диск, желі) және дерекқорға арналған бөлек экран.

Алерт жазбас бұрын деректер сапасын тексеріңіз:

• графиктерде тесік жоқ па (графиктердегі үзілістер жиі жинау проблемасын білдіреді);
• өлшем бірліктері бірдей ме (секунд vs миллисекунд, bytes vs MiB);
• кардиналдық жарылыс жоқ па (user_id, request_id сияқты меткалар Prometheus-қа арналмаған);
• командалар арасында метрика және метка атаулары сәйкес пе.

Мысал: GSE S200 деңгейіндегі стойкада "API баяу" деген шағым шын мәнінде iowait пен диск толуына байланысты екенін бір экраннан көруге болады — ауыр APM қажет емес.

Шусыз алерттер: уақытты үнемдейтін ережелер

Ең үлкен қателік — барлығына алерт қою. Жақсы алерт жай ғана «бірдеңе болды» деп хабарламайды. Ол: «пайдаланушыға нашар әсер етті және бұл дереу әрекет етуді талап етеді» деп айтады.

Симптомдардан бастаңыз, себептерден емес. Симптомдарға 5xx өсуі, сәтті сұраныстардың азаюы, кешігулердің өсуі және фондық тапсырмалардың орындамауы жатады. Себептер (CPU, жады, диск, желі) — диагностика үшін. Сондықтан алғашқы алерттерді сырттан көрінетін нәрсеге қойыңыз, ал себептерді дашбордта көрсетіңіз.

Порогтарды «әдеттен ауытқу» ретінде қойыңыз, қайсыбір әдемі сан үшін емес. Көп жағдайда салыстырмалы шектер мен перцентильдер жақсы жұмыс істейді: мысалы, p95 кешігуі қалыптан жоғары немесе қателер пайызы күндегі орташаға карағанда 3 есе өсуі. SLO болғанда burn rate ұғымы ыңғайлы: қазір қанша «қате бюджетін» жұмсап жатырмыз. Сол кезде алерт бір ғана оқиғаға емес, деградация қарқынына реакция жасайды.

Қысқа уақыттық шыбықтар адамдарды оятпауы керек. Уақытты терезелер мен кешіктірулерді қолданыңыз: «5–10 минут бойы тұрақты түрде» деген ереже көп шуықты жояды. Флапайтын метрикалар үшін ескерту және критикалық алертті әртүрлі терезелерде бөлу пайдалы.

Бір инциденттің ондаған хабарламаларға айналуын болдырмас үшін Alertmanager-де группалау мен дедупликация орнатыңыз. Сервис деңгейінде (service, cluster, environment) мағыналы меткалармен топтаңыз, pod немесе instance бойынша емес. Бір сервис құлаған болса — бір хабарлама, оның ішінде зақымданған компоненттер тізімі бар.

Әр алерт әрекетке апаруы тиіс. Алерт сипаттамасында ең төменгі runbook:

• Пайдаланушыларға әсер бар-жоғын тексеріңіз: қателер, p95/p99, сәтті сұраныстар.
• Не өзгерді: релиз, конфигурация, сыртқы тәуелділік.
• Зиянды шектеу: роллбек, функцияны өшіру, запас контурға ауысу.
• Талдау үшін деректер жинау: графиктер, логтар, басталған уақыт.
• Егер 15 минут ішінде шешілмесе — алдын ала келісілген эскалация бойынша қозғалыңыз.

Осылайша алерттер сирек, түсінікті және пайдалы болады, дежурство тыныш өтеді.

Бизнеспен SLO: артық математикасыз келісу

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

SLI — пайдаланушы көзімен не өлшейміз

SLI — пайдаланушы тәжірибесін көрсететін бір сандық өлшем. «CPU 80%» емес, «операция сәтті және тез өтті». Көбісі үшін екі-үш SLI жеткілікті:

• Қолжетімділік: сәтті сұраныстардың үлесі (мысалы, HTTP 2xx/3xx)
• Кешігу: белгілі бір шектен тез өтетін сұраныстардың үлесі (мысалы, 95% сұраныстар 500 мс-тан тез)
• Қателер: 5xx немесе бизнес қателерінің үлесі (төлем өтпеді, тапсырыс құрылмады)
• Насығу: кезектер немесе таймауттар, олар тікелей сәтсіздікке әкеледі

SLI‑ді пайдаланушы ауырсынатын жерде есептеңіз. Әдетте бұл ingress, API gateway немесе кілттік endpoint.

SLO — не уәде етеміз және қандай кезеңде

SLO — бұл белгілі бір кезеңге берілген сапа кепілі: «ай ішінде 99.9% сәтті сұраныс». Кезең керек, себебі сирек инциденттер күнделікті дүрбелеңге айналмауы тиіс. Ішкі сервистер үшін апта белсенді таңдалуы мүмкін, сыртқы үшін ай жиі қолданылады.

Содан кейін error budget пайда болады: SLO 99.9% болғанда кезең ішінде 0.1% сұраныс «жаман» болуға рұқсат. Бұл компромисс — неғұрлым жоғары кепілдік, соғұрлым сенімділікті қамтамасыз етуге көбірек уақыт пен ақша қажет және өзгерістерді шығаруды қиындатады. Error budget таусылғанда бизнес таңдайды: релиздерді тоқтатып, тұрақтылықты қалпына келтіру ме, әлде қауіпке бару ма.

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

Келісімді жеңілдету үшін әр сервиске 2–3 SLO қойыңыз және инциденттің не екенін анық жазыңыз:

• негізгі операцияның қолжетімділігі (кезең бойынша)
• негізгі операцияның кешігуі (перцентиль және шек)
• қалпына келтіру уақыты (мысалы, 90% инциденттер N сағат ішінде жабылсын)

Бұл бизнестің сапаның бағасын түсінуіне және командаға алерт пен жұмыс жоспарын орнатуға жеткілікті.

Мысал сценарий: метрикалардан SLO және алерттерге

Мысалы, қызмет: қызметкерлер ішкі порталы — өтініштер беру, IT және кадр сұранымдары. Әдетте жүктеме тұрақты, бірақ әр дүйсенбі таңертең және айдың аяғында пики болады. Команда коммерциялық APM-нан Prometheus пен Grafana-ға ауыстырғысы келеді, және бизнес нені қалыпты санайтынын түсінуі тиіс.

SLI-ден бастаңыз, олар пайдаланушы көретін нәрсемен сәйкес болуы тиіс. Портал үшін әдетте үші жеткілікті:

• Қолжетімділік: жауап алған сұраныстар үлесі (5xx және таймаут емес)
• Жауап уақыты: негізгі операция бойынша p95
• Операцияның сәттілігі: бизнес мағынасы бар сәтті әрекеттердің үлесі (өзі орындалғаны, жай ғана 200 қайтарылды емес)

Содан кейін айға SLO формулаңыз: мысалы «айға қолжетімділік 99.9%, p95 құжат жасау 1.2 секундтан аспауы тиіс, сәттілік 99.5% кем емес».

Grafana‑да пайызбен қатар «қандай минуттар жоғалтуға болады» деген көрсеткіш көрсету ыңғайлы. Мысалы, 99.9% үшін айда шамамен 43 минут қолжетімсіздік рұқсат етіледі. Бұл бизнеске цифрлар төңірегінде дауласпай, уақыт лимитін көрсетуге көмектеседі.

Алерттер: Alertmanager‑тің шусыз жұмыс істеуі үшін екі деңгей пайдалы: тез симптомды алерт және баяу тренд туралы ескерту. Тезі нақты пайдаланушыға ауырсынуды дереу ұстайды, баяуы деградация туралы ескертеді, бірақ түнгі жалған сработкаларды қоздырмайды.

Мысал алерттер жиыны:

• Тез: кіріс пен өтініш жасауда 5xx немесе таймауттар 5 минут ішінде 2%-дан жоғары.
• Тез: өтініш жасау p95 5 минут бойы 2 секундтан жоғары.
• Баяу: p95 аптадан аптаға өсіп жатыр (мысалы, сағаттық p95 базалықпен салыстырғанда 30% жоғары 2 сағат бойы).
• Баяу: тапсырмалар кезегі немесе ДҚ байланыс пулдары лимитке жақын 30–60 минут бойы.

SLO бұзылғанда error budget ұғымы іске қосылады — бұл «рұқсат етілген ақаулар қоры». Егер бюджет жоспардан ерте таусылып жатса (мысалы, айдың 10‑ына дейін 70% жұмсалды), алдын ала не болатынын келісіңіз.

Әдетте осындай тәртіп жұмыс істейді:

• Релиздерді тоқтату, тек инцидентті түзетуге арналған релизтерге рұқсат.
• 1–2 аптаға техбордтар мен жақсартулар жоспары (сұраныстарды оңтайландыру, кэш, лимиттер, ретраи).
• Алерттер мен дашбордтарды қайта қарау: не көмектемеді, не артық болды.
• Кілт SLI тұрақтанғаннан кейін ғана feature‑да жұмысқа қайта оралу.

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

Қысқаша чек‑лист және келесі қадамдар

Бастапқы метрикалар мен дашбордтарды орнатқаннан кейін процесті тез бекіту керек, әйтпесе мониторинг хаосқа айналып, алерттер шу тудырады.

Іске қосу чек‑листі (1–2 күн)

Тек техника емес, жауапкершілікті де тексеріңіз: кім жауап береді, кім шешім қабылдайды, кім қолданушылармен байланысады.

• Кілт сервис үшін 4 сигнал жиналған: кешігулер, қателер, трафик, ресурстардың қанығуы.
• 2–3 дашборд бар: сервис шолу, инфрақұрылым, тәуелділіктер (ДҚ, кезек, сыртқы API).
• Алғашқы алерттер тек пайдаланушы симптомдарына және ресурстардың сарқылу тәуекелдеріне қойылған (кешіктіріп және дубликаттарды басып тастайтын баптаулармен).
• Әр алерттің иесі және алғашқы 10 минутта не істеу керек деген нақты әрекет көрсетілген.
• Дежур кестесі мен эскалация каналы анықталған.

Инцидент чек‑листі (алғашқы 15 минут)

Локалдық сервис мәселесі ме әлде инфрақұрылымның жалпы сәтсіздігі ме — сол сұрақтан бастаңыз.

• Пайдаланушы не көріп тұр: 5xx өсуі, таймауттар, жылдамдықтың төмендеуі, операциялар сәтсіздігінің өсуі.
• Қай жерде тар жəнеу: CPU, жады, диск, желі, контейнер лимиттері, ДҚ байланыс пулдары, кезек.
• Не өзгерді: релиз, конфигурация, миграция, жүктеменің өсуі, провайдердің немесе сыртқы серіктің істен шығуы.
• Тәуелділіктерде не болып жатыр: дерекқор (қосылыстар, кешігулер), кэш, брокер.
• Қалай шұғылы шектеу жағымды: уақытша шара (мысалы, ауыр фичаны өшіру), кейін себепті тапқасын бэклогқа тасымалдау.

Ай сайынғы ритм орнатыңыз: SLO‑ларды бір рет ай сайын қарап шығыңыз (олар тым жұмсақ немесе жетпейтін болды ма), шулы алерттерді жою, меткалардағы кардиналдықты тексеру (әсіресе user_id, URL параметрлері, trace_id) және дашбордтарды жаңа тәуелділіктерге бейімдеу.

Пилоттан кейінгі келесі қадам көбіне инфрақұрылым мен қолдауға ойынып тіреледі: Prometheus, Grafana және метрикалар сақтау сенімді жұмыс істеуі үшін тұрақты платформа және олардың қолдауы жауапқа алынуы тиіс. Осындай жобаларда GSE.kz (gse.kz) кейбір «жер жұмыстары» — мониторингке арналған серверлер S200 орнату, платформалық жүктемелерді орналастыру және 24/7 интеграция мен қолдау көрсету арқылы көмектесе алады.