Эпоха наблюдаемости: почему будущее открыто, взаимосвязано и программируемо

Введение

Когда основатель «New Relic» Лью Сирн (Lew Cirne) создал систему мониторинга производительности приложений (APM), его ключевым нововведением стала возможность  глубокая просматриваемость кода в монолитных приложениях, работающих в центре обработки данных. Затем его система стала доступна в виде SaaS, и ей может воспользоваться каждый инженер, занимающийся разработкой и эксплуатацией программного обеспечения. Сегодня новые технологии и практики (облако, микросервисы, контейнеры, DevOps, SRE и другие) ускоряют внедрение программного обеспечения в промышленную эксплуатацию. Но вместе с тем, эти технологии  достаточно сложные.

«New Relic» считает, что основной способ преодолеть эту сложность, поддерживать современные системы и обеспечить превосходное качество обслуживания клиентов — это наблюдаемость (observability).

Однако важно понимать: наблюдаемость  — это не просто синоним мониторинга.

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

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

Наблюдаемость помогает современным командам разработчиков:

• Создавать высококачественное программное обеспечение
• Создавать устойчивую культуру инноваций
• Оптимизировать инвестиции в облако и современные инструменты
• Наблюдать за эффективностью своего цифрового бизнеса в реальном времени

В «New Relic» считают, что метрики, события, логи и трассировки являются основными типами данных наблюдаемости. Но наблюдаемость — это гораздо больше, чем просто данные.

Как обеспечить наблюдаемость ваших систем и каких результатов ожидать, когда у вас все уже налажено? Практика наблюдаемости основана на трех компонентах: открытые инструменты (open instrumentation), связанные данные (connected data) и программируемость (programmability).

Глава 1: Современные архитектуры требуют нового подхода к мониторингу

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

• Стремление к быстрому внедрению инноваций. Команды разработчиков сталкиваются с огромным давлением: необходимо быстро и часто внедрять новые функции и возможности, опережая конкурентов. Облачные технологии, снизив барьер для входа, увеличивают конкурентную среду. Теперь команды разработчиков должны релизится и адаптироваться (deliver and adapt) быстрее, чем когда-либо, ещё и с меньшими ресурсами. Высокопроизводительные специалисты развертывают ПО от одного раза в неделю до одного раза в день, а лучшие исполнители делают это по запросу несколько раз в день.
• Более высокие ожидания клиентов. Клиенты ожидают большего и терпят меньшее. Медленный, подверженный ошибкам (error-prone), плохо спроектированный пользовательский интерфейс не имеет шанса на успех. По данным разработчика мобильных приложений «Dot Com Infoway», 62% людей удаляют приложение, если возникли сбои, зависания и ошибки. Лучшие специалисты в случае инцидента или неисправности восстанавливают сервис меньше, чем за час, в то время как низкоэффективным требуется от недели до месяца.
• Дополнительные технологические возможности. Сегодня организации создают микросервисные архитектуры и распределенные системы на неограниченном количестве вычислительных платформ и облачных провайдеров. Эти сервисы сегодня проще, чем когда-либо, внедрить и использовать. Вы можете выбирать различные системы и службы для поддержки всего, что вам нужно в стеке технологий, при этом абстрагируясь от усилий по настройке и обслуживанию.
• Рост DevOps и автоматизации. Компании объединяются вокруг автономных команд, занимающихся сквозным проектированием, доставкой и эксплуатацией сервисов. Автоматизация сокращает повторяющуюся рутинную работу и повышает надежность работы систем. В облачной архитектуре все в стеке контролируется программным обеспечением. А поскольку вся эта автоматизация программная, она может дать сбой. Команды должны контролировать свои CI/CD и другие инструменты автоматизации точно так же, как и приложения своих клиентов. Сбор данных о каждом компоненте в системе — это сущность наблюдаемости.

Эти тенденции создают четыре проблемы, которые обусловливают потребность в наблюдаемости современных систем:

 

1. Бóльшая сложность. Облачные технологии изменили способы создания, развертывания и эксплуатации приложений, но они же усложнили работу групп, отвечающих за их поддержку. Поскольку монолитные приложения реорганизуются в микросервисы, где время жизни контейнера может измеряться минутой и меньше, внезапно разработчики получают услуги, которые постоянно меняются. Поскольку каждое отдельное приложение разбивается потенциально на десятки микросервисов, команды сталкиваются со сложностью масштабирования: теперь они несут ответственность за службы, о которых они мало знают, но должны поддерживать.
2. Более высокий риск. Частые развертывания и динамическая инфраструктура означают высокий риск. Этот повышенный риск делает мгновенное обнаружение и откат на предыдущую версию гораздо более важными, чем ранее. И по мере того, как компании внедряют agile-практики для более быстрого внедрения  программного обеспечения, они создают новую область, которую необходимо отслеживать и поддерживать.
3. Пробелы в навыках. Бурный рост архитектур микросервисов привел к появлению новых проблем: команды разработчиков должны переосмыслить, то как они проектируют, создают и развертывают приложения. Каждый член команды должен понимать и уметь устранять неполадки в частях приложения, с которыми он ранее не был знаком, например, специалист по базам данных должен также знать о сетях и API. С другой стороны, количество новых и разных технологий, которые команды должны научиться использовать, слишком велико, чтобы один человек мог их освоить.
4. Слишком много инструментов. Гибридные среды, тысячи контейнеров в производственной среде и несколько развертываний в день приводят к огромным объемам телеметрических операционных данных. «Жонглирование» инструментами мониторинга и переключение между контекстами для поиска и сопоставления данных отнимает драгоценное время, которого у команд нет, когда их клиенты сталкиваются с проблемой.

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

Глава 2: Эпоха observability

Хотя мониторинг в целом восходит к началу эры «Unix» (первая версия была выпущена в 1971 году), термин «мониторинг производительности приложений» (APM) не имел широкого распространения до начала 2000-х годов. С тех пор мониторинг эволюционировал до предоставления подробных метрик, трассировок и оповещений о производительности и опыте пользователей по всему стеку технологий, включая облако.

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

Наблюдаемость — совсем не новое понятие. Изначально термин пришел из инженерии и теории управления, был введен венгерско-американским инженером Рудольфом Э. Кальманом для линейных динамических систем. Общепринятое определение наблюдаемости, применяемое в инженерии и теории управления, — это мера того, насколько близкие к реальности выводы о внутреннем состоянии системы можно сделать из имеющихся внешних выходных данных.

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

Юрий Шкуро (Yuri Shkuro), инженер-программист в «Uber Technologies», объясняет разницу так: “Мониторинг — это измерение того, что вы заранее обозначаете важным, а наблюдаемость — это способность задать вопросы о своей системе, ответы на которые вы ещё не знаете”.

Как уже было сказано, в «New Relic» основными типами данных считаются метрики, события, журналы и трассировки. В конечном итоге, когда мы все «инструментируем» и используем данные для формирования фундаментального понимания отношений и зависимостей в системе, ее производительности и состоянии, мы практикуем наблюдаемость. Однако подход может быть «тоньше» — нужно разобраться в трех основных компонентах наблюдаемости.

Глава 3: Три основных компонента наблюдаемости

До сих пор мы определяли наблюдаемость как практику инструментальных систем для сбора данных, которые дают не только информацию о том, когда произошла ошибка или проблема, но и почему. А способность ответить на вопрос «почему» — ключ к решению коренных проблем и обеспечение надежности системы в целом. Три основных компонента наблюдаемости:

1. Открытые инструменты. Открытые инструменты — набор метрик из приложения, службы, узла инфраструктуры, контейнера, облачной службы, мобильного приложения или любого другого объекта, который передает данные. Они обеспечивают наблюдаемость инфраструктуры и всех важных для бизнеса приложений.
2. Связанные объекты. Все эти метрики должны быть проанализированы, чтобы можно было идентифицировать и связать производящие их объекты, а также включить в анализ метаданные для создания корреляции между объектами и их данными. Эти два действия создают контекст и смысл для больших объемов данных. Исходя из этого контекста, курирование может осуществляться в виде визуальных моделей системы или технологии. Последнее преимущество связанных объектов заключается в том, что для получения еще большего смысла может быть использован ИИ. Прикладной интеллект (applied intelligence) — это применение машинного обучения и науки о данных для поиска закономерностей или аномалий в данных, чтобы люди могли принимать решения и действовать.
3. Программируемость. Каждый бизнес уникален, и никакое автоматическое курирование (automatic curation) не может удовлетворить различные потребности и подойти под любой вариант использования. Компаниям нужно найти способ создания своего собственного контекста и курирования всех данных телеметрии (а также бизнес-показателей).

Глава 4: Открытые инструменты

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

Несмотря на то, что сегодня это остается эффективным способом сбора данных телеметрии, отрасль изменилась. Сейчас источников телеметрии намного больше. Многие открытые системы и платформы для разработки ПО имеют встроенные способы сбора метрик, событий, логов и трассировок. Для наблюдаемости вам необходимо собрать данные как из открытых, так и из закрытых источников, и объединить их в одном месте. Вам нужно автоматически применять инструменты там, где это имеет смысл, и добавлять инструменты там, где вам больше всего нужна видимость.

В большинстве случаев метрики являются отправной точкой для наблюдения. Они не требуют больших затрат на сбор, недороги в хранении, подходят для быстрого анализа и являются отличным способом измерения общего состояния «здоровья» системы. Появилось множество инструментов для сбора метрик, таких как «Prometheus», «Telegraf», «StatsD», «DropWizard» и «Micrometer».

Трассировки полезны для демонстрации сквозной задержки (end-to-end latency) отдельных вызовов в распределенной архитектуре. Эти вызовы дают конкретное представление о бесчисленных взаимодействиях клиентов с системой. Трассировки позволяют инженерам понять путь клиента (customer journey), найти узкие места и выявить ошибки, чтобы исправить их и оптимизировать. Как и в случае с метриками, многие инструменты для сбора трассировок («Jaeger», «Zipkin» и «AWS X-ray» и т.д.) появились из специализированных решений, созданных продвинутыми организациями.

«W3C Trace Context» скоро станет стандартом для распространения «контекста трассировки» на другие процессы. Контекст трассировки обеспечивает стандартный способ отслеживания потока данных через систему, отслеживающую вызовы в сложных распределенных системах. Когда разработчики используют стандарт для своего контекста трассировки, данные от многих систем могут быть надежно соединены вместе для отображения и поиска на платформе наблюдения (observability platform). Контекст трассировки также содержит важные теги и другие метаданные, которые делают поиск и корреляцию более эффективными.

Часть «Cloud Native Computing Foundation (CNCF)«, проект «OpenTelemetry«, объединяют коллекции метрик и трассировок в открытом формате. Учитывая распространенность таких инструментов, как «Kubernetes» и «Istio», “OpenTelemetry”, вероятно, станет одним из основных источников телеметрических данных в технологические компаниях.

Логи важны, когда инженер находится в режиме «глубокой» отладки, пытаясь понять проблему. Логи предоставляют данные с высокой точностью и дают подробный контекст события, поэтому инженеры могут воссоздать то, что произошло миллисекунды за миллисекундами. Как и в случае с метриками и трассировками, появились инструменты, позволяющие сократить трудоемкость и усилия по сбору, фильтрации и экспорту логов: «Fluentd», «Fluent Bit», «Logstash» и «AWS CloudWatch», а также многие новые стандарты.

Все эти проекты для показателей, логов и трассировок создаются «на будущее», в котором инструментарий станет проще для всех благодаря подходу «batteries included» (девиз языка программирования Python, означающий, что он поставляется с большой библиотекой полезных модулей).

События — это важный тип телеметрии, который должен быть частью любого решения для наблюдения. К сожалению, хотя события и логи имеют общие черты, их часто ошибочно объединяют. События представляют собой дискретные подробные записи важных моментов для анализа. Но они содержат более высокий уровень абстракции, чем логи. Логи — это подробные и дискретные записи всего, что происходило в системе; события — это записи избранных значимых явлений с метаданными, прикрепленными к записи, чтобы уточнить ее контекст. Например, когда «New Relic» собирает транзакционные события, данные автоматически добавляются, чтобы показать количество выполненных вызовов базы данных и продолжительность этих вызовов. События предоставляют возможность выполнить детальный анализ в режиме реального времени.

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

Глава 5: Связанные и контролируемые данные

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

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

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

• Подробная информация о группе, которой принадлежит приложение, runbook и репозиторий кода.
• Теги из Docker’а или облачного провайдера, где он развернут
• Тип и функция услуги
• Регионы размещения
• Его восходящие и нисходящие зависимости
• Его развертывание или изменение событий
• Его состояние
• Любые данные трассировки или лога, связанные с выполняемыми им транзакциями.
• Дополнительные бизнес-данные (например, стоимость корзины)

Курирование (сuration) визуализации данных — мощный инструмент для выявления связанных, хорошо понятных и четко определенных объектов. Мы уже знаем, как лучше всего представить процессы в приложении «Java», работающего в контейнере, или функцию «AWS Lambda», которая вызывает «DynamoDB» после вызова из «SQS», или кластер «Kubernetes», выполняющий динамическое развертывание, — мы решили эти проблемы. А для занятого инженера SRE или DevOps моделирование этих сред с помощью набора информационных панелей — пустая трата драгоценного времени. Платформа наблюдения (observability platform) должна включать в себя передовой опыт лидеров отрасли и давать наиболее важные сигналы о работоспособности, а также предоставлять интерактивные возможности, позволяющие инженерам быстро устранять проблемы. Создание визуализаций и информационных панелей для узкоспециальных и общераспространенных технологий вручную —это утомительно.

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

Наблюдаемость — ничто, если вы не можете быстро принять меры, когда ваша система работает некорректно. Благодаря машинному обучению и прогнозной аналитике искусственный интеллект берет наблюдаемые данные и делает их значимыми и действенными. Прикладной интеллект (applied intelligence), который иногда называют искусственным интеллектом для ИТ-операций, находит важный сигнал в «шуме» (finds the signal within the noise), чтобы вы могли предпринять правильные действия.

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

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

Преимущества здесь очевидны. Поскольку прикладной интеллект уже выполнил критически важный анализ для устранения неполадок и сократил среднее время определения  (MTTD — mean-time-to-discovery), ваша группа разработки и сопровождения  может быстрее решить основную (корневую) проблему и, в свою очередь, сократить свое среднее время разрешения проблемы (MTTR — mean-time-to-resolution). Прикладной интеллект становится более полезным при обучении с большим количеством данных и может отфильтровывать шум из незначительных или ложных сигналов тревоги, так ваша команда значительно снизит общую усталость от предупреждений, что позволит им сосредоточиться на выпуске лучшего программного обеспечения.

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

Глава 6: Программируемость

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

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

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

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

Когда у вас есть платформа наблюдения, на которой вы можете создавать приложения, адаптированные к вашим уникальным потребностям, это дает возможность делать то, что ранее было невозможно в инструменте наблюдения, например:

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

Наконец, платформа программируемой наблюдаемости позволяет создавать приложения, работающие в единой системе записи, без необходимости развертывания другого инструмента. Это дает ряд преимуществ: не нужно переключаться между контекстами в аварийной ситуации; сокращение времени и трудозатрат на обеспечение, эксплуатацию, обслуживание и мониторинг другой системы; снижение стоимости покупки, создания или изучения еще одного инструмента.

Глава 7: Подведем итог

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

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

Платформа наблюдения должна:

 

• Собирать и объединять метрики из открытых и частных источников в одном месте. Открытый инструментарий сокращает количество инструментов и необходимость переключаться между контекстами при возникновении проблем и чрезвычайных ситуаций, поскольку он обеспечивает функциональную совместимость всех данных, независимо от их источника.
• Формировать связи и отношения между объектами и применять эти связи для создания контекста и смысла, чтобы вы могли понимать данные.
• Давать вам возможность создавать на ее основе собственные приложения. В отличие от панелей мониторинга, приложения предоставляют интерактивные возможности; они позволяют комбинировать наборы внешних данных в реальном времени. Программируемость переопределяет возможности наблюдаемости.

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

Источник: https://newrelic.com/resources/ebooks/what-is-observability