- PVSM.RU - https://www.pvsm.ru -
В прошлой статье мы рассказали о созданной нами системе под названием ULA [1] (Unified Logfile Analyser) — анализаторе, основными функциями которого являются сбор и агрегация входящих сообщений об ошибках c использованием алгоритма shingles, принятие решений по ним и автоматическая нотификация при проблемах с тестовой средой. Сегодня мы поделимся практикой обнаружения/решения багов раскатки этой системы и нашими планами.
На текущий момент мы подключили к системе чуть менее половины запланированных проектов. Почему не все? Может, сотрудники получили недостаточно информации, может, просто не поверили в продукт — как оказалось, просто рассказать о продукте менеджерам и устроить несколько презентаций недостаточно. В проектной среде, где участвовали разработчики из числа создателей ULA, успехи были выше, и внедрение в начале проходило без особых усилий.
Внедряли ULA через встречи с руководством и тестировщиками. Рассказывали про систему на презентациях, демонстрировали основные функции. После нескольких таких сессий с разработчиками автотестов ЕФС постепенно начали поступать заявки на подключение. Пожалуй, удалось бы стартовать лучше, если бы мы анонсировали инструмент заранее, чтобы пользователи ждали релиз.
Стандартные вопросы, которые нам задавали:
— Ваша система конкурирует с HP ALM?
Возможно, в будущем, в части сбора метрик по автоматизированному тестированию.
— Ваша система умеет агрегировать логи самих систем ЕФС?
На данный момент нет, но в будущем анализ логов самих систем мы внедрим. Пока эти данные собираются и прикрепляются к тестам в виде дополнительной информации.
— Почему не стек ELK (Elastic Search, Log Stash, Kibana)?
Нам требуется более сложная логика обработки, функционал принятия решений, интеграция с HP SM, HP ALM, возможность работать с исходными данными целенаправленно по нужному запросу, т.е. не нужен постоянный поток данных из логов систем.
— А кто будет пользоваться системой?
Здесь все неоднозначно. Подразумевалось, что разбором ошибок должна заниматься команда инженеров, которая проводит в основном ручное тестирование и анализирует автотесты. Но так происходит не всегда: в совсем новых проектах разбором часто занимаются разработчики автотестов или другие инженеры. Поэтому сейчас нам важно четко понимать ситуацию по каждому проекту, определить тех, кого требуется обучить работе с системой.
Теперь о проблемах, с которыми мы столкнулись после подключения нескольких проектов ЕФС.
Основная проблема, которая потребовала изменения базового алгоритма, — наличие однотипных stack trace в логах, которые пишут автотесты. Для ряда тестов используется TestNG, и при ошибке ребята пишут в лог полный trace, который генерит фреймворк. В результате до 80% длины сообщения об ошибке становятся схожи. Нужно было что-то с этим делать. И достаточно срочно. Обрезать часть лога и совершенно его не обрабатывать было бы в корне неверно. Поэтому было решено ввести веса shingles, т.е. ввести веса канонизированным, очищенным от «мусора» словосочетаниям. Такого подхода в классическом алгоритме нет.
В будущем, когда наберется достаточно статистических данных, мы выведем необходимый полином для определения весов. Пока при просмотре нескольких сотен сообщений было решено использовать немного скорректированную функцию арккотангенса. Основную значимость принимают первые 20 — 30 слов сообщения, затем начинается небольшой спад (начало стек-трейса). Хвост trace имеет наименьшую значимость. Возможно, в будущем придется вводить зависимость параметров алгоритма от тестируемой подсистемы и используемого фреймворка.
Хотя при разработке системы нагрузочное тестирование проводилось на каждом спринте, это не помогло нам избежать ряда проблем с производительностью при подключении реальных проектов. Мы столкнулись с тем, что:
Бывает, что в очередь попадает до 200 сообщений в секунду, и они начинают скапливаться. В итоге все, конечно, обрабатывается без критических ситуаций, но занятый на 100% процессор влияет на работу WEB-сервисов. Вот что мы пока сделали для решения проблем с производительностью:
Тем не менее, вопрос производительности до конца не решен, команда продолжает работу.
Разбор очереди Oracle AQ происходит процедурой, которая связана с подписчиком. СУБД управляет многопоточностью, но при большой нагрузке мы столкнулись с проблемой.
Дело в том, что необходимо вести счетчики входящих в систему сообщений (одно сообщение для нас — это запись о шаге теста). Счетчики сгруппированы по уникальным ID запусков. Это необходимо для того, чтобы сравнить количество входящих сообщений с ожидаемым и понять, завершен ли запуск, построить дерево тестов и вывести таблицу агрегированных ошибок. Без элементов синхронизации потоков такой счетчик ввести невозможно. Сперва мы изобрели «велосипед» и сделали таблицу MUTEX, которую блокировали на доли секунды на время расчета значения счетчика. Под большой нагрузкой стали ловить dead block. Потом воспользовались пакетом DBMS_LOCK и создали блокировку куска кода, который работал со счетчиком. Долго не могли понять, почему иногда счетчик показывал некорректное значение, но в итоге проблему синхронизации решили. Для интересующихся, рекомендуем почитать эту статью [2] о подводных камнях блокировок.
Мы позиционируем систему как универсальную: достаточно написать для нее свой парсер отчетов автотестов. Но на деле для того же Allure это оказалось сделать достаточно сложно. Дело в том, что одно и то же можно записать в отчете по-разному, общих правил у нас нет. В итоге на протяжении двух недель постоянно приходилось проводить доработки и, скорее всего, это еще не конец. Мы даже влезли в код самого Allure, но об этом чуть позже.
Первая проблема Allure, с которой мы столкнулись, — различие адаптеров для разных фреймворков. Это не специфика наших автотестов, а обычная практика. Лейблы testClass и testMethod, с помощью которых происходило определение теста, принадлежали к feature testNG адаптеру, а другие адаптеры по умолчанию их не предоставляли. Добавить 2 лейбла оказалось несложно, так как модель (AllureModelUtils) располагала этими методами:
public static Label createTestClassLabel(String testClass) {
return createLabel(LabelName.TEST_CLASS, testClass);
}
public static Label createTestMethodLabel(String testMethod) {
return createLabel(LabelName.TEST_METHOD, testMethod);
}
Было решено не переписывать логику парсера, а сделать свой листенер, в котором были бы добавлены два этих лейбла.
Вторая проблема, с которой мы столкнулись, — testNG. Адаптер создает отдельные тесты для before [3] методов, если во время их исполнения произошла ошибка. Сами тесты при этом переходят в статус cancelled. Таким образом мы получали дубли тестов в нашей системе.
Исправление этой особенности Allure было помечено в RoadMap Allure 2.0, но большинство проектов до сих пор использовало версию 1.5 или даже ниже. Наш парсер в первую очередь был написан для этих версий. Ждать мы не могли, поэтому снова пошли путем исправления листенера.
При проектировании мы выбрали React JS и сделали акцент на работу в Google Chrome. Показали менеджменту, стали тестировать на других браузерах и выяснилось, что ничего толком не работает. В будущем нужно будет уделять проблеме мультибраузерности больше времени. На данный момент WEB часть системы работает в Google Chrome, Mozilla Firefox, MS IE последних версий.
Мы так увлеклись чужими логам, что забыли о своих. Они, конечно, были, но детализация оказалась недостаточной. Когда началась реальная эксплуатация и посыпались проблемы, нам пришлось потратить несколько дней, пройтись по всему функционалу и сделать нормальное логирование в самой системе. Логи пишутся при ошибках в разборе очередей, в вызываемых процедурах и в самих сервисах системы. Логируется каждое действие пользователя.
В целях ускорения вывода системы в продуктивную эксплуатацию для поиска нужных кусков логов в файловой системе на тестовых средах ЕФС был использован обычный bash. Написали скрипт, который проходит по директориям, распаковывает нужные файлы, ищет там вхождения для переданной на вход сессии и записывает промежуточные результаты во временный файл (достаточно крупный). В последнем действии и заключалась ошибка. Такое решение оказалось однопоточным и неприемлемым для нас. В данный момент мы переписали почти весь функционал на Java, а промежуточные результаты целиком хранятся в памяти.
В ближайшее время мы планируем:
Несмотря на все баги, мы полны оптимизма и верим, что разработка поможет инженерам существенно сократить время на разбор результатов и повысит качество анализа. На текущий момент у нас накопился объемный бэклог, реализация которого даст нам новый интересный опыт и сделает продукт лучше. Будем рады ответить на ваши вопросы по теме, узнать о вашей практике и кейсах.
Автор: EFS_programm
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/administrirovanie-baz-danny-h/268033
Ссылки в тексте:
[1] ULA: https://habrahabr.ru/company/efs/blog/338164/
[2] статью: http://bluefrog-oracle.blogspot.ru/2013/12/user-defined-locking-with-dbmslock.html
[3] before: https://habrahabr.ru/users/before/
[4] Источник: https://habrahabr.ru/post/342112/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.