Рекомендации по мониторингу и диагностике

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

Сценарии мониторинга и диагностики

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

• Убедитесь, что система остается работоспособной.

• Отслеживайте доступность системы и ее компонентов.

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

• Обеспечьте соответствие системы соглашениям об уровне обслуживания (SLA).

• Защита конфиденциальности и безопасности системы, пользователей и их данных.

• Отслеживайте аудиторские операции или операции по соблюдению нормативных требований.

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

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

• Отслеживайте операции и отлаживайте релизы ПО.

В следующих разделах подробно описаны эти сценарии.

Мониторинг здоровья

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

Настройка оповещений

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

• Красный — система неисправна (система остановилась)
• Желтый — для частичной работоспособности (система работает с ограниченной функциональностью)
• Зеленый для здорового

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

Сбор данных о состоянии

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

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

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

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

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

• Мониторинг конечных точек.

• Собирать фоновые данные о производительности, такие как фоновая загрузка ЦП или операции ввода-вывода, включая сетевую активность.

Анализ данных о здоровье

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

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

• Скорость запросов, направленных на каждую службу или подсистему
• Время отклика этих запросов
• Объем данных, которые передаются в каждую службу и из нее

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

Мониторинг доступности

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

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

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

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

Сбор данных о доступности

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

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

Анализ данных доступности

Агрегировать и сопоставлять данные для поддержки следующих типов анализа:

• Немедленная доступность системы и подсистемы.

• Частота сбоев доступности систем и подсистем. Сопоставляйте сбои с конкретными действиями, чтобы понять причины сбоя системы.

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

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

Вы можете вычислить процент доступности службы за период времени с помощью следующей формулы:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

Используйте эту формулу для мониторинга SLA. Определение простоя зависит от службы. Например, служба сборки Azure DevOps определяет время простоя в качестве периода, в течение которого служба сборки недоступна. Служба считается недоступной в течение одной минуты, если все непрерывные HTTP-запросы в течение этой минуты приводят к коду ошибки или не возвращают ответ.

Отслеживание производительности

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

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

Требования к мониторингу производительности

Для оценки производительности системы обычно требуются следующие сведения:

• Частота ответов для запросов пользователей
• Количество одновременных запросов пользователей
• Объем сетевого трафика
• Ставки, с которыми система завершает бизнес-транзакции
• Среднее время обработки запросов

Используйте средства, которые помогут определить следующие корреляции:

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

• Количество одновременных пользователей и среднее время отклика или продолжительность выполнения запроса после начала обработки

• Объем запросов и количество ошибок обработки

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

• Использование памяти
• Количество потоков
• Время обработки ЦП
• Длина очереди запроса
• Скорость и ошибки операций ввода-вывода на диске или сети
• Число записанных или прочитанных байтов
• Индикаторы посредующего слоя, такие как длина очереди

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

Сбор данных о производительности

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

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

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

Анализ данных о производительности

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

Еще одним общим требованием является обобщение данных о производительности в процентилях. Например, можно определить время отклика для 99% запросов, 95% запросов и 70% запросов. Вы можете задать целевые показатели SLA или другие цели для каждого процентиля. Сообщите о текущих результатах практически в реальном времени, чтобы быстро обнаружить проблемы. Обобщайте результаты с течением времени в статистических целях.

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

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

Мониторинг безопасности

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

• Все попытки входа и неудачные или успешные попытки входа

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

• Когда пользователь завершает сеанс и выходит из него

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

Требования к мониторингу безопасности

Данные, которые отслеживают мониторинг безопасности, помогут вам:

• Обнаружьте попытки вторжения неаутентифицированным объектом.

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

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

Для поддержки этих задач система должна отправлять оповещения, если:

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

• Одна учетная запись с проверкой подлинности неоднократно пытается получить доступ к запрещенной ресурсу в течение указанного периода.

• Большое количество неавторизованных или несанкционированных запросов происходит в течение указанного периода.

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

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

Сбор данных безопасности

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

Мониторинг безопасности может включать данные из средств за пределами приложения. К этим средствам относятся служебные программы, определяющие действия сканирования портов внешними агентствами и сетевыми фильтрами, которые обнаруживают попытки получить доступ к приложению и данным, не прошедшим проверку подлинности. В некоторых случаях средства непрерывной интеграции и непрерывной доставки (CI/CD) составляют важную часть жизненного цикла приложения. Эти средства также должны пометить аномальное поведение.

Анализ данных безопасности

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

Мониторинг SLA

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

Следующие метрики определяют соглашения об уровне обслуживания.

• Общая доступность системы. Например, организация может обязаться поддерживать доступность системы в 99,9% случаев. Этот процент соответствует не более девяти часов простоя в год или примерно 10 минут в неделю.

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

• Рабочее время отклика. Кроме того, системе может потребоваться обрабатывать запросы с определенной скоростью. Например, 99% всех бизнес-транзакций должны завершиться в течение 2 секунд, и ни одна транзакция не занимает более 10 секунд.

Требования к мониторингу соглашения об уровне обслуживания

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

Вы можете визуализировать следующие высокоуровневые индикаторы:

• Процент времени бесперебойной работы службы

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

• Количество успешных или неудачных запросов приложения

• Количество ошибок приложения и системы, исключений и предупреждений

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

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

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

Сбор данных об уровне обслуживания

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

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

Все данные должны содержать временные метки и таймстамп.

Анализ данных об уровне обслуживания

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

• Вычислите общее количество запросов пользователей в течение указанного периода и определите частоту успешности и сбоя этих запросов.

• Объедините время отклика запросов пользователей, чтобы создать общее представление времени ответа системы.

• Анализ хода выполнения запросов пользователей, чтобы разбить общее время отклика на время отклика отдельных рабочих элементов в запросе.

• Определите общую доступность системы в процентах от времени простоя в течение определенного периода.

• Проанализируйте процентное время доступности отдельных компонентов и служб в системе. Возможно, потребуется проанализировать журналы, созданные службами, не относящимися к Microsoft.

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

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

Auditing

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

Требования к аудиту

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

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

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

• Отчёты с подробной хронологией активности одного пользователя

• Отчеты, которые перечисляют последовательность операций, выполняемых для одного или нескольких ресурсов

Сбор данных аудита

К основным источникам информации для аудита относятся:

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

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

Анализ данных аудита

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

Мониторинг использования

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

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

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

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

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

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

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

Требования к мониторингу использования

Для оценки использования системы обычно требуются следующие сведения:

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

• Работа, выполняемая каждым пользователем

• Объем хранилища данных, которое занимает каждый пользователь

• Ресурсы, к которым обращается каждый пользователь

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

Сбор данных об использовании

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

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

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

Отслеживание проблем

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

Требования к отслеживанию проблем

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

Сбор данных отслеживания проблем

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

• Аварийный дамф, если приложение включает компонент, работающий на рабочем столе пользователя

• Моментальный снимок экрана

• Дата и время возникновения ошибки и другие сведения об окружающей среде, например расположение пользователя

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

Анализ данных отслеживания проблем

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

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

Если пользователь сообщает о проблеме, которая имеет известное решение в системе отслеживания проблем, вы можете немедленно сообщить пользователю о решении.

Трассировка операций и отладка релизов программного обеспечения

Когда пользователь сообщает о проблеме, он обычно осознаёт лишь непосредственные последствия, которые она имеет для его рабочих процессов. Пользователь может сообщать только результаты собственного опыта. Эти опыты обычно являются видимым симптомом одной или нескольких фундаментальных проблем. Во многих случаях аналитику необходимо проанализировать хронологию базовых операций, чтобы установить первопричину проблемы. Этот процесс называется анализом первопричин (RCA).

Требования к трассировке и отладке

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

Сбор данных трассировки и отладки

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

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

Конвейер мониторинга и диагностики

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

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

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

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

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

Источники данных мониторинга и диагностики

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

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

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

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

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

Если приложение использует другие внешние службы, например веб-сервер или систему управления базами данных (СУБД), эти службы могут публиковать собственные сведения трассировки, журналы и счетчики производительности. Например, динамические административные представления (DMVs) в SQL Server отслеживают операции, выполняемые в базе данных SQL Server. Application Insights использует журналы трассировки для записи запросов, направленных в Служба приложений Azure.

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

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

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

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

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

  Important

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

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

  Note

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

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

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

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

Для максимального охвата следует использовать сочетание этих методов.

Инструментирование приложения

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

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

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

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

Сведения о сопоставлении данных

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

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

Присваивайте всем данным мониторинга метки времени единообразно. Для согласованности запишите все даты и время с помощью UTC. Этот метод помогает легче отслеживать последовательности событий.

Сведения, которые следует включать в данные инструментирования

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

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

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

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

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

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

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

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

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

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

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

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

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

Наилучшие практики по инструментированию приложений

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

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

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

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

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

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

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

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

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

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

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

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

Сбор и хранение данных

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

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

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

Для Azure приложений и служб, работающих на виртуальных машинах, агент Azure Monitor предоставляет решение для записи данных. Вы определяете правила сбора данных (DCR), которые указывают данные для сбора данных из каждого вычислительного узла и рабочей области Log Analytics в Azure Monitor для отправки. Агент может собирать данные из следующих источников:

• журналы Службы интернет-информации (IIS)
• Журналы событий Windows
• Счетчики производительности
• Syslog с узлов Linux
• Текстовые журналы и журналы JSON, записываемые приложениями

Стратегии сбора данных инструментирования

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

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

Извлечение и отправка данных инструментирования

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

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

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

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

Локальная служба сбора данных может добавлять данные в очередь сразу после получения. Очередь выступает в качестве буфера, а служба записи в хранилище может получать и записывать данные в своём темпе. По умолчанию очередь работает по принципу "первым пришёл - первым вышел" (FIFO). Но вы можете определить приоритеты сообщений, чтобы ускорить их через очередь, если они содержат данные, которые необходимо быстро обрабатывать. Дополнительные сведения см. в шаблоне очереди приоритета. Кроме того, можно использовать различные каналы, такие как темы служебная шина, чтобы направлять данные в разные конечные точки в зависимости от того, какая форма аналитической обработки требуется.

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

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

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

Хранение данных инструментирования

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

Например, Хранилище BLOB-объектов Azure и Azure Table Storage имеют схожие модели доступа, но набор поддерживаемых ими операций ограничен, а уровень детализации хранимых в них данных различается. Если вам нужно выполнять аналитические операции или требовать возможности полнотекстового поиска, может потребоваться использовать хранилище данных, которое предоставляет следующие возможности запроса и доступа к данным:

• Сохраните данные счетчика производительности в базе данных SQL, чтобы включить незапланированный анализ.
• Храните журналы трассировки в Azure Cosmos DB.
• Запись сведений о безопасности в распределенную файловую систему Hadoop (HDFS).
• Храните информацию, требующую полнотекстового поиска, с помощью Elasticsearch, который использует расширенные возможности индексирования для ускорения поиска.

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

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

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

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

Ротация журналов и хранение данных

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

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

Уменьшение частоты выборки

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

Рекомендации по сбору и хранению информации из журналов логирования

В следующем списке приведены рекомендации по сбору и хранению сведений о ведении журнала.

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

• Все выходные данные агента мониторинга или службы сбора данных должны быть независимыми от компьютера, операционной системы или сетевого протокола. Например, выведите сведения в самоописающем формате, например JSON, MessagePack или Protobuf, а не файлы журнала трассировки событий (ETL) в Linux или ETW. Используйте стандартный формат, чтобы система может создавать конвейеры обработки. Вы можете легко интегрировать компоненты, которые считывают, преобразуют и отправляют данные в согласованном формате.

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

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

Анализ данных и диагностика проблем

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

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

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

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

Поддержка горячего, теплого и холодного анализа

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

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

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

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

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

Корреляция данных

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

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

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

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

Устранение неполадок и диагностика

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

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

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

Визуализация данных и создание оповещений

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

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

Визуализация с помощью панелей мониторинга

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

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

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

• Красный цвет для диска с частотой ввода-вывода, приближающейся к максимальной емкости в течение длительного периода или горячего диска

• Жёлтый — для диска, скорость операций ввода-вывода которого периодически достигает своего максимального предела на короткие промежутки времени, или для тёплого диска

• Зелёный — для диска с обычным уровнем использования

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

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

Создавать оповещения

Система оповещений анализирует данные мониторинга и инструментальные данные и формирует уведомление при обнаружении важного события.

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

Оповещения зависят от следующих данных инструментирования:

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

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

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

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

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

Отчеты

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

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

• Сводная статистика, которую можно использовать для анализа использования ресурсов

• Тенденции использования ресурсов

• Мониторинг исключений

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

Отчеты по безопасности отслеживают, как клиенты используют систему. Обычно он включает следующие аспекты:

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

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

Во многих случаях отчеты могут создаваться процессами пакетной обработки согласно заданному расписанию Создание отчетов обычно не увеличивает задержку, поэтому при необходимости можно создавать отчеты по запросу. При хранении данных в реляционной базе данных, например База данных SQL Azure, можно использовать средство, например SQL Server Reporting Services для извлечения и форматирования данных и представления их в виде набора отчетов.

Дальнейшие действия

• Общие сведения о службе Azure Monitor
• Мониторинг, диагностика и устранение неполадок хранилища
• Обзор оповещений в Azure
• Обзор Application Insights
• Диагностика производительности виртуальных машин Azure

Связанные ресурсы

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

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

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