Экспресс-чек инфраструктуры Directum RX: Демонстрационный контур

2026-10-01 21:20 · rxdoctor 0.3.0 · утилита только читает состояние и ничего не меняет
7проблемы
7внимание
29норма
Сначала главное

PostgreSQL

Источник: скрыто · 30 с
PG-01Соединения к лимитунорма
3 из 100 (3 %)
PG-02Долгие транзакциивнимание
2 транзакции дольше 5 минут, самая старая 12 мин
Чем грозит: долгая транзакция держит блокировки и мешает autovacuum, таблицы раздуваются, очереди RX встают
Что делать: найти сессию по pid, разобрать запрос с разработчиками, выставить idle_in_transaction_session_timeout
pid 82, postgres, psql, idle in transaction, 12 мин: update documents set name = name where id = 1;
pid 90, postgres, psql, active, 12 мин: update documents set name = 'x' where id = 1
PG-03Сессии idle in transactionвнимание
1 сессия idle in transaction дольше 5 минут, самая старая 12 мин
Чем грозит: сессия открыла транзакцию и ничего не делает: блокировки держатся, autovacuum не может очистить строки
Что делать: idle_in_transaction_session_timeout на роли приложения, поиск места в коде, где транзакция не закрывается
pid 82, postgres, psql, 12 мин: update documents set name = name where id = 1;
PG-04Ожидающие блокировкипроблема
1 сессия в ожидании блокировки, самое долгое ожидание 12 мин
Чем грозит: цепочка блокировок: пользователи ждут, задания RX не двигаются, возможны дедлоки
Что делать: разобрать блокирующую сессию по pid, передать запросы разработчикам, проверить долгие транзакции
pid 90 ждёт 12 мин, блокируют pid [82]: update documents set name = 'x' where id = 1
PG-05Мёртвые строкинорма
у крупных таблиц (больше 1 ГБ) мёртвых строк меньше 20 %
PG-06Autovacuumнорма
включён, scale_factor 0.2, крупные таблицы вакуумируются
PG-07Возраст транзакцийнорма
максимальный возраст 0 млн (postgres)
PG-08Вынужденные чекпоинтынорма
по расписанию 2, вынужденных 1 (33 %) с последнего сброса статистики 12 мин назад
PG-09Попадание в кэшнорма
за окно 30 с ни одна база не читала с диска заметно (порог 78.1 МБ), кэш справляется
postgres: за 30 с обращений 73, с диска 0 (0 Б), из кэша 100 %; накопительно 96 % за всё время (статистику не сбрасывали)
rx: за 30 с обращений 1706, с диска 0 (0 Б), из кэша 100 %; накопительно 97 % за всё время (статистику не сбрасывали)
PG-10Размер базынорма
база RX 7.5 МБ, все базы кластера 29.4 МБ
Что делать: свободное место на томе проверяет хостовый сборщик; сохраните отчёт, чтобы видеть рост между запусками
PG-11Репликанорма
реплик не подключено
Что делать: если реплика по плану есть, а здесь её нет, это проблема; если нет по плану, точка восстановления равна последней копии
PG-12Архив WALнорма
архивирование WAL выключено
Что делать: точка восстановления равна последней полной копии; если RPO должен быть меньше, нужен архив WAL или реплика
PG-13Каталог WALнорма
1 сегментов, 16.0 МБ, max_wal_size 1GB
PG-14Слоты репликациивнимание
1 слот, неактивных 1
Чем грозит: неактивный слот держит WAL бесконечно, пока диск не кончится
Что делать: если потребителя слота больше нет, удалить слот; если реплика временно выключена, вернуть её
old_replica: неактивен, удерживает 570.5 КБ WAL
PG-15Версиянорма
PostgreSQL 16.15, поддержка мажорной версии до 2028.11
PG-00Учётка запусканорма
запущено под суперпользователем postgres
Что делать: для регулярных запусков удобнее отдельная роль с pg_monitor: rxdoctor grant

RabbitMQ

Источник: скрыто · 30 с
MQ-08Накопление в очередяхпроблема
всего 12152 сообщений в 3 очередях, в самой большой 12000
Чем грозит: очередь копится быстрее, чем разбирается: задания, уведомления, преобразование и индексация документов приходят с задержкой или не приходят
Что делать: по имени очереди понять сервис-потребитель и проверить его: запущен ли, хватает ли ему памяти и процессора, нет ли блокировок в СУБД (PG-04); если потребителей 0, см. MQ-01
rx_indexing_service (/): 12000 сообщений, готовых 12000, в обработке 0, потребителей 0
rx_jobs_configure (/): 150 сообщений, готовых 150, в обработке 0, потребителей 0
rx_entitycache_0a1b2c3d4e (/): 2 сообщений, готовых 2, в обработке 0, потребителей 0
MQ-01Очереди без потребителейпроблема
2 очереди с сообщениями и без потребителей, всего 12150 сообщений
Чем грозит: сообщения никто не читает: либо сервис RX, который должен их обрабатывать, не запущен, либо очередь осиротела и копит мусор
Что делать: сопоставить очередь с сервисом RX и проверить, что он живой; осиротевшие очереди удалять после подтверждения, что потребителя нет по плану
rx_indexing_service (/): 12000 сообщений
rx_jobs_configure (/): 150 сообщений
временных очередей экземпляров без потребителя: 1, в них 2 сообщений (остаются после рестарта сервисов, это штатно)
MQ-02Рост очередейнорма
за 30 с ни одна очередь заметно не выросла
MQ-03Неподтверждённые сообщениянорма
очередей с большим числом неподтверждённых сообщений нет
MQ-04Тревоги брокеранорма
тревог нет, память и диск в норме
rabbit@99b06c58cb54: память 166.9 МБ из лимита 7.0 ГБ, диск свободно 91.9 ГБ (порог 47.7 МБ)
MQ-05Узлы кластеранорма
кластер rabbit@99b06c58cb54: работает 1 из 1 узлов, ожидалось 1
rabbit@99b06c58cb54: работает, uptime 12 мин, разделений 0
MQ-06Число очередейнорма
3 очередей, 0 потребителей
MQ-07Версиянорма
RabbitMQ 3.13.7, Erlang 26.2.5.16

Полнотекстовый поиск

Источник: скрыто · 66 мс
ES-01Здоровье кластеравнимание
docker-cluster: yellow, узлов 1 (данных 1), шардов 1, неназначенных 1; один узел данных, реплики разместить негде
Чем грозит: жёлтый на одном узле означает, что у индексов заданы реплики, которые никогда не поднимутся; сами данные доступны
Что делать: для одного узла задать number_of_replicas: 0 в шаблоне индексов, тогда статус станет зелёным честно
ES-02Шарды к лимитунорма
1 шардов из лимита 1000 (1000 на узел × 1 узлов, 0 %)
ES-03Диск к порогамнорма
максимум 53 % занято, пороги low 85 % и high 90 %
ea1ae7a25c8b: занято 104.8 ГБ из 196.7 ГБ (53 %), шардов 1
ES-04Куча JVMнорма
максимум 27 % кучи занято
ea1ae7a25c8b: куча 512.0 МБ, занято 27 %
ES-05Отклонённые запросынорма
пулы write и search ничего не отклоняли с момента запуска узлов
ES-06Версиянорма
Elasticsearch 8.15.3
ES-07Блокировка записипроблема
1 индекс закрыт на запись
Чем грозит: в закрытый индекс ничего не пишется: новые и изменённые документы не попадают в поиск, сервис индексации получает ошибки и копит очередь
Что делать: освободить диск (ES-03), затем снять блокировку: PUT /<индекс>/_settings {"index.blocks.read_only_allow_delete": null}; после этого проверить очередь индексации в RabbitMQ (MQ-08)
rx-documents: read_only

Хосты

Источник: скрыто · 3 с
OS-01Свободное местонорма
в норме на всех опрошенных хостах
сервер RX /: занято 53 %, свободно 91.9 ГБ
сервер RX /var/lib/docker: занято 12 %, свободно 128.7 ГБ
OS-02Память и свопнорма
в норме на всех опрошенных хостах
сервер RX: доступно 46 % из 17.6 ГБ, своп занят 0.0 ГБ
сервер RX: больше всех памяти занимают java 1.0 ГБ (процессов 1), dotnet 2.3 ГБ (процессов 9), beam.smp 167.3 МБ (процессов 1), postgres 106.9 МБ (процессов 9)
OS-03Нагрузканорма
в норме на всех опрошенных хостах
сервер RX: load 3.35 / 3.95 (1 и 15 мин) на 6 ядер
OS-04Время и NTPнорма
в норме на всех опрошенных хостах
сервер RX: Timezone=Europe/Moscow | LocalRTC=no
OS-05Перезагрузка и uptimeвнимание
сервер RX: установлены обновления, требуется перезагрузка
Чем грозит: обновления ядра и библиотек не действуют, пока узел не перезагружен
Что делать: перезагрузка в ближайшее окно обслуживания
сервер RX: Debian GNU/Linux 12 (bookworm), uptime 194 дн, ждёт перезагрузки
OS-06Контейнерыпроблема
сервер RX: rx-worker: убит по памяти (OOMKilled), сейчас running, перезапусков 34
Чем грозит: контейнер, который падает или перезапускается, это неработающая часть системы: брокер, СУБД, поиск или сервис RX
Что делать: docker logs --tail 200 <контейнер> покажет причину; при OOMKilled поднять лимит памяти или искать утечку (OS-07)
сервер RX: rx-worker: убит по памяти (OOMKilled), сейчас running, перезапусков 34
сервер RX: контейнеров 5, работает 5
OS-07Память контейнероввнимание
сервер RX: rx-webserver 89 % лимита
Чем грозит: контейнер у лимита будет убит по памяти (OOMKilled) и перезапущен; без лимита он задушит соседей на том же хосте, обычно СУБД
Что делать: сохранить отчёт и сравнить через сутки (rxdoctor diff): если память только растёт при той же нагрузке, это утечка; иначе поднять лимит или память узла
сервер RX: rx-elasticsearch занято 999.3 МБ, 67 % от лимита 1.5 ГБ, работает 12 мин
сервер RX: rx-rabbitmq занято 137.6 МБ, 34 % от лимита 400.0 МБ, работает 12 мин
сервер RX: rx-webserver занято 88.5 МБ, 89 % от лимита 100.0 МБ, работает 12 мин
сервер RX: rx-postgres занято 43.6 МБ, 4 % от лимита 1.0 ГБ, работает 12 мин
сервер RX: rx-worker занято 496.0 КБ, 1 % от лимита 48.0 МБ, работает 7 с
сервер RX: контейнеров без лимита памяти 0

Ответы администратора

Источник: скрыто
Q-01Резервные копиинорма
снапшоты виртуальной машины раз в сутки
Что делать: оценка по ключевым словам; при разборе отчёта перепроверьте ответ
Q-02Проверка восстановленияпроблема
никогда
Чем грозит: копия, которую ни разу не разворачивали, копией не считается
Что делать: раз в квартал восстановить на отдельный стенд и записать время и результат
Q-03Владелец контуравнимание
один системный администратор
Чем грозит: при аварии некому принять решение, у одного человека нет замены
Что делать: назначить владельца и заместителя, записать в регламент
Q-04Уведомления мониторинганорма
мониторинга нет
Что делать: оценка по ключевым словам; при разборе отчёта перепроверьте ответ
Q-05Тестовый контур и обновленияпроблема
тестового контура нет, обновляем сразу продуктив
Чем грозит: обновление без теста это билет в один конец
Что делать: тестовый контур, репетиция обновления на нём, план отката