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

16.02.22

Разработка - DevOps и автоматизация разработки

Вы не задумывались о том, что расчет APDEX должен быть онлайн? Онлайн для всех - от бизнес-пользователей до команды разработки. Если задумывались - то в статье мы расскажем, зачем это делать, и поделимся наработками, как подключить 1С+APDEX к такой штуке, как Prometeus.

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

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

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

Зовут меня Валентин Козлов. Я начинал свою карьеру простым разработчиком 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 - “Хранилище накопленных метрик”

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

 

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

 

Инфраструктурный сервис

Особенность сервиса

Потенциальный выигрыш в перспективе

Prometheus

Сервис провоцирует разработчика думать о метриках самому - то есть идея сервиса в том, что “Только разработчик продукта знает какие точки и метрики ему мониторить”, в отличие от Zabbix агента - где метриками управляют админы, которые ничего не знают про продукт

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

Grafana

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

Накопление готовых элементов в формате JSON/YAML с последующим переиспользованием между командами продуктов - вне зависимости от языка программирования

Superset

Сервис провоцирует инженеров погружаться в концепцию SelfService-Bi - а не ждать пока выдадут доступ на платные сервисы типа PowerBI/1C-Аналитика/Tableu/etc

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

TimescaleDB

Сервис провоцирует инженеров изучать специализированные хранилища данных - в частности хранение временных рядов

Обучающий эффект - позволяет изучать экосистему PostgreSQL, без необходимости внедрять спец средства типа Yandex ClickHouse - то есть инженер развивается как DBA изучая теорию СУБД.

 

В качестве пилота был выбран один из наших сервисов написанных на 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. Обратите внимание, пока мой аккаунт "отбрендирован" как корпоративный - это временное решение, так как мы хотим уже начать делиться с сообществом, а наши корпоративные закупщики пока согласуют деньги ;-) на корпоративный аккаунт.

APDEX 1C Prometheus Grafana Superset

См. также

Автотесты для типовых конфигураций ERP Управление предприятием 2 и Комплексная автоматизация 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.15.111.

2220 руб.

04.07.2022    6720    26    0    

22

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9140    78    4    

110

Автотесты для типовых конфигураций Бухгалтерия предприятия КОРП 3.0 и Бухгалтерия предприятия 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.144.49.

1728 руб.

20.01.2022    6586    10    0    

9

Автоматическое подтверждение легальности обновления базы или как обновить 100 типовых баз 1С за 5 часов

DevOps и автоматизация разработки Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

Расширение для конфигураций 1С для автоматического подтверждения легальности обновления и выполнения обработчиков обновления при пакетном автоматическом обновлении большого числа баз 1С. А также сам модуль обработки по автоматическому обновлению баз.

2 стартмани

08.05.2019    24210    54    VPanin56    26    

26

1С, СППР и Архитектура как код

DevOps и автоматизация разработки Бесплатно (free)

Можно ли идеи подхода «Архитектура как код» положить на 1С или иную платформу, чтобы не изобретать ещё какой-то язык и сразу получить множество готовых библиотек функций и инструмент достижения главной цели подхода AaC.

01.02.2024    2457    roman72    9    

7

TCP прокси-сервер хранилища конфигурации 1С

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2771    kamisov    17    

57

Infrastructure as code: кнопка «Сделать всё», или Упаковываем наше окружение в 5 кБ текста

DevOps и автоматизация разработки Бесплатно (free)

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

01.11.2023    1324    Libelle    5    

13

Обработка для подготовки файла настройки дымовых тестов измененных объектов конфигурации

DevOps и автоматизация разработки Тестирование QA Россия Абонемент ($m)

В статье приведен пример обработки, которая на основании измененных файлов git-репозитория готовит специальный файл настройки xUnitParams.json для последующего выполнения дымовых тестов (xUnitFor1C/add) только для измененных объектов конфигурации

1 стартмани

09.10.2023    706    4    ICL-Soft    0    

3
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. ImHunter 312 16.02.22 12:24 Сейчас в теме
Рассматривали стек ELK?
2. digital-samolet 124 16.02.22 12:31 Сейчас в теме
(1) Вопрос больше евангелистический - над нами давлеет то что нам нужно на несколько платформ - а у Python/Golang - Prometeus+loki+graphana - это стандарт. ELK как бы нет
3. comol 5051 16.02.22 12:59 Сейчас в теме
(1) "Стеку ELK гореть в аду". По крайней мере для таких задач. Ну оооочень дорого.
4. ImHunter 312 16.02.22 12:59 Сейчас в теме
(2) Ясно. Так исторически сложилось)
5. comol 5051 16.02.22 13:00 Сейчас в теме
А вот почему push gateway... не пытались pull сделать - классический для прометеуса подход?
8. Frog 16.02.22 13:06 Сейчас в теме
мы не любим когда у нас сосут :-).
anosin; amon_ra; botokash; +3 Ответить
6. ImHunter 312 16.02.22 13:00 Сейчас в теме
(3) Гхм. А в чем дорого? Если спец модули не нужны, то как бы и забесплатно.
7. comol 5051 16.02.22 13:02 Сейчас в теме
(6) x10 к объёму хранения + процессор/память сопоставимы с продом. + 3 ноды + если более 1ТБ журналов получится (а у вас получится) на Elastic gold попадаете. Ну или если хоть какой то инфобез есть в компании и нужна ролевая модель к эластику
16. IT_Magnit 16.02.22 15:01 Сейчас в теме
(7) На одной ноде живем с более 1 ТБ журналов
17. comol 5051 16.02.22 15:06 Сейчас в теме
(16) Отвага и .... :)))
Эластик в принципе официальная рекомендация от 3-х нод. Но можно и на одной конечно запустить и в докере на десктопе без рейда, кто же запретит :)
18. IT_Magnit 16.02.22 15:18 Сейчас в теме
(17) Всегда все делаешь по официальным рекомендациям?))) И в 1С в СУБД не ногой?)
Для разбора логов прекрасно подходит и одна нода, проблем не наблюдаем. В день около 60 млн записей.
20. comol 5051 16.02.22 15:55 Сейчас в теме
(18) Ну вообще я ещё "немного" его внутри знаю. И собственно говоря потерять все данные вообще не проблема. Кроме всего прочего нагрузка на диск просто лютая. 60 млн в день это ни о чём конечно, но добавить ноду уже будет проблемно - придётся индекс пересоздавать. Дисковая подсистема которая в одиночку выдерживает даже такую нагрузку это конечно круто, но... очень уж смело, да как и в принципе логи в эластик это смело.
IT_Magnit; +1 Ответить
9. ImHunter 312 16.02.22 13:06 Сейчас в теме
(7) Понял, пасиб.... Буду сильно иметь в виду.
10. Tavalik 3350 16.02.22 13:12 Сейчас в теме
Спасибо, что поделились. Хоть задач таких нет, но было интересно прочитать какие проблемы у других и как они их успешно решают.
11. Tavalik 3350 16.02.22 13:13 Сейчас в теме
На Инфостарте, как и давно уже на Хабре, начали появляться корпоративные аккаунты. Это радует! Лишь бы качество контента не падало за счет заказных статей ради статей.
15. IT_Magnit 16.02.22 14:01 Сейчас в теме
(11) В 2020 Инфостарт Магниту не разрешил публиковать статьи под корп. аккаунтом. Сказали, что только человек может статьи писать. И, мол, вообще нельзя, чтобы публикующийся аккаунт содержал название компании или её лого.
19. digital-samolet 124 16.02.22 15:54 Сейчас в теме
Мы явно хотим создать корпоративный аккаунт - но пока идут согласования бюджетов просто поделились интересным параллельно. Я так понимаю - это временное исключение, за что мы искренне благодарны команде Инфостарт
38. ix5s 118 21.02.22 11:55 Сейчас в теме
(15) такая же была ситуация, удаляли аккаунт с логотипом и названием компании
12. vovast 16.02.22 13:20 Сейчас в теме
Я правильно понял, что у вас для всех ключевых операций целевое время выполнения - 1 секунда?
13. digital-samolet 124 16.02.22 13:24 Сейчас в теме
(12) так точно - а для некоторых меньше секунды. Это сделано специально - чтобы 1С разработчики не делали ключевых операций длинных, а разделяли их на многопоточные. Такой подход используется в соседних платформах - стиимулировать разработчиков писать асинхронные многопоточные алгоритмы
JohnyDeath; It-developer; +2 Ответить
21. Tavalik 3350 16.02.22 16:55 Сейчас в теме
(13) Интересно. И как? Удается? Как быть с кодом типовых конфигураций?
JohnyDeath; +1 Ответить
23. It-developer 24 17.02.22 10:58 Сейчас в теме
(13)При этом понимание чужого кода или своего кода через время - нормальное?
14. Frog 16.02.22 13:52 Сейчас в теме
22. kraynev-navi 647 16.02.22 22:32 Сейчас в теме
(0) Вдохновляюще! С нетерпением ожидаю продолжение про superset. Спасибо!
24. digital-samolet 124 17.02.22 12:04 Сейчас в теме
25. JohnyDeath 301 17.02.22 21:29 Сейчас в теме
Режим совместимости расширения указан как "Версия 8.3.17". А типовые сейчас на 8.3.16 подзастряли.
Будут ли какие-то проблемы, если я изменю режим совместимости? Может вы завязывались на некие плюшки этого режима совместимости?
26. digital-samolet 124 18.02.22 08:44 Сейчас в теме
(25) Приветствую.
Не знаю, не тестировал. Я думаю, что может не работать только в части функционала расширений. Например, в 17 версии есть какая-то фишка с объектами, а в 16 нет. В любом случае сам алгоритм сбора и отправки метрик будет работать и переделать стандартный функционал не проблема.
По факту это просто MVP и вы можете дорабатывать его как хотите :-)
27. JohnyDeath 301 18.02.22 08:51 Сейчас в теме
(26) в любом случае - спасибо!

Осталось только с Графаной разобраться ) На "интуитивно" создать графики не получилось. Придется, наверное, документацию читать ))
28. digital-samolet 124 18.02.22 08:53 Сейчас в теме
(27) У меня в репозитории есть уже борд готовый в формате JSON, просто разберитесь как его загрузить ;-)
29. JohnyDeath 301 18.02.22 08:59 Сейчас в теме
(28) его я подгрузил, но что-то там полупустое всё. Поэтому вот и пытаюсь разобраться.
34. vovast 18.02.22 11:31 Сейчас в теме
(25) С режимом совместимости 8.3.16 работает
30. digital-samolet 124 18.02.22 09:20 Сейчас в теме
Скорее всего для борда нужно еще переменную создать. Скрин приложил
Прикрепленные файлы:
JohnyDeath; +1 Ответить
31. digital-samolet 124 18.02.22 09:23 Сейчас в теме
(30) Извиняюсь за дурацкий скрин: label_values(onec_business_transaction_duration_seconds_by_key_operation_­sum, exported_instance)
Прикрепленные файлы:
JohnyDeath; +1 Ответить
32. Jimbo 9 18.02.22 11:26 Сейчас в теме
Что за конфигурация 1с ?
После этих замеров нашли и оптимизировали хоть что-то ? Хотелось бы пару слов ещё конкретики.
33. JohnyDeath 301 18.02.22 11:30 Сейчас в теме
(31) Вроде бы импортировались сразу вместе с настройками
35. digital-samolet 124 18.02.22 12:01 Сейчас в теме
(33) Тогда придется ковырять. Не знаю.
36. user1407676 18.02.22 16:58 Сейчас в теме
Валентин, у меня вопрос по методике.
Все приведено к "односекундному" интервалу. Т.е. разработчики должны мегатяжелые операции раздробить. А как быть с теми, для которых 1 секунда это уже очень долго? Т.е. запрос в соседнюю систему за данными выполняется в разы меньше и это считается ключевой операцией. Укрупнять?
Я к тому, что почему не пошли по пути передачи непосредственно вычисленного апдекса из системы, например?

p.s. Может кому-то пригодится:
При применении дашборда в Графану пришлось немного руками код подправить в части источника. Почему-то Прометеус не распознавался.
Заменил rate на delta - так как-то понятнее с количеством операций в промежутке, в отличии от "Операций в секунду". Хотя все равно не целое значение отображается.
JohnyDeath; +1 Ответить
37. digital-samolet 124 19.02.22 21:07 Сейчас в теме
(36) Тут вопрос методический - мы скорее приглашаем наших продактов к дискуссии - они могут поменять свои целевые времена - мы решили что 1Секунда это прикольно - потому что во первых показывает что длительные операции это плохо. С другой стороны на микрооперации мы закрываем глаза - если пользователь хочет быстрей - ему ничего не стоит попросить нас уменьшить время - в формате я хочу чтобы "Операция XXX выполнялась за 0.2 секунды". По сути - наши команды живут в дружбе с пользователями - поэтому если кто-то не согласен - он может в рамках дискуссии изменить время. Сейчас среди программистов сложилась нехорошая практика - целевое время меняет сам программист - а ему выгодно поставить побольше время, ну чтобы сильно не заморачиваться. Причем такая порочная практика сложилась не только у 1С программистов, но и у GoLang/ Python/C#/Java программистов

Применение внешнего сервиса контроля целевого времени APDEX позволяет вынести данную метрику в зону публичного обсуждения - в том числе с группой QA.
Ta_Da; Shmell; +2 Ответить
39. vovast 24.02.22 09:29 Сейчас в теме
(37) Но ведь при текущей реализации у вас не получится в Grafana считать APDEX для операций с разным целевым временем выполнения? У вас в Grafana 1 сек в формулу расчета APDEX в явном виде внесена.
40. digital-samolet 124 24.02.22 10:07 Сейчас в теме
(39) У нас не было такой цели. Мы считаем, что любая бизнес-операция должна выполняться не более 1 секунды. С этим можно соглашаться или нет, но мы так считаем.
Если у вас стоит задача сделать несколько границ, то я бы сначала их логически разбил на несколько блоков (сейчас в 1С это неуправляемая штука, где можно поставить все что угодно), а дальше сделал бы дополнительный lable со значением этих блоков и построил бы несколько бордов. В любом случае, если конфигурация большая вы никогда не достигните 100% APDEX, но сразу будете видеть отклонения, с которыми нужно работать.
41. fregl 06.03.22 00:27 Сейчас в теме
Спасибо за статью, очень познавательно.
Подскажите, когда планируете следующую про логи журнала регистрации?
42. digital-samolet 124 07.03.22 10:51 Сейчас в теме
(41) Здравствуйте.
Спасибо за обратную связь.

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