Интеграциялар мен кезектерді бақылау: метрикалар мен алерттер шусыз

Нақты мәселе неде: хабарламалар мен уақыт қай жерде жоғалып жатыр

Бизнес көбінесе «брокер істен шықты» дегенді емес, симптомды көреді: тапсырыс жетпей қалды, статус 30 минуттан кейін жаңарды, төлем екі рет өтті, хабарлама басқа адамға кетті. Командаларда бұл жиі «Kafka/MQ істен шықты» деп айтылады, бірақ уақыт көбіне шекараларда жоғалады: продьюсер жібермеді, консьюмер өңдемеді, ретрайлер ағынды тұйықтады, ал «өлген» хабарламалар DLQ-ға түсіп, байқалмай жатады.

Олай болатыны — көп графиктер оңай алынатын нәрсені көрсетеді (CPU, жад, жалпы throughput), бірақ инцидентте көмектесетінін көрсетпейді. Пайдаланушылар кешігу туралы шағымданғанда "секундтағы хабарламалар" графигі мінсіз болуы мүмкін. Ал дубликат болғанда, брокер метрикалары мәселені байқамауы мүмкін: ол ретрайл, дедупликация логикасында немесе өңдеушінің ішінде пайда болады.

Наблюдаемость (бақылау) — жай графиктер жиынтығы емес; ол төрт сұраққа жауап беруі керек: не істен шықты, қай жерде, қашан бастап және қанша нақты операция зардап шекті. Бұған «продьюсер — брокер — консьюмер — сыртқы жүйе» жолы бойынша сквозной бақылау керек, тек "кезек тірі" дегеннен гөрі.

Жұмыс істейтін мониторинг — "50 дашборд" емес. Ол себепке тез жетелейтін бірнеше түсінікті сигналдар: негізгі ағындар бойынша кешігулер, қателер мен ретрайлердің үлесі, дубльдер мен идемпотенттілік бұзылыстары, сондай-ақ DLQ — қоқыс емес басқаратын карантин.

Егер осы сигналдар бизнес-операцияларға байланса (мысалы, «заявка құру», «төлем жүргізу», «статусты жаңарту»), себепті табу минуттарда, сағаттарда емес, минуттарда шешіледі.

Қарапайым интеграция моделі: метрикалар бір тілде сөйлесін

Мониторинг бөлшектеніп кетпеуі үшін бір қарапайым модельге келісу пайдалы. Кез келген кезекте немесе топикте үш рөл бар: продьюсер (жіберуші), брокер (сақтайтын және тарату), консьюмер (оқып, әрекет жасайтын). Кешігу әр қадамда пайда болуы мүмкін, және метрикалар дәл қай жерде екенін көрсетуі тиіс.

Хабарламаның жолын қарапайым түрде ойлаңыз:

• A жүйесі оқиға жасады және жіберуге тырысты.
• Брокер қабылдап, сақтап қойды.
• Консьюмер оқып, өңдеді.
• B жүйесі әсерді алды (дерекқорға жазба, статус өзгерісі, хат жіберу).

Ack деген — консьюмер брокерге «мен өңдедім, жеткізілді» дейді. Егер ack жоқ болса, ретрайлер іске қосылады: қайтадан жеткізуге немесе өңдеуге талпыныстар.

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

Дубликаттар екі жерде жиі туындайды: қайта жіберу кезінде (продьюсер брокердің қабылдағанынан сенімді емес) және қайта өңдеу кезінде (консьюмер әрекет жасап, бірақ ack жібермей құлаған). Сондықтан бір метрика жеткізілімге жауап беруі керек, ал басқа әсерге жауап беруі тиіс.

DLQ (dead letter queue) — қалдық емес, карантин болу керек: онда бірнеше рет өңделмейтін хабарламалар түседі. DLQ-да түсінікті себеп, талпыныстар саны және иесі болуы тиіс, ол хабарламаны қайта өңдеуге немесе мәліметті түзеуге шешім қабылдайды.

Сквозной бақылау бір correlation өрісінен басталады (мысалы, orderId немесе requestId). Ол A жүйесіндегі оқиғаны B жүйесіндегі нәтижемен байланыстырады және толық жолды өлшеуге мүмкіндік береді, тек «брокерде жатыр» ғана емес.

Кешігулердің метрикалары: пайдаланушының нақты әбзалы қайда

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

End-to-end latency: оқиғадан нәтижеге дейін өлшеу

Ең пайдалы метрика — сквозная кешігу: көздің оқиға жасаған сәтінен бастап мақсатты жүйе нәтижені растағанға дейінгі уақыт (дерекқорға жазба, құжат жасалуы, хабар жіберілуі). Практикада бұл хабарламадағы timestamp және консьюмер логикасындағы «финиш» жазбасын (немесе жауап оқиға) тіркеу арқылы іске асады.

Қарапайым мысал: сервис шот шығарды 10:00:00 — бухгалтерия оны 10:07:30 көрді. Сквозная кешігу — 7 минут 30 секунд, тіпті брокер «жақсы» болса да.

Consumer lag: пайдалы, бірақ бизнес кешігуіне тең емес

Consumer lag — тұтынушының партициядан қаншалықты артта қалғанын көрсетеді. Бұл қысым индикаторы, бірақ нақты бір хабарламаның қанша күтіп тұрғанын айтпайды. Lag жоспарлы жүктеме кезінде үлкен болуы мүмкін, ал пайдаланушылар оны байқамайды. Керісінше, lag кіші болуы мүмкін, бірақ бір «ескі» хабарлама өңдеуде тұрып қалуы ықтимал.

Күту уақытын ұстау үшін көбіне age of oldest message (ең ескі өңделмеген хабарлама жасы) көмектеседі. Оның шектік мәндерін қою оңай: егер «ең ескі» 10 минут болса, біреу анық күтіп отыр.

Орташа кешігуді басты сигнал ретінде қолданбаңыз. Перцентильдерді (p95, p99) қараңыз: проблемалар көбіне құйрықта болады, 1–5% хабарлама процессін баяулатуы мүмкін.

Және кешігулерді оқиға түрлері мен негізгі кезектер бойынша бөлек есептеңіз. «Авторизация» мен «түнгі жіберілімнің» күтілетін уақыты әртүрлі, ал жалпы график шынайы проблеманы жасыра алады.

Сенімділіктің метрикалары: қателер, ретрайлер, дубльдер және DLQ таза көріністе

Кезектер мен интеграцияларда сенімділік жиі «брокерде» емес, өңдеушілерде: код, тәуелділіктер, деректер. Сондықтан бақылауда болуы тиіс метрикалар — хабарламалар нәтижеге жетті ме, әлде талпыныстарда қатып қалды ма деген сұраққа жауап беретіндер.

Өңдеу қателері мен ретрайлер

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

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

Пайдалы практикалық метрикалар:

• қатемен аяқталған хабарламалардың пайызы (қателер типтері бойынша бөлініс);
• хабарламаға орташа және p95 бойынша әрекеттер саны;
• бірінші талпыныстан сәтті өңдеуге дейінгі уақыт;
• N минуттан артық ретрайлерде тұрған хабарламалар саны.

DLQ, poison message және дубльдер

DLQ жүйенің «жеңілмегенін» көрсетеді. DLQ көлемін ғана емес, ең ескі хабарламаның жасын да қадағалаңыз: толық DLQ онша қорқынышты емес, ал апта бойы ешкім қарамайтын DLQ — қауіпті.

Poison message әдетте бірдей кілт/идентификатор бойынша анықталады, ол үнемі DLQ-ға түседі немесе бірдей қатені тудырады. Егер бір хабарлама 30% қателік берсе, бұл жиі деректер мәселесі, жүйенің тұрақсыздығы емес.

Дубликаттар ақша, лимиттер, статустар мен қорлар бар жерде қауіпті. Оларды бизнес-кілтпен немесе idempotency key арқылы және уақыт терезесі бойынша есептейді (мысалы, төлем нөмірі).

Шуды аз қалдыратын пайдалы алерттер:

• DLQ-ға түсу жылдамдығы базадан жоғары;
• DLQ-дегі ең ескі хабарламаның жасы шектен жоғары;
• әрекеттер саны \u003e X болатын хабарламалардың үлесі бірнеше аралықта өсіп жатыр;
• бизнес-кілт бойынша дубльдер нормадан асты;
• бірдей кілт бойынша бірдей қате N рет қайталанады.

Өткізу қабілеті мен ресурстар: себеп пен салдарды шатастырмау үшін

Кешігу басталғанда диагноз қою оңай: брокер «жіктелмей тұр» деп ойлайсыз, ал шын мәнінде консьюмерлер жетіспейді немесе желі мойындамай жатыр. Сондықтан тек "кезекте қанша хабарлама" қарамай, ағын теңгерімін бақылаңыз: қанша келеді және қанша шын мәнінде өңделеді.

Кіріс пен шығыс ағындарын бір масштабта қараңыз: messages/sec және bytes/sec. Егер кіріс тұрақты түрде шығыстан жоғары болса, жиналу міндетті. Егер кіріс түсіп кетсе, ал backlog өссе, онда мәселе әдетте өңдеуде немесе ack/commit-те.

Backlog (немесе Kafka-дегі consumer lag) өзгеру жылдамдығымен бірге пайдалы. "10 000 хабарлама" өзі көп мән айтпайды. Маңыздысы — саны өсіп жатыр ма және шығынды қалайша азайту жылдамдығы қандай.

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

Kafka-да шекара partitions пен consumer group-қа тиесілі. Бір partition тізбекті оқылады, сондықтан consumer санын арттыру партициялар аз болса немесе кілттер нашар бөлінсе көмектеспейді.

Тез табу үшін тексеріңіз:

• бірдей уақыт аралығында кіріс ағыны vs шығыс ағыны;
• backlog өсу жылдамдығы және ағымдағы жылдамдықпен «нөлге» жету уақыты;
• lag-тың paritions арасында тең емес таралуы (бір «ыстық» партиция бүкіл ағынды бұзуы мүмкін);
• консьюмердің өңдеу уақыты (орташа және p95/p99);
• commit/ack қателері және таймауттардан туындаған қайта жіберулер.

Ресурстарды жалпы түрде қараңыз: CPU, жад, диск және желі. Жиі көрінетін картина: CPU қалыпты, бірақ GC паузалары немесе баяу диск ұзақ тоқтаулар береді. Соның салдарынан консьюмер «енжарланып», ack жібере алмай қалады.

Шек шығыстары күнделікті жүктемеден бөлек

Пиктерді бөлек қараңыз: ай соңында, есеп кезеңдерінде, жаппай жіберілімдер. Мысалы, күндіз жүйе тұрақты, ал 18:00-де кіріс 30 минутқа екі еселеніп, backlog сағаттар бойы өсіп кетеді. Мұндай терезелер үшін бөлек шектер мен «қалпына келтіру уақыты» алерттері пайдалы, әйтпесе сіз шынымен пикте үнсіз қаласыз немесе ай бойы шулы алерттер аласыз.

Шулы емес алерттер: ережелер, шектер және приоритеттер

Жақсы алерт бір сұраққа жауап беруі тиіс: егер ештеңе жасалмаса пайдаланушы үшін не бұзылады. Сондықтан бастау SLO-дан: кешігуді қанша минутқа төзуге болады, хабарламалардың қанша пайызы ретрайға кетсе рұқсат етіледі, және қашан ағын "тоқтады" деп санаймыз.

Көптеген графиктер бар болады, бірақ алерт тәуекелге негізделуі керек, өзгеріске емес. Ең пайдалы сигналдар көбінесе уақыт пен өңделмеген құйрықтар туралы: ең ескі хабарламаның жасы, тұтынушының артта қалуының өсуі, DLQ-ға үдемелі өсу, дубльдер үлесінің көбеюі — егер бұл ақшаға немесе есепке әсер етсе.

Порогтық алерттер жерде айқын шекара болғанда жарайды. Мысалы: "хабарламалар жасы \u003e 5 минут және 10 минут бойы" — критикалық процесс үшін. Тренд алерттері пайдалы, егер ағын жиі өзгеріп тұрса: "lag 20k" емес, "lag 15 минут қатар өсіп, төмендемей жатыр".

Шуды азайту ережелері:

• Қызмет етуді кешіктіру (мысалы, 5–10 минут) — қысқа үзілістерді ұстамай қалу үшін.
• Ағын немесе топик бойынша топтау, әр партиция бойынша емес.
• Дедупликация: бір инцидент — бір хабарлама, әрі қарай тек жаңартулар.
• Бизнес терезелеріне байлану (түнде фондық ағындарға басқа шектер).

Приоритеттерді графиктің әдемілігіне емес, тоқтата тұрудың құнына қарай қойыңыз. Үш деңгей ыңғайлы схема:

• P1: бизнес-сыни ағындар (төлемдер, есеп, қолжетімділік) және DLQ өсуі, ол қалпына келтіруді бөгейді.
• P2: дереу шығынсыз деградация (ретрайлердің өсуі, кешігудің 2–3 есе артуы).
• P3: ерте белгілер (lag өсу тенденциясы, өңдеу уақыттың ұзаруы) — күндік талқылауға.

Сквозной бақылау: тек брокер ішінде емес, барлық қадамдар бойынша корреляция

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

Correlation identifier (correlation_id) — барлық қадаммен өтетін жалпы нөмір. Оны әдетте кіріс сұраудан алады (егер бар болса) немесе бірінші сервис жасайды, кейін хабарлама тақырыпшасында өткізіп, логтарға жазылады. Оны продьюсерде, консьюмерде және DLQ-да сақтау маңызды; әйтпесе тергеу дәл ең ауыр жерінде үзіледі.

Бір форматтағы логтар жақсырақ жұмыс істейді: бірдей өрістер және бірдей атаулар. Содан кейін correlation_id бойынша іздеу оқиғалар тізбегін береді, қарапайым бір-бірімен байланысқан жолдар емес.

Диагностика үшін оқиға мен логтардағы минималды өрістер әдетте:

• correlation_id;
• message_id (хабарламаға бірегей);
• event_type және version;
• produced_at және received_at/processed_at;
• source_system және consumer_service.

Трассировка "сұрау -> оқиға -> өңдеу" жолын байланыстыруы тиіс. Қиын құралдарсыз да бастауға болады: әр қадамда сол correlation_id пен уақыт белгілерін логқа жазу, хабарламада produced_at жіберу ережесін қабылдау жеткілікті.

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

Қадам бойынша: MQ мен Kafka мониторингін іске қосу ақылға сыйатын мерзімде

Күшті мониторинг келісімдерден басталады. Барлық топиктер мен кезектерді бірден бақылауға алу шулы жүйеге әкеледі. Клиентке және процестерге шынымен әсер ететін бірнеше ағынды таңдаңыз және «норманы» SLA сияқты дәл жазып алыңыз.

2–3 апталық жоспар, әдетте жұмыс істейтін

3–5 критикалық ағыннан бастаңыз: мысалы, "тапсырыс жасалды", "жеткізу статусы жаңартылды", "шот шығарылды". Әрқайсысы үшін күтілетін мінез-құлықты белгілеңіз: максималды кешігу, рұқсат етілген ретрайлер, нені қате деп санайтыныңыз, қай жерде асинхрондық рұқсат етіледі.

Одан әрі қарапайым тізбек бойынша жүріңіз:

• Оқиғаларға уақыт белгісін (қашан орын алған) және бір correlation id қосыңыз. Осысыз сквозной бақылау құлазып қалады.
• Брокер мен клиенттердің негізгі метрикаларын жинаңыз: consumer lag, өңдеу жылдамдығы, қателер пайызы, кезек тереңдігі, DLQ көлемі, ретрайлер үлесі.
• Дежурға арналған бір дашборд жасаңыз: 5–8 негізгі график және "проблемалы ағындардың топ-ті" кешігулер мен DLQ бойынша.
• Симптомдарға 5–10 алерт орнатыңыз: кешігудің N минуттан асуы, lag X минут қатар өсуі, DLQ Y минут бойы босемегені, өңдеу қатесі Z%-дан жоғары.
• Оқу инциденттерін өткізіңіз: консьюмерді әдейі баяулату, сыртқы тәуелділікті өшіру, массовый ретрай шақыру. Алерттің түсінікті екенін және дежурный не істеу керек екенін тексеріңіз.

DLQ пен ретрайлер ережелерін бөлек келісіңіз: қанша талпыныс, қандай қателер ретрайланады, қай кезде DLQ-ға кетеді, кім және қалай оны қолмен талдайды, нәтижені қалай тіркейсіз (қайта жіберу, компенсация, "мүмкін емес" деп жою). Бұл бақылауды басқарылатын процессқа айналдырады.

Қайталанатын тұзақтар: метрикалар бар, бірақ бақылау жоқ

Көп жағдайда былай болады: «метрикаларды қостық, бірнеше алерт қойдық», бірақ инциденттер пайдаланушылардан келеді. Себебі қарапайым: метрикалар бар, бірақ "қай жерде баяу" және "не істеу керек" сұрақтарына жауап жоқ.

Типтік қате — орташаға алерт қою. Орташа кешігу әдемі болуы мүмкін, кішкентай бөлік хабарламалардың минуттар бойы ілініп қалғанда. Сондықтан құйрықты (p95, p99) қараңыз және оған алерт қойыңыз.

Екінші тұзақ — consumer lag пен бизнес кешігуін шатастыру. Lag қанша хабарлама өңделмегенін айтады, бірақ клиенттің қанша уақыт күтіп жатқанын айтпайды. Lag аз болуы мүмкін, бірақ хабарлама ұзақ өңдеуде тұруы мүмкін (сыртқы сервис, дерекқор, блокировкалар). Керісінше де болатын жағдай бар: lag үлкен, бірақ пайдаланушылар зардап шекпейді, егер кезек критикалық болмаса.

Тағы үш нәрсе бақылауды үндемей бұзады:

• Шексіз ретрайлер істен шыққанды маскировка қылады: жүйе "жұмыс жасап тұрғандай" көрінеді, бірақ ұзақ уақыттан кейін қалпына келу кезінде лавина шығады.
• DLQ тақырыбы жоқ процессте қоқысқа айналады: апта бойы өседі және жағымсыз уақытта сыр береді.
• Идемпотенттілік болмауы дубльдерді қауіпті етеді: қайта жеткізу ақшаны екі рет ұстап қалуы немесе екі жазба жасауы мүмкін.

Тағы бір жиі қате — барлық кезектерге бірдей шектер қою. Төлемдер үшін 2 минут кешігу — инцидент, ал түнгі анықтама синхронизациясы үшін — қалыпты. Шектер мен приоритеттер критичность пен күтілетін өңдеу уақытқа тәуелді болуы керек.

Релиз алдындағы және инцидент кезінде тез чек-лист

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

Релиз алдында тексеріңіз:

• Әр критикалық ағын бойынша ең ескі хабарламаның жасы (oldest message age) бар ма, тек жалпы backlog емес.
• DLQ-ға қатысты алерттер бапталған ба: көлемнің өсуі және "застой" (DLQ-дегі хабарламалардың жасы өсіп жатыр).
• Дубликат сценарийі тексерілді ме: бірдей оқиға екі рет келгенде жүйе деректі бұзбай ма (идемпотенттік, дедупликация кілттері, уникалды шектеулер).
• Ретрайл саясаты бекітілді ме: қанша талпыныс, қандай паузалар, қай жерде қайта өңдеу аяқталады және қай жерде "тоқтатылады".
• DLQ иесі мен процедурасы анықталған ба: себепті талдау, деректі түзету, ағымға қайтару, есеп беру.

Инцидент кезінде алғашқы қадам — барды бір жерде жинау. Дежурныйға бір дашборд керек: кешігулер (age), backlog, қателер/ретraйлер, DLQ. Бұл бірнеше экран арасында секіргеннен гөрі жылдамырақ.

Инцидент кезінде әрекет тәртібі:

• Хабарламалар жасы мен backlog-ты салыстырыңыз: егер backlog кіші, ал жас үлкен болса, мәселе көбіне партиция кілтінде немесе бір баяу консьюмерде.
• Ретрайлерді тексеріңіз: бірдей қате қайта-қайта айналып жүр ме, сол арқылы лавина қалыптасып жатыр ма.
• DLQ-ны қараңыз: көлем өсіп, жас ұлғайып жатыр ма (демек, өңдеу жүрмей жатыр).
• Дубликаттарды бағалаңыз: қайталанып алыну себебінен ақша/тапсырыстар екі рет тіркелді ме.
• Уақытша шешім мен әрі қарай кім жауапты екенін тіркеңіз: қазір не істеу (тоқтату, шектеу, қолмен өңдеу), кейін қалай түзету.

Практикалық мысал: критикалық процестегі кешігу мен дубльдер

Бір критикалық процесте A жүйесі "заявка расталды" оқиғасын жариялап, B жүйесі клиент картасындағы статусты жаңартты. Бизнес үшін барлығы қарапайым: пайдаланушы батырманы басып, бірнеше секунд ішінде статусын көруі тиіс.

Мәселе анық қатемен емес, «іліну» түрінде шықты: статустар 10–40 минут кешігіп жаңартылып, кейбір клиенттерде статус кері-келіп жүрді. Тикеттерде бұл тұрақсыздық ретінде көрінді, ал брокер «жасыл» еді.

Бірінші көмектескен нәрсе — CPU емес, уақытқа қарау болды. Кезектегі хабарламалардың жасын (message age) және консьюмер lag-ін тексердік: жаңа оқиғалар B жүйесі оны өңдей алатыннан жылдам жиналды. Бір уақытта өңдеу қателері өсті және DLQ тола бастады.

Келесі қадам — жүктеме ме, әлде «нашар деректер» пе екенін ажырату. Жүктеме кезінде lag біркелкі өседі, ал қателер мөлшері тұрақты қалады. Poison message жағдайында көрініс өзгеше: lag секіріп өседі, бірдей типтегі қателер қайталанады, DLQ-ға бірдей себеппен оқиғалар түседі (мысалы, өріс мәнінің күтпеген форматы).

Не істедік:

• Ретрайлерді уақыт пен сан бойынша шектедік, бір хабарламаны сағаттап қайталауды тоқтаттық.
• Уақытша проблемалы оқиға түрін бөлек ағынға оқшауладық, қалғандарын бөгемеу үшін.
• DLQ-ны сараптадық: негізгі себебін анықтап, деректерді түзету және қайта өңдеу жоспарын дайындадық.
• B жағында идемпотенттікті қосып, қайталанбаған кілт енгіздік, қайта жеткізу статусты екі рет өзгертпесін үшін.

Бұрынғы жағдай қайталанбауы үшін екі ереже бекіттік: "хабарлама жасы \u003e X минут" бойынша алертті қателер санынан жоғары приоритетпен қою және нақты себеп бойынша DLQ-ға өсуді бақылау. Сонымен қатар оқиға схемасын жаңарттық: міндетті өрістерді айқындадық және version қосып, тұтынушы өзгерістерге дұрыс жауап берсін.

Келесі қадамдар: процесті бекіту және инфрақұрылымды дайындау

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

Процесс иелерімен SLO-ларды келістіріңіз: кешігу қанша минутқа рұқсат етіледі, қанша хабарламаны жоғалтуға болады (әдетте 0), қалпына келтіру қаншалықты жылдам болуы тиіс. Бұл шектер мен приоритеттерге мән береді.

Содан кейін метрикаларды деңгейлерге бөліңіз. Қолданба деңгейінде пайдаланушы көретін фактілер маңызды: оқиға жасау мен өңдеу арасы, ретрайлер үлесі, дубльдер саны, DLQ-ға кеткен хабарламалардың пайызы. Брокер деңгейінде — тасымалдаудың денсаулығы: лаг, тұтыну жылдамдығы, продьюсер/консьюмер қателері, диск толымдылығы, партиция мен репликация күйі.

Практикалық 2–4 апталық жоспар:

• Критикалық ағындардың тізімін жасап, иелерін анықтаңыз.
• Қолданбаға 3–5, брокерге 3–5 міндетті метриканы бекітіңіз.
• Жүктеме тесті және бір оқу инцидентін өткізіңіз (мысалы, консьюмерді 10 минутқа тоқтату) және алерттер түсінікті жауап беретінін тексеріңіз.
• Runbook жазыңыз: кім жауап береді, алғашқы не тексеріледі, DLQ қайда, қауіпсіз қайта өңдеу қалай жасалады.

Инфрақұрылымды алдын ала дайындау жақсы: брокерлерге сенімді серверлер, резервтеу, ретеншнге диск болжамы, метрикалар мен логтарды бөлек сақтау, қатынастар мен аудит. Ұйымдар үшін жеткізілім мен қолдау ашық болуы маңызды.

Егер кластерді жаңарту немесе кеңейту жоспары болса, GSE.kz (gse.kz) серверлер таңдау, жеткізу және жүйелік интеграция бойынша көмектесе алады, сондай-ақ 24/7 қолдауды ұсынады, сонда кезектер мен мониторинг алдын ала болжанатын болады.