Azure Kubernetes Service (AKS) bewaken

AKS-bewaking vereist meerdere niveaus van waarneembaarheid voor metrische platformgegevens, Prometheus-metrische gegevens, activiteitenlogboeken, resourcelogboeken en containerinzichten. AKS biedt ingebouwde bewakingsmogelijkheden en integreert met Azure Monitor, Container Insights, Beheerde service voor Prometheus en Azure Managed Grafana voor uitgebreide clusterstatus- en prestatiebewaking.

Inzichten

Sommige services in Azure hebben een ingebouwd bewakingsdashboard in Azure Portal dat een beginpunt biedt voor het bewaken van uw service. Deze dashboards worden inzichten genoemd en u kunt ze vinden in de Insights Hub van Azure Monitor in Azure Portal.

AKS-bewakingsgegevens: metrische gegevens, logboeken, integraties

AKS genereert dezelfde soorten bewakingsgegevens als andere Azure-resources, zoals beschreven in Monitor-gegevens van Azure-resources. Zie de referentie voor AKS-bewakingsgegevens voor gedetailleerde informatie over de metrische gegevens en logboeken die zijn gemaakt door AKS.

Andere Azure-services en -functies verzamelen andere gegevens en maken andere analyseopties mogelijk, zoals wordt weergegeven in het volgende diagram en de volgende tabel.

Resourcetypen

Azure maakt gebruik van het concept van resourcetypen en id's om alles in een abonnement te identificeren. Resourcetypen maken ook deel uit van de resource-id's voor elke resource die wordt uitgevoerd in Azure. Eén resourcetype voor een virtuele machine is Microsoft.Compute/virtualMachinesbijvoorbeeld . Zie Resourceproviders voor een lijst met services en de bijbehorende resourcetypen.

Azure Monitor organiseert op dezelfde manier kernbewakingsgegevens in metrische gegevens en logboeken op basis van resourcetypen, ook wel naamruimten genoemd. Er zijn verschillende metrische gegevens en logboeken beschikbaar voor verschillende resourcetypen. Uw service is mogelijk gekoppeld aan meer dan één resourcetype.

Zie de referentie voor AKS-bewakingsgegevens voor meer informatie over resourcetypen in AKS.

Gegevensopslag

Voor Azure Monitor:

• Metrische gegevens worden opgeslagen in de metrische gegevensdatabase van Azure Monitor.
• Logboekgegevens worden opgeslagen in het logboekarchief van Azure Monitor. Log Analytics is een hulpprogramma in de Azure-portal waarmee u queries op dit archief kunt uitvoeren.
• Het Azure-activiteitenlogboek is een afzonderlijk archief met een eigen interface in Azure Portal.

U kunt eventueel metrische gegevens en activiteitenlogboekgegevens routeren naar het logboekarchief van Azure Monitor. Vervolgens kunt u Log Analytics gebruiken om een query uit te voeren op de gegevens en deze te correleren met andere logboekgegevens.

Veel services kunnen diagnostische instellingen gebruiken om metrische gegevens en logboekgegevens te verzenden naar andere opslaglocaties buiten Azure Monitor. Voorbeelden hiervan zijn Azure Storage, gehoste partnersystemen en niet-Azure-partnersystemen, met behulp van Event Hubs.

Zie het Azure Monitor-gegevensplatform voor gedetailleerde informatie over hoe Azure Monitor gegevens opslaat.

Metrische gegevens van het Azure Monitor-platform

Azure Monitor biedt metrische platformgegevens voor de meeste services. Deze metrische gegevens zijn:

• Afzonderlijk gedefinieerd voor elke naamruimte.
• Opgeslagen in de metrische gegevensdatabase van Azure Monitor.
• Lichtgewicht en in staat om bijna real-time waarschuwingen te realiseren.
• Wordt gebruikt om de prestaties van een resource in de loop van de tijd bij te houden.

Verzameling: Azure Monitor verzamelt automatisch metrische platformgegevens. Er is geen configuratie vereist.

Routering: U kunt sommige metrische platformgegevens ook routeren naar Azure Monitor-logboeken/Log Analytics, zodat u er query's op kunt uitvoeren met andere logboekgegevens. Controleer de DS-exportinstelling voor elke metriek om te zien of u een diagnostische instelling kunt gebruiken om de metrische gegevens te routeren naar Azure Monitor-logboeken/Log Analytics.

• Voor meer informatie, zie de diagnostische instelling voor metrics.
• Zie Diagnostische instellingen maken in Azure Monitor om diagnostische instellingen voor een service te configureren.

Zie Ondersteunde metrische gegevens in Azure Monitor voor een lijst met alle metrische gegevens die kunnen worden verzameld voor alle resources in Azure Monitor.

Zie de referentie voor AKS-bewakingsgegevens voor een lijst met metrische gegevens die u voor AKS kunt verzamelen.

Metrische gegevens spelen een belangrijke rol bij het bewaken van clusters, het identificeren van problemen en het optimaliseren van prestaties in AKS-clusters. Metrische platformgegevens worden vastgelegd met behulp van de out-of-the-box metrics-server die is geïnstalleerd in de kube-system naamruimte, waarmee periodiek metrische gegevens worden verwijderd uit alle AKS-knooppunten die door kubelet worden geleverd. U moet ook beheerde service inschakelen voor Prometheus-metrieken om de metrieken van de containers en Kubernetes-objecten te verzamelen, inclusief de implementatiestatus van objecten.

U kunt de lijst met standaard beheerde service voor metrische gegevens van Prometheus bekijken.

Zie Met een beheerde service Prometheus-metrieken verzamelen vanuit een AKS-cluster voor meer informatie.

Metrische gegevens op basis van niet-Azure Monitor

Deze service biedt andere metrische gegevens die niet zijn opgenomen in de metrische Gegevensdatabase van Azure Monitor.

U kunt de volgende Azure-services en Azure Monitor-functies gebruiken om uw AKS-clusters te bewaken. U schakelt deze functies in wanneer u een AKS-cluster maakt.

Gebruik in Azure Portal het tabblad Integraties of gebruik de Azure CLI, Terraform of Azure Policy. In sommige gevallen kunt u uw cluster toevoegen aan een bewakingsdienst of optie na het maken van het cluster. Voor elke service of functie kunnen kosten in rekening worden gebracht, dus zie de prijsinformatie voor elk onderdeel voordat u deze inschakelt.

Bewaking van metrische gegevens van AKS-besturingsvlak (preview)

Vereisten en bereik: deze preview-functie is beschikbaar voor AKS-clusters met Kubernetes 1.27 of hoger en vereist dat de beheerde service voor Prometheus is ingeschakeld op uw cluster. De functie ondersteunt momenteel Linux- en Windows-knooppuntgroepen, maar is niet compatibel met VMAS (Virtual Machine Availability Sets).

AKS maakt ook metrische gegevens beschikbaar van essentiële besturingsvlakonderdelen, zoals de API-server, enzovoort, en de planner via de beheerde service voor Prometheus in Azure Monitor. Deze functie is momenteel beschikbaar als preview-versie. Voor meer informatie, zie Metrische gegevens van het AKS-besturingsvlak bewaken. Een subset van metrische gegevens van het controlevlak voor de API-server en etcd is gratis beschikbaar via de metrische gegevens van het Azure Monitor-platform. Deze metrische gegevens worden standaard verzameld. U kunt de metrische gegevens gebruiken om waarschuwingen te maken.

Azure Monitor-resourcelogboeken

Resourcelogboeken bieden inzicht in bewerkingen die zijn uitgevoerd door een Azure-resource. Logboeken worden automatisch gegenereerd, maar u moet ze routeren naar Azure Monitor-logboeken om ze op te slaan of er query's op uit te voeren. Logboeken zijn ingedeeld in categorieën. Een bepaalde naamruimte kan meerdere categorieën voor resourcelogboeken hebben.

Verzameling: Resourcelogboeken worden pas verzameld en opgeslagen als u een diagnostische instelling maakt en de logboeken doorsturen naar een of meer locaties. Wanneer u een diagnostische instelling maakt, geeft u op welke categorieën logboeken moeten worden verzameld. Er zijn meerdere manieren om diagnostische instellingen te maken en te onderhouden, waaronder via de Azure-portal, programmatisch en via Azure Policy.

Routering: de voorgestelde standaardinstelling is het routeren van resourcelogboeken naar Azure Monitor-logboeken, zodat u er query's op kunt uitvoeren met andere logboekgegevens. Andere locaties, zoals Azure Storage, Azure Event Hubs en bepaalde Microsoft-bewakingspartners, zijn ook beschikbaar. Zie Azure-resourcelogboeken en resourcelogboekbestemmingen voor meer informatie.

Zie Diagnostische instellingen in Azure Monitor voor gedetailleerde informatie over het verzamelen, opslaan en routeren van resourcelogboeken.

Zie Ondersteunde resourcelogboeken in Azure Monitor voor een lijst met alle beschikbare resourcelogboekcategorieën in Azure Monitor.

Alle resourcelogboeken in Azure Monitor hebben dezelfde koptekstvelden, gevolgd door servicespecifieke velden. Het algemene schema wordt beschreven in het schema voor resourcelogboeken van Azure Monitor.

Zie de referentie voor AKS-bewakingsgegevens voor de beschikbare resourcelogboekcategorieën, de bijbehorende Log Analytics-tabellen en logboekschema's voor AKS.

Resourcelogboeken van het AKS-besturingsvlak

Vereisten: Vereist een Log Analytics-werkruimte in hetzelfde abonnement als uw AKS-cluster. Resourcelogboeken brengen kosten met zich mee voor opname en retentie in de doel-werkruimte. Voor kostenoptimalisatie gebruikt u de resourcespecifieke modus en configureert u de laag Basic-logboeken voor audittabellen.

Besturingsvlaklogboeken voor AKS-clusters worden geïmplementeerd als resourcelogboeken in Azure Monitor. Resourcelogboeken worden pas verzameld en opgeslagen als u een diagnostische instelling maakt om ze naar ten minste één locatie te routeren. Doorgaans verzendt u resourcelogboeken naar een Log Analytics-werkruimte, waar de meeste gegevens voor Container Insights worden opgeslagen.

Zie Diagnostische instellingen maken voor meer informatie over het maken van een diagnostische instelling met behulp van Azure Portal, de Azure CLI of Azure PowerShell. Wanneer u een diagnostische instelling maakt, geeft u op welke categorieën logboeken moeten worden verzameld. De categorieën voor AKS worden vermeld in de AKS-bewakingsgegevensreferentie.

AKS ondersteunt de diagnostische modus van Azure of de resourcespecifieke modus voor resourcelogboeken. De diagnostische modus van Azure verzendt alle gegevens naar de tabel AzureDiagnostics. De resourcespecifieke modus specificeert de tabellen in de Log Analytics-werkruimte waar de gegevens worden verzonden. Het verzendt ook gegevens naar AKSAudit, AKSAuditAdminen AKSControlPlane zoals wordt weergegeven in de tabel in resourcelogboeken.

We raden u aan om de resourcespecifieke modus voor AKS te gebruiken om de volgende redenen:

• Gegevens zijn eenvoudiger te doorzoeken omdat deze zich in afzonderlijke tabellen bevinden die zijn toegewezen aan AKS.
• Resourcespecifieke modus ondersteunt configuratie als basislogboeken voor aanzienlijke kostenbesparingen.

Zie De verzamelingsmodus selecteren voor meer informatie over het verschil tussen verzamelingsmodi, waaronder het wijzigen van een bestaande instelling.

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

Query's en voorbeelden van AKS-resourcelogboeken

Vereisten voor querybereik: Wanneer u Logboeken selecteert in een AKS-clustermenu, wordt Log Analytics geopend met het querybereik ingesteld op het huidige cluster. Logqueries bevatten alleen gegevens uit die bron. Als u query's wilt uitvoeren die gegevens uit andere clusters of Azure-services bevatten, selecteert u Logboeken in het menu Azure Monitor .

Als de diagnostische instellingen voor uw cluster gebruikmaken van de diagnostische modus van Azure, worden de resourcelogboeken voor AKS opgeslagen in de tabel AzureDiagnostics . Identificeer logboeken via de kolom Categorie . Zie AKS-referentieresourcelogboeken voor een beschrijving van elke categorie.

Als u toegang wilt krijgen tot een set vooraf gedefinieerde query's in de Log Analytics-werkruimte, raadpleegt u de interface voor Log Analytics-query's en selecteert u het resourcetype Kubernetes Services . Zie Container Insights-query's voor een lijst met algemene query's voor Container Insights.

AKS-controlebeleid

AKS maakt gebruik van een Kubernetes-controlebeleid om te bepalen welke gebeurtenissen worden geregistreerd en welke gegevens ze bevatten. Het beleid definieert regels die het controleniveau bepalen voor verschillende typen API-aanvragen op basis van gebruikers, resources, naamruimten en werkwoorden. De volgende controleniveaus worden gebruikt:

• Geen: gebeurtenissen die overeenkomen met deze regel worden niet geregistreerd.
• Metagegevens: metagegevens van logboekaanvragen (gebruiker, tijdstempel, resource, werkwoord) maar geen aanvraag- of antwoordtekst.
• Aanvraag: Metagegevens van gebeurtenis vastleggen en hoofdtekst van aanvraag, maar niet antwoordtekst.
• RequestResponse: logboekgegevens, aanvraag- en antwoordteksten.

De volgende tabel bevat een overzicht van de belangrijkste controlebeleidsregels die zijn toegepast in AKS:

Het volledige controlebeleid dat in AKS wordt gebruikt, is beschikbaar voor controle in de volgende samenvouwbare sectie.

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-datavlak container-inzichtenlogboeken

Vereisten en configuratievereisten: Voor Container Insights is een Log Analytics-werkruimte vereist voor logboekopslag en worden zowel beheerde identiteit als verouderde verificatiemethoden ondersteund. Voor nieuwe clusters wordt verificatie van beheerde identiteit aanbevolen. Gegevensverzameling kan worden aangepast met behulp van Azure Monitor Data Collection Rules (DCR's) om de kosten te beheren en het opnamevolume te verminderen.

Containerinzichten verzamelt verschillende typen telemetriegegevens van containers en AKS-clusters om u te helpen bij het bewaken, oplossen van problemen en het verkrijgen van inzicht in uw containertoepassingen die worden uitgevoerd in uw AKS-clusters. Zie de azure Monitor-tabelreferentie voor een lijst met tabellen en de bijbehorende gedetailleerde beschrijvingen die door Container Insights worden gebruikt. Alle tabellen zijn beschikbaar voor logboekquery's.

Gebruik instellingen voor kostenoptimalisatie om de metrische gegevens die worden verzameld via de Container Insights-agent aan te passen en te beheren. Deze functie ondersteunt de instellingen voor gegevensverzameling voor afzonderlijke tabelselectie, intervallen voor gegevensverzameling en naamruimten om de gegevensverzameling uit te sluiten via Azure Monitor-regels voor gegevensverzameling (DCR's). Deze instellingen bepalen het volume van opname en verlagen de bewakingskosten van Container Insights. U kunt containerinzichten die worden verzameld in Azure Portal aanpassen met behulp van de volgende opties. Als u andere opties dan Alle (standaard) selecteert, is de Container Insights-ervaring niet beschikbaar.

Met logboeken en gebeurtenissen worden de logboeken vastgelegd uit de tabellen ContainerLog of ContainerLogV2, KubeEvents en KubePodInventory , maar niet de metrische gegevens. Het aanbevolen pad voor het verzamelen van metrische gegevens is om de beheerde service voor Prometheus vanuit uw AKS-cluster in te schakelen en Azure Managed Grafana te gebruiken voor gegevensvisualisatie. Zie Azure Monitor werkruimte beheren voor meer informatie.

ContainerLogV2-schema

Compatibiliteits- en configuratievereisten: ContainerLogV2-schema wordt aanbevolen voor nieuwe Container Insights-implementaties met behulp van verificatie van beheerde identiteiten via ARM-sjablonen (Azure Resource Manager), Bicep, Terraform, Azure Policy of Azure Portal. Het schema is compatibel met de laag Basic-logboeken voor kostenbesparingen en heeft geen invloed op de functionaliteit van analyses of waarschuwingen. Zie Het ContainerLogV2-schema inschakelen voor meer informatie over het inschakelen van ContainerLogV2 via de DCR of configmap van het cluster.

Containerinzichten in Azure Monitor biedt een aanbevolen schema voor containerlogboeken, ContainerLogV2. De indeling bevat de volgende velden voor algemene query's om gegevens weer te geven die betrekking hebben op AKS- en Kubernetes-clusters met Azure Arc:

• ContainerName
• PodName
• PodNamespace

Azure-activiteitenlogboek

Het activiteitenlogboek bevat gebeurtenissen op abonnementsniveau waarmee bewerkingen voor elke Azure-resource worden bijgehouden, zoals van buiten die resource wordt gezien; Bijvoorbeeld het maken van een nieuwe resource of het starten van een virtuele machine.

Verzameling: gebeurtenissen in activiteitenlogboeken worden automatisch gegenereerd en verzameld in een afzonderlijk archief voor weergave in Azure Portal.

Routering: U kunt activiteitenlogboekgegevens verzenden naar Azure Monitor-logboeken, zodat u deze naast andere logboekgegevens kunt analyseren. Andere locaties, zoals Azure Storage, Azure Event Hubs en bepaalde Microsoft-bewakingspartners, zijn ook beschikbaar. Zie Overzicht van het Azure-activiteitenlogboek voor meer informatie over het routeren van het activiteitenlogboek.

AKS-containerlogboeken, gebeurtenissen en metrische gegevens over pods in realtime weergeven

Vereisten en configuratie-eisen: De functie voor livegegevens vereist dat Containerinzichten op uw cluster is ingeschakeld en directe toegang tot de Kubernetes-API wordt gebruikt. Voor privéclusters is voor toegang een computer in hetzelfde privénetwerk als het cluster vereist. Verificatie volgt het Kubernetes RBAC-model en vereist de juiste clustermachtigingen.

U kunt AKS-containerlogboeken, gebeurtenissen en metrische podgegevens weergeven met behulp van de functie voor livegegevens in Container Insights en problemen in realtime oplossen met directe toegang tot kubectl logs -c, kubectl get gebeurtenissen en kubectl top pods.

Zie Live-gegevens configureren in Container Insights voor meer informatie over het instellen van deze functie. De functie heeft rechtstreeks toegang tot de Kubernetes-API. Zie de Kubernetes-API voor meer informatie over het verificatiemodel.

Livelogboeken van AKS-resources weergeven

Netwerkvereisten voor privéclusters: als u logboeken wilt openen vanuit een privécluster, moet u een computer gebruiken die zich in hetzelfde privénetwerk bevindt als het cluster.

1. Ga in Azure Portal naar uw AKS-cluster.

2. Selecteer Workloads onder Kubernetes-resources.

3. Voor Deployment, Pod, ReplicaSet, StatefulSet, Job of CronJob selecteert u een waarde en selecteert u vervolgens Live Logs.

4. Selecteer een logboek van een hulpbron om weer te geven.

   In het volgende voorbeeld ziet u de logboeken voor een podresource:

   

Livelogboeken van containers weergeven met Behulp van Container Insights

Verificatie en gegevensstreaming: na een geslaagde verificatie, als gegevens kunnen worden opgehaald, wordt het gestreamd naar het tabblad Livelogboeken . Logboekgegevens worden weergegeven in een continue stroom. Alternatieve logboektoegang is beschikbaar via Weergavelogboeken in Log Analytics voor historische analyse.

U kunt realtime logboekgegevens bekijken terwijl de containerengine deze genereert op het tabblad Cluster, Knooppunten, Controllers of Containers .

1. Ga in Azure Portal naar uw AKS-cluster.

2. Selecteer Inzichten onder Monitoring.

3. Selecteer een waarde op het tabblad Cluster, Knooppunten, Controllers of Containers .

4. Selecteer Live Logs in het Overzicht-venster voor de resource.

   In de volgende afbeelding ziet u de logboeken voor een containerresource:

   

Livegebeurtenissen van containers weergeven met containerinzichten

Gebeurtenisstreaming en -toegang: realtime streaming van gebeurtenisgegevens terwijl de containerengine deze genereert. Gebeurtenissen omvatten het maken, verwijderen van pods, schaalbewerkingen en foutvoorwaarden. Historische gebeurtenisgegevens zijn toegankelijk via Gebeurtenissen weergeven in Log Analytics.

U kunt realtime gebeurtenisgegevens bekijken terwijl de containerengine deze genereert op het tabblad Cluster, Knooppunten, Controllers of Containers .

1. Ga in Azure Portal naar uw AKS-cluster.

2. Selecteer Inzichten onder Monitoring.

3. Selecteer het tabblad Cluster, Knooppunten, Controllers of Containers en selecteer vervolgens een object.

4. Selecteer Live Evenementen in het Overzicht-deelvenster van resources.

   Na een geslaagde authenticatie, als de gegevens kunnen worden opgehaald, worden ze gestreamd naar het tabblad Live Events. In de volgende afbeelding ziet u de gebeurtenissen bij een containerresource:

   

Live-metrische gegevens van pods weergeven met containerinzichten

Bereik en beschikbaarheid van metrische gegevens: Live metrics zijn beschikbaar voor pod-resources op de tabbladen Knooppunten of Controllers . Metrische gegevens omvatten CPU-gebruik, geheugenverbruik, netwerk-I/O- en bestandssysteemstatistieken. Historische metrics zijn toegankelijk via View Events in Log Analytics.

U kunt realtime metrische gegevens bekijken terwijl de containerengine deze genereert op het tabblad Knooppunten of Controllers door een podresource te selecteren.

1. Ga in Azure Portal naar uw AKS-cluster.

2. Selecteer Inzichten onder Monitoring.

3. Selecteer het tabblad Knooppunten of Controllers en selecteer vervolgens een podobject.

4. Selecteer Live Metrics in het deelvenster Overzicht van resources.

   Na een geslaagde verificatie, als gegevens kunnen worden opgehaald, wordt het gestreamd naar het tabblad Live Metrics . In de volgende afbeelding ziet u de metrische gegevens voor een podresource:

   

   Bewakingsgegevens analyseren

   Er zijn veel hulpprogramma's voor het analyseren van bewakingsgegevens.

   Azure Monitor-hulpprogramma's

   Azure Monitor ondersteunt de volgende basishulpprogramma's:

   • Metrics Explorer, een hulpprogramma in Azure Portal waarmee u metrische gegevens voor Azure-resources kunt weergeven en analyseren. Zie Metrische gegevens analyseren met Azure Monitor Metrics Explorer voor meer informatie.

   • Log Analytics, een hulpprogramma in Azure Portal waarmee u logboekgegevens kunt opvragen en analyseren met behulp van de Kusto-querytaal (KQL). Zie Aan de slag met logboekquery's in Azure Monitor voor meer informatie.

   • Het activiteitenlogboek, dat een gebruikersinterface in Azure Portal heeft voor het weergeven en uitvoeren van basiszoekopdrachten. Als u uitgebreidere analyses wilt uitvoeren, moet u de gegevens routeren naar Azure Monitor-logboeken en complexere query's uitvoeren in Log Analytics.

   Hulpprogramma's waarmee complexere visualisaties mogelijk zijn, zijn onder andere:

   • Dashboards waarmee u verschillende soorten gegevens kunt combineren in één deelvenster in Azure Portal.
   • Werkmappen, aanpasbare rapporten die u kunt maken in Azure Portal. Werkmappen kunnen tekst, metrische gegevens en logboekquery's bevatten.
   • Grafana, een open platformhulpprogramma dat excelleert in operationele dashboards. U kunt Grafana gebruiken om dashboards te maken die gegevens uit meerdere andere bronnen dan Azure Monitor bevatten.
   • Power BI, een business analytics-service die interactieve visualisaties biedt in verschillende gegevensbronnen. U kunt Power BI zo configureren dat logboekgegevens automatisch vanuit Azure Monitor worden geïmporteerd om te profiteren van deze visualisaties.

   Azure Monitor-exporthulpprogramma's

   U kunt gegevens uit Azure Monitor ophalen in andere hulpprogramma's met behulp van de volgende methoden:

   • Metrische gegevens: gebruik de REST API voor metrische gegevens om metrische gegevens te extraheren uit de metrische Azure Monitor-database. De API ondersteunt filterexpressies om de opgehaalde gegevens te verfijnen. Zie azure Monitor REST API-naslaginformatie voor meer informatie.

   • Logboeken: Gebruik de REST API of de bijbehorende clientbibliotheken.

   • Een andere optie is het exporteren van werkruimtegegevens.

   Als u aan de slag wilt gaan met de REST API voor Azure Monitor, raadpleegt u de stapsgewijze instructies voor Azure Monitoring REST API.

AKS-clusters bewaken in Azure Portal

Het tabblad Bewaking in het deelvenster Overzicht voor uw AKS-clusterresource biedt een snelle manier om bewakingsgegevens weer te geven in Azure Portal. Dit tabblad bevat grafieken met algemene metrische gegevens voor het cluster, gescheiden door knooppuntgroep. U kunt een van deze grafieken selecteren om de gegevens verder te analyseren in de Metrics Explorer.

Het tabblad Bewaking bevat ook koppelingen naar de beheerde Azure-service voor Prometheus en Container Insights voor het cluster. U kunt deze hulpprogramma's inschakelen op het tabblad Bewaking . Mogelijk ziet u boven aan het deelvenster ook een banner die andere functies aanbeveelt om de bewaking voor uw cluster te verbeteren.

Kusto-query's

U kunt bewakingsgegevens analyseren in de Azure Monitor-logboeken/Log Analytics-opslag met behulp van de Kusto-querytaal (KQL).

Zie de interface voor Log Analytics-query's voor een lijst met algemene query's voor elke service.

Waarschuwingen

Azure Monitor-waarschuwingen melden u proactief wanneer er specifieke voorwaarden worden gevonden in uw bewakingsgegevens. Met waarschuwingen kunt u problemen in uw systeem identificeren en oplossen voordat uw klanten ze opmerken. Zie Azure Monitor-waarschuwingen voor meer informatie.

Er zijn veel bronnen van algemene waarschuwingen voor Azure-resources. Zie Voorbeeldquery's voor logboekwaarschuwingen voor voorbeelden van veelvoorkomende waarschuwingen voor Azure-resources. De site Azure Monitor Baseline Alerts (AMBA) biedt een semi-geautomatiseerde methode voor het implementeren van belangrijke metrische platformwaarschuwingen, dashboards en richtlijnen. De site is van toepassing op een voortdurend uitbreidende subset van Azure-services, inclusief alle services die deel uitmaken van de Azure Landing Zone (ALZ).

Het algemene waarschuwingsschema standaardiseert het verbruik van Azure Monitor-waarschuwingsmeldingen. Zie Algemeen waarschuwingsschema voor meer informatie.

Typen waarschuwingen

U kunt een waarschuwing ontvangen voor elke metrische gegevensbron of logboekgegevensbron in het Azure Monitor-gegevensplatform. Er zijn veel verschillende typen waarschuwingen, afhankelijk van de services die u bewaakt en de bewakingsgegevens die u verzamelt. Verschillende typen waarschuwingen hebben verschillende voordelen en nadelen. Zie Het juiste waarschuwingstype voor bewaking kiezen voor meer informatie.

In de volgende lijst worden de typen Azure Monitor-waarschuwingen beschreven die u kunt maken:

• Metrische waarschuwingen evalueren op regelmatige basis de resource-metrics. Metrische gegevens kunnen platformmetrieke gegevens, aangepaste metrieke gegevens, logboeken van Azure Monitor die zijn omgezet in metrieke gegevens of metrieke gegevens van Application Insights zijn. Metrische waarschuwingen kunnen ook meerdere voorwaarden en dynamische drempelwaarden toepassen.
• Met logboekwaarschuwingen kunnen gebruikers een Log Analytics-query gebruiken om resourcelogboeken met een vooraf gedefinieerde frequentie te evalueren.
• Waarschuwingen voor activiteitenlogboeken worden geactiveerd wanneer een nieuwe gebeurtenis van het activiteitenlogboek plaatsvindt die overeenkomt met gedefinieerde voorwaarden. Resource Health-waarschuwingen en Service Health-waarschuwingen zijn logboekwaarschuwingen die rapporteren over de gezondheid van uw service en resources.

Sommige Azure-services ondersteunen ook waarschuwingen voor slimme detectie, Prometheus-waarschuwingen of aanbevolen waarschuwingsregels.

Voor sommige services kunt u op schaal bewaken door dezelfde waarschuwingsregel voor metrische gegevens toe te passen op meerdere resources van hetzelfde type dat in dezelfde Azure-regio aanwezig is. Afzonderlijke meldingen worden verzonden voor elke bewaakte resource. Zie Meerdere resources bewaken met één waarschuwingsregel voor ondersteunde Azure-services en -clouds.

Aanbevolen waarschuwingsregels

Voor sommige Azure-services kunt u aanbevolen out-of-the-box waarschuwingsregels inschakelen.

Het systeem compileert een lijst met aanbevolen waarschuwingsregels op basis van:

• De kennis van de resourceprovider van belangrijke signalen en drempelwaarden voor het bewaken van de resource.
• Gegevens die aangeeft waar klanten vaak op waarschuwen voor deze resource.

Waarschuwingen op basis van metrische gegevens van Prometheus configureren

Download- en configuratievereisten: waarschuwingsregels zijn beschikbaar als downloadbare ARM-sjablonen of Bicep-bestanden. Voordat u waarschuwingen configureert, moet u ervoor zorgen dat de beheerde service voor Prometheus is ingeschakeld op uw cluster en dat een Azure Monitor-werkruimte correct is gekoppeld aan uw AKS-cluster.

Wanneer u de verzameling van de beheerde service voor Prometheus-metrieken voor uw cluster inschakelt, kunt u een verzameling aanbevolen waarschuwingsregels voor de beheerde service van Prometheus downloaden.

De download bevat de volgende regels:

Zie Logboekwaarschuwingen maken van Container Insights en Query-logboeken van Container Insights voor meer informatie.

Logboekwaarschuwingen kunnen twee soorten informatie meten om u te helpen diverse scenario's te bewaken:

• Aantal resultaten: telt het aantal rijen dat door de query wordt geretourneerd. Gebruik deze informatie om te werken met gebeurtenissen zoals Windows-gebeurtenislogboeken, syslog-gebeurtenissen en toepassingsuitzondering.
• Berekening van een waarde: Maakt een berekening op basis van een numerieke kolom. Gebruik deze informatie om verschillende bronnen op te nemen. Een voorbeeld is cpu-percentage.

De meeste logboekquery's vergelijken een DateTime waarde met de huidige tijd en gaan een uur terug met behulp van de now operator. Zie Logboekwaarschuwingen maken vanuit Container Insights voor meer informatie over het maken van waarschuwingen op basis van logboeken.

AKS-waarschuwingsregels

De volgende tabel bevat enkele voorgestelde waarschuwingsregels voor AKS. Deze waarschuwingen zijn alleen voorbeelden. U kunt waarschuwingen instellen voor elke vermelding van metrische gegevens, logboekvermeldingen of activiteitenlogboeken die worden vermeld in de AKS-controlegegevensverwijzing.

Advisor-aanbevelingen

Voor sommige services, als er kritieke omstandigheden of aanstaande wijzigingen optreden tijdens resourcebewerkingen, wordt een waarschuwing weergegeven op de pagina Serviceoverzicht in de portal. Meer informatie en aanbevolen oplossingen voor de waarschuwing vindt u in Advisor-aanbevelingen onder Bewaking in het linkermenu. Tijdens normale bewerkingen worden er geen aanbevelingen van advisor weergegeven.

Zie het overzicht van Azure Advisor voor meer informatie over Azure Advisor.

Bewaking van metrische gegevens van AKS-knooppuntnetwerk

Versie- en activeringsvereisten: In Kubernetes versie 1.29 en hoger zijn metrische knooppuntnetwerkgegevens standaard ingeschakeld voor alle clusters waarvoor Azure Monitor is ingeschakeld. Voor eerdere Kubernetes-versies moet u netwerkbewaking handmatig inschakelen via clusterconfiguratie. Voor deze functie moet Azure Monitor of Container Insights in uw cluster worden geconfigureerd.

Metrische gegevens van het knooppuntnetwerk zijn van cruciaal belang voor het onderhouden van een goed presterend Kubernetes-cluster. Door gegevens over netwerkverkeer te verzamelen en te analyseren, kunt u waardevolle inzichten verkrijgen over de werking van uw cluster en potentiële problemen identificeren voordat ze leiden tot storingen of prestatieverlies.

De volgende metrische netwerkgegevens van knooppunten zijn standaard ingeschakeld en worden per knooppunt samengevoegd. Alle metrische gegevens bevatten het labelcluster en het exemplaar (knooppuntnaam). U kunt deze metrische gegevens eenvoudig weergeven met behulp van het beheerde Grafana-dashboard onder Azure Managed Prometheus>Kubernetes-netwerkclusters>>.

Metrische gegevens van het AKS-knooppuntnetwerk per gegevensvlaktype

Alle metrische gegevens bevatten deze labels:

• cluster
• instance (knooppuntnaam)

Het verzamelen van netwerkmetrische gegevens van AKS-knooppunten uitschakelen

U kunt het verzamelen van metrische netwerkgegevens op specifieke knooppunten uitschakelen door het label networking.azure.com/node-network-metrics=disabled toe te voegen aan die knooppunten.

Het verzamelen van metrische gegevens op een knooppunt uitschakelen:

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

Zie Advanced Container Networking Services voor gedetailleerde metrische gegevens op podniveau en DNS.

Gerelateerde inhoud

• Zie de referentie voor AKS-bewakingsgegevens voor een verwijzing naar de metrische gegevens, logboeken en andere belangrijke waarden die zijn gemaakt voor AKS.
• Zie Azure-resources bewaken met behulp van Azure Monitor voor algemene informatie over het bewaken van Azure-resources.
• Zie Kubernetes-clusters bewaken met behulp van Azure-services en cloudeigen hulpprogramma's voor gedetailleerde bewaking van de volledige Kubernetes-stack.
• Zie Managed Service voor Prometheus in Azure Monitor om metrische gegevens van Kubernetes-clusters te verzamelen.
• Zie Azure Monitor-functies voor Kubernetes-bewaking voor het verzamelen van logboeken in Kubernetes-clusters.
• Zie Azure Workbooks en Monitor your Azure services in Grafana voor gegevensvisualisatie.