Anton Sidorov homepage

Bookmark this to keep an eye on my project updates!

Follow me on GitHub

Zipkin

Зачем

  • Качество архитектуры Наблюдаемость Observability реализация Distributed Tracing
  • Distributed context propagation
  • Distributed transaction monitoring
  • Root cause analysis
  • Service dependency analysis
  • Performance / latency optimization

Плюсы-минусы

Как работает

Zipkin понимает, как выстроить запросы, собирая и используя метаданные, отправляемые вместе с каждым запросом через систему. Каждый запрос сопровождается уникальным идентификатором трассировки (trace ID), идентификатором операции (span ID) и, в случае вложенных запросов, идентификатором родительской операции (parent ID). Эти идентификаторы помогают Zipkin собирать отдельные операции (spans) в полную трассировку (trace), показывая путь запроса через систему.

Каждый span содержит таймстемпы и может содержать аннотации, которые описывают события (например, начало и конец запроса), а также бинарные аннотации с дополнительными данными, такими как адреса IP и порты. Для HTTP-трассировки используются специальные заголовки HTTP, которые передают информацию о трассировке между сервисами.

Zipkin также собирает данные о продолжительности операций, и все временные метки представлены в микросекундах для обеспечения высокой точности. Информация о трассировке отправляется в Zipkin асинхронно, чтобы не влиять на производительность пользовательского приложения.

Система хранения в Zipkin плагинизирована и может использовать различные бэкенды, такие как Cassandra, Elasticsearch и MySQL, что обеспечивает гибкость в конфигурации системы сбора трассировок.

Эти механизмы позволяют Zipkin эффективно реконструировать полную картину запроса в распределенной системе и предоставлять полезные визуализации и инструменты для анализа производительности и отладки.

Version