Zipkin допоміг багатьом командам зробити перші кроки у розподіленому трасуванні. Він простий, з відкритим вихідним кодом і добре справляється з основними завданнями. Але в міру того, як системи стають складнішими, ця простота може почати здаватися обмежувальною. Більше сервісів, більше середовищ, більше шуму - і раптом трасування вже не зводиться лише до відстеження шляху запиту.
Багато команд сьогодні хочуть, щоб трасування природно вписувалося в процес створення та постачання програмного забезпечення. Менше ручних налаштувань, менше рухомих частин, які потрібно обслуговувати, і кращий контекст журналів, метрик та інфраструктури. Ось тут і з'являються альтернативи Zipkin. Деякі з них зосереджені на більш глибокому спостереженні, інші - на простоті використання або тіснішій інтеграції з хмарою. Правильний вибір зазвичай залежить від того, як швидко рухається ваша команда, і скільки накладних витрат ви готові нести, щоб бачити, що відбувається у вашій системі.
1. AppFirst
AppFirst підходить до розмови про трасування з незвичного боку. Вони не намагаються замінити функцію Zipkin функцією. Замість цього вони розглядають спостережність як щось, що вже має бути присутнім під час запуску програми, а не як щось, що команди додають пізніше. Трасування, журнали та метрики живуть у ширшому середовищі, де розробники визначають, що потрібно їхньому додатку, а платформа керує інфраструктурою, яка стоїть за цим. На практиці це означає, що дані трасування відображаються як частина життєвого циклу програми, а не як окрема система, яку хтось повинен з'єднати разом.
Особливістю AppFirst є те, як вона розподіляє відповідальність. Розробники зберігають право власності на додаток від початку до кінця, але їх не втягують у файли Terraform, хмарні політики чи запити на вилучення даних лише для того, щоб отримати видимість. Для команд, які звикли, що Zipkin працює як ще один сервіс, який потрібно підтримувати, це може здатися перезавантаженням. Трасування - це не стільки управління колекторами і сховищем, скільки бачення поведінки в контексті - який сервіс, яке середовище і скільки коштує його запуск. Це не чистий інструмент для відстеження, але для деяких команд це саме те, що потрібно.
Основні моменти:
- Підхід до спостережуваності та інфраструктури, орієнтований на додатки
- Вбудована функція відстеження, а також ведення журналів і моніторингу
- Централізовані аудиторські сліди для змін в інфраструктурі
- Прозорість витрат у прив'язці до програм і середовищ
- Працює з AWS, Azure та GCP
- Варіанти розгортання SaaS та самостійного хостингу
Для кого це найкраще:
- Команди розробників, які не хочуть керувати інфраструктурою трасування
- Швидка доставка для команд з обмеженою пропускною здатністю DevOps
- Організації, що стандартизують розгортання та моніторинг програм
- Розробники, яким потрібна трасування без вивчення хмарних інструментів
Контактна інформація:
- Веб-сайт: www.appfirst.dev
2. Єгер.
Jaeger часто є першою серйозною альтернативою Zipkin, на яку звертають увагу альтернативні команди, особливо коли розподілені системи починають давати збої. Вони зосереджуються саме на відстеженні: відстежують запити в різних сервісах, розуміють затримки і виявляють, де щось сповільнюється або виходить з ладу. Jaeger зазвичай дає більше контролю, більше варіантів конфігурації та кращу видимість складних графіків сервісів.
Існує також сильна орієнтація на спільноту. Jaeger має відкритий вихідний код, управляється відкрито і тісно пов'язаний з OpenTelemetry. Це важливо для команд, які хочуть уникнути замкнутості або покладатися на широко прийняті стандарти. Компроміс - це зусилля. Належне використання Jaeger означає, що потрібно думати про зберігання, вибірку та масштабування. Він підходить командам, яким комфортно володіти цією складністю і налаштовувати її з часом, а не очікувати, що трасування з'явиться за замовчуванням.
Основні моменти:
- Розподілена трасувальна платформа з відкритим вихідним кодом
- Розроблено для мікросервісів і складних робочих процесів
- Глибока інтеграція з OpenTelemetry
- Аналіз залежності від сервісів та затримок
- Активна спільнота та довгострокова зрілість проекту
Для кого це найкраще:
- Інженерні команди, які вже запускають мікросервіси у великих масштабах
- Організації, прихильні до інструментарію з відкритим кодом
- Команди, яким потрібен точний контроль над поведінкою трасування
Контактна інформація:
- Веб-сайт: www.jaegertracing.io
- Twitter: x.com/JaegerTracing
3. Grafana Tempo
Grafana Tempo йде іншим шляхом, ніж класичні системи типу Zipkin. Замість того, щоб індексувати кожну трасу, вони зосереджуються на дешевому зберіганні великих обсягів даних трасування і зв'язують їх з метриками і журналами, коли це необхідно. Для команд, які досягли межі масштабування Zipkin, цей підхід може виявитися більш практичним, особливо коли обсяг трасування зростає швидше, ніж очікувалося.
Темп зазвичай використовується разом з іншими інструментами Grafana, що визначає те, як команди працюють з ним. Трасування - це не завжди перше, що ви запитуєте самостійно. Замість цього інженери переходять від метричного шипа або лінії журналу прямо до трасування. Такий робочий процес робить Tempo менш орієнтованим на перегляд трас і більш орієнтованим на з'єднання сигналів. Це добре працює, якщо ви вже працюєте з дашбордами Grafana, але може здатися незвичним, якщо ви очікуєте, що трасування буде окремим процесом.
Основні моменти:
- Масштабний бекенд трасування, створений для зберігання об'єктів
- Підтримує протоколи Zipkin, Jaeger та OpenTelemetry
- Тісна інтеграція з Grafana, Loki та Prometheus
- Призначений для роботи з дуже великими обсягами трасування
- Відкритий код з самокерованими та хмарними опціями
Для кого це найкраще:
- Системи, що генерують великі обсяги даних трасування
- Організації, орієнтовані на економічно ефективне довгострокове зберігання
- Інженери, які співставляють траси з журналами та метриками, а не просто переглядають траси
Контактна інформація:
- Веб-сайт: grafana.com
- Facebook: www.facebook.com/grafana
- Twitter: x.com/grafana
- LinkedIn: www.linkedin.com/company/grafana-labs
4. SigNoz
SigNoz зазвичай розглядається як альтернатива самостійному запуску Zipkin. Він розглядає трасування як частину більш широкого підходу до спостережуваності, інтегруючи його з логами та метриками, а не тримаючи його окремо. Для команд, які спочатку використовували Zipkin, а потім включили інші інструменти, SigNoz часто стає актуальним, коли їх набір інструментів відчуває себе розрізненим. Його дизайн від самого початку обертається навколо OpenTelemetry, впливаючи на збір даних і різних сигналів під час налагодження.
Команди швидко помічають переваги робочого процесу. Замість того, щоб перемикатися між різними інструментами трасування, ведення журналів і метрик, SigNoz зберігає ці види інтегрованими. Повільна кінцева точка може привести безпосередньо до трасування, а потім до пов'язаних журналів без втрати контексту. Він не такий легкий, як Zipkin, але це компроміс. Ви отримуєте більше контексту, але також маєте більшу систему для роботи. Деякі команди вважають це прийнятним, оскільки їхні системи перевершують базові потреби в трасуванні.
Основні моменти:
- OpenTelemetry - власний дизайн для трас, журналів та метрик
- Використовує стовпчикову базу даних для обробки даних спостережень
- Можна розміщувати на власному хостингу або використовувати як керовану послугу
- Зосередьтеся на кореляції сигналів під час налагодження
Для кого це найкраще:
- Команди, які вже використовують OpenTelemetry в різних сервісах
- Інженери втомилися зшивати воєдино численні інструменти спостереження
- Командам зручно працювати з ширшим стеком спостережень
Контактна інформація:
- Веб-сайт: signoz.io
- Twitter: x.com/SigNozHQ
- LinkedIn: www.linkedin.com/company/signozio
5. OpenTelemetry
OpenTelemetry не є єдиним інструментом, який ви розгортаєте, а забезпечує спільну мову для створення та переміщення трас, метрик та журналів. Багато команд замінюють Zipkin, стандартизуючи OpenTelemetry для інструментарію, а потім обирають бекенд пізніше.
Такий підхід змінює спосіб прийняття рішень щодо відстеження. Замість того, щоб заздалегідь прив'язуватися до однієї системи, команди використовують інструменти один раз і тримають свої можливості відкритими. Сервіс може почати з надсилання трас до простого бекенду, а згодом перейти до чогось більш просунутого, не торкаючись коду програми. Така гнучкість є привабливою, але вона вимагає відповідальності. Хтось все одно повинен вирішувати, куди йдуть дані і як вони зберігаються. OpenTelemetry не позбавляє вас цієї роботи, вона просто уникає жорстких залежностей.
Основні моменти:
- Незалежні від постачальника API та SDK для трасування, журналів і метрик
- Підтримує багато мов і фреймворків з коробки
- Розроблено для роботи з декількома бекендами, а не для їх заміни
- Відкритий вихідний код з розробкою, керованою спільнотою
Для кого це найкраще:
- Команди, які планують відійти від Zipkin без бекенд-блокування
- Організації, що стандартизують інструментарій для різних послуг
- Інженерні групи, яким потрібна гнучкість в інструментах спостереження
Контактна інформація:
- Веб-сайт: opentelemetry.io
6. Вгору.
Uptrace зазвичай розглядається, коли командам потрібно більше, ніж Zipkin, але вони не хочуть самостійно збирати повний стек спостережуваності. Вони зосереджуються на розподіленому трасуванні, але зберігають метрики і логи досить близько, щоб налагодження залишалося практичним. Трасування зберігається і запитується таким чином, що працює добре, навіть коли окремі запити стають великими, що має значення, коли сервіси починають розгалужуватися на багато залежностей.
Однією з особливостей є те, як Uptrace балансує між контролем і зручністю. Команди можуть запускати його самостійно або використовувати кероване налаштування, але досвід залишається досить схожим. Інженери часто описують перехід з Zipkin як менш болючий, ніж очікувалося, в основному тому, що OpenTelemetry працює з приладами, а Uptrace фокусується на тому, що відбувається після надходження даних. Це більше схоже на систему, яка спочатку відстежує, ніж на платформу "все в одному", якій віддають перевагу деякі команди.
Основні моменти:
- Розподілена трасування на основі OpenTelemetry
- Підтримує великі траси з багатьма прольотами
- Працює як самостійний хостинг, так і керований варіант
- Траси, метрики та журнали доступні в одному місці
Для кого це найкраще:
- Системи зі складними шляхами запитів і великими трасами
- Інженери, які хочуть OpenTelemetry, не будуючи все самостійно
Контактна інформація:
- Веб-сайт: uptrace.dev
- Електронна пошта: support@uptrace.dev
7. Apache SkyWalking
До Apache SkyWalking зазвичай звертаються, коли Zipkin починає здаватися занадто вузьким для того, що насправді потрібно командам щодня. Вони розглядають трасування як частину ширшої картини продуктивності додатків, особливо для мікросервісів та систем на основі Kubernetes. Замість того, щоб зосереджуватися лише на шляхах запитів, SkyWalking використовує топологію сервісів, уявлення про залежності та поведінку сервісів в цілому. На практиці команди часто використовують його, щоб відповісти на питання, чому один сервіс сповільнює роботу всіх інших, а не тільки там, де одна трасування не спрацювала.
SkyWalking відрізняється тим, що намагається охопити якомога більше в одному місці. Траси, метрики і журнали можуть проходити через одну систему, навіть якщо вони надходять з різних джерел, таких як Zipkin або OpenTelemetry. Така широта може бути корисною, але вона також означає, що SkyWalking працює найкраще, коли хтось бере на себе відповідальність за нього.
Основні моменти:
- Розподілена трасування з переглядом топології сервісів
- Призначено для мікросервісів і середовищ з великою кількістю контейнерів
- Підтримує декілька форматів телеметрії, включаючи Zipkin та OpenTelemetry
- Агенти доступні для широкого спектру мов
- Вбудовані трубопроводи оповіщення та телеметрії
- Опція власної бази даних спостережуваності
Для кого це найкраще:
- Команди, що працюють зі складними мікросервісними архітектурами
- Середовища, де сервісні відносини мають таке ж значення, як і окремі сліди
- Організації, які хочуть отримати трасування та APM в одній системі
- Інженерним командам зручно керувати більшою платформою спостереження
Контактна інформація:
- Веб-сайт: skywalking.apache.org
- Twitter: x.com/asfskywalking
- Адреса: 1000 N West Street, Suite 1200 Wilmington, DE 19801 USA
8. Datadog
Datadog підходить до альтернатив Zipkin з точки зору платформи. Розподілена трасування знаходиться поряд з журналами, метриками, профілюванням і довгим списком інших сигналів. Команди зазвичай звертаються до Datadog, коли Zipkin відповідає на деякі питання, але залишає занадто багато прогалин в контексті, особливо коли системи охоплюють кілька хмар або команд.
У реальному використанні трасування за допомогою Datadog часто з'являється під час аналізу інцидентів. Хтось починає з повільної дії користувача, стежить за трасуванням, а потім переходить до журналів або метрик інфраструктури без перемикання інструментів. Зручність полягає в тому, що все тісно інтегровано, але це також означає, що Datadog менш модульний, ніж інструменти трасування з відкритим вихідним кодом. Ви використовуєте трасування як частину ширшої екосистеми, а не як окрему послугу.
Основні моменти:
- Розподілене трасування, інтегроване з журналами та метриками
- Автоматична підтримка багатьох мов
- Візуальне дослідження траси з поданням сервісів і залежностей
- Взаємозв'язок між даними програми та інфраструктури
Для кого це найкраще:
- Команди, які хочуть, щоб трасування було тісно пов'язане з іншими даними спостережень
- Організації, що керують великими або змішаними хмарними середовищами
- Інженерні групи, які віддають перевагу єдиній платформі перед кількома інструментами
Контактна інформація:
- Веб-сайт: www.datadoghq.com
- Електронна пошта: info@datadoghq.com
- Twitter: x.com/datadoghq
- LinkedIn: www.linkedin.com/company/datadog
- Instagram: www.instagram.com/datadoghq
- Адреса: 620 8th Ave 45th Floor New York, NY 10018 USA
- Телефон: 866 329 4466
9. Соти
Honeycomb фокусується на даних високої кардинальності і дозволяє інженерам задавати питання після факту, а не просто переглядати заздалегідь визначені дашборди. Трасування в Honeycomb має дослідницький характер. Люди натискають на трасування, розрізають його за користувацькими полями і слідкують за закономірностями, а не за окремими збоями.
Цей досвід більше дослідницький, ніж операційний. Команди іноді описують Honeycomb як щось, що вони відкривають, коли проблема здається дивною або її важко відтворити. Це робить його хорошим інструментом для налагодження невідомої поведінки, але він може відрізнятися від традиційних інструментів моніторингу. Ви не просто спостерігаєте за слідами, які прокручуються повз. Ви копаєтесь у них.
Основні моменти:
- Розподілена трасування на основі даних високої кардинальності
- Сильний акцент на робочі процеси дослідницької налагодження
- Тісна інтеграція з приладами OpenTelemetry
- Подання трасування, призначені для дослідження всією командою
Для кого це найкраще:
- Команди, які налагоджують складну або непередбачувану поведінку системи
- Інженерні культури, які надають перевагу глибокому дослідженню, а не інформаційним панелям
Контактна інформація:
- Веб-сайт: www.honeycomb.io
- LinkedIn: www.linkedin.com/company/honeycomb.io
10. Вартовий
Sentry, як правило, вступає в розмову про заміну Zipkin з точки зору налагодження. Вони зосереджуються на підключенні трасування до реальних проблем програми, таких як повільні кінцеві точки, невдалі фонові завдання або збої, з якими насправді стикаються користувачі. Трасування розглядається не як окрема карта сервісів, а як контекст навколо помилок і проблем з продуктивністю. Наприклад, розробник, який стежить за повільним процесом оформлення замовлення, може перестрибнути з фронтенду на бекенд і побачити, де зникає час.
Sentry відрізняється від інших тим, що робочий процес має власну думку. Замість того, щоб переглядати траси заради них самих, команди зазвичай потрапляють на траси через проблеми, сповіщення або регресії після розгортання. Це може бути корисно для команд, які зосереджені на продукті, але менш привабливо, якщо ви хочете бачити трасування як нейтральне уявлення про інфраструктуру. Sentry найкраще працює, коли трасування є частиною повсякденного налагодження, а не чимось, що відкривають лише SRE.
Основні моменти:
- Розподілене трасування тісно пов'язане з помилками та проблемами продуктивності
- Наскрізний контекст від фронт-енд дій до бекенд сервісів
- Метрики рівня прольоту для відстеження затримок і збоїв
- Траси, пов'язані з розгортанням та змінами коду
Для кого це найкраще:
- Продуктові команди налагоджують реальні проблеми, з якими стикаються користувачі
- Розробники, які хочуть, щоб трасування було безпосередньо пов'язане з помилками
- Команди, які більше дбають про усунення проблем, ніж про вивчення сервісних карт
Контактна інформація:
- Веб-сайт: sentry.io
- Twitter: x.com/sentry
- LinkedIn: www.linkedin.com/company/getsentry
- Instagram: www.instagram.com/getsentry
11. Тире0
Dash0 позиціонує трасування як щось, що має бути швидким і приносити користь, а не те, з чим потрібно няньчитися тижнями. Вони будують все навколо OpenTelemetry і припускають, що команди вже хочуть мати стандартні інструменти замість специфічних агентів. Трасування, журнали та метрики представлені разом, але трасування часто виступає в ролі хребта, який з'єднує все інше. Інженери зазвичай починають з підозрілого запиту і починають з нього.
Процес роботи навмисно спрощено. Фільтрація трас за атрибутами більше схожа на пошук коду, ніж на налаштування дашбордів, а конфігурація як код з'являється на ранніх стадіях робочого процесу. Dash0 - це не стільки довгостроковий історичний аналіз, скільки швидкі відповіді під час розробки та інцидентів. Це робить його привабливим для команд, які вважають традиційні інструменти спостереження важкими або повільними для навігації.
Основні моменти:
- Підтримка OpenTelemetry для трас, журналів і метрик
- Фільтрація трас високої кардинальності та швидкий пошук
- Підтримка конфігурації як коду для дашбордів та сповіщень
- Тісна кореляція між сигналами без ручного підключення
Для кого це найкраще:
- Команди вже стандартизовані на OpenTelemetry
- Інженери, які віддають перевагу швидкому дослідженню, а не складним дашбордам
- Платформні команди, які хочуть, щоб спостережуваність розглядалася як код
Контактна інформація:
- Веб-сайт: www.dash0.com
- Електронна пошта: hi@dash0.com
- Twitter: x.com/dash0hq
- LinkedIn: www.linkedin.com/company/dash0hq
- Адреса: 169 Madison Ave STE 38218 New York, NY 10016 United States
12. Еластичний АПМ
Elastic APM часто замінює Zipkin, коли трасування має відбуватися поряд з пошуком, журналами та ширшими системними даними. Вони розглядають розподілене трасування як один сигнал у більш широкій системі спостереження, побудованій на моделі даних Elastic. Трасування можна відстежувати в різних сервісах, а потім співвідносити з журналами, метриками або навіть кастомними полями, які команди вже зберігають в Elastic.
Що виділяється, так це гнучкість. Еластичний APM добре працює в змішаних середовищах, де деякі сервіси є сучасними, а інші - ні. Трасування не вимагає підходу з чистого аркуша. Команди можуть поступово встановлювати інструменти, вводити дані OpenTelemetry і аналізувати все через звичний інтерфейс. Він не мінімальний, але масштабується природним чином для організацій, які вже використовують Elastic з інших причин.
Основні моменти:
- Розподілене трасування, інтегроване з журналами та пошуком
- Підтримка приладів на базі OpenTelemetry
- Аналіз залежності від сервісів та затримок
- Працює з сучасними та застарілими програмами
Для кого це найкраще:
- Організації з різноманітними або застарілими системами
- Інженери, які хочуть прив'язати трасування до пошуку та журналів
Контактна інформація:
- Веб-сайт: www.elastic.co
- Електронна пошта: info@elastic.co
- Facebook: www.facebook.com/elastic.co
- Twitter: x.com/elastic
- LinkedIn: www.linkedin.com/company/elastic-co
- Адреса: 5 Southampton Street London WC2E 7HA
13. Камон.
Kamon фокусується на тому, щоб допомогти розробникам зрозуміти затримки та збої, не потребуючи глибоких знань у сфері моніторингу. Трасування поєднується з метриками та журналами, але користувальницький інтерфейс підштовхує користувачів до практичних питань, наприклад, яка кінцева точка сповільнила роботу або який виклик до бази даних спричинив сплеск після розгортання.
Також існує сильна орієнтація на конкретні екосистеми. Kamon природно вписується в стеки, побудовані за допомогою сервісів на базі Akka, Play або JVM, де автоматичні інструменти зменшують тертя при налаштуванні. У порівнянні з ширшими платформами, Kamon здається вужчим, але це може бути перевагою. Команди часто обирають його, оскільки він відповідає на їхні щоденні запитання, не вимагаючи від них переробляти свій підхід до моніторингу.
Основні моменти:
- Розподілене трасування, орієнтоване на бекенд-сервіси
- Потужна підтримка стеків на основі JVM та Scala
- Корельовані метрики та траси для аналізу затримок
- Мінімальні витрати на інфраструктуру та налаштування
Для кого це найкраще:
- Команди розробників з важким бекендом
- Системи на основі JVM та Akka
- Розробники, яким потрібна проста, практична трасування без складних інструментів
Контактна інформація:
- Веб-сайт: kamon.io
- Twitter: x.com/kamonteam
Висновок
Підводячи підсумок, вихід за межі Zipkin полягає не стільки в гонитві за функціоналом, скільки в тому, щоб вирішити, як ви хочете, щоб трасування вписувалося в повсякденну роботу. Деякі команди хочуть, щоб трасування було тісно пов'язане з помилками та розгортаннями, щоб налагодження залишалося близьким до коду. Іншим важливіше бачити, як сервіси взаємодіють в масштабі, або об'єднати трасування з логами і метриками без жонглювання інструментами.
Серед цих альтернатив виділяється те, що не існує єдиного шляху оновлення, який підходить для всіх. Правильний вибір зазвичай відображає те, як команда створює, постачає та виправляє програмне забезпечення, а не те, наскільки вражаюче виглядає інтерфейс трасування.
