Zabbix жазылымсыз мониторинг: шаблондар, триггерлер, карталар

«Тірі/өлген» мониторингпен не дұрыс емес

«Пинг бар» дегені тек бір нәрсені көрсетеді: құрылғы желіге жауап береді. Бірақ сервис өзі қолжетімсіз болуы мүмкін. Веб-портал қосылмайды, қосымшада қате, дерекқор ілініп қалған, диск толған, сертификат мерзімі өткен, хабар алмасу кезегі тоқтап қалды — ал қолданушылар әлі де «жұмыс істемейді» деп жазады.

Мұндай мониторинг қауіпті — ол тыныштандырады. Дежурствода тыныштық, жасыл статустар, ал бизнес уақыт пен ақша жоғалтады. Тіпті нашаррақ — хабарламалар тек толық құлаған кезде келеді. Сол кезде команда проблеманы кеш біледі: тоқтап қалу басталған, мерзімдер бұзылған, клиенттер шағымданады.

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

Жақсы тексеру әрдайым қолданушы әрекетіне байланады. Егер сайт ашылады, бірақ авторизация өтпесе — бұл бизнес үшін инцидент. Егер бэкап тоқтаған болса, бұл қазір авария болмауы мүмкін, бірақ ертең үлкен тәуекел бар.

Мониторинг бизнес сұрақтарын жауып беруі керек:

• Негізгі қолданушы сценарийі жұмыс істей ме (кіру, іздеу, төлем, жазылу)?
• Цепочка қай жерде үзіліп кетті (DNS, желі, ДҚ, қосымша, сыртқы провайдер)?
• Қанша уақытқа дейін ақау пайда болмайды (диск бос орны, қателер өсуі, жүктеме)?
• Қай сервис тәуекелде және инциденттің приоритеті қандай?
• Бірінші минутта кім жауап беруі керек және не тексеру керек?

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

Қайдан бастау: сервистер, тәуелділіктер және критичность

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

Инвентаризацияны ұйымдық құрылым бойынша емес, қолданушы сценарийлері бойынша жасаңыз. Көбінесе процесс иесімен және ИТ-пен 30–60 минут әңгіме жеткілікті: адам күнде қандай 3–5 әрекет жасауы керек, қай уақытта бұл маңызды, не «ақаулық» саналады ("баяу", "қате", "деректер жаңаланбады"), айналып өту жолы бар ма және қанша уақытқа шыдайды, «бұл инцидент пе» деп кім шешеді, ал кім «біраз күте тұрыңдар» дейді.

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

Жоғарыдан төменге тізбек сызу ыңғайлы: сервис -> қосымша -> ДҚ -> ОС/сервер -> желі/электрқоректене беру, плюс сыртқы нүктелер (SMS-шлюз, мемлекеттік қызметтер, төлем провайдері). Кейіннен бұл карталар мен бизнес-сервистерге айналады.

Содан кейін бизнес үшін «ауыратын» шекті анықтаңыз. «CPU 90%» емес, қолданушы байқайтын нәрсе: жауап уақыты, қателер үлесі, сәтсіз транзакциялар саны, кезектің артта қалуы, пакеттік шығын. Мысалы: «егер жүйеге кіру 8 секундтан ұзаққа созылып, 5 минут қатарынан сақталса — операторлық смена бұзыла бастайды».

Соңында критичность туралы келісіңіз. P1–P3 сияқты қарапайым шкала және эскалация ережесі әдетте жеткілікті: P1 — ақша/қауіпсіздік/процесс тоқтауы, P2 — тоқтаусыз деградация, P3 — қолайсыздық. Бұл келісімдер приоритеттер мен оповещениелер маршрутизациясының негізін құрайды.

Zabbix шаблондары қалай құрылады және оларды қалай жоспарлау керек

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

Жақсы шаблонның құрамдастары

Әдетте шаблон бірнеше элементтен тұрады:

• Items — мәндерді жинайды (CPU жүктемесі, API жауап уақыты, диск бос орны).
• Triggers — сандарды күйге аударады (қалып, ескерту, мәселе).
• Graphs — динамиканы көрсетеді.
• Discovery (LLD) — файлдық жүйелер, интерфейстер, базалар, сервистер сияқты қайталанатын объектілерді автоматты түрде табады.

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

Макростар, орталар және атаулар тәртібі

Бірдей логика өндірісте, тестте және филиалдарда әртүрлі порогтармен жұмыс істеуі керек. Бұл үшін макростарды қолданыңыз. Мысалы, "диск бос емес" бір триггер {$DISK.MIN.FREE} макросынан мән алып, prod пен test үшін әртүрлі сандар алады.

Инциденттерді тез талдау үшін қарапайым ережелерге келіңіз: метрикалардың біркелкі атауы (не өлшенеді, қай жерде, қандай бірліктерде), триггер тэгтері (service=payments, layer=db, env=prod), оқиғалардың түсінікті аттары ("5xx қателер өсуі — сайттың қолжетімсіздігі қаупі"), және маңыздылық бойынша бөліну (барлық ескертулер түнде оятпайды).

Көп типтік алаңдары бар компанияларда (офистер, ауруханалар, мектептер, ЦОД) осы стандарттар әсіресе пайдалы: мониторинг моделі бір, ал айырмашылықтар макростар мен тэгтер арқылы анықталады, қолмен түзетулер арқылы емес.

Қызмет сапасын көру үшін қандай метрикалар жинау керек

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

ОС бойынша базалық жиынтықтан бастаңыз. Бұл графиктер үшін емес, «серверге ме әлде қосымшаға ма» дегенді тез ажырату үшін қажет: CPU (iowait қоса), RAM (swap өсімін қоса), диск (бос орын және I/O кешігулері/кезектері), желі (пакет шығындары, интерфейс қателері, канал утилизациясы), уақыт синхрондауы (сағат дрейфы аутентификация мен логтарды бұзады).

Сосын сервер рөліне қарай метрикалар қосыңыз. Гипервизор үшін «шулы» VM-дер мен торап ресурстарының жетіспеуі маңызды. Файл сервері үшін — диск кешігулері мен SMB/NFS қателері. Терминалдық серверлер үшін — белсенді сессиялар саны мен логин уақыты. AD үшін — репликация, кезектер және LDAP/Kerberos жауап уақыты.

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

Қайталап қалудың алдын алу үшін LLD пайдаланыңыз: диск, интерфейс, файлдық жүйе және сервистерді автотану. Шаблон жаңа диск немесе интерфейс тапса, бақылауды өзі қосады.

Және 1–2 «қолмен көретін» тексеруді ұстаңыз: логин парағын ашу, қарапайым сұрау орындау, API-ден сәтті жауап алу — бұл нақты сапаның ең жақсы индикаторларының бірі.

Қадам бойынша: Zabbix-та алғашқы «дұрыс» мониторингті жинау

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

Қолыңыздағы адамдар үшін маңызды сервисті таңдаңыз: «корпоративті пошта», «өтініш порталы», «электронды тіркеу». Тәуелділік тізбегін салыңыз: DNS -> балансировщик -> веб/қосымша -> дерекқор -> сақтау -> желі. Шынайы жағдайда кейбір буындар физикалық серверде, кейбірі виртуализацияда болады және осы байланыстар не инцидент саналады соны анықтайды.

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

Жұмыс тәртібі әдетте мынадай:

• Сервис пен оның тәуелділіктерін сипаттау, не маңызды, не деградация көтеруді қажет ететіні анықтау.
• Базалық шаблон жасау: қолжетімділік, кешігулер, негізгі ресурс пен қосымша метрикалары, талдау үшін тэгтер.
• Объектілер көп жерде LLD қосу (дисктер, интерфейстер, файл жүйелері), порогтарды макростарға шығару.
• Деректер "тазалығын" тексеру: бірліктер (ms, %, B/s), бірдей интервалар, түсінікті атаулар.
• Шағын дашборд жинап, тек іс-қимылды талап ететін оповещениелерді қосу.

Барлық командаға хабарландыруларды қосардан бұрын хабарламалар сапарын тексеріңіз. Нағыз проблема кезінде хабарлама үш сұраққа жауап беруі тиіс: не сынған, бұл сервиске қалай әсер етеді, алғаш рет не тексеру керек. Мысалы, бір интерфейстің құлауы әрдайым инцидент емес, ал жүктеме сағаттарында ДҚ кешігулерінің өсуі — сервиске тәуекел, тіпті хост "тірі" болғанда да.

Триггерлер: метрикаларды анық түсінікті тәуекелдерге қалай аудару

Метрикалар өздігінен инцидент сәтінде сирек көмектеседі. «CPU 92%» немесе «ping өсті» сервиске тәуекел бар ма және қазір не істеу керек екенін айтпайды. Zabbix триггерлері сандарды оқиғаларға аударады, сондықтан олар басқарылатын тәуекелдерге айналады.

Ең басты мәселе — шу. Егер 5 минут сайын алерт келіп және жиі "өзінен өтеді" болса, команда жауап беруді тоқтатады.

Флаппинг болмас үшін порогтарды белгілі бір қорғанышпен қойып, гистерезис қолданыңыз: «диск 90%-дан жоғары 10 минут бойы» және «қалпына келу 85%-тан төмен» сияқты. Солай тенденцияны ұстап, бірреттік шыңдарды емес ұстайсыз.

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

Әдетте жұмыс істейтін бірнеше ереже:

• Триггер тек іс-қиметке бағытталсын (оған сене отырып не істейсіз).
• «Жай қозғалмалы» метрикалар үшін уақытша растау (5–15 минут) қосыңыз.
• «Деградация» мен «құлау» (баяу vs қолжетімсіз) арасында бөлу жасаңыз.
• Бір мәселе үшін бір негізгі алерт қалдырыңыз, қалғандарын диагностикалық ретінде көрсетіңіз.
• Оқиға атауы сервиске тәуекелді түсіндіруі керек, тек метрика мәнін емес.

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

Серьезность пен тэгтер маршрутизацияны анықтайды: критикалық оқиғалар дежурлыға, деградациялар талдау кезегіне, ескертулер жоспарлы жұмыстарға жіберіледі.

Карталар, сервистер және дашбордтар: бизнес-картинаны көру үшін

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

Карталар: байланыстар және тар жерлер

Инфрақұрылым картасы әдемілік үшін емес. Ол цепочка қай жерде үзіліп жатқанын тез көруге көмектеседі: коммутатор, канал, кластер, нақты стойка немесе сервис контур.

Жақсы карта тұтынушыдан бастап ағыс бойынша байланыстарды көрсетеді: қолданушы -> балансировщик -> веб -> ДҚ -> сақтау. Қойылатын ортақ сәтсіздік нүктелерін бөлек белгілеу пайдалы (мысалы, бірнеше сегмент үшін бір коммутатор). Инцидент кезінде «неге бәрі бірден құлады» дегенді карта арқылы түсінуге болады.

Бизнес-сервис: компоненттардың статустары негізінде сервис мәртебесі

Zabbix-та бизнес-сервис ағаш ретінде жиналады: жоғарғы деңгейде сервис (мысалы, «Электронды қабылдау»), одан төмен компоненттер (DNS, канал, веб, ДҚ, кезек, сертификаттар). Маңыздысы — тек down емес, деградацияны да орнату: сервис қолжетімді болуы мүмкін, бірақ баяу немесе ішінара сынған болуы да мүмкін.

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

Дашбордтарды рөл бойынша жасаңыз, әйтпесе оларды қарауды тоқтатады:

• Дежурлыға — ең проблемалы сервистер, ағымдағы алерттер, "қазір не істеу керек".
• Адмінге — утилизация, кезектер, кешігулер, сыйымдық, трендтер.
• Басшыға — негізгі сервистердің мәртебесі және қалпына келтіру уақыты техникалық мәліметтерсіз.
• Сервис-менеджерге — сервистер бойынша қолжетімділік және тоқтап қалу себептері.

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

Zabbix баптауындағы жиі қателіктер

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

Шу сигналдың орнына

Бір шеткерілік — тым көп тексеріс қосып, опрос жиілігін 10–30 секундқа қою. Бұл агентті, желіні және Zabbix-ты жүктейді, бірақ егер метрика шешімдерге әсер етпесе пайда әкелмейді.

Тағы бір шеткерілік — тым сирек опрос. Егер веб-сервис 10 минут сайын тексерілсе, қолданушылар сізден бұрын мәселені байқайды.

Шу көзі тағы — әртүрлі шарттар үшін бірдей порогтар. Бірдей CPU, диск немесе желі кешігулері ДҚ үшін қалыпты, ал офис файл сервері үшін алаңдатарлық болуы мүмкін. Филиалдарда да: қашықтағы нүкте үшін 50 мс пинг қалыпты, ал дата-орталықта бұл деградация белгісі болуы мүмкін.

Алерт бар, әрекет жоқ

Контексті жоқ триггер "Disk space low" сияқты көрінеді және осы жерде бәрі аяқталады. Дежурлы қай бөлім, қандай бөлім және не істеу керектігін іздеуге уақыт жұмсайды.

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

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

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

Тез чеклист: мониторинг шынайы инциденттерге дайын ба

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

Ең алдымен бизнес-картинаның бар екеніне көз жеткізіңіз, тас-кеңістігіндегі бөлшектелген хосттар жиынтығы емес. Бір сервер құлса, бірақ сервис резерв арқылы жұмысын жалғастыра берсе, дежурлыға "өрт" қажет емес.

Қайталанатын инциденттер болмас үшін минимум

• Сервиске тәуелділік схемасы және иесі бар (техлид, админ, мердігер). Иесі жоқ алерт «ешкімнің емес» болып қалады.
• Триггерлер мәні бойынша бөлінген: себептер (диск толды, кезек өсті, I/O тоқтады) және симптомдар (сайт қолжетімсіз, таймауттар).
• Деградация порогтары алдын ала қойылған: не «құлатты», не «нашарлады» (қателер, кешігулер, кезектер, диск бос орны, жауап уақыты). Екі деңгей — ескерту мен критикалы — жақсы.
• Оповещениелер тэгтер бойынша бағытталады: сервис, орта (prod/test), критичность, тип (security, storage, network).
• Екі түр дашборд бар: дежурлыға — «қазір не істеу», және басшыға — «қауіпте тұрған сервистер және себептері».

Жанды тексерулер

Шынайы апатқа дейін қысқа тест жасаңыз:

• Техжұмыс жоспарлап, алерттердің басылып жатқанын және терезе соңында қайта іске қосылатынын тексеріңіз.
• Флаппингтен қорғаныс жұмыс істейтінін тексеріңіз: қысқа секірулер түнде оятпауы керек.
• Деградацияны имитациялаңыз (мысалы, тест дискіні толтыру немесе latency-ны арттыру) және көріңіз: "сервис тәуекелі" көтеріледі ме, әлде тек хост қызара ма.

Мысал: Zabbix сервис үшін тәуекелді қалай көрсетеді, хост үшін емес

Мысалы мемлекеттік орган немесе банк: азаматтар үшін өтініш қабылдау сервисі және қызметкер кабинеті бар. Екі сервис бір инфрақұрылымда болуы мүмкін, бірақ бизнес үшін олар әртүрлі. "Барлық хосттар пингу болады" дегені азамат өтініш бере алады дегенді білдірмейді.

Деградация әдетте тыныш басталады. Сайт ашылады, бірақ формалар бұрынғыша тез жіберілмейді. Кейінірек кей сұраулар HTTP 500 қайтарады. Дерекқорда кезек өседі, қолданушылар қолдауына хабарласады. Мұнда мониторинг тәуекелді басқару құралы ретінде пайдалы, лампочканың орнына.

Падуға дейін тәуекелді ертерек көрсету үшін әдетте метрикалар мен триггерлердің жұбы жеткілікті: API жауап уақытының (мысалы, p95) 5–10 минут қатарынан өсуі, кейін 5xx шегі бұзылуы, параллельді ДҚ кезегінің өсуі немесе репликация кешігуі, ал төменгі деңгейде техникалық себеп (I/O wait, CPU steal, диск толуы) көрінеді.

Көрсету маңызды: картада сіз "сервер 1 қызыл" емес, "Өтініш қабылдау: жоғары тәуекел" көресіз және оның төмендегі тәуелді узелдері: API, ДҚ, кезек, балансировщик. Оқиғаларға еніп, қайсысы бірінші, қайсысы екінші екенін және ықтимал себебін көресіз. Бұл уақыт үнемдейді: қай хост «күнәлі» екенін болжаудың қажеті жоқ.

Бизнеске қарапайым тілде айтыңыз: қай функция қолжетімсіз (мысалы, өтініш жіберу), қанша қолданушы зардап шегіп жатыр, не болады әрі қарай (кезектің өсуі мен қайталанатын қателер), қалпына келтірудің болжамды уақыты — тіпті кезек пен өңдеу жылдамдығы бойынша жуық болжау техникалық «біз қарастырып жатырмыз» дегеннен пайдалы.

Келесі қадамдар: мониторингті қалай масштабтап және қолдау керек

Негізгі схема сервистер бойынша тәуекелдерді көрсеткеннен кейін келесі қарапайым сұрақ: ал жарты жылдан кейін бәрі солай анық жұмыс істеуді қалай сақтаймыз, мониторинг жеке тексерістер жиынтығына айналмасын?

Пилотты бір сервиске бастаңыз, иесі бар және тоқтауының бағасы анық: клиникадағы электронды тіркеу немесе банктағы төлем шлюзі. Ол жерде шаблондар, триггерлер, тәуелділіктер мен карта дежурлы үшін 30 секунд ішінде: не сынған, кімге әсер еткен және алғашқы не істеу керектігін түсіндіретін деңгейге жетсін.

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

Масштаб туралы бөлек ойланыңыз. Бірнеше филиал, көп желі жабдығы, әртүрлі ОС паркі және 24/7 әрекет қажет болса, интеграторды қосу ақылға сыяды.

Мониторингті сыйымдылық жоспарлаумен байланыстырыңыз. Тек "диск таусылып жатыр" алертін күтіп қалмаңыз. CPU, жады, IOPS, кезектер мен дерекқорлардың өсуін, пик сағаттарды қарап отырыңыз. Сол кезде "ресурстарды қосу" шешімі алдын ала қабылданады, түнгі инцидент кезінде емес.

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