Azure Monitor- возможности и ограничения
Сегодня хотелось бы с вами поделиться заметкой, которая появилась в результате моего небольшого research на тему ключевых особенностей Azure Monitor.
Возможности
Опираясь на Microsoft docs описать ключевые возможности инструмента можно следующим образом:
- route - streaming данных между сервисами и функционал оповещения;
- store and arhive - хранилище данных;
- query - предоставление доступа к данным на чтение;
- visualize - визуализация, представление и аналитика;
- automate - автоматизация и триггеры процессов (autoscale, email, webhook);
Представленное ниже изображение характерно для вычисляемых (исполняемых) ресурсов и отличается от невычисляемых лишь наличием Application Logs and metrics.
Activity log
Данный раздел мониторинга содержит информацию об операциях, выполненных в рамках конкретных компонентов (ресурсов):
- Наименование (тип) операции;
- Кто её инициировал и когда она была завершена;
- Статусе её выполнения;
Кроме того, предоставляются возможности:
- Экспорта в Storage Account & Azure Event Hub;
- Доступа посредством PowerShell & REST API;
- Добавления правил оповещения;
- Анализа в PowerBI;
Metrics and Events
Кроме возможности отслеживать информацию о метриках и событиях используемых компонентов Azure также доступно добавление собственных custom metrics & events.
Если мы хотим предпринять действие основанное на значении метрики, то в этом нам поможет система оповещения и реагирования, в арсенале которой присутствует возможность отправлять email уведомления, вызывать webhook или запускать logic app (с помощью request trigger).
Log search
Благодаря log search и специализированному языку запросов доступна возможность выполнять query/filter/aggregate применимо к логам и метрикам, а также визуализировать итоговые результаты в требуемом виде (table, list, bar).
Autoscale
Горизонтальное масштабирование основанно на наступлении одного из двух видов условий:
- На основании значения метрики- например, увеличить количество запущенных экземпляров того или иного ресурса в случае превышения использования % CPU или загрузки ОЗУ;
- На основании расписания- например, если нагрузка в выходные дни снижается, то можно уменьшать и количество экземпляров до необходимого минимума;
Azure Service Health
Благодаря такому компоненту как Azure Service Health появляется возможность своевременно узнавать о технических работах и сбоях в инфраструктуре Azure, которые могут затронуть доступность развернутых в облаке сервисов и ресурсов. В качестве оповещений могут выступать уведомления по почте, телефону или webhook.
Также появляется возможность заблаговременно подготовиться к плановому обслуживанию Azure.
Ограничения
Задержка при отправке уведомлений о наступлении событий- ограничением это можно назвать весьма условно, однако, оповещение о срабатывании того или иного правила будет получено в интервале от одной до пяти минут.
Отсутствует вертикальное масштабирование- на данный момент возможно изменение количества запущенных экземпляров (как в большую, так и в меньшую сторону), но не их вычислительных мощностей. Связано это с накладываемыми на такой вид масштабирования ограничениями- возможные отсутствие аппаратных средств и необходимость перезапуска.
Не все Azure services на данный момент помещают информацию в Azure Monitor, однако, это будет реализовано в будущем.
Срок хранения metrics и activity log entry ограничен- он составляет 30 и 90 дней соответственно (для большей продолжительности необходимо подключить Azure storage).
Заключение
В заключении можно сказать, что рассмотренный в данной статье инструмент позволяет:
- Однозначно ответить кто, когда и какие действия выполнял применимо к ресурсам или инфраструктуре;
- Получить, проанализировать и визуализировать информацию о выполненных действиях;
- Добавлять набор правил и действий для реагирования при их наступлении;
Полезные ссылки: