Наблюдаема ли ваша система мониторинга?

Наблюдаемость приобрела большую популярность в последние годы. Современные парадигмы DevOps поощряют создание надежных приложений за счет включения автоматизации, инфраструктуры как кода и гибкой разработки. Для оценки работоспособности и надежности ИТ-систем инженерные группы обычно используют журналы, метрики и трассировки, которые используются различными инструментами разработчика для облегчения наблюдения. Но что такое наблюдаемость и чем она отличается от наблюдения?

Определение наблюдаемости в Википедии

Наблюдаемость - это мера того, насколько хорошо внутренние состояния системы могут быть выведены из информации о ее внешних выходных данных. - Википедия

Наблюдаемая система позволяет нам оценить, как система работает, не вмешиваясь в нее и даже не взаимодействуя с ней. Просто глядя на выходные данные системы (такие как журналы, метрики, трассировки), мы можем оценить, как эта система работает.

Мониторинг против наблюдаемости

Одно из лучших объяснений по поводу мониторинга и наблюдаемости, которое я когда-либо видел, было дано в онлайн-курсе «Создание современных приложений Python на AWS», проведенном Морганом Уиллисом, старшим специалистом по облачным технологиям в AWS.

Мониторинг - это сбор данных. Какие типы данных мы собираем, что мы делаем с данными, и если эти данные легко анализируются или доступны - это совсем другая история. Вот где в игру вступает наблюдаемость. Наблюдаемость - это не глагол, это не то, что вы делаете. Вместо этого наблюдаемость - это скорее свойство системы . - Морган Уиллис

Согласно этому объяснению, такие инструменты, как CloudWatch или X-Ray, можно рассматривать как инструменты мониторинга или отслеживания. Они позволяют нам собирать журналы и показатели о нашей системе и отправлять предупреждения об ошибках и инцидентах. Таким образом, мониторинг - это активная часть сбора данных, которые помогают нам оценить состояние нашей системы и то, как ее различные компоненты работают вместе. Как только мы установим мониторинг, который непрерывно собирает журналы, системные данные, показатели и трассировки, наша система становится наблюдаемой.

Как специалист по обработке данных, мне нравится рассматривать мониторинг как часть приема данных в ETL (извлечение, преобразование, загрузка) - вы собираете данные из нескольких источников (журналы, трассировки, метрики) и помещаете их в озеро данных. Как только все эти данные будут доступны, опытный аналитик сможет извлечь из них представление и построить красивые информационные панели, которые рассказывают историю, которую эти данные передают. Это часть наблюдаемости - получение информации из собранных данных. А платформы наблюдения, такие как Dashbird , играют роль опытного аналитика. Они предоставляют вам визуализацию и понимание состояния вашей системы.

Мониторинг - необходимое условие для наблюдения. Система, которую мы не отслеживаем, не подлежит наблюдению.

Примеры, показывающие различие между наблюдаемостью и мониторингом

Мониторинг

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

  • отслеживание ошибок и оповещение о них сразу после их возникновения,
  • отслеживание показателей, касающихся загрузки ЦП или сетевого трафика, чтобы в дальнейшем определить, исправны ли определенные вычислительные ресурсы,
  • реагирование на сбои и нарушения безопасности посредством предупреждений, сигналов тревоги и уведомлений.

Несмотря на то, что мониторинг является активным процессом, AWS позаботится об этом автоматически, когда мы используем CloudWatch или X-Ray.

Наблюдаемость

Цель наблюдения - использовать результаты системы для сбора информации и действий на ее основе. Примеры:

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

Наблюдаемость бессерверных микросервисов

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

При просмотре AWS вам нужно будет перейти в AWS, чтобы просмотреть журналы, найти группу журналов вашей функции Lambda, а затем найти журналы, которые вам действительно интересны. Затем, чтобы увидеть соответствующие трассировки API, вы должны перейти к X- Ray или CloudTrail и снова выполните поиск среди потенциально сотен компонентов, чтобы найти тот, который вы хотите исследовать. Как видите, поиск и доступ к журналам и трассировкам каждого отдельного компонента занимает довольно много времени. Кроме того, отладка отдельных частей не дает вам полного представления о том, как эти компоненты работают вместе.

С ростом архитектуры микросервисов нам нужен более простой (автоматизированный) способ добавить наблюдаемости бессерверной экосистеме.

Как Твиттер это делает?

Вот пример сервиса, с которым мы слишком хорошо знакомы - Twitter. Как вы можете себе представить, такой продукт, как Twitter, имеет множество движущихся частей, и когда что-то ломается, может быть трудно понять, почему или что вызвало проблему. Представьте, что у вас 350 миллионов активных пользователей, которые взаимодействуют друг с другом через вашу систему, пишут твиты, лайкают, пишут, ретвитят и т. Д. Когда вы имеете дело с тысячами небольших сервисов, которые асинхронно обмениваются данными друг с другом, становится все труднее найти основную причину ошибки, например, почему не публикуется твит или почему сообщение длилось дольше, чем обычно. быть доставленным. Twitter писал об их переходе на микросервисы в 2013 году, вы можете найти сообщение здесь.

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

Наша служба приема метрик временных рядов обрабатывает более 2,8 миллиарда запросов на запись в минуту, хранит 4,5 петабайта данных временных рядов и обрабатывает 25 000 запросов запросов в минуту. - Энтони Аста об объеме своих систем наблюдения, опубликованных в 2016 году - для получения дополнительной информации см. Часть первая и часть вторая.

Чем может помочь бессерверная платформа наблюдения?

Понятно, что не у всех предприятий есть масштабы Twitter, и у них может не быть ресурсов и времени для создания собственной системы наблюдения. Поэтому я хочу продемонстрировать простую и интуитивно понятную платформу наблюдаемости. За 2 минуты настройки вы можете зарегистрироваться в Dashbird и сразу же добавить наблюдаемость в свою бессерверную архитектуру AWS. Каждый бессерверный компонент в вашей учетной записи AWS, для которого вы включили журналы CloudWatch и трассировку X-Ray или CloudTrail, автоматически отслеживается с помощью этих инструментов. Но это пока не наблюдается, пока вы не сделаете что-то с этими собранными данными.

Истинное преимущество Dashbird заключается в том, что он не требует каких-либо изменений кода и каких-либо усилий с вашей стороны - он просто использует данные, которые уже существуют , т. е. данных, мониторинг которых вы уже включили с помощью собственных сервисов AWS, предназначенных для этой цели.

В качестве платформы наблюдения Dashbird позволяет вам выполнить все пункты, упомянутые при обсуждении примеров идей, собранных из наблюдаемой системы:

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

Заключение

В то время как инструменты мониторинга позволяют собирать журналы приложений, а также показатели использования ресурсов и сетевого трафика или трассировки HTTP-запросов, сделанных к определенным службам, наблюдаемость - это свойство системы, которая анализирует и визуализирует собранные данные, тем самым позволяя вам улучшить жизненный цикл вашего приложения за счет сбора информации о базовой системе.

Ресурсы:

[1] Википедия

[2] Создание современных приложений Python на AWS - Морган Уиллис

[3] Мониторинг против наблюдаемости: в чем разница? - Джеймс Ярия.