Распределенная трассировка в действии: использование OpenTracing в расследовании инцидентов разработки

Для создания приложений разработчики всё чаще используют микросервисную архитектуру – гораздо более сложную, чем монолит, в плане мониторинга и разбора логов при возникновении инцидентов. Концепция OpenTracing, или распределенная трассировка запросов, позволяет автоматизировать этот процесс, отслеживать запросы и анализировать проблемы максимально удобным способом. Ведущий архитектор компании IT_One Андрей Дудин рассказывает о преимуществах, которые OpenTracing приносит команде разработки, и делится лайфхаками, взятыми из собственной практики.

OpenTracing – ответ на запрос времени

Мы, конечно, помним, как во времена монолитных приложений, сосредоточенных в больших кластерах, разбирать инциденты разработки приходилось по крупицам, используя вторичные признаки – IP, время и так далее. Найти конкретный запрос конкретного клиента было практически нереально. Чтобы получить нужную информацию по проблеме, нужно было разбирать огромные массивы логов. Наборы bash-скриптов для диагностики передавались "по наследству" от старших разработчиков к "джунам". Но, как ни странно, мы научились более-менее сносно жить с этим.

Когда же главенствующую роль в разработке заняла микросервисная архитектура, ситуация стала намного более тяжелой. Сегодня структура приложений и взаимосвязь между микросервисами усложняются. Команд разработки становятся все больше, количество логов и точек отказа растет одновременно с количеством сервисов, время ответа растет. Вот бы иметь возможность генерировать некий сквозной ID, который пронизывал бы логи и не терялся при прохождении запроса через различные очереди и базы данных.

И такая возможность появилась – с технологией OpenTracing. Она представляет собой независимый набор API и инструментов для распределенной трассировки запросов. В общих чертах – система присваивает каждому запросу специальный идентификатор: TraceID. Благодаря нему мы можем анализировать конкретные проблемы, а не искать примерно подходящие по времени или по IP. Кроме того, внедрив OpenTracing в приложения, мы получаем ряд дополнительных преимуществ: тайминги отдельных кусков кода, детальный анализ ошибок, анализ связанности сервисов, мониторинг отдельных вызовов.

Архитектура и компоненты OpenTracing

Наиболее популярные инструменты, в которых имплементированы стандарты распределенной трассировки, – Zipkin и Jaeger. Архитектуры двух этих продуктов с открытым исходным кодом схожие, и мы можем представить принцип их работы на одном примере.

Основными объектами OpenTracing являются Span (конкретное событие конкретного вызова, предназначенное для трассировки) и Trace (совокупность всех событий, которые происходили в данном запросе). У них есть взаимосвязанные индикаторы – соответственно, SpanID и TraceID. Baggage – позволяет передавать информацию о конкретном Span (в том числе SpanID и TraceID) между микросервисами.

В основании архитектуры OpenTracing лежит Sender – инфраструкрутный сервис или инструментированное приложение, настроенное на отправку трассировок.

Инструмент транспортировки (Transport) может быть разный: например, Kafka. Каждый Span попадает по транспорту в Collector, а тот, в свою очередь, складывает трассировки в базу данных – Storage. В качестве хранилища обычно используется Elasticseach, но также есть возможность использовать Cassandra или другие стораджи, для которых есть драйвера у Zipkin/Jaeger.

Agregator, Spark job, взаимодействующий с базой, производит агрегацию полученных данных, создает связанности и собирает статистику.

С другой стороны, для просмотра и анализа трассировок к Storage подключается веб-интерфейс: Query Service у Jaeger или Zipkin UI у Zipkin. Благодаря им пользователи получают информацию о трассировке и могут ее детально изучать. Для более подробной аналитики всегда есть возможность взаимодействия со стораджем напрямую.

Стоит заметить, что технология OpenTracing реализуется не только на уровне приложений. Например, ряд программных продуктов (Cassandra, ClickHouse, Tarantool и другие) также поддерживают трассировку для того, чтобы пользователи могли видеть внутренние механизмы этих приложений: что происходит там в момент исполнения запросов.

Практика применения OpenTracing

Команда IT_One получила большой опыт при внедрении OpenTracing в инфраструктуру крупного государственного портала. Вот какие лайфхаки мы вынесли из этого проекта.

Tracing без OpenTracing. В больших компаниях ИТ-инфраструктура не слишком динамичная. Чтобы внедрить что-то новое, нужно пройти ряд согласований и другие бюрократические процедуры. При этом решения не всегда принимаются моментально. Но просто внедрив библиотеку внутри нашего приложения и начав записывать TraceID в логи, мы уже получили некий "Tracing без OpenTracing" – возможность увязать весь поток логов с одним Trace ID и быстро находить нужные логи по тому событию, которое нам нужно рассмотреть.

Архивирование трассировок. Если, например, в компании SLA на рассмотрение инцидентов составляет до 30 дней (имеется в виду самый низкий приоритет), то логи и трассировки вам нужно будет хранить в течение этого периода. Такая возможность не всегда есть. Поэтому у Zipkin есть опция архивирования трассировок. Таким образом, под реальной нагрузкой их можно хранить, допустим, один день, а те, которые вызывают вопросы или по которым поступили инциденты, можно хранить в архиве – сколь угодно долго.

TraceID в тестировании.

Один из самых нелюбимых кейсов разработчиков – когда нагрузочное тестирование показывает множество ошибок 504. Типичная ситуация в микросервисной архитектуре, когда при вызове один из множества сервисов не ответил вовремя, весь запрос "ложится" с ошибкой 504. Благодаря трассировке вы можете получать информацию о таких запросах. Если генерировать TraceID на нагрузочном агенте и добавлять в запрос при проведении тестирования – вы всегда сможете найти его в трассировке, даже если ответа от сервера не поступило.

TraceID в ошибках.

Пользователи не всегда обладают достаточной компетенцией для того, чтобы адекватно рассказать, что у них произошло. Зачастую они могут только сделать скриншот или сфотографировать экран с ошибкой, сопроводив ее комментарием "у меня что-то сломалась". Просто добавив TraceID в сообщения об ошибках для клиентов, вы намного упростите диагностику и сможете оперативно найти проблему. Т.к. ID будет на скриншоте или в тексте ошибки, присланной клиентом.

Бот в мессенджере. Сократить время на поиск нужных логов и трассировок поможет простой чат-бот, который встраивается в любой мессенджер, собирает (парсит) TraceID из сообщений от команды (разработчиков, тестировщиков) и в ответ посылает ссылки для просмотра трассировки. Создавая такой бот, мы предусмотрели все форматы написания TraceID: например, с кавычками и без кавычек, с двоеточием и без двоеточия. К слову, среди наших команд тестировщиков этот инструмент оказался тотально востребованным.

Он позволяет не запоминать и не хранить актуальные адреса сервисных инструментов окружения, будь то kibana или zipkin ui. Особенно актуально в больших инсталляциях, когда различных стендов разработки и тестирования много, условно больше 5-10.