Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Платформа Kubernetes — это сложная распределенная система. Необходимо отслеживать развертывание Kubernetes на нескольких уровнях. Хотя служба Azure Kubernetes (AKS) — это управляемая служба Kubernetes, для мониторинга развертывания на нескольких уровнях требуется тот же уровень тщательности. В этой статье содержатся общие сведения и рекомендации по мониторингу кластера AKS.
- Подробный мониторинг полного стека Kubernetes см. в разделе "Мониторинг кластеров Kubernetes" с помощью служб Azure и облачных собственных средств.
- Сведения о сборе данных метрик из кластеров Kubernetes см. в статье "Управляемая служба для Prometheus" в Azure Monitor.
- Сведения о сборе журналов в кластерах Kubernetes см. в функциях Azure Monitor для мониторинга Kubernetes.
- Сведения о визуализации данных см . в книгах Azure и мониторинге служб Azure в Grafana.
Совет
Вы можете использовать Microsoft Copilot в Azure для настройки мониторинга в кластерах AKS на портале Azure. Дополнительные сведения см. в статье "Работа с кластерами AKS эффективно с помощью Microsoft Copilot в Azure".
Аналитические выводы (Insights)
Некоторые службы в Azure имеют встроенную панель мониторинга в портал Azure, которая предоставляет отправную точку для мониторинга службы. Эти панели мониторинга называются аналитическими сведениями, и их можно найти в Центре аналитики Azure Monitor в портал Azure.
Аналитика контейнеров в Azure Monitor собирает пользовательские метрики для узлов, модулей pod, контейнеров и постоянных томов. Дополнительные сведения см. в разделе "Метрики", собранные аналитикой контейнеров.
Application Insights помогает отслеживать производительность приложений. Сведения о включении Application Insights с изменениями кода см. в статье "Включить Azure Monitor OpenTelemetry". Сведения о включении Application Insights без изменений кода см. в статье автоинструментация AKS. Дополнительные сведения о инструментировании см. в основах сбора данных.
Данные мониторинга
AKS создает те же типы данных мониторинга, что и другие ресурсы Azure, как описано в разделе "Мониторинг данных из ресурсов Azure". Подробные сведения о метриках и журналах, созданных AKS, см. в справочнике по данным мониторинга AKS.
Другие службы и функции Azure собирают другие данные и обеспечивают другие параметры анализа, как показано на следующей схеме и таблице.
Оригинал | Описание |
---|---|
Метрики платформы | Метрики платформы автоматически собираются для кластеров AKS без затрат. Эти метрики можно проанализировать с помощью обозревателя метрик или использовать их для создания оповещений метрик. |
Метрики Prometheus | Если включить очистку метрик для кластера, управляемая служба Prometheus в Azure Monitor собирает метрики Prometheus и сохраняет их в рабочей области Azure Monitor. Анализируйте эти метрики, используя заранее настроенные панели мониторинга в Azure Managed Grafana и с оповещениями Prometheus. |
Журналы действий | Журнал действий Azure Monitor автоматически собирает некоторые данные для кластеров AKS без затрат. Эти файлы журналов отслеживают такие сведения, как при создании кластера или внесении изменений в конфигурацию кластера. Чтобы проанализировать данные журнала действий с другими данными журнала, отправьте данные журнала действий в рабочую область Log Analytics. |
Журналы ресурсов | Журналы плоскости управления для AKS реализуются в виде журналов ресурсов. Создайте параметр диагностики для отправки журналов в рабочую область Log Analytics. В рабочей области можно проанализировать журналы с помощью запросов и настроить оповещения на основе сведений журнала. |
Аналитика контейнеров | Аналитика контейнеров собирает различные журналы и данные о производительности из кластера и сохраняет их в рабочей области Log Analytics и в метриках Azure Monitor. Анализируйте данные, такие как stdout и потоки stderr , с помощью представлений и рабочих книг в Container insights или с помощью Log Analytics и Обозревателя метрик. |
Application Insights | Application Insights, функция Azure Monitor, собирает журналы, метрики и распределенные трассировки. Данные телеметрии хранятся в рабочей области Log Analytics для анализа на портале Azure. |
Типы ресурсов
Azure использует концепцию типов ресурсов и идентификаторов для идентификации всего в подписке. Типы ресурсов также являются частью идентификаторов ресурсов для каждого ресурса, работающего в Azure. Например, для виртуальной машины используется Microsoft.Compute/virtualMachines
один тип ресурса. Список служб и связанных с ними типов ресурсов см. в разделе "Поставщики ресурсов".
Azure Monitor аналогично упорядочивает основные данные мониторинга в метрики и журналы на основе типов ресурсов, которые также называются пространствами имен. Различные метрики и журналы доступны для различных типов ресурсов. Служба может быть связана с несколькими типами ресурсов.
Дополнительные сведения о типах ресурсов в AKS см. в справочнике по данным мониторинга AKS.
Хранилище данных
Для Azure Monitor:
- Данные метрик хранятся в базе данных метрик Azure Monitor.
- Данные журнала хранятся в хранилище журналов Azure Monitor. Log Analytics — это средство в портал Azure, которое может запрашивать это хранилище.
- Журнал действий Azure — это отдельное хранилище с собственным интерфейсом в портал Azure.
При необходимости можно перенаправить данные журнала метрик и действий в хранилище журналов Azure Monitor. Затем с помощью Log Analytics можно запрашивать данные и сопоставлять их с другими данными журнала.
Многие службы могут использовать параметры диагностики для отправки данных метрик и журналов в другие расположения хранилища за пределами Azure Monitor. Примеры включают служба хранилища Azure, размещенные партнерские системы и системы партнеров, отличные от Azure, с помощью Центров событий.
Подробные сведения о том, как Azure Monitor хранит данные, см. на платформе данных Azure Monitor.
Метрики платформы Azure Monitor
Azure Monitor предоставляет метрики платформы для большинства служб. Эти метрики перечислены ниже.
- По отдельности определяется для каждого пространства имен.
- Хранится в базе данных метрик временных рядов Azure Monitor.
- Упрощенный и способный поддерживать оповещения практически в режиме реального времени.
- Используется для отслеживания производительности ресурса с течением времени.
Коллекция: Azure Monitor автоматически собирает метрики платформы. Настройка не требуется.
Маршрутизация. Вы также можете направлять некоторые метрики платформы в журналы Azure Monitor или Log Analytics, чтобы запросить их с другими данными журнала. Проверьте параметр экспорта DS для каждой метрики, чтобы узнать, можно ли использовать параметр диагностики для маршрутизации метрик в журналы Azure Monitor или Log Analytics.
- Дополнительные сведения см. в параметре диагностики метрик.
- Сведения о настройке параметров диагностики для службы см. в статье "Создание параметров диагностики" в Azure Monitor.
Список всех метрик, которые можно собрать для всех ресурсов в Azure Monitor, см. в статье "Поддерживаемые метрики в Azure Monitor".
Список метрик, которые можно собирать для AKS, см. в справочнике по данным мониторинга AKS.
Метрики играют важную роль в мониторинге кластеров, выявлении проблем и оптимизации производительности в кластерах AKS. Метрики платформы фиксируются с помощью сервера метрик по умолчанию, установленного в kube-system
пространстве имен, который периодически собирает метрики со всех узлов AKS, обслуживаемых kubelet. Вы также должны включить управляемую службу для метрик Prometheus для сбора метрик контейнеров и метрик объектов Kubernetes, включая состояние развертывания объекта.
Вы можете просмотреть список управляемых служб по умолчанию для метрик Prometheus.
Дополнительные сведения см. в разделе Сбор управляемых служб для метрик Prometheus из кластера AKS.
AKS также предоставляет метрики из критически важных компонентов уровня управления, таких как сервер API, etcd и планировщик, через управляемую службу для Prometheus. В настоящее время эта функция доступна в предварительной версии. Дополнительные сведения см. в разделе "Мониторинг показателей плоскости управления AKS( предварительная версия)". Подмножество метрик плоскости управления для сервера API и т. д. доступно бесплатно с помощью метрик платформы Azure Monitor. Метрики собираются по умолчанию и можно использовать метрики для создания оповещений на основе метрик.
Метрики, отличные от Azure Monitor
Эта служба предоставляет другие метрики, которые не включены в базу данных метрик Azure Monitor.
Для мониторинга кластеров AKS можно использовать следующие службы Azure и функции Azure Monitor. Эти функции можно включить при создании кластера AKS.
На портале Azure перейдите на вкладку "Интеграция" или используйте Azure CLI, Terraform или политику Azure. В некоторых случаях вы можете подключить кластер к службе мониторинга или функции после создания кластера. Каждая служба или функция могут повлечь за собой затраты, поэтому перед включением см. сведения о ценах для каждого компонента.
Служба или компонент | Описание |
---|---|
Аналитика контейнеров | Использует контейнерную версию агента Azure Monitor для сбора stdout журналов и stderr событий Kubernetes с каждого узла в вашем кластере. Эта функция поддерживает различные сценарии мониторинга для кластеров AKS. Мониторинг кластера AKS можно включить при создании с помощью Azure CLI, политики Azure, портала Azure или Terraform. Если вы не включите аналитику контейнеров при создании кластера, ознакомьтесь с разделом «Включить аналитику контейнеров для кластера AKS», чтобы узнать о других способах включения этой функции.Аналитика контейнеров хранит большую часть своих данных в рабочей области Log Analytics. Вы обычно используете ту же рабочую область Log Analytics, что и журналы ресурсов для вашего кластера. Инструкции по использованию и расположению рабочих областей см. в статье "Проектирование архитектуры рабочей области Log Analytics". |
Управляемая служба Prometheus в Azure Monitor |
Prometheus — это облачное решение метрик из Cloud Native Computing Foundation. Это наиболее распространенное средство для сбора и анализа данных метрик из кластеров Kubernetes. Управляемая служба для Prometheus в Azure Monitor — это полностью управляемое решение для мониторинга, совместимое с Prometheus. Если вы не включите управляемую службу для Prometheus при создании кластера, см. статью "Сбор метрик Prometheus из кластера AKS" для получения других способов включения этой службы. Управляемая служба prometheus в Azure Monitor хранит свои данные в рабочей области Azure Monitor , связанной с рабочей областью Grafana. Вы можете использовать Azure Managed Grafana для анализа данных. |
Управляемая Grafana Azure | Полностью управляемая реализация Grafana. Grafana — это платформа визуализации данных с открытым исходным кодом, которая обычно используется для представления данных Prometheus. Для мониторинга Kubernetes и устранения неполадок с полным стеком доступны несколько предопределенных панелей мониторинга Grafana. Если вы не настроите управляемую Grafana Azure при создании кластера, см. Ссылка на рабочую область Grafana. Вы можете связать его с рабочей областью Azure Monitor, чтобы получить доступ к метрикам Prometheus из кластера. |
Мониторинг метрик плоскости управления AKS (предварительная версия)
AKS также предоставляет метрики из критически важных компонентов плоскости управления, таких как сервер API, etcd и планировщик, через управляемую службу для Prometheus в Azure Monitor. В настоящее время эта функция доступна в предварительной версии. Дополнительные сведения см. в разделе "Мониторинг показателей плоскости управления AKS". Подмножество метрик плоскости управления для сервера API и т. д. доступно бесплатно с помощью метрик платформы Azure Monitor. Эти метрики собираются по умолчанию. Для создания оповещений можно использовать метрики.
Журналы ресурсов Azure Monitor
Журналы ресурсов предоставляют аналитические сведения об операциях, выполненных ресурсом Azure. Журналы создаются автоматически, но их необходимо перенаправить в журналы Azure Monitor, чтобы сохранить или запросить их. Журналы организованы по категориям. Заданное пространство имен может содержать несколько категорий журналов ресурсов.
Коллекция. Журналы ресурсов не собираются и хранятся, пока не создадите параметр диагностики и перенаправите журналы в одно или несколько расположений. Создавая параметр диагностики, нужно указать, какие категории журналов должны собираться. Существует несколько способов создания и обслуживания параметров диагностики, включая портал Azure, программно и хотя Политика Azure.
Маршрутизация: рекомендуемая по умолчанию — маршрутизация журналов ресурсов в журналы Azure Monitor, чтобы запросить их с другими данными журнала. Также доступны другие расположения, такие как служба хранилища Azure, Центры событий Azure и некоторые партнеры по мониторингу Майкрософт. Дополнительные сведения см. в журналах ресурсов Azure и назначениях журналов ресурсов.
Подробные сведения о сборе, хранении и маршрутизации журналов ресурсов см. в разделе "Параметры диагностики" в Azure Monitor.
Список всех доступных категорий журналов ресурсов в Azure Monitor см. в статье "Поддерживаемые журналы ресурсов" в Azure Monitor.
Все журналы ресурсов в Azure Monitor имеют одинаковые поля заголовков, а затем поля для конкретной службы. Общая схема показана в разделе Схема журнала ресурсов Azure Monitor.
Доступные категории журналов ресурсов, связанные таблицы Log Analytics и схемы журналов для AKS, см. в справочнике по данным мониторинга AKS.
Журналы ресурсов контрольной плоскости AKS
Журналы плоскости управления для кластеров AKS реализуются в виде журналов ресурсов в Azure Monitor. Журналы ресурсов не собираются и не хранятся, пока не создадите настройки диагностики для их перенаправления как минимум в одно местоположение. Обычно журналы ресурсов отправляются в рабочую область Log Analytics, где хранятся большинство данных для аналитики контейнеров.
Сведения о создании параметра диагностики с помощью портала Azure, Azure CLI или Azure PowerShell см. в статье "Создание параметров диагностики". Создавая параметр диагностики, нужно указать, какие категории журналов должны собираться. Категории для AKS перечислены в справочнике по данным мониторинга AKS.
Предупреждение
При сборе журналов ресурсов для AKS можно нести значительные затраты, особенно для журналов kube-audit. Рассмотрим следующие рекомендации, чтобы уменьшить объем собранных данных:
- Отключите
kube-audit
ведение журнала, если не требуется. - Включите коллекцию из
kube-audit-admin
, исключая события аудитаget
иlist
. - Включите журналы, относящиеся к ресурсам, как описано в этой статье, и настройте таблицу AKSAudit в качестве базовых журналов.
Дополнительные рекомендации по мониторингу см. в статье "Мониторинг кластеров AKS" с помощью служб Azure и облачных средств. Стратегии снижения затрат на мониторинг см. в статье "Оптимизация затрат" и Azure Monitor.
AKS поддерживает режим диагностика Azure или режим, зависящий от ресурса, для журналов ресурсов. Режим диагностики Azure отправляет все данные в таблицу AzureDiagnostics. Режим, зависящий от ресурса, указывает таблицы в рабочей области Log Analytics, в которой отправляются данные. Он также отправляет данные в AKSAudit
, AKSAuditAdmin
и AKSControlPlane
, как показано в таблице в журналах ресурсов.
Для AKS рекомендуется использовать режим, зависящий от ресурсов, по следующим причинам:
- Данные проще запрашивать, так как они находятся в отдельных таблицах, предназначенных для AKS.
- Режим, зависящий от ресурса, поддерживает конфигурацию как базовые журналы для значительной экономии затрат.
Дополнительные сведения о различиях между режимами сбора, включая изменение существующего параметра, см. в разделе "Выбор режима коллекции".
Примечание.
Параметры диагностики можно настроить с помощью Azure CLI. Этот подход не гарантирует успех, поскольку он не проверяет состояние предоставления кластера. После изменения параметров диагностики убедитесь, что кластер отражает изменения параметров.
az monitor diagnostic-settings create --name AKS-Diagnostics --resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.ContainerService/managedClusters/my-cluster --logs '[{"category": "kube-audit","enabled": true}, {"category": "kube-audit-admin", "enabled": true}, {"category": "kube-apiserver", "enabled": true}, {"category": "kube-controller-manager", "enabled": true}, {"category": "kube-scheduler", "enabled": true}, {"category": "cluster-autoscaler", "enabled": true}, {"category": "cloud-controller-manager", "enabled": true}, {"category": "guard", "enabled": true}, {"category": "csi-azuredisk-controller", "enabled": true}, {"category": "csi-azurefile-controller", "enabled": true}, {"category": "csi-snapshot-controller", "enabled": true}]' --workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myresourcegroup/providers/microsoft.operationalinsights/workspaces/myworkspace --export-to-resource-specific true
Пример запросов журнала
Внимание
При выборе Логи в меню кластера AKS открывается Log Analytics с областью запроса, заданной для текущего кластера. Запросы журнала включают данные только из этого ресурса. Чтобы выполнить запрос, содержащий данные из других кластеров или данных из других служб Azure, в меню Azure Monitor выберите журналы. Дополнительные сведения см. в разделе "Область запросов журнала" и диапазон времени в Log Analytics.
Если параметры диагностики для кластера используют режим диагностики Azure, журналы ресурсов для AKS хранятся в таблице AzureDiagnostics . Определите журналы с помощью столбца Категория. Описание каждой категории см. в справочнике по журналам ресурсов AKS.
Описание | Запрос журнала |
---|---|
Подсчет журналов для каждой категории (Режим диагностика Azure) |
AzureDiagnostics | where ResourceType == "MANAGEDCLUSTERS" | summarize count() by Category |
Все журналы сервера API (Режим диагностика Azure) |
AzureDiagnostics | where Category == "kube-apiserver" |
Все журналы аудита kube в диапазоне времени (Режим диагностика Azure) |
let starttime = datetime("2023-02-23"); let endtime = datetime("2023-02-24"); AzureDiagnostics | where TimeGenerated between(starttime..endtime) | where Category == "kube-audit" | extend event = parse_json(log_s) | extend HttpMethod = tostring(event.verb) | extend User = tostring(event.user.username) | extend Apiserver = pod_s | extend SourceIP = tostring(event.sourceIPs[0]) | project TimeGenerated, Category, HttpMethod, User, Apiserver, SourceIP, OperationName, event |
Все журналы аудита (режим, зависящий от ресурса) |
AKSAudit |
Все журналы аудита, за исключением событий аудита get и list (режим, зависящий от ресурса) |
AKSAuditAdmin |
Все журналы сервера API (режим, зависящий от ресурса) |
AKSControlPlane | where Category == "kube-apiserver" |
Чтобы получить доступ к набору предварительно созданных запросов в рабочей области Log Analytics, ознакомьтесь с интерфейсом запросов Log Analytics и выберите тип ресурса Kubernetes Services . Список распространенных запросов для аналитики контейнеров см . в разделе "Запросы аналитики контейнеров".
Журналы аналитики контейнеров плоскости данных AKS
Аналитика контейнеров собирает различные типы данных телеметрии из контейнеров и кластеров AKS, помогая отслеживать, устранять неполадки и получать аналитические сведения о контейнерных приложениях, работающих в кластерах AKS. Список таблиц с подробными описаниями, используемыми службой аналитики контейнеров, представлен в справочнике по таблицам Azure Monitor. Все таблицы доступны для запросов журналов.
Используйте параметры оптимизации затрат для настройки и управления данными метрик, собранными с помощью агента аналитики контейнеров. Эта функция поддерживает параметры сбора данных для отдельных наборов таблиц, интервалов сбора данных и пространств имен, чтобы исключить сбор данных с помощью правил сбора данных Azure Monitor (DCR). Эти параметры управляют объемом приема и сокращают затраты на мониторинг аналитических сведений о контейнерах. Данные аналитики контейнеров на портале Azure можно настроить с помощью следующих параметров. Выбор всех параметров, отличных от всех (по умолчанию), делает интерфейс аналитики контейнеров недоступным.
Группировка | Таблицы | Примечания. |
---|---|---|
Все (по умолчанию) | Все стандартные таблицы аналитики контейнеров | Требуется для включения визуализаций аналитики контейнеров по умолчанию. |
Производительность | Perf, InsightsMetrics | |
Журналы и события | ContainerLog или ContainerLogV2, KubeEvents, KubePodInventory | Рекомендуется, если вы включили управляемую службу для метрик Prometheus. |
Рабочие нагрузки, развертывания и HPAs | InsightsMetrics, KubePodInventory, KubeEvents, ContainerInventory, ContainerNodeInventory, KubeNodeInventory, KubeServices | |
Постоянные тома | InsightsMetrics, KubePVInventory |
Группировка журналов и событий собирает журналы из таблиц ContainerLog или ContainerLogV2, KubeEvents и KubePodInventory, но не метрики. Рекомендуемый путь для сбора метрик — включить управляемую службу для Prometheus из кластера AKS и использовать Azure Managed Grafana для визуализации данных. Дополнительные сведения см. в статье Управление рабочей областью в Azure Monitor.
Схема ContainerLogV2
Аналитика контейнеров в Azure Monitor предоставляет рекомендуемую схему для журналов контейнеров ContainerLogV2. Формат включает следующие поля для распространенных запросов для просмотра данных, связанных с AKS и кластерами Kubernetes с поддержкой Azure Arc:
- Имя контейнера
- PodName
- PodNamespace
Эта схема совместима с планом данных таблицы базовых журналов, который предлагает доступную альтернативу стандартным журналам аналитики. Используйте план данных таблицы базовых журналов, чтобы сэкономить на стоимости приема и хранения больших объемов, подробных журналов в рабочей области Log Analytics для отладки, устранения неполадок и аудита. Это не влияет на затраты на аналитику и оповещения. Дополнительные сведения см. в разделе "Управление таблицами" в рабочей области Log Analytics.
Мы рекомендуем использовать схему ContainerLogV2 по умолчанию, если вы подключаете анализ контейнеров с помощью проверки подлинности управляемого удостоверения, используя шаблон Azure Resource Manager (ARM-шаблон), Bicep, Terraform, политику Azure или портал Azure. Дополнительные сведения о включении ContainerLogV2 с помощью DCR или конфигурации кластера см. в разделе "Включить схему ContainerLogV2".
Журнал действий Azure
Журнал действий содержит события уровня подписки, отслеживающие операции для каждого ресурса Azure, как видно извне этого ресурса; например, создание нового ресурса или запуск виртуальной машины.
Коллекция: события журнала действий автоматически создаются и собираются в отдельном хранилище для просмотра в портал Azure.
Маршрутизация. Вы можете отправлять данные журнала действий в журналы Azure Monitor, чтобы их можно было анализировать вместе с другими данными журнала. Также доступны другие расположения, такие как служба хранилища Azure, Центры событий Azure и некоторые партнеры по мониторингу Майкрософт. Дополнительные сведения о маршрутизации журнала действий см. в разделе "Обзор журнала действий Azure".
Просмотр журналов контейнеров AKS, событий и метрик pod в режиме реального времени
Используйте функцию динамических данных в аналитике контейнеров для просмотра журналов контейнеров AKS, событий и метрик pod. Получите прямой доступ к kubectl logs -c
, kubectl get
событиям и kubectl top pods
, чтобы помогать вам устранять неполадки в режиме реального времени.
Примечание.
AKS использует архитектуры ведения журнала на уровне кластера Kubernetes. Журналы контейнеров находятся на узле по адресу /var/log/containers
. Чтобы получить доступ к узлу, см. статью "Подключение к узлам кластера AKS".
Сведения о настройке этой функции см. в статье "Настройка динамических данных" в аналитике контейнеров. Функция напрямую обращается к API Kubernetes. Дополнительные сведения о модели проверки подлинности см. в API Kubernetes.
Просмотр динамических журналов ресурсов AKS
Примечание.
Чтобы получить доступ к журналам из частного кластера, необходимо использовать компьютер, который находится в той же частной сети, что и кластер.
- На портале Azure перейдите в кластер AKS.
- В разделе ресурсов Kubernetes выберите рабочие нагрузки.
- Для развертывания, Pod, ReplicaSet, StatefulSet, задания или Cron задания выберите значение, а затем выберите Живые логи.
- Выберите журнал ресурсов для просмотра.
В следующем примере показаны логи для ресурса pod:
Просмотр динамических журналов
Данные журнала в режиме реального времени можно просматривать, как только подсистема контейнеров её генерирует, на вкладке «Кластер», «Узлы», «Контроллеры» или «Контейнеры».
- На портале Azure перейдите в кластер AKS.
- В разделе Мониторинг выберите Аналитические сведения.
- На вкладке "Кластер", "Узлы", "Контроллеры" или " Контейнеры " выберите значение.
- На панели обзора ресурса выберите "Динамические журналы".
Примечание.
Чтобы просмотреть данные из рабочей области Log Analytics, выберите "Просмотреть журналы" в Log Analytics. Чтобы узнать больше о просмотре исторических журналов, событий и метрик, см. Запросы журналов в аналитике контейнеров.
После успешной проверки подлинности, если данные можно получить, начинается их потоковая передача на вкладку "Динамические журналы". Данные журнала отображаются здесь в непрерывном потоке.
На следующем рисунке показаны логи для контейнера ресурса:
Просмотр трансляций
Вы можете просматривать данные событий в режиме реального времени, которые генерируются движком контейнеров, на вкладке "Кластер", "Узлы", "Контроллеры" или "Контейнеры".
- На портале Azure перейдите в кластер AKS.
- В разделе Мониторинг выберите Аналитические сведения.
- Перейдите на вкладку "Кластер", "Узлы", "Контроллеры" или " Контейнеры " и выберите объект.
- На панели обзора ресурсов выберите "Трансляции".
Примечание.
Чтобы просмотреть данные из рабочей области Log Analytics, выберите "Просмотреть события" в Log Analytics. Чтобы узнать больше о просмотре исторических журналов, событий и метрик, см. Запросы журналов в аналитике контейнеров.
После успешной проверки подлинности, если данные можно получить, начинается потоковая передача на вкладку "Трансляции". На следующем рисунке показаны события для ресурса контейнера:
Просмотр метрик
Данные метрик в режиме реального времени можно просматривать по мере их генерации контейнерным движком на вкладке "Узлы или Контроллеры, выбрав ресурс pod.
- На портале Azure перейдите в кластер AKS.
- В разделе Мониторинг выберите Аналитические сведения.
- Перейдите на вкладку "Узлы " или "Контроллеры ", а затем выберите объект pod.
- На панели "Обзор ресурсов" выберите "Динамические метрики".
Примечание.
Чтобы просмотреть данные из рабочей области Log Analytics, выберите "Просмотреть события" в Log Analytics. Чтобы узнать больше о просмотре исторических журналов, событий и метрик, см. Запросы журналов в аналитике контейнеров.
После успешной проверки подлинности, если данные можно получить, они начинают потоковую передачу на вкладку Реальные метрики. На следующем рисунке показаны метрики для pod-ресурса:
Анализ данных мониторинга
Существует множество средств для анализа данных мониторинга.
Средства Azure Monitor
Azure Monitor поддерживает следующие основные средства:
Обозреватель метрик— средство в портал Azure, позволяющее просматривать и анализировать метрики для ресурсов Azure. Дополнительные сведения см. в разделе "Анализ метрик" с помощью обозревателя метрик Azure Monitor.
Log Analytics— средство в портал Azure, позволяющее запрашивать и анализировать данные журнала с помощью языка запросов Kusto (KQL). Дополнительные сведения см. в статье Начало работы с запросами журнала в Azure Monitor.
Журнал действий, имеющий пользовательский интерфейс в портал Azure для просмотра и базового поиска. Для более подробного анализа необходимо направлять данные в журналы Azure Monitor и выполнять более сложные запросы в Log Analytics.
Средства, которые позволяют более сложной визуализации, включают:
- Панели мониторинга, позволяющие объединить различные виды данных в одну область в портал Azure.
- Книги, настраиваемые отчеты, которые можно создать в портал Azure. Книги могут включать текст, метрики и запросы журналов.
- Grafana — открытое средство платформы, которое работает на операционных панелях мониторинга. С помощью Grafana можно создавать панели мониторинга, содержащие данные из нескольких источников, отличных от Azure Monitor.
- Power BI— служба бизнес-аналитики, которая предоставляет интерактивные визуализации в различных источниках данных. Вы можете настроить Power BI на автоматический импорт данных журналов из Azure Monitor, чтобы воспользоваться этими визуализациями.
Средства экспорта Azure Monitor
Вы можете получить данные из Azure Monitor в другие средства с помощью следующих методов:
Метрики. Используйте REST API для метрик для извлечения данных метрик из базы данных метрик Azure Monitor. API поддерживает выражения фильтров для уточнения полученных данных. Дополнительные сведения см . в справочнике по REST API Azure Monitor.
Журналы: используйте REST API или связанные клиентские библиотеки.
Другим вариантом является экспорт данных рабочей области.
Сведения о начале работы с REST API для Azure Monitor см . в пошаговом руководстве по REST API мониторинга Azure.
Мониторинг с помощью области обзора на портале Azure
Вкладка "Мониторинг " на панели "Обзор " для ресурса кластера AKS позволяет быстро просмотреть данные мониторинга на портале Azure. Эта вкладка содержит графы с общими метриками для кластера, разделенного пулом узлов. Для дальнейшего анализа данных в обозревателе метрик можно выбрать любой из этих графов.
Вкладка "Мониторинг " также содержит ссылки на управляемую службу Azure для Prometheus и аналитику контейнеров для кластера. Эти средства можно включить на вкладке "Мониторинг ". Вы также можете увидеть баннер в верхней части панели, которая рекомендует другим функциям улучшить мониторинг кластера.
Совет
Чтобы получить доступ к функциям мониторинга для всех кластеров AKS в подписке, на домашней странице портала Azure выберите Azure Monitor.
Запросы Kusto
Данные мониторинга можно анализировать в хранилище журналов Azure Monitor или Log Analytics с помощью языка запросов Kusto (KQL).
Внимание
При выборе журналов в меню службы на портале Log Analytics откроется область запроса, заданная текущей службой. Эта область означает, что запросы журналов будут включать только данные из этого типа ресурса. Если вы хотите выполнить запрос, содержащий данные из других служб Azure, выберите журналы в меню Azure Monitor . Подробные сведения см. в статье Область запросов журнала и временной диапазон в Azure Monitor Log Analytics.
Список распространенных запросов для любой службы см. в интерфейсе запросов Log Analytics.
видны узлы
Оповещения Azure Monitor заранее уведомляют вас о конкретных условиях, обнаруженных в данных мониторинга. Оповещения позволяют выявлять и устранять проблемы в системе, прежде чем клиенты заметят их. Дополнительные сведения см. в оповещениях Azure Monitor.
Существует множество источников распространенных оповещений для ресурсов Azure. Примеры распространенных оповещений для ресурсов Azure см. в примерах запросов оповещений журнала. Сайт базовых оповещений Azure Monitor (AMBA) предоставляет полуавтомативный метод реализации важных оповещений метрик платформы, панелей мониторинга и рекомендаций. Сайт применяется к постоянно расширяющемуся подмножество служб Azure, включая все службы, которые являются частью целевой зоны Azure (ALZ).
Общая схема оповещений стандартизирует потребление уведомлений об оповещениях Azure Monitor. Дополнительные сведения см. в разделе "Общая схема оповещений".
Типов оповещений
Вы можете получать оповещения о любых источниках данных метрик или журналов на платформе данных Azure Monitor. Существует множество различных типов оповещений в зависимости от служб, которые вы отслеживаете, и данных мониторинга, которые вы собираете. Различные типы оповещений имеют различные преимущества и недостатки. Дополнительные сведения см. в разделе "Выбор правильного типа оповещений мониторинга".
В следующем списке описаны типы оповещений Azure Monitor, которые можно создать:
- Оповещения метрик оценивают метрики ресурсов через регулярные интервалы. Метрики могут быть метриками платформы, пользовательскими метриками, журналами из Azure Monitor, преобразованными в метрики или метриками Application Insights. Оповещения метрик также могут применять несколько условий и динамические пороговые значения.
- Оповещения журнала позволяют пользователям использовать запрос Log Analytics для оценки журналов ресурсов на предопределенной частоте.
- Оповещения журнала действий активируются при возникновении нового события журнала действий, соответствующего определенным условиям. Работоспособность ресурсов оповещения и оповещения о работоспособности служб — это оповещения журнала действий, которые сообщают о работоспособности службы и ресурсов.
Некоторые службы Azure также поддерживают оповещения интеллектуального обнаружения, оповещения Prometheus или рекомендуемые правила генерации оповещений.
Для некоторых служб можно отслеживать масштаб, применяя одно правило генерации оповещений метрик к нескольким ресурсам одного типа, которые существуют в одном регионе Azure. Для каждого отслеживаемого ресурса отправляются отдельные уведомления. Сведения о поддерживаемых службах и облаках Azure см. в статье "Мониторинг нескольких ресурсов с помощью одного правила генерации оповещений".
Рекомендуемые правила генерации оповещений
Для некоторых служб Azure можно включить рекомендуемые правила оповещений вне поля.
Система компилирует список рекомендуемых правил генерации оповещений на основе:
- Знания поставщика ресурсов о важных сигналах и пороговых значениях для мониторинга ресурса.
- Данные, указывающие клиентам, которые обычно оповещают об этом ресурсе.
Примечание.
Рекомендуемые правила генерации оповещений доступны для следующих вариантов:
- Виртуальные машины
- ресурсы Служба Azure Kubernetes (AKS)
- Рабочие области Log Analytics
Оповещения на основе метрик Prometheus
При включении коллекции управляемых служб для метрик Prometheus для кластера можно скачать коллекцию рекомендуемых управляемых служб для правил генерации оповещений Prometheus.
Скачивание включает следующие правила:
Уровень | видны узлы |
---|---|
Уровень кластера | KubeCPUQuotaOvercommit KubeMemoryQuotaOvercommit KubeContainerOOMKilledCount KubeClientErrors KubePersistentVolumeFillingUp KubePersistentVolumeInodesFillingUp KubePersistentVolumeErrors KubeContainerWaiting KubeDaemonSetNotScheduled KubeDaemonSetMisScheduled KubeQuotaAlmostFull |
Уровень узла | KubeNodeUnreachable KubeNodeReadinessFlapping |
Уровень pod | KubePVUsageHigh KubeDeploymentReplicasMismatch KubeStatefulSetReplicasMismatch KubeHpaReplicasMismatch KubeHpaMaxedOut KubePodCrashLooping KubeJobStale KubePodContainerRestart KubePodReadyStateLow KubePodFailedState KubePodNotReadyByController KubeStatefulSetGenerationMismatch KubeJobFailed KubeContainerAverageCPUHigh KubeContainerAverageMemoryHigh KubeletPodStartUpLatencyHigh |
Дополнительные сведения см. в разделе Создание оповещений журнала по данным Аналитики контейнеров и Запрос журналов по данным Аналитики контейнеров.
Оповещения журнала могут измерять два типа информации, помогая отслеживать различные сценарии:
- Число результатов: подсчитывает количество строк, возвращаемых запросом. Используйте эти сведения для работы с такими событиями, как журналы событий Windows, события системного журнала и исключения приложений.
- Вычисление значения: выполняет вычисление на основе числового столбца. Используйте эти сведения для включения различных ресурсов. Примером является процент ЦП.
Большинство запросов журнала сравнивают значение DateTime
с текущим временем, используя оператор now
и возвращаясь на один час назад. Сведения о создании оповещений на основе журналов см. в статье "Создание оповещений журнала" из аналитики контейнеров.
Правила генерации оповещений AKS
В следующей таблице перечислены некоторые предлагаемые правила генерации оповещений для AKS. Эти оповещения являются только примерами. Вы можете настраивать оповещения для любой метрики, записи журнала или записи о действиях в журнале, перечисленных в справочнике по данным мониторинга AKS.
Условие | Описание |
---|---|
Процент >использования ЦП95 | Оповещения, когда среднее использование ЦП на всех узлах превышает пороговое значение. |
Процент используемого рабочего набора памяти>100 | Оповещения срабатывают, когда средний рабочий набор по всем узлам превышает пороговое значение. |
Рекомендации Помощника
Для некоторых служб, если критические условия или неизбежные изменения происходят во время операций ресурсов, на странице обзора службы на портале отображается оповещение. Дополнительные сведения и рекомендуемые исправления для оповещения в рекомендациях Помощника см. в разделе "Мониторинг" в меню слева. Во время обычных операций рекомендации помощника не отображаются.
Дополнительные сведения о Помощнике по Azure см. в обзоре Помощника по Azure.
Примечание.
Если вы создаете или запускаете приложение, работающее в службе, аналитика приложений Azure Monitor может предложить дополнительные типы оповещений.
Метрики сети узла
Метрики сети узлов важны для поддержания работоспособного и производительного кластера Kubernetes. Собирая и анализируя данные о сетевом трафике, вы можете получить ценные сведения о работе кластера и определить потенциальные проблемы, прежде чем они приводят к сбоям или потере производительности.
В Kubernetes версии 1.29 и более поздних версиях метрики сети узлов включены по умолчанию для всех кластеров с включенным Azure Monitor.
Следующие сетевые метрики узлов включены по умолчанию и агрегируются на узел. Все метрики включают метки кластера и экземпляра (имя узла). Эти метрики можно легко просмотреть с помощью панели мониторинга Managed Grafana в сетевых кластерах Azure под Managed Prometheus>Kubernetes>.
Метрики уровня узла
Следующие метрики агрегируются для каждого узла.
Все метрики включают следующие метки:
cluster
-
instance
(имя узла)
В сценариях плоскости данных Cilium функция наблюдения за сетями контейнеров предоставляет метрики только для Linux. В настоящее время Windows не поддерживается для метрик наблюдаемости сети контейнеров.
Cilium предоставляет несколько метрик, которые используются для наблюдения за сетью контейнеров.
Имя метрики | Описание | Дополнительные метки | Линукс | Виндоус |
---|---|---|---|---|
общее количество пересылок cilium | Общее число пересылаемых пакетов | direction |
✅ | ❌ |
cilium_forward_bytes_total (общее количество переданных байт Cilium) | Общее число перенаправленных байтов | direction |
✅ | ❌ |
cilium_drop_count_total (общее количество сбросов cilium) | Общее число потерянных пакетов |
direction , reason |
✅ | ❌ |
cilium_drop_bytes_total | Общее число утраченных байтов |
direction , reason |
✅ | ❌ |
Подробные метрики уровня pod и DNS см. в разделе "Расширенные сетевые службы контейнеров".
Связанный контент
- Справочник по метрикам, журналам и другим важным значениям, созданным для AKS, см. в справочнике по данным мониторинга AKS.
- Общие сведения о мониторинге ресурсов Azure см. в статье "Мониторинг ресурсов Azure" с помощью Azure Monitor.
Azure Kubernetes Service