Кирилл Черятов. Эволюция системы логирования интеграционного ПО. Сокращаем время сбора и анализа логов в 9 раз
•Télécharger en tant que PPTX, PDF•
0 j'aime•393 vues
Автоматизация бизнес-процессов часто подразумевает интеграцию большого количества IT систем. При производстве такого ПО серьезной проблемой является сбор и анализ логов систем. Эта проблема актуальная и для системы FORIS, которая поддерживает бизнес МТС. Мы разберем проблемы, которые подтолкнули к разработке системы Central Logging, обозначим решение этих проблем, узнаем, какое отношение имеет игра пинг-понг к разработке программного обеспечения, а так же, как Central Logging помогла нам меньше играть в пинг-понг и больше времени тратить на разработку новых задач для заказчика.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (14)
Similaire à Кирилл Черятов. Эволюция системы логирования интеграционного ПО. Сокращаем время сбора и анализа логов в 9 раз
Similaire à Кирилл Черятов. Эволюция системы логирования интеграционного ПО. Сокращаем время сбора и анализа логов в 9 раз (20)
Plus de ScrumTrek
Plus de ScrumTrek (20)
Кирилл Черятов. Эволюция системы логирования интеграционного ПО. Сокращаем время сбора и анализа логов в 9 раз
- 1. Эволюция системы логирования интеграционного ПО. Сокращаем время сбора и анализа логов в 9 раз. Черятов Кирилл МТС ИТ kcheryatov@gmail.com
- 2. Проблемы. Сложность сбора логов. Логи сгруппированы по модулям/системам, а не по бизнес- процессам. В случае FORIS количество папок с логами ~ 300.
- 3. Проблемы. Сложность сбора логов. • Невозможно выделить логи, относящиеся к конкретному тестовому сценарию. • Для сбора логов нужно знать, какие модули вызываются при выполнении бизнес-процесса.
- 4. Проблемы. Пинг-понг багов. из письма 2013 года …Наблюдаю пинг-понг в подавляющем большинстве багов…
- 5. Этап 1. Пользовательская история. Я, как инженер группы тестирования, хочу собирать все необходимые разработке логи тестового сценария, не зная подробностей о реализации модулей.
- 6. Этап 1. Название системы. Central Logging
- 8. Этап 1. Реализация. Идентификатор сессии. Если сессия еще не создана, то она создается при первой попытке записи лога. Идентификатор сессии – GUID. Транспорт: WCF/Soap headers, BPM context, .net CallContext.
- 9. Этап 1. Реализация. Сбор логов. Для сбора логов разработан log4net appender, WCF служба для группировки, сжатия и записи логов. Хранилище логов - DB Oracle.
- 11. Этап 1. Реализация. Поиск логов. Для поиска логов разработано WPF приложение. Тиражируется с помощью ClickOnce.
- 12. Этап 1. Реализация. Поиск логов.
- 13. Этап 1. Реализация. Средства для анализа логов. Контекстный поиск, навигация по результатам поиска.
- 14. Этап 1. Внедрение. Внедрение проходило несколько этапов: • Proof на небольшой группе тестирования. • Отдали в эксплуатацию в аутсорсную команду тестирования (~30 человек). • CL – стал стандартным инструментом для поиска логов для большинства UC. В баге не приложены логи CL – баг возвращается в тестирование с просьбой приложить логи.
- 15. Этап 1. Результаты. • Термин «пинг-понг багов» безнадежно устарел и перестал употребляться. • Оценка сокращения временных затрат по результатам тестовой эксплуатации Название БП Поиск логов с CL Поиск логов без CL Смена ТП 5 30 Продажа контракта 5 45 ДУУ 5 15 Заказ документов 5 20 Расторжение контракта 5 25 Объединение ЛС 5 25
- 16. Сокращаем время сбора и анализа логов в 9 раз. Название БП c CL без CL Продажа контракта 5 45
- 17. Этап 1. Результаты. Затраты на 1 баг -30%. На один баг: Testing (Test) — 1 час Testing (Creation) — 15 мин сбор логов Integration (Localization) — 15 мин изучения стенда и логов 50% Testing (Add Logs) — 15 мин досбор других логов 50% Integration (Localization) — 15 мин изучения стенда и логов Dev Team 1 (Localization) — 15 мин изучение логов 30% Testing (Add Logs) — 15 мин сбор логов (если удалились, то ретест) Dev Team 1 (Localization) — 15 мин изучение логов 30% Dev Team 2 (Localization) — 15 мин изучение логов Testing (Retest + Add Logs) — 1 час на ретест (уже точно удалились) + сбор логов Dev Team 1 или 2 (Fix) — 2 часа на исправление Testing (Retest) – 1 час
- 18. Этап 2. Я, как инженер технической поддержки, тоже хочу иметь возможность собрать логи выполнения бизнес-процесса на продуктиве, без перенастройки модулей, рестарта служб, существенного увеличения нагрузки на сервер.
- 19. Этап 2. Отличия от этапа 1. Тестовый стенд: 1-30 серверов БЛ, несколько тысяч БП. Продуктив: 300 серверов БЛ, 50 млн. БП в сутки.
- 20. Этап 2. Идея. Модуль фильтрации логов
- 21. Этап 2. Реализация. Модуль фильтрации состоит из 3 элементов: • Метод, который применяет фильтры к логам. • Таймер, который периодически получает обновленные фильтры • Флаг «пиши логи», который передается аналогично идентификатору сессии, если сработал фильтр.
- 23. Этап 2. Реализация. Типы фильтров. • Логин оператора, • Временной интервал, • Тип бизнес-процесса, • Абонент
- 24. Этап 2. Внедрение. Система развернута и эксплуатируется на продуктиве. Для ряда интеграционных проблем CL позволяет ускорить локализацию на несколько дней.
- 25. Этап 3. Я, как разработчик, хочу в результатах запуска интеграционных автотестов видеть логи бизнес-процесса, который запускался в автотесте.
- 26. Этап 3. Идея. Позволяем помечать сессии атрибутами, реализуем службу, которая ищет сессии по заданным атрибутам.
- 28. Этап 3. Внедрение. О том, что в итоге получилось, чуть позже расскажет Павел Бирюков.
- 29. Этап 4. Я, как представитель разработки системы, которая интегрируется с FORIS, хочу получить возможность писать логи в CL.
- 31. Этап 4. Реализация. Добавили еще 1 интерфейс для записи логов в CL – RabbitMQ. (асинхронное взаимодействие, кроссплатформенный клиент) Как правило, взаимодействие между модулями происходит с помощью SOAP, поэтому идентификатор сессии передается стандартным образом.
- 32. Этап 4. Внедрение. Внедрено в рамках задачи интеграции с платформой SMBP (unix, c++, java) В процессе внедрения в online платформу SCP (unix, c++).
- 33. Подведем итоги. • Сократили календарь исправления бага за счет сокращения количества ретестов и сбора логов. • Сократили трудоемкость исправления бага ~30%. • Упростили сбор логов для ошибок на продуктиве.
Notes de l'éditeur
- Привет. Меня зовут. Я работаю в МТС ИТ. Сегодня мы поговорим о том, каким образом эволюционировала наша система сбора логов, для чего вообще потребовалась эволюция этой системы и какие бенефиты это принесло. Начнем с вопроса. Поднимите, пожалуйста руки, у кого в компании/системе есть проблема с сбором логов. Ну круто, что почти ни у кого нет проблем, если бы они были, мы бы наверно сейчас бы занимались их решением, а не участвовали в конференции). Супер, значит проблема не только в нашей системе, из моего рассказа вы сможете подчерпнуть идеи и решить схожие проблемы в своих система. Давайте вспомним схему модулей FORIS, которая была на слайде Павла: SOA архитектура, 50 модулей, бизнес-value создается с помощью интеграции модулей. Для логирования модули используют log4net. Логирование каждого модуля настраивается отдельно, часто для того, чтобы настройки применились, требуется рестарт служб модуля. Логи пишутся в файлы.
- Проблема в том, что основная сложность в интеграции и соответственно основные тестовые сценарии – интеграционные.
- Тут наверно стоит разбить на 4 слайда – группировка логов, выделение логов, относящихся к тестовому сценарию и знания о составе модулей в БД. Найти то, не знаю, что.
- Происходит это следующим образом: Команде приходит баг. В нем нет логов или нет нужных логов. Баг возвращается в тестирование с просьбой собрать логи. Между заведением бага и его обработкой на стороне разработки может пройти час или пара дней, логи за это время уже перетерлись (для некоторых стендов они складируются и тогда шансы остаются, для некоторых – нет). Это означает, что нужно заново подбирать тестовые данные и воспроизводить баг. Еще через несколько часов/дней баг возвращается с логами в разработку. Еще через несколько часов/дней разработка может перевести баг на другую команду с комментарием «Метод X не вернул данные, посмотрите, почему». Как вы уже догадались, логов модуля, в котором реализован метод, в баге не приложено. И так далее. Это не самый худший вариант, не всегда логи модуля можно однозначно ассоциировать с бизнес-процессом, тогда логи выбираются просто по времени, иногда с 10 серверов.
- Первым делом мы придумали, как наша система будет называться.
- Это не реклама чемодана. Все, кто летал на самолетах, знают, почему их багаж не теряется и оказывается (если оказывается) в нужный момент в нужном месте. И даже если багаж состоит из двух сумок, то с этим тоже не возникает проблем. Архитектура системы основана на двух идеях: Научиться генерировать и транслировать уникальный идентификатор сессии для всех типов взаимодействий в рамках БП. Научиться ассоциировать логи модулей с идентификатором бизнес-сессии.
- На предыдущем этапе Павел рассказал о жизненном цикле бага. CL позволил сjкратить затраты производства на исправление бага на 30%/
- … Сразу возникает вопрос, почему нельзя взять систему и использовать ее на продуктиве. Переход.
- Для не самого «пишущего» модуля Order Catalogue в сутки для логов потребуется 26 ТБ. Чтобы логировать все, потребуется: Существенно расширять КТС. Существенно перерабатывать архитектуру. Пересмотреть подходы к логированию в 40 модулях. Слишком дорого.
- Добавляем в CL фильтрующий модуль. Модуль будет выбирать, какие БП логировать, а какие – нет. Собираем логи в соответствии с заранее настроенными фильтрами. При этом алгоритм фильтрации должен быть простым и не влиять на производительность системы. Это поможет собрать логи для значимого количества проблем. Остальные проблемы дешевле воспроизвести на тестовых стендах.
- На стороне БЛ модуль фильтрации состоит из 3 элементов: Метод, который применяет фильтры к логам. Таймер, который периодически получает обновленные фильтры Заголовок «пиши логи», который передается аналогично идентификатору сессии, если сработал фильтр. Таким образом, фильтр настраивается на службу/форму, которая инициирует бизнес-сессию, остальные службы просто проверяют наличие заголовка.
- Данные фильтры позволяют собрать логи для большинства тестовых сценариев: запуск форм и БП от имени оператора (удаленный дилер, формы для call-центра), от имени абонента (интернет-помощник), либо предоставление API для внешних систем (в последнем случае фильтруем по типу БП, для которого предоставляется API, и абоненту, для которого осуществляется запуск API).
- Сначала включаем трассировку на нужном типе процесса, т.к. требуется согласовывать эти работы с заказчиком. Далее анализ силами ТП и разработки. Если дампа процесса не достаточно, но установили проблемную подсистему по дампу процесса, то еще согласование с заказчиком на включение логов на короткий период на этой подсистеме. Выполнение теста. Из-за невозможности снять все необходимые для анализа данные за один раз может растянуться на несколько дней.
- В данном случае речь идет о поддержке процесса автотестирования. Цель – позволить разработчику написать интеграционный тест и после выполнения теста не тратить время на сбор логов. После выполнения теста логи автоматически должны появляться в папке на диске программиста (для локального запуска) или в папке с результатами билда, если речь идет о запуске автотестов на DEV стенде.
- При запуске БП из автотеста в заголовке передается идентификатор теста, который сохраняется в CL. Последним шагом теста является вызов метода получения логов по идентификатору теста. Таким образом, после выполнения теста разработчик имеет доступ к логам выполнения бизнес-процессов, которые выполнялись в рамках данного конкретного теста. Для UI автотестов схема аналогична. Роль идентификатора играет IP тестового агента + время выполнения теста. На тестовых агентах тесты выполняются последовательно, поэтому этого достаточно для однозначной идентификации сессии CL.