[Open source, Программирование, Отладка, Реверс-инжиниринг] Обратная отладка в большом масштабе (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Отладка — неотъемлемая часть профессионального программирования. К старту курса о Fullstack-разработке на Python делимся переводом о том, как отладка устроена в Facebook; в статье вы найдёте ссылку на разработанный FB плагин трассировки для LLDB, который преобразует необработанную трассировку в удобочитаемый формат.Допустим, вы получаете уведомление по электронной почте о том, что сервис терпит крах сразу после развёртывания вашего последнего изменения кода. Сбой происходит только на 0,1 % серверов, где запущен сервис. Но вы работаете в крупной компании, поэтому 0,1 % равняется тысячам серверов, и эту проблему будет трудно воспроизвести. Несколько часов спустя вы всё ещё не можете воспроизвести проблему, хотя потратили целый день на её решение.Здесь вступает в действие обратная отладка. Существующие методы позволяют инженерам записывать приостановленную (или потерпевшую крах) программу, затем перематывать её назад и воспроизводить, чтобы найти первопричину. Однако для таких крупных компаний, как Facebook, эти решения требуют слишком больших накладных расходов, чтобы быть практичными в производственной среде. Для решения этой проблемы мы разработали новую методику, позволяющую инженерам отследить неудачный запуск и просмотреть его историю, чтобы найти первопричину без необходимости повторного запуска программы, что экономит огромное количество времени. Для этого мы эффективно отслеживаем активность CPU на наших серверах и при сбоях сохраняем историю процессов, которая затем отображается в удобочитаемом формате с помощью отладчика LLDB, предлагающего всё — от просмотра истории команд до реверс-дебага.Звучит здорово, но как это работает?Для разработки мы использовали Intel Processor Trace (Intel PT), который использует специализированное оборудование для ускорения сбора шагов в программе, что позволяет нам использовать его в производстве и в масштабе. Однако эффективная трассировка программы — это только первый шаг.Непрерывный сбор и быстрое хранилище в производственной средеПоскольку мы не знаем, когда произойдёт сбой и какой именно процесс потерпит крах, нам необходимо постоянно собирать трассировку Intel PT всех запущенных процессов. Чтобы ограничить объём памяти, необходимой для работы, мы храним трассировку в кольцевом буфере, где новые данные перезаписывают старые:
Когда несколько процессов (A и B) выполняются одновременно, данные трассировки хранятся в буфере. В t+8 данные процесса B начинают перезаписывать самые старые данные (данные процесса A) в буфере.На больших серверах, наподобных тем, чтоприменяютсядля обучениямоделей ИИ, Intel PT может генерировать сотни мегабайт данных в секунду даже в сжатом формате. Когда процесс терпит крах, сборщик должен приостановить сбор и скопировать содержимое буфера для потерпевшего крах процесса. Для этого операционная система должна уведомить нашего сборщика о крахе процесса, на что требуется время. Чем больше задержка между крахом и копированием содержимого буфера, тем больше данных будет перезаписано новыми данными из других процессов.Чтобы решить эту проблему, мы разработали eBPF-зонд ядра — программу, запускаемую при определённых событиях ядра, чтобы в течение нескольких миллисекунд уведомить нашего сборщика о том, что произошёл сбой, таким образом максимизируя количество информации в трассировке, относящейся к сбою. Мы попробовали несколько подходов, но ни один из них не был таким быстрым, как этот. Дополнительно в рахитектуре учтено, что при сбоях компьютер часто остаётся в плохом состоянии, а это не позволяет нам проводить какой-либо анализ собранной трассировки на лету. Поэтому мы решили хранить трассировки и соответствующие двоичные файлы потерпевших крах процессов в наших центрах обработки данных, чтобы их можно было проанализировать позже на другой машине.Декодирование и символизацияКак преобразовать эти данные в инструкции, которые возможно проанализировать? Необработанные трассировки не поддаются расшифровке инженерами. Людям необходим контекст, такой как информация об исходной строке и имена функций. Чтобы добавить контекст, мы создали компонент в LLDB, способный получать трассировку и восстанавливать инструкции вместе с их символами. Недавно мы начали открытое исходного кода этой работы. Найти компонент вы можете здесь.
Трассировка в первую очередь содержит информацию о том, какие ветки были захвачены, а какие — нет. Мы сравниваем эту информацию со всеми инструкциями из исходного двоичного файла и восстанавливаем инструкции, которые были выполнены программой. Позже с помощью стека символизации LLDB мы можем получить соответствующую информацию об исходном коде и показать её инженеру в удобочитаемом виде.С помощью указанного на рисунке выше потока мы можем преобразовать необработанный файл трассировки в такой:
Символизация инструкций — это только первая часть работы LLDB. Следующая часть — реконструкция истории вызовов функций. Для этого мы построили алгоритм, который способен пройти по инструкциям и построить дерево вызовов функций, то есть какая функция вызвала другую функцию и когда. Самое интересное в этом то, что трассировка может начинаться в произвольный момент выполнения программы, и не обязательно с самого начала.
Часть дерева вызовов функций, где каждый вертикальный сегмент содержит инструкции, а места вызова отображаются стрелками.Это дерево может помочь нам быстро ответить на вопрос, например, о том, какова трассировка стека в данный момент истории; вопрос решается простым движением вверх по дереву. С другой стороны, более сложный вопрос — где останавливается обратный шаг с обходом?Представьте, что вы находитесь в строке 16 этого небольшого куска кода. При обратном шаге с обходом вы должны остановиться либо на строке 13, либо на строке 15, в зависимости от того, было ли захвачено if или нет. Наивный подход заключается в том, чтобы проверять инструкции в истории по одной, пока не будет найдена одна из этих строк, но это может быть очень неэффективно, так как функция foo может содержать миллионы инструкций. Вместо этого можно воспользоваться вышеупомянутым деревом, чтобы перемещаться по строкам, не перемещаясь внутри вызовов. В отличие от предыдущего подхода обход дерева почти тривиален.
Кроме того, добавлена поддержка точек останова. Предположим, что вы находитесь в середине сеанса отладки и хотите вернуться назад во времени к последнему вызову function_a. Вот что можно сделать:
Наконец, мы планируем в какой-то момент интегрировать этот поток с VSCode, чтобы получить богатый опыт визуальной обратной отладки.Анализ и профилирование задержекТрассировка выполнения содержит больше информации, чем другие представления потока управления, например стеки вызовов. Кроме того, в рамках трассировки мы собираем информацию о времени с высокой точностью; так, инженеры знают не только последовательность выполняемых операций (или функций), но и их временные метки, а это позволяет задействовать новую возможность — анализ задержек.Представьте себе сервис, который обрабатывает различные запросы, получающие данные с использованием внутреннего кеша. При определённых условиях кеш должен быть очищен, и следующий вызов fetch займёт гораздо больше времени.Сервер получает несколько запросов от инженеров, и вы хотите разобраться с длинным хвостом задержки в вашем сервисе (например, P99). Вы берёте свой профайлер и собираете несколько выборок стеков вызовов для двух основных типов запросов. Они выглядят, как на графике ниже, который не позволяет понять, чем они отличаются, поскольку выборка стека вызовов показывает только агрегированные цифры. Нам нужно преобразовать трассировки в информацию о пути выполнения и на этом пути символизировать инструкции.
На изображении ниже показана трассировка, позволяющая легко понять происходящее: запрос B очищает данные перед их получением.
Тогда как отладчик может помочь вам двигаться в пределах трассировки по шагам, визуализация поможет вам легко увидеть общую картину. Вот почему мы также работаем над добавлением графиков, подобных графику "Трассировка стека вызовов" выше, в наш инструмент анализа производительности Tracery. Мы создаём инструмент, который может производить эту трассировку и временные данные и объединять их с производимой LLDB символизацией. Наша цель — предложить разработчикам способ увидеть всю эту информацию сразу, а затем увеличить или уменьшить масштаб и получить необходимые данные на нужном им уровне.Помните нежелательный сценарий в начале этого поста? Теперь представьте, что вы получаете уведомление по электронной почте о том, что ваш сервис падает на 0,1 % машин, но на этот раз оно приходит с кнопкой "Reverse debug on VSCode". Вы нажимаете на кнопку, а затем перемещаетесь по истории программы, пока не найдёте вызов функции, который не должен был произойти, или ветку if, которая не должна была выполняться, и исправляете её в течение нескольких минут.Такие технологии позволяют нам решать проблемы на уровне, который мы раньше не считали возможным. Большинство наших работ (если судить по истории) в этой области привели к значительным накладным расходам, что ограничивало наши возможности масштабироваться. Сейчас мы создаём инструменты отладки, которые интерактивно и наглядно помогают разработчикам решать проблемы производства и разработки гораздо более эффективным способом. Это захватывающее начинание, которое поможет нам ещё больше расширить наши масштабы.
Узнайте, как прокачаться и в других специальностях или освоить их с нуля:
Другие профессии и курсыПРОФЕССИИ
- Профессия Fullstack-разработчик на Python
- Профессия Java-разработчик
- Профессия QA-инженер на JAVA
- Профессия Frontend-разработчик
- Профессия Этичный хакер
- Профессия C++ разработчик
- Профессия Разработчик игр на Unity
- Профессия Веб-разработчик
- Профессия iOS-разработчик с нуля
- Профессия Android-разработчик с нуля
КУРСЫ
- Курс по Machine Learning
- Курс "Machine Learning и Deep Learning"
- Курс "Математика для Data Science"
- Курс "Математика и Machine Learning для Data Science"
- Курс "Python для веб-разработки"
- Курс "Алгоритмы и структуры данных"
- Курс по аналитике данных
- Курс по DevOps
===========
Источник:
habr.com
===========
===========
Автор оригинала: Walter Erquinigo, David Carrillo-Cisneros, Alston Tang
===========Похожие новости:
- [Программирование микроконтроллеров, Производство и разработка электроники] HK32F030C8T6 全功能克隆(полный функциональный клон) STM32F030C8T6
- [Информационная безопасность, Программирование, C++] Грехи C++ (перевод)
- [Open source, PostgreSQL] pgSCV — экспортер метрик для PostgreSQL
- [Программирование, Работа с 3D-графикой, Алгоритмы, Визуализация данных] Майнкрафт для геологов: 3D-рендеринг миллиарда ячеек на встроенной видеокарте (часть 2)
- [Программирование, Машинное обучение] SberCloud + Intel oneAPI = бесплатное облако для ML-разработчиков
- [Open source, Программирование, C++] Развитие проекта arataga: пара рефакторингов по результатам натурных испытаний
- [Читальный зал, Научно-популярное, Физика, Астрономия] Почему для чёрных дыр 28 + 47 = 72, а не 75 (перевод)
- [Веб-дизайн, Habr, JavaScript, Программирование, HTML] Косяк колхозной простоты в коде веб-сайта Хабра
- [Python, Программирование, Google App Engine] Как использовать GraphQL Federation для инкрементальной миграции с монолита (Python) на микросервисы (Go) (перевод)
- [Программирование, Разработка мобильных приложений, Тестирование мобильных приложений] Особенности тестирования Android без Google-сервисов
Теги для поиска: #_open_source, #_programmirovanie (Программирование), #_otladka (Отладка), #_reversinzhiniring (Реверс-инжиниринг), #_skillfactory, #_otladka (отладка), #_debag (дебаг), #_programmirovanie (программирование), #_obratnaja_otladka (обратная отладка), #_lldb, #_simvolizatsija (символизация), #_open_source, #_reversdebag (реверс-дебаг), #_tracery, #_blog_kompanii_skillfactory (
Блог компании SkillFactory
), #_open_source, #_programmirovanie (
Программирование
), #_otladka (
Отладка
), #_reversinzhiniring (
Реверс-инжиниринг
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 24-Ноя 11:34
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Отладка — неотъемлемая часть профессионального программирования. К старту курса о Fullstack-разработке на Python делимся переводом о том, как отладка устроена в Facebook; в статье вы найдёте ссылку на разработанный FB плагин трассировки для LLDB, который преобразует необработанную трассировку в удобочитаемый формат.Допустим, вы получаете уведомление по электронной почте о том, что сервис терпит крах сразу после развёртывания вашего последнего изменения кода. Сбой происходит только на 0,1 % серверов, где запущен сервис. Но вы работаете в крупной компании, поэтому 0,1 % равняется тысячам серверов, и эту проблему будет трудно воспроизвести. Несколько часов спустя вы всё ещё не можете воспроизвести проблему, хотя потратили целый день на её решение.Здесь вступает в действие обратная отладка. Существующие методы позволяют инженерам записывать приостановленную (или потерпевшую крах) программу, затем перематывать её назад и воспроизводить, чтобы найти первопричину. Однако для таких крупных компаний, как Facebook, эти решения требуют слишком больших накладных расходов, чтобы быть практичными в производственной среде. Для решения этой проблемы мы разработали новую методику, позволяющую инженерам отследить неудачный запуск и просмотреть его историю, чтобы найти первопричину без необходимости повторного запуска программы, что экономит огромное количество времени. Для этого мы эффективно отслеживаем активность CPU на наших серверах и при сбоях сохраняем историю процессов, которая затем отображается в удобочитаемом формате с помощью отладчика LLDB, предлагающего всё — от просмотра истории команд до реверс-дебага.Звучит здорово, но как это работает?Для разработки мы использовали Intel Processor Trace (Intel PT), который использует специализированное оборудование для ускорения сбора шагов в программе, что позволяет нам использовать его в производстве и в масштабе. Однако эффективная трассировка программы — это только первый шаг.Непрерывный сбор и быстрое хранилище в производственной средеПоскольку мы не знаем, когда произойдёт сбой и какой именно процесс потерпит крах, нам необходимо постоянно собирать трассировку Intel PT всех запущенных процессов. Чтобы ограничить объём памяти, необходимой для работы, мы храним трассировку в кольцевом буфере, где новые данные перезаписывают старые:  Когда несколько процессов (A и B) выполняются одновременно, данные трассировки хранятся в буфере. В t+8 данные процесса B начинают перезаписывать самые старые данные (данные процесса A) в буфере.На больших серверах, наподобных тем, чтоприменяютсядля обучениямоделей ИИ, Intel PT может генерировать сотни мегабайт данных в секунду даже в сжатом формате. Когда процесс терпит крах, сборщик должен приостановить сбор и скопировать содержимое буфера для потерпевшего крах процесса. Для этого операционная система должна уведомить нашего сборщика о крахе процесса, на что требуется время. Чем больше задержка между крахом и копированием содержимого буфера, тем больше данных будет перезаписано новыми данными из других процессов.Чтобы решить эту проблему, мы разработали eBPF-зонд ядра — программу, запускаемую при определённых событиях ядра, чтобы в течение нескольких миллисекунд уведомить нашего сборщика о том, что произошёл сбой, таким образом максимизируя количество информации в трассировке, относящейся к сбою. Мы попробовали несколько подходов, но ни один из них не был таким быстрым, как этот. Дополнительно в рахитектуре учтено, что при сбоях компьютер часто остаётся в плохом состоянии, а это не позволяет нам проводить какой-либо анализ собранной трассировки на лету. Поэтому мы решили хранить трассировки и соответствующие двоичные файлы потерпевших крах процессов в наших центрах обработки данных, чтобы их можно было проанализировать позже на другой машине.Декодирование и символизацияКак преобразовать эти данные в инструкции, которые возможно проанализировать? Необработанные трассировки не поддаются расшифровке инженерами. Людям необходим контекст, такой как информация об исходной строке и имена функций. Чтобы добавить контекст, мы создали компонент в LLDB, способный получать трассировку и восстанавливать инструкции вместе с их символами. Недавно мы начали открытое исходного кода этой работы. Найти компонент вы можете здесь.  Трассировка в первую очередь содержит информацию о том, какие ветки были захвачены, а какие — нет. Мы сравниваем эту информацию со всеми инструкциями из исходного двоичного файла и восстанавливаем инструкции, которые были выполнены программой. Позже с помощью стека символизации LLDB мы можем получить соответствующую информацию об исходном коде и показать её инженеру в удобочитаемом виде.С помощью указанного на рисунке выше потока мы можем преобразовать необработанный файл трассировки в такой:  Символизация инструкций — это только первая часть работы LLDB. Следующая часть — реконструкция истории вызовов функций. Для этого мы построили алгоритм, который способен пройти по инструкциям и построить дерево вызовов функций, то есть какая функция вызвала другую функцию и когда. Самое интересное в этом то, что трассировка может начинаться в произвольный момент выполнения программы, и не обязательно с самого начала.  Часть дерева вызовов функций, где каждый вертикальный сегмент содержит инструкции, а места вызова отображаются стрелками.Это дерево может помочь нам быстро ответить на вопрос, например, о том, какова трассировка стека в данный момент истории; вопрос решается простым движением вверх по дереву. С другой стороны, более сложный вопрос — где останавливается обратный шаг с обходом?Представьте, что вы находитесь в строке 16 этого небольшого куска кода. При обратном шаге с обходом вы должны остановиться либо на строке 13, либо на строке 15, в зависимости от того, было ли захвачено if или нет. Наивный подход заключается в том, чтобы проверять инструкции в истории по одной, пока не будет найдена одна из этих строк, но это может быть очень неэффективно, так как функция foo может содержать миллионы инструкций. Вместо этого можно воспользоваться вышеупомянутым деревом, чтобы перемещаться по строкам, не перемещаясь внутри вызовов. В отличие от предыдущего подхода обход дерева почти тривиален.  Кроме того, добавлена поддержка точек останова. Предположим, что вы находитесь в середине сеанса отладки и хотите вернуться назад во времени к последнему вызову function_a. Вот что можно сделать:  Наконец, мы планируем в какой-то момент интегрировать этот поток с VSCode, чтобы получить богатый опыт визуальной обратной отладки.Анализ и профилирование задержекТрассировка выполнения содержит больше информации, чем другие представления потока управления, например стеки вызовов. Кроме того, в рамках трассировки мы собираем информацию о времени с высокой точностью; так, инженеры знают не только последовательность выполняемых операций (или функций), но и их временные метки, а это позволяет задействовать новую возможность — анализ задержек.Представьте себе сервис, который обрабатывает различные запросы, получающие данные с использованием внутреннего кеша. При определённых условиях кеш должен быть очищен, и следующий вызов fetch займёт гораздо больше времени.Сервер получает несколько запросов от инженеров, и вы хотите разобраться с длинным хвостом задержки в вашем сервисе (например, P99). Вы берёте свой профайлер и собираете несколько выборок стеков вызовов для двух основных типов запросов. Они выглядят, как на графике ниже, который не позволяет понять, чем они отличаются, поскольку выборка стека вызовов показывает только агрегированные цифры. Нам нужно преобразовать трассировки в информацию о пути выполнения и на этом пути символизировать инструкции.  На изображении ниже показана трассировка, позволяющая легко понять происходящее: запрос B очищает данные перед их получением.  Тогда как отладчик может помочь вам двигаться в пределах трассировки по шагам, визуализация поможет вам легко увидеть общую картину. Вот почему мы также работаем над добавлением графиков, подобных графику "Трассировка стека вызовов" выше, в наш инструмент анализа производительности Tracery. Мы создаём инструмент, который может производить эту трассировку и временные данные и объединять их с производимой LLDB символизацией. Наша цель — предложить разработчикам способ увидеть всю эту информацию сразу, а затем увеличить или уменьшить масштаб и получить необходимые данные на нужном им уровне.Помните нежелательный сценарий в начале этого поста? Теперь представьте, что вы получаете уведомление по электронной почте о том, что ваш сервис падает на 0,1 % машин, но на этот раз оно приходит с кнопкой "Reverse debug on VSCode". Вы нажимаете на кнопку, а затем перемещаетесь по истории программы, пока не найдёте вызов функции, который не должен был произойти, или ветку if, которая не должна была выполняться, и исправляете её в течение нескольких минут.Такие технологии позволяют нам решать проблемы на уровне, который мы раньше не считали возможным. Большинство наших работ (если судить по истории) в этой области привели к значительным накладным расходам, что ограничивало наши возможности масштабироваться. Сейчас мы создаём инструменты отладки, которые интерактивно и наглядно помогают разработчикам решать проблемы производства и разработки гораздо более эффективным способом. Это захватывающее начинание, которое поможет нам ещё больше расширить наши масштабы.  Узнайте, как прокачаться и в других специальностях или освоить их с нуля: Другие профессии и курсыПРОФЕССИИ
=========== Источник: habr.com =========== =========== Автор оригинала: Walter Erquinigo, David Carrillo-Cisneros, Alston Tang ===========Похожие новости:
Блог компании SkillFactory ), #_open_source, #_programmirovanie ( Программирование ), #_otladka ( Отладка ), #_reversinzhiniring ( Реверс-инжиниринг ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 24-Ноя 11:34
Часовой пояс: UTC + 5