APDEX 1C + Prometheus + Grafana + Superset, а точнее наоборот

Здравствуйте, мои маленькие любители программирования. Сегодня мы поговорим об ….

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

В порядке знакомства

Зовут меня Валентин Козлов. Я начинал свою карьеру простым разработчиком 1С и дошел до руководителя отдела ИТ в компании являющейся частью глобального концерна. За годы работы мы смогли создать уникальную команду ИТ, способную решать задачи любой сложности, со средним сроком работы разработчиков 6 лет, и нам было совершенно не важно на каких технологиях мы решим ту или иную задачку. Поэтому я могу с полной уверенностью сказать, что в ИТ главное люди - а не технологии. По моему мнению, сработанная команда из 3-5 инженеров, которым «непофиг», может полностью изменить компанию изнутри и вывести её на первые места в отрасли. Для того, чтобы это произошло, этими людьми должны управлять люди, способные понимать все нюансы работы в ИТ и самое главное, что мотивирует и демотивирует инженеров. Именно поэтому сейчас есть огромный спрос на ИТ-лидеров, способных своими руками «делать страшное», а эра классических ИТ менеджеров потихоньку уходит в закат (да простят меня классические ИТ менеджеры 😊).

Большая проблема многих инженеров — это то, что они считают, что им достаточно просто хорошо работать. К сожалению, мир гораздо сложнее и нужно не только хорошо работать, но еще нужно уметь хорошо продавать результаты своего труда. Именно поэтому сегодня я хочу начать серию статей, рассказывающих о том, что нашей команде удалось сделать интересного, вместе с этим поделиться с Вами готовыми и не очень решениями, чтобы вы не делали всё с нуля.

Постановка проблемы и формулировка задачи

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

Итак - предположим, у вас как в свое время и у нас есть проблема

• В условиях непрерывной разработки неизбежна ситуация, когда системы и продукты начинают “тормозить”
• Отдать технический долг быстро почти невозможно, для начала много времени будет затрачено на поиск неоптимальных мест

Отсюда и возникла задача:

• Измерить производительность наших ключевых операций для всех наших сервисов-продуктов, которых у нас больше 30 и количество их постоянно растет

На момент написания статьи у нас было 4 основных стека: 1C, Python, GoLang и C#, поэтому нам нужна была стандартная методология замера производительности операций, вместе с этим было важно предоставить “сервис для команд” который будет помогать им каждый спринт видеть какой технический долг отдать надо сегодня и какую ключевой операцию починить

Особенности решения (ADR)

В качестве рекомендуемой методики мы, недолго думая выбрали APDEX. И не потому, что она простая - есть и более качественные методики. Самыми главными критериями были:

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

И для тех, кто совсем не в курсе “за методику” APDEX дам вам небольшое определение из ссылки выше:
Apdex (Application Performance Index) - это открытый стандарт для измерения производительности программных приложений в вычислениях. Его цель - преобразовать измерения в информацию об удовлетворенности пользователей, указав единообразный способ анализа и составления отчетов о том, в какой степени измеренная производительность соответствует ожиданиям пользователей. Он был разработан альянсом компаний.

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

• Prometheus для сбора метрик - “Коллектор”
• Grafana для оперативного отслеживания метрик инженерами - “Отображатель и оповещатель”
• Superset для анализа накопленной аналитики - “Анализатор”
• В качестве хранилища и источника данных для Superset был выбран PostgreSQL с расширением TimescaleDB - “Хранилище накопленных метрик”

Мы получили следующую схему:

Скрытые причины выбора -  о них стоит сказать отдельно

В качестве пилота был выбран один из наших сервисов написанных на Python. Для сбора метрик использовалась стандартная SDK “Prometheus Python Client”. Мои коллеги, успешно реализовали пилот и быстро получили свой дашбоард и быстро поправили неоптимальности…

То есть - в данном случае, исследовать особенности “прометея и не пришлось”

1С конфигурация про Open Telemetry не знает ничего

После пилота дошла очередь и до 1С. С ней все оказалось сложнее так как «проклятые буржуи» не сделали SDK для 1С, поэтому пришлось «колхозить» свой вариант реализации 😊. Для этого пришлось изучить формат выгрузки метрик и разобраться с их типами. Согласно документации Prometheus данные по APDEX должны «ехать» с типом метрик «histogram».

Вообще здесь важно обратить ваше внимание на несколько особенностей сервиса Prometheus которые заложены в нем архитектурно

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

Интересно то, что скорость выполнения запросов из 1С должна быть очень высокой, так как метрики должны поставляться:

1 раз в минуту. Да - мы хотим видеть Continuous APDEX !!!

То есть команда может глядеть на свой APDEX раз в день, а сервис должен получать их раз в минуту — это важное требование. Потому что почистить и сжать метрики мы сможем всегда - а вот переделывать загрузку, когда нам понадобится изменить частоту отправки совершенно не хочется, плюс это стало дополнительным тестом на производительность самого “Прометея”.

• Вторая особенность Prometheus: Служба “Прометея” желает подключаться к API приложения и делать оттуда PULL метрик

А у нас при интеграции есть одно из наших любимых правил

 «сосать плохо»

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

Адаптер 1С-Prometheus

Как же в итоге сделан - адаптер на стороне 1С. Внимание - сейчас будет минутка программиста.

В расширении перехватываем запись стандартного регистра "ЗамерВремени” из БСП и формируем данные в нужном нам формате в регистре “APDEXMetrics”:

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

Для отправки метрик выбираем данные из регистра APDEXMetrics:

Формируем метрику в нужном формате:

и отправляем данные в Pushgetway:

Ну и из Ынтересного. Обратите внимание, что все метки (Labels) формируются в кодировке base64. Это нужно, чтобы русские букавки выводились корректно:

Красивые результаты, что видят наши команды

Когда метрики были доставлены до Prometheus, дошла очередь для формирования красивых бордов в Grafana:

Далее метрики из Prometheus были перенаправлены в PostgreSQL и выведены в общий борд Superset-а по APDEX:

Заключение

Все доработки по 1С живут в моем репозитории 1C_PrometheusExporter там же есть подробная инструкция по адаптации расширения. Есть множество микро идей как его можно развить, например:

• Покрыть тестами
• Перевести на EDT
• Поработать с функцией ИсторияДанных для регистра сведений замеров, чтобы не использовать подписку на событий
• Прочее

Но сейчас, я как любой «нормальный» ИТ специалист люблю делать полезные вещи итеративно и радуюсь, когда результатами моего труда могут пользоваться другие, поэтому очень надеюсь, что данная статья будет полезна вам.

В любом случае - в следующей статье я расскажу вам, как мы «вывезли» в Superset логи журнала регистрации, какие проблемы у нас были и как мы их решили, ну и конечно выложу рабочие инструменты позволяющие повторить «наш подвиг» 😊.

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

P.S. Обратите внимание, пока мой аккаунт "отбрендирован" как корпоративный - это временное решение, так как мы хотим уже начать делиться с сообществом, а наши корпоративные закупщики пока согласуют деньги ;-) на корпоративный аккаунт.