Наблюдаемость в Azure с помощью OpenTelemetry: практическое руководство

Наблюдаемость — это способность объяснить внутреннее состояние системы по доказательствам, которые она сама создает. Ее цель состоит не в том, чтобы собирать все подряд. Она должна помогать команде замечать ущерб для клиентов, находить ответственную зависимость, понимать, что изменилось, безопасно восстанавливать работу и делать выводы до следующего происшествия. Azure Monitor, Application Insights и Log Analytics предоставляют технические возможности, а OpenTelemetry — переносимые правила и средства измерения. Ни один из них не заменяет правильной организации эксплуатации.

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

Начните с путей пользователя, а затем подбирайте журналы, показатели и трассировку

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

Двигайтесь от пути пользователя в обратном направлении. Для цели оформления заказа могут понадобиться доля завершения, задержка p95 и ошибки платежей; трассировка через API, очередь и поставщика; а также упорядоченные журналы для сверки. Одна лишь загрузка процессора не скажет, достигли ли клиенты цели. В то же время запись каждого содержимого создает риски для конфиденциальности и стоимости, не улучшая диагностику.

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

Сделайте OpenTelemetry устойчивым слоем измерения

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

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

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

Исследуйте поведение приложения через Application Insights

Application Insights может показывать запросы и зависимости, исключения, результаты проверки доступности, производительность браузера и распределенные пути в Azure Monitor. Определите устройство ресурсов до подключения служб: границы сред и ответственности, регионы, использование рабочих областей, доступ, сроки хранения и потребность совместно запрашивать несколько служб. Не создавайте один неразделенный ресурс, в котором права, расходы и границы происшествия становятся неясными.

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

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

Используйте Log Analytics с четкой целью запросов и хранения

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

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

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

Сохраняйте связь событий на каждой асинхронной границе

На всех поддерживаемых границах придерживайтесь контекста трассировки W3C и явно переносите его через HTTP, сообщения и запланированные задания. Участок отправителя должен быть связан с обработкой получателем, но время ожидания в очереди не следует выдавать за выполнение на сервере. Сохраняйте идентификаторы сообщений и деловых объектов для сверки, однако не используйте значения с огромным числом вариантов как измерения показателей.

Повторные попытки, пакеты и разветвления требуют явной модели. Записывайте номер попытки, причину повтора и окончательный результат; связывайте работу ссылками, когда строгое дерево «родитель-потомок» искажает действительность. Измеряйте базу данных и внешние вызовы по безопасным названиям операций, а не по необработанным выражениям или URL. Убедитесь, что асинхронные среды и обновления средств разработки незаметно не теряют контекст.

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

Стройте оповещения и панели вокруг решений

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

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

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

Управляйте стоимостью телеметрии и связывайте ее с работой над происшествиями

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

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

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

Когда стоит пригласить независимых специалистов по наблюдаемости

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

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

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

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