Мониторинг Azure Front Door
Azure Monitor собирает и агрегирует метрики и журналы из системы для мониторинга доступности, производительности и устойчивости, а также уведомляет вас о проблемах, влияющих на систему. Вы можете использовать портал Azure, PowerShell, Azure CLI, REST API или клиентские библиотеки для настройки и просмотра данных мониторинга.
Различные метрики и журналы доступны для различных типов ресурсов. В этой статье описываются типы данных мониторинга, которые можно собирать для этой службы и способы анализа этих данных.
Отчеты содержат сведения о том, как трафик проходит через Azure Front Door, брандмауэр веб-приложения (WAF) и приложение.
Внимание
Azure Front Door (классическая версия) будет прекращена 31 марта 2027 г. Чтобы избежать нарушений работы служб, важно перенести профили Azure Front Door (классический) на уровень Azure Front Door standard или Premium к марту 2027 года. Дополнительные сведения см. в статье azure Front Door (классическая версия) для выхода на пенсию.
Сбор данных с помощью Azure Monitor
В этой таблице описывается, как собирать данные для мониторинга службы и что можно сделать с данными после сбора:
| Данные, которые нужно собрать | Description | Сбор и маршрутизация данных | Где просмотреть данные | Поддерживаемые данные |
|---|---|---|---|---|
| Данные метрик | Метрики — это числовые значения, описывающие аспект системы в определенный момент времени. Метрики можно агрегировать с помощью алгоритмов, по сравнению с другими метриками и анализировать для тенденций с течением времени. | — собирается автоматически через регулярные интервалы. — Вы можете направлять некоторые метрики платформы в рабочую область Log Analytics для запроса с другими данными. Проверьте параметры экспорта DS для каждой метрики, чтобы узнать, можно ли использовать параметр диагностики для маршрутизации данных метрик. |
Обозреватель метрик | Метрики Azure Front Door, поддерживаемые Azure Monitor |
| Данные журнала ресурсов | Журналы записывают системные события с меткой времени. Журналы могут содержать различные типы данных, а также структурировать или текст свободной формы. Данные журнала ресурсов можно направлять в рабочие области Log Analytics для запроса и анализа. | Создайте параметр диагностики для сбора и маршрутизации данных журнала ресурсов. | Служба Log Analytics | Данные журнала ресурсов Azure Front Door, поддерживаемые Azure Monitor |
| Данные журнала действий | Журнал действий Azure Monitor содержит сведения о событиях уровня подписки. Журнал действий включает информацию, например, об изменении ресурса или запуске виртуальной машины. | — собирается автоматически. - Создайте параметр диагностики для рабочей области Log Analytics без платы. |
Журнал действий |
Список всех данных, поддерживаемых Azure Monitor, см. в следующих статье:
Встроенный мониторинг Для Azure Front Door
Журналы отслеживают все запросы, проходящие через Azure Front Door. Для обработки и хранения журналов может потребоваться несколько минут.
Существует несколько журналов Front Door, которые можно использовать для различных целей:
- Журналы доступа можно использовать для выявления медленных запросов, определения частоты ошибок и понимания того, как поведение кэширования Front Door работает для вашего решения.
- Журналы брандмауэра веб-приложений (WAF) можно использовать для обнаружения потенциальных атак и ложных срабатываний, которые могут указывать на допустимые запросы, заблокированные WAF. Дополнительные сведения о журналах WAF см. в статье Azure Брандмауэр веб-приложений мониторинга и ведения журнала.
- Журналы проб работоспособности можно использовать для идентификации источников, которые являются неработоспособными или не отвечают на запросы некоторых географически распределенных poPs Front Door.
- Журналы действий обеспечивают видимость операций, выполняемых в ресурсах Azure, таких как изменения конфигурации профиля Azure Front Door.
Журналы доступа и журналы WAF включают ссылку на отслеживание, которая также распространяется в запросах на источники и ответы клиента с помощью заголовкаX-Azure-Ref. Вы можете использовать ссылку на отслеживание для получения комплексного представления обработки запросов приложения.
По умолчанию журналы доступа, журналы проб работоспособности и журналы WAF не включены. Сведения о включении и хранении журналов диагностики см. в статье "Настройка журналов Azure Front Door". Записи этого журнала собираются по умолчанию, и их можно просмотреть на портале Azure.
журнал доступа;
Сведения о каждом запросе вошли в журнал доступа. Каждая запись журнала доступа содержит сведения, перечисленные в следующей таблице.
| Свойство | Description |
|---|---|
| TrackingReference | Уникальная строка ссылки, которая идентифицирует запрос, обслуженный Azure Front Door. Ссылка на отслеживание отправляется клиенту и источнику с помощью X-Azure-Ref заголовков. Используйте ссылку на отслеживание при поиске определенного запроса в журналах доступа или WAF. |
| Время | Дата и время, когда пограничный сервер Azure Front Door доставил запрошенное содержимое клиенту (в формате UTC). Для подключений WebSocket время представляется при закрытии соединения. |
| HttpMethod | Метод HTTP, используемый запросом: DELETE, GET, HEAD, OPTIONS, PATCH, POST или PUT. |
| HttpVersion | Версия HTTP, указанная клиентом в запросе. |
| RequestUri | Универсальный код ресурса (URI) полученного запроса. Это поле содержит полную схему, порт, домен, путь и строку запроса. |
| HostName | Имя узла в запросе от клиента. Если вы включаете пользовательские домены и имеете подстановочный знак (*.contoso.com), значение поля журнала HostName имеет значение subdomain-from-client-request.contoso.com. Если вы используете домен Azure Front Door (contoso-123.z01.azurefd.net), значение поля журнала HostName имеет значение contoso-123.z01.azurefd.net. |
| RequestBytes | Размер сообщения с HTTP-запросом в байтах, включая заголовки и текст запроса. Для подключений WebSocket это значение — общее количество байтов, отправляемых клиентом на сервер через подключение. |
| ResponseBytes | Размер сообщения HTTP-ответа в байтах. Для подключений WebSocket это значение — общее количество байтов, отправляемых с сервера клиенту через подключение. |
| UserAgent | Агент пользователя, используемый клиентом. Как правило, агент пользователя определяет тип браузера. |
| ClientIp | IP-адрес клиента, от которого исходит оригинальный запрос клиента. Если в запросе X-Forwarded-For был заголовок, то IP-адрес клиента берется из заголовка. |
| SocketIp | IP-адрес прямого подключения к пограничному краю Azure Front Door. Если клиент для отправки запроса использовал прокси-сервер HTTP или подсистему балансировки нагрузки, значение SocketIp — это IP-адрес прокси-сервера или балансировщика нагрузки. |
| TimeTaken | Длительность от момента, когда пограничный сервер Azure Front Door получил запрос клиента до последнего байта ответа, измеряемого клиентом в секундах. Эта метрика исключает задержку сети и буферизацию TCP. Для подключений WebSocket он представляет длительность подключения от создания до закрытия. |
| RequestProtocol | Протокол, указанный клиентом в запросе. Возможные значения: HTTP, HTTPS. Для WebSocket протоколы — WS, WSS. Только запросы, которые успешно обновляются до WebSocket, имеют WS/WSS. |
| SecurityProtocol | Версия протокола TLS/SSL, используемая запросом или значение NULL, если запрос не использовал шифрование. Возможные значения: SSLv3, TLSv1, TLSv1.1, TLSv1.2. |
| SecurityCipher | Если значение протокола запроса — HTTPS, это поле указывает шифр TLS/SSL, согласованный клиентом и Azure Front Door. |
| Конечная точка | Доменное имя конечной точки Azure Front Door, например contoso-123.z01.azurefd.net. |
| HttpStatusCode | Код состояния HTTP, полученный от Azure Front Door. Если время ожидания запроса к источнику истекло, значение поля HttpStatusCode равно 0. Если клиент закрыл подключение, значение поля HttpStatusCode равно 499. |
| Pop | Граничная точка присутствия Azure Front Door (PoP), которая ответила на запрос пользователя. |
| Состояние кэша | Как кэш Azure Front Door обрабатывает запрос. Возможные значения:
|
| MatchedRulesSetName | Имена правил обработчика правил, которые были обработаны. |
| Имя маршрута | Имя маршрута, которому соответствует запрос. |
| ClientPort | IP-порт клиента, отправившего запрос. |
| Referrer | URL-адрес сайта, откуда исходит запрос. |
| TimetoFirstByte | Продолжительность времени в секундах, от момента, когда край Azure Front Door получил запрос до момента, когда первый байт был отправлен клиенту, как измеряется Azure Front Door. Это свойство не учитывает данные клиента. |
| ErrorInfo | Если во время обработки запроса произошла ошибка, это поле содержит подробные сведения об ошибке. Возможные значения:
|
| OriginURL | Полный URL-адрес источника, в котором был отправлен запрос. URL-адрес состоит из схемы, заголовка узла, порта, пути и строки запроса. Перезапись URL-адреса: если обработчик правил перезаписывает URL-адрес запроса, путь ссылается на путь перезаписи. Кэш на пограничном сервере PoP: если запрос был обработан из кэша Azure Front Door, источник — N/A. Большой запрос: если запрошенное содержимое большое и существует несколько блокированных запросов, возвращаемых в источник, это поле соответствует первому запросу источника. Дополнительные сведения см. в разделе "Блокирование объектов". |
| OriginIP | IP-адрес источника, обслуживающего запрос. Кэш на пограничном сервере PoP: если запрос был обработан из кэша Azure Front Door, источник — N/A. Большой запрос: если запрошенное содержимое большое и существует несколько блокированных запросов, возвращаемых в источник, это поле соответствует первому запросу источника. Дополнительные сведения см. в разделе "Блокирование объектов". |
| OriginName | Полное имя узла (DNS-имя) источника. Кэш на пограничном сервере PoP: если запрос был обработан из кэша Azure Front Door, источник — N/A. Большой запрос: если запрошенное содержимое большое и существует несколько блокированных запросов, возвращаемых в источник, это поле соответствует первому запросу источника. Дополнительные сведения см. в разделе "Блокирование объектов". |
| Результат |
SSLMismatchedSNI — это код состояния, который обозначает успешный запрос с предупреждением о несоответствии между SNI и заголовком узла. Этот код состояния подразумевает интерфейс домена, метод, который нарушает условия обслуживания Azure Front Door. Запросы с SSLMismatchedSNI будут отклонены после 22 января 2024 г. |
| Sni | Это поле указывает указание имени сервера (SNI), которое отправляется во время подтверждения TLS/SSL. Его можно использовать для идентификации точного SSLMismatchedSNI значения SNI, если был код состояния. Кроме того, его можно сравнить со значением узла в requestUri поле для обнаружения и устранения проблемы несоответствия. |
Журнал проверки работоспособности
Azure Front Door регистрирует все неудачные запросы пробы работоспособности. Эти журналы помогают диагностировать проблемы с источником. Журналы предоставляют сведения, которые можно использовать для изучения причины сбоя, а затем вернуть источник в работоспособное состояние.
Ниже рассматриваются несколько сценариев, в которых будет полезен этот журнал.
- Вы заметили, что трафик Azure Front Door был отправлен в подмножество источников. Например, вы можете заметить, что только три из четырех источников получают трафик. Вы хотите знать, получают ли источники и отвечают на пробы работоспособности, чтобы вы знали, являются ли источники здоровыми.
- Вы заметили, что метрика процента работоспособности источника ниже, чем ожидалось. Вы хотите знать, какие источники записываются как неработоспособные и причина сбоев пробы работоспособности.
Каждая запись журнала проб работоспособности имеет следующую схему:
| Свойство | Description |
|---|---|
| HealthProbeId | Уникальный идентификатор для идентификации запроса пробы работоспособности. |
| Время | Дата и время отправки пробы работоспособности (в формате UTC). |
| HttpMethod | Метод HTTP, используемый запросом пробы работоспособности. Значения включают GET и HEAD на основе конфигурации пробы работоспособности. |
| Результат | Состояние пробы работоспособности. Значением является успешное или описание ошибки, полученной пробой. |
| HttpStatusCode | Код состояния HTTP, возвращаемый источником. |
| ProbeURL | Полный целевой URL-адрес, в который был отправлен запрос пробы. URL-адрес состоит из схемы, заголовка узла, пути и строки запроса. |
| OriginName | Имя источника, в который была отправлена проба работоспособности. Это поле помогает найти источники, интересующие вас, если источник настроен для использования полного доменного имени. |
| POP | Пограничный poP, отправляющий запрос пробы. |
| Исходный IP-адрес | IP-адрес источника, в который была отправлена проба работоспособности. |
| TotalLatency | Время, когда пограничный сервер Azure Front Door отправил запрос пробы работоспособности источнику, когда источник отправил последний ответ в Azure Front Door. |
| ConnectionLatency | Время, затраченное на настройку TCP-подключения для отправки запроса пробы HTTP в источник. |
| DNSResolution Latency | Время, затраченное на разрешение DNS. Это поле имеет только значение, если источник настроен на полное доменное имя вместо IP-адреса. Если источник настроен для использования IP-адреса, значение равно N/A. |
В следующем примере фрагмента JSON показана запись журнала проб работоспособности для запроса пробы работоспособности сбоем.
{
"records": [
{
"time": "2021-02-02T07:15:37.3640748Z",
"resourceId": "/SUBSCRIPTIONS/mySubscriptionID/RESOURCEGROUPS/myResourceGroup/PROVIDERS/MICROSOFT.CDN/PROFILES/MyProfile",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "http://www.example.com:80/",
"originName": "www.example.com",
"originIP": "PublicI:Port",
"totalLatencyMilliseconds": "141",
"connectionLatencyMilliseconds": "68",
"DNSLatencyMicroseconds": "1814"
}
}
]
}
Журнал брандмауэра веб-приложения
Дополнительные сведения о журналах брандмауэра веб-приложений Front Door (WAF) см. в статье azure Брандмауэр веб-приложений мониторинга и ведения журнала.
Для классической версии Azure Front Door встроенный мониторинг включает журналы диагностики.
Журналы диагностики
Журналы диагностики предоставляют широкие сведения об операциях и ошибках, полезные для аудита и (или) устранения неполадок. Журналы диагностики отличаются от журналов действий.
Журналы действий позволяют анализировать операции, выполненные с ресурсами Azure. Журналы диагностики предоставляют аналитические сведения об операциях, выполняемых вашим ресурсом. См. дополнительные сведения о журналах диагностики Azure Monitor.
Чтобы настроить журналы диагностики для Azure Front Door (классическая модель):
Выберите профиль Azure Front Door (классическая модель).
Выберите Параметры диагностики.
Выберите Включить диагностику. Вы можете архивировать журналы диагностики и метрики в учетную запись хранения, передать их потоком в концентратор событий или отправить в журналы Azure Monitor.
В настоящее время Front Door предоставляет журналы диагностики. Журналы диагностики содержат сведения о каждом запросе к API со следующей схемой.
| Свойство | Description |
|---|---|
| BackendHostname | Если запрос пересылается в серверную часть, это поле представляет имя узла серверной части. Это поле пусто, если запрос перенаправляется или перенаправляется в региональный кэш (при включении кэширования для правила маршрутизации). |
| CacheStatus | В сценариях кэширования в этом поле определяются попадание или промахи кэша в точке POP |
| ClientIp | IP-адрес отправившего запрос клиента. Если в запросе был указан заголовок X-Forwarded-For, то IP-адрес клиента выбирается из него. |
| ClientPort | IP-порт клиента, отправившего запрос. |
| HttpMethod | Метод HTTP, используемый для запроса. |
| HttpStatusCode | Код состояния HTTP, полученный от прокси-сервера. Если запрос к источнику истекает, значение httpStatusCode равно 0. |
| HttpStatusDetails | Итоговое состояние запроса. Пояснения к этому строковому значению есть в ссылочной таблице "Состояние". |
| HttpVersion | Тип запроса или подключения. |
| POP | Короткое имя граничного сервера, который стал местом назначения запроса. |
| RequestBytes | Размер сообщения с HTTP-запросом в байтах, включая заголовки и текст запроса. |
| RequestUri | URI полученного запроса. |
| ResponseBytes | Количество байтов, отправленных внутренним сервером в качестве ответа. |
| RoutingRuleName | Имя правила маршрутизации, которому соответствует запрос. |
| RulesEngineMatchNames | Имена правил, которым соответствует запрос. |
| SecurityProtocol | Версия протокола TLS/SSL, которая использовалась в запросе. Содержит значение NULL, если шифрование не использовалось. |
| SentToOriginShield (устарело)* См. примечания об устаревании в следующем разделе. |
Если установлено значение true, значит, ответ на запрос был получен из кэша защиты источника, а не из граничной точки присутствия. Защитой источника называется родительский кэш, который предназначен для повышения коэффициента попаданий в кэш. |
| isReceivedFromClient | Значение True означает, что запрос поступил от клиента. Значение False означает, что запрос не поступил на граничный сервер (дочернюю точку POP) и ответ получен из системы защиты сервера-источника (родительской точки POP). |
| TimeTaken | Время в секундах, прошедшее с поступления первого байта запроса в Front Door, до отправки последнего байта ответа. |
| TrackingReference | Это уникальная эталонная строка, которая идентифицирует обслуженный Front Door запрос. Она же отправляется клиенту в заголовке X-Azure-Ref. Эта строка нужна для поиска в журналах доступа сведений о конкретном запросе. |
| UserAgent | Тип браузера, используемый клиентом. |
| ErrorInfo | Это поле содержит сведения об ошибке конкретного типа для дальнейшего устранения неполадок.
Возможные значения включают: NoError: указывает, что ошибка не найдена. CertificateError: общая ошибка SSL-сертификата. CertificateNameCheckFailed — имя узла в сертификате SSL недействительно или не совпадает с действительным. ClientDisconnected — сбой запроса из-за проблем с сетевым подключением клиента. UnspecifiedClientError — общая ошибка на стороне клиента. InvalidRequest — недопустимый запрос. Причиной может быть неправильно составленный заголовок, тело запроса или URL-адрес. DNSFailure — сбой DNS. DNSNameNotResolved — не удалось разрешить имя или адрес сервера. OriginConnectionAborted — подключение к источнику было внезапно остановлено. OriginConnectionAborted — общая ошибка подключения к источнику. OriginConnectionRefused — не удалось установить подключение к источнику. OriginError — общая ошибка на стороне источника. OriginError — источник вернул недопустимый или нераспознанный ответ. OriginTimeout: истек срок ожидания для запроса на источник. ResponseHeaderTooBig — источник вернул слишком длинный заголовок ответа. RestrictedIP — запрос был заблокирован по причине ограничения IP-адреса. SSLHandshakeError — не удалось установить подключение к источнику по причине сбоя рукопожатия SSL. UnspecifiedError — произошла ошибка, которая не включена в эту таблицу. SSLMismatchedSNI: запрос недопустим, так как заголовок HTTP-сообщения не совпадает со значением, представленным в расширении TLS SNI во время настройки подключения SSL/TLS. |
| Результат |
SSLMismatchedSNI — это код состояния, который обозначает успешный запрос с предупреждением о несоответствии между SNI и заголовком узла. Этот код состояния подразумевает интерфейс домена, метод, который нарушает условия обслуживания Azure Front Door. Запросы с SSLMismatchedSNI будут отклонены после 22 января 2024 г. |
| Sni | Это поле указывает указание имени сервера (SNI), которое отправляется во время подтверждения TLS/SSL. Его можно использовать для идентификации точного SSLMismatchedSNI значения SNI, если был код состояния. Кроме того, его можно сравнить со значением узла в requestUri поле для обнаружения и устранения проблемы несоответствия. |
Свойство "Отправлено на защиту источника" больше не поддерживается
Свойство необработанного журнала isSentToOriginShield устарело и заменено новым полем IsReceivedFromClient. Используйте новое поле, если вы уже используете нерекомендуемое.
Необработанные журналы включают в себя журналы, созданные на граничном сервере CDN (дочерней точке POP) и в системе защиты сервера-источника. Система защиты сервера-источника ссылается на родительские узлы, которые стратегически расположены по всему миру. Эти узлы обмениваются данными с серверами-источниками и снижают нагрузку на эти серверы.
Для каждого запроса, который отправляется на экран источника, есть две записи журнала:
- одна для граничных узлов;
- Один для щита происхождения
Чтобы отличить, пришел ли трафик или ответ через граничный узел или систему защиты сервера-источника, можно использовать поле isReceivedFromClient и получить таким образом верные данные.
Значение False, означает, что ответ на запрос получен на граничных узлах из системы защиты сервера-источника. Этот подход эффективен для сравнения необработанных журналов с данными о выставлении счетов. За исходящий трафик из системы защиты сервера-источника на граничные узлы плата не взимается. Плата взимается за исходящий трафик от граничных узлов к клиентам.
Пример запроса Kusto для исключения журналов, созданных в системе защиты сервера-источника в Log Analytics.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Примечание.
Для различных конфигураций маршрутизации и поведения трафика некоторые поля, такие как backendHostname, cacheStatus, isReceivedFromClient и поле POP могут реагировать с различными значениями. В следующей таблице описаны различные значения этих полей для различных сценариев:
| Сценарии | Число записей в журнале | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| Правило маршрутизации без включенного кэширования | 1 | Код POP граничного узла | Серверная часть, в которой был перенаправлен запрос | Истина | CONFIG_NOCACHE |
| Правило маршрутизации с включенным кэшированием. Попадание в кэше на POP граничного узла | 1 | Код POP граничного узла | Нет значения | Истина | HIT |
| Правило маршрутизации с включенным кэшированием. Промахи кэша на POP граничного узла, но попадания в кэше на POP родительского кэша | 2 | 1. Код POP граничного узла 2. Код POP родительского кэша |
1. Имя узла POP родительского кэша 2. Нет значения |
1. True 2. False |
1. MISS 2. HIT |
| Правило маршрутизации с включенным кэшированием. Промах кэша на POP граничного узла, но ЧАСТИЧНОЕ попадание на POP родительского кэша | 2 | 1. Код POP граничного узла 2. Код POP родительского кэша |
1. Имя узла POP родительского кэша 2. Серверная часть, которая помогает заполнять кэш |
1. True 2. False |
1. MISS 2. PARTIAL_HIT |
| Правило маршрутизации с включенным кэшированием. PARTIAL_HIT на POP граничного узла, но попадания в кэше на POP родительского кэша | 2 | 1. Код POP граничного узла 2. Код POP родительского кэша |
1. Код POP граничного узла 2. Код POP родительского кэша |
1. True 2. False |
1. PARTIAL_HIT 2. HIT |
| Правило маршрутизации с включенным кэшированием. Промахи кэша на POP граничного узла и родительского кэша | 2 | 1. Код POP граничного узла 2. Код POP родительского кэша |
1. Код POP граничного узла 2. Код POP родительского кэша |
1. True 2. False |
1. MISS 2. MISS |
| Произошла ошибка при обработке запроса | Неприменимо |
Примечание.
Для сценариев кэширования значение состояния кэша — это PARTIAL_HIT, когда некоторые из байтов запроса получают от пограничного кэша Azure Front Door или кэша экрана источника, а некоторые из байтов получают от источника для больших объектов.
Azure Front Door использует метод фрагментирования объекта. Когда запрашивается большой файл, Azure Front Door извлекает меньшие фрагменты файла из источника. Когда сервер POP Azure Front Door получит полный или частичный байтовый диапазон запрошенного файла, граничный сервер Azure Front Door будет запрашивать файл из источника фрагментами по 8 МБ.
Когда фрагмент поступает в граничный узел Azure Front Door, он кэшируется и немедленно отправляется пользователю. Одновременно с этим Azure Front Door предварительно загружает следующий фрагмент. Эта предварительная загрузка гарантирует, что всегда будет загружен следующий фрагмент содержимого (по сравнению с тем фрагментом, который просматривает пользователь), что позволяет снизить задержку. Этот процесс продолжается до тех пор, пока не будет скачан весь файл (если он запрашивался), пока не будут скачаны все запрошенные диапазоны байт (если они запрашивались) или пока клиент не завершит соединение. Дополнительные сведения о запросе диапазона байт см. в разделе RFC 7233. Azure Front Door кэширует все фрагменты по мере их получения. Весь файл не кэшируется в кэше Front Door. Последующие запросы файла или диапазонов байтов обслуживаются из кэша Azure Front Door. Если в Azure Front Door отсутствуют некоторые фрагменты файла, запрошенные недостающие фрагменты будут предварительно загружены с сервера-источника. В основе этой оптимизации лежит поддержка запросов диапазонов байт сервером-источником. Если сервер-источник не поддерживает запросы диапазонов байт, эта оптимизация будет неэффективной.
Использование средств Azure Monitor для анализа данных
Эти средства Azure Monitor доступны в портал Azure для анализа данных мониторинга:
Некоторые службы Azure имеют встроенную панель мониторинга мониторинга в портал Azure. Эти панели мониторинга называются аналитическими сведениями, и их можно найти в разделе "Аналитика" в Azure Monitor в портал Azure.
Обозреватель метрик позволяет просматривать и анализировать метрики для ресурсов Azure. Дополнительные сведения см. в разделе "Анализ метрик" с помощью обозревателя метрик Azure Monitor.
Log Analytics позволяет запрашивать и анализировать данные журнала с помощью языка запросов Kusto (KQL). Дополнительные сведения см. в статье Начало работы с запросами журнала в Azure Monitor.
В портал Azure есть пользовательский интерфейс для просмотра и базового поиска журнала действий. Чтобы выполнить более подробный анализ, перенаправите данные в журналы Azure Monitor и выполните более сложные запросы в Log Analytics.
Application Insights отслеживает доступность, производительность и использование веб-приложений, чтобы можно было выявлять и диагностировать ошибки, не ожидая, когда пользователь сообщит о них.
Application Insights включает точки подключения к различным средствам разработки и интегрируется с Visual Studio для поддержки процессов DevOps. Дополнительные сведения см. в разделе "Мониторинг приложений" для Служба приложений.
Средства, которые позволяют более сложной визуализации, включают:
- Панели мониторинга, позволяющие объединить различные виды данных в одну область в портал Azure.
- Книги, настраиваемые отчеты, которые можно создать в портал Azure. Книги могут включать текст, метрики и запросы журналов.
- Grafana — открытое средство платформы, которое работает на операционных панелях мониторинга. С помощью Grafana можно создавать панели мониторинга, содержащие данные из нескольких источников, отличных от Azure Monitor.
- Power BI— служба бизнес-аналитики, которая предоставляет интерактивные визуализации в различных источниках данных. Вы можете настроить Power BI на автоматический импорт данных журналов из Azure Monitor, чтобы воспользоваться этими визуализациями.
Экспорт данных Azure Monitor
Вы можете экспортировать данные из Azure Monitor в другие средства с помощью:
Метрики. Используйте REST API для метрик для извлечения данных метрик из базы данных метрик Azure Monitor. Дополнительные сведения см . в справочнике по REST API Azure Monitor.
Журналы: используйте REST API или связанные клиентские библиотеки.
Экспорт данных рабочей области Log Analytics.
Сведения о начале работы с REST API Azure Monitor см . в пошаговом руководстве по REST API мониторинга Azure.
Использование запросов Kusto для анализа данных журнала
Вы можете анализировать данные журнала Azure Monitor с помощью языка запросов Kusto (KQL). Дополнительные сведения см. в разделе Запросы журналов в Azure Monitor.
Использование оповещений Azure Monitor для уведомления о проблемах
Оповещения Azure Monitor позволяют выявлять и устранять проблемы в системе, а также заранее уведомлять вас, когда конкретные условия находятся в данных мониторинга, прежде чем клиенты заметят их. Вы можете получать оповещения о любых источниках данных метрик или журналов на платформе данных Azure Monitor. Существуют различные типы оповещений Azure Monitor в зависимости от служб, которые вы отслеживаете, и собираемых данных мониторинга. См. раздел "Выбор правильного типа правила генерации оповещений".
Примеры распространенных оповещений для ресурсов Azure см. в примерах запросов оповещений журнала.
Реализация оповещений в масштабе
Для некоторых служб можно отслеживать масштаб, применяя одно правило генерации оповещений метрик к нескольким ресурсам одного типа, которые существуют в одном регионе Azure. Оповещения базовых показателей Azure Monitor (AMBA) предоставляют полуавтомативный метод реализации важных оповещений метрик платформы, панелей мониторинга и рекомендаций в масштабе.
Получение персонализированных рекомендаций с помощью Помощника по Azure
Для некоторых служб, если критические условия или неизбежные изменения происходят во время операций ресурсов, на странице обзора службы на портале отображается оповещение. Дополнительные сведения и рекомендуемые исправления для оповещения в рекомендациях Помощника см. в разделе "Мониторинг" в меню слева. Во время обычных операций рекомендации помощника не отображаются.
Дополнительные сведения о Помощнике по Azure см. в обзоре Помощника по Azure.