Как связать задержку в 1С с метриками сервера и СУБД

Бухгалтер сообщает: «1С зависла». На панели мониторинга процессор загружен, но этот график не называет причину. Запрос мог занять ядро, процесс мог ждать диск, а сеанс — свободное соединение с PostgreSQL.

Администратору нужен не ещё один дашборд, а общий маршрут диагностики. Зафиксируйте время жалобы и базу, найдите тот же интервал на сервере, в СУБД и технологическом журнале 1С. Тогда вместо перезапуска служб наугад появится конкретный запрос, блокировка или дефицит ресурса.

Ниже — минимальный контур из трёх слоёв:

• ресурсы узла: процессор, память, диск и очередь задач;
• состояние СУБД: запросы, операции со строками и соединения;
• технические события платформы 1С.

Microsoft в руководстве по мониторингу SQL Server разделяет два режима наблюдения: снимки текущего состояния помогают изолировать проблемный процесс, а непрерывный сбор показывает историю и тенденции. Один график без соседних данных закрывает только половину задачи.

Начните со времени жалобы и имени базы

Запишите время до минуты, имя базы и действие пользователя. Фраза «после обеда всё тормозило» бесполезна: за несколько часов меняются фоновые задания, нагрузка и состав активных сеансов.

В панели Selectel время графика совпадает со временем на устройстве пользователя. Регион размещения кластера на отображение не влияет. Это правило относится именно к панели Selectel; в другом стеке проверьте часовой пояс дашборда, сервера 1С и СУБД самостоятельно.

Конкретный кластер PostgreSQL в экспортированных метриках Selectel определяется по метке ds_id. В технологическом журнале имя информационной базы хранит поле p:processName. Файлы разложены по процессам rphost, ragent, rmngr и по часам.

Материал OTUS о технологическом журнале уточняет: Dur хранит микросекунды, а записи DBMSSQL и DBPOSTGRS содержат SQL-запрос, длительность, число строк, имя базы и контекст вызова. Без общей временной точки эти сведения останутся несвязанными наблюдениями.

Если жалобы приходят через несколько часов, добавьте в заявку обязательные поля: точное время, база, операция и имя пользователя. Такой шаблон даст диагностике больше, чем новый набор графиков.

Первый проход: найдите ресурс, на котором возникло ожидание

Сначала откройте метрики узла за короткий интервал вокруг жалобы. Не начинайте с перезапуска rphost: он удалит текущее состояние, а причина может остаться.

Для PostgreSQL-кластеров Selectel панель показывает занятую память без кэша и буферов ОС, загрузку vCPU, CPU iowait, Load Average и события OOM. Эти показатели отвечают на разные вопросы.

Высокая загрузка vCPU направляет поиск к активным запросам и процессам. Рост CPU iowait означает, что процессор тратит время на ожидание ввода-вывода. Здесь нужно проверять диск и запросы, которые читают или записывают большой объём данных.

Load Average в панели Selectel отображается за одну, пять и пятнадцать минут. Документация сервиса предлагает сопоставлять эти значения с числом ядер ноды: показатель не должен превышать число ядер. Это правило конкретной панели, а не универсальный порог для любого Linux-сервера.

Метрика OOM показывает число процессов, которые система завершила из-за нехватки памяти. Если значение выросло в интервале жалобы, ищите завершённый процесс и причину расхода памяти. Среднее потребление за день такой эпизод скроет.

Порядок первого прохода:

1. Сверьте память с обычным уровнем выбранного узла.
2. Проверьте загрузку vCPU в момент задержки.
3. Сопоставьте её с CPU iowait.
4. Посмотрите Load Average на коротком и длинном интервалах.
5. Проверьте, появились ли события OOM.

Этот порядок не ставит диагноз по одной метрике. Он сокращает область поиска перед переходом к СУБД.

Второй проход: проверьте PostgreSQL и пулер соединений

Если ресурсы узла изменились в момент жалобы, откройте показатели базы и пулера за тот же интервал. Панель Selectel выводит попадания в кэш, операции со строками и состояния клиентских подключений.

Попадание в кэш считается как отношение blks_hit к сумме blks_hit и blks_read. Смотрите не только на сам показатель, но и на его изменение относительно обычного периода этой базы. Универсальный порог без данных о нагрузке даст ложный диагноз.

Метрики tup_fetched, tup_inserted, tup_updated и tup_deleted показывают операции со строками в секунду. Они помогают увидеть, что происходило с базой: чтение, массовое изменение или удаление.

Отдельно проверьте pools_client_waiting_connections. Документация Selectel описывает её как число клиентов, которые уже отправили запрос, но ещё не получили соединение с нодой. Рост этой метрики ведёт к настройкам пулера и числу доступных серверных соединений, а не к диску пользовательского компьютера.

Таблица задаёт переход между слоями: признак на сервере ведёт к проверке СУБД, а запись техжурнала возвращает контекст операции в 1С.

Назначение событий в таблице приведено по материалу OTUS. Это не полный справочник событий платформы: среди использованных материалов нет документа фирмы «1С», который задаёт всю расшифровку. Для настройки новых фильтров сверяйте обозначения с документацией вашей версии платформы.

Технологический журнал возвращает контекст 1С

Метрика СУБД показывает запрос, но не всегда объясняет, какое действие пользователя его вызвало. Технологический журнал связывает SQL с базой, процессом и участком конфигурации.

Записи DBMSSQL и DBPOSTGRS содержат текст запроса и контекст вызова. Поле Context указывает модуль и строку в терминах 1С. События TLOCK, TTIMEOUT и TDEADLOCK относятся к управляемым блокировкам, ожиданиям и взаимным блокировкам. EXCP хранит текст ошибки, стек и контекст, а MEM отражает потребление памяти процессами rphost.

Здесь появляется цепочка, ради которой строился мониторинг:

жалоба → время и база → ресурс узла → состояние СУБД → событие 1С

Если серверные показатели не изменились, не пытайтесь подобрать аппаратную причину. Проверьте блокировки, вызовы между процессами и ошибки платформы. Когда задержка совпала с ростом iowait, двигайтесь в сторону диска и SQL-запросов.

Для оперативной проверки сеансов и рабочих процессов пригодится разбор команд кластера и операций с rphost. Консоль не заменяет историю метрик, но помогает проверить текущее состояние после того, как вы выбрали нужную базу и процесс.

Если нужен переход от активного сеанса к SQL-статистике по query_id, посмотрите сценарий диагностики задержек в PPEM 2.9. Он продолжает тот же маршрут на уровне конкретного запроса.

Собирайте не все события, а нужный срез

Технологический журнал настраивается файлом logcfg.xml. В Windows его обычно размещают по пути:

C:\Program Files\1cv8\conf\logcfg.xml

В Linux материал OTUS указывает путь:

/opt/1cv8/x86_64/current/conf/logcfg.xml

Платформа подхватывает изменения файла в течение минуты без перезапуска сервера. После удаления logcfg.xml сбор прекращается.

Не включайте полный набор событий на неопределённый срок. По данным OTUS, на нагруженном сервере такой журнал способен создавать гигабайты файлов за час. Диск закончится раньше, чем администратор найдёт нужную запись.

Выберите фильтр под наблюдаемый признак:

Узкий фильтр сохраняет данные, по которым можно принять решение, и не превращает журнал в отдельную причину заполнения диска.

В материале OTUS для рабочей среды предложена история за 72 часа с фильтрами по проблемным событиям. Это рекомендация автора материала, а не требование фирмы «1С». Подберите срок под частоту жалоб: если о задержке сообщают на следующий день, журнал должен хранить этот интервал.

Не угадывайте назначение _Fld123

В SQL из технологического журнала встречаются имена вроде _Fld123 и _AccumRg789. По самому имени нельзя определить реквизит или регистр конфигурации.

Таблицу соответствий получают через команду конфигуратора «Конфигурация — Выгрузить описание структуры данных». Материал OTUS также описывает получение данных из таблицы Config. Для типовых конфигураций сообщество публикует готовые сопоставления, но их нужно сверять с вашей версией.

Не заменяйте сопоставление догадкой. Ошибка в одном поле уведёт проверку к другому объекту конфигурации, хотя время события и сам запрос были найдены верно.

Текущей панели недостаточно без истории

Панель Selectel показывает метрики PostgreSQL в реальном времени, но не хранит их историю. Документация сервиса предлагает экспорт полного набора в формате Prometheus. Нужный кластер затем выбирают по ds_id.

Минимальная схема постоянного контроля может выглядеть так:

• node_exporter отдаёт Prometheus показатели Linux-узлов;
• экспортёр СУБД передаёт метрики PostgreSQL;
• Grafana строит панели по общей временной шкале;
• технологический журнал сохраняет выбранные события 1С.

Практический разбор двух стеков мониторинга у John Gorn показывает такую связку в работе: Zabbix собирает процессор, память, диски и сеть; во втором контуре Prometheus опрашивает node_exporter, а Grafana строит панели. Это пример архитектуры, а не обязательный набор программ.

Если вы уже используете готовый продукт, сверьте покрытие с маршрутом от Linux и PostgreSQL к процессам 1С. Название системы здесь вторично. Проверьте, можно ли увидеть один интервал на всех трёх слоях.

Для SQL Server новый сбор не стоит строить на SQL Trace или SQL Server Profiler. Microsoft пометила оба средства устаревшими и рекомендует Extended Events. В SQL Server Management Studio также доступны Query Store и Activity Monitor.

Закройте метрики от внешнего доступа

Экспортёры и панели раскрывают устройство внутренней сети, имена узлов и характер нагрузки. Не публикуйте их служебные интерфейсы вместе с обычным сайтом.

В стенде John Gorn облачный сервер и лаборатория соединены через WireGuard. Агенты и экспортёры слушают только VPN-интерфейс, порты мониторинга не открыты в интернет, а служебные адреса Prometheus закрыты обратным прокси. Внутренние IP исключаются из хранилища правилами relabel.

Возьмите из этого примера принцип, а не готовую конфигурацию: сборщик должен видеть узлы, но внешний посетитель не должен видеть сборщик. Публичной панели отдавайте только выбранные метрики и режим просмотра без административных функций.

Порядок проверки при следующей жалобе

Когда пользователь снова скажет «1С зависла», пройдите пять шагов:

1. Запишите время, базу, пользователя и выполняемую операцию.
2. Проверьте память, vCPU, iowait, Load Average и OOM в том же интервале.
3. Посмотрите попадания в кэш, операции со строками и ожидающие соединения СУБД.
4. Найдите этот интервал в DBMSSQL или DBPOSTGRS, блокировках, EXCP либо MEM.
5. Зафиксируйте причину и оставьте постоянный сбор только для метрик и событий, которые помогли её найти.

График указывает участок задержки. СУБД показывает запрос или внутреннее ожидание. Технологический журнал возвращает базу и контекст 1С. Диагностика начинается, когда все три слоя привязаны к одному времени.