Prometheus-та IPMI және Redfish мониторингі: ескертулер мен дашбордтар

Құрал-жабдықты не үшін қадағалау керек және жетістік қалай өлшенеді

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

IPMI және Redfish BMC-ден тікелей телеметрия береді, және бұл үшін коммерциялық агенттер мен лицензиялар қажет емес. Мұндай тәсіл маңызды, егер серверлер көп болса, парк біртектіс болса, импорт алмастыру талаптары болса немесе хосттарға қосымша программалық қамтамасыз етуді орнатуға болмайтын болса. Экспортёрлер сенсорларды оқиды, ал Prometheus пен Alertmanager оларды метрикалар, ережелер және уведомленияға айналдырады.

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

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

Рөлдер әдетте былай бөлінеді: әкімші Prometheus, экспортёрлер және құқықтар үшін жауапты; ЦОД инженері — стойкалар, салқындату және қуат үшін; ИБ — BMC-ке қалай қауіпсіз қолжеткізуге болатынын бекіту; дежурный смена алерттер алып, бастапқы тексерулерді жүргізеді.

Қарапайым сценарий: стойкадағы серверде бір PSU істен шығып, екінші артық жүктеліп, ішкі температура 8–10°C көтеріледі. Егер ескерту дереу келсе, PSU қызмет көрсету уақытында ауыстырылып, сервис тоқтамай қалуы мүмкін. Бұл типтік стоечные серверлерге және GSE S200 сияқты жергілікті өндірістегі платформаларға да қатысты — сенсорлар арқылы себепті тез растау ыңғайлы.

IPMI мен Redfish нақты жағдайларда не береді

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

IPMI ең қарапайым сенсорлар жиынтығын береді, ол шамамен барлық жерде болады: аймақтар бойынша температуралар (CPU, кіріс ауа, корпустық), вентиляторлардың айналымы, кернеулер мен PSU статустары, кейде ток пен тұтыну. Сондай-ақ қарапайым күй көрсеткіштері — қақпағы ашық па, шамадан тыс қызу бар ма, аппараттық оқиғалар тіркелді ме.

Redfish — заманауи API, онда деректер әдетте құрылымды әрі түсінікті болады: шасси, PSU, вентиляторлар, дискілер, желілік адаптерлер, инвентарь өрістері (сериялық нөмірлер, модельдер), оқиғалар мен журналдар. Бұл нақты қандай PSU немесе қай слоттағы құрылғы істен шыққанын анықтауға ыңғайлы. Жаңа платформаларда Redfish жиі IPMI-дан көбірек ақпарат береді.

Практикада шикі деректер әдетте мына топтарға жинақталады: температуралар, вентиляторлар, қуат (PSU бар/жоқ, кіріс кернеу, OK/Fail статусы), жалпы health-статустар және компоненттер, сондай-ақ оқиға есептегіштері немесе аппараттық қателер белгілері.

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

Лицензиясыз архитектура: жүйені қалай толық жинау

Схема әдетте қарапайым: Prometheus IPMI exportер және/немесе Redfish exportерден метрикаларды скрейп жасайды, Alertmanager ережелерді уведомленияға түрлендіреді, Grafana бәрін бір жерде көрсетеді.

Минималды құрамдастар:

• IPMI exportер (BMC-ті IPMI арқылы опрос)
• Redfish exportер (BMC-ті Redfish/HTTPS арқылы опрос)
• Prometheus (жинау және сақтау)
• Alertmanager (алерттерді маршрутизациялау)
• Grafana (дашбордтар)

Экспортёрлерді қайда орналастыру емес, желіге байланысты. Егер BMC мониторинг зонасынан қолжетімді болса, экспортёрлерді Prometheus-қа жақын ұстау ыңғайлы: жаңарту және отладка оңай. Егер BMC бөлек management-желісінде болса және оған қолжетімділік қатаң шектелсе, экспортёрлерді сол желіге жақын орналастыру логичнее (мысалы, management VLAN ішіндегі торапта), сонда қажетсіз өту пункттерін ашпайсыз.

Желілерді қатты бөліп қойған дұрыс: production (қызметтер) басқару (BMC) желісіне тікелей қосылмауы керек. Мониторинг үшін әдетте BMC-ке тек бір рұқсат етілген маршрут қалдырылады. Таралған нұсқа — екі интерфейсі бар мониторинг торабы: бірі Prometheus/Grafana аймағында, екіншісі management-та және тек сол торап BMC-ті опрашивает.

Егер BMC мониторинг аймағынан тікелей қолжетімді болмаса, аралық нүкте пайдаланыңыз: jump-хост немесе шағын прокси-узел, ол BMC-ті опрашива отырып, метрикаларды бір адрес бойынша сыртқа береді. Мысалы, стойкадағы серверлер үшін (оның ішінде GSE S200 сияқты) бір прокси management-желісінде орнатып, Prometheus тек соны скрейп етеді. Осылайша оқшаулануды сақтай отырып, температура, вентиляторлар және қуат бақылауын жоғалтпайсыз.

Қадамдық бастама: нөлден алғашқы метрикаларға дейін

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

Экспортёрлерді орнатпас бұрын BMC инвентаризациясын жасаңыз: адрес, сервер моделі, оқу паролі, желілік сегмент. Егер стойкада мысалы GSE S200 Series тұрса, rack және рөл (storage, compute, mgmt) сияқты ақпаратты дереу тіркеу пайдалы — кейін дашбордтарда табу оңай болады.

Келесі қадамдардан бастаңыз:

• IPMI және/немесе Redfish exportерін Prometheus-қа жақын іске қосып, қатынауды жылдам отладтаңыз;
• 2–3 серверде негізгі метрикаларды көріп тұрғаныңызды тексеріңіз: температуралар, вентилятор жылдамдықтары, PSU күйлері;
• Prometheus-қа scrape job қосып, бірден лейблдар орнатыңыз: site, rack, role;
• ақылға қонымды интервал қойыңыз (мысалы, 30–60 секунд) және опрос BMC-ті жүктемейтінін тексеріңіз;
• сәтті тексеруден кейін мақсаттар тізімін бүкіл паркіге кеңейтіңіз.

Егер метрикалар келмесе, көбінесе мәселе Prometheus-та емес, басқару желісінде, BMC логинінде немесе кейбір серверлерде қажет интерфейс өшірілгенінде болады. Алдымен бірнеше торапта тұрақты деректерді алыңыз, содан соң масштабтаңыз.

Метрикаларды нормализациялау: ескертулердің шудан тазартылуы

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

Бастапқыда бірліктерге назар аударыңыз. Температураны °C-де ұстаңыз, кернеу — V, қуат — W, вентилятор жылдамдығы — RPM. Егер экспортёр мәндерді ондықтарда немесе милливатттарда берсе, recording rules арқылы түзетіңіз, осылайша алерттер мен дашбордтар әртүрлі модельдерде бірдей жұмыс істейді.

Содан кейін сенсор атауларын шешіңіз. IPMI-де «CPU Temp», «CPU1_T», «Processor 1» тәрізді әртүрлі нұсқалар болады. Redfish-та «CPU1» немесе «CPU.Socket.1» болуы мүмкін. Практикалық тәсіл — сәйкестік сөздігі жасап, негізгі категорияларға (cpu, inlet, exhaust, vrm, psu) және реттік нөмірге нормализациялау.

Лейблдар мәселені стойка мен сервиске жылдам тарылту үшін керек. Минималды жиын: dc (орын), rack, host, role (db/app/vdi), service (команда немесе бизнес-сервис).

Шуды тудыратын сенсорларды бөлек шығарып тастаңыз: қосылмаған (state: unavailable), үнемі нөл көрсететіндер, бірлігі жоқ, бірдей көрсеткішпен қайталанатын датчиктер. Жақсы ереже: ескертулерге тек өткен тәулікте кемінде N минут тұрақты болған сенсорлар кіреді.

Порогтарды рөлге қарай қойыңыз. GPU-ға тығыз толтырылған кластер үшін inlet шегі басқа болады, ал файлдық сервер үшін — өзгеше. Егер сенім аз болса, статикалық порогтардан бастап, кейін baseline қосыңыз (мысалы, соңғы 7 күннің p95 + қорғаныш).

Қуатты нормализациялау үш нәрсені қамтиды: PSU статусы (ok/fail), кіріс қуат және резервтеу. Егер redundancy lost болса, бұл бөлек және жоғары приоритетті алерт болуы керек — тұтыну өсімімен шатастырмау үшін. «AC fail» бөлек класс ретінде қарастырған дұрыс.

Температура, вентилятор және қуат бойынша минималды алерттер

Минималды алерттер нақты поломкаларды ұстап, секундтық секірістер үшін адамдарды оятпауы керек. Екі деңгейді ұстау ыңғайлы: warning (тексеру) және critical (шұғыл әрекет).

Температура: warning пен critical және секірістерден қорғау

Температура қысқа уақытта секіріп кетуі мүмкін. Сондықтан срабатывание уақытын (for) және екі порог қойыңыз: ескерту және авариялық.

- alert: HostTempHighWarning
  expr: (max_over_time(node_hwmon_temp_celsius[5m]) \u003e 75)
  for: 10m
  labels: {severity: \"warning\"}
  annotations:
    summary: \"Высокая температура (warning)\"

- alert: HostTempHighCritical
  expr: (max_over_time(node_hwmon_temp_celsius[2m]) \u003e 85)
  for: 3m
  labels: {severity: \"critical\"}
  annotations:
    summary: \"Высокая температура (critical)\"

Деградация сигналы да пайдалы: температура қалыпты жүктеме кезінде де өсіп жатса. Мұндай алерт міндетті түрде критикалық болмауы мүмкін, бірақ стойкада сүзгілердің бітеліп жатқаны немесе салқындатудың проблемасы бар екендігін көрсетуге көмектеседі.

- alert: HostTempRising
  expr: (predict_linear(node_hwmon_temp_celsius[30m], 30*60) - node_hwmon_temp_celsius) \u003e 8
  for: 20m
  labels: {severity: \"warning\"}
  annotations:
    summary: \"Температура растет быстрее обычного\"

Вентиляторлар мен қуат: "сенсор жоқ" пен аварияны айыра білу

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

Уведомленияларды маңыздылыққа қарай бағыттау ыңғайлы:

• warning: дежурный инженер (жұмыс уақыты ішінде тексеру)
• critical: дежурный + on-call (жедел әрекет)
• "сенсор недоступен": бөлек арна, нақты аварияларды маскаламас үшін

Егер сізде GSE стойкасы болса, мұндай алерттер әдетте типтік сценарийді тез көрсетеді: бір PSU өшті, резервтелу жоғалды, температура пайдаланушылар шағымданардан бұрын өсе бастады.

Alertmanager орнату: аз шу, көп пайда

Метрикалар Prometheus-қа түскеннен кейін ең көп кездесетін проблема — уведомленияның толқыны. Alertmanager мақсат — бір айқын инцидентке жүздеген ұқсас хабарламаның орнына біріктіру.

Алдымен группировканы ұйғарыңыз. Егер бір стойкада немесе желі сегментінде массалық температура көтерілуі болса (мысалы, кондиционердің істен шығуы), "стойка A2" туралы бір хабарлама алу 40 серверге қатысты әрқайсысына жеке хабарламадан гөрі пайдалырақ. Көбінесе group_by ретінде rack, dc және alertname жеткілікті.

Дедупликация — Prometheus бірдей алерттер жіберсе, Alertmanager оларды біріктіреді. Бұл үшін group_wait және group_interval мәндерін ақылға қонымды қойып, repeat_interval-ды ұзақ етіп қойыңыз (мысалы, бірнеше сағатқа), осылайша дежурный үнемі бір хабарламаны бірнеше минут сайын алмайды.

Техникалық жұмыстарды Silences арқылы жабу ыңғайлы. PSU ауыстыру немесе BMC firmware жаңарту сияқты жоспарлы жұмыстар түнде адамдарды оятпауы керек. Silences-ты instance, rack немесе service бойынша сүзеді.

Уведомление мәтіні көп мәселені шешеді. Алерт аннотацияларында қысқа «автокомментарий» қосыңыз: сервер мен оның орны (rack/row), сенсор және ағымдағы мән, порог пен деңгей, әрі қысқа нұсқау («вентилятор/PSU/кіріс температурасын тексеру»).

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

Grafana үшін минималды дашбордтар жинағы (5)

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

1. Обзор парка (health). Температура, вентиляторлар, қуат және сенсор қателері бойынша серверлер саны: OK, warning, critical. Қасында ең проблемалы хосттар кестесі.

2. Стойкалар бойынша жылу картасы. Әр стойка үшін сервердегі максимум температура (CPU, inlet, system). Ең ыстық сервер бойынша тренд қосу пайдалы — салқындату деградациясын алдын ала байқауға көмектеседі.

3. Қуат және резервтелу. PSU статустары, N+1 жоғалту және кіріс қуат/тұтыну графиктері (егер сенсорлар бұл мәліметті берсе).

4. Вентиляторлар және ауа ағыны. Non-OK статусындағы вентиляторлар тізімі және маңызды тораптар үшін RPM графиктері. Көп жағдайда бір вентилятордың «қозғалысы» толық істен шығудан бұрын көрінеді.

5. BMC және экспортёрлердің қолжетімділігі. up/скрейп панельдері, опрос ұзақтығы және қателер саны. Бұл нақты аппараттық ақаудан емес, BMC-тің желі бойынша немесе экспортёрдің ілініп қалуынан туындаған жағдайларды ажыратуға көмектеседі.

Дашбордтарды ыңғайлы ету үшін бірдей айнымалылар мен бірдей топтауды енгізіңіз: site, rack, host, model; ортақ warning/critical порогтар; "деректер жоқ" және "сенсор қате" белгілерін айыра білу; алерт аннотациялары; және қайдан алынғаны (IPMI немесе Redfish) анық көрсетілуі.

Қауіпсіздік және қолжетімділіктер: BMC-ті осал нүктеге айналдырмау

BMC (IPMI/Redfish) ОС-тан бөлек өмір сүреді, сондықтан оны жаңартуды, желіден бөлу мен қолжетімділікті шектеуді жиі ұмытып кетеді. Мониторинг үшін бұл ыңғайлы болса да, қауіпсіздік тұрғысынан сервердегі ең қауіпті интерфейстердің бірі болуы мүмкін.

Учеттік жазбалар: кім парольді біледі және қалай ауыстырады

Ережесі қарапайым: BMC-ке қолжетімділік минималды адамдар тобында болуы керек және сервис аккаунттары арқылы, жеке логиндер арқылы емес.

Практикалық минимум:

• парольдерді конфигурацияда немесе ашық ортада емес, құпия сақтау орнында (secret store) сақтаңыз;
• тек сенсорларды оқу үшін бөлек қолданушы пайдаланыңыз (мүмкін болса);
• кұпиясөздерді кестеге сай және кадр өзгерістерінен кейін ауыстырып тұрыңыз;
• әдепкі есептік жазбаларды өшіру немесе атауын өзгерту;
• қандай BMC-аккаунт қай сервер пулына қатысты екенін тіркейтін тізім жүргізіңіз.

Желілер мен протоколдар: BMC-ті қажетсіздердің қолынан қорғау

Идеалдық схема: BMC бөлек басқару желісінде, ал оған тек мониторинг торабымен (және қажет болғанда әкімшілердің jump-хостымен) қолжетімділік бар. Фаерволда немесе ACL-де мониторинг IP-інен ғана IPMI/Redfish порттарына рұқсат беріңіз, қалғанын бұғаттаңыз.

Егер Redfish қолдансаңыз, мүмкін болса TLS қосыңыз. Кейбір модельдер ескі фирмаверде дұрыс TLS-ды қолдамайтынын немесе бұзылатынын ескеріп, барлық жабдыққа бірдей конфигурация орнатпау керек. Оларды аппараттық типтерге бөліп (әр түрлі job немесе экспортёр конфигурациясы) және ерекшеліктерді уақытша әрекет ретінде жазып қою пайдалы.

Инцидент талдау үшін логтар

Тек алерттерді ғана емес, опрос сапасын да журналдаңыз: таймауттар, аутентификация қателері, кешігулердің өсуі, қолжетімсіз BMC саны. Мысалы, GSE S200 сияқты стойкада бірнеше торапта Redfish таймауттары басталса, көбінесе барлығы «бұзылып қалды» емес, басқарушы коммутатордың жүктелуі немесе ACL қате болуы мүмкін. Экспортер логтары мен опрос метрикалары бойынша бұл тез көрінеді.

Енгізуде жиі кездесетін қателіктер және тұзақтар

Ең жиі кездесетін проблема — BMC-ті тым жиі опрашивать жасау. Әр минут сайын жинау логикалық көрінсе де, көптеген контроллерлер баяулап, таймаут береді немесе сұрауларды уақытша блоктай бастайды. Нәтижесінде графиктер рваные болады, ал алерттер жинаудан емес, аппараттық ақаудан срабатығандай көрінеді.

Екінші тұзақ — барлық серверге бірдей порогтарды қолдану. Температура модельге, фирмаверге, стойкадағы орналасуына және жүктемеге байланысты. Жоғарғы бөлікке орналасқан немесе «ыстық дәлізде» тұрған сервер тұрақты түрде 5–10°C жоғары болуы мүмкін — бұл міндетті түрде авария емес. Базалық порогтардан бастап, рөл немесе стойка бойынша ерекшеліктерге орын қалдырыңыз.

Алерттерге кешіктірілмей және топталмай жіберу түнгі будильникке айналады. Вентилятордың қысқа секірісі, қуат сенсорындағы жалғыз глитч немесе басқару желісінің секундтық үзілуі үшін адамдарды ояту мониторингке сенімділікті жояды.

Жібермес бұрын тексеріңіз:

• BMC опрос интерваллары ақылға қонымды (көбінесе 2–5 минут жеткілікті);
• алерттерде ұстап тұру (for) бар (мысалы, 5–10 минут);
• алерттер хост/стойка бойынша топталған, әр сенсор бойынша емес;
• мониторится өз контур: Prometheus, экспортёр және басқару желісі;
• жауапкершілік бөлінген: жабдық бөлек, қолданбалар бөлек.

Тағы бір типтік қателік — аппараттық алерттер мен қолданбалы алерттерді бір арнаға жіберіп, жауапты анықтамай қалу. Нәтижесінде PSU мәселесін dev-дар қарап, сервис құласа жүйелік инженерлерге жүгінуі мүмкін. Арналарды бөлу немесе Alertmanager-да маршруттарды анық жазу керек.

Продқа жібермес бұрын жылдам тексерістер

Продқа жатқызардан бұрын жүйе түнгі уақытта пайдалы болатынына сенімді болу маңызды. Бұл тексерістер 30–60 минут алады, бірақ бірінші инциденттен кейінгі күндердегі талқылауларды жиі үнемдейді.

Дайындық чек-листі

Басты бес нәрсені тексеріңіз, олар іске қосу кезінде жиі бұзылады:

• BMC инвентары жаңартылған: біртекті тізім, логиндер, желілерге қолжетім және жаңа серверді орнатқанда күні ішінде қосу процесі;
• үш негізгі алерт сценарийі өтеді: перегрев, PSU сәтсіздігі және BMC қолжетімсіздігі (маңыздысы — тек алерт келуі емес, Grafana-да оңай табылуы);
• алерттерге иесі бар: түнде кім қабылдайды, таңертең кім растайды, не нормамен саналады (мысалы, перезагрузка кезінде қысқа секіріс);
• дашбордтар жылдам ашылады және site, rack, role бойынша сүзгіленеді;
• модельдер бойынша порогтар мен ерекшеліктер туралы қысқа құжат бар.

Тесті қалай жылдам өткізуге болады

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

BMC қолжетімсіздігін мониторинг желісінен уақытша блоктап немесе басқару интерфейсін өшіріп тексеріңіз, содан соң қайтару. Температураны қауіпсіз түрде тестілеу үшін уақытша алерт порогын 10–15 минутқа төмендетіп, срабатывание барлығын тексеріп, кейін қайтарыңыз.

Егер серверлер бірнеше орындарда (мысалы, Қазақстанның әр түрлі қалаларында) орналасқан болса, site және rack тегтері барлық жерде бірдей толтырылғанына алдын ала көз жеткізіңіз. Әйтпесе сүзгілер мен алерт маршрутизациясы дежурныхты шатастырады.

Практикалық мысал: PSU сәтсіздігі және стойкадағы температураның өсуі

10 серверлі стойка. Әрқайсысында екі PSU (A/B) және IPMI немесе Redfish арқылы BMC бар. Күнделікті жағдайда бір сервер N7-те бір PSU істен шығады, бірақ сервер құламайды: қуатты екінші канал ұстап тұрады. Кейін жағымсыз бөлігі басталады. 40–60 минут ішінде стойкадағы температура көтеріле бастайды, себебі бір PDU-каналға қосымша жүктеме түседі, кабель жүйесі артық жүктеледі, кей вентиляторлар жылдамдығын жоғарылатады.

Бірінші сигнал көбіне қуат туралы болады: резервтелудің жоғалуы. "PSU redundancy: OK" орнына "Degraded" немесе бір power_supply_status жоғалуы пайда болады.

Кейін екінші алерт келеді: температура warning. Көп жағдайда бұл бірнеше серверде бірден "Inlet temperature жоғары" немесе "CPU temp warning" болады. Бұл көрсеткіш проблема бір хостта емес, целая стойкада болуы мүмкіндігін білдіреді.

Дежурный қысқа сценарий бойынша әрекет етеді: қуат дашбордын ашып, қай жерде A/B желісінің жоғалғанын көреді; жылу картасын қарап, қызатын белгілі бір сервер бар ма әлде бірнеше ме екенін анықтайды; inlet және ішкі датчиктерді салыстырады; вентиляторлар жылдамдығын қарайды (бір топ серверде RPM-ның тез өсуі ауа салқындатудың нашарлағанын көрсетеді).

Егер бір хост қызарып жатса, көбінесе себебі сол хосттың PSU, вентиляторы немесе радиаторы. Егер бірнеше құрылғыда inlet пен fan speed бір уақытта өссе, қуат тарату, ауа ағыны (жабық заглушкалар, ауа қабылдау жабылған), бөлме температурасы немесе PDU-дың жүктелуі сияқты ортақ себептерді іздеңіз.

Әрі қарай әрекеттер белгіленеді: PSU-ды ауыстыру (redundancy: OK қайтуы), кабельдерді және ауа ағынын тексеру, температура қалыпқа келгенін және алерттердің өздігінен жапқанын бақылау (оларды жай ғана дауыссыздандырмау керек).

Келесі қадамдар: тұрақты эксплуатацияға жеткізу

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

Келесі қадам — дискілерді (SMART), RAID-контроллер күйін және SEL оқиғаларын қосу. SEL арнайы пайдалы, себебі сервер өзі қайта жүктелгенде немесе қуат үзіліп кеткенде ОС-та іздер сирек қалады.

Тағы бір деңгей — жеке серверлерді ғана емес, стойкалар мен зона бойынша мониторинг. Массовое нашарлау (мысалы, 6–10 серверде бір уақытта температура көтерілуі немесе кернеудің түсуі) бөлек инцидент ретінде қарастырылуы керек, бұл мәселені жылдам табуға көмектеседі: салқындату, PDU, жалпы қуат контуры немесе залдағы вентиляция.

Порогтар мен реакцияларды нақтылауды ЧОД және ИБ-пен бірге жасаңыз. Бір порог әртүрлі модельдер үшін қалыпты болуы мүмкін, ал кейбір әрекеттер (мысалы, BMC-ге қолжетімділік) қатаң реттелуі тиіс.

Практикалық регламенттің минимумі:

• кім алерт қабылдайды және қандай мерзімде;
• перегрев, вентилятор істен шығуы, PSU мәселесі кезінде не істеу;
• қашан авариялық режимге көшу (жүктемені азайту, өшіру);
• өтінішке қандай деректер қоса берілуі тиіс (график, SEL оқиғалары, сервер моделі).

Егер сіз сервер паркін құрып немесе жаңартсаңыз, BMC мониторингін бастапқы кезеңде енгізу оңайырақ: бөлек басқару желісін бөлу, рөлдерге сай есептік жазбалар, IPMI/Redfish экспорт шаблонын бірдей енгізу және өндіріске өткір алдында алерттер тестін өткізу.

Қазақстандағы жобалар үшін бұл көп жағдайда жеткізу мен интеграция кезеңінде орындау ыңғайлы — мысалы, GSE.kz S200 Series серверлерін енгізгенде BMC қолжетімділік схемасын алдын ала келісіп, мониторинг орнатуды жалпы жұмыс жоспарына қосуға болады, сонда өндіріске кейін қайта оралу қажет болмайды.