Мониторинг NVIDIA GPU в дата-центре: DCGM и алерты

Какие проблемы с GPU нужно ловить заранее

Деградация GPU редко выглядит как резкий отказ. Чаще это медленное ухудшение: карта еще работает, но греется сильнее, чаще сбрасывает частоты, а ошибки памяти появляются понемногу. Если заметить это рано, можно заменить карту или перенести нагрузку до того, как пострадают пользователи и сроки.

Для SLA опасны не только поломки, но и тихие потери производительности. Перегрев запускает защитное снижение частот и делает инференс или обучение заметно медленнее. Ошибки памяти (ECC) приводят к сбоям задач, перезапускам контейнеров и, реже, к дорогим ошибкам в результатах. А постоянный троттлинг превращает плановую загрузку кластера в очередь.

Мониторинг NVIDIA GPU в дата-центре удобнее строить в три слоя:

• узел целиком: питание, охлаждение, драйвер, общая стабильность;
• каждая GPU: какая именно карта начинает вести себя хуже;
• приложение: итог для бизнеса - рост времени выполнения, больше ретраев, меньше throughput.

Ранние сигналы, которые важно ловить до инцидента:

• рост температуры при той же нагрузке и тех же оборотах вентиляторов;
• появление корректируемых ECC-ошибок, особенно если счетчик растет каждый день;
• частые события throttling и падение effective clocks под нагрузкой;
• рост потребления при той же производительности (намек на проблемы охлаждения или питания);
• нестабильная утилизация: пилы, провалы, неожиданные простои.

Пример из практики: в одной стойке задачи стали выполняться на 10-15% дольше, но ошибок не было. Если есть метрики температуры, ECC и throttling по каждой карте, причина обычно находится быстро: одна GPU начала перегреваться и чаще сбрасывать частоты, хотя сервер в целом жив.

DCGM простыми словами: что он дает в дата-центре

DCGM (Data Center GPU Manager) - набор инструментов NVIDIA для эксплуатации GPU в серверной среде. Он превращает видеокарту в понятный объект мониторинга: со статусом, историей метрик и быстрыми проверками здоровья. Часто DCGM становится базовым слоем, поверх которого строятся дашборды и алерты.

Сильная сторона DCGM в том, что он стандартизирует сбор данных и делает их сопоставимыми между разными узлами и моделями. Вместо разрозненных показаний из разных утилит появляется один источник метрик и единые проверки.

Health checks и метрики: в чем разница

Health checks отвечают на вопрос: все ли сейчас нормально? Это быстрые тесты и статусы, которые помогают оперативно найти явную проблему: отвалившуюся GPU, критические ошибки, проблемы с драйвером.

Метрики для тренда отвечают на другой вопрос: становится ли хуже со временем? Здесь важны графики за дни и недели: температура при одинаковой нагрузке, рост исправляемых ECC, изменение частот, доля времени в throttling.

DCGM дает данные на разных уровнях, что помогает точнее диагностировать:

• GPU целиком: температура, загрузка, частоты, питание;
• память: объем, ошибки;
• MIG (если включен): метрики по инстансам;
• NVLink и PCIe: ошибки и пропускная способность;
• питание и лимиты: power cap и причины снижения частот.

Частая причина ложных выводов - отсутствие контекста нагрузки. Высокая температура не всегда означает поломку: это может быть долгий 100% compute при нормальной вентиляции. И наоборот, низкая загрузка при высоком энергопотреблении бывает следствием неверных power-лимитов или фоновых процессов. Поэтому полезно смотреть не одну цифру, а несколько признаков сразу.

Exporters и схема мониторинга: как собрать все вместе

В мониторинге важна не только метрика, но и путь, по которому она доходит до графиков и алертов. В инфраструктуре с Prometheus-подходом обычно делают так: DCGM на узле читает состояние GPU, а DCGM-Exporter отдает это как HTTP-метрики.

Типовая цепочка выглядит так:

• узел с GPU: драйвер NVIDIA + DCGM;
• экспортер: DCGM-Exporter;
• сборщик (например, Prometheus или совместимый агент): опрашивает экспортеры;
• хранилище метрик: держит историю;
• дашборды и алерты: графики, пороги, уведомления.

Чтобы не утонуть в данных, разделяйте метрики по уровню: per-GPU для деградации конкретной карты, per-process для понимания, кто грузит GPU и забирает память, per-node для контекста (температура воздуха, питание, вентиляторы, ошибки PCIe).

Отдельно продумайте лейблы. Хорошие лейблы экономят часы расследований. Минимум, который обычно окупается: hostname, gpu_index и uuid, serial (если доступен) или инвентарный ID, slot/pcie_bus_id, pool/role (training, inference, vdi).

Если вы собираете кластеры под ключ, удобно сразу связать эти лейблы с инвентаризацией и поддержкой. Тогда алерт показывает не просто GPU 0, а конкретную карту в конкретном слоте и пуле.

Базовые метрики GPU: что смотреть в первую очередь

Начните с метрик, которые быстрее всего показывают перегрев, упор в питание и скрытую потерю скорости. Эти сигналы часто появляются за часы или дни до явных сбоев.

Температура - не одна цифра. Важно видеть температуру ядра, а также показания для памяти (если доступны) и hot spot. Бывает, что ядро выглядит нормально, а память уже перегревается из-за пыли, высохших термопрокладок или слабого обдува в стойке.

Дальше - потребление и лимиты питания. Пара power draw и power limit помогает понять, теряет ли карта производительность из-за упора в лимит мощности.

Частоты и причины их падения полезнее, чем просто текущая частота. В DCGM обычно видно, почему карта сбросила частоту: перегрев (thermal), ограничение по питанию (power) или защитные режимы надежности (reliability). Это быстро сужает круг причин.

Загрузка (utilization) часто вводит в заблуждение. Высокая загрузка нормальна для обучения или инференса. Проблема начинается, если при той же нагрузке растет время выполнения, а параллельно падают частоты или растет throttling.

Еще один ранний сигнал - PCIe: throughput и ошибки передачи (ретраи, корректируемые ошибки). Рост ретраев на одном узле при одинаковой нагрузке может намекать на плохой контакт, деградацию райзера или проблемы со слотом.

Для быстрого старта держите перед глазами:

• температуры (GPU, hot spot, память);
• power draw vs power limit;
• частоты и причины throttling;
• GPU utilization и memory utilization;
• PCIe throughput и ошибки/ретраи.

Например, на одном сервере S200 Series можно заметить: память на одной карте стала на 8-10 градусов горячее соседних при той же загрузке, а затем появились короткие thermal throttling. Обычно это сигнал разбираться с охлаждением этой позиции до того, как начнутся ECC-ошибки или падения задач.

Метрики ECC и память: как заметить проблемы до падения

ECC в GPU нужен, чтобы ловить ошибки памяти и исправлять часть из них на лету. Для дата-центра это один из самых ранних сигналов деградации.

Ключевое разделение: SBE и DBE. SBE (single-bit error) обычно исправляются и могут не влиять на задачу сразу, но их рост почти всегда говорит, что с конкретной картой или условиями работы что-то не так. DBE (double-bit error) не исправляются и часто заканчиваются сбоями драйвера, падением процесса или необходимостью перезапуска. DBE почти всегда трактуют как инцидент.

Кроме счетчиков SBE/DBE, следите за retired pages - страницами памяти, выведенными из использования. Полезно также подтягивать Xid события из логов драйвера: одиночный Xid может быть случайностью, но повторяющиеся Xid на одной GPU вместе с ростом ECC - явный тренд.

Как отличать разовый шум от деградации:

• смотрите прирост (ошибки в час или в сутки), а не только текущие значения;
• сравнивайте GPU внутри одного узла и между одинаковыми узлами: если одна выбивается, это важно;
• связывайте всплески с температурой, питанием и нагрузкой;
• учитывайте историю: рост после месяцев стабильности тревожнее, чем редкие ошибки с первого дня.

Режим работы сильно влияет на картину. Во время обучения нагрузка и нагрев выше, поэтому скрытые проблемы проявляются быстрее. При инференсе ошибки могут копиться медленнее.

Учитывайте и перезапуски узла: часть счетчиков может сбрасываться после ребута или сбоя драйвера. Поэтому ориентируйтесь на скорость роста по временным рядам.

Небольшой пример

Если на одном сервере SBE растут только на GPU-2, и рост совпадает с периодами, когда температура памяти держится выше обычного, а параллельно начали появляться retired pages, это хороший кандидат на раннюю замену или перенос нагрузок, даже если DBE еще не было.

Throttling и частоты: как понять, что GPU теряет производительность

Throttling - это когда GPU снижает частоты, чтобы не выйти за безопасные рамки. Снаружи это выглядит так: все работает, но стало медленнее. Загрузка может быть высокой, а реальная скорость задач падает.

Частые причины throttling в дата-центре: перегрев (thermal), ограничение по питанию (power), ограничения по надежности (reliability) и сценарии, когда устройство уходит в экономичный режим при низкой нагрузке. В DCGM это видно через счетчики причин throttling и текущие частоты графики и памяти.

Clock capping и заниженные лимиты питания

Иногда проблема не в железе, а в настройках. Жесткое ограничение частот (clock capping) и слишком низкий power limit могут сделать идеально холодную GPU медленной. Если вы видите частые power-throttle события при нормальной температуре, проверьте лимиты питания и профиль работы. Это особенно важно после обновлений драйвера, смены прошивок, замены блока питания или переноса сервера в другую стойку.

Как отличить экономию энергии от деградации охлаждения

Нормальная экономия энергии обычно выглядит так: низкая загрузка, низкое энергопотребление, частоты плавают, но при росте нагрузки быстро возвращаются к ожидаемым.

Деградация охлаждения выглядит иначе: нагрузка стабильная, температура растет, thermal throttling повторяется, а частоты держатся ниже привычных для этой же задачи.

Смотрите не разовые всплески, а длительность и повторяемость. Удобно оценивать долю времени в throttling за 5-15 минут и сравнивать с базовой линией для этой модели GPU и типа нагрузки. Если один и тот же сервер начинает чаще уходить в thermal-throttle на одинаковых задачах, это ранний сигнал: пыль, ухудшение воздушного потока, уставшие вентиляторы или высохшая термопаста.

Пошагово: как настроить мониторинг DCGM и алерты

Начните с простого вопроса: что именно вы хотите ловить? Обычно цели три: инциденты (GPU реально ломается), деградация (падает производительность без явной аварии) и емкость (хватает ли ресурсов кластера).

1) Соберите DCGM метрики и договоритесь о лейблах

Поставьте DCGM и exporter на каждый узел с GPU, чтобы метрики собирались одинаково. Сразу согласуйте лейблы, иначе сравнивать будет сложно. Часто хватает cluster, site, node, gpu_uuid, gpu_index, model, driver, pool.

Затем выберите базовый набор метрик: температура, потребление, utilization, частоты, ECC, причины throttling. Лучше меньше, но стабильно и одинаково на всех узлах.

2) Задайте пороги и временные окна

Пороги без окон часто дают шум. Обычно хватает трех горизонтов: 5 минут (быстрый инцидент), 30 минут (устойчивая деградация), 24 часа (тренд). Краткий скачок температуры - это одно, а устойчивое превышение - уже проблема охлаждения.

3) Дашборды: узел и пул

Сделайте два вида дашбордов: для конкретного узла (все GPU и их отличия) и для пула (распределение температур, частот, ошибок по всем узлам). Так проще увидеть, что одна GPU выбивается из остальных.

4) Алерты без флаппинга и с понятной маршрутизацией

Чтобы алерты помогали, а не раздражали:

• добавляйте задержку срабатывания (держится 10-15 минут);
• разделяйте уровни (warning и critical);
• группируйте по node и gpu_uuid, чтобы не получить десятки одинаковых уведомлений;
• отправляйте ECC и резкое падение частот в дежурную смену, а суточные тренды - в плановые задачи;
• заранее определите владельца: эксплуатация ЦОД, команда ML, вендор/интегратор.

Примеры алертов по температуре, ECC и throttling

Ниже примеры алертов для Prometheus, если метрики собираются через DCGM exporter. Логика простая: warning ловит начало проблемы, critical - когда риск уже высокий и нужно действовать сразу.

groups:
- name: gpu-alerts
  rules:
  # Температура: разные окна для warning/critical
  - alert: GPU_Temperature_Warning
    expr: max_over_time(DCGM_FI_DEV_GPU_TEMP[10m]) > 80
    for: 10m
    labels: {severity: warning}
    annotations:
      summary: "GPU температура повышена"
      description: "Проверьте охлаждение узла (воздух, фильтры, вентиляторы), нагрузку, соседние GPU. Сравните с другими картами в сервере."

  - alert: GPU_Temperature_Critical
    expr: max_over_time(DCGM_FI_DEV_GPU_TEMP[2m]) > 90
    for: 2m
    labels: {severity: critical}
    annotations:
      summary: "GPU перегревается"
      description: "Срочно: уменьшить нагрузку/перенести джобы, проверить airflow в стойке и состояние кулеров. Риск throttling и аварийных остановок."

  # ECC: DBE сразу, SBE по росту за период
  - alert: GPU_ECC_DBE_Detected
    expr: increase(DCGM_FI_DEV_ECC_DBE_VOL_TOTAL[5m]) > 0
    labels: {severity: critical}
    annotations:
      summary: "ECC DBE ошибка на GPU"
      description: "DBE обычно приводит к падениям. Зафиксируйте GPU/сервер, проверьте логи драйвера, планируйте диагностику и замену."

  - alert: GPU_ECC_SBE_Growing
    expr: increase(DCGM_FI_DEV_ECC_SBE_VOL_TOTAL[6h]) > 100
    for: 30m
    labels: {severity: warning}
    annotations:
      summary: "ECC SBE ошибки растут"
      description: "Это ранний сигнал деградации памяти или условий работы. Сравните рост по GPU, проверьте температуру и питание, запланируйте тест."

  # Throttling: доля времени в ограничениях и постоянный cap
  - alert: GPU_Thermal_Throttling_Ratio
    expr: (rate(DCGM_FI_DEV_THERMAL_VIOLATION[5m]) / 1e6) > 0.05
    for: 10m
    labels: {severity: warning}
    annotations:
      summary: "GPU часто уходит в thermal throttling"
      description: "Более 5% времени за последние минуты GPU ограничивает частоты из-за температуры. Проверьте охлаждение и плотность размещения."

  - alert: GPU_Power_Cap_Constant
    expr: (rate(DCGM_FI_DEV_POWER_VIOLATION[15m]) / 1e6) > 0.10
    for: 30m
    labels: {severity: warning}
    annotations:
      summary: "GPU часто упирается в power cap"
      description: "Если это не ожидаемая настройка, проверьте лимиты мощности, блоки питания и распределение нагрузки по GPU."

Комбинированные алерты полезны, когда один симптом не дает уверенности. Например, высокая температура плюс рост thermal throttling почти всегда означает проблему с охлаждением. А рост ECC (особенно SBE) вместе с повторяющимися Xid в логах драйвера - повод быстрее выводить карту из критичных задач.

В тексте алерта полезно писать не только что случилось, но и первый шаг: где подтвердить (метрики, логи драйвера), что сделать за 5 минут (снизить нагрузку, проверить airflow, сравнить с соседними GPU), как понять масштаб (одна GPU, весь сервер, стойка) и когда эскалировать (DBE сразу, повторяющиеся Xid, постоянный throttling).

Реалистичный пример: как нашли деградацию одной GPU

На одном узле внезапно выросло время эпохи: обучение стало идти на 12-18% медленнее, хотя нагрузка и код не менялись. На дашборде было видно, что одна GPU в сервере начала греться сильнее остальных.

По метрикам это выглядело так: температура проблемной GPU держалась около 83-86 C, а у соседних была 70-74 C. Одновременно росло число событий throttling по причине температуры: падали SM clock и memory clock, хотя utilization оставался высоким.

Такое поведение отличается от лимита питания: при power cap обычно видно, что power usage упирается в power limit, в причинах throttling доминирует PWR, а температура может оставаться нормальной.

Затем появился второй сигнал: на проблемной GPU медленно рос счетчик corrected ECC, а на двух запусках были единичные uncorrected. Даже исправляемые ECC-ошибки могут давать просадки: увеличиваются повторы чтения, растет латентность, иногда драйвер начинает вести себя нестабильно.

Действовали по шагам:

• проверили вентиляторы и airflow (обороты, фильтры, направление потока, температуру на входе);
• остановили задачи и почистили узел от пыли;
• проверили прижим и состояние термоинтерфейса, заменили термопасту;
• переставили GPU в соседний слот, чтобы исключить локальный перегрев зоны шасси;
• если ECC продолжит расти после нормализации температуры, запланировали замену GPU.

Результат подтвердили по трендам до/после: температура вернулась к 72-75 C, доля thermal throttling стала близка к нулю, частоты стабилизировались, время эпохи вернулось к прежнему уровню. Счетчики ECC перестали расти под нагрузкой. Это показало, что первопричина была в охлаждении, а не в деградации памяти.

Частые ошибки и ловушки в мониторинге GPU

Самая частая ошибка - свести мониторинг к графику GPU utilization и на этом остановиться. Загрузка и потребление энергии хорошо показывают, чем занята карта, но почти ничего не говорят о здоровье. Деградация чаще видна в температуре, частотах под нагрузкой, ошибках памяти и повторяющихся сбросах.

Вторая ловушка - одинаковые пороги для всех. В одной стойке могут стоять разные модели NVIDIA, разные профили нагрузки (обучение, инференс, VDI) и разная вентиляция. Если выставить единый порог вроде температура 80 C = критично без привязки к модели и условиям, вы либо получите много ложных срабатываний, либо пропустите реальную проблему.

Третья проблема - метрики без идентичности железа. Если не фиксировать uuid/serial и связку сервер-слот-GPU, при инциденте будет трудно понять, какая именно карта деградирует и куда ехать инженеру. Это особенно важно, если карты меняются местами после обслуживания.

Отдельная боль - флаппинг: алерт то появляется, то пропадает. Кратковременный throttling на каждом пике нагрузки быстро превращается в шум, и команда перестает реагировать.

И наконец, отсутствие истории. Без 30-90 дней данных вы не увидите тренд: температура растет на 1-2 градуса в неделю, частоты все чаще упираются в ограничения, ECC-ошибки появляются регулярнее.

Практики, которые помогают:

• разделить производительность и здоровье, завести отдельные алерты на температуру, throttling и ECC;
• настраивать пороги по модели GPU и типу нагрузки, учитывать температуру воздуха;
• сохранять привязку метрик к серийному номеру и месту установки;
• добавлять задержки и условия, чтобы снизить флаппинг;
• хранить метрики достаточно долго, чтобы видеть медленную деградацию и планировать замену.

Короткий чеклист: что проверить за 10 минут

Если нужно быстро понять, все ли в порядке на узле, сравните один проблемный сервер с нормальным соседним (той же стойки или хотя бы той же модели). Такое сравнение часто быстрее любых абсолютных порогов.

Проверьте пять вещей:

• температура GPU и, если доступно, температура памяти: нет ли устойчивого перегрева под нагрузкой;
• throttling: растет ли доля времени с ограничением по температуре или питанию;
• ECC и retired pages: нет DBE, SBE не прибавляются каждый день;
• Xid: нет повторяющихся событий на одной и той же GPU;
• перекос по группе: одна карта или один узел не выбивается из остальных по температуре, ECC и троттлингу.

Ориентир: если у одной карты температура выше соседей на 8-12 C при той же нагрузке, и одновременно растет SBE и появляется throttling, это повод быстро вынести узел в отдельную очередь проверки, пока он не начнет сыпаться в продакшене.

Следующие шаги: стандартизировать мониторинг и поддержку

Когда метрики и алерты уже работают, главный риск - каждый смотрит по-своему. Нужен единый стандарт, чтобы одинаково быстро находить деградацию, не спорить о порогах и не терять время при инциденте.

Сначала определите метрики, которые важны именно вашему кластеру и SLA. Для обучения обычно критичны throttling по питанию и температуре, ошибки ECC и просадки частот. Для VDI и графики чаще важны перегрев, fan speed и стабильность памяти.

Затем закрепите процесс реакции: у алерта должен быть владелец и понятная точка решения - кто получает уведомление, кто подтверждает проблему, кто имеет право вывести GPU из пула и за какое время.

Минимум, который стоит зафиксировать как стандарт:

• набор дашбордов: температура, частоты, power, utilization, память, ECC, причины throttling;
• набор алертов: критические (действовать сейчас) и предупреждения (наблюдать и планировать работы);
• короткий runbook: что проверить за 5 минут, какие логи собрать, когда эскалировать;
• политика карантина: как помечать подозрительную GPU и не давать ей новые задания;
• регулярный просмотр трендов, чтобы ловить медленную деградацию.

Профилактика часто дает больший эффект, чем тонкая настройка порогов: чистка, контроль воздушного потока, проверка вентиляторов и термоинтерфейсов. Если по трендам видно рост температуры при той же нагрузке или увеличение correctable ECC, лучше заранее запланировать обслуживание.

Если нужна помощь с унификацией мониторинга, эксплуатационными стандартами и поддержкой 24/7, это обычно зона системного интегратора. GSE.kz (gse.kz) как производитель и интегратор дата-центровой инфраструктуры может помочь собрать GPU-платформу, организовать сопровождение и закрепить единый стандарт мониторинга для эксплуатации.