Мониторинг службы Azure Kubernetes (AKS)

Для мониторинга AKS требуется несколько уровней наблюдаемости между метриками платформы, метриками Prometheus, журналами действий, журналами ресурсов и аналитикой контейнеров. AKS предоставляет встроенные возможности мониторинга и интегрируется с Azure Monitor, аналитикой контейнеров, управляемой службой для Prometheus и Управляемой Grafana Azure для комплексного мониторинга работоспособности и производительности кластера.

Аналитические выводы (Insights)

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

Данные мониторинга AKS: метрики, журналы, интеграции

AKS создает те же типы данных мониторинга, что и другие ресурсы Azure, как описано в разделе "Мониторинг данных из ресурсов Azure". Подробные сведения о метриках и журналах, созданных AKS, см. в справочнике по данным мониторинга AKS.

Другие службы и функции 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.

Метрики, отличные от Azure Monitor

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

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

На портале Azure перейдите на вкладку "Интеграция" или используйте Azure CLI, Terraform или политику Azure. В некоторых случаях вы можете подключить кластер к службе мониторинга или функции после создания кластера. Каждая служба или функция могут повлечь за собой затраты, поэтому перед включением см. сведения о ценах для каждого компонента.

Мониторинг метрик плоскости управления AKS (предварительная версия)

Предварительные требования и область. Эта предварительная версия доступна для кластеров AKS под управлением Kubernetes 1.27 или более поздней версии и требует включения управляемой службы для Prometheus в кластере. В настоящее время эта функция поддерживает пулы узлов Linux и Windows, но не совместима с группами доступности виртуальных машин (VMAS).

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

Необходимые условия. Требуется рабочая область Log Analytics в той же подписке, что и кластер AKS. Журналы ресурсов создают затраты на ингестию и хранение в целевом рабочем пространстве. Для оптимизации затрат используйте режим, зависящий от ресурсов, и настройте уровень базовых журналов для таблиц аудита.

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

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

AKS поддерживает режим диагностика Azure или режим, зависящий от ресурса, для журналов ресурсов. Режим диагностики Azure отправляет все данные в таблицу AzureDiagnostics. Режим, зависящий от ресурса, указывает таблицы в рабочей области Log Analytics, в которой отправляются данные. Он также отправляет данные в AKSAudit, AKSAuditAdmin и AKSControlPlane, как показано в таблице в журналах ресурсов.

Для AKS рекомендуется использовать режим, зависящий от ресурсов, по следующим причинам:

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

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

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

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

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

Чтобы получить доступ к набору предварительно созданных запросов в рабочей области Log Analytics, ознакомьтесь с интерфейсом запросов Log Analytics и выберите тип ресурса Kubernetes Services . Список распространенных запросов для аналитики контейнеров см . в разделе "Запросы аналитики контейнеров".

Политика аудита AKS

AKS использует политику аудита Kubernetes для управления тем, какие события регистрируются и какие данные они содержат. Политика определяет правила, определяющие уровень аудита для различных типов запросов API на основе пользователей, ресурсов, пространств имен и команд. Используются следующие уровни аудита:

• Нет. События, соответствующие этому правилу, не регистрируются.
• Метаданные: метаданные журнала запроса (пользователь, сделавший запрос, метка времени, ресурс, глагол), но не текст запроса или ответа.
• Запрос: метаданные события журнала и текст запроса, но не текст ответа.
• RequestResponse: метаданные события журнала, органы запроса и ответа.

Следующая таблица суммирует ключевые правила аудиторской политики, применяемые в AKS:

Полная политика аудита, используемая в AKS, доступна для ознакомления в следующем сворачиваемом разделе.

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # audit level 'None' for high volume and low risk events
  - level: None
    users: ["aksService"]
    verbs: ["get", "list"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: ""
        resources: ["endpoints", "services", "services/status"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["kubelet"] # legacy kubelet identity
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes", "nodes/status"]
  # audit level 'None' for low-risk requests
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["nodes", "nodes/status"]
  # audit level 'None' for low-risk requests
  - level: None
    users:
      - aksService # the default user/cert used by aks in master node
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: ""
        resources: ["endpoints"]
  # audit level 'None' for low-risk requests
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: ""
        resources: ["namespaces", "namespaces/status", "namespaces/finalize"]
  # audit level 'None' for low-risk requests
  - level: None
    users:
      - aksService # the default user/cert used by aks in master node
    verbs: ["get", "list"]
    resources:
      - group: "metrics.k8s.io"
  # Don't log these read-only URLs.
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # monitor metadata for system events which are being logged by eventlogger component
  - level: Metadata
    verbs: ["create", "update", "patch"]
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
    namespaces: ["default", "kube-system"]
  # Monitoring of actions to detect security/performance relevant activities.
  - level: Metadata
    verbs: ["delete", "list"]
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
  # Don't log other events requests.
  - level: None
    resources:
      - group: ""
        resources: ["events"]
      - group: "events.k8s.io"
        resources: ["events"]
  # node and pod status calls from nodes are high-volume and can be large, don't log responses for expected updates from nodes
  - level: Request
    users: ["client", "kubelet", "system:node-problem-detector", "system:serviceaccount:kube-system:node-problem-detector", "system:serviceaccount:kube-system:aci-connector-linux"]
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["nodes/status", "pods/status"]
    omitStages:
      - "RequestReceived"
  # node and pod status calls from nodes are high-volume and can be large, don't log responses for expected updates from nodes
  - level: Request
    userGroups: ["system:nodes"]
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["nodes/status", "pods/status"]
    omitStages:
      - "RequestReceived"
  # deletecollection calls can be large, don't log responses for expected namespace deletions
  - level: Request
    users: ["system:serviceaccount:kube-system:namespace-controller"]
    verbs: ["deletecollection"]
    omitStages:
      - "RequestReceived"
  # ignore response object that has big size
  - level: Request
    verbs: ["update","patch"]
    resources:
      - group: "apiextensions.k8s.io"
        resources: ["customresourcedefinitions"]
        resourceNames: ["volumesnapshotcontents.snapshot.storage.k8s.io", "volumesnapshots.snapshot.storage.k8s.io"]
    omitStages:
      - "RequestReceived"
  # ignore request and response objects for large CRDs that will be filtered down anyway
  - level: Metadata
    resources:
      - group: "apiextensions.k8s.io"
        resources: ["customresourcedefinitions"]
        resourceNames: ["installations.operator.tigera.io"]
    omitStages:
      - "RequestReceived"
  # overriding the default behavior of coredns might have security threats for Kubernetes DNS in security perspective, set the level as RequestResponse
  - level: RequestResponse
    verbs: ["update","patch"]
    resources:
      - group: ""
        resources: ["configmaps"]
        resourceNames: ["coredns-custom"]
    namespaces: ["kube-system"]
    omitStages:
      - "RequestReceived"
  # Secrets, ConfigMaps, ServiceAccounts, TokenRequest and TokenReviews can contain sensitive & binary data,
  # so only log at the Metadata level.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps", "serviceaccounts", "serviceaccounts/token"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"
  # Capture state of vertical pod autoscalers
  - level: Request
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "autoscaling.k8s.io"
        resources: ["verticalpodautoscalers", "verticalpodautoscalercheckpoints"]
    omitStages:
      - "RequestReceived"
  # Capture create and delete of internal fleet resources
  - level: RequestResponse
    verbs: ["create", "delete"]
    resources:
      - group: "cluster.kubernetes-fleet.io"
        resources: ["memberclusters", "internalmemberclusters"]
      - group: "placement.kubernetes-fleet.io"
        resources: ["works"]
      - group: "networking.fleet.azure.com"
        resources: ["internalserviceexports", "internalserviceimports"]
    omitStages:
      - "RequestReceived"
  # Capture CUD of user facing Fleet API
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "placement.kubernetes-fleet.io"
        resources: ["clusterstagedupdateruns", "clusterresourceplacements", "clusterresourceplacementevictions", "clusterresourceplacementdisruptionbudgets", "clusterstagedupdatestrategies", "clusterapprovalrequests", "clusterresourceoverrides", "resourceoverrides"]
      - group: "networking.fleet.azure.com"
        resources: ["serviceexports", "multiclusterservices", "trafficmanagerprofiles", "trafficmanagerbackends"]
    omitStages:
      - "RequestReceived"
  # Capture CUD of user facing Karpenter resources
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "karpenter.azure.com"
        resources: ["aksnodeclasses", "aksnodeclasses/status"]
      - group: "karpenter.sh"
        resources: ["nodepools", "nodepools/status", "nodeclaims", "nodeclaims/status"]
    omitStages:
      - "RequestReceived"
  # Get responses can be large; don't log response
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: ""
      - group: "admissionregistration.k8s.io"
      - group: "apiextensions.k8s.io"
      - group: "apiregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "metrics.k8s.io"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "scheduling.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
    omitStages:
      - "RequestReceived"
  # Default level for known APIs
  - level: RequestResponse
    resources:
      - group: ""
      - group: "admissionregistration.k8s.io"
      - group: "apiextensions.k8s.io"
      - group: "apiregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "metrics.k8s.io"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "scheduling.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
    omitStages:
      - "RequestReceived"
  # Default level for all other requests.
  - level: Metadata
    omitStages:
      - "RequestReceived"

Журналы аналитики контейнеров плоскости данных AKS

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

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

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

Группировка журналов и событий собирает журналы из таблиц ContainerLog или ContainerLogV2, KubeEvents и KubePodInventory, но не метрики. Рекомендуемый путь для сбора метрик — включить управляемую службу для Prometheus из кластера AKS и использовать Azure Managed Grafana для визуализации данных. Дополнительные сведения см. в статье Управление рабочей областью в Azure Monitor.

Схема ContainerLogV2

Требования к совместимости и конфигурации: Схема ContainerLogV2 рекомендуется для новых развертываний Container insights, использующих аутентификацию с управляемой идентичностью через шаблоны Azure Resource Manager (ARM), Bicep, Terraform, политику Azure или портал Azure. Схема совместима с уровнем "Базовый" для экономии затрат и не влияет на функции аналитики или оповещений. Дополнительные сведения о включении ContainerLogV2 с помощью DCR или конфигурации кластера см. в разделе "Включить схему ContainerLogV2".

Аналитика контейнеров в Azure Monitor предоставляет рекомендуемую схему для журналов контейнеров ContainerLogV2. Формат включает следующие поля для распространенных запросов для просмотра данных, связанных с AKS и кластерами Kubernetes с поддержкой Azure Arc:

• Имя контейнера
• PodName
• PodNamespace

Журнал действий Azure

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

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

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

Просмотр журналов контейнеров AKS, событий и метрик pod в режиме реального времени

Предварительные требования и требования к настройке. Функция динамических данных требует включения аналитики контейнеров в кластере и прямого доступа к API Kubernetes. Для частных кластеров для доступа требуется компьютер в той же частной сети, что и кластер. Проверка подлинности соответствует модели RBAC Kubernetes и требует соответствующих разрешений кластера.

Вы можете просматривать журналы контейнеров AKS, события и метрики pod с помощью функции живые данные в Container Insights и устранять проблемы в режиме реального времени, получая прямой доступ к kubectl logs -c, kubectl get событиям и kubectl top pods pod.

Сведения о настройке этой функции см. в статье "Настройка динамических данных" в аналитике контейнеров. Функция напрямую обращается к API Kubernetes. Дополнительные сведения о модели проверки подлинности см. в API Kubernetes.

Просмотр динамических журналов ресурсов AKS

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

1. На портале Azure перейдите в кластер AKS.

2. В разделе ресурсов Kubernetes выберите рабочие нагрузки.

3. Для развертывания, Pod, ReplicaSet, StatefulSet, задания или Cron задания выберите значение, а затем выберите Живые логи.

4. Выберите журнал ресурсов для просмотра.

   В следующем примере показаны логи для ресурса pod:

   

Просмотр динамических журналов контейнера с помощью аналитики контейнеров

Проверка подлинности и потоковая передача данных: после успешной проверки подлинности, если данные можно получить, он начинает потоковую передачу на вкладку "Динамические журналы". Данные журнала отображаются в непрерывном потоке. Альтернативный доступ к журналам доступен через Просмотр журналов в Log Analytics для исторического анализа.

Данные журнала в режиме реального времени можно просматривать, как только подсистема контейнеров её генерирует, на вкладке «Кластер», «Узлы», «Контроллеры» или «Контейнеры».

1. На портале Azure перейдите в кластер AKS.

2. В разделе Мониторинг выберите Аналитические сведения.

3. На вкладке "Кластер", "Узлы", "Контроллеры" или " Контейнеры " выберите значение.

4. На панели обзора ресурса выберите "Динамические журналы".

   На следующем рисунке показаны логи для контейнера ресурса:

   

Просмотр динамических событий контейнера с помощью аналитики контейнеров

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

Вы можете просматривать данные событий в режиме реального времени, которые генерируются движком контейнеров, на вкладке "Кластер", "Узлы", "Контроллеры" или "Контейнеры".

1. На портале Azure перейдите в кластер AKS.

2. В разделе Мониторинг выберите Аналитические сведения.

3. Перейдите на вкладку "Кластер", "Узлы", "Контроллеры" или " Контейнеры " и выберите объект.

4. На панели обзора ресурсов выберите "Трансляции".

   После успешной проверки подлинности, если данные можно получить, начинается потоковая передача на вкладку "Трансляции". На следующем рисунке показаны события для ресурса контейнера:

   

Просмотр динамических метрик pod с помощью аналитики контейнеров

Область и доступность метрик: актуальные метрики доступны для ресурсов Pod на вкладках Узлы или Контроллеры. Метрики включают использование ЦП, потребление памяти, сетевые операции ввода-вывода и статистику файловой системы. Исторические метрики доступны через просмотр событий в Log Analytics.

Данные метрик в режиме реального времени можно просматривать по мере их генерации контейнерным движком на вкладке "Узлы или Контроллеры, выбрав ресурс pod.

1. На портале Azure перейдите в кластер AKS.

2. В разделе Мониторинг выберите Аналитические сведения.

3. Перейдите на вкладку "Узлы " или "Контроллеры ", а затем выберите объект pod.

4. На панели "Обзор ресурсов" выберите "Динамические метрики".

   После успешной проверки подлинности, если данные можно получить, они начинают потоковую передачу на вкладку Реальные метрики. На следующем рисунке показаны метрики для 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.

Мониторинг кластеров AKS на портале Azure

Вкладка "Мониторинг " на панели "Обзор " для ресурса кластера AKS позволяет быстро просмотреть данные мониторинга на портале Azure. Эта вкладка содержит графы с общими метриками для кластера, разделенного пулом узлов. Для дальнейшего анализа данных в обозревателе метрик можно выбрать любой из этих графов.

Вкладка "Мониторинг " также содержит ссылки на управляемую службу Azure для Prometheus и аналитику контейнеров для кластера. Эти средства можно включить на вкладке "Мониторинг ". Вы также можете увидеть баннер в верхней части панели, которая рекомендует другим функциям улучшить мониторинг кластера.

Запросы Kusto

Данные мониторинга можно анализировать в хранилище журналов Azure Monitor или Log Analytics с помощью языка запросов Kusto (KQL).

Список распространенных запросов для любой службы см. в интерфейсе запросов 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 можно включить рекомендуемые правила оповещений вне поля.

Система компилирует список рекомендуемых правил генерации оповещений на основе:

• Знания поставщика ресурсов о важных сигналах и пороговых значениях для мониторинга ресурса.
• Данные, указывающие клиентам, которые обычно оповещают об этом ресурсе.

Настройка оповещений на основе метрик Prometheus

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

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

Скачивание включает следующие правила:

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

Оповещения журнала могут измерять два типа информации, помогая отслеживать различные сценарии:

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

Большинство запросов журнала сравнивают DateTime значение с текущим временем, используя now оператор и рассматривая данные за прошлый час. Сведения о создании оповещений на основе журналов см. в статье "Создание оповещений журнала" из аналитики контейнеров.

Правила генерации оповещений AKS

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

Рекомендации Помощника

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

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

Мониторинг сетевых метрик узлов AKS

Требования к версии и включению. В Kubernetes версии 1.29 и более поздних версиях метрики сети узлов включены по умолчанию для всех кластеров с включенным Azure Monitor. Для более ранних версий Kubernetes необходимо вручную включить мониторинг сети с помощью конфигурации кластера. Эта функция требует настройки Azure Monitor или аналитики контейнеров в кластере.

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

Следующие сетевые метрики узлов включены по умолчанию и агрегируются на узел. Все метрики включают метки кластера и экземпляра (имя узла). Эти метрики можно легко просмотреть с помощью панели мониторинга Managed Grafana в разделе Azure Managed Prometheus>Kubernetes>сетевых кластеров.

Сетевые метрики узла AKS по типу плоскости данных

Все метрики включают следующие метки:

• cluster
• instance (имя узла)

Отключение сбора сетевых метрик узла AKS

Вы можете отключить сбор сетевых метрик на определенных узлах, добавив метку networking.azure.com/node-network-metrics=disabled в эти узлы.

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

kubectl label node <node-name> networking.azure.com/node-network-metrics=disabled

Подробные метрики уровня pod и DNS см. в разделе "Расширенные сетевые службы контейнеров".

Связанный контент

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