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

  • Статья

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

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

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

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

Ключевые стратегии проектирования

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

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

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

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

Примечание

Для автоматического инструментирования приложения можно использовать такие средства, как Application Insights, Dynatrace и мониторинг производительности эластичных приложений. Эти средства упрощают инструментирование, но также могут быть ограничивающими. Если вы используете средство автоматического инструментирования, при необходимости можно добавить дополнительные возможности с помощью инструментирования вручную.

Журналы и журналы распределенной трассировки

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

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

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

Примечание

Журнал может быть реализован как файл в файловой системе или храниться в другом формате, например в хранилище BLOB-объектов. Сведения журнала также могут храниться в структурированном хранилище, например в строках таблицы.

Метрики

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

Сведения о корреляции данных

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

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

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

Примечание

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

Какие сведения должны входить в данные инструментирования

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

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

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

Включите в данные следующие сведения об окружающей среде:

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

Инвестиции в отслеживание и корреляцию

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

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

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

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

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

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

Обеспечение согласованности данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации

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

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

Упрощение поддержки Azure

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

Контрольный список эффективности операций

См. полный набор рекомендаций.

Контрольный список эффективности операций