Monitorování služby Azure Kubernetes Service (AKS)

Monitorování AKS vyžaduje několik úrovní pozorovatelnosti napříč metrikami platformy, metrikami Prometheus, protokoly aktivit, protokoly prostředků a přehledy kontejnerů. AKS poskytuje integrované funkce monitorování a integruje se se službou Azure Monitor, Container Insights, spravovanou službou pro Prometheus a Azure Managed Grafana pro komplexní monitorování stavu clusteru a výkonu.

Návod

Ke konfiguraci monitorování clusterů AKS na webu Azure Portal můžete použít Azure Copilot. Další informace najdete v tématu Efektivní práce s clustery AKS pomocí Azure Copilotu.

Přehledy

Některé služby v Azure mají integrovaný řídicí panel monitorování na webu Azure Portal, který poskytuje výchozí bod pro monitorování vaší služby. Tyto řídicí panely se nazývají přehledy a najdete je v Centru přehledů služby Azure Monitor na webu Azure Portal.

Data monitorování AKS: metriky, protokoly, integrace

AKS generuje stejné druhy dat monitorování jako jiné prostředky Azure, jak je popsáno v tématu Monitorování dat z prostředků Azure. Podrobné informace o metrikách a protokolech vytvořených službou AKS najdete v referenčních informacích k datům monitorování AKS.

Ostatní služby a funkce Azure shromažďují další data a umožňují další možnosti analýzy, jak je znázorněno v následujícím diagramu a tabulce.

Diagram dat monitorování shromážděných z AKS

Zdroj Popis
Metriky platformy Metriky platformy se automaticky shromažďují pro clustery AKS zdarma. Tyto metriky můžete analyzovat pomocí Průzkumníka metrik nebo je použít k vytváření upozornění metrik.
Prometheus metriky Když povolíte výstřižky metrik pro cluster, spravovaná služba pro Prometheus ve službě Azure Monitor shromažďuje metriky Prometheus a ukládá je do pracovního prostoru Služby Azure Monitor. Analyzujte tyto metriky pomocí předem připravených řídicích panelů ve službě Azure Managed Grafana a s upozorněními Prometheus.
Protokoly aktivit Protokol aktivit služby Azure Monitor automaticky shromažďuje některá data pro clustery AKS bez poplatků. Tyto soubory protokolu sledují informace, jako je vytvoření clusteru nebo změny konfigurace clusteru. Pokud chcete analyzovat data protokolu aktivit s ostatními daty protokolu, odešlete data protokolu aktivit do pracovního prostoru služby Log Analytics.
Protokoly prostředků Protokoly řídicí roviny pro AKS jsou implementovány jako protokoly zdrojů. Vytvořte nastavení diagnostiky pro odesílání protokolů do pracovního prostoru služby Log Analytics. V pracovním prostoru můžete protokoly analyzovat pomocí dotazů a nastavit upozornění na základě informací protokolu.
Přehledy kontejnerů Container Insights shromažďuje různé protokoly a údaje o výkonu z clusteru a ukládá je do pracovního prostoru služby Log Analytics a v metrikách služby Azure Monitor. Analyzujte data jako stdout a stderr streamy pomocí zobrazení a sešitů v Container Insights nebo Log Analytics a Metrics Explorer.
Application Insights Application Insights, funkce služby Azure Monitor, shromažďuje protokoly, metriky a distribuované trasování. Telemetrie se ukládá do pracovního prostoru služby Log Analytics pro účely analýzy na webu Azure Portal. Pokud chcete povolit Application Insights se změnami kódu, přečtěte si článek Povolení Azure Monitor OpenTelemetry. Pokud chcete povolit Application Insights bez změn kódu, podívejte se na autoinstrumentaci AKS. Další informace o instrumentaci najdete v základních informacích o shromažďování dat.

Typy zdrojů

Azure používá koncept typů prostředků a ID k identifikaci všeho v předplatném. Typy prostředků jsou také součástí ID prostředků pro každý prostředek spuštěný v Azure. Například jedním typem prostředku pro virtuální počítač je Microsoft.Compute/virtualMachines. Seznam služeb a jejich přidružených typů prostředků najdete v tématu Poskytovatelé prostředků.

Azure Monitor podobně řadí základní monitorovací data do metrik a protokolů podle typů prostředků, také nazývaných jako jmenné prostory. Různé metriky a protokoly jsou k dispozici pro různé typy prostředků. Vaše služba může být přidružená k více než jednomu typu prostředku.

Další informace o typech prostředků v AKS najdete v referenčních informacích k datům monitorování AKS.

Úložiště dat

Pro použití s Azure Monitor:

  • Data metrik se ukládají v databázi metrik služby Azure Monitor.
  • Data protokolů se ukládají v úložišti protokolů služby Azure Monitor. Log Analytics je nástroj v portálu Azure, který umožňuje dotazování na toto úložiště.
  • Protokol aktivit Azure je samostatné úložiště s vlastním rozhraním na webu Azure Portal.

Volitelně můžete směrovat data metriky a protokolu aktivit do úložiště protokolů služby Azure Monitor. Log Analytics pak můžete použít k dotazování na data a jejich korelaci s jinými daty protokolů.

Mnoho služeb může použít nastavení diagnostiky k odesílání metrik a dat protokolů do jiných umístění úložiště mimo Azure Monitor. Mezi příklady patří Azure Storage, hostované partnerské systémy a partnerské systémy mimo Azure pomocí služby Event Hubs.

Podrobné informace o tom, jak Azure Monitor ukládá data, najdete na datové platformě Azure Monitoru.

Metriky platformy Azure Monitoru

Azure Monitor poskytuje metriky platformy pro většinu služeb. Tyto metriky jsou:

  • Individuálně definované pro každý obor názvů.
  • Uložená v databázi metrik časových řad služby Azure Monitor.
  • Zjednodušené a schopné podporovat upozorňování téměř v reálném čase.
  • Používá se ke sledování výkonu prostředku v průběhu času.

Kolekce: Azure Monitor shromažďuje metriky platformy automaticky. Není nutná žádná konfigurace.

Směrování: Některé metriky platformy můžete také směrovat do protokolů služby Azure Monitor / Log Analytics, abyste je mohli dotazovat pomocí jiných dat protokolů. Zkontrolujte nastavení exportu DS pro každou metriku a zjistěte, jestli můžete pomocí nastavení diagnostiky směrovat metriku do protokolů služby Azure Monitor nebo Log Analytics.

Seznam všech metrik, které je možné shromáždit pro všechny prostředky ve službě Azure Monitor, najdete v tématu Podporované metriky ve službě Azure Monitor.

Seznam metrik, které můžete shromažďovat pro AKS, najdete v referenčních informacích k datům monitorování AKS.

Metriky hrají důležitou roli při monitorování clusterů, identifikaci problémů a optimalizaci výkonu v clusterech AKS. Metriky platformy se zaznamenávají pomocí standardního serveru metrik nainstalovaného v oboru jmen kube-system, který pravidelně shromažďuje metriky ze všech uzlů AKS obsluhovaných kubeletem. Měli byste také povolit spravovanou službu pro metriky Prometheus ke shromažďování metrik kontejneru a metrik objektů Kubernetes, včetně stavu nasazení objektu.

Můžete zobrazit seznam výchozích spravovaných služeb pro metriky Prometheus.

Další informace najdete v tématu Shromažďování metrik spravované služby pro Prometheus z clusteru AKS.

Metriky nezaložené na službě Azure Monitor

Tato služba poskytuje další metriky, které nejsou zahrnuté v databázi metrik služby Azure Monitor.

K monitorování clusterů AKS můžete použít následující služby Azure a funkce služby Azure Monitor. Tyto funkce povolíte při vytváření clusteru AKS.

Na webu Azure Portal použijte kartu Integrace nebo použijte Azure CLI, Terraform nebo Azure Policy. V některých případech můžete cluster připojit ke službě monitorování nebo funkci po vytvoření clusteru. Za každou službu nebo funkci můžou být účtovány náklady, proto si před povolením prohlédněte informace o cenách jednotlivých komponent.

Služba nebo funkce Popis
Přehledy kontejnerů Používá konteinerizovanou verzi agenta Azure Monitor ke shromažďování protokolů a událostí Kubernetes z každého uzlu ve vašem clusteru. Tato funkce podporuje různé scénáře monitorování pro clustery AKS. Monitorování clusteru AKS můžete povolit při jeho vytvoření pomocí Azure CLI, Azure Policy, webu Azure Portal nebo Terraformu. Pokud při vytváření clusteru nepovolíte Přehledy kontejnerů, přečtěte si téma Povolení přehledů kontejnerů pro cluster AKS , kde najdete další možnosti, jak ho povolit.

Container Insights ukládá většinu svých dat do pracovního prostoru služby Log Analytics. Obvykle používáte stejný pracovní prostor služby Log Analytics jako protokoly prostředků pro váš cluster. Pokyny k tomu, kolik pracovních prostorů byste měli použít a kde je najít, najdete v tématu Návrh architektury pracovního prostoru služby Log Analytics.
Spravovaná služba pro Prometheus ve službě Azure Monitor Prometheus je řešení metrik nativní pro cloud ze služby Cloud Native Computing Foundation. Nejběžnějším nástrojem pro shromažďování a analýzu metrických dat z Kubernetes clusterů. Spravovaná služba pro Prometheus ve službě Azure Monitor je plně spravované řešení pro monitorování kompatibilní s platformou Prometheus. Pokud při vytváření clusteru nepovolíte spravovanou službu pro Prometheus, přečtěte si téma Shromažďování metrik Prometheus z clusteru AKS , kde najdete další možnosti, jak ji povolit.

Spravovaná služba pro Prometheus ve službě Azure Monitor ukládá data do pracovního prostoru služby Azure Monitor , který je propojený s pracovním prostorem Grafana. K analýze dat můžete použít Azure Managed Grafana.
Azure Managed Grafana Plně spravovaná implementace Grafany. Grafana je opensourcová platforma pro vizualizaci dat, která se běžně používá k prezentaci dat Prometheus. K dispozici je několik předdefinovaných řídicích panelů Grafana pro monitorování Kubernetes a komplexní řešení potíží s celým technologickým stackem. Pokud při vytváření clusteru nepovolíte Azure Managed Grafana, přečtěte si téma Propojení pracovního prostoru Grafana. Můžete ho propojit s pracovním prostorem služby Azure Monitor, aby mohl přistupovat k metrikám Prometheus z vašeho clusteru.

Monitorování metrik řídicí roviny AKS (Preview)

Požadavky a rozsah: Tato funkce Preview je dostupná pro clustery AKS se systémem Kubernetes 1.27 nebo novějším a vyžaduje, aby byla ve vašem clusteru povolená spravovaná služba pro Prometheus. Tato funkce aktuálně podporuje fondy uzlů Linuxu a Windows, ale není kompatibilní se skupinami dostupnosti virtuálních počítačů (VMAS).

AKS také zveřejňuje metriky z důležitých komponent řídicí roviny, jako je server API atd., a plánovač prostřednictvím spravované služby pro Prometheus ve službě Azure Monitor. V současné době je tato funkce ve verzi Preview. Další informace najdete v tématu Monitorování metrik řídicí roviny AKS. Podmnožina metrik řídicí roviny pro server rozhraní API a etcd jsou k dispozici zdarma prostřednictvím metrik platformy Služby Azure Monitor. Tyto metriky se ve výchozím nastavení shromažďují. Pomocí metrik můžete vytvářet výstrahy.

Protokoly prostředků služby Azure Monitor

Záznamy o prostředcích poskytují přehled o operacích, které byly provedeny prostředkem Azure. Protokoly se generují automaticky, ale pokud je chcete uložit nebo dotazovat, musíte je směrovat do protokolů služby Azure Monitor. Protokoly jsou uspořádané do kategorií. Daný obor názvů může mít více kategorií záznamů o prostředcích.

Kolekce: Protokoly prostředků se neshromažďují a neukládají, dokud nevytvoříte nastavení diagnostiky a nenasměrujete protokoly do jednoho nebo více umístění. Při vytváření nastavení diagnostiky určíte, které kategorie protokolů se mají shromažďovat. Existuje několik způsobů, jak vytvořit a udržovat nastavení diagnostiky, včetně webu Azure Portal, prostřednictvím kódu programu a služby Azure Policy.

Směrování: Navrhované výchozí nastavení je směrovat protokoly prostředků do protokolů Azure Monitor, abyste je mohli dotazovat spolu s dalšími protokolovanými daty. K dispozici jsou také jiná umístění, jako je Azure Storage, Azure Event Hubs a někteří monitorovací partneři Microsoftu. Další informace najdete v protokolech prostředků Azure a destinacích protokolů prostředků.

Podrobné informace o shromažďování, ukládání a směrování protokolů prostředků najdete v části Nastavení diagnostiky ve službě Azure Monitor.

Seznam všech dostupných kategorií protokolů prostředků ve službě Azure Monitor najdete v tématu Podporované protokoly prostředků ve službě Azure Monitor.

Všechny protokoly prostředků v Azure Monitoru mají stejná záhlaví, za nimiž následují pole specifická pro službu. Běžné schéma je popsané ve schématu protokolu prostředků služby Azure Monitor.

Dostupné kategorie protokolů prostředků, přidružené tabulky Log Analytics a schémata protokolů pro AKS najdete v referenčních informacích k datům monitorování AKS.

Protokoly prostředků řídicí roviny AKS

Požadavky: Vyžaduje pracovní prostor služby Log Analytics ve stejném předplatném jako cluster AKS. V protokolech prostředků se účtují náklady na příjem dat a uchovávání v cílovém pracovním prostoru. Pro optimalizaci nákladů použijte režim specifický pro prostředky a nakonfigurujte úroveň základních protokolů pro tabulky auditu.

Protokoly řídicí roviny pro clustery AKS se ve službě Azure Monitor implementují jako protokoly o prostředcích. Protokoly prostředků nejsou shromažďovány ani ukládány, dokud nevytvoříte diagnostické nastavení pro jejich směrování do alespoň jednoho umístění. Záznamy o prostředcích obvykle odesíláte do pracovního prostoru služby Log Analytics, kde je uložena většina dat pro přehledy kontejnerů.

Informace o vytvoření nastavení diagnostiky pomocí webu Azure Portal, Azure CLI nebo Azure PowerShellu najdete v tématu Vytvoření nastavení diagnostiky. Při vytváření nastavení diagnostiky určíte, které kategorie protokolů se mají shromažďovat. Kategorie pro AKS jsou uvedené v referenčních informacích o monitorování AKS.

Výstraha

Při shromažďování protokolů pro prostředky AKS, zejména pro protokoly kube-audit, mohou vzniknout značné náklady. Zvažte následující doporučení ke snížení množství shromážděných dat:

  • Zakažte kube-audit protokolování, pokud není vyžadováno.
  • Povolte kolekci z kube-audit-admin, která vylučuje get a list auditní události.
  • Povolte protokoly specifické pro prostředky, jak je popsáno v tomto článku, a nakonfigurujte tabulku AKSAudit jako základní protokoly.

Další doporučení pro monitorování najdete v tématu Monitorování clusterů AKS pomocí služeb Azure a nástrojů nativních pro cloud. Strategie pro snížení nákladů na monitorování najdete v tématu Optimalizace nákladů a Azure Monitor.

AKS podporuje pro protokoly prostředků buď režim diagnostiky Azure, nebo režim specifický pro prostředky. Režim diagnostiky Azure odesílá všechna data do tabulky AzureDiagnostics. Režim specifický pro zdroje definuje tabulky v pracovním prostoru Log Analytics, kam jsou data odesílána. Odesílá také data do AKSAudit, AKSAuditAdmin a AKSControlPlane, jak je znázorněno v tabulce v protokolech prostředků.

Doporučujeme používat pro AKS režim specifikovaný pro prostředky z těchto důvodů:

  • Dotazování dat je snazší, protože jsou v jednotlivých tabulkách, které jsou vyhrazené pro AKS.
  • Režim specifický pro prostředky podporuje konfiguraci jako základní logy pro významné úspory nákladů.

Další informace o rozdílu mezi režimy kolekce, včetně toho, jak změnit existující nastavení, najdete v tématu Výběr režimu kolekce.

Poznámka:

Nastavení diagnostiky můžete nakonfigurovat pomocí Azure CLI. Tento přístup není zaručený, že bude úspěšný, protože nekontroluje stav zajištění clusteru. Po změně nastavení diagnostiky zkontrolujte, že cluster odráží změny nastavení.

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

Dotazy a příklady záznamů prostředků AKS

Požadavky na obor dotazu: Když v nabídce clusteru AKS vyberete Protokoly , otevře se Log Analytics s oborem dotazu nastaveným na aktuální cluster. Dotazy protokolu zahrnují data pouze z daného prostředku. Pokud chcete spouštět dotazy, které obsahují data z jiných clusterů nebo služeb Azure, vyberte v nabídce Azure Monitorprotokoly.

Pokud nastavení diagnostiky vašeho clusteru používají režim Azure Diagnostics, protokoly prostředků pro AKS se ukládají do tabulky AzureDiagnostics. Identifikujte protokoly prostřednictvím sloupce Kategorie . Popis jednotlivých kategorií najdete v referenčních záznamech zdrojů AKS.

Popis Mode Dotaz protokolu
Počet protokolů v každé kategorii Režim diagnostiky Azure AzureDiagnostics
| where ResourceType == "MANAGEDCLUSTERS"
| summarize count() by Category
Všechny protokoly serveru rozhraní API Režim diagnostiky Azure AzureDiagnostics
| where Category == "kube-apiserver"
Všechny protokoly kube-audit v časovém rozsahu Režim diagnostiky 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
Všechny protokoly auditu Režim specifický pro prostředky AKSAudit
Všechny protokoly auditu s výjimkou get a list událostí auditu Režim specifický pro prostředky AKSAuditAdmin
Všechny protokoly serveru rozhraní API Režim specifický pro prostředky AKSControlPlane
| where Category == "kube-apiserver"

Pokud chcete získat přístup k sadě předem připravených dotazů v pracovním prostoru služby Log Analytics, podívejte se na rozhraní dotazů Log Analytics a vyberte typ prostředku služby Kubernetes Services . Seznam běžných dotazů ke Container insights naleznete v části Dotazy k Container insights.

Zásady auditu AKS

AKS používá zásady auditu Kubernetes k řízení událostí, které se protokolují a jaká data obsahují. Zásada definuje pravidla, která určují úroveň auditu pro různé typy požadavků rozhraní API na základě uživatelů, prostředků, oborů názvů a příkazů. Používají se následující úrovně auditu:

  • Žádné: Události odpovídající tomuto pravidlu se nezaprotokolují.
  • Metadata: Metadata protokolu žádosti (požadující uživatel, časové razítko, prostředek, příkaz), ale ne tělo požadavku nebo odpovědi.
  • Požadavek: Metadata událostí protokolu a text požadavku, ale ne text odpovědi.
  • RequestResponse: Zaznamenávání metadat událostí, těla požadavků a odpovědí.

Následující tabulka shrnuje klíčová pravidla zásad auditu použitá v AKS:

Úroveň auditu Popis Příklady událostí
Nic Operace čtení s vysokým objemem a nízkým rizikem aksService uživatelské operace get/list, kube-proxy monitorování koncových bodů/služeb, kubelet get na uzlech/stavu uzlů, URL adresy pro kontrolu stavu (/healthz*, /version, /swagger*)
Metadata Systémové události, zdroje událostí (s výjimkou vytváření/aktualizací v default/kube-system), tajné kódy, ConfigMap, účty služeb, recenze tokenů Kontroly tokenů, přístup k tajným klíčům nebo konfiguračním mapě, velké identifikátory CRD, jako je installations.operator.tigera.io
Prosba Aktualizace stavu uzlů a podů z kubelets/uzlů, operace odstranění kolekce, aktualizace CRD pro snímky svazků, operace čtení (get/list/watch) u základních skupin rozhraní API, změny VPA Aktualizace stavu Kubeletu, odstranění namespace, aktualizace VPA kontrolního bodu
RequestResponse Aktualizace vlastní mapy konfigurace CoreDNS, operace rozhraní FLEET API, změny prostředků Karpenteru, všechny ostatní operace zápisu v základních skupinách rozhraní API Změny konfigurace CoreDNS, operace clusteru členů flotily, změny fondu uzlů Karpenter

Úplné zásady auditu použité v AKS jsou k dispozici ke kontrole v následující sbalitelné části.

Zobrazení kompletních zásad auditu 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"

Poznámka:

Zásady auditu spravuje AKS a není možné je přizpůsobit. Tato zásada je navržená tak, aby vyvažovala pozorovatelnost zabezpečení s ohledem na výkon a optimalizaci nákladů tím, že snižuje objem protokolů pro vysokofrekvenční operace s nízkým rizikem.

Protokoly přehledů kontejnerů roviny dat AKS

Předpoklady a požadavky na konfiguraci: Služba Container Insights vyžaduje pracovní prostor Log Analytics pro úložiště protokolů a podporuje spravovanou identitu a starší autentizační metody. U nových clusterů se doporučuje ověřování spravovaných identit. Shromažďování dat je možné přizpůsobit pomocí pravidel shromažďování dat služby Azure Monitor za účelem řízení nákladů a snížení objemu příjmu dat.

Přehledy kontejnerů shromažďují různé typy telemetrických dat z kontejnerů a clusterů AKS, které vám pomůžou monitorovat, řešit potíže a získat přehled o kontejnerizovaných aplikacích běžících v clusterech AKS. Seznam tabulek a jejich podrobný popis používaných službou Container Insights najdete v referenčních informacích k tabulce služby Azure Monitor. Všechny tabulky jsou k dispozici pro dotazy protokolu.

Pomocí nastavení optimalizace nákladů můžete přizpůsobit a řídit data metrik shromažďovaná prostřednictvím agenta Container Insights. Tato funkce podporuje nastavení shromažďování dat pro jednotlivé výběry tabulek, intervaly shromažďování dat a obory názvů pro vyloučení shromažďování dat prostřednictvím pravidel shromažďování dat služby Azure Monitor (DCR). Tato nastavení řídí objem příjmu dat a snižují náklady na monitorování přehledů kontejnerů. Shromážděné údaje o kontejnerech můžete přizpůsobit na webu Azure Portal pomocí následujících možností. Když vyberete jakékoli jiné možnosti než Všechny (výchozí), nebude prostředí Přehledy kontejnerů dostupné.

Seskupení Tabulky Poznámky
Vše (výchozí) Všechny standardní tabulky přehledů kontejnerů Vyžaduje se k povolení výchozích vizualizací Přehledů kontejnerů.
Performance Výkon, Analytické metriky N/A
Protokoly a události ContainerLog nebo ContainerLogV2, KubeEvents, KubePodInventory Doporučuje se, pokud jste povolili spravovanou službu pro metriky Prometheus.
Úlohy, nasazení a HPAs InsightsMetrics, KubePodInventory, KubeEvents, ContainerInventory, ContainerNodeInventory, KubeNodeInventory, KubeServices N/A
Trvalé svazky InsightsMetrics, KubePVInventory N/A

Seskupování protokolů a událostí zaznamenává protokoly z tabulek ContainerLog nebo ContainerLogV2, KubeEvents a KubePodInventory, ale ne z metrik. Doporučenou metodou pro shromažďování metrik je povolit spravovanou službu Prometheus ve vašem AKS clusteru a použít Azure spravovanou Grafanu pro vizualizaci dat. Další informace najdete v tématu Monitorování pracovního prostoru Azure.

Schéma ContainerLogV2

Požadavky na kompatibilitu a konfiguraci: Schéma ContainerLogV2 se doporučuje pro nová nasazení Container Insights s využitím ověřování spravovaných identit pomocí šablon Azure Resource Manageru (ARM), Bicep, Terraformu, Azure Policy nebo webu Azure Portal. Schéma je kompatibilní s úrovní protokolů Basic pro úsporu nákladů a nemá vliv na funkce analýzy nebo upozornění. Další informace o povolení ContainerLogV2 prostřednictvím DCR nebo konfigurační mapy clusteru naleznete v tématu Povolení schématu ContainerLogV2.

Container Insights ve službě Azure Monitor poskytuje doporučené schéma pro protokoly kontejneru ContainerLogV2. Formát obsahuje následující pole pro běžné dotazy pro zobrazení dat souvisejících s clustery Kubernetes s podporou AKS a Azure Arc:

  • Název kontejneru
  • Název podu
  • PodNamespace

Protokol aktivit Azure

Protokol aktivit obsahuje události na úrovni předplatného, které sledují operace každého prostředku Azure tak, jak jsou viditelné zvenčí; například vytvoření nového prostředku nebo spuštění virtuálního počítače.

Shromažďování: Události protokolu aktivit se automaticky generují a shromažďují v samostatném úložišti pro zobrazení na webu Azure Portal.

Směrování: Data protokolu aktivit můžete odesílat do protokolů služby Azure Monitor, abyste je mohli analyzovat společně s dalšími daty protokolů. K dispozici jsou také jiná umístění, jako je Azure Storage, Azure Event Hubs a někteří monitorovací partneři Microsoftu. Další informace o směrování protokolu aktivit najdete v tématu Přehled protokolu aktivit Azure.

Zobrazení protokolů kontejneru AKS, událostí a metrik podů v reálném čase

Požadavky a požadavky na nastavení: Funkce živých dat vyžaduje povolení přehledů kontejnerů ve vašem clusteru a použití přímého přístupu k rozhraní API Kubernetes. Pro privátní clustery vyžaduje přístup počítač ve stejné privátní síti jako cluster. Ověřování se řídí modelem RBAC Kubernetes a vyžaduje příslušná oprávnění clusteru.

Protokoly kontejnerů AKS, události a metriky podů můžete zobrazit pomocí funkce živých dat v přehledech kontejnerů a řešit problémy v reálném čase s přímým přístupem k kubectl logs -cudálostem , kubectl get událostem a kubectl top pods.

Poznámka:

AKS používá architektury protokolování na úrovni clusteru Kubernetes. Protokoly kontejneru se nacházejí v /var/log/containers uzlu. Pokud chcete získat přístup k uzlu, přečtěte si téma Připojení k uzlům clusteru AKS.

Informace o nastavení této funkce najdete v tématu Konfigurace živých dat v Přehledech kontejnerů. Tato funkce přistupuje přímo k rozhraní API Kubernetes. Další informace o modelu ověřování najdete v rozhraní Kubernetes API.

Zobrazení živých protokolů prostředků AKS

Požadavky na síť privátního clusteru: Pokud chcete získat přístup k protokolům z privátního clusteru, musíte použít počítač, který je ve stejné privátní síti jako cluster.

  1. Na webu Azure Portal přejděte do clusteru AKS.

  2. V části Prostředky Kubernetes vyberte Úlohy.

  3. Pro nasazení, pod, sadu replik, stavovou sadu, úlohu nebo Cron Job vyberte hodnotu a pak vyberte Živé protokoly.

  4. Vyberte protokol prostředků, který chcete zobrazit.

    Následující příklad ukazuje logy pro pod:

    Snímek obrazovky znázorňující nasazení živých protokolů

Zobrazení živých protokolů kontejneru pomocí nástroje Container Insights

Ověřování a streamování dat: Po úspěšném ověření, pokud lze data načíst, začnou streamovat na záložku Živé protokoly. Data protokolu se zobrazují v průběžném datovém proudu. Alternativní přístup k protokolům je k dispozici prostřednictvím zobrazení protokolů v Log Analytics pro historickou analýzu.

Data protokolu v reálném čase můžete zobrazit, když je modul kontejneru vygeneruje na kartě Cluster, Uzly, Kontrolery nebo Kontejnery .

  1. Na webu Azure Portal přejděte do clusteru AKS.

  2. V části Monitorování vyberte Přehledy.

  3. Na kartě Cluster, Uzly, Kontrolery nebo Kontejnery vyberte hodnotu.

  4. V podokně Přehled prostředku vyberte Živé protokoly.

    Následující obrázek ukazuje protokoly pro prostředek kontejneru:

    Snímek obrazovky znázorňující možnost Živé protokoly kontejneru pro zobrazení dat

Zobrazení živých událostí kontejneru pomocí přehledů kontejnerů

Streamování událostí a přístup: Datové proudy událostí v reálném čase generované kontejnerovým enginem. Mezi události patří vytváření, odstraňování podů, operace škálování a chybové stavy. Historická data událostí jsou přístupná prostřednictvím zobrazení událostí v Log Analytics.

Můžete zobrazit data událostí v reálném čase tak, jak je kontejnerový engine generuje na kartě Cluster, Uzly, Kontrolery nebo Kontejnery.

  1. Na webu Azure Portal přejděte do clusteru AKS.

  2. V části Monitorování vyberte Přehledy.

  3. Vyberte kartu Cluster, Uzly, Kontrolery nebo Kontejnery a pak vyberte objekt.

  4. V podokně Přehled prostředků vyberte Živé události.

    Po úspěšném ověření a pokud jsou data dostupná, začne streamovat na kartu Živé události. Následující obrázek znázorňuje události pro prostředek kontejneru:

    Snímek obrazovky znázorňující možnost živé události kontejneru pro zobrazení dat

Zobrazení živých metrik podů pomocí Container insights

Rozsah a dostupnost metrik: Živé metriky jsou k dispozici pro prostředky podů na kartách Uzly nebo Kontrolery . Mezi metriky patří využití procesoru, spotřeba paměti, vstupně-výstupní operace sítě a statistika systému souborů. Historické metriky jsou přístupné prostřednictvím zobrazení událostí v Log Analytics.

Metriky v reálném čase můžete zobrazit, jakmile je kontejnerový engine vygeneruje, na kartě Uzly nebo Kontrolery výběrem prostředku podsítě.

  1. Na webu Azure Portal přejděte do clusteru AKS.

  2. V části Monitorování vyberte Přehledy.

  3. Vyberte kartu Uzly nebo Kontrolery a pak vyberte objekt podu.

  4. V podokně Přehled prostředků vyberte Živé metriky.

    Po úspěšném ověření, pokud lze data načíst, začnou se streamovat na kartu Živé metriky. Následující obrázek ukazuje metriky pro prostředek podu.

    Snímek obrazovky znázorňující možnost živé metriky podu pro zobrazení dat

    Analýza dat monitorování

    Existuje mnoho nástrojů pro analýzu dat monitorování.

    Nástroje služby Azure Monitor

    Azure Monitor podporuje následující základní nástroje:

    Mezi nástroje, které umožňují složitější vizualizaci, patří:

    • Řídicí panely , které umožňují kombinovat různé druhy dat do jednoho podokna na webu Azure Portal.
    • Sešity, přizpůsobitelné sestavy, které můžete vytvořit na webu Azure Portal. Sešity můžou obsahovat text, metriky a dotazy na protokoly.
    • Grafana, otevřený nástroj platformy, který exceluje v provozních řídicích panelech Grafana umožňuje vytvářet řídicí panely, které obsahují data z více zdrojů, než je Azure Monitor.
    • Power BI, služba obchodní analýzy, která poskytuje interaktivní vizualizace napříč různými zdroji dat. Power BI můžete nakonfigurovat tak, aby automaticky naimportovali data protokolů ze služby Azure Monitor, abyste mohli tyto vizualizace využívat.

    Nástroje pro export ve službě Azure Monitor

    Data ze služby Azure Monitor můžete získat do jiných nástrojů pomocí následujících metod:

    Pokud chcete začít s rozhraním REST API pro Azure Monitor, přečtěte si průvodce rozhraním REST API pro monitorování Azure.

Monitorování clusterů AKS na webu Azure Portal

Karta Monitorování v podokně Přehled vašeho prostředku clusteru AKS nabízí rychlý způsob, jak začít zobrazovat data monitorování na webu Azure Portal. Tato karta obsahuje grafy s běžnými metrikami pro cluster oddělený fondem uzlů. Výběrem libovolného z těchto grafů můžete dále analyzovat data v Průzkumníku metrik.

Karta Monitorování obsahuje také odkazy na spravovanou službu Azure pro Prometheus a přehledy kontejnerů pro cluster. Tyto nástroje můžete povolit na kartě Monitorování . V horní části podokna se také může zobrazit banner, který doporučí další funkce ke zlepšení monitorování clusteru.

Návod

Pokud chcete získat přístup k funkcím monitorování pro všechny clustery AKS ve vašem předplatném, na domovské stránce webu Azure Portal vyberte Azure Monitor.

Dotazy Kusto

Data monitorování můžete analyzovat v protokolech služby Azure Monitor nebo v úložišti Log Analytics pomocí dotazovacího jazyka Kusto (KQL).

Důležité

Když na portálu vyberete protokoly z nabídky služby, otevře se Log Analytics s oborem dotazu nastaveným na aktuální službu. Tento obor znamená, že dotazy protokolu budou obsahovat pouze data z tohoto typu prostředku. Pokud chcete spustit dotaz, který obsahuje data z jiných služeb Azure, vyberte Protokoly v nabídce Azure Monitor. Podrobnosti najdete v tématu Rozsah dotazů protokolu a časový rozsah ve službě Azure Monitor Log Analytics .

Seznam běžných dotazů pro libovolnou službu najdete v rozhraní dotazů Log Analytics.

Výstrahy

Upozornění služby Azure Monitor vás aktivně upozorňují, když se v datech monitorování nacházejí konkrétní podmínky. Upozornění umožňují identifikovat a řešit problémy ve vašem systému, než si je zákazníci všimnou. Další informace najdete v tématu Upozornění služby Azure Monitor.

Existuje mnoho zdrojů běžných upozornění pro prostředky Azure. Příklady běžných upozornění pro prostředky Azure najdete v tématu Ukázkové dotazy na protokol upozornění. Web AMBA (Baseline Alerts) služby Azure Monitor poskytuje poloautomatickou metodu implementace důležitých upozornění, řídicích panelů a pokynů pro metriky platformy. Web se vztahuje na neustále se rozšiřující podmnožinu služeb Azure, včetně všech služeb, které jsou součástí cílové zóny Azure (ALZ).

Jednotné schéma upozornění standardizuje způsob přijímání oznámení o výstrahách služby Azure Monitor. Další informace najdete v tématu Běžné schéma upozornění.

Typy výstrah

Na datové platformě Azure Monitor můžete upozornit na libovolnou metriku nebo zdroj dat protokolu. Existuje mnoho různých typů upozornění v závislosti na službách, které monitorujete, a na datech monitorování, která shromažďujete. Různé typy upozornění mají různé výhody a nevýhody. Další informace naleznete v tématu Volba správného typu upozornění monitorování.

Následující seznam popisuje typy upozornění služby Azure Monitor, které můžete vytvořit:

  • Upozornění na metriky vyhodnocují metriky prostředků v pravidelných intervalech. Metriky můžou být metriky platformy, vlastní metriky, protokoly ze služby Azure Monitor převedené na metriky nebo metriky Application Insights. Upozornění na metriky můžou také použít více podmínek a dynamických prahových hodnot.
  • Upozornění na protokoly umožňují uživatelům použít dotaz Log Analytics k vyhodnocení logů prostředků podle předem stanovené frekvence.
  • Upozornění protokolu aktivit se aktivují, když dojde k nové události protokolu aktivit, která odpovídá definovaným podmínkám. Upozornění Resource Health a Service Health jsou typem upozornění protokolu aktivit, která hlásí stav vašich služeb a zdrojů.

Některé služby Azure také podporují upozornění inteligentního zjišťování, výstrahy Prometheus nebo doporučená pravidla upozornění.

U některých služeb můžete monitorovat škálování použitím stejného pravidla upozornění na metriku u více prostředků stejného typu, které existují ve stejné oblasti Azure. Jednotlivá oznámení se odesílají pro každý monitorovaný prostředek. Pro podporované služby a cloudy Azure viz Monitorování více prostředků pomocí jednoho pravidla upozornění.

U některých služeb Azure můžete povolit doporučená předdefinovaná pravidla upozornění.

Systém zkompiluje seznam doporučených pravidel upozornění na základě:

  • Znalosti poskytovatele prostředků o důležitých signálech a prahových hodnotách pro monitorování prostředku
  • Data, která ukazuje, na co zákazníci u tohoto zdroje obvykle upozorňují.

Poznámka:

Doporučená pravidla upozornění jsou k dispozici pro:

  • Virtuální počítače
  • Prostředky Azure Kubernetes Service (AKS)
  • Pracovní prostory služby Log Analytics

Konfigurace upozornění na základě metrik Prometheus

Požadavky na stažení a konfiguraci: Pravidla upozornění jsou k dispozici jako šablony ARM ke stažení nebo soubory Bicep. Před konfigurací upozornění se ujistěte, že je spravovaná služba pro Prometheus ve vašem clusteru povolená a pracovní prostor služby Azure Monitor je správně propojený s vaším clusterem AKS.

Když pro váš cluster povolíte shromažďování metrik spravované služby pro metriky Prometheus , můžete si stáhnout kolekci doporučených spravovaných služeb pro pravidla upozornění Prometheus.

Stahování zahrnuje následující pravidla:

Úroveň Výstrahy
Úroveň clusteru KubeCPUQuotaOvercommit
KubeMemoryQuotaOvercommit
KubeContainerOOMKilledCount
KubeClientErrors
KubePersistentVolumeFillingUp
KubePersistentVolumeInodesFillingUp
KubePersistentVolumeErrors
KubeContainerWaiting
KubeDaemonSetNotScheduled
KubeDaemonSetMisScheduled
KubeQuotaAlmostFull
Úroveň uzlu KubeNodeUnreachable
KubeNodeReadinessFlapping
Úroveň podu KubePVUsageHigh
KubeDeploymentReplicasMismatch
KubeStatefulSetReplicasMismatch
KubeHpaReplicasMismatch
KubeHpaMaxedOut
KubePodCrashLooping
KubeJobStale
KubePodContainerRestart
KubePodReadyStateLow
KubePodFailedState
KubePodNotReadyByController
KubeStatefulSetGenerationMismatch
KubeJobFailed
KubeContainerAverageCPUHigh
KubeContainerAverageMemoryHigh
KubeletPodStartUpLatencyHigh

Další informace najdete v tématu Vytváření upozornění protokolu z přehledů kontejnerů a Vytváření dotazování protokolů z přehledů kontejnerů.

Upozornění protokolu můžou měřit dva typy informací, které vám pomůžou monitorovat různé scénáře:

  • Počet výsledků: Spočítá počet řádků vrácených dotazem. Tyto informace slouží k práci s událostmi, jako jsou protokoly událostí Systému Windows, události syslogu a výjimky aplikací.
  • Výpočet hodnoty: Vytvoří výpočet založený na číselném sloupci. Tyto informace použijte k zahrnutí různorodých zdrojů. Příkladem je procento procesoru.

Většina dotazů protokolu porovnává DateTime hodnotu se současným časem pomocí operátoru now, který zahrnuje období jedné hodiny nazpět. Informace o vytváření upozornění založených na protokolech najdete v tématu Vytváření upozornění protokolu z přehledů kontejnerů.

Pravidla upozornění AKS

Následující tabulka uvádí několik navrhovaných pravidel upozornění pro AKS. Tyto výstrahy jsou pouze příklady. Můžete nastavit upozornění na libovolnou metriku, položku protokolu nebo položku protokolu aktivit uvedenou v referenčních informacích o monitorování AKS.

Podmínka Popis
Procento> využití procesoru95 Upozornění, když průměrné využití procesoru napříč všemi uzly překročí prahovou hodnotu.
Procento pracovní sady paměti>100 Výstrahy, když průměrná pracovní sada napříč všemi uzly překročí prahovou hodnotu.

Doporučení poradce

U některých služeb, pokud během operací prostředků dojde k kritickým nebo bezprostředním změnám, zobrazí se na stránce Přehled služby na portálu výstraha. Další informace a doporučené opravy výstrahy najdete v doporučeních Advisoruv části Monitorování v nabídce vlevo. Během normálních operací se nezobrazují žádná doporučení poradce.

Další informace o Azure Advisoru najdete v přehledu Azure Advisoru.

Poznámka:

Pokud vytváříte nebo spouštíte aplikaci, která běží ve vaší službě, může Azure Monitor application Insights nabízet více typů upozornění.

Monitorování metrik sítě uzlů AKS

Požadavky na verzi a povolení: V Kubernetes verze 1.29 a novějších jsou metriky sítě uzlů ve výchozím nastavení povolené pro všechny clustery, které mají povolenou službu Azure Monitor. Pro starší verze Kubernetes musíte ručně povolit monitorování sítě prostřednictvím konfigurace clusteru. Tato funkce vyžaduje, aby byly ve vašem clusteru nakonfigurovány Azure Monitor nebo Container insights.

Metriky sítě uzlů jsou zásadní pro udržování clusteru Kubernetes v pořádku a výkonu. Shromažďováním a analýzou dat o síťovém provozu můžete získat cenné přehledy o provozu clusteru a identifikovat potenciální problémy předtím, než dojde k výpadkům nebo ztrátě výkonu.

Následující metriky sítě uzlů jsou ve výchozím nastavení povolené a agregují se na jeden uzel. Všechny metriky zahrnují popisky pro clustery a instance (název uzlu). Tyto metriky můžete snadno zobrazit pomocí řídicího panelu Managed Grafana v rámci Azure Managed Prometheus>Kubernetes>Networking>Clusters.

Metriky sítě uzlů AKS podle typu roviny dat

Všechny metriky zahrnují tyto popisky:

  • cluster
  • instance (název uzlu)

Podpora a omezení operačního systému: Pro scénáře roviny dat Cilium poskytuje funkce Pozorovatelnost kontejnerové sítě metriky pouze pro fondy uzlů Linuxu. V současné době windows nepodporuje metriky pozorovatelnosti kontejnerové sítě. Ujistěte se, že váš cluster má uzlové pooly pro Linux pro plnou dostupnost Cilium metrik.

Pro scénáře roviny dat Cilium poskytuje funkce Pozorovatelnost kontejnerové sítě metriky pouze pro Linux. V současné době windows nepodporuje metriky pozorovatelnosti kontejnerové sítě.

Cilium zveřejňuje několik metrik, které používá pozorovatelnost kontejnerové sítě:

Název metriky Popis Nadbytečné popisky Operační systém Linux Windows
cilium_forward_count_total Celkový počet přesměrovaných paketů direction Podporovaný ✅ Nepodporovaný ❌
cilium_forward_bytes_total Celkový počet přeposlaných bajtů direction Podporovaný ✅ Nepodporovaný ❌
cilium_drop_count_total Celkový počet zahozených paketů direction, reason Podporovaný ✅ Nepodporovaný ❌
cilium_drop_bytes_total Celkový počet vyřazených bajtů direction, reason Podporovaný ✅ Nepodporovaný ❌

Zakázání shromažďování síťových metrik uzlů AKS

Shromažďování síťových metrik můžete zakázat na konkrétních uzlech přidáním popisku networking.azure.com/node-network-metrics=disabled do těchto uzlů.

Poznámka:

Retina má schopnost tolerance operator: "Exists"effect: NoSchedule, která jí umožňuje obcházet NoSchedule znečištění. Popisky se proto používají místo taintů k řízení plánování.

Pokud je cluster autoprovisioning/autoscaling uzlů, příznak musíte ručně povolit na každém uzlu.

Důležité

Tato funkce se nedá použít, pokud je ve vašem clusteru povolená služba ACNS (Advanced Container Networking Services).

Zakázání shromažďování metrik na uzlu:

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

Podrobné metriky na úrovni podů a DNS najdete v tématu Advanced Container Networking Services.

Související obsah

  • Last updated on