В программной инженерии , а точнее в распределенных вычислениях , наблюдаемость — это способность собирать данные о выполнении программ, внутренних состояниях модулей и коммуникации между компонентами. [1] [2] Для улучшения наблюдаемости инженеры-программисты используют широкий спектр методов регистрации и трассировки для сбора телеметрической информации, а также инструменты для ее анализа и использования. Наблюдаемость является основополагающей для проектирования надежности сайта , поскольку это первый шаг в сортировке сбоя обслуживания. Одна из целей наблюдаемости — минимизировать объем предварительных знаний, необходимых для отладки проблемы.
Термин заимствован из теории управления, где « наблюдаемость » системы измеряет, насколько хорошо ее состояние может быть определено из ее выходов. Аналогично, наблюдаемость программного обеспечения измеряет, насколько хорошо состояние системы может быть понято из полученной телеметрии (метрики, журналы, трассировки, профилирование).
Определение наблюдаемости различается у разных поставщиков:
мера того, насколько хорошо вы можете понять и объяснить любое состояние, в которое может прийти ваша система, независимо от того, насколько оно новое или странное [...] без необходимости отправки нового кода
— Соты [3]
программные инструменты и методы для агрегации, корреляции и анализа постоянного потока данных о производительности распределенного приложения, а также оборудования и сети, на которых оно работает
— IBM Instana [4]
Наблюдаемость начинается с отправки всех ваших необработанных данных в центральный сервис до начала анализа.
— Дельта Эджа [5]
способность измерять текущее состояние системы на основе генерируемых ею данных, таких как журналы, метрики и трассировки
— Динатрейс [6]
Наблюдаемость — это инструментарий или техническое решение, которое позволяет командам активно отлаживать свою систему. Наблюдаемость основана на исследовании свойств и шаблонов, которые не определены заранее.
— Google Облако [7]
проактивный сбор, визуализация и применение аналитики ко всем вашим метрикам, событиям, журналам и трассировкам, чтобы вы могли понять поведение вашей сложной цифровой системы
— Новая Реликвия [8]
Термин часто называют его нумеронимом o11y (где 11 обозначает количество букв между первой и последней буквой слова). Это похоже на другие аббревиатуры в компьютерной науке, такие как i18n, l10n и k8s . [9]
Наблюдаемость и мониторинг иногда используются как взаимозаменяемые понятия. [10] По мере того, как инструменты, коммерческие предложения и практики становились все сложнее, «мониторинг» был переименован в наблюдаемость, чтобы отличать новые инструменты от старых.
Термины обычно противопоставляются в том смысле, что системы контролируются с использованием предопределенных наборов телеметрии [7] , а контролируемые системы могут быть наблюдаемыми [11] .
Мейджорс и др. предполагают, что инженерные группы, имеющие только инструменты мониторинга, в конечном итоге полагаются на экспертное предвидение (старшинство), тогда как группы, имеющие инструменты наблюдения, полагаются на исследовательский анализ (любопытство). [3]
Наблюдаемость опирается на три основных типа телеметрических данных: метрики, журналы и трассировки. [6] [7] [12] Их часто называют «столпами наблюдаемости». [13]
Метрика — это измерение в определенный момент времени ( скаляр ), которое представляет некоторое состояние системы. Примеры общих метрик включают:
Инструменты мониторинга обычно настроены на отправку оповещений, когда определенные значения показателей превышают установленные пороговые значения. Пороговые значения устанавливаются на основе знаний о нормальных условиях эксплуатации и опыта.
Метрики обычно помечаются тегами для облегчения группировки и поиска.
Разработчики приложений выбирают, какими метриками оснащать свое программное обеспечение, до его выпуска. В результате, когда возникает ранее неизвестная проблема, невозможно добавить новые метрики без отправки нового кода. Более того, их мощность может быстро сделать размер хранилища телеметрических данных непозволительно дорогим. Поскольку метрики ограничены мощностью, они часто используются для представления агрегированных значений (например, среднее время загрузки страницы или 5-секундное среднее значение частоты запросов). Без внешнего контекста невозможно сопоставить события (например, запросы пользователей) и отдельные значения метрик.
Журналы или строки журнала, как правило, представляют собой неструктурированные текстовые блоки свободной формы [ требуется пояснение ] , предназначенные для чтения человеком. Современное ведение журнала структурировано для обеспечения возможности машинного анализа. [3] Как и в случае с метриками, разработчик приложения должен заранее инструментировать приложение и поставлять новый код, если требуется другая информация для ведения журнала.
Журналы обычно включают временную метку и уровень серьезности. Событие (например, запрос пользователя) может быть фрагментировано по нескольким строкам журнала и переплетаться с журналами параллельных событий.
Облачное приложение обычно состоит из распределенных служб, которые вместе выполняют один запрос. Распределенная трассировка — это взаимосвязанная серия дискретных событий (также называемых интервалами), которые отслеживают ход выполнения одного запроса пользователя. [3] Трассировка показывает причинно-следственные и временные связи между службами, которые взаимодействуют для выполнения запроса.
Оснащение приложения трассировками означает отправку информации о диапазоне в бэкэнд трассировки. Бэкэнд трассировки сопоставляет полученные диапазоны для создания презентабельных трасс. Чтобы иметь возможность отслеживать запрос, когда он проходит через несколько служб, диапазоны помечаются уникальными идентификаторами , которые позволяют строить родительско-дочерние отношения между диапазонами. Информация о диапазоне обычно передается в заголовках HTTP исходящих запросов. [3] [14] [15]
Непрерывное профилирование — еще один тип телеметрии, используемый для точного определения того, как приложение потребляет ресурсы. [16]
Чтобы иметь возможность наблюдать за приложением, необходимо собирать или экспортировать телеметрию о поведении приложения. Инструментирование означает генерацию телеметрии наряду с нормальной работой приложения. [3] Затем телеметрия собирается независимым бэкэндом для последующего анализа.
В быстро меняющихся системах контрольно-измерительные приборы сами по себе часто являются наилучшей возможной документацией, поскольку они сочетают намерение (какие измерения назвал инженер и решил собрать?) с актуальной информацией в режиме реального времени о текущем состоянии производства. [3]
Инструментарий может быть автоматическим или индивидуальным. Автоматический инструментарий обеспечивает полное покрытие и немедленную ценность; индивидуальный инструментарий приносит большую ценность, но требует более тесного взаимодействия с инструментированным приложением.
Инструментирование может быть собственным — выполняемым в коде (изменение кода инструментируемого приложения) — или внешним (например, sidecar, eBPF ).
Проверка новых функций в процессе производства путем их поставки вместе с пользовательским инструментарием — это практика, называемая «разработка, основанная на наблюдаемости». [3]
Метрики, журналы и трассировки чаще всего упоминаются как столпы наблюдаемости. [13] Мэйджорс и др. предполагают, что столпы наблюдаемости — это высокая кардинальность, высокая размерность и исследуемость, утверждая, что рабочие журналы и панели мониторинга не имеют большой ценности, поскольку «современные системы редко выходят из строя дважды одним и тем же образом». [3]
Самоконтроль — это практика, при которой стеки наблюдаемости контролируют друг друга, чтобы снизить риск незаметных сбоев. Самоконтроль может быть реализован в дополнение к высокой доступности и избыточности, чтобы еще больше избежать коррелированных сбоев.