Моніторинг температури серверів: де починаються відмови
Температура вузла — не одне число, а набір залежностей: навантаження процесора, температура повітря на вході, оберти вентиляторів, місце в стійці. Поки всі датчики вкладаються в поріг, обладнання працює на знижених обертах і мовчить.
Перший помітний симптом зазвичай не перегрів, а раптовий простій обладнання: тепловий захист знімає навантаження раніше, ніж черговий встигає помітити попередження.
Відмова вентилятора виглядає підступніше. Один модуль із шести виходить з ладу, решта розганяються до максимуму й тримають середню температуру в нормі — але охолоджують вузол нерівномірно, і локально гріється модуль пам'яті або накопичувач.
Якщо оберти кожного вентилятора не знімаються окремим показником, відмову виявляють під час наступного планового візиту інженера або при повторній деградації.
Нерівномірне обдування стійки дає схожу картину вже на рівні інфраструктури. Порожні слоти без заглушок, корпуси різної глибини, потік, який повертається по колу замість проходу через фронт, — і нижні вузли отримують повітря на кілька градусів тепліше за верхні.
Моніторинг температури серверів показує це лише при порівнянні показань на вході й виході кожної одиниці, а не за однією точкою в холодному коридорі.
Причина в усіх сценаріях спільна: знімаються не ті сигнали або знімаються рідко. Поріг спрацювання налаштований на критичне значення, оповіщення йдуть у загальний потік, історія показань не зберігається — тренд не побудувати.
У підсумку перегрів сервера фіксується за фактом виходу з ладу, і йдеться вже про відновлення, а не про профілактику.
Розбираємо, як це закривається: які датчики та оберти вентиляторів збирати, як задавати пороги окремо для вузла й для стійки, щоб відхилення було видно до зупинки обладнання.
Що дає контроль температури та обертів вентиляторів
Температура виходить за поріг не миттєво — це повільний тренд: забитий фільтр, деградація термопасти, зношений підшипник. Пороговий алерт спрацьовує, коли запас уже вичерпано, і в чергового залишається не час на реакцію, а час на розбір наслідків.
Тому знімаємо показання з датчиків впуску й випуску, зон процесорів і дискових кошиків, а окремо — оберти кожного вентилятора через IPMI, напряму з платформи й без агентів усередині операційної системи.
Контроль обертів — раніша ознака, ніж нагрів. Підшипник зношується, оберти за тієї самої уставки просідають на кілька відсотків, і лише через тижні це проявляється температурою й тротлінгом.
На такому сигналі алерт приходить до відмови: час реакції на інцидент вимірюється хвилинами, а не годинами пошуку винуватця за логами.
З того самого тренду рахується ресурс вентиляторів. За нахилом обертів і напрацюванням будуємо прогноз, коли модуль доведеться міняти, і плануємо обслуговування за фактичним зносом, а не за календарем.
Заодно видно, що річ не в залізі: якщо просіли всі модулі в стійці — питання до температури в машинній залі й до фільтрів.
Підсумок — зниження частки відмов: аварійні відключення через перегрів і деградація дисків виходять із класу «раптові». Черговий отримує не абстрактне «сервер гарячий», а конкретний вентилятор, конкретну стійку й запас часу на заміну в плановому вікні.
Варіанти контролю: штатні датчики, збір даних, зовнішнє опитування
Вибір режиму впирається в сумісність з обладнанням: різні покоління платформ віддають температуру процесорів, дисків, блоків живлення й оберти вентиляторів через власні інтерфейси, а частину показників вендор закриває зовсім.
Тому спочатку інвентаризуємо парк і за кожною моделлю фіксуємо, які датчики реально доступні — інакше порогові значення виявляться налаштовані на порожній набір даних, і аварія в стійці не спливе.
Підходи різняться частотою опитування, глибиною й трудомісткістю супроводу. Штатні датчики дають максимум на сучасних платформах, зовнішнє опитування обладнання — на різнорідних стійках і мережевих вузлах, разові заміри закривають приймання й розбір уже сталого інциденту.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Штатні датчики через інтерфейс керування платформою | Однорідний парк, у серверів є контролер керування | Частина сенсорів закрита вендором, набір різниться між моделями, читається лише штатним способом |
| Агент на операційній системі | Є доступ усередину вузла, потрібні метрики разом із навантаженням | Бачить лише те, що віддає система; при зависанні вузла дані перестають надходити |
| Зовнішнє опитування обладнання по мережі | Різнорідний парк, мережеве обладнання, ізольовані сегменти | Потребує узгоджених доступів і розкладу опитування; провал між опитуваннями залишається непоміченим |
| Разові заміри тепловізором і датчиками на стійці | Приймання після монтажу, аудит гарячих зон, пошук причини перегріву | Немає історії та автоматичних порогів, тренд не відстежується |
Порогові значення виставляємо лише після базової лінії: знімаємо показники під робочим навантаженням і в простої, і вже від них рахуємо попередження й критичний рівень.
Такий набір правил не спрацьовує на штатних коливаннях, але ловить зростання температури й падіння обертів вентилятора до того, як спрацює захист вузла.
Порядок впровадження моніторингу: від аудиту до передачі
Порядок етапів тут не формальність: якщо виставити пороги до схеми розміщення датчиків, система реагує на нагрів сусіднього обладнання й на протяг у коридорі, а не на реальний перегрів.
Чергова зміна звикає до хибних спрацювань і перестає на них реагувати — контроль формально є, захисту від відмови немає. Тому маршрут іде від фізичної картини парку до налаштувань, а не навпаки.
- Інвентаризація обладнання. Звіряємо парк зі стійками: де температура й оберти вентиляторів знімаються штатно, де датчиків немає фізично, які вузли критичні для сервісу. На виході — перелік контрольованих одиниць із прив'язкою до місця.
- Схема розміщення датчиків. Точки ставимо на впуску й випуску повітря, у верхніх юнітах стійки та в зонах зворотного потоку — перегрів виникає там першим. Для стійок без вбудованих датчиків добираємо зовнішні.
- Збір і прив'язка показників. Зводимо дані в Zabbix: єдина точка збору, кожен показник прив'язаний до стійки й юніта, щоб повідомлення одразу називало конкретне залізо.
- Налаштування порогів. Два рівні на кожен показник — попередження й критичний, з різними значеннями для навантаженого й резервного обладнання та затримкою підтвердження, щоб гасити короткочасні сплески.
- Перевірка оповіщень. Даємо реальне навантаження, перевіряємо шлях повідомлення до чергового й ескалацію, заміряємо час від відхилення до сигналу. Хибні спрацювання розбираємо й усуваємо до передачі.
- Передача в експлуатацію. Віддаємо описи датчиків, регламент реакції й навчання зміни; залишаємося на зв'язку, поки система не відпрацює повний цикл навантаження.
Конфігурації, схеми опитування та регламенти реагування
Робота здається не звітом, а комплектом, який можна застосувати без нас: розгорнути на другому майданчику, передати новій зміні, використати при розборі інциденту.
Усі артефакти зберігаються в системі контролю версій — зміни проходять перевірку, а попередня редакція залишається доступною для відкату.
- Конфігурації опитування: список вузлів, інтервали знімання, перелік датчиків (процесор, пам'ять, диски, блок живлення, вхідне повітря), пороги попередження й аварії з гістерезисом проти хибних спрацювань.
- Схема опитування: які вузли опитуються напряму, де стоїть проміжний збирач, як дані доходять до сховища й що фіксується при втраті зв'язку з вузлом.
- Карта температурних зон: прив'язка стійок і юнітів до зон, нормальний діапазон для кожної, точки, де датчик є на корпусі, і місця, де потрібен зовнішній.
- Політики доступу: ролі чергового, інженера й зовнішнього підрядника, що можна змінювати без погодження, хто отримує оповіщення, як закриваються доступи при звільненні співробітника.
- Регламент реагування: матриця «подія → дія → строк», розділення попередження й аварії, хто ухвалює рішення про перенесення навантаження.
- Інструкція для чергової зміни: покрокові дії при перегріві, чищенні фільтрів і відмові вентилятора — з командами перевірки й точками ескалації.
- Журнал планових робіт: чищення, заміна вентиляторів, тестові спрацювання оповіщень — з відмітками, щоб тиша в оповіщеннях не читалася як «усе гаразд».
Комплект живе разом з інфраструктурою: при введенні нової стійки карта зон і пороги переглядаються до запуску обладнання, а не після першого перегріву.
Кейс: перегрів у щільній стійці та що показали заміри
Звернулися після серії спонтанних перезавантажень і провалів продуктивності в серверів у щільній стійці. Датчик у залі показував норму, тому причину спочатку шукали в прикладному шарі.
В історії інцидентів за квартал набралося сім подій, і майже всі — у вікно нічного резервного копіювання, коли навантаження на процесори й диски максимальне.
Показники до впровадження контролю виглядали оманливо: температура на вході в нижніх юнітів збігалася із зальною, а розкид між верхніми й нижніми серверами однієї стійки сягав восьми градусів.
Вентилятори постійно крутилися на підвищених обертах — захист вузли не відключала, але запас по нагріву вже було вичерпано.
Що показали заміри
Розмістили датчики на вході кожної групи юнітів і на виході, знімали телеметрію з інтервалом у кілька секунд і звели її з обертами вентиляторів і температурою процесорів у Prometheus.
Теплова карта стійки показала локальний перегрів у верхній третині: туди підсмоктувалося гаряче повітря сусіднього ряду. Датчик у залі таку рециркуляцію не бачить у принципі.
Що змінили
Перестановка обладнання закрила джерело: заглушки в порожні юніти, розділення холодного й гарячого коридорів, перенесення двох найгарячіших серверів нижче рівня рециркуляції.
Поверх — правила оповіщення за порогами: попередження при підході до межі, критично — до входу вузла в режим зниження частоти, плюс окрема перевірка розсинхрону самих датчиків, інакше моніторинг мовчки бреше.
Показники після: розкид температур по стійці скоротився з восьми градусів до двох-трьох, температура на вході в усіх юнітів зрівнялася, вентилятори скинули оберти, і за наступний квартал в історії інцидентів не з'явилося жодної події щодо перегріву.
Заміри перейшли в регулярну звітність — тепер будь-яка перестановка обладнання в залі супроводжується звіркою теплової карти.
Чим відрізняється контроль перегріву від клімату в стійці?
Клімат у серверній залі й контроль перегріву конкретного вузла — різні задачі з різними зонами відповідальності. Кліматична система тримає режим за датчиком на зворотному потоці: поки повітря в залі вкладається в норму, для неї все гаразд. Але на вході в корпус воно вже інше — і це ключова точка розходження.
Усе впирається в точку заміру. Кліматика вимірює повітря, що повертається в блок, а локальний датчик — той, що стоїть на вході повітря в шасі та в зоні процесорів і живлення.
У щільних рядах розходження між цими точками звичайна річ, і саме воно вирішує, чи піде вузол у примусове зниження частоти, чи ні.
| Що порівнюємо | Кліматична система залу | Інженерний моніторинг вузла |
|---|---|---|
| Точка заміру | Зворотний потік, середня по приміщенню | Вхід повітря в корпус, зона процесорів |
| Об'єкт контролю | Ряд стійок, зал загалом | Конкретний сервер і шасі |
| Що бачить | Відмову кондиціонера, зростання температури в залі | Відмову вентилятора, забитий радіатор, локальний перегрів |
| Сліпа пляма | Перегрів окремого вузла | Загальний збій клімату по всьому ряду |
Звідси й межа зон відповідальності. Клімат не побачить вентилятора, що відмовив, або повернутої заслінки сусіднього сервера — для нього зал досі холодний. Локальний датчик, навпаки, не зрозуміє, що вийшов кондиціонер і весь ряд опинився в гарячому коридорі.
Одного рівня контролю тому недостатньо: перший відповідає на питання «у залі нормально?», другий — «вузол у допуску?». Моніторинг температури серверів зводить обидва потоки, щоб перегрів ловився до спрацювання захисту й відключення обладнання.
Технічні сумніви: від сумісності до доступу
Перед стартом проєкту замовник зазвичай піднімає одні й ті самі технічні питання — про мережу керування, старий парк обладнання й доступи. Нижче короткі відповіді, які найчастіше знімають ці заперечення.
Чи не завантажить моніторинг температури мережу керування?
Опитування йде окремим інтерфейсом керування й не змішується з робочим трафіком стійок. Частота задається під кожен клас обладнання: частіше там, де навантаження щільне, рідше для архівних вузлів. Сам збір займає частки відсотка каналу, а при піках черга опитування відсувається.
А якщо частина серверів уже не віддає телеметрію?
Моделі, які не віддають показання штатно, закриваємо зовнішніми датчиками на вході й виході стійки. Для них опираємося на динаміку по групі вузлів, а не на точність окремого сенсора — цього достатньо, щоб уловити локальний перегрів і відмову вентилятора.
Які права потрібні вашій команді?
Сервісний обліковий запис лише для читання — без права змінювати конфігурацію й перезавантажувати обладнання. Секрети зберігаються в захищеному сховищі й ротуються, журнал звернень залишається у вас. Відкликати доступ можна будь-якої миті: збір даних просто зупиняється.
У нас уже впроваджена система контролю — доведеться її міняти?
Ні. Підключаємося другим споживачем і не чіпаємо наявні правила. Іде паралельний період зі звіркою показань і порогів, розходження розбираємо, і лише потім оповіщення переводяться на нову логіку — з можливістю відкату.
Наскільки можна довіряти штатним датчикам?
У них є власна похибка й розкид між партіями, тому пороги будуємо на динаміці: швидкість зростання температури й різниця між входом і виходом повітря. Абсолютне значення залишаємо довідковим — так ідуть хибні тривоги, а справжній перегрів залишається видимим.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Щоб оцінка робіт спиралася на реальний парк, а не на середні цифри, нам потрібен короткий вступний контекст. Опишіть задачу у вільній формі — достатньо кількох абзаців: яке обладнання стоїть, як зараз дізнаєтеся про перегрів, що вже пробували.
Цього вистачає, щоб зрозуміти масштаб і запропонувати схему контролю, яка не потребує перебудови серверних.
Що допомагає нам повернутися з точним планом впровадження:
- Склад парку обладнання — скільки стійок і серверів, моделі, чи є вже датчики й у яких точках вони стоять.
- Поточна ситуація — чи були відключення через температуру, як зараз контролюються вентилятори й повітряні потоки в стійках.
- Схема контролю — які пороги вважаєте аварійними для різних зон і кому мають надходити повідомлення.
- Інфраструктурні обмеження — доступи, ізольовані сегменти, регламенти обслуговування й вікна для робіт.
- Що вже пробували — чому попередні рішення не прижилися або не дали потрібної деталізації.
- Очікування щодо строків — чи є дата, до якої контроль має працювати без вашої участі.
За цими даними ми повертаємося з оцінкою робіт, схемою впровадження за етапами й складом задач — з явним розділенням, що робимо ми, а що залишається на вашому боці. Опишіть задачу зручним способом: листом із переліком стійок або короткою розмовою за фактами.
Обговоримо задачу й повернемося з планом, у якому видно порядок кроків і точку, де контроль уже працює.
