DISK_NOT_FOUND на SSD: ложная тревога чекера

Симптом

• Событие DISK_NOT_FOUND CRITICAL по одному или двум SSD; details содержит diskid, device (sdX), buslocation вида pno-1:1, type:SSD, размер.
• В GUI диск показан ONLINE, но событие висит и повторяется циклами чекера.
• В логе монитора (mona) постоянно, каждые доли секунды: No preferred buslocation type was provided, we'll try all buslocation types: ['enc', 'ses', 'nvme', 'sled', 'pno', 'sas', 'lun'].
• Соседние события могут быть про память или супервизор — по времени совпадают, причинной связи нет.

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

1. Что видит ОС: bash lsblk -o NAME,SIZE,TYPE,TRAN,MODEL,SERIAL Ожидается: устройство на месте, размер совпадает с details события, TRAN — sata/nvme.

2. Здоровье диска: bash sudo smartctl -H /dev/<DEV> Ожидается SMART overall-health self-assessment test result: PASSED. Любой другой ответ — это уже не ложная тревога.

3. RAID-массивы: bash cat /proc/mdstat Ожидается все массивы в состоянии [UU], без [_] (degraded). [_] — реальная проблема, идти в статью замена диска и decommission.

4. Статус в модели (GUI → Manage → Machines → диски, или Model API): диск ONLINE, роль (os/meta/blockstore) и серийник совпадают с физическим.

5. Кто именно ругается: bash grep -i 'model_disk' /opt/ampli/var/log/mona/mona.log | tail -20 Ожидается строка про перебор типов buslocation — это подтверждает, что событие от чекера, а не от SMART/RAID.

Причина

1. Чекер сопоставляет диск со слотом, а не проверяет его здоровье

DISK_NOT_FOUND эмитит встроенный чекер модели (model_disk), задача которого — связать физический диск с записью в модели по buslocation. Если сопоставление не удалось, чекер считает диск отсутствующим. SMART, RAID и данные он при этом не проверяет — поэтому событие и реальное состояние железа расходятся.

2. Тип buslocation платформы не разрешается

В нашем разборе диск определён как pno-1:N (слот PCI-подобной нумерации), а чекер работает без «предпочитаемого» типа и перебирает список enc/ses/nvme/sled/pno/sas/lun. Перебор по pno у SSD на этой платформе не даёт совпадения → «не найден». Это дефект сопоставления, а не отказ диска: тот же диск виден в модели ONLINE и отвечает на SMART.

3. Гипотеза: профиль железа не задаёт предпочитаемый тип

Вероятная точка исправления — профиль оборудования (hardware/types/<PROFILE>.json), где задаётся список поддерживаемых buslocation и флаг NG-пути. Логика продукта умеет работать с pno, если тип заявлен в профиле. Проверяется так: сравнить профиль платформы с рабочим профилем, где события нет, и посмотреть, меняется ли поведение чекера после явного указания типа. Без такого сравнения это остаётся гипотезой, и «править профиль на живой системе» без вендорского подтверждения нельзя.

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

Совпадение DISK_NOT_FOUND по времени с OOM_KILLER или MONA_DOWN — не причинная связь. Это разные подсистемы (память / чекер дисков / супервизор), и лечить их нужно раздельно.

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

1. Ничего не менять в железе. Подтвердить пунктами 1–4, что диск жив. Замена работающего SSD по ложному событию — худший исход: снимается исправный носитель и тратится окно обслуживания.
2. Зафиксировать доказательства для обращения: details события (diskid, device, buslocation, type, size), вывод smartctl -H, mdstat, строку из mona.log про перебор buslocation.
3. Передать вендору как дефект сопоставления buslocation для SSD на этой платформе. В обращении — платформа, версия ПО, профиль железа, приложенные выводы. Это штатный путь: код продукта мы не патчим.
4. Если событие мешает эксплуатации (шум в мониторинге, ложные ночные вызовы) — согласовать с вендором подавление конкретного события или правку профиля; самостоятельно «глушить» чекер нельзя, иначе вместе с ложной тревогой уйдёт и настоящая.
5. Проверить соседние классы отдельно: если рядом были события памяти или супервизора, они разбираются своими статьями, а не «за компанию» с дисками.

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

Временная мера, не штатно. Если шум мешает реагировать на настоящие отказы, допускается ручное закрытие события действием ignore (через GUI/Model API) с записью в журнал: причина — подтверждённая ложная тревога, диск проверен. Это не устраняет дефект: событие вернётся на следующем цикле чекера, пока сопоставление buslocation не исправлено вендором.

Проверка

• smartctl -H /dev/<DEV> → PASSED.
• /proc/mdstat → все массивы [UU].
• lsblk → диск на месте, серийник совпадает с моделью.
• Модель: диск ONLINE, роль и слот не менялись.
• grep 'model_disk' mona.log — причина в переборе buslocation, а не в ошибке чтения диска.
• Новых DISK_NOT_FOUND нет после закрытия события/обновления профиля (по договорённости с вендором); до этого — событие повторяется циклами, и это ожидаемо.

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

• В регламенте обслуживания закрепить: DISK_NOT_FOUND без smartctl/mdstat не считается отказом диска.
• Вести список известных ложных тревог платформы и сверять с ним новые события.
• При инвентаризации фиксировать соответствие «модель ↔ устройство ↔ buslocation» — это ускоряет разбор любого дискового события.
• Не менять диски «по событию»: только по совокупности SMART, RAID и модели.

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

• X200 Service Docs (доступ 2026-11-07).
• Наша практика (обезличено): разбор DISK_NOT_FOUND по двум SSD на 3-нодном кластере; диски ONLINE, SMART PASSED, RAID [UU]; причина — перебор типов buslocation чекером model_disk.
• Обновлено: 2026-11-07.