Рекомендации по инструментированию приложения

Применяется к этой контрольной рекомендации по операционному превосходству в Azure Well-Architected Framework:

Связанное руководство. Рекомендации по проектированию и созданию системы мониторинга

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

Основные стратегии проектирования

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

• Журналы — это записи метки времени дискретных событий. Существует три формы журналов: обычный текст, структурированный и двоичный файлы.

• Распределенные журналы трассировки позволяют просматривать путь запроса по мере перемещения по различным службам и компонентам.

• Метрики — это числовые значения, описывающие аспект системы в определенный момент времени.

Использование структурированных журналов и трассировки

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

Журналы трассировки содержат текстовые данные или двоичные данные, созданные из события трассировки, если приложение использует трассировку событий для Windows (ETW). Системные журналы создают содержимое журнала трассировки из событий в инфраструктуре, например веб-сервера. Содержимое текстового журнала предназначено для чтения людьми, но вы должны убедиться, что он написан в формате, который автоматизированная система также может анализировать.

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

Сбор метрик приложения

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

Упрощение корреляции между компонентами

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

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

Все данные мониторинга следует снабжать единообразной меткой времени. Для обеспечения согласованности регистрируйте даты и время в формате UTC.

Сбор соответствующих данных

Рассмотрим следующие моменты, когда вы решите, какие данные инструментирования необходимо собрать.

Данные, доступные для чтения человеком

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

Включите в данные следующие экологические сведения:

• Среда развертывания
• Компьютер обработки
• Сведения о процессе
• Стек вызовов

Инвестиции в возможность трассировки и корреляции

Укажите достаточный контекст, например идентификатор действия, связанный с определенным экземпляром запроса, чтобы разработчик или администратор могли определить источник каждого запроса.

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

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

Запись всех соответствующих данных

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

Тщательно регистрируйте и фиксируйте сведения об исключениях. Критически важные сведения об отладке часто теряются из-за плохой обработки исключений. Захватить все сведения об исключении, которые вызывает приложение, включая любые внутренние исключения или другие контекстные сведения, например стек вызовов, если это возможно.

Стремиться к согласованности данных

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

Сбор данных, таких как объем входных и выходных данных, количество запросов, памяти, сети и использования ЦП, из ключевых счетчиков производительности. Некоторые службы инфраструктуры предоставляют собственные счетчики производительности, такие как:

• количество подключений к базе данных;
• Скорость транзакции.
• количество успешно выполненных или неудачных транзакций.

Приложения также могут определять собственные счетчики производительности.

Рассмотрим внешние зависимости

Регистрируют все вызовы внешних служб. Внешние вызовы могут выполняться следующими способами:

• Системы баз данных.
• Веб-службы.
• Другие системные службы, которые являются частью инфраструктуры.

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

Обеспечение совместимости системы телеметрии

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

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

• Имя события.
• Время события.
• IP-адрес отправителя.
• Сведения, необходимые для корреляции событий, включая:
  • Идентификатор пользователя
  • Идентификатор устройства
  • Application ID

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

• Сведения об исключениях.
• События запуска и завершения приложения.
• Успешное или неудачное выполнение вызовов API веб-службы.

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

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

Оптимизация кода инструментирования

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

• Обеспечьте простоту чтения и анализа журналов. По возможности используйте структурированное ведение журналов.

• Используйте краткие и содержательные сообщения журнала.

• Определите источник журнала.

• Добавьте сведения о метке времени при записи каждой записи журнала.

• Используйте один часовой пояс и формат для всех меток времени.

• Классифицируйте журналы и записывайте сообщения в соответствующем месте.

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

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

• Фиксируйте и регистрируйте все сведения о логике повторных попыток. Эти данные полезны для мониторинга временной работоспособности системы.

• Осуществляйте трассировку вызовов процесса, например запросов к внешним веб-службам или базе данных.

• Не смешивайте сообщения журнала с различными требованиями к безопасности в одном файле журнала.

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

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

• Убедитесь, что все ведение журнала небезопасно и не активирует каскадные ошибки.

• Регулярно рассматривайте инструментирование как текущий итеративный процесс и просматривайте журналы.

Использование профилирования приложений

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

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

Упрощение функций Azure

Автоинструментация доступна для многих типов Azure и локальных приложений, отслеживаемых с помощью Application Insights. Функция автоинструментации автоматически настраивает приложение для предоставления полнофункциональные данные телеметрии Application Insights и обеспечивает простой доступ к таким функциям, как панель мониторинга приложений и карта приложений. Поддерживаемые платформы размещения и языки разработки см. в статье "Поддерживаемые среды", "Языки" и поставщики ресурсов.

Дополнительные ссылки

• Общие сведения об Application Insights
• Что такое автоинструментация для Application Insights?
• Общие сведения о журналах Azure Monitor
• Обзор метрик Azure Monitor
• Сбор событий ETW для анализа журналов Azure Monitor
• Рекомендации по проектированию и созданию платформы наблюдаемости
• Что такое корреляция распределенной трассировки и телеметрии?

Ссылки на ресурсы сообщества

• OpenTelemetry

Контрольный список операционных знаний

Ознакомьтесь с полным набором рекомендаций.