Может, все-таки включим мониторинг?

Если у вас система выглядит не так, как самолет на этой картинке, вам этот доклад будет не интересен, вы свою систему можете и в консоли мониторить.

Доклад для всех, кто работает с чем-то подобным, и со всем этим пытается как-то лететь.

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

• пользователи орут;

• система падает;

• обмены отваливаются и т. д.

Хочется узнать – кто всё сломал; как всё чинить; и что делать, чтобы этого не происходило.

Проходим все стандартные стадии – пытаемся паниковать, увольняться, чинить.

И тут умные люди из крупного ИТ (не чета 1С), внесли вот такое волшебное слово Observability, которое, кстати, нужно как-то перевести на русский.

Слово Observability говорит о том, что мы должны вот с этим самолетом уметь отвечать на вопросы:

• Что вообще происходит?

• Почему это происходит?

• К чему это приведет?

• Как это вылечить?

• И как сделать так, чтобы этого не происходило?

Т.е. Observability – это наблюдаемость, обозримость и прочее. Если у вас есть предложения, как это перевести, напишите их в комментариях. Как-то не комильфо говорить об этом по-английски.

Важнейшая часть Observability – это мониторинг.

Что и как можно мониторить в 1С?

Мониторить в контексте 1С мы можем, вообще-то, всё.

Платежи контрагентов тоже можно мониторить.

Power BI и прочее – по сути, это тоже часть системы мониторинга.

Никто не пробовал финансовые данные с помощью Zabbix мониторить? Попробуйте, он для этой цели вполне подходит.

Разберемся, какие вообще у нас есть задачи мониторинга:

• сбор интересных нам метрик;

• накопление данных для последующего анализа;

• отображение данных;

• оповещения и автоматические обработчики;

• анализ – отчеты и BigData.

Какие инструменты можно использовать для этих задач?

• Сбор метрик – это обычно Zabbix, Prometheus, Victoria Metrics.

• Накопление данных – это ClickHouse, MS SQL, ElasticSearch. Кто-то даже и базу 1С для этого использует – об этом есть статьи на Инфостарте.

• Отображение данных – это родная для ElasticSearch Kibana и Grafana. Есть еще такой инструмент, как Redash.

• Оповещения – это стандартный механизм. Почта, телеграф, телефон.

• Отчетность и анализ – здесь я инструменты не перечислил, называть не буду. Но это обычно то, что прилагается к инструментам накопления данных – что-то традиционное.

Как из этого всего многообразия выбрать конкретный инструмент? Критерии простые.

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

• У некоторых для целей мониторинга появляется 1С, потому что: «Если не мы, то кто?»

• При выборе нужно предусмотреть возможность масштабирования и расширения, да, потому что наши «самолётики» в системе множатся.

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

• Ну и повторное использование. Если у нас что-то уже есть, мы будем пользоваться тем, что есть.

Собираем систему мониторинга для 1С

Рассмотрим наши источники – именно в контексте 1С. У нас есть:

• Наш любимый журнал регистрации.

• Ещё более любимый технологический журнал.

• Сервер администрирования RAS – очень интересный инструмент.

• Системные счётчики, чтобы смотреть, что у нас происходит с системой и с оборудованием.

• Какие-то данные SQL – или Postgres, или MS SQL, или, возможно, Oracle.

• APDEX из 1С. И не только APDEX – на том же Инфостарте были статьи по другим подходам к мониторингу производительности 1С. Из 1С это тоже всё можно тащить, это все – полезная информация.

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

В этот раз мы ограничим выбор следующими инструментами:

• Zabbix как система сбора и отображения метрик,

• ClickHouse как система накопления данных

• И в качестве волшебной палочки используем OneScript.Web.

Что у нас делает Zabbix?

• У него широкая сеть агентов – мы можем поставить их на все узлы, которые нам необходимо мониторить.

• У него есть возможность автообнаружения – об этом подробнее чуть позже.

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

• Доступен выбор механизмов получения и обработки различных данных.

• Механизм оповещений.

• А также широкий выбор механизмов автоматических действий по триггерам.

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

Решаем проблемы получения и передачи данных. Реализуем HTTP-интерфейс

Это все есть, но какие у нас есть проблемы в связке Zabbix с 1С?

Для получения основной информации о состоянии кластера мы можем воспользоваться:

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

• Если не хотим использовать консоль, поднимаем сервис администрирования кластера RAS, и консольной утилитой RAC начинаем из нее тащить данные.

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

Что мы сделали? Мы взяли OneScript, на нем написали библиотечку под названием iRAC (Interface for RAC).

Так как мы решили к этому всему обращаться с помощью REST API, появился HiRAC (HTTP-Interface for RAC).

Получилась вот такая волшебная цепочка:

Сервер 1С -> RAS -> RAC -> iRAC -> HiRAC -> Zabbix

Вся необходимая информация по этому инструменту опубликована в открытом доступе в репозитории https://github.com/arkuznetsov/hirac.

Этот REST API умеет выдавать информацию в трех форматах.

• Формат JSON;

• Формат Plain text – тоже можно пользоваться.

• И формат в стандарте Prometheus – туда можно цеплять агента Prometheus, и он все это благополучно засосет, и все правильно в базу разложит.

Можно использовать что кому удобнее.

Далее мы продолжим про использование HiRAC в контексте Zabbix.

Что умеет HiRAC?

• Он работает на OneScript Web и умеет выдавать любую информацию о текущем состоянии кластера 1С – сеансы, базы и прочее.

• Он умеет выдавать как списки объектов кластера, так и специально настроенные счетчики с агрегированными показателями в различных разрезах.

• Может параллельно обрабатывать любое количество запросов (это не совсем так, об этом потом отдельно скажу!).

• Умеет одновременно поддерживать соединение с несколькими серверами администрирования кластеров. Вы можете натравить одну службу HiRAC на несколько кластеров 1С и мониторить через одно единственное подключение.

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

Оптимизация

Характерно, что эту же тему мы обсуждали на митапе в феврале 2021 года, и тогда на этом месте был слайд, как у нас все хорошо. Но буквально через пару дней после доклада выяснилось, что все работает не так, как ожидалось.

Первоначально использовался следующий подход:

• Мы подключались к Zabbix-агенту, который располагался на машине рядом с HiRAC.

• HiRAC обращался к Zabbix-агенту с HTTP-запросами через ключи вида web.page.get/web.page.regexp (то есть с регулярками).

• Вытягивал из этих JSON-чиков необходимые данные и их возвращал.

Думали, все хорошо. Но каждый настроенный в Zabbix счетчик (а счетчиков получилось достаточно много, я дальше расскажу, что они не просто настраиваются, а там работает именно автообнаружение) каждый раз дергал HiRAC, HiRAC дергал iRAC, дальше RAC, дальше RAS, и обратно по цепочке возвращал все эти данные.

Это оказалось накладно.

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

• И есть подозрение (пока не до конца подтвержденное), что RAS не очень любит массовые одновременные обращения и обрабатывает запросы все-таки в порядке очереди.

Прошло месяца три, и мы, глубоко погрузившись в Zabbix, все это дело порешали.

• Сейчас раз в минуту запрашивается полный снимок состояния кластера – этакой здоровенной «простыней» в JSON. Все сервера, все сеансы, все соединения. Раз в минуту – это вполне допустимая нагрузка, все отлично работает.

• А дальше уже средствами Zabbix через волшебное средство JSON-path все данные, полученные через зависимые элементы, разбираются на те счетчики, которые нам нужны.

Расскажу про автообнаружение – здесь, наверное, самый интересный кейс на примере сеансов.

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

• кто «кушает» процессор;

• кто «кушает» память;

• кто слишком долго общается с SQL и т.д.

Все эти фильтры настраиваются через JSON-path, и только на такие сеансы цепляется ряд счетчиков – где мы слишком много читаем, слишком много пишем, слишком много «кушаем» проца, памяти и т.д.

В этом случае срабатывают уже соответствующие триггеры и отправляются оповещения.

Результат работы Zabbix

Вот такие красивые картиночки нам рисует Zabbix – здесь, кстати, мониторится сам сервис HiRAC, то, как быстро он нам отвечает.

Здесь сверху видно те самые пресловутые 15-20 секунд на получение списка соединений.

Вот такие картинки заставляют нас паниковать – мы видим, что у нас возникли какие-то проблемы.

При возникновении проблем могут приходить оповещения:

• по email;

• по SMS;

• с любыми web-хуками;

• а также с использованием произвольных скриптов.

Вот так это приблизительно выглядит.

• приходит сообщение, что произошло;

• какие допустимые пределы нарушены;

• ссылка, где можно посмотреть подробности.

В данном случае по этой ссылке открывается голый REST HiRAC, где мы можем в JSON увидеть полную информацию о проблемном сеансе.

Пробуем прогнозировать проблемы чуть шире, чем «заканчивается место на диске»

На этом мы решили не останавливаться. Нам же интересно, что с СУБД происходит. Да, у MS SQL, у PostgreSQL существуют свои средства подключения к Zabbix, даже готовые агенты.

Ну, мы же 1С-ники. Более того, мы любим OneScript. Поэтому результаты работы HiRAC мы обогатили информацией непосредственно от сервера СУБД.

Здесь кривой красной линией отмечены данные о размерах нашей базы данных, которые мы получили непосредственно из MS SQL.

И это не единственные данные, которые можно получать.

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

Единственной проблемой будет одинаково назвать различные данные PostgreSQL и MS SQL, потому что у них параметры немного отличаются, и смысл немного разный имеют. В общем, это тоже решаемая проблема.

Более того, мы умеем вот так.

Здесь выведена информация о конкретных таблицах базы данных. Причем даже написано, что это за таблица – например, здесь красной стрелочкой показано, что это у нас «РегистрБухгалтерии.Хозрасчетный».

Это значит, что мы можем прекрасно мониторить:

• размер этих таблиц;

• их рост;

• количество обращений к этим таблицам и т.д.

И дальше с этим что-то делать.

ClickHouse

До сих пор я рассказывал все про Zabbix, но там был еще ClickHouse. Зачем он нам нужен?

• Он нам нужен для того, чтобы хранить какие-то данные.

• Например, мы можем в него собирать данные из разных источников – с разных кластеров, с разных баз. Когда я рассказывал этот доклад на февральском митапе, на слайдах вместо ClickHouse был ElasticSearch. После этого мы посмотрели ClickHouse, и у него есть замечательное преимущество по сравнению с ElasticSearch – он использует гораздо меньше места. Например, журнал регистрации ClickHouse жмет как минимум в пять раз, в отличие от ElasticSearch. И это только один узел в кластере. А если у нас нормальный кластер ElasticSearch – как минимум из трех узлов – соответственно, умножайте свои журналы регистрации на это количество.

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

• У ClickHouse отличное REST API – и для помещения в него данных, и для получения, например, в Grafana или даже в 1С.

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

Средства сбора и анализа проблем по данным ЖР и ТЖ

А что у нас с журналом регистрации не так?

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

Это все нужно разобрать, каким-то образом привести удобочитаемый вид, и каким-то образом привести в тот вид, который съест наша хранилка – ElasticSearch или ClickHouse.

И для этого коллеги напилили массу инструментов. Здесь я, наверное, указал ссылки на самые известные.

• https://github.com/YPermitin/YY.EventLogExportAssistant и https://github.com/YPermitin/YY.TechJournalExportAssistant – пара инструментов от Юры Пермитина для сбора журналов регистрации и сбора технологических журналов.

• https://github.com/akpaevj/OneSTools.EventLog – отличный инструмент для экспорта журнала регистрации от Жени Акпаева. Если кто видел видео про сверхбыстрый журнал регистрации 1С от Андрея Овсянкина – он его там использовал.

• https://github.com/arkuznetsov/yabr.os – я тоже немного в этом марафоне поучаствовал, сделал на OneScript разбор скобкофайлов для разных целей, в том числе для целей помещения журнала регистрации в ElasticSearch или в ClickHouse. Честно скажу, что инструмент на OneScript помедленнее вышеперечисленных в силу некоторых особенностей самого OneScript. Но, тем не менее, имеет право на жизнь. Можно пользоваться.

iRAC command line interface для накопления данных о сеансах 1С

Ну, и куда же без извращений?

Был сделан так называемый iRAC command line interface – в просторечии iracli. Это – инструмент командной строки, который является обёрткой над библиотекой (iRAC) и над инструментом командной строки (RAC).

Зачем, спрашивается? Причин три.

• Первая причина звучит как: «Because I can».

• Вторая причина – у него получился более дружелюбный интерфейс. Там синтаксис, аналогичный тому, который использует HiRAC для HTTP-запросов, есть человекочитаемые фильтры, человекочитаемые названия баз, серверов и прочего. Использовать его удобнее.

• Ну, и третья причина – в тот момент, когда я схватился за голову, что ничего не взлетает, т.к. процессор тупо тормозит, я подумал, что, возможно, надо воспользоваться другим инструментом Zabbix – через Zabbix-агент сделать user commands. А user commands на вход просит указать командную строку вызова другого инструмента – того, который вернёт нужные вам данные. Поэтому был написан iracli.

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

• он эти снимки может либо просто сохранять в файлики JSON с метками времени;

• либо, опять же, отправлять ClickHouse и там копить.

На слайде скриншот Tabix – это веб-интерфейс к ClickHouse. Здесь показаны накопленные данные о сеансах 1C.

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

Мы планируем включить уже в процесс мониторинга не только «post mortem» мониторинг, но и попробовать построить на основе этой информации какое-то прогнозирование.

Выводы

При помощи перечисленных в докладе инструментов мы в итоге:

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

• В очередной раз подтвердили, что OneScript Web имеет право на жизнь – это шикарный инструмент для быстрых «поделок». Мне больше всего нравится на нем именно REST API делать.

• Рассмотрели варианты решений для сбора журналов.

• Копим статистику.

• И собираемся развивать наши инструменты дальше.

Вопросы

У вас показывалась табличка Tabix. Насколько это читаемо, когда GUID хранятся без человеческого представления? Что за пользователь? Что за информационная база? Как вы их идентифицируете потом?

На той картинке были сырые данные, но вы можете с кластера простым JOIN в SQL-запросе получить полную информацию – например, превратить GUID в человекочитаемые имена баз.

Планируете ли вы создавать готовые решения по мониторингу кеша планов запросов и других внутренних метрик СУБД, куда еще не ступала нога 1С-ника?

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

Сейчас промышленные решения уходят на Loki и на CNCF. Например, все, что мониторит Kubernetes, использует вместо ELC Grafana и Loki. Вы туда пока не смотрели, чтобы написать адаптер?

На Loki пока не смотрел. Я очень пристально смотрю на Victoria Metrics, честно говоря. Мне нравится, что эти ребята делают. Но пока, опять же, руки не дошли.

Вы эти инструменты в одиночку, получается, пишете?

Почти. Есть еще один товарищ, который хочет все переписать на Java.

По поводу RAC, RAS и их взаимодействия... Когда-то фирма «1С» опубликовала Java-интерфейс для администрирования. Не было ли желания покопать именно в сторону использования другого клиента – не RAC? В плане оптимизации взаимодействия с RAS.

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

А из корпоративного инструментального пакета не рассматривали ЦКК в целях мониторинга?

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

С ЦКК я знаком с первых версий. Он, конечно, развивается очень неплохо, поэтому кому удобно – могут его использовать.

Почему у вас все RAC-ом через RAS? Нет ли идей избавиться от них вообще?

С одной стороны, хочется задуматься об альтернативе.

Но с другой стороны, если развернуть в Kubernetes, тут уже появляются сомнения. Мы же за микросервисы и прочее. Поэтому отдельные сервисы в отдельных pod`ах, в отдельных кластерах, RAS, RAC и прочее...

Если серьезно, наверное, у вендора были причины, почему они сделали именно так.

Я не готов тратить время на разбор этих причин – пытаться выяснять, что, зачем. Я им доверяю – за 20 лет, судя по моему благосостоянию, меня 1С ни разу не подвел.

Ссылки на упомянутые инструменты

https://github.com/EvilBeaver/OneScript – интерпретатор OneScript

https://github.com/EvilBeaver/OneScript.Web – движок OneScript.Web

https://github.com/arkuznetsov/irac – библиотека взаимодействия с утилитой RAC

https://github.com/arkuznetsov/hirac – реализация REAS API для получения данных и управления кластером 1С

https://github.com/arkuznetsov/iracli – утилита командной строки для получения данных от кластера 1С

https://github.com/arkuznetsov/yabr.os – утилита командной строки для обработки «скобкофайлов»

https://github.com/YPermitin/YY.EventLogExportAssistant – инструмент для экспорта журнала регистрации 1С

https://github.com/YPermitin/YY.TechJournalExportAssistant – инструмент для экспорта технологического журнала 1С

https://github.com/akpaevj/OneSTools.EventLog – еще один инструмент для экспорта журнала регистрации 1С