«PACS работает» — фраза, за которой скрываются три совершенно разных утверждения. Порт архива отвечает. Исследования принимаются. Данные действительно лежат там, где считает база, а накопленные задачи выполняются, а не копятся. Мониторинг доступности подтверждает только первое. Две самые тихие аварии PACS он не видит вообще: остановившаяся очередь экспорта и потерянные объекты в хранилище.
Обе обнаруживаются не в момент возникновения, а через недели — когда выясняется, что во второй архив ничего не уходило с мая, или когда исследование не открывается, хотя в списке оно есть. Статья о двух механизмах, которые позволяют увидеть это вовремя: очередях задач архива и проверке хранилища (Storage Verification). Это третья часть разбора прикладной эксплуатации dcm4chee-arc — после удаления исследований и слияния пациентов и исправления атрибутов.
Часть 1. Очереди и задачи архива
Значительная часть работы архива выполняется не в момент обращения, а отложенно, задачами. Пришло исследование — задача на экспорт во второй архив. Настроена проверка хранилища — задача на верификацию. Запрошены данные из внешнего архива — задача на получение. Такая архитектура нужна, чтобы медленный или недоступный получатель не блокировал приём данных от модальности. Обратная сторона: если задачи перестали выполняться, приём продолжает работать, и внешне всё выглядит нормально.
В интерфейсе архива задачи разложены по вкладкам страницы Monitoring: Queues, Export, External Retrieve, Diff, Storage Verification. Это первое место, куда администратор смотрит, когда что-то «не доехало».
Состояния задачи
Задача проходит через понятный набор состояний, и различать их важнее, чем кажется:
| Состояние | Что означает | Реакция администратора |
|---|---|---|
| Scheduled | Задача поставлена в очередь и ждёт выполнения | Нормально, если очередь движется. Тревожно, если число только растёт |
| In process | Задача выполняется сейчас | Насторожиться, если задача «выполняется» сутками: обычно это след падения узла |
| Completed | Выполнена успешно | Ничего. Такие задачи должны автоматически убираться из базы |
| Warning | Выполнена, но не полностью — например, часть объектов не принята получателем | Разобрать обязательно: это не «почти успех», а частичная потеря результата |
| Failed | Не выполнена, попытки исчерпаны | Найти причину. Перезапуск без устранения причины даст то же самое |
| Canceled | Отменена вручную | Убедиться, что отмена зафиксирована в журнале с причиной |
Отдельно про Warning. Это состояние регулярно проскакивают мимо: задача же не упала. На практике за ним стоит ровно то, о чём потом спрашивают через месяц: половина серий ушла во второй архив, половина — нет.
Типовые картины и что за ними стоит
| Что видно в Monitoring | Вероятная причина | Что делать |
|---|---|---|
| Очередь экспорта монотонно растёт, задачи уходят в failed | Получатель недоступен, изменился его адрес или порт, не зарегистрирован AE Title | Проверить связь с получателем (C-ECHO), сверить конфигурацию exporter, и только потом перепланировать задачи |
| Задачи висят в in process и не двигаются | Узел архива был перезапущен или упал во время выполнения | Перепланировать задачи; в кластере — при необходимости на другой узел |
| Много задач в warning | Получатель принимает не все объекты: несовместимый transfer syntax, отказ по отдельным SOP Class, нехватка места на приёмнике | Разобрать один случай до конца по логам обеих сторон, затем исправлять причину, а не задачи |
| Очередь пустая, но исследования во второй архив не уходят | Правило экспорта не срабатывает: условия не совпадают с данными | Проверить условия правила на конкретном исследовании, а не искать неисправность в очередях |
| База данных архива непривычно растёт, хотя исследований столько же | Не настроена автоочистка выполненных задач | Настроить удаление отработанных сообщений очередей |
Главная ошибка в работе с очередями — массовое «перепланировать всё» до того, как понята причина. Задачи уйдут в работу, снова упадут и вернутся в том же количестве, зато будет потеряна картина: какие именно задачи падали и с какими ошибками.
Отмена и перепланирование
Архив позволяет отменять задачи и планировать их заново — как по одной, так и выборкой. В кластере перепланирование поддерживает указание целевого узла: запрос принимается одним узлом и выполняется тем, который указан параметром, а при его отсутствии задача перепланируется на том же устройстве. Для этого узлы должны быть описаны конфигурацией сетевых соединений и веб-приложений со служебным классом DCM4CHEE_ARC.
Порядок работы, который стоит закрепить в собственном runbook:
-
- Зафиксировать состояние: сколько задач, в каких состояниях, с какого времени, с какими сообщениями об ошибке. Скриншот или выгрузка — до любых действий.
- Взять одну упавшую задачу и разобрать её до конца: что за операция, какой получатель, что в логах архива и в логах получателя.
- Устранить причину.
- Перепланировать одну задачу и убедиться, что она прошла.
- Только теперь перепланировать остальные.
- Записать в журнал: сколько задач, почему падали, что исправлено, сколько прошло после исправления.
Гигиена: автоочистка отработанных задач
Записи о задачах хранятся в базе данных архива. Если их не удалять, база растёт, а страница Monitoring со временем становится нечитаемой. Удаление настраивается отдельно для каждого состояния — и это удобно: выполненные можно убирать быстро, а упавшие держать долго, чтобы было что разбирать.
| Атрибут | Что задаёт |
|---|---|
dcmPurgeQueueMessagePollingInterval |
Как часто запускается очистка. Пока не задан, очистка не работает |
dcmPurgeQueueMessageCompletedDelay |
Через какое время удалять успешно выполненные задачи |
dcmPurgeQueueMessageWarningDelay |
То же для задач со статусом warning |
dcmPurgeQueueMessageFailedDelay |
То же для упавших задач |
dcmPurgeQueueMessageCanceledDelay |
То же для отменённых |
PT1H — час, P1D — сутки, P30D — тридцать суток.Разумная отправная точка: выполненные — через сутки, warning и failed — через две-четыре недели. Держать упавшие задачи неделями стоит именно потому, что заявка «а почему в июне не выгрузилось» приходит в июле.
Часть 2. Storage Verification: проверка хранилища
В архиве всегда две истины: записи в базе данных и файлы в хранилище. В норме они совпадают. Разойтись они могут по множеству причин: сбойный диск, отвалившийся NFS-ресурс, чья-то ручная правка, незавершённая операция удаления, ошибка при миграции между хранилищами.
Пока никто не спрашивает конкретное исследование, расхождение незаметно. Storage Verification — механизм, который проверяет соответствие планово, а не в момент, когда исследование срочно потребовалось врачу.
Уровни проверки и их цена
Проверять можно с разной глубиной, и это главный выбор при настройке. Логика уровней такая:
| Что проверяется | Цена | Что поймает и что пропустит |
|---|---|---|
Существование объекта в хранилище — OBJECT_EXISTS |
Дёшево: только обращение к метаданным файловой системы | Поймает пропавшие файлы и неподключённое хранилище. Пропустит повреждённое содержимое |
Совпадение контрольной суммы — OBJECT_CHECKSUM, значение по умолчанию |
Дорого: каждый объект читается целиком | Поймает и пропажу, и порчу содержимого. Создаёт заметную нагрузку на диск и сеть |
Про цену стоит сказать прямее. Проверка по контрольной сумме означает чтение всего проверяемого объёма. Для архива в единицы терабайт на локальных дисках это вопрос планирования; для хранилища на NFS или для nearline-уровня это может означать многочасовую нагрузку на сеть и заметное замедление обычной работы. Поэтому у механизма есть и расписание, и ограничители.
Настройки
Настраивается на уровне устройства архива и Archive AE. Основные атрибуты:
| Атрибут | Что задаёт |
|---|---|
dcmStorageVerificationPollingInterval |
Как часто планировщик берётся за работу. Не задан — проверка не выполняется вовсе |
dcmStorageVerificationInitialDelay |
Отсрочка первой проверки после поступления данных: свежие объекты проверять сразу смысла мало |
dcmStorageVerificationPeriod |
Периодичность повторной проверки уже проверенных объектов |
dcmStorageVerificationSchedule |
Окно, в которое разрешено выполнять проверку — например, только ночью |
dcmStorageVerificationMaxScheduled |
Предел одновременно запланированных задач: защита от того, чтобы проверка не вытеснила обычную работу |
dcmStorageVerificationFetchSize |
Размер порции, которую планировщик берёт за раз |
dcmStorageVerificationPolicy |
Глубина проверки, по умолчанию OBJECT_CHECKSUM |
dcmStorageVerificationStorageID |
Какие хранилища проверять |
dcmStorageVerificationAETitle |
От имени какого AE выполняется проверка |
dcmStorageVerificationUpdateLocationStatus |
Обновлять ли статус расположения объекта по результату проверки |
dcmStorageVerificationBatchID |
Идентификатор пакета для группировки задач в Monitoring |
Запускать проверку вручную для отдельных исследований можно из интерфейса архива: страница Studies, меню дополнительных функций, пункт проверки хранилища. Наблюдать за выполнением — на странице Monitoring, вкладка Storage Verification. Отдельно инициировать подтверждение хранения через DIMSE или REST для этого не требуется: планировщик делает всё сам.
Как читать результат
Расхождение — это сигнал, а не приговор. Прежде чем говорить о потере данных, проверьте более прозаические причины, расположенные в порядке убывания частоты:
-
- Хранилище не смонтировано. Классика: сервер перезагрузился, NFS-ресурс не подключился, каталог на месте, но пустой. Проверяется первым делом.
- Права доступа. Процесс архива перестал читать каталог после смены владельца или обновления.
- Объекты перемещены вручную. Кто-то переносил данные между дисками, не используя средства архива.
- Незавершённая операция удаления. Записи удалены, файлы ещё нет, или наоборот — смотрите разбор двух стадий удаления в первой части.
- Аппаратная проблема. Сбойные секторы, деградировавший массив, отказывающий контроллер. Смотрите SMART и состояние RAID.
- Реальная потеря объектов. Вывод, к которому приходят последним, а не первым.
Чего при расхождении делать нельзя категорически: удалять записи из базы, «чтобы расхождений не было». Это не устранение проблемы, а уничтожение единственного свидетельства о том, что объекты когда-то существовали. Пока запись есть, известно, что именно потеряно, и остаётся шанс найти копию — во втором хранилище, в nearline, во внешнем архиве, куда исследование выгружалось, или в резервной копии.
Правильная последовательность: зафиксировать перечень расхождений с идентификаторами → проверить монтирование и права → проверить состояние дисков и массива → искать копию → эскалировать с полным перечнем. И только по решению ответственного — что-либо менять в записях.
Чем не является страница Metrics
У архива есть встроенные показатели производительности: скорости чтения и записи в хранилище, время удаления объектов, скорости передачи внешним получателям, число одновременных ассоциаций от модальностей и к удалённым системам, время обновления базы данных. Смотрят их на странице Monitoring, вкладка Metrics, настраивают в расширении устройства архива.
Важное ограничение, которое стоит знать до того, как вы начнёте на них опираться: эти показатели не хранятся в базе данных. Они существуют только пока сервер запущен, по умолчанию удерживаются около часа и теряются при перезапуске и при изменении конфигурации.
Отсюда практический вывод: встроенные показатели хороши для разбора «что происходит прямо сейчас» — упала скорость выгрузки, выросло число ассоциаций. Для истории, трендов и прогноза заполнения нужна внешняя система мониторинга, которая собирает и хранит данные у себя. Встроенные метрики её не заменяют.
Что проверять регулярно
Оба механизма бесполезны, если в них никто не смотрит. Минимальный регламент, который имеет смысл превратить в скрипт и в привычку:
| Периодичность | Что смотреть |
|---|---|
| Ежедневно | Свободное место и inode на всех хранилищах. Число задач в failed и warning по каждой вкладке Monitoring. Есть ли задачи, висящие в in process дольше суток. Результат последнего прогона проверки хранилища |
| Еженедельно | Динамика: очередь растёт или движется. Рост базы данных и хранилища. Состояние RAID и SMART. Сроки сертификатов и CRL |
| Ежемесячно | Полный обзор расхождений проверки хранилища. Прогноз заполнения и остаток ёмкости. Контрольное восстановление по ротационному графику. Проверка, что автоочистка задач работает и база не пухнет |
Ключевая мысль: наблюдать нужно за динамикой, а не за абсолютным числом. Сто задач в очереди — норма, если через час их десять, и авария, если вчера их было пятьдесят. Поэтому в ежедневной проверке полезно фиксировать числа, а не просто смотреть на них.
Чек-лист «архив действительно здоров»
-
- DICOM-порт отвечает на проверку связи, web-интерфейс открывается.
-
- Тестовое исследование принимается, находится поиском и открывается во вьювере.
-
- Все настроенные хранилища смонтированы и доступны на запись.
-
- Свободного места и inode достаточно с запасом до следующей проверки.
-
- Очереди движутся: число задач в failed не растёт, нет задач, зависших в in process.
-
- Задачи в состоянии warning разобраны, а не просто присутствуют.
-
- Проверка хранилища выполняется по расписанию, и известно, когда был последний успешный прогон.
-
- Расхождения проверки либо отсутствуют, либо по каждому есть объяснение и решение.
-
- Автоочистка отработанных задач настроена, база не растёт без причины.
-
- Последняя резервная копия выполнена успешно, и это проверено, а не предполагается.
Первые два пункта обычно уже закрыты внешним мониторингом. Остальные восемь — это и есть та часть, которую приходится смотреть руками и которую чаще всего не смотрит никто.
Частые ошибки
-
- Считать, что «сервис отвечает» равно «архив здоров». Порт может отвечать при неподключённом хранилище и вставшей очереди.
-
- Перепланировать все упавшие задачи разом, не разобрав ни одной. Причина не устранится, а картина сотрётся.
-
- Игнорировать статус warning. За ним стоит частичная передача данных.
-
- Оставить проверку хранилища на значениях по умолчанию, не задав окно и ограничители. Проверка по контрольной сумме способна сама создать инцидент, заняв диск и сеть в рабочее время.
-
- Никогда не включить проверку вообще. Тогда о расхождении вы узнаёте от врача, которому исследование нужно сейчас.
-
- Удалять записи о ненайденных объектах. Это уничтожение свидетельства, а не решение проблемы.
-
- Не настроить автоочистку задач. База растёт, интерфейс перестаёт быть пригодным для диагностики.
-
- Полагаться на встроенные показатели как на историю. Они живут только до перезапуска.
Итог
Доступность архива и его исправность — разные вещи. Очереди показывают, выполняет ли архив отложенную работу; проверка хранилища — соответствуют ли файлы тому, что записано в базе. Обе аварии тихие: приём данных продолжается, порт отвечает, мониторинг молчит.
Минимум, который стоит сделать один раз и потом поддерживать: включить проверку хранилища с разумным окном и ограничителями, настроить автоочистку отработанных задач, добавить в ежедневный обход число задач в failed и warning и дату последнего успешного прогона проверки. Это несколько строк в скрипте и одна привычка, которая избавляет от вопроса «почему во второй архив ничего не уходило три месяца».
Источники
-
- dcm4chee-arc wiki: Storage Verification — политики, настройки и запуск проверки хранилища.
-
- dcm4chee-arc wiki: Purge Queue Messages — автоочистка отработанных задач по состояниям.
-
- dcm4chee-arc wiki: Rescheduling Tasks within Cluster — перепланирование задач, в том числе на другой узел.
-
- dcm4chee-arc wiki: Metrics — встроенные показатели производительности и их ограничения.
-
- Export Rule и DICOM Exporter — настройка экспорта, задачи которого чаще всего и появляются в очередях.
-
- Storage Properties и Nearline Storage — свойства хранилищ, которые проверяются.
-
- Удаление исследований в PACS: rejection, IOCM и retention — первая часть разбора.
-
- Слияние пациентов и исправление атрибутов — вторая часть разбора.
Названия настроек, состав политик проверки и вкладок интерфейса приведены по актуальной на момент написания ветке dcm4chee-arc 5.35.x. В более старых инсталляциях они отличаются — сверяйтесь с документацией и интерфейсом своей версии.