К основному содержимому
#Architecture

[2/2] Observability in an Asynchronous World • James Eastham • GOTO 2024 (Рубрика Architecture)

#Architecture #SRE #DistributedSystems #Software

Вторая часть поста про observability в асинхронных системах как раз говорит про observability, так как в первой мы успели обсудить только асинхронность:)

  1. В асинхронных системах используются стандартные подходы к observability: logs, metriics, traces. Но это инструменты для обеспечения observability
  2. А автор предлагает вернуться к вопросу, а зачем нам нужна наблюдаемость в нашей системе - по его мнению это

The ability to ask questions of your system, you didn't know you'd need to ask from outside your system То есть, при возникновении проблем мы сможем разобраться в этом.

  1. Асинхронные системы сложны с точки зрения наблюдаемости из-за множества движущихся частей. Essential complexity домена остается на месте, а accidental complexity в асинхронной системе высока.
  2. Чтобы с ней бороться нам надо правильно использовать distributed tracing. Трассировка помогает понять влияние событий на систему.
  3. Асинхронная архитектура упрощает эволюцию за счет добавления новых обработчиков событий, но надо следить за тем, как эволюционирует схема событий во времени - это может приводить к интересным проблемам. В качестве примера Джеймс приводит изменение для поддержки оплаты пиццы несколькими валютами. То есть важно учитывать влияние изменений на все системы, участвующие в обработке событий.
  4. Дальше автор говорит про спецификацию событыий и ррассказывает про cloud events и про event catalog. Эти подходы определяют что включать в события, что помогает с идемпотентностью при обработке и с трассировкой.
  5. Дальше автор рассказывает про подход API First Design и дальше говорит о том, что события в некотором роде тоже являются API, то есть нам нужно относиться к ним с уважением. И использовать каталог событий для документирования систем, управляемых событиями.
  6. Автор говорит о том, что в нашей observability системе часто важно сохранять не содержание событий, а их схему. Это позволяет задавать вопросы о системе и улучшать распределенную трассировку
  7. Вообще про observability и трассировки прикольно посмотреть в докладе "What Is This OpenTelemetry Thing?", про который я недавно рассказывал
  8. Отдельно автор говорит про полезные метрики по событиям: глубина очереди, количество опубликованных и обработанных сообщений, возраст сообщений. Но вообще выбор метрик зависит от контекста и целей.
  9. Observability платформа позволяет находить события, анализировать их структуру, а также отслеживать распространение событий и выявлять регрессии.
  10. Мне понравился вопрос автора о том, а как понять что тот или иная часть кода работает на проде. По-факту, через те же логи, трейсы и метрики.

Для тех, кто хочет посмотреть как это работает на практике, Джеймс запилил код той систеемы для пиццерии, о которой он рассказывал. При желании можно изучить как это работает с использованием в качестве observability платформы Datadog.

#SRE #Architecture #DistributedSystems #Software