Мониторинг сеансов и действий пользователей в 1С 8.3

Самый быстрый способ увидеть, кто сейчас в базе, — открыть список активных пользователей. В режиме «1С:Предприятие» это Главное меню → Все функции → Стандартные → Активные пользователи, в конфигураторе — Администрирование → Активные пользователи. Там видно имя, компьютер, время начала сеанса и приложение (толстый клиент, тонкий, веб).

Этого хватает, чтобы понять текущую картину. Но «активность» бывает разной: кто-то держит открытую форму, кто-то повесил базу долгой обработкой, а кто-то две недели назад натворил в документе — и это надо найти задним числом. Разберём все инструменты платформы: от простого списка сеансов до технологического журнала и утилиты rac.

Чтобы не путаться, какой инструмент под какую задачу, держите в голове короткую карту:

Кто сейчас работает: список активных сеансов

Список активных пользователей — это снимок на текущий момент. В клиент-серверной базе он показывает все сеансы кластера, в файловой — всех, кто подключён к каталогу базы.

Чтобы попасть в список в режиме предприятия:

1. Нажмите кнопку главного меню (значок в левом верхнем углу интерфейса «Такси»).
2. Выберите Все функции. Если пункта нет — включите его: Сервис и настройки → Настройки → Параметры → Отображать команду «Все функции».
3. Откройте Стандартные → Активные пользователи.

В списке по каждому сеансу видно:

• 👤 Пользователь — имя из справочника пользователей ИБ.
• 💻 Компьютер — сетевое имя рабочей станции.
• 🕐 Начало работы — когда пользователь зашёл в базу.
• 🖥️ Приложение — тонкий клиент, толстый, веб-клиент или фоновое задание.

Завершить чужой сеанс из режима предприятия нельзя — только посмотреть. Принудительно отключить пользователя получится либо из конфигуратора (Администрирование → Активные пользователи → Завершить сеанс), либо из консоли кластера, либо через rac. Об этом ниже.

Что делал пользователь: журнал регистрации

Список сеансов отвечает на вопрос «кто сейчас». Журнал регистрации отвечает на вопрос «кто и что делал» — это история всех значимых событий базы.

Открыть журнал:

• в режиме предприятия — Все функции → Стандартные → Журнал регистрации;
• в конфигураторе — Администрирование → Журнал регистрации.

Журнал пишет события: вход и выход из системы, проведение и изменение документов, запись элементов справочников, ошибки, запуск фоновых заданий, изменение прав. У каждой записи — дата, пользователь, компьютер, сеанс, метаданные (какой объект затронут) и представление данных.

Как найти нужное событие

Записей в активной базе — десятки тысяч в день, поэтому главное в журнале — отбор. Нажмите Настроить отбор (кнопка в командной панели) и ограничьте выборку:

• по пользователю — чтобы увидеть всё, что делал конкретный сотрудник;
• по периоду — например, последние сутки или конкретный день;
• по важности — Ошибка, Предупреждение, Информация;
• по метаданным — например, только документы «Реализация товаров и услуг»;
• по данным — конкретный документ или элемент справочника.

Несколько приёмов, которые ускоряют разбор:

• Вход в нерабочее время. Отбор по событию входа в систему плюс отбор по времени за пределами рабочего дня — так ловят подключения ночью и по выходным.
• Чужой компьютер. Если одно имя пользователя входит с нескольких компьютеров, в колонке «Компьютер» это сразу видно — повод проверить, не передал ли сотрудник пароль.
• Серия ошибок. Отбор по важности Ошибка за последний час показывает, у кого и на каком действии сыплются сбои, — часто это один и тот же регламент или обмен.
• Удаление данных . Событие удаления объекта фиксируется с указанием пользователя — так находят, кто пометил на удаление или удалил элемент.

Где физически лежит журнал

С версии платформы 8.3.5 журнал по умолчанию хранится в формате SQLite — файл 1Cv8.lgd в каталоге базы (или в служебном каталоге кластера для серверной базы). Старый формат — набор файлов .lgf в папке 1Cv8Log.

Размер журнала растёт и может замедлять работу. Период хранения и разделение на файлы настраиваются в конфигураторе: Администрирование → Настройка журнала регистрации. Там же задаётся, какие события вообще регистрировать — отключив незначимые, вы уменьшите объём.

Блокировки и соединения в клиент-серверной базе

Когда «база висит», а один документ не проводится из-за другого пользователя — это блокировки. Посмотреть их можно только в клиент-серверном варианте, через консоль кластера.

Платформа работает с двумя уровнями блокировок:

• Управляемые блокировки 1С — накладываются платформой на уровне объектов (например, при проведении документа). Видны в консоли кластера в разделе блокировок сеанса.
• Блокировки СУБД — накладываются самой базой данных (MS SQL, PostgreSQL) на уровне записей и страниц. Их анализируют уже средствами СУБД или через технологический журнал.

Чтобы понять, кто кого ждёт:

1. Откройте консоль администрирования серверов (см. раздел ниже).
2. Разверните кластер → сеансы.
3. Посмотрите колонку «Захвачено СУБД» и соединение, в контексте которого выполняется запрос.

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

Детальная диагностика: технологический журнал

Когда штатного журнала регистрации мало — например, нужно поймать взаимоблокировку (deadlock), таймаут или долгий запрос к СУБД, — включают технологический журнал (ТЖ). Это низкоуровневый лог платформы.

ТЖ настраивается файлом logcfg.xml, который кладут в каталог conf рядом с исполняемыми файлами платформы (...\1cv8\conf\) либо в каталог, указанный в настройках. Платформа подхватывает изменения файла без перезапуска службы.

Полезные события для анализа активности и блокировок:

• TLOCK и TTIMEOUT — ожидания на управляемых блокировках и таймауты;
• TDEADLOCK — взаимоблокировки (кто кого заблокировал по кругу);
• DBMSSQL / SDBL — тексты запросов к СУБД и их длительность;
• CALL / SCALL — серверные вызовы и их продолжительность;
• EXCP — исключения (ошибки) с текстом.

Простой пример logcfg.xml, который час пишет блокировки и взаимоблокировки в каталог логов:

<?xml version="1.0"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\v8log" history="1">
    <event>
      <eq property="name" value="TLOCK"/>
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <property name="all"/>
  </log>
</config>

Логи ТЖ — это текстовые файлы, разложенные по подкаталогам процессов. Читать их вручную тяжело, поэтому для разбора применяют парсеры и утилиту сбора производительности (например, анализ дампов и логов из состава инструментов обслуживания). Для начала же достаточно поиска по тексту: открыть файл события TDEADLOCK и увидеть пары конфликтующих соединений.

Как читать запись блокировки на практике:

1. В событии TLOCK смотрите свойства Regions (какие ресурсы заблокированы) и WaitConnections (кто кого ждёт).
2. В TDEADLOCK платформа прямо указывает цепочку соединений, которые заблокировали друг друга по кругу.
3. По номеру соединения из ТЖ возвращаетесь в консоль кластера и находите сеанс и пользователя — так замыкается связка «технический лог → живой человек».

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

Консоль администрирования серверов и утилита rac

Централизованно управлять активностью в клиент-серверной базе позволяют два инструмента: графическая консоль и консольная утилита rac.

Графическая консоль (оснастка MMC)

«Администрирование серверов 1С:Предприятия» — это оснастка MMC, которая ставится вместе с сервером. Через неё видно всю иерархию: центральный сервер → кластеры → информационные базы → сеансы, соединения, блокировки, рабочие процессы.

Что полезно смотреть по активности:

• Сеансы — все открытые сеансы всех баз кластера, с временем, пользователем и захваченными ресурсами.
• Соединения — низкоуровневые подключения (один сеанс может держать несколько соединений).
• Блокировки — управляемые блокировки, кто их держит и кто ждёт.

Если оснастка не показывает кластер, частая причина — не запущена служба сервера или не зарегистрирована библиотека администрирования. В этом случае помогает перерегистрация radmin.dll командой regsvr32 из каталога bin платформы (от имени администратора).

Утилита rac (удалённое администрирование)

rac — консольный клиент администрирования. Он работает в связке со службой ras (сервер администрирования) и удобен для скриптов и удалённого мониторинга. Архитектура подключения такая: клиент обращается к агенту сервера (порт 1540), затем к менеджеру кластера (1541) и рабочим процессам; rac ходит через ras.

Базовые команды для просмотра активности:

rac cluster list
rac session list --cluster=<идентификатор кластера>
rac connection list --cluster=<идентификатор кластера>

Сначала rac cluster list возвращает идентификатор кластера (UUID), затем этот идентификатор подставляется в остальные команды. Посмотреть занятые лицензии по сеансам:

rac session list --licenses --cluster=<идентификатор кластера>

Завершить сеанс через rac можно командой завершения сеанса с указанием кластера и идентификатора сеанса (см. rac session help).

Автоматический мониторинг активности

Разовый просмотр хорош для разбора инцидента. Для постоянного контроля активность снимают регулярно и складывают в удобное место.

Варианты автоматизации:

• 📊 Отчёт по журналу регистрации. В языке запросов журнал напрямую не доступен, но его выгружают средствами встроенного языка (методы работы с журналом регистрации) в табличный документ или внешний файл. На основе выгрузки строят отчёт: кто сколько провёл документов, когда были ошибки, кто входил в нерабочее время.
• ⏱️ Регламентное задание. Настраивается в Администрирование → Обслуживание → Регламентные и фоновые задания. По расписанию задание выгружает срез активности и отправляет его ответственному (например, письмом).
• 🖥️ Скрипт на rac. Планировщик ОС по расписанию запускает rac session list и пишет результат в файл или систему мониторинга. Удобно, когда нужен контроль числа сеансов и лицензий без захода в консоль.
• 📈 Внешние системы мониторинга. Метрики числа сеансов, памяти рабочих процессов и очередей собирают системы класса Zabbix через те же rac/ras.

Такой набор закрывает и текущий контроль («кто сейчас в базе»), и ретроспективу («что было вчера»), и разбор тяжёлых инцидентов с блокировками.

Частые вопросы