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

Transcript

1. Распределённый трэйсинг Go приложения Андреенко Артём CIO Prisma Labs

2. План доклада - О компании - О себе - Описание

   проблемы - Теория - Инструменты - Примеры кода

3. Prisma Labs https://prisma-ai.com - iPhone и Android приложение - Искусственный

   интеллект, который перерисовывает фото в другом стиле - Создано в 2016 году - 150M скачиваний
4. None
5. None

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 лет после начала работы
16. None

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пасибо за внимание! Вопросы?