Azure monitor что это

Обзор журналов Azure Monitor

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

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

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

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

Что можно делать с журналами Azure Monitor?

В следующей таблице описаны некоторые способы использования журналов Azure Monitor.

сбор данных

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

Эта конфигурация будет отличаться в зависимости от источника данных. Например:

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

Большинство сбор данных в журналах будет нести расходы на прием и хранение. Прежде чем включить сбор данных, ознакомьтесь с ценами на Azure Monitor.

Полный список источников данных, которые можно настроить для передачи данных в журналы Azure Monitor, см. в статье Что отслеживает Azure Monitor?

Рабочие области Log Analytics

Данные, собранные в журналах Azure Monitor, сохраняются в одной или нескольких рабочих областях Log Analytics. Чтобы использовать журналы Azure Monitor, необходимо создать хотя бы одну рабочую область. Описание рабочих областей Log Analytics см. в обзоре рабочей области Log Analytics.

Служба Log Analytics

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

Описание Log Analytics см. в статье Обзор Log Analytics в Azure Monitor. Дополнительные сведения об использовании функций Log Analytics для создания простого запроса журналов и анализа результатов запросов см. в руководстве по Log Analytics.

Запросы журнала

Данные извлекаются из рабочей области Log Analytics с помощью запроса к журналу, который является запросом только для чтения для обработки данных и возврата результатов. Эти запросы создаются на языке запросов Kusto (KQL). KQL — это тот же язык запросов, который используется в обозревателе данных Azure.

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

Аналитические сведения включают готовые запросы для поддержки представлений запросов и книг.

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

Связь с обозревателем данных Azure Data Explorer

Журналы Azure Monitor основаны на Azure Data Explorer. Рабочая область Log Analytics — это, условно говоря, эквивалент базы данных в Azure Data Explorer. Таблицы структурированы так же и используют KQL. Дополнительные сведения о KQL см. в обзоре язык запросов Kusto (KQL).

Использование Log Analytics для работы с запросами Azure Monitor на портале Azure аналогично работе с пользовательским веб-интерфейсом Azure Data Explorer. В запрос Azure Data Explorer можно даже включить данные из рабочей области Log Analytics.

Связь с Azure Sentinel и Microsoft Defender для облака

Эти службы хранят свои данные в журналах Azure Monitor, чтобы их можно было анализировать с другими данными журнала, собранными Azure Monitor. Дополнительные сведения см. в разделе «Интеграция продуктов» и «Другие службы».

Подробнее

• Где хранятся данные Microsoft Sentinel
• Проектирование архитектуры рабочей области Microsoft Sentinel
• Проектирование архитектуры рабочей области Log Analytics
• Подготовка к нескольким рабочим областям и клиентам в Microsoft Sentinel
• Включите Microsoft Sentinel в рабочей области Log Analytics.
• Управление журналами в Microsoft Sentinel
• Цены на Microsoft Sentinel
• Плата за рабочие области с помощью Microsoft Sentinel

• Непрерывный экспорт данных Microsoft Defender для облака
• Использование данных
• Часто задаваемые вопросы о рабочих областях Log Analytics, используемых с Microsoft Defender для облака
• Цены на Microsoft Defender для облака
• Плата за рабочие области с Microsoft Defender для облака

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

• Изучите статью о запросах к журналу для извлечения и анализа данных из рабочей области Log Analytics.
• Прочитайте статью о метриках в Azure Monitor.
• Узнайте о доступных данных мониторинга для различных источников в Azure.

Платформа данных Azure Monitor

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

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

Данные наблюдаемости в Azure Monitor

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

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

Метрики

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

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

Метрики Azure Monitor включают два типа метрик — собственные метрики и метрики Prometheus. Ознакомьтесь с сравнением двух и дополнительных сведений о метриках Azure Monitor, включая их источники данных, на странице метрик в Azure Monitor.

Журналы

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

Журналы в Azure Monitor хранятся в рабочей области Log Analytics обозревателя данных Azure Data Explorer, которая предоставляет эффективный модуль анализа и полнофункциональный язык запросов. В журналах, как правило, содержится достаточно сведений для предоставления полного контекста обнаруженной проблемы и выявления основной причины проблем.

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

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

Вы можете работать с запросами журналов в интерактивном режиме с помощью Log Analytics на портале Azure. Вы также можете добавить результаты на панель мониторинга Azure для визуализации совместно с другими данными. Можно создавать оповещения журнала, которые будут активировать оповещение на основе результатов запланированного запроса.

Подробнее о журналах Azure Monitor, включая их источники данных, см. в статье Журналы в Azure Monitor.

Распределенные трассировки

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

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

Дополнительные сведения о распределенной трассировке см. в статье Что такое распределенная трассировка?.

Изменения

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

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

• Устранение неполадок в приложении, используя раздел Диагностика &средство решения проблем.
• Выполните общее управление и мониторинг с помощью портала обзора «Анализ изменений» и журнала действий.
• Узнайте больше о том, как просмотреть результаты данных для других сценариев.

Дополнительные сведения об анализе изменений, включая источники данных, читайте в статье Использование анализа изменений в Azure Monitor.

Сбор данных мониторинга

Различные источники данных для Azure Monitor будут записываться либо в рабочую область Log Analytics (журналы), либо в базу данных метрик Azure Monitor (метрики), либо и в рабочую область, и в базу данных. Некоторые источники будут записывать данные непосредственно в эти хранилища данных, а другие могут записывать данные в другое расположение, например в хранилище Azure, и требуется определенная конфигурация для заполнения журналов или метрик.

Список различных источников данных, заполняющих каждый тип, см. в статьях Метрики в Azure Monitor и Журналы Azure Monitor.

Потоковая передача данных во внешние системы

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

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

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

• Узнайте подробнее о метриках в Azure Monitor.
• Узнайте подробнее о журналах в Azure Monitor.
• Узнайте о доступных данных мониторинга для различных источников в Azure.

Обзор метрик в Azure Monitor

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

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

Типы метрик

Существует несколько типов метрик, поддерживаемых метриками Azure Monitor:

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

  

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

  Категория	Метрики собственной платформы	Собственные пользовательские метрики	Метрики Prometheus
  Источники	Ресурсы Azure	Агент Azure Monitor Application Insights REST API	Кластер службы Azure Kubernetes (AKS) Любой кластер Kubernetes с помощью удаленной записи
  Настройка	нет	Зависит от источника	Включение управляемой службы Azure Monitor для Prometheus
  Хранятся	Отток подписок	Отток подписок	Рабочая область Azure Monitor
  Себестоимость	No	Да	Да (бесплатно во время предварительной версии)
  Агрегат	предварительно агрегированный	предварительно агрегированный	необработанные данные
  Анализ	Обозреватель метрик	Обозреватель метрик	PromQL Панели мониторинга Grafana
  Предупреждение	Правило генерации оповещений метрик	Правило генерации оповещений метрик	Правило генерации оповещений Prometheus
  Визуализировать	книги Панели мониторинга Azure Grafana	книги Панели мониторинга Azure Grafana	Grafana
  Извлечь	Azure CLI Командлеты Azure PowerShell REST API или клиентская библиотека .NET GO Java JavaScript Python	Azure CLI Командлеты Azure PowerShell REST API или клиентская библиотека .NET GO Java JavaScript Python	Grafana

  сбор данных

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

  • Ресурсы Azure — метрики платформы создаются ресурсами Azure и информируют об их работоспособности и производительности. Каждый тип ресурсов создает отдельный набор метрик, который не нужно настраивать. Метрики платформы собираются из ресурсов Azure с частотой раз в минуту, если в определении метрики не указано иное.
  • Приложения — служба Application Insights создает метрики для отслеживаемых приложений, что помогает обнаруживать проблемы с производительностью и отслеживать тенденции использования приложений. В числе таких метрик время ответа сервера и исключения браузера.
  • Агенты виртуальной машины — метрики собираются из гостевой операционной системы виртуальной машины. Вы можете включить метрики гостевой ОС для виртуальных машин Windows с помощью расширения системы диагностики Windows, а для виртуальных машин Linux — с помощью агента InfluxData Telegraf.
  • Пользовательские метрики — вы можете определить метрики в дополнение к стандартным метрикам, которые доступны автоматически. Вы можете определять пользовательские метрики в своих приложениях, отслеживаемых службой Application Insights. Вы также можете создать пользовательские метрики для службы Azure с помощью API пользовательских метрик.
  • Кластеры Kubernetes: кластеры Kubernetes обычно отправляют данные метрик на локальный сервер Prometheus, который необходимо поддерживать. Управляемая служба Azure Monitor для Prometheus предоставляет управляемую службу, которая собирает метрики из кластеров Kubernetes и хранит их в метриках Azure Monitor.

  Полный список источников данных, которые могут посылать данные в метрики Azure Monitor, см. в статье Что отслеживает Azure Monitor?

  REST API

  Azure Monitor предоставляет ИНТЕРФЕЙСы REST API, которые позволяют получать данные из метрик Azure Monitor и из него.

  • Пользовательские метрики API — пользовательских метрик позволяют загружать собственные метрики в базу данных метрик Azure Monitor. Затем эти метрики можно использовать теми же средствами анализа, которые обрабатывают метрики платформы Azure Monitor.
  • REST API метрик Azure Monitor— позволяет получить доступ к определениям и значениям метрик платформы Azure Monitor. Дополнительные сведения см. в rest API Azure Monitor. Сведения об использовании API см. в пошаговом руководстве по REST API мониторинга Azure.
  • API пакетной службы метрик Azure Monitor для пакетной службы Azure Monitor — это API пакетной службы — метрик Azure Monitor, предназначенный для клиентов с большими запросами метрик томов. Это похоже на существующий стандартный REST API метрик Azure Monitor, но предоставляет возможность получить данные метрик для до 50 идентификаторов ресурсов в одной подписке и регионе в одном пакетном вызове API. Это повышает пропускную способность запросов и снижает риск регулирования.

  Безопасность

  Все обмен данными между подключенными системами и службой Azure Monitor шифруются с помощью протокола TLS 1.2 (HTTPS). Процесс Microsoft SDL следует, чтобы убедиться, что все службы Azure актуальны с последними достижениями в криптографических протоколах.

  Безопасное подключение устанавливается между агентом и службой Azure Monitor с помощью проверки подлинности на основе сертификатов и TLS с портом 443. Для создания и обслуживания ключей в Azure Monitor используется секретное хранилище. Закрытые ключи меняются каждые 90 дней, хранятся в Azure и управляются с помощью операций Azure согласно строгим рекомендациям соответствия нормативам и требованиям. Дополнительные сведения о безопасности см. в разделе «Шифрование данных во время передачи», «Шифрование неактивных данных» и «Безопасность данных журналов Azure Monitor»

  Обозреватель метрик

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

  

  Дополнительные сведения см. в разделе «Анализ метрик» с помощью обозревателя метрик Azure Monitor.

  Структура данных

  Данные, собираемые метриками Azure Monitor, хранятся в базе данных временных рядов, оптимизированной для анализа меток времени. Каждый набор значений метрик представляет собой временной ряд со следующими свойствами:

  • время получения значения;
  • ресурс, с которым связано значение.
  • пространство имен, используемое в качестве категории метрики;
  • имя метрики;
  • само значение.
  • измерения метрики при их наличии Пользовательские метрики ограничены 10 измерениями.

  Многомерные метрики

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

  Измерения метрик — это пары «имя-значение», которые содержат больше данных для описания значения метрик. Например, метрика Доступное место на диске может иметь измерение Диск со значениями C: и D:. Эта метрика позволяет узнать свободное место на каждом диске.

  Дополнительные сведения о просмотре измерений в обозревателе метрик см. в разделе «Применение фильтров измерений измерений и разделение «.

  Немеричная метрика

  В следующей таблице показаны примеры данных из немерной метрики, пропускной способности сети. Он может ответить только на базовый вопрос, например «Что было моей пропускной способностью сети в определенное время?»

  Метка времени	Значение метрики
  8/9/2017 8:14	1331,8 Кбит/с
  8/9/2017 8:15	1141,4 Кбит/с
  8/9/2017 8:16	1110,2 Кбит/с

  Пропускная способность сети и два измерения («IP-адрес» и «Направление»)

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

  Метка времени	Измерение «IP-адрес»	Измерение «Направление»	Значение метрики
  8/9/2017 8:14	IP-адрес — 192.168.5.2	Направление — отправка	646,5 Кбит/с
  8/9/2017 8:14	IP-адрес — 192.168.5.2	Направление — получение	420,1 Кбит/с
  8/9/2017 8:14	IP-адрес — 10.24.2.15	Направление — отправка	150,0 Кбит/с
  8/9/2017 8:14	IP-адрес — 10.24.2.15	Направление — получение	115,2 Кбит/с
  8/9/2017 8:15	IP-адрес — 192.168.5.2	Направление — отправка	515,2 Кбит/с
  8/9/2017 8:15	IP-адрес — 192.168.5.2	Направление — получение	371,1 Кбит/с
  8/9/2017 8:15	IP-адрес — 10.24.2.15	Направление — отправка	155,0 Кбит/с
  8/9/2017 8:15	IP-адрес — 10.24.2.15	Направление — получение	100,1 Кбит/с

  Имена измерений и значения измерений не учитывает регистр.

  Хранение метрик

  Платформы и пользовательские метрики

  Платформа и пользовательские метрики хранятся в течение 93 дней со следующими исключениями:

  • Классические метрики гостевой ОС. Это счетчики производительности, данные которых собираются с помощью расширения системы диагностики Windows или Linux и передаются в учетную запись хранения Azure. Срок хранения этих метрик составляет не менее 14 дней, но дата окончания этого срока не указывается в учетной записи хранения. Для обеспечения производительности портал ограничивает объем отображаемых данных. Следовательно, фактическое число дней, данные за которые можно получить на портале, может быть больше 14, если объем записываемых данных небольшой.
  • Метрики гостевой ОС, отправляемые в метрики Azure Monitor. Это счетчики производительности, данные которых собираются с помощью расширения системы диагностики Windows и передаются в приемник данных Azure Monitor. Сбор данных также может выполняться с помощью агента InfluxData Telegraf на компьютерах Linux или нового решения — агента Azure Monitor с использованием правил сбора данных. Период хранения этих метрик составляет 93 дней.
  • Метрики гостевой ОС, собираемые агентом Log Analytics. Это счетчики производительности, данные которых собираются агентом Log Analytics и передаются в рабочую область Log Analytics. Период хранения этих метрик составляет 31 день, но его можно увеличить до 2 лет.
  • Метрики на основе журналов Application Insights. В фоновом режиме метрики на основе журналов преобразовываются в запросы журналов. Период хранения для них может быть разным и соответствует периоду хранения событий в базовых журналах (от 31 дня до 2 лет). Для ресурсов Application Insights журналы хранятся в течение 90 дней.

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

  Перемещение или переименование ресурса Azure может привести к потере журнала метрик для этого ресурса.

  Метрики Prometheus

  Метрики Prometheus хранятся в течение 18 месяцев, но запрос PromQL может охватывать не более 32 дней.

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

  • Дополнительные сведения о платформе данных Azure Monitor.
  • Дополнительные сведения о данных журналов в Azure Monitor.
  • Узнайте о доступных данных мониторинга для различных источников в Azure.

  Мониторинг Службы приложений

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

  Данные мониторинга

  Служба приложений собирает данные мониторинга тех же типов, что и другие ресурсы Azure, описанные в статье Мониторинг данных из ресурсов Azure.

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

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

  Application Insights

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

  Сбор и маршрутизация

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

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

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

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

  Журналы группируются в группы категорий. Группы категорий — это коллекция различных журналов, которые помогут вам достичь различных целей мониторинга.
  Группа категорий аудита позволяет выбрать журналы ресурсов, необходимые для аудита ресурса. Дополнительные сведения см. в разделе «Параметры диагностики» в журналах ресурсов Azure Monitor.

  Анализ метрик

  Метрики Службы приложений можно анализировать вместе с метриками других служб Azure с помощью обозревателя метрик. Для этого выберите пункт Метрики в меню Azure Monitor. Дополнительные сведения об использовании этого средства см . в обозревателе метрик Azure Monitor.

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

  анализ журналов;

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

  Все журналы ресурсов в Azure Monitor имеют те же поля, за которыми следуют поля, характерные для службы. Общая схема показана в разделе Схема журнала ресурсов Azure Monitor.

  Журнал действий — это журнал платформы, который предоставляет аналитические сведения о событиях уровня подписки. Его можно просматривать отдельно или передавать в журналы Azure Monitor. Преимуществом передачи в журналы Azure Monitor является возможность использования Log Analytics для выполнения сложных запросов.

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

  Список доступных для запросов таблиц, используемых в журналах Azure Monitor и Log Analytics, см. в справочнике по данным мониторинга Службы приложений.

  Примеры запросов Kusto

  Если выбрать в меню Службы приложений пункт Журналы, откроется Log Analytics с текущим ресурсом в качестве области запроса. Это означает, что запросы к журналам будут содержать данные только из этого ресурса. Если требуется выполнить запрос, включающий данные из другого ресурса или других служб Azure, выберите в меню Azure Monitor пункт Журналы. Подробные сведения см. в статье Область запросов журнала и временной диапазон в Azure Monitor Log Analytics.

  Следующий пример запроса может помочь в мониторинге журналов приложений с помощью AppServiceAppLogs :

  AppServiceAppLogs | project CustomLevel, _ResourceId | summarize count() by CustomLevel, _ResourceId 

  Следующий пример запроса может помочь в мониторинге журналов HTTP с помощью AppServiceHTTPLogs , где HTTP response code имеет значение 500 или более высокое:

  AppServiceHTTPLogs //| where ResourceId = "MyResourceId" // Uncomment to get results for a specific resource Id when querying over a group of Apps | where ScStatus >= 500 | reduce by strcat(CsMethod, ':\\', CsUriStem) 

  Следующий пример запроса может помочь в мониторинге ошибок HTTP 500 путем объединения AppServiceConsoleLogs и AppserviceHTTPLogs :

  let myHttp = AppServiceHTTPLogs | where ScStatus == 500 | project TimeGen=substring(TimeGenerated, 0, 19), CsUriStem, ScStatus; let myConsole = AppServiceConsoleLogs | project TimeGen=substring(TimeGenerated, 0, 19), ResultDescription; myHttp | join myConsole on TimeGen | project TimeGen, CsUriStem, ScStatus, ResultDescription; 

  Дополнительные примеры запросов см. в статье Запросы Azure Monitor для Службы приложений.

  видны узлы

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

  Если вы запускаете приложение в Службе приложений, в Azure Monitor Application Insights предоставлены дополнительные типы оповещений.

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

  Тип оповещения	Condition	Примеры
  Метрика	Среднее число подключений	Если число подключений превышает заданное значение
  Метрика	HTTP 404	Когда число ответов HTTP 404 превышает заданное значение
  Метрика	Ошибки HTTP-сервера	Когда число ответов HTTP 5xx превышает заданное значение
  Журнал действий	Создание или обновление веб-приложения	При создании или обновлении приложения
  Журнал действий	Удаление веб-приложения	При удалении приложения
  Журнал действий	Перезапуск веб-приложения	При перезапуске приложения
  Журнал действий	Остановка веб-приложения	При остановке приложения

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

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

  1. Как можно использовать nfc
  2. Как сделать rgb подсветку на клавиатуре
  3. Как создать cookie на час php
  4. Что такое платформа в программировании