«1С не открывается уже полчаса», — сообщает пользователь. На панели мониторинга всё зелёное: CPU не перегружен, память не закончилась, диски отвечают. Но эти графики говорят только о Windows Server. Работу самой 1С они не подтверждают.
Сначала проверьте прикладной HTTP-эндпоинт 1С. Если ответа нет, переходите к rphost, rmngr и ragent, затем — к СУБД. Такой маршрут быстро отделяет сбой платформы от проблем публикации, базы данных и хоста.
В первые минуты нужно найти участок, на котором оборвалась цепочка:
пользователь → HTTP-публикация → сервер 1С → СУБД → инфраструктура
CPU и свободное место относятся лишь к последнему участку. Windows Server продолжит отдавать метрики, даже если рабочий процесс 1С уже упал.
Начните с пользовательского маршрута
Проверка должна повторять путь пользователя хотя бы до входа в приложение. Для опубликованной базы отправьте HTTP-запрос через blackbox_exporter.
windows_exporter и node_exporter собирают показатели хоста. blackbox_exporter обращается к адресу приложения и проверяет ответ. Именно так разделены проверки в опубликованной конфигурации мониторинга Fast1C для Prometheus и Grafana.
| Что показывает мониторинг | Чего это не доказывает | Что проверить следом |
|---|---|---|
| CPU загружен умеренно | Операция 1С не ждёт диск или блокировку в СУБД | HTTP-эндпоинт, ожидания СУБД, задержки ввода-вывода |
| В памяти остался свободный объём | rphost жив и принимает новые сеансы | Состояние rphost, rmngr, ragent |
| СУБД заняла много RAM | Серверу не хватает памяти | Вытеснение кэша, обращения к диску, задержки операций |
| Диск отвечает, свободное место есть | Пользовательская операция проходит без ожидания | Задержки чтения и записи во время сбоя |
| Windows доступен по сети | Опубликованная база открывается | URL публикации и ожидаемый ответ |
| Prometheus получает метрики | Среди целей настроена проверка приложения | Список целей и модуль blackbox_exporter |
Вывод: первой должна срабатывать проверка пользовательского маршрута. Ресурсные графики понадобятся позже, когда вы начнёте искать причину.
Методика диагностики 1С от EFSOL предостерегает от двух ложных выводов. Умеренная загрузка CPU не исключает долгое ожидание диска. Высокая занятость RAM тоже не доказывает дефицит: MS SQL Server и PostgreSQL держат в памяти кэш.
Ищите сочетание признаков. Если одновременно растут ожидания СУБД, обращения к диску и длительность операции, гипотеза получает основание. Один график памяти ничего такого не доказывает.
Внутри виртуальной машины гостевая ОС показывает лишь часть картины. Отдельный маршрут проверки виртуального хоста поможет сопоставить показатели ВМ с нагрузкой физического узла.
При молчащем эндпоинте проверьте процессы кластера
Если URL не отвечает, не перезапускайте все службы подряд. Запишите точное время сбоя и проверьте, какие процессы остались в системе.
У каждого процесса свой участок работы:
rphostпринимает клиентские подключения и исполняет логику информационной базы;rmngrраспределяет соединения и управляет сеансами;ragentрегистрирует кластер и управляет жизненным циклом рабочих процессов.
Роли процессов описаны в техническом материале Infostart о сборе дампов сервера 1С. Автор также разделяет способы фиксации падений: для rphost применяют logcfg.xml, а сбои rmngr и ragent фиксируют через Windows Error Reporting.
| Наблюдаемый признак | Участок проверки | Что сохранить для разбора |
|---|---|---|
Нет одного rphost, остальные процессы живы | Рабочий процесс конкретной базы или группы сеансов | Дамп rphost, события Windows, техжурнал |
rphost перезапускается несколько раз | Лимиты памяти, внешние компоненты, драйвер подключения | Полный дамп каждого отличающегося сбоя |
Нет rmngr | Маршрутизация соединений и управление сеансами | Отчёт Windows Error Reporting |
Нет ragent | Агент кластера и запуск рабочих процессов | Отчёт Windows Error Reporting |
| Все три процесса живы, URL не отвечает | HTTP-публикация, веб-сервер, доступ к СУБД | Журналы веб-сервера, события СУБД, техжурнал |
| URL отвечает, отдельная операция зависает | Серверный вызов, запрос, блокировка или фоновое задание | Время операции и данные всех слоёв за один интервал |
Вывод: состояние процессов сужает поиск, но не заменяет прикладную проверку. Живой rphost может ждать ответа СУБД или обслуживать другую базу.
Не пытайтесь расшифровать код завершения процесса по случайной таблице из интернета. Среди материалов к этой статье нет документа 1С со значениями кодов для нужной версии платформы. Дамп и запись Windows дадут для диагностики больше, чем неподтверждённая расшифровка.
Если неясно, упал клиент или серверный процесс, пройдите порядок разделения клиентского и серверного сбоя. Он убережёт от поисков проблемы в rphost, когда закрылось только приложение пользователя.
Сведите наблюдения к одной временной шкале
Prometheus забирает только настроенные метрики. Его pull-модель сама не обнаружит отказ приложения. Если среди целей указан лишь экспортер Windows, мониторинг продолжит опрашивать живой хост после падения 1С.
Во время сбоя запишите семь полей:
- точное время начала и окончания;
- имя информационной базы;
- пользователя, роль или подразделение;
- операцию, которую выполнял пользователь;
- длительность операции или зависания;
- повторяемость симптома;
- изменения перед сбоем: релиз, драйвер, настройки кластера или инфраструктура.
Такой набор приводит EFSOL в методике послойной диагностики 1С. Без общего интервала администратор смотрит спокойный CPU за час, DBA находит блокировку за пять минут, а команда 1С открывает событие техжурнала из другого периода. Все видят настоящие данные, но относятся они к разным эпизодам.
Техжурнал связывает действие пользователя с серверными вызовами и запросами. Сопоставляйте его с ожиданиями СУБД, дисковыми задержками и состоянием процессов за тот же интервал. Подробный порядок описан в материале про связку техжурнала, APDEX и серверных метрик.
При зависании ищите не самый высокий график, а совпадение по времени. Долгое проведение документа может упереться в запрос, блокировку, длинную транзакцию, диск или фоновое задание. Привязка к одной базе и одной операции быстро отсекает лишние гипотезы.
Добавьте два уровня HTTP-проверки
Первый HTTP-запрос отвечает на простой вопрос: доступна ли публикация. Второй проверяет, вернуло ли приложение ожидаемый ответ.
В опубликованной конфигурации Fast1C настроены два модуля blackbox_exporter:
http_1c_aliveждёт ответ до 10 секунд и принимает все коды, кроме 5xx;http_1c_strictждёт код 200 и заданную строку в теле ответа.
Это параметры одной конкретной настройки, а не готовый стандарт для любой базы. Например, код 405 может быть штатным ответом на неподходящий HTTP-метод. Поэтому строгую проверку привязывают к своему служебному эндпоинту с предсказуемым результатом.
Не ищите строку на странице входа: после обновления платформы она может измениться. Подготовьте короткий служебный ответ, который не зависит от оформления интерфейса. HTTP-сервис должен выполнять дешёвую операцию и не менять данные базы.
| Проверка | Что она подтверждает | Интервал в конфигурации Fast1C | Условие сигнала |
|---|---|---|---|
http_1c_alive | Веб-узел получил ответ, публикация не вернула 5xx | 15 секунд | probe_success == 0 в течение 2 минут |
http_1c_strict | Эндпоинт вернул код 200 и ожидаемую строку | 15 секунд | Нет ожидаемого ответа в течение 2 минут |
| Время HTTP-ответа | Сервис отвечает без долгой задержки | 60 секунд | probe_duration_seconds > 5 в течение 5 минут |
| Проверка процессов | rphost, rmngr и ragent присутствуют | По принятому интервалу мониторинга служб | Процесс исчез или перезапустился |
| Метрики хоста | Windows, CPU, RAM и диски доступны для анализа | По принятому интервалу инфраструктуры | Порог зависит от ресурса и рабочей нагрузки |
Вывод: первый сигнал сообщает о недоступности, второй — о неверном ответе, третий — о замедлении. Одно уведомление для трёх событий только затруднит диагностику.
В описанном Fast1C внедрении опрос раз в 15 секунд и выдержка сигнала две минуты сократили среднее время реакции с 30–40 до 2–3 минут. Это результат настройки в одной компании. Переносить его на другой контур без проверки нельзя.
Выдержка отсекает одиночные сетевые сбои. Уведомление придёт не раньше чем через две минуты устойчивой ошибки. Если бизнесу нужна более быстрая реакция, сократите выдержку и посчитайте ложные срабатывания в своей сети.
Время ответа и доступность проверяйте раздельно. Пять секунд — порог из опубликованного примера Fast1C. Для своей базы выберите границу, после которой пользователь уже не может работать, и подтвердите её историей наблюдений.
Сохраняйте дамп повторно падающего rphost
После автоматического перезапуска процесс исчезает, а вместе с ним — материал для диагностики. Если rphost падает снова, заранее включите создание дампа и проверьте свободное место.
В инструкции Infostart файл конфигурации расположен здесь:
C:\Program Files\1cv8\conf\logcfg.xmlПо умолчанию дампы отключены:
<dump create="false" type="0" prntscrn="false"/>Значение type="3" создаёт полный дамп памяти вместе с heap. Один файл может занять 2,5–3 ГБ. Автор инструкции получил такие размеры на платформе 1С 8.3.27 под Windows Server 2016. На вашем сервере размер может отличаться, поэтому место нужно проверить заранее.
Не включайте полные дампы без ограничения хранения. Три падения с файлами по 3 ГБ займут около 9 ГБ:
3 × 3 ГБ = 9 ГБ
Это расчёт по верхней границе из инструкции Infostart. Если падают несколько процессов, умножьте лимит на их количество.
Другой вариант — Microsoft Sysinternals ProcDump. Ключ -ma сохраняет все области памяти процесса. Команду и условие захвата выбирайте по документации Microsoft Sysinternals с учётом версии Windows и сценария падения.
Не ставьте диагноз «не хватает памяти» по одному WorkingSet. Эта метрика включает общие страницы, подключённые к адресному пространству процесса. PrivateUsage учитывает память, которая принадлежит только этому процессу.
Для диагноза разница принципиальна. Большой WorkingSet при умеренном PrivateUsage ещё не говорит об утечке внутри rphost. Сопоставьте рост частной памяти со временем, числом сеансов, выполняемыми операциями и перезапусками.
Память могут уводить внешние компоненты. В материале Infostart среди возможных причин названы зарегистрированные в Windows компоненты IFilter и подключения через устаревший sqlncli11.dll. Для SQL Server автор советует заменить его на Microsoft OLE DB Driver for SQL Server — MSOLEDBSQL.
Название библиотеки само по себе ничего не доказывает. Сначала подтвердите, что процесс загрузил компонент. Затем проверьте, совпадают ли его работа, рост памяти и падение rphost.
Маршрут следующей проверки
Считайте продакшн доступным только после успешной прикладной проверки. Зелёные графики CPU, RAM и дисков подтверждают работу хоста. Они ничего не говорят о прохождении операции через 1С и СУБД.
При следующем отказе идите по этому порядку:
- Проверьте HTTP-эндпоинт 1С с машины мониторинга.
- Зафиксируйте время, базу, пользователя и операцию.
- Проверьте
rphost,rmngrиragent. - Сопоставьте техжурнал, события СУБД и метрики ОС за один интервал.
- Сохраните дамп повторно падающего процесса.
Если эндпоинт недоступен, а процессы живы, переходите к веб-публикации и соединению с СУБД. Если процесс исчез, нужны дамп и Windows Error Reporting. Когда сервис отвечает, но отдельная операция висит, ищите её след в техжурнале, ожиданиях СУБД и фоновых заданиях.
Иногда сбой возникает только при конкретном сочетании версии платформы, драйвера, публикации и настроек кластера. Тогда общего чек-листа уже не хватает. Нужен разбор конкретного серверного контура по данным одного инцидента: времени, дампу, техжурналу и событиям СУБД.