Как организовать простой и эффективный мониторинг без КИП, без ТЖ, без СМС и регистрации, только на 1С

Меня зовут Крапивин Евгений. Я – сертифицированный эксперт по технологическим вопросам и технический архитектор компании Factory5.

Для нас, 1С-разработчиков, сервер-приложение – это центральное звено, фокус всего нашего внимания. Если провести аналогию, то он как дилер в покере. Вы делаете запрос – он возвращает ответ. А особо удачливые получают огромный «выигрыш». При этом он «в уме» просчитывает все комбинации и анализирует ситуацию. Чтобы понять, как он это делает и «заглянуть в его мозги», мы можем воспользоваться несколькими методами.

Роль сервера-приложения и встроенные средства мониторинга

Сервер-приложение – центр всей архитектуры. На схемах он всегда изображается в центре, выступая в роли маршрутизатора между клиентом и СУБД. Через него проходят все запросы и потоки данных.

Внутри у него есть полноценная подсистема мониторинга производительности, которая позволяет получать различные метрики. Например, через консоль администрирования можно посмотреть сеансы, ресурсы, затраченные каждым из них, и другую информацию.

Однако, на мой взгляд, у этой системы есть два существенных недостатка. Во-первых, отсутствует хранение исторических данных. Да, кое-что накапливается, но это в основном счетчики производительности ресурсов, доступные только «счастливым обладателям» КОРП-платформ. Большинству пользователей они недоступны, да и использовать их в повседневной работе довольно сложно.

Во-вторых, в системе отсутствует нормальная, удобная система триггеров и уведомлений. В технологический журнал (ТЖ) записываются события, включая события ATTN, но никаких сообщений администратору, SMS или оповещений – ничего подобного не приходит.

Что же делать, чтобы извлечь эти данные и аккуратно разложить их «по полочкам»?

RAS – сервер администрирования 1С

Компания 1С разработала специальный сервер администрирования – RAS. Начиная с версии платформы 8.3.14 для работы с ним был добавлен отдельный объект языка программирования. Это означает, что вы можете писать код прямо в 1С на привычном языке, обращаться к кластеру и получать всю необходимую информацию.

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

В синей зоне – пример взаимодействия, когда на одном хосте развернуто несколько кластеров. В этом случае для каждого кластера требуется отдельный сервер администрирования, поскольку он должен совпадать с версией кластера. Однако приложение, написанное на 1С, может работать с любой версией платформы – оно будет корректно обращаться к RAS и получать нужные данные.

Какие способы взаимодействия с RAS существуют?

• RAC – консольная утилита, предназначенная в первую очередь для администраторов. Требует ручного ввода команд, получения данных по запросу. Работает медленно – значительно медленнее, чем использование объектной модели 1С.

• Java API – вариант для технических энтузиастов. Кто хочет, может попробовать.

Типы собираемых метрик

Метрики, которые можно получать через RAS, условно можно разделить на две большие группы:

1. Справочные данные – настройки кластера, информация об информационных базах, списки хостов и другие статические сведения.

2. Метрики производительности – данные по сеансам, рабочим процессам, загрузке ресурсов и т.д.

Если вы интересуетесь объектной моделью, обязательно загляните в Синтакс-помощник. Там информация изложена очень подробно – даже лучше, чем на ИТС.

Практическое применение мониторинга: память и рабочие процессы

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

Что можно сделать:

• Настроить одну информационную базу на отдельный рабочий процесс.

• Если выявленная база сильно «бьет» по памяти (создает высокие пики), ее можно детально проанализировать.

Правда, такая настройка доступна только пользователям корпоративной лицензии. Пользователи ПРОФ могут просто вынести проблемную базу на отдельный кластер – даже на тот же хост. Лицензия для этого не требуется, все будет работать стабильно, и база будет изолирована.

Анализируя топ сеансов, можно определить, какие из них потребляют больше всего памяти. Важный момент: когда в консоли администрирования вы видите, что какой-то сеанс сильно нагружает процессор, возникает вопрос – что он делает?

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

• Если это обычный пользовательский сеанс, можно заранее настроить ТЖ на сбор событий ADMIN и EXCP, а затем прервать текущий вызов. В технологическом журнале появятся события ADMIN, а вслед за ними – ошибки с контекстом выполнения и даже текстом текущего SQL-запроса. Таким образом вы получите точное представление о том, что происходило на сервере в конкретный момент.

Ошибки в использовании памяти: результат запроса и циклические ссылки

Хочу остановиться на одном часто недооцениваемом объекте – результате запроса. Многие считают его «бесплатным», но это далеко не так.

Если вы выполните запрос вроде «ВЫБРАТЬ * ИЗ РегистраНакопления.Себестоимость» в крупной ERP-системе, он мгновенно начнет активно потреблять оперативную память на сервере приложения – порой на гигабайты. А если результат этого запроса выгрузить в таблицу значений, ситуация усугубится: рядом с результатом запроса на сервере создастся еще одна такая же по объему занимаемой оперативной памяти сущность. В итоге память будет загружена в два раза сильнее.

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

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

Также с помощью объектной модели языка мы можем сразу получать выборку данных. Этот метод не возвращает объект «Результат запроса» – он сразу извлекает и предоставляет данные. Его минус: нельзя сразу определить количество элементов в выборке (так как это не таблица значений и не результат запроса). Зато маленькими порциями нативно платформа получает данные из СУБД и отображает их.

Другие причины потери оперативной памяти:

Циклические ссылки. Их необходимо разрывать следующим образом:

Данные = Новый Структура;

Данные.Вставить("Ключ", Данные); ? Данные.Ключ = Неопределено;

Вычитывание больших текстовых файлов. Использование объекта ТекстовыйДокумент для больших объемов данных неэффективно. Лучше применять потоковые объекты, которые читают данные последовательно (например, ЧтениеДанных):

ТекстовыйДокумент / ДокументDOM / ДокументHTML ? ЧтениеXML / ЗаписьXML / ЧтениеТекста / ЗаписьТекста

Неправильное использование кэша (повторяющееся использование). С информацией о правильном использовании кэша рекомендую ознакомиться по ссылке https://its.1c.ru/db/v8std#content:724:hdoc.

Комбинированные показатели и блокировки

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

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

Также можно обнаружить неэффективное использование лицензий и выявлять «зомби-сеансы».

Особенности метрик в кластере

Фоновые задания (COM-соединения, HTTP- и WC-Соединения) – по сути, это один крупный серверный вызов. У такого вызова доступны только текущие показатели – то есть данные о том, что выполняется прямо сейчас.

При этом накопленная статистика (суммарное время, количество вызовов и т.п.) для таких операций не ведется. Поэтому для объективной картины важно одновременно учитывать два показателя:

• накопленные данные (за период),

• текущий активный вызов.

Только их совокупность дает полное представление о нагрузке.

Важно не путать:

• Объем данных – это объем передаваемых данных между клиентом и сервером приложения,

• Данные СУБД – объем обмена между сервером приложения и базой данных.

Если вы видите рост объема данных между клиентом и сервером, особенно при передаче больших объемов в обе стороны, это может означать, что крупные контексты или данные «ездят» туда-сюда. Такое поведение стоит проанализировать и оптимизировать.

Дополнительные нюансы:

• Загрузка процессора указывается в секундах с точностью до миллисекунд (три знака после запятой).

• Сеансы нужно идентифицировать по уникальному внутреннему идентификатору, а не по номеру сеанса, поскольку номера переиспользуются.

Также можно мониторить метрики рабочих процессов:

• фиксировать время запуска,

• учитывать интервал перезапуска,

• прогнозировать время следующей перезагрузки.

Начиная с платформы 8.3.27 появится возможность задавать точное время перезапуска рабочих процессов.

Еще один важный параметр – PID (Process ID) рабочего процесса. Он отображается в диспетчере задач, записывается в логи, дампы и используется в технологическом журнале. Это позволяет однозначно сопоставить процесс на сервере (например, rphost.exe) с конкретным рабочим процессом в кластере.

Главный показатель для мониторинга – объем потребляемой оперативной памяти процессом. Его также можно отслеживать в режиме реального времени.

Анализ производительности рабочих процессов

Эти показатели измеряют производительность рабочих процессов в кластере.

Реакция сервера формируется из метрик, выделенных зеленым цветом. По сути, это среднее время выполнения вызовов, рассчитываемое за 10-минутный интервал – в момент завершения каждого серверного вызова.

Так называемые события ТЖ CALL – это завершенные вызовы, время выполнения которых фиксируется и экстраполируется на 10 минут. Это позволяет постфактум, с небольшой задержкой, понять, где именно тратилось время:

• на выполнение кода на сервере,

• на запросы к СУБД,

• менеджером блокировок (он же Rmngr.exe).

Особое внимание стоит уделить показателю «Доступная производительность», который для многих остается «черным ящиком». Что он означает и как рассчитывается?

В документации указано, что это 10?000, поделенные на среднее время эталонных операций за 5 минут. На практике это почти верно. Платформа действительно выполняет набор эталонных операций, замеряет их время и записывает данные в технологический журнал с типом события performance update. Внутри этого события можно увидеть детали: какие операции выполнялись и сколько времени они заняли.

24:08.491033-0,CLSTR,

Event=Performance update,

Data='process=tcp://SRV1:1586,

pid=22804,

sql=0,

cpu=15,

queue_length=0,

queue_length/cpu_num=0,

memory_performance=28,

disk_performance=12,

response_time=55,

average_response_time=58.24'

В строке выше приведены:

• SQL – время запросов к базе данных. Значение может быть 0, и эти операции не учитываются в итоговой сумме.

• CPU – загрузка процессора (в процентах).

• Очередь к процессору – критически важный показатель. Он не складывается, а умножается на коэффициент (в среднем около 3-х, но зависит от системы). Даже небольшое значение очереди (например, 5) может значительно ухудшить общую производительность.

• Использование памяти – операции выделения и освобождения массивов.

• Использование диска – создание и удаление временных файлов.

Суммируя время, затраченное на CPU, память, дисковые операции и очереди к диску, получаем среднее время одной эталонной операции за 5 минут.

Затем применяется формула: 10?000 / среднее время. Результат и есть значение «Доступная производительность». В нашем случае он равен 303.

Паттерн построения систем мониторинга

Такую систему мониторинга можно реализовать на любом приложении 1С по следующей логике:

• создать регламентное задание;

• организовать опрос серверов;

• использовать главный управляющий поток, который порождает дочерние потоки;

• каждый дочерний поток опрашивает один сервер или кластер;

• все данные собираются в единую базу, агрегируются;

• при достижении каких-то триггеров отправляются сообщения администраторам.

Ключевое требование – система должна быть самообслуживаемой и не создавать дополнительной нагрузки. Для этого:

• Удаляйте старые метрики, собранные более 6 месяцев назад – они редко нужны.

• «Пережимайте» данные: если собираете метрики каждую минуту, то для старых периодов (например, месячной давности) сохраняйте только средние или экстремальные значения (максимум, минимум, среднее).

• Вместо хранения минутных данных за месяц оставьте, например, часовые средние значения.

Также обязательно реализуйте самодиагностику:

• Проверяйте, не зависли ли фоновые задания.

• Контролируйте потребление памяти самим приложением мониторинга.

Не забывайте настраивать триггеры и уведомления. Без них система мониторинга теряет смысл.

Дополнительные источники метрик

Помимо данных, получаемых из кластера через RAS, мы можем собирать и другие полезные метрики – все, что можно передать в наше централизованное приложение мониторинга. «Сложить в шару» можно все, что угодно.

К таким источникам относятся:

• Данные Performance Monitor (счетчики Windows) по загрузке оборудования – их можно сохранять в файлы и затем парсить, чтобы анализировать нагрузку на оборудование.

• Количество дампов платформы – критически важный индикатор стабильности.

• Автоматический экспорт данных из системы оценки производительности (БСП). В платформе есть встроенная функция, которая позволяет настроить регулярный экспорт результатов в указанную папку. Вы задаете интервал – и система сама будет туда выгружать данные.

• Журналы регистрации (режим eventlog утилиты ibcmd – 8.3.25).

Также полезно:

• Регулярно опрашивать веб-серверы – проверять, доступны ли веб-публикации.

• Следить, чтобы не менялись параметры компьютера.

• Следить за состоянием лицензий.

Также рекомендую настраивать внешний сервис мониторинга. Потому что если система упадет, она уже не сможет сама себя оповестить.

Сопутствующая польза от системы мониторинга

Внедрение такой системы дает не только оперативный контроль, но и значительную дополнительную пользу. Во-первых, появляется единая точка сбора информации – по всем информационным базам, кластерам, серверам и их состоянию. Это становится настоящей кладезью данных для построения удобной и понятной каталогизации всей IT-инфраструктуры.

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

• Аналитикам разрешить только завершать сеансы,

• Программистам – дополнительно блокировать соединения для обновления конфигурации.

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

И, как говорится, «вишенка на торте» – сбор карт интеграций. Когда внешняя система обращается к базе 1С, она должна делать это под отдельным пользователем, имя которого соответствует имени этой внешней информационной системы.

Такой подход позволяет:

• Четко видеть, какая система с какой базой взаимодействует,

• Определять тип соединения (например, HTTP) – это сразу указывает на интеграцию, а не на работу пользователя.

Собрав все эти интеграции, мы сможем понять, какие вообще карты взаимодействия есть между информационными системами. И если нам нужно смигрировать какую-то базу на другой сервер, то посмотрев эту карту, мы поймем, какие обмены мы могли не учесть, и поправим это.

Развитие платформы: нововведения в версиях 25 и 27

В версии 8.3.25 появилось сразу несколько важных и полезных функций.

Одна из самых заметных – шлюз монитора производительности. Он позволяет получать метрики в формате OpenMetrics – вы просто отправляете HTTP-запрос и в ответ получаете структурированные данные о состоянии системы.

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

Эти метрики можно легко интегрировать в Prometheus, а потом с помощью Grafana выдавать красивые графики. Однако есть ложка дегтя в бочке меда: эта функция доступна только пользователям корпоративных лицензий. Поэтому наше сообщество Open Source в лице Артема Лазаренко разработало прекрасную утилиту, которая позволяет собирать те же самые метрики в формате OpenMetrics даже на обычных лицензиях – https://github.com/LazarenkoA/prometheus_1C_exporter.

Также в 25-й платформе у утилиты ibcmd появился режим eventlog. Он позволяет не взаимодействуя напрямую с информационной базой и, не аутентифицируясь в ней, брать журналы регистрации и складывать туда, куда укажете. Благодаря этому можно агрегировать журналы регистрации со всех серверов в специализированную систему (например, в OpenSearch) и получать аналитику по журналам регистрации со всех серверов. Подробная инструкция по настройке есть по ссылке https://its.1c.ru/db/metod8dev#content:6019:hdoc:techlog_data.

Новые свойства объекта администрирования в версии 25

В 25-й платформе у объекта администрирования «АдминистрированиеСеанс» появились новые свойства. Одно из них – ДлительностьТекущегоВызоваСУБД. Раньше в консоли администрирования оно отображалось как «Захвачено СУБД».

Важно не путать его с ДлительностьВызововСУБДТекущее, длительностью текущего запроса. ДлительностьТекущегоВызоваСУБД – это все наше текущее взаимодействие с сервером СУБД, а не только время выполнения запроса.

Зеленая область на графике – это момент создания одного менеджера временных таблиц, и в этом менеджере одновременно переиспользуют два запроса. Желтые участки – два запроса, каждый из которых выполняется по-разному. Желтая область – это ДлительностьВызоваСУБДТекущее, а зеленая – ДлительностьТекущегоВызоваСУБД.

Еще один полезный параметр – ВремяПоследнегоВызоваСУБД. Это дата и время текущего соединения с СУБД. По умолчанию, если соединение с СУБД не установлено, значение параметра равно нулю. Если происходит вызов из СУБД, в этом поле фиксируется дата и время начала соединения.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.