Каталог решений - 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 — “Хранилище накопленных метрик”

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

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