Zabbix, Prometheus және Loki үшін сервер талаптары: есептеу

Неліктен мониторинг пен логтар бірнеше аптадан кейін баяулай бастайды

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

Негізгі себеп — деректер өсімі сызықты емес. Алдымен негізгі хосттар мен бірнеше дашборд қосылады. Кейін сервистер қосылады, командалар қосымша экспортерлер қояды, жаңа меткалар (labels) пайда болады. Әр «шағын» қадам сақтау көлемін және оқу/жазу операциялары санын көбейтеді.

Ең жылдам өсетіндер:

• Логтар. Бір күн debug қосуды ұмыттық па — тәуліктік көлем оңай екі есеге артады.
• Метрикалардың кардиналдылығы. Бір нашар таңдалған label (user_id, request_id, толық URL) бір метриканы мыңдаған немесе миллиондаған серияларға бөлетін жағдай тудырады.
• Алерттер. Дедупликация немесе уақытша приглушение жоқ көп ережелер жүйені жиі қайта есептеуге мәжбүр етеді.

Симптомдар әдетте тез көрінеді, егер қайда қарау керектігін білсеңіз. Графиктер мен іздеу сұраулары ұзарады, әсіресе «апта» немесе «ай» интервалы үшін. Алерттер кешігеді немесе топ-топ болып келеді. Prometheus-та графиктерде «жолдар» пайда болуы мүмкін, Loki-да логтарда үзілімдер, Zabbix-та кезектердің өсуі және жаңа мәндердің кешігуі байқалады.

Жеке жиі кездесетін себеп — диск. Деректер аз болғанда баяу диск те «қабылдайды». Дегенмен метрикалар мен логтар ұлғайған сайын жүктеме кішігірім тұрақты жазулар мен оқуларға айналып, бәрі IOPS-та тұрып қалады. CPU мен RAM әлі «жасыл аймақта» болуы мүмкін, бірақ жүйе баяу сезіледі.

Сондықтан Zabbix, Prometheus және Loki үшін сервер талаптарын бірінші аптаның сезіміне сүйеніп бағалауға болмайды. Керек кіріс деректері мен запаспен есептеу қажет, әйтпесе бір айдан кейін сіз инфрақұрылымды емес, мониторингті мониторинг жасайтын боласыз.

Zabbix, Prometheus және Loki-де не жүктейді

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

Zabbix. Негізгі жүктеме жинау және өңдеуде туындайды. Әр агент, SNMP немесе скрипт опросы: мән алу — тарихқа жазу — триггерлерді қайта есептеу — кейде трендтерді жасау. Интервал қысқараған сайын және элементтер көп болған сайын CPU мен диск жүктемесі өседі. Көп жағдайда база (SQL) белсенді жазады, сондықтан диск кешігулері жылдам кезектерге әкеледі.

Prometheus. Ол метрикаларды тұрақты скрейп жасайды және оларды уақытша қатарлар ретінде сақтайды. Негізгі жау — меткалар мен кардиналдылық: метрикалар аз болып көрінуі мүмкін, бірақ label комбинациялары мыңдаған немесе миллиондаған болады. Бұл RAM-ға (индекстер мен белсенді сериялар), CPU-ға (сығымдау, блоктарға жазу, ережелерді есептеу) және дискке (TSDB-нің тұрақты кішкентай жазбалары) әсер етеді.

Loki. Көбінесе лог көлемі мен сұраулар сипатына тұрып қалады. Логтарды қабылдау дискке тұрақты жазу береді, ал «апта бойынша барлық сервис» сияқты сұраулар уақытша чанктерді көп оқуға мәжбүрлейді. Жады индекстер мен буферлерге керек, бірақ тар орын әдетте дискілік подсистема мен IOPS болады.

Практикалық кеңес: егер 200 серверіңіз бар және қосымша debug қосып қойсаңыз, Loki дискіге басып тастауы мүмкін, ал Prometheus-қа request_id тәрізді label қоссаңыз, RAM бірінші таусылады, тіпті трафик аз болса да.

Егер ресурстар бойынша бөлсек:

• CPU: триггерлер мен ережелер (Zabbix), серийларды өңдеу мен сұраулар (Prometheus), ауыр лог іздеулер (Loki)
• RAM: кардиналдылық пен кэштер (Prometheus), дерекқор кэштері мен кезектер (Zabbix), индекстер мен буферлер (Loki)
• Дискілер: тарих және индекстер (Zabbix), TSDB жазбалары (Prometheus), лог ағыны мен чанктерді оқу (Loki)

Егер стек бір серверде тұрса, жиі жылдам SSD және жеткілікті RAM жеңіске жетеді. Мұндай жағдайда GSE S200 сияқты стоечный сервер сыныптары артықшылық береді: диск пен жад жетпей қалмауы ықтимал.

Есептеу алдында жинау керек деректер

Есептеу болжам емес, нақты фактілерге негізделуі тиіс. Алдымен жүйеге не түсетінін және қалай пайдаланылатынын анықтаңыз.

1. Инвентаризация. Тек серверлер саны емес, әрбір жеке мақсат: ВМ, контейнер түйіндері, желі құрылғылары, СХД, ДБ, балансировщиктар. «Шулы» обьектілерді бөлек белгілеп қойыңыз: ДБ, жоғары жүктеме сервистері, көп интерфейсі бар құрылғылар.

2. Метрикалар ағыны. Әр типтегі хост үшін қанша метрика жинайтыныңызды және қандай интервалда болатынын жазыңыз. 15 секунд пен 60 секунд арасындағы айырмашылық шамамен 4x болады — бұл бірден жазба көлемін, компакцияларды және сұраулар жүктемесін көбейтеді.

3. Логтар ағыны. Нақты цифрлар: қанша көз (қосымша, nginx, AD, firewall, endpoints), орташа оқиға өлшемі және пиктегі жылдамдық (оқиғалар/сек). Мәлімет болмаса, бірнеше типтік лог файлды бір күнге алып, көлемін және минутына жол санын пик уақыттағы өлшеп есептеңіз.

4. Сақтау мерзімі (retention). Метрикалар мен логтар үшін бөлек қойыңыз. Жиі практика: трендтер үшін метрикалар ұзақ сақталады (6–12 ай), логтар қысқа (7–30 күн), себебі логтар дискті тез жейді және іздеу кезінде көп IOPS талап етеді.

5. Пайдаланушы белсенділігі. Егер 1–2 инженер бірнеше дашбордқа қараса, талаптар жеңіл. Егер күнделікті көп зерттеулер, лог іздеулер және графиктерді салыстыру болса, CPU мен RAM жүктемесі айтарлықтай жоғары болады.

Қысқа чек ретінде осы бес пункт жеткілікті: мониторинг мақсаттары, метрикалар мен интервалдар, лог көздері мен пиктер, retention (бөлек), пайдаланушылар белсенділігі.

Интервалы, көлемдер және retention: қай жерде жиі қателеседі

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

Сирек опрос ресурстарды үнемдейді, бірақ диагностиканы жоғалтуы мүмкін. Мысалы, метрика 5 минут сайын алынса, ал инцидент 40 секундта өтсе, сіз оны байқамауыңыз мүмкін. Ал «барлығы 15 секунд» режимінде жүздеген хостта шум пайда болып, деректер көмектеспейді.

Жақсы ереже: қысқа интервалды тек динамика маңызды жерлерге қалдырыңыз. Көбіне 15–30 секунд байланыс арналарына, негізгі түйіндердің жүктемесіне, кезектерге, критикалық API мен ДБ-ға жарайды. Қызмет күйі (up/down), температура, диск толуы сияқты өлшемдер үшін 1–5 минут жеткілікті.

Қысқа интервал қоюдан бұрын өзіңізге төрт сұрақ қойыңыз:

• Егер мәселені 30 секундта емес, 3 минутта көрсем, не бұзылады?
• Алерт болады ма және оны кім өңдейді?
• Нақты қанша объектіге мұндай дәлдік қажет?
• Дәлдікті азайтып, сақтау мерзімін ұлғайту мағыналы ма?

Логтарда қателік қарапайым: бәрін «солай» жібереді, фильтрациясыз және лимиттерсіз. Нәтижесінде Loki-да debug, healthcheck, пайдалы емес access жазбалары көп жиналып, іздеу баяулайды. Көбінесе шумды алдын ала кесіп тастау (prod-та debug өшіру, жиі 200 OK-тарды алып тастау), жеке деректерді жою және өрістерді нормалдау лог көлемін бірнеше есе кемітеді.

Retention дискіге CPU-дан көбірек әсер етеді. «Тағы 30 күн» сақтау айтарлықтай көлемнің өсуін білдіреді. Мысал: қызмет 200 ГБ/тәулік лог жасаса, 7 күн — ~1.4 ТБ, 30 күн — ~6 ТБ, және бұл индекстер мен репликацияны қоспағанда.

CPU, RAM және диск нақты жүктемемен қалай байланысты

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

CPU — деректерді қабылдау (ingest), өңдеу және агрегациялар, сығымдау (логтарда айтарлықтай), сұрауларды орындау үшін кетеді. Жүктеме тұрақты емес: күндіз сұраныс көп, түнде фондық жұмыстар (переиндексация, компакция) болуы мүмкін. CPU көбіне 70–80% деңгейінде ұзақ тұрса, кез келген шарықтау кезекті тудырады.

RAM — кэштер мен жұмыс жиынтығына керек: белсенді сериялар, жазба кезектері, уақытша буферлер, сұраныс жарылыстары. Жад жетпесе, жүйе дискіге жиі жүгінеді, тіпті жылдам SSD де ауыр сұрауларды құтқармайды. SWAP белсенділігі — жад тапшылығының айқын белгісі (оны болдырмау керек).

Дискілер — жазу мен оқуды қаншалықты жылдам істей алатынын шешеді. Метрикалар үшін тұрақты жазба маңызды; логтар үшін жазу мен оқу екеуі де маңызды. Мұнда тек ГБ емес, IOPS ролі үлкен: көп кішкентай операциялар HDD-ты тез «өлтіреді».

Мониторинг және лог стекі үшін қадамдап есептеу

Төмендегі тәртіп сатып алу алдында жұмыс істейтін бағалау береді және өсу кезінде тез қайта есептеуге көмектеседі.

1. Метрикаларды секундтағы нүктелер (MPS) және пиктерді есептеңіз. Prometheus үшін: targets x метрикалар/target x (1 / scrape interval). Содан кейін автоскейл, түнгі джобтар, жаппай рестарттар үшін 1.5–3 коэффициентпен көбейтіңіз.

2. Сұраулар мен дашбордтар көлемін бағалаңыз. CPU жиі жинау емес, графиктер мен алерттер жейді: көп range-сұраулар, үлкен терезелер (7–30 күн), көп пайдаланушылар. Егер NOC-экрандар жоспарланса, CPU-ға қосымша запас қойыңыз.

3. Белсенді деректер мен кэштер үшін RAM-ды бағалаңыз. Жад «тар» болса, дискке ұмтылу болады. Prometheus пен Loki үшін индекстер, кэштер және ыстық чанктер үшін RAM маңызды. Zabbix үшін DB және сервер кэштері (history, trend, value cache) үшін жад қосыңыз.

4. Сақтауды тәуліктік көлемге келтіріңіз. Метрикалар: бір нүктенің орташа өлшемін MPS пен бір күндегі секундтарға көбейтіңіз. Логтар: тәуліктік ГБ көлемі плюс индекс. Содан кейін retention-ға көбейтіп, компакциялар мен уақытша файлдар үшін орын қосыңыз.

5. Өсу мен күтпеген көздерді есепке алыңыз. CPU/RAM және диск үшін кемінде +30–50% запас қойыңыз. Жаңа сервистер, қосымша label-дар және инцидент кезіндегі лог жарылыстары әрқашан пайда болады.

Егер есептеу дискілік жүктемеге және белсенді деректерге тәуелді екенін көрсетсе, бастапқыда жылдам SSD және жеткілікті RAM бар серверді қарау ақылға near. S200 Series (GSE S200) сияқты сервер сыныптары практикалық таңдау болады.

Дискілерді есептеу: сыйымдылық, IOPS және SSD/HDD таңдау

Дискілер — мониторинг жиі «өлетін» бөлік. Zabbix/Prometheus/Loki стек үшін тек ГБ емес, пиковые жазу мен оқу кезіндегі қаншалықты жылдам жазып/оқи алатыны маңызды.

Сыйымдылық: тәуліктік көлем және retention

Бастапқы есеп: оқиғалар/сек x орташа өлшем x 86400. Мысалы, 500 жол/сек, әр жол 300 байт болса — тәулігіне ~13 ГБ (сығылмаған және индекстерсіз). Содан кейін retention-ға және 30–50% запасқа көбейтіңіз.

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

IOPS: неге оқу кейде жазудан маңызды

Жазба үнемі жүрсе де, кешігулерді көбіне іздеулер кезінде байқайды: күндік таңдау, апта бойынша панельдер, уақыт пен өрістер бойынша фильтрлер. Осы кезде диск көп кішкентай блоктарды оқып беруі тиіс, сондықтан кездейсоқ оқу маңызды болады.

Егер логтарды жиі іздесеңіз және дашбордтар жиі жасалса — приоритет SSD және жеткілікті IOPS. Егер логтар көбіне жазылып, сирек оқылатын болса, арзанырақ сақтау таңдауына баруға болады, бірақ retention шектеулерін ескеріңіз.

RAID жылдамдық пен сенімділікке әсер етеді. Айна жасау (mirroring) оқу жылдамдығын арттырады және диск істен шыққанда қорғайды, ал кейбір RAID түрлері кішкентай жазбаларды баяулатуы мүмкін.

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

Архитектура: бір сервер немесе рольдерге бөлу

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

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

Екі түйінге бөлу орташа масштабта үлкен жеңілдік береді. Практикалық бөліну — метрикалар/Zabbix бір жерде, логтар (Loki) бөлек. Метрикалар мен Zabbix көбіне CPU мен RAM-ға тәуелді, ал Loki көбіне дискке тәуелді.

Горизонталды масштабтау — бір серверге қосымша ресурс қосу қымбат немесе ыңғайсыз болған кезде жоспарланады. Белгілер: диск үнемі бос емес, қызмет көрсету терезесін табу қиын, өсім ай сайын байқалады. Онда ролдер бойынша жаңа түйіндер қосқан жеңілірек.

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

Әдеттегі қателер, нәтижесінде бәрі баяулайды

Көп жағдайда жүктеме алдын ала есептелмегенде проблема басталады. «Көзге қарап» sizing жасағанда 3–6 аптадан кейін сұраныстар ұзарады, алерттер кешігеді, дискілер кенет бітеді.

Ең жиі қателер:

• Retention-ды үлкен қойып, индекс пен өсімді есептемейді.
• Кардиналдылықты динамикалық меткалармен ұлғайтады (user_id, request_id, толық URL).
• Логтарды фильтрацияламай және лимитсіз жинайды: prod-та debug, бірнеше агенттен қайталанатын жазбалар, шексіз жол ұзындығы.
• Өндіріс пен тест ортасын бір жерде сақтайды, квота мен ережелер жоқ.
• Мониторингтің өзіне бақылау орнатпайды: диск толуы, кардиналдылық өсуі, скрейп кешігулері, кезектер, сұрау уақыты бойынша алерттер жоқ.

Практикалық мысал: команда path меткасын толық URL-пен қосты. Бірінші күні бәрі қалыпты көрінді, ал апта ішінде уникалды қатарлар саны өсті, Prometheus компакциялары жиі болды, ал «7 күндік» сұраулар ілесіп жете алмай қалды.

Тиімді тәсіл — алдымен көздер мен ережелерді шектеу (retention, фильтрлер, квоталар), содан кейін ресурс қосу.

Іске қосқаннан кейін жылдам тексеру: 15 минуттық чеклист

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

Таңдаулы бір жұмыс сағатын және бір пик сағатты (мысалы, дүйсенбі таңертең) алып тексеріңіз:

• CPU: тәуліктік орташа және пиктер. Егер пиктерде 80–90% байқалса, сұраныстар кешігуі мүмкін.
• RAM және swap. Қалдығы болуы керек. Swap белсенділігі көбіне жад жетімсіздігінен.
• Диск: жазу/оқу кешігуі мен жылдамдығын қараңыз. Жазба кешігулерінің өсуі Loki мен мониторинг дерекқорын бұзады.
• Деректер өсімі және болжам. Тәуліктік қосылған ГБ-ты тіркеп, оны 90 және 180 күнге көбейтіңіз.
• Алерттер мен деректер үзілістері. Оқиға мен хабарлама арасындағы кешігу және графиктердегі «жолдардың» болуы.

Жылдам цифр жинау үшін келесі командалар жарайды:

uptime
free -h
vmstat 1 5
iostat -xz 1 5

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

Орташа ұйымға мысал есептеу және келесі қадамдар

Сценарий: 200 сервер (150–300 диапазоны), бірнеше критикалық жүйе (ДБ, интеграция шинасы, виртуализация) және желі жабдықтары. Мақсат — стек (Zabbix, Prometheus, Loki) ресурстарға ұялмауы үшін инцидент кезінде барлығы бірге графиктер мен логтарға жүгінгенде де тұрақты болу.

«Орташа» ИТ үшін шынайы бағалау: Prometheus шамамен 250–400 мың белсенді уақытша қатар ұстайды (30 секунд интервалымен). Loki тәулігіне орташа 80–150 ГБ лог қабылдайды (сығылмай), инцидент кезінде ағым 2–3 есе көбейеді. Retention: метрикалар 15 күн, логтар 7 күн «ыстық» іздеу үшін, кейін арзан сақтауқа немесе жоюға.

Барлығын бір түйінге салғыңыз келсе, бастапқы конфигурация ретінде жиі келесілерді ұсынады:

• 16 vCPU (пик сұраныстар мен компакция үшін запас)
• 64 ГБ RAM
• 3–5 ТБ SSD/NVMe деректер мен индекстерге
• ОС және сервистер үшін бөлек SSD

Алайда практикада бөлу жиі тиімді: (1) Zabbix + Prometheus, (2) Loki. Солай логтардың ауыр сұраулары метрикалар мен Zabbix базасына кедергі келтірмейді.

Өсуге запас сан түрінде: жаңа көздер (Kubernetes, аудит), retention өсімі, кардиналдылық пен дашбордтар саны. Көбіне жылына +30–50% CPU мен диск үшін жоспарланады, ал RAM-ды жоғарырақ деңгейде ұстайды, егер жаңа дашбордтар мен ережелер жоспарланған болса.

Келесі қадамдар:

• инфрақұрылаттың 10–20% бөлігіне пилот орнатып 1–2 аптада series count, ingest жылдамдығын, тәуліктік өсімді өлшеу
• лог іздеу мен дашбордтар SLO-ын бекіту, содан кейін retention пен интервалдарды түзету
• дискілерді тексеру: нақты IOPS пен latency пикте және компакция кезінде
• масштабтау шешімі: екінші түйін, рольдерді бөлу немесе HA

Егер пилоттан кейін «темірлік» запас қажет болса — ECC, көп жылдам диск және қолдау екеніне мән беріп, GSE S200 сыныпты серверлеріне қараған жөн. Егер толық шешімді (архитектура, сенімділік, 24/7 қолдау) қажет етсе, жүйелік интегратор GSE.kz қатысуы пайдалы болуы мүмкін.