Статья написана на основе моего выступления на IE 2024. Формат выступления подразумевает сжатый тайминг, и основной задачей было заинтересовать возможностями бесплатных open-source инструментов, дать ссылки, показать на примерах: как это может выглядеть, и что мы дорабатывали для себя.
Кому это будет полезно? В первую очередь – тем, кто отвечает за работоспособность баз 1С. Во-вторых – тем, кто планирует организацию контроля за работой информационной системы и тем, кому интересен OpenSource. А тот, у кого уже все настроено и работает, получит несколько идей по улучшению своего мониторинга.
Описание системы: высокая нагрузка и сложная архитектура
Ключевой момент – высокая нагрузка на уровне СУБД. Система обрабатывает большой документооборот, в ней работает более 6 000 пользователей, плюс интеграции и регламентные задания. В пиковые моменты нагрузка превышает сто тысяч запросов в секунду на уровне СУБД. У нас крупная команда разработки – более ста специалистов по 1С. Конечно, не все они пишут именно для этой системы, но релизы выходят каждые две недели, и это всегда новый функционал или переработка существующего.
В итоге мы имеем систему Enterprise-уровня, у которой просто нет права на простой. В таких условиях главное – скорость решения проблем. Просто мониторинга мало: важно не только видеть, что происходит в системе, но и оперативно устранять сбои. Нужны инструменты, которые помогут быстро найти причины проблем, а не просто обозначить факт их наличия.
Минимальный набор инструментов мониторинга
Что нужно иметь «на минималках»? Если у вас сейчас вообще ничего нет, то, как минимум, должна быть налажена работа с технологическим журналом.
Технологический журнал обязателен. Если вы отвечаете за работу системы, эксплуатируете ее или сопровождаете – без него никак. Казалось бы, тема уже избитая, но практика показывает обратное: приходишь на аудит – в лучшем случае журнал просто архивируется и где-то лежит в бэкапах, но в таком виде пользы от него мало.
Часто технологический журнал воспринимают как «страшный» инструмент: много всего, непонятно, что смотреть и как разбираться. Как раз поэтому я хочу показать, какими инструментами можно упростить вход в эту тему.
Дальше в моем личном рейтинге идет нагрузка на оборудование. Это также очень важная информация, и второе место не исключает необходимость ее собирать. Чаще всего админы ее уже как-то собирают, но вам необходимо самим видеть, как загружена инфраструктура, поэтому запрашивайте у них доступ к этим данным. Если ничего не собирается – можно воспользоваться следующим набором инструментов:
Мониторинг Win серверов: ссылка
Сбор метрик от MS SQL: ссылка
Сбор метрик от PostgreSQL: ссылка
Третье – информация от кластера 1С. Она помогает разбираться в сложных ситуациях и при этом аккумулирует полезную статистику. Например, сколько пользователей работает в течение суток, и через какие типы подключений (WSConnection, ComConnection, толстые и тонкие клиенты). Ну и, конечно, потребление лицензий. Минимум, что нужно – контролировать их количество. Это тоже можно получать от кластера.
Статьи и репозитарии по теме
Если используется КОРП платформа версии 8.3.25 или более старшая, то рекомендую использовать получение метрик от кластера по HTTP сервису, подробности на ИТС.
Если это не подходит, то с большой благодарностью к Артему Лазаренко используем готовое решение получения метрик кластера: тут.
ELK-стек: первый шаг в мониторинге
ELK (ElasticSearch, Logstash, Kibana) – это самый популярный стек. И здесь важный момент: если вы хотите попробовать, нужно, чтобы первый опыт оказался удачным. Потому что именно он формирует отношение: «работает – значит, буду использовать». Или, наоборот: «какая-то тягомотина, непонятно, все падает, докеры какие-то – разбираться не хочу». Чтобы этого не произошло, начните с готового, проверенного решения. Разверните его, попробуйте в работе, почувствуйте саму философию open-source. А дальше уже сможете, как кубики, менять компоненты на более подходящие для ваших задач.
В основе стека – ElasticSearch или его «брат-близнец» OpenSearch. Это поисковая система, которая позволяет хранить и сжимать логи технологического журнала, быстро искать по ним, фильтровать, структурировать данные и работать с ними через запросы.
Logstash отвечает за доставку логов с сервера 1С в Elastic. Здесь тоже есть варианты: Logstash, Filebeat, Fluent Bit или Vector. В Logstash есть встроенный скриптовый язык, и с помощью правил обработки текста логи технологического журнала разбираются на отдельные поля и складываются в индексы эластика – и уже с ними можно работать, образно говоря, как с отдельными колонками таблицы. Правила разбора логов называются pipeline.
Данные собрали, обработали и разложили, осталось их как-то увидеть. Для этого используем графический интерфейс Kibana. С ней проще и нагляднее видеть проблемы, закономерности, взаимосвязи событий: что, во сколько началось и к чему привело.
Статьи и репозитарии по теме
-
Статья-инструкция c ссылкой на проект github, pipeline и видеоинструкцией: тут
-
Еще одна интересная статья: тут
-
Классический стек ELK: тут
-
Наш конфиг настройки:
<log location="Disk:\monitoring" history="2">
<event>
<eq property="Name" value="LIC"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="EXCPCNTX"/>
</event>
<event>
<eq property="Name" value="ATTN"/>
</event>
<event>
<eq property="Name" value="PROC"/>
</event>
<event>
<eq property="Name" value="ADMIN"/>
</event>
<event>
<eq property="Name" value="SDGC"/>
</event>
<event>
<eq property="Name" value="TTIMEOUT"/>
</event>
<event>
<eq property="Name" value="TDEADLOCK"/>
</event>
<event>
<eq property="Name" value="CLSTR"/>
<ne property="Event" value="Successful service call"/>
</event>
<event>
<eq property="Name" value="CLSTR"/>
<eq property="t:applicationName" value="AgentStandardCall"/>
</event>
<event>
<eq property="Name" value="QERR"/>
</event>
<event>
<eq property="Name" value="CALL"/>
<ge property="MemoryPeak" value="104857600"/>
</event>
<event>
<eq property="Name" value="CALL"/>
<ge property="Durationus" value="1000000"/>
</event>
<event>
<eq property="Name" value="DBMSSQL"/>
<ge property="Durationus" value="1000000"/>
</event>
<event>
<eq property="Name" value="TLOCK"/>
<ne property="WaitConnections" value=""/>
</event>
<event>
<eq property="Name" value="TLOCK"/>
<eq property="escalating" value="true"/>
</event>
<event>
<eq property="Name" value="SDBL"/>
<eq property="Func" value="setRollbackOnly"/>
</event>
<property name="all"/>
</log>
Альтернативный стек: ClickHouse, Vector, Grafana (CVG)
Идеальной целевой архитектурой можно считать постепенный переход от ElasticSearch к ClickHouse. Чуть ниже я остановлюсь на сравнении Elastic и ClickHouse.
В качестве средства доставки логов оптимально использовать Vector. Его преимущество в том, что он умеет рассчитывать хэш по тексту запроса или, например, по строке контекста.
Зачем нужен хэш? Чтобы группировать запросы. Допустим, у нас есть 2 000 запросов, из которых реально уникальных – только 10. Остальные отличаются лишь именами временных таблиц или количеством параметров (где-то их три, где-то десять). Если удалить эти изменяемые части (например, все имена временных таблиц привести к виду #tt) и по полученному тексту рассчитать хэш, то вы сможете сгруппировать повторяющиеся запросы и сразу показать лидеров по нагрузке – тех, с кем в первую очередь стоит работать.
Для визуализации данных удобнее использовать Grafana. В отличие от Kibana, которая «заточена» в основном под Elastic, Grafana поддерживает множество источников: Prometheus, MS SQL, PostgreSQL, тот же Elastic и многие другие. Есть даже интеграция с Git.
Практические кейсы использования ELK (CVG): как выглядит анализ проблем
Работу с технологическим журналом в связке эластик + кибана/графана можно принципиально сравнить с получением данных из регистра сведений с помощью СКД. Один раз «собрав» СКД под регистр, дальше, без единой строки кода, вы можете получать нужный состав данных с фильтрами, группировками, сортировками по любым полям и при этом еще и выбирать формат отображаемых данных – график, таблица, диаграммы.
Для нижеследующих примеров на рабочий стол Grafana были добавлены два элемента с типом «Time series», один элемент «Table» и две переменных: «group» для выбора поля, используемого в качестве группировки, и «GroupResource» для выбора, какое поле мы будем агрегировать.
В самом простом варианте рабочий стол может выглядеть так:
Далее разберем несколько примеров, показывающих, как может выглядеть работа с бесплатным стеком мониторинга. В примерах используется Grafana (в Kibana интерфейс немного отличается, но аналогичные решения реализуемы).
Количественная оценка ситуации
Устанавливаем поле группировки «event», т.е. по событию.
На временной шкале графика «Количество событий» будут отображены все события из технологического журнала: видно, какие именно события происходили в конкретные периоды, и в какой момент начался их рост. В данном примере сразу можно определить два интервала, когда увеличивалось количество ошибок (EXCP) и событий кластера (CLSTR). Эти интервалы можно изучить детальнее, достаточно выделить мышкой нужный промежуток – и статистика перестраивается именно под него.
Качественная оценка ситуации
Выбираем группируемый ресурс «duration» и уже на соседнем графике получаем распределение событий по длительности их выполнения. Видны интервалы со всплесками длительных TLOCK (ожидания на управляемых блокировках).
Про блокировки ниже будет более подробный разбор, а сейчас просто выделим кликом мыши событие DBMSSQL и посмотрим только события выполнения запросов.
Получаем распределение запросов по длительности, видим пики нагрузки: два больших интервала и два с меньшей длительностью. Скорее всего, в эти периоды менялась и нагрузка на процессор СУБД.
1. Кто грузит процессор СУБД
Чтобы понять, кто и где вызывает эти длительные запросы, достаточно установить отбор event = DBMSSQL и, меняя значения в группировке, смотреть статистику в интересующем разрезе. Например, сгруппировать по «Usr».
Получили распределение, какие пользователи формируют «тяжелые» запросы.Если поставить группировку по контексту, то получим стеки кода, где эти запросы вызываются.
Для удобства мы при парсинге логов из контекста выделяем первую и последнюю строки и записываем в отдельные поля. Установив группировку по «LastLineContext» получим более корректное распределение, т.к. точка входа (документ, отчет, веб-сервис или фоновое задание) не будет иметь значения – группировка идет по строке непосредственного выполнения запроса. Да и работать с одной строкой удобнее, чем с многоуровневым стеком кода.
Вот так, просто «щелкая мышкой», можно получить источник проблем с высокой нагрузкой на CPU. В чем специфика такого подхода: информация о запросах содержит только одну качественную метрику – длительность. При этом все время обработки запроса сервером баз данных может тратиться на процессор. Например, в случаях повышенной нагрузки на ЦПУ, запросы встают в очередь, но процессор не используют, поэтому в аварийных ситуациях в лидеры могут попасть не плохие, а самые часто выполняемые запросы. Что делать: дополнительно собирать запросы на самом СУБД.
2. Работа с управляемыми блокировками
Технологический журнал позволяет анализировать события ожиданий на управляемых блокировках (события TLOCK). Ошибки при этом еще не возникают – фиксируется только факт ожидания.
Группировка по «Regions» дает список блокируемых объектов и покажет что чаще всего блокируется и на каких таблицах дольше всего ждем.
В лидерах и по количеству блокировок, и по длительности ожидания объект «InfoRg76.DIMS», устанавливает фильтр Regions = InfoRg76.DIMS. А что бы понять кто блокирует - сгруппируемся по WaitConnections.
Получаем список номеров соединений, которые блокировали работу. Следующий шаг – понять кто «скрывается» под этим ID и что он делал. В лидерах соединение 5495300, с него и начнем, установив фильтр tconnectid = 5495300.
В таблице смотрим, что делал этот пользователь: здесь видно конкретную строку кода и факт эскалации блокировок. Значит в процедуре идет работа с большим объемом данных, и уже ясно, какое «лечение» требуется.
Но не всегда причина находится так легко. Если у «виновника» была большая транзакция, но блокировки были короткими, а эскалации не возникло, то в таком случае запись в ТЖ могла и не попасть.
3. Жалоба пользователя на «тормоза»
Допустим, приходит пользователь (в нашем примере пусть это будет «ПолучитьХарактеристикиТоваровИПокупателей») и жалуется: «В такой-то период, с 17:30 до 17:40, база сильно тормозила».
Фильтруем все события по пользователю, выбираем соответствующий период и смотрим на графики: какие именно события происходили, в какие моменты времени что менялось.
В данном случае видно, что длительными были события CALL и DBMSSQL.
Переходим в таблицу, сортируем по длительности и видим, что в лидерах двойной CALL. Мы знаем метод и модуль, откуда этот вызов произошел. Третьим по длительности идет SQL-запрос. Фактически мы получаем две задачи на рефакторинг: проверить, что за метод выполняется так долго, и разобраться, почему запрос выполнялся почти 20 секунд.
Сравнение ElasticSearch и ClickHouse
Мы используем оба инструмента, но на данный момент технологический журнал складываем в ElasticSearch, а метрики типа APDEX и различные замеры – в ClickHouse. Скорее всего, в будущем мы перейдем на ClickHouse для хранения логов ТЖ, так как он лучше сжимает данные. В нашем случае логи в ElasticSearch занимают 1.4Тб, а ровно те же данные в ClickHouse – 80Гб.
ClickHouse использует язык, похожий на SQL, что более привычно для разработчика 1С. В ElasticSearch запросы формируются в формате JSON.
Еще одно удобство ClickHouse – возможность подключать его как внешний источник данных прямо в конфигурацию 1С и работать с ним через консоль запросов.
С другой стороны, ElasticSearch пока лучше интегрируется с Grafana. У него надежнее работают ad-hoc фильтры – то есть фильтры, где можно выбрать любое поле и значение без дополнительного программирования в Grafana. В ClickHouse это работает менее стабильно.
Еще одно преимущество ElasticSearch: если в технологическом журнале появляется новое поле или событие, то при изменении правил парсинга оно автоматически создается в отдельном индексе. ClickHouse требует ручного создания новой колонки, прежде чем она станет доступна для запросов.
В качестве короткого резюме: если вы хотите попробовать и понять, ваше это направление или нет, интересно ли вам работать с этим стеком, и что вы можете из этого получить, начните с ElasticSearch.
Идеальный набор инструментов: к чему нужно стремиться
Мы обсудили некий минимальный набор инструментов, но чтобы понять, чего еще не хватает, необходимо провести мысленный эксперимент и представить, что какой-либо узел инфраструктуры (например, кластер 1С) нагружен. Подумайте, есть ли ответы на эти вопросы:
-
Как я пойму, что узел нагружен, и нагружен ли он вообще?
-
Чем именно он нагружен? Если это кластер 1С, то нагрузка вызвана процессами сервера 1С или администратор что-то запустил?
-
Если это процесс сервера 1С, то что внутри процесса rphost вызывает нагрузку? Какой именно код?
Ваши инструменты должны позволять докопаться прямо до строки кода и, в идеале, быстро и наглядно выявлять закономерности. Для серверов 1С это будет технологический журнал. Для сервера баз данных вопросы остаются аналогичными: как себя чувствует сервер, какие метрики у него есть, что именно является его «пульсом», и какие запросы его нагружают?
Дополнительные доработки и фичи
Важный момент – приведенные выше инструменты действительно бесплатны. И их наличие уже сильно лучше, чем вообще ничего. Но если рассматривать через призму «идеальности», то этого недостаточно. Все бесплатные утилиты, которые мы использовали для старта, пришлось дорабатывать, переделывать и дополнять своими сервисами. И это основной камень преткновения – придется инвестировать свое время и силы в настройку и доработку, кирпичик за кирпичиком собирая свой «швейцарский нож».
Мы начали этот путь очень давно и продолжаем наращивать функционал в наш мультитул. Кратко перечислю основное, что очень помогает в работе:
-
Расчет hash по очищенному тексту запроса (как по логам ТЖ, так и по трассе запросов из СУБД).
-
Выделение последней строки контекста.
-
Отдельные значения свойств события CLSTR (например, CLSTR.memDur, cpu, sql), помогающие определить причины снижения индекса производительности rphost.
-
Свойства события CALL, такие как Memory, MemoryPeak, CpuTime. И сразу вычисляем CpuTimePercent как отношение CpuTime к общей длительности вызова. Это помогает быстро идентифицировать код, неоптимально использующий ресурсы сервера 1С.
-
Автоматическая подготовка и хранение отчетов по каждому случаю TLOCK и TDEADLOCK.
Пример отчета по ожиданиям на блокировках:
Теперь не приходится кликать, как в примере выше, для поиска виновника управляемых блокировок: эту «склейку» делает отдельный сервис. А чтобы с гарантией 100% расшифровать все случаи, в отдельный файл собираем все TLOCK (Важно! Будьте аккуратны на продуктиве, этих событий может быть очень много, и нужны очень хорошие диски и место на них).
Пример отчета по взаимоблокировке 1С:
Такой текстовый граф дедлока. Ниже графа идет подробный time-line: что и в каком порядке делали пользователи.
-
Автоматическая подготовка и сохранение расшифровок по каждому случаю ошибок «в данной транзакции уже происходили ошибки» с загрузкой из git текстов процедур и функций.
Например:
Этот отчет помогает быстрее найти причины ошибок, когда транзакция помечается «сломанной», и выработать рекомендации. А интеграция с git –просмотр исходников сразу на рабочем столе – минимизирует необходимость открывать конфигуратор.
-
Сбор запросов с сервера СУБД с помощью трассировок XEvent и сохранением плана запроса. Почему это точно стоит делать, я уже писал, повторюсь – это помогает отвечать на вопрос «Что не так с СУБД?» на основе информации от самой СУБД. Да, можно получить запросы из логов ТЖ, но там только одна метрика – длительность. В информации от СУБД, помимо длительности, есть и время использования запросом процессора, и объемы прочитанных/записанных данных.
Пример рабочего стола:
Тут цифровые значения – это тот самый hash по тексту запроса из трассы, и он будет совпадать с рассчитанным hash этого же запроса в ТЖ: это позволяет узнать контекст запроса.
-
Агрегация данных по трассировкам запросов. Трассировки СУБД храним месяц, а для получения статистики за предыдущие периоды сделали следующее: каждый час группируем данные по hash запроса и сохраняем в отдельную таблицу с расчетом средних и суммарным метрик.
Пример рабочего стола для аналитики «в какой момент запрос стал работать хуже»:
-
Сбор выполняемых в моменте запросов (и их планов) на стороне СУБД. Агент подключается и сохраняет все выполняющиеся запросы: получается так называемый «срез» запросов. Это помогает контролировать мелкие-быстрые запросы, расследовать факты блокировок СУБД, видеть типы и ресурсы ожиданий при выполнении запросов.
Пример рабочего стола:
-
Запись замеров APDEX в ClickHouse. Быстрое получение аналитики было/стало. Из лайфхаков – все необходимые свойства и признаки (например, ключевое время) записывать сразу в таблицу замеров и все, что необходимо для фильтрации и расчета Apdex, должно быть в этой таблице. И обязательно предусмотреть однородность регистра букв при записи имени базы и сервера.
Пример графического отображения распределения длительностей выполнения операции за четыре временных промежутка:
-
Контроль обменов, постобработок и рассылок. Любые очереди должны контролироваться. Например, есть процесс обмена данными документа «Заказ» из ИС 1 в ИС 2. Процесс построен с использованием плана обмена и брокера сообщений. Движение данных: при изменении/создании заказа в ИС 1 в регистрации изменений автоматически появляется запись. Вторым этапом работает регламентное задание: осуществляет выборку изменений и отдает в брокер сообщений. Брокер передает пакет данных в ИС 2, где эти пакеты складывают в промежуточный регистр сведений. Последним этапом регламентное задание в ИС 2 берет пакеты из регистра-очереди и создает нужные документы. При такой схеме, как минимум, необходимо контролировать следующее:
-
ИС 1: количество зарегистрированных в плане обмена заказов.
-
Брокер сообщений: количество пакетов в очереди.
-
ИС 2: количество пакетов в регистре с пришедшими пакетами.
-
-
Загрузка журнала регистрации в ClickHouse. Вспомогательный инструмент, но помогает собирать и накапливать статистику. Очень быстро работает поиск и вывод данных за большие (месяцы) временные интервалы.
В качестве заключения
Сейчас платформа 1С постепенно улучшает возможности по контролю за информационными системами – запись логов ТЖ в формате JSON, получение информации о метриках кластера 1С по http, выгрузка журнала регистрации с помощью утилиты ibcmd. Все это упрощает настройку и разворачивание средств мониторинга и кратно повышает точность и скорость локализации причин сбоев. Да, придется посидеть и разобраться с контейнерами, с Prometheus, OpenSearch, Grafana и т.д. и т.п., но чем раньше в это окунуться, тем быстрее придет понимание, что получаемый функционал с лихвой окупает затраченные усилия. Успехов!
P.S. Делитесь в комментариях своими лайфхаками и функционалом, задавайте вопросы.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
Вступайте в нашу телеграмм-группу Инфостарт
