Наблюдаема ли ваша система мониторинга?
Наблюдаемость приобрела большую популярность в последние годы. Современные парадигмы 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] Мониторинг против наблюдаемости: в чем разница? - Джеймс Ярия.