PSU/FAN NOT_FOUND: платформа не отдаёт датчики

Симптом

• Пачка ERROR FAN_NOT_FOUND (несколько подряд) и PSU_NOT_FOUND в одном окне 10–15 секунд, details пустой, события уходят в ARCHIVED.
• Повторяется: в нашей хронике — 28 FAN_NOT_FOUND и 16 PSU_NOT_FOUND за месяцы, всегда всплесками, а не постоянно.
• В GUI «один вентилятор недоступен» на одной ноде; сами psu/fan в модели при этом ONLINE.
• Побочно в SEL — разовый выброс по рельсу напряжения (например, P3V3 SYS), который через секунду снимается.

Что проверить первым (read-only)

1. Отдаёт ли платформа штатный тип: bash sudo ipmitool sdr type "Power Supply" sudo ipmitool sdr type "Power Unit" Пусто — это и есть механизм события; «нет вывода» здесь ожидаемо, а не поломка BMC.

2. Живые значения датчиков: bash sudo ipmitool sensor | grep -iE 'PSU|Fan' Ожидается: входное/выходное напряжение БП (порядка 220 В вход, 12 В выход), ток/мощность, температура, обороты вентиляторов в тысячах RPM. Ноль или na у рабочего блока — реальная проблема.

3. SEL за сутки: bash sudo ipmitool sel elist | tail -20 Ожидается: если есть записи — разовые Asserted/Deasserted по рельсам с интервалом в секунду. Долго висящее Asserted — уже железо, эскалация к оператору.

4. Статус в модели: psu/fan ONLINE, число устройств совпадает с физическим. Если модель показывает NOTFOUND у устройства, которого физически нет, — это ошибка инвентаря, не отказ.

5. Кто эмитит: grep -iE 'psu_status|fan' /opt/ampli/var/log/mona/mona.log | tail -20 — подтверждает, что событие от инвентаризатора модели, а не от драйвера.

Причина

1. Инвентарь перечисляет по типу, а платформа тип не отдаёт

Инвентаризатор модели обходит BMC и перечисляет устройства по штатному IPMI-типу. Если тип «Power Supply» не реализован прошивкой, список пуст → эмитится PSU_NOT_FOUND. То же с вентиляторами: часть банок рапортует no reading, и такие устройства попадают в «не найдено».

2. Алиасы вентиляторов

BMC отдаёт несколько записей на один физический вентилятор (алиасы вида Fan chassis 1A/2A/…), включая каналы, которых физически нет. Модель заводит по ним документы, и они годами висят NOTFOUND/DEGRADED. Это не отказ, а лишние записи инвентаря.

3. Гипотеза: эмиттер не найден в коде

Модуль, который формирует именно эти два события, по нашему разбору не локализован: поиск даёт только тексты в eventdefinitions.ini. Значит, точную точку эмиссии мы не доказали. Проверяется так: воспроизвести событие на стенде с заведомо пустым sdr type "Power Supply" и сопоставить время с циклом инвентаризации; до этого причину «прошивка BMC» считать рабочей гипотезой, а не фактом.

4. Чего в этом классе нет

Разовый выброс SEL по рельсу и PSU_NOT_FOUND — разные вещи. SEL — реальная телеметрия, просто короткая; такие выбросы у платформы повторяются (разные рельсы, 1–2 секунды) и сами по себе не требуют замены блока питания. Связывать их с событиями модели без доказательства нельзя. Правило простое: пока в SEL нет длительного Asserted, а датчики показывают норму, питания это не касается, и трогать железо в окно обслуживания нельзя.

Решение (штатное)

1. Проверить железо пунктами 1–4. Если напряжения и обороты в норме — ничего не менять.
2. Убрать алиасы вентиляторов фильтром в профиле оборудования: в шаблоне железа задаётся ignore_fans_regex со списком лишних каналов. json "ignore_fans_regex": "Fan chassis [0-9]B|Fan chassis 4A|Fan chassis 8A" Значения — из фактического вывода BMC на этой платформе, не копировать чужие.
3. Порядок применения: фильтр → перезапуск монитора (mona) → удаление осиротевших документов вентиляторов → контрольный скан. Инвентаризация с --update-existing удалённые документы обратно не создаёт, но и сама их не удаляет — чистка ручная.
4. Зафиксировать доказательства для вендора: вывод sdr type "Power Supply" (пусто), живые sensor, список событий с временами. Это штатный путь для PSU_NOT_FOUND: дефект инвентаризации, а не наш.
5. Не менять БП и вентиляторы по событию: только по совокупности датчиков, SEL и внешнего осмотра.

Если штатный путь недоступен

Временная мера, не штатно. Если правка профиля недоступна, допустимо закрывать события действием ignore и вести их в списке известных ложных тревог. Событие вернётся на следующем всплеске — мера только снижает шум, дефект инвентаря не устраняет.

Проверка

• ipmitool sdr type "Power Supply" — пусто (ожидаемо для этой платформы).
• ipmitool sensor — оба БП под нагрузкой, вход ~220 В, выход ~12 В, обороты в норме.
• ipmitool sel elist — нет длительно висящего Asserted.
• В модели psu/fan — ONLINE, лишних документов после чистки нет.
• Новых PSU_NOT_FOUND/FAN_NOT_FOUND нет за сутки после фильтра и чистки; если всплеск повторился — сверить время с циклом инвентаризации и приложить к обращению вендору.

Профилактика

• Держать в профиле оборудования актуальный ignore_fans_regex под конкретную платформу.
• В регламенте закрепить: PSU_NOT_FOUND без ipmitool sensor не считается отказом питания.
• Вести журнал SEL-выбросов по рельсам: повторяющийся узор = наблюдение, длительное Asserted = эскалация.
• Не «лечить» событие заменой исправного БП или вентилятора.

Источники и дата

• X200 Service Docs (доступ 2026-11-07).
• Наша практика (обезличено): разбор всплеска FAN_NOT_FOUND ×9 и PSU_NOT_FOUND ×4 на 3-нодном кластере; sdr type "Power Supply" пуст, живые датчики в норме, оба БП несут нагрузку.
• Обновлено: 2026-11-07.