Вы, наверное, слышали этот термин Наблюдаемость в последнее время. В пространстве мониторинга происходят фундаментальные изменения, и за ними стоит наблюдаемость. Наблюдаемость сама по себе является обширной темой, поэтому в этом посте мы поговорим о том, что значит перейти от мониторинга производительности приложений к наблюдению за производительностью приложений .
МОНИТОРИНГ
ПРОИЗВОДИТЕЛЬНОСТИ ПРИЛОЖЕНИЙ Если вы использовали традиционную службу APM, вы, скорее всего, установили библиотеку в свое приложение от этого поставщика APM. Затем эта библиотека, или агент, будет собирать метрики и трассировки приложений во время работы приложения в рабочей среде.
Трассировки и метрики в APM Традиционные агенты APM
собирают подробные трассировки того, что происходит под капотом, чтобы ваше приложение могло обслуживать транзакции конечным пользователям. Но они также в значительной степени основаны на показателях. Они генерируют предопределенные агрегированные метрики о производительности приложения в целом. Такие показатели, как пропускная способность, среднее время отклика, процентили и т. д. Мертвой раздачей относительно того, ориентирован ли сервис на мониторинг или наблюдаемость, является подавляющее присутствие информационных панелей для метрик. Это не значит, что информационным панелям нет места в инструменте наблюдения, но они не должны быть основной функцией. Вы не должны тратить значительное количество времени на настройку или обслуживание информационных панелей.
Отсутствие контекста Поскольку
традиционные службы APM по-прежнему в значительной степени основаны на метриках, в данных отсутствует огромное количество контекста. Без контекстной информации из каждой трассировки приложения невозможно задавать важные вопросы, такие как «Что изменилось? Почему? Кого это касается?». Подробные трассировки, собранные с помощью инструментов APM, выбираются на основе простой стратегии выборки.
Вопросы
с длинным хвостомТрадиционный мониторинг приложений хорошо справляется с проблемами производительности, которые влияют на большинство пользователей. На общие проблемы, такие как «Работает ли сайт?» или «Соответствует ли время отклика 95% в рамках нашего SLA?», можно ответить с помощью мониторинга. Вопросы с длинным хвостом могут быть решены только с помощью решения наблюдаемости. «Покажите мне всех пользователей, время отклика которых превысило наш порог SLA в любое время в этом месяце», «Время ответа увеличилось на 95% за последний час. Отображение всех служб, участвующих в обслуживании этих запросов, и пользователей, на которых они затронуты», «Пользователь X имеет длительное время загрузки на конечной точке Y. Показать мне все трассировки от пользователя X в конечной точке Y». Наблюдаемость позволяет задавать эти и многие другие вопросы о ваших приложениях.
Дублирующиеся усилия Поставщики
APM написали агенты для динамического внедрения кода в платформы приложений и библиотеки, такие как Rails, Redis и MongoDB. Это позволило собирать данные телеметрии из запущенных приложений. Инструментарий был трудным, утомительным и деликатным процессом, и каждый поставщик APM должен был написать свой собственный. Это привело к напрасным усилиям по инструментированию фреймворков и библиотек.
Согласитесь на некачественную поддержку отдельных языков с одной панелью
, надежность API, согласованность соглашений об именах и множество факторов, препятствующих совместному использованию или интеграции данных мониторинга. У Ops, Developers, SRE, DevOps есть свои любимые инструменты. Каждый соответственно выбрал лучший инструмент для удовлетворения своих потребностей в прошлом, что привело к разрастанию инструментов и услуг. Собираетесь использовать это единственное стекло? Приготовьтесь к некоторым серьезным компромиссам, по крайней мере, для нескольких из этих команд, чтобы все пользовались одним и тем же сервисом.
НАБЛЮДАЕМОСТЬ
ПРОИЗВОДИТЕЛЬНОСТИ ПРИЛОЖЕНИЙ Контекст связывает все
Вместо того, чтобы агент APM заранее определял, какие агрегированные метрики собирать, соберите каждую трассировку приложения. При необходимости извлекайте метрики из трассировок по запросу. Нарезайте и нарезайте грани контекстной информации, содержащейся в трассировках по запросу. Контекстные данные являются краеугольным камнем для того, чтобы иметь возможность задавать важные вопросы о наблюдаемости и отвечать на эти проблемы с длинным хвостом.
Внедрение стандартов, межъязыковых и кроссплатформенных стандартов — это масштабная задача. Вы должны иметь возможность отправить запрос, чтобы ответить на вопросы о наблюдаемости на всех языках, которые вы используете в рабочей среде. А также знайте, что контекст применяется и находится в одном и том же месте во всех ваших приложениях. Структура, определяющая эти стандарты, является обязательной для наблюдаемости.
Формирование ландшафта
Obs Огромное влияние здесь оказывает стандартизированная спецификация. Вот список некоторых типов портов внешнего интерфейса, которые, как я помню, приходилось использовать на компьютерах на протяжении многих лет: Parallel, RS232, DB9, VGA, S-Video, DVI, DisplayPort, HDMI, MIDI, RCA, Component, Toslink, RJ11, RJ45, PCMCIA, SCSI, eSATA, AT, PS/2, Firewire. Да, у меня есть коробка, полная кабелей для подключения к любому из них, без PCMCIA...
Вы заметили, чего не хватало в списке? Правильно, USB! Конечно, у меня есть миллион USB-кабелей. Потому что все, что подключается к моему компьютеру, теперь USB . Конечно, разные форм-факторы, но протокол волшебным образом обратно совместим. Если вы можете подогнать его или перевернуть вверх дном один или два раза - или больше - это просто работает! Это тот стандарт, за который следовал каждый производитель периферийных устройств, потому что он так хорошо разработан. Это огромная часть того, что формирует ландшафт наблюдаемости и, наконец, заставляет подавляющее количество поставщиков и разработчиков поддерживать единую спецификацию: OpenTelemetry .
Корреляции
Я остановлюсь на теме: стандартизация. Обладая универсальным и последовательным пониманием того, что представляют собой данные, мы можем проводить глубокие корреляции между приложениями, языками и стеком инфраструктуры. Этот богатый контекст обеспечивает помощь в производительности и операционной отладке, а не только в рамках одного приложения.
Культура развития меняет
Наблюдаемость — это больше, чем просто инструмент. Он не может дать вам всезнающих сил, как в фильме «Безграничный». Наблюдаемость должна быть намеренно добавлена в ваш код и стек. Разработчики должны не забывать добавлять его при написании и проверке кода. Они должны задавать такие вопросы, как «Нужно ли это измерять?» или «Как я узнаю, что это будет работать так, как ожидалось?» Проприетарные решения APM могут стать отличным началом, но вам нужно сделать наблюдаемость регулярной мыслью в вашем коде. Не забудьте прикрепить контекстную информацию для дальнейшего просмотра трассировок производительности.
FACTORS ENABLING НАБЛЮДАЕМОСТЬ
ПРОИЗВОДИТЕЛЬНОСТИ ПРИЛОЖЕНИЙ Экономичные вычислительные решения и решения для хранения данных большой мощности
Наблюдаемость — это высокая мощность и большие наборы данных. Стоимость облачных вычислений и хранения данных достигла переломного момента. Теперь мы можем использовать эти облачные сервисы для обработки по требованию, чтобы ответить на вопросы, которые требует наблюдаемость, и предоставить их нашим пользователям по разумной цене.
API/SDK для наблюдений с открытым исходным кодом.
Наконец-то мы видим, как сближение нескольких конкурирующих стандартов объединяется в один с огромной поддержкой сообщества и отрасли: OpenTelemetry ! Спецификация OpenTelemetry определяет межъязыковые спецификации данных, включая API, пакеты SDK и транспортные протоколы. Они формируют новый «лингва-франка» для наблюдаемости, позволяя всему стеку говорить на одном языке, собирать данные в одном формате и, в конечном итоге, передавать эти данные для обработки. Чтобы сделать наблюдаемость по-настоящему повсеместной, нам нужен этот важный кусочек головоломки.
НАБЛЮДАЕМОСТЬ
ПРОИЗВОДИТЕЛЬНОСТИ ПРИЛОЖЕНИЙ OpenTelemetry выравнивает поле для сбора, обработки и передачи данных телеметрии с богатым контекстом. Он делает это одинаково для популярных языков и системных стеков. Это фокусирует ценность поставщиков наблюдаемости, таких как TelemetryHub, на том, какие аналитические сведения и ценность вы можете извлечь из этих новых унифицированных данных. Это переломный момент в ландшафте мониторинга и наблюдаемости, и ближайшие несколько лет обещают быть чрезвычайно интересными.
У TelemetryHub , мы создаем новую платформу наблюдения на основе OpenTelemetry. Мы сосредоточены на предоставлении действенной информации, которая быстро выявляет проблемы, давая вашим разработчикам уверенность в решении проблем производительности во все более сложных приложениях и инфраструктуре.
