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

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

5b8d20aa7d63c5d391b1c881e1764460?s=128

Iskander (Alex) Sharipov

December 08, 2018
Tweet

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