Упражнение. Определение состояния работоспособности, метрик и пороговых значений
В этом упражнении мы продолжаем структуру модели работоспособности, созданную ранее. Задача состоит в том, чтобы квалифицировать состояния работоспособности отдельных компонентов для примера приложения.
В структуре модели работоспособности начните с оценки слоев, начиная с верхней части с пользовательскими потоками, и перейдите к более низким уровням.
Состояние работоспособности потока пользователя
До сих пор мы определили два потока пользователей: элементы каталога списка и добавление комментариев. Чтобы определить состояния работоспособности для каждого потока, задайте такие вопросы, как:
- Когда поток пользователя считается работоспособным?
- Может ли он работать в деградируемом состоянии?
На основе требований к реализации и функциональным требованиям определите компоненты приложения, участвующие в потоке пользователя. Компоненты описаны в примерах компонентов архитектуры.
| Поток пользователя | Компоненты |
|---|---|
| Список элементов каталога | Интерфейсное внутреннее веб-приложение, API каталога |
| Добавление комментария | Интерфейсное внутреннее веб-приложение, API каталога, фоновый процессор |
Если любой из этих компонентов станет неработоспособным, то ожидается, что поток пользователя станет неработоспособным.
Примечание.
Некоторые приложения могут работать в специальном режиме снижения производительности . Например, если Contoso Shoes реализует кэширование локального браузера, сотрудники, использующие веб-приложение, могут создавать комментарии, но не могут отправляться комментарии, а представление клиента не обновляется до тех пор, пока API каталога не станет работоспособным, что браузер может непрерывно проверять.
Состояние работоспособности компонента приложения
Определите метрики, которые способствуют состоянию работоспособности компонента. Для этого шага необходимо знать функциональные возможности компонента. Задайте такие вопросы:
- Какое время обработки в API приемлемо для поддержания хорошего взаимодействия с пользователем?
- Есть ли ожидаемые ошибки? Что такое "обычная" частота ошибок?
- Что такое обычное время обработки? Что означает, если время обработки выше нормального?
- Что происходит с операциями записи, если Azure Cosmos DB недоступен?
Эти вопросы должны привести к конкретным и измеримым пороговым значениям для ключевых метрик. Например, можно рассмотреть эти пороговые значения для компонента API каталога.
| Метрики и пороговые значения | Состояние работоспособности |
|---|---|
| Время < отклика 150 мс число неудачных запросов < 10 | Работоспособно |
| Время < отклика 300 мс Число неудачных запросов < 50 | Деградация |
| Время > отклика 300 мс Число неудачных запросов > 50 | Unhealthy |
Значения можно получить из решения мониторинга приложений, например Application Insights.
Состояние работоспособности ресурсов Azure
Состояния работоспособности службы Azure основаны на определенных ресурсах. Например, Azure Cosmos DB сообщает об использовании единицы транзакций базы данных (DTU), а службы приложение Azure предоставляют сведения об использовании ЦП.
Сведения о метриках по типу ресурса см. в статье "Поддерживаемые метрики" в Azure Monitor.
Состояния работоспособности и пороговые значения
После оценки всех уровней приложения у вас должен быть список компонентов и их определения состояния работоспособности, которые выглядят примерно так же, как в этом примере.
| Компонент | Индикатор или метрика | Работоспособно | Деградация | Unhealthy |
|---|---|---|---|---|
| Поток пользователя элементов списка элементов каталога | Базовое состояние работоспособности | Работоспособное интерфейсное интерфейсное и работоспособное API каталога | ||
| Добавление потока пользователя примечания | Базовое состояние работоспособности | Интерфейс работоспособный, API каталога работоспособный и фоновый процессор | ||
| Интерфейсное веб-приложение | # от 20x http-ответов/мин | 0 | 1–10 | > 10 |
| API каталога | # исключений/с | < 10 | 10:50 | > 10 |
| Среднее время обработки (мс) | < 150 | 150-500 | > 500 | |
| Фоновый процессор | Среднее время в очереди (мс) | < 200 | 200-1,000 | > 1000 |
| Среднее время обработки (мс) | < 100 | 100-200 | > 200 | |
| Число сбоев | < 3 | 3-10 | > 10 | |
| Azure Cosmos DB | Использование DTU | < 70% | 70%-90% | > 90 % |
| Azure Key Vault | Число сбоев | < 3 | 3-10 | > 10 |
| Центры событий Azure | Длина невыполненной обработки (исходящие и входящие сообщения) | < 3 | 3-20 | > 20 |
| Хранилище BLOB-объектов Azure | Средняя задержка (мс) | < 100 | 100-200 | > 200 |
В этом примере погрешность для интерфейсного веб-приложения и API каталога отличается. Это различие относится к техническому пониманию приложения. Все ошибки внешнего интерфейса должны обрабатываться на стороне клиента, поэтому имеется нулевое пороговое значение. Однако на уровне API 10 исключений разрешено учитывать ошибки, вызванные пользователем. Например, ошибки, такие как 404- Не найдено , не обязательно указывают на проблему работоспособности.