[Atlassian] Как трассировка запросов с помощью open-source Glowroot помогает Atlassian инженеру?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В настоящей статье расскажу историю о том, как можно столкнуться с довольно простой проблемой на больших инсталляциях продуктов компании Atlassian, в частности на Jira. Методы анализа и поиска узких мест:
- статистика
- сэмплирование
- профилирование и трассировка
В этой статье мы разберем трассировку запросов, которая показывает практически весь отрезок запроса, а именно от начала запроса с браузера клиента до перехода к обратному прокси, если он существует, к серверу приложений и от него до кэшей, поисковых индексов Lucene, СУБД. Важный момент — сложно провести анализ системы со стороны заказчика, так как с их стороны были жесткие требования по использованию инструментов, которые перечислены в требованиях.Требования Расходы на APM-инструменты (инструменты для мониторинга производительности) изначально не были заложены в бюджете проекта, поэтому одним из главных критериев выбора стала бесплатность решения. Другой важный момент — нужно было предварительно проверить инструмент на наличие уязвимостей и вредоносного кода. Стало очевидно, что чтобы удовлетворить первые два критерия поиска, нужно искать open source решения. Еще одно требование — чтобы данные не выходили за пределы ограниченного контура, и была дополнительная возможность интеграции с существующей инфраструктурой.Поэтому критерии выбора инструмента были следующими:
- бесплатный;
- установка на собственном инфраструктура (On-Premise);
- открытый исходный код;
- возможность интеграции с Elasticsearch (Opendistro);
- совместимость с JVM (поскольку Atlassian написан в основном, на Java), или как javaagent;
- возможность связки запроса HTTP c SQL-запросы;
- наличие графиков в перцентилях;
Для меня последний пункт важен, поскольку он помогает выявить отправную точку, чтобы не заниматься последствиями. На рисунке ниже видно, что проблема фактически началась в 12 часов ночи, а не спустя 1 час. В случае отсутствия деления на процентили легко можно потратить много времени на устранение симптомов и только потом разобраться с причиной. Конечно, случаи бывают разные. 
графикВ качестве отправной точки использовался сайт https://openapm.io/landscape, который собрал практически все актуальные APM-инструменты. После проведения сравнительного анализа мы остановили выбор на инструменте Glowroot, который удовлетворял всем критериям.Установка Установка приложения довольно простая на агентах, и в данной статье показана схема работы со встроенным коллектором, но для промышленных инсталляций используется Cassandra (как представлено на диаграмме) со связкой с Elasticsearch.
- Скачиваем инсталлятор
wget -c https://github.com/glowroot/glowroot/releases/download/v0.13.6/glowroot-0.13.6-dist.zip
2. Для проверки создаем директорию mkdir -p /jira/glowroot/tmp, чтобы владелец процесса приложения Jira мог писать в эту же директорию, и устанавливаем права на владение для простоты, но рекомендуется просто выдать возможность записи владельцу процесса Jira
chown -R jira: /jira/home/glowroot
3. Устанавливаем дополнительно аргумент в setenv.sh в инсталляционной директории jira, в нашем случае это /jira/current/bin. По умолчанию, Атлассиан использует директорию /opt/atlassian/jira/bin в файле добавляем следующую строку:
JVM_SUPPORT_RECOMMENDED_ARGS="-javaagent:/jira/glowroot/glowroot.jar ${JVM_SUPPORT_RECOMMENDED_ARGS}"
4.После перезапускаем приложение:
systemctl restart jira
И мониторим на наличие ошибок посредством команды:
tail -f {jira_installation_directory}/logs/catalina.out
Так как по умолчанию биндится адрес 127.0.0.1, то идем в директорию в glowroot и смотрим, что появились файлы такие, как admin.json. В ней можете поменять bindAddress на 0.0.0.0 или на нужный вам. В моем случае я добавлю contextPath - /glowroot. И после на reverse proxy (в данном случае nginx), устанавливаем:
location /glowroot {
proxy_pass http://127.0.0.1:4000;
}
Дополнительно можете посмотреть на приложенную документацию Agent-Installation-(with-Embedded-Collector)Как результат, по нашему адресу jira.example.com/glowroot видит транзакции.
Первичные анализыСпустя некоторое время графики и сэмплы пополняются, как следствие инженер по исследованию узких мест начинает создавать множество задач. Например, о том, что интеграции медленные, и часть запросов идет синхронно или запросы дублируются. 
Чем больше система, тем неожиданнее сюрпризыПосредством glowroot было обнаружено, что при каждом изменении задачи в проекте с количеством пользователей более 30000, при проверке прав создавались временные таблицы на стороны СУБД. Ниже представлен trace, который это демонстрирует.Как результат, создаются временные таблицы на стороне СУБД PostgreSQL, а на кластере PostgreSQL эта активность сильно влияет на производительность в связи с высоким показателем IOPS.
glowroot в делеВозникал вопрос — почему кэширование на стороне приложения Jira не отрабатывало, ведь согласно thread dump информации показывает, что существует кэширование объектов.
Согласно stacktrace из трассированого запроса был видно, что реализация кэширования выполнена абсолютно удобно.
кусок трейсаПри изучении stacktrace было обнаружено, что метод createTemporaryTablesIfNeeded влиял на эту деградацию по производительности. И нижеприведенный пулл реквест изменил поведение приложения, https://bitbucket.org/atlassian/entity-engine/pull-requests/32/stable-issue-stable-issue-raid-438-in/diff, как следствие мы столкнулись с этой проблемой на большой инсталляции.
так и нашли ограниченияПричиной изменения было ограничение неправильно настроенных проектов и ограничение действительно больших проектов. Так что данное решение является довольно прагматичным решением в программной инженерии.В качестве выводаКак мы видим из примера изменения в entity engine, вендор также беспокоится за продукт и с удовольствием принимает запросы на улучшение, если это относится к его компоненте. А решили мы свои проблемы пересборкой компоненты под наши реалии, не дожидаясь правильного и официального фикса. Фактически у нас были следующие варианты по устранению поведения приложения для большого количества пользователей:
- Изменить константу и пересобрать компонент
- Изменить схему прав безопасности на уровне приложения и провести очистку и полное ревью
- Переделать на unlogged таблицу cwd_users в PostgreSQL
Подскажите,сталкивались ли вы подобными ситуация и как решали? Особенно, интересны ситуации, связанные с поиском узких мест в системе посредством инструментов по анализу производительности? Как много времени потратили на установку, настройку инструментов и выявление проблем? Буду рад вашим вопросам, а также можно задавать Atlassian сообществе в Телеграм.Хорошего дня, Гончик.Ссылки
- https://glowroot.org/
- Admin monitoring tools
- Расширенная презентация с TechFest with Ontico
- openapm.io/landscape
===========
Источник:
habr.com
===========
Похожие новости:
- [Системное администрирование, IT-инфраструктура, Алгоритмы, Бизнес-модели] Доступность ИТ-сервисов как ключевой бизнес показатель, и причем тут арбуз
- [Big Data, Квантовые технологии] Что такое квантовые фонды и почему в них уходят лучшие разработчики?
- [IT-инфраструктура, Управление проектами, Инженерные системы] Мониторинг в ЦОДе: как мы меняли старую BMS на новую. Часть 4
- [C++, C, C#] Алгоритмы аллокации памяти, автономное зрение и специфика работы в модели Software House
- [Информационная безопасность, Софт] Мониторинг атак
- [Системное администрирование, Kubernetes] 29 апреля состоится Online Monitoring Meetup, Kubernetes: мониторинг c помощью Prometheus
- [IT-инфраструктура, Big Data, Исследования и прогнозы в IT, Интернет вещей, Data Engineering] Почему мониторинг простоев тянет бизнес на дно?
- [Управление продуктом, Управление персоналом, IT-компании, Удалённая работа] Один год удалённой работы в Figma (перевод)
- [Управление разработкой, Управление проектами, Управление продуктом] Нет Jira — нет проблемы (перевод)
- [Информационная безопасность, Софт] Мониторинг эксплойтов
Теги для поиска: #_atlassian, #_atlassian, #_apm, #_monitoring (мониторинг), #_jira, #_blog_kompanii_luxoft (
Блог компании Luxoft
), #_atlassian
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 01:44
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
В настоящей статье расскажу историю о том, как можно столкнуться с довольно простой проблемой на больших инсталляциях продуктов компании Atlassian, в частности на Jira. Методы анализа и поиска узких мест:
 графикВ качестве отправной точки использовался сайт https://openapm.io/landscape, который собрал практически все актуальные APM-инструменты. После проведения сравнительного анализа мы остановили выбор на инструменте Glowroot, который удовлетворял всем критериям.Установка Установка приложения довольно простая на агентах, и в данной статье показана схема работы со встроенным коллектором, но для промышленных инсталляций используется Cassandra (как представлено на диаграмме) со связкой с Elasticsearch. 
wget -c https://github.com/glowroot/glowroot/releases/download/v0.13.6/glowroot-0.13.6-dist.zip
chown -R jira: /jira/home/glowroot
JVM_SUPPORT_RECOMMENDED_ARGS="-javaagent:/jira/glowroot/glowroot.jar ${JVM_SUPPORT_RECOMMENDED_ARGS}"
systemctl restart jira
tail -f {jira_installation_directory}/logs/catalina.out
location /glowroot {
proxy_pass http://127.0.0.1:4000; }  Первичные анализыСпустя некоторое время графики и сэмплы пополняются, как следствие инженер по исследованию узких мест начинает создавать множество задач. Например, о том, что интеграции медленные, и часть запросов идет синхронно или запросы дублируются.  Чем больше система, тем неожиданнее сюрпризыПосредством glowroot было обнаружено, что при каждом изменении задачи в проекте с количеством пользователей более 30000, при проверке прав создавались временные таблицы на стороны СУБД. Ниже представлен trace, который это демонстрирует.Как результат, создаются временные таблицы на стороне СУБД PostgreSQL, а на кластере PostgreSQL эта активность сильно влияет на производительность в связи с высоким показателем IOPS.  glowroot в делеВозникал вопрос — почему кэширование на стороне приложения Jira не отрабатывало, ведь согласно thread dump информации показывает, что существует кэширование объектов.  Согласно stacktrace из трассированого запроса был видно, что реализация кэширования выполнена абсолютно удобно.  кусок трейсаПри изучении stacktrace было обнаружено, что метод createTemporaryTablesIfNeeded влиял на эту деградацию по производительности. И нижеприведенный пулл реквест изменил поведение приложения, https://bitbucket.org/atlassian/entity-engine/pull-requests/32/stable-issue-stable-issue-raid-438-in/diff, как следствие мы столкнулись с этой проблемой на большой инсталляции.  так и нашли ограниченияПричиной изменения было ограничение неправильно настроенных проектов и ограничение действительно больших проектов. Так что данное решение является довольно прагматичным решением в программной инженерии.В качестве выводаКак мы видим из примера изменения в entity engine, вендор также беспокоится за продукт и с удовольствием принимает запросы на улучшение, если это относится к его компоненте. А решили мы свои проблемы пересборкой компоненты под наши реалии, не дожидаясь правильного и официального фикса. Фактически у нас были следующие варианты по устранению поведения приложения для большого количества пользователей:
=========== Источник: habr.com =========== Похожие новости:
Блог компании Luxoft ), #_atlassian |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 01:44
Часовой пояс: UTC + 5