Трэйсинг Go приложения

Transcript

1. Распределённый трэйсинг Go приложения Андреенко Артём CIO Prisma Labs
2. План доклада - О компании - О себе - Описание проблемы - Теория - Инструменты - Примеры кода
3. Prisma Labs https://prisma-ai.com - iPhone и Android приложение - Искусственный интеллект, который перерисовывает фото в другом стиле - Создано в 2016 году - 150M скачиваний
6. О себе - Занимаюсь бэкендом и инфраструктурой в Prisma Labs - Ведущий подкаста GolangShow https://golangshow.com - Продвигаю язык Go в русскоязычном сообществе http://slack.golang-ru.com
7. Проблема - Внешний мониторинг отображает только общее время работы запроса и их количество. Отсутствует понимание происходящих процессов внутри компонентов приложения
8. Проблема - Внешний мониторинг отображает только общее время работы запроса и их количество. Отсутствует понимание происходящих процессов внутри компонентов приложения - Любой мониторинг должен вносить минимальное ухудшение производительности и времени работы запросов
9. Проблема - Внешний мониторинг отображает только общее время работы запроса и их количество. Отсутствует понимание происходящих процессов внутри компонентов приложения - Любой мониторинг должен вносить минимальное ухудшение производительности и времени работы запросов - Логи событий для одного запроса различных компонентов системы разбросаны по разным лог файлам
10. Решение В приложение вносятся такие дополнения:
11. Решение В приложение вносятся такие дополнения: • Каждый внешний запрос помечается уникальным идентификатором
12. Решение В приложение вносятся такие дополнения: • Каждый внешний запрос помечается уникальным идентификатором • Прохождение запроса внутри компонентов приложения происходит с сохранением уникального идентификатора
13. Решение В приложение вносятся такие дополнения: • Каждый внешний запрос помечается уникальным идентификатором • Прохождение запроса внутри компонентов приложения происходит с сохранением уникального идентификатора • Идентификатор включается во все лог сообщения
14. Решение В приложение вносятся такие дополнения: • Каждый внешний запрос помечается уникальным идентификатором • Прохождение запроса внутри компонентов приложения происходит с сохранением уникального идентификатора • Идентификатор включается во все лог сообщения • Информация (вместе с таймстампами) сохраняется в централизованное хранилище
15. Dapper a Large-Scale Distributed Systems Tracing Infrastructure https://ai.google/research/pubs/pub36356 Google, 2010 Опубликован через 6 лет после начала работы
17. 3 принципа Dapper • Низкий оверхед
18. 3 принципа Dapper • Низкий оверхед ◦ Система должна вносить в работу приложения минимальные потери в производительности и времени работы
19. 3 принципа Dapper • Низкий оверхед ◦ Система должна вносить в работу приложения минимальные потери в производительности и времени работы ◦ Должна быть ручка для полного выключения трассировок
20. 3 принципа Dapper • Низкий оверхед ◦ Система должна вносить в работу приложения минимальные потери в производительности и времени работы ◦ Должна быть ручка для полного выключения трассировок • Прозрачность уровня приложения
21. 3 принципа Dapper • Низкий оверхед ◦ Система должна вносить в работу приложения минимальные потери в производительности и времени работы ◦ Должна быть ручка для полного выключения трассировок • Прозрачность уровня приложения ◦ Разработчики не должны беспокоиться о системе трассировки
22. 3 принципа Dapper • Низкий оверхед ◦ Система должна вносить в работу приложения минимальные потери в производительности и времени работы ◦ Должна быть ручка для полного выключения трассировок • Прозрачность уровня приложения ◦ Разработчики не должны беспокоиться о системе трассировки ◦ Инфраструктура трассировки должна быть надежна, и не являться источником багов в приложении
23. 3 принципа Dapper • Низкий оверхед ◦ Система должна вносить в работу приложения минимальные потери в производительности и времени работы ◦ Должна быть ручка для полного выключения трассировок • Прозрачность уровня приложения ◦ Разработчики не должны беспокоиться о системе трассировки ◦ Инфраструктура трассировки должна быть надежна, и не являться источником багов в приложении • Масштабирование
24. 3 принципа Dapper • Низкий оверхед ◦ Система должна вносить в работу приложения минимальные потери в производительности и времени работы ◦ Должна быть ручка для полного выключения трассировок • Прозрачность уровня приложения ◦ Разработчики не должны беспокоиться о системе трассировки ◦ Инфраструктура трассировки должна быть надежна, и не являться источником багов в приложении • Масштабирование ◦ Инфраструктура трассировки должна уметь масштабироваться с минимальными трудозатратами
25. Дополнительно о Dapper • Обновления о новых событиях должны быть доступны как можно раньше для исследований • Задержка обновления не должна превышать 1 минуты • Необходима поддержка сэмплирования (сбор только 1 трассировки из N) ◦ Для обеспечения низкого вмешательства в производительность приложения
26. Пример следования пользовательского запроса через компоненты проекта
27. Схема одной трассировки из 5 спэнов
28. Пример отображения одного спэна
29. Схема хранения трассировок в хранилище
30. Нагрузка на CPU в зависимости от кол-ва процессов и потока событий
31. Нагрузка на CPU при разных порогах сэмплирования
32. Пример исследования приложения в Google Dapper
33. Инструменты Opensource • Jaeger • Zipkin SaaS сервисы • NewRelic • LightStep • DataDog
34. Zipkin - Создан в Twitter - Опубликован через 4 года после публикации Google Dapper White paper - Написан на Java - Управляет сбором и поиском данных через сервисы Collector и Query
35. Zipkin
36. Zipkin
37. Zipkin UI
38. Zipkin и Go https://github.com/openzipkin/zipkin-go
39. Zipkin и Go
40. Jaeger • Создан в Uber • Написан на Go • Участник CNCF • Учитывались лучшие вещи из Google Dapper и Zipkin • Включает в себя: ◦ Распределенной распространение контекста ◦ Распределенный мониторинг транзакций ◦ Анализ корней проблем ◦ Анализ зависимостей компонентов приложения ◦ Оптимизация производительности и времени выполнения запросов приложения
41. Jaeger
42. Jaeger UI
43. Jaeger UI: анализ зависимостей
44. OpenTracing • Инициатива унифицировать API • Участник CNCF • Поддерживается в Zipkin • Поддерживается в Jaeger
45. Open tracing принципы • Стандартизация управления спэнами • Стандартизация передачи данных контекста внутри компонентов приложения • Стандартизация доступа к активному спэну приложения • Стандартизация передачи внешнего входящего контекста • Стандартизация выгрузки данных трассировок
46. Cпасибо за внимание! Вопросы?