Шаблон мониторинга конечных точек работоспособности

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

Контекст и проблема

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

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

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

Решение

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

Обычно проверка работоспособности выполняется по двум направлениям:

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

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

На следующем рисунке представлен обзор шаблона.

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

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

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

Типичные проверки выполнения средств мониторинга:

• Проверка кода ответа. Например, ответ HTTP 200 (ОК) означает, что приложение выполнено без ошибок. Система отслеживания может проверять и другие коды ответов, чтобы получить более полные результаты.
• Проверка содержимого ответа для обнаружения ошибок, даже если код состояния равен 200 (ОК). Проверив содержимое, можно обнаружить ошибки, влияющие только на раздел возвращаемой веб-страницы или ответа службы. Например, вы можете проверить название страницы или найти определенную фразу, указывающую, что приложение вернуло правильную страницу.
• Измерение времени отклика. Это значение включает задержку в сети и время, которое потребовалось приложению для выдачи запроса. Если это значение увеличивается, это может указывать на развитие проблем в приложении или сети.
• Проверка ресурсов или служб, расположенных за пределами приложения. Примером является сеть доставки содержимого, которую приложение использует для доставки содержимого из глобальных кэшей.
• Проверка срока действия сертификатов TLS.
• Измерение времени отклика поиска DNS для URL-адреса приложения. Эта проверка измеряет задержку DNS и сбои DNS.
• Проверка URL-адреса, возвращаемого подстановкой DNS. Проверяя, можно убедиться, что записи верны. Вы также можете предотвратить перенаправление вредоносных запросов, которые могут привести к атаке на DNS-сервере.

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

• Где развернуть приложение
• Развертывание в нескольких центрах обработки данных

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

Проблемы и рекомендации

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

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

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

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

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

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

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

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

  • Предоставление приложению вредоносных атак.
  • Риск раскрытия конфиденциальной информации.
  • Привлечение атак типа "отказ в обслуживании" (DoS).

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

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

  • Используйте замаскированные или скрытые конечные точки. Например, предоставляют конечную точку по другому IP-адресу, отличному от используемого URL-адресом приложения по умолчанию. Настройте конечную точку на нестандартном HTTP-порту. Кроме того, рекомендуется использовать сложный путь к тестовой странице. Обычно можно указать дополнительные адреса конечных точек и порты в конфигурации приложения. При необходимости можно добавить записи для этих конечных точек на DNS-сервер. Затем не нужно указывать IP-адрес напрямую.

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

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

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

Когда следует использовать этот шаблон

Этот шаблон можно использовать для следующих целей:

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

Проектирование рабочей нагрузки

Архитектор должен оценить, как шаблон мониторинга конечных точек работоспособности можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:

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

Пример

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

На сайте GitHub доступны несколько примеров реализаций, использующих проверки работоспособности ASP.NET.

Мониторинг конечных точек в размещенных в Azure приложениях

Варианты мониторинга конечных точек в приложениях Azure:

• Используйте встроенные функции мониторинга Azure, такие как Azure Monitor.
• Используйте стороннюю службу или платформу, например Microsoft System Center Operations Manager.
• Создайте пользовательскую служебную программу или службу, которая выполняется на собственном сервере или размещенном сервере.

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

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

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

Диспетчер трафика — это служба маршрутизации и балансировки нагрузки. Он может использовать ряд правил и параметров для распространения запросов в определенные экземпляры приложения. Помимо запросов маршрутизации, Диспетчер трафика регулярно могут выполнять связь с URL-адресом, портом и относительным путем. Целевые показатели связи указываются с целью определения активных экземпляров приложения и реагирования на запросы. Если Диспетчер трафика обнаруживает код состояния 200 (ОК), приложение помечается как доступное. Получив любой другой код состояния, диспетчер трафика отмечает приложение как неработоспособное. В консоли Диспетчер трафика отображается состояние каждого приложения. Вы можете настроить каждое правило для перенаправки запросов на другие экземпляры приложения, которые отвечают.

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

Следующие шаги

Для реализации этого шаблона полезно следующее руководство.

• Руководство по мониторингу работоспособности в приложениях на основе микрослужб
• Мониторинг работоспособности приложений для обеспечения надежности в azure Well-Architected Framework
• Создание нового правила генерации оповещений

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

• Шаблон внешнего хранилища конфигураций
• Шаблон размыкателя цепи
• Схема маршрутизации шлюза
• Шаблон gatekeeper