Inzicht in bewakingskosten voor Container Insights

Dit artikel bevat prijsrichtlijnen voor Container Insights om inzicht te krijgen in het volgende:

• Meet de kosten nadat Container Insights is ingeschakeld voor een of meer containers.
• Beheer het verzamelen van gegevens en maak kostenreducties.

Tip

Zie Kostenoptimalisatie en Azure Monitor voor strategieën om uw Azure Monitor-kosten te verlagen.

Het prijsmodel van Azure Monitor is voornamelijk gebaseerd op de hoeveelheid gegevens die in gigabytes per dag in uw Log Analytics-werkruimte is opgenomen. De kosten van een Log Analytics-werkruimte zijn niet alleen gebaseerd op het aantal verzamelde gegevens, het is ook afhankelijk van het geselecteerde plan en hoe lang u ervoor hebt gekozen om gegevens op te slaan die zijn gegenereerd op basis van uw clusters.

Notitie

Zie Azure Monitor-kosten schatten om uw kosten voor Container Insights te schatten voordat u deze inschakelt.

De volgende typen gegevens die worden verzameld uit een Kubernetes-cluster met Container Insights beïnvloeden de kosten en kunnen worden aangepast op basis van uw gebruik:

• Perf, Inventory, InsightsMetrics en KubeEvents kunnen worden beheerd via instellingen voor kostenoptimalisatie
• Stdout- en stderr-containerlogboeken van elke bewaakte container in elke Kubernetes-naamruimte in het cluster via de agent ConfigMap
• Containeromgevingsvariabelen van elke bewaakte container in het cluster
• Voltooide Kubernetes-taken/pods in het cluster waarvoor geen bewaking is vereist
• Actieve scraping van metrische prometheus-gegevens
• Verzameling resourcelogboeken van kubernetes-hoofdknooppuntlogboeken in uw AKS-cluster (Azure Kubernetes Service) om logboekgegevens te analyseren die zijn gegenereerd door hoofdonderdelen, zoals kube-apiserver en kube-controller-manager.

Gegevensopname beheren om de kosten te verlagen

Overweeg een scenario waarin de verschillende bedrijfseenheden van uw organisatie kubernetes-infrastructuur en een Log Analytics-werkruimte delen. Elke bedrijfseenheid wordt gescheiden door een Kubernetes-naamruimte. U kunt visualiseren hoeveel gegevens in elke werkruimte worden opgenomen met behulp van het runbook Gegevensgebruik . Het runbook is beschikbaar op het tabblad Rapporten .

Met deze werkmap kunt u de bron van uw gegevens visualiseren zonder dat u uw eigen bibliotheek met query's hoeft te bouwen op basis van wat we in onze documentatie delen. In deze werkmap kunt u grafieken weergeven waarin factureerbare gegevens worden weergegeven, zoals:

• Totaal factureerbare gegevens die per oplossing in GB zijn opgenomen.
• Factureerbare gegevens die zijn opgenomen door containerlogboeken (toepassingslogboeken).
• Factureerbare containerlogboeken van gegevens die zijn opgenomen door Kubernetes-naamruimte.
• Factureerbare containerlogboeken gegevens opgenomen gescheiden door clusternaam.
• Factureerbare containerlogboekgegevens die zijn opgenomen per logboekbronvermelding.
• Factureerbare diagnostische gegevens die worden opgenomen door logboeken van diagnostische hoofdknooppunten.

Raadpleeg Toegangsbeheer voor meer informatie over het beheren van rechten en machtigingen voor de werkmap.

De hoofdoorzaak van de gegevensopname bepalen

Container Insights-gegevens bestaan voornamelijk uit metrische gegevens (Prestatiemeteritems, Inventaris, InsightsMetrics en aangepaste metrische gegevens) en logboeken (ContainerLog). Op basis van het gebruik en de grootte van uw cluster hebt u mogelijk verschillende vereisten en bewakingsbehoeften.

Als u naar de sectie Per tabel van de werkmap Gegevensgebruik navigeert, ziet u de uitsplitsing van tabelgrootten voor Container Insights.

Als het merendeel van uw gegevens afkomstig is van een van deze volgende tabellen:

• Perf
• InsightsMetrics
• ContainerInventory
• ContainerNodeInventory
• KubeNodeInventory
• KubePodInventory
• KubePVInventory
• KubeServices
• KubeEvents

U kunt uw opname aanpassen met behulp van de instellingen voor kostenoptimalisatie en/of migreren naar de invoegtoepassing voor metrische prometheus-gegevens

Anders behoort het merendeel van uw gegevens tot de ContainerLog-tabel. en u kunt de onderstaande stappen volgen om uw ContainerLog-kosten te verlagen.

Uw ContainerLog-kosten verlagen

Nadat u de analyse hebt voltooid om te bepalen welke bronnen de gegevens genereren die uw vereisten overschrijden, kunt u het verzamelen van gegevens opnieuw configureren. Zie Instellingen voor het verzamelen van agentgegevens configureren voor meer informatie over het configureren van verzameling van stdout-, stderr- en omgevingsvariabelen.

In de volgende voorbeelden ziet u welke wijzigingen u op uw cluster kunt toepassen door het ConfigMap-bestand te wijzigen om de kosten te beheren.

1. Schakel stdout-logboeken uit voor alle naamruimten in het cluster door de volgende code in het ConfigMap-bestand te wijzigen voor de Azure Container Insights-service die de metrische gegevens ophaalt:

   [log_collection_settings]       
      [log_collection_settings.stdout]          
         enabled = false
   

2. Het verzamelen van stderr-logboeken uitschakelen vanuit uw ontwikkelnaamruimte. Een voorbeeld is dev-test. Ga door met het verzamelen van stderr-logboeken van andere naamruimten, zoals prod en default, door de volgende code in het ConfigMap-bestand te wijzigen:

   Notitie

   De verzameling kube-system-logboeken is standaard uitgeschakeld. De standaardinstelling blijft behouden. Het toevoegen van de dev-test naamruimte aan de lijst met uitsluitingsnaamruimten wordt toegepast op het verzamelen van stderr-logboeken.

   [log_collection_settings.stderr]          
      enabled = true          
         exclude_namespaces = ["kube-system", "dev-test"]
   

3. Schakel het verzamelen van omgevingsvariabelen in het cluster uit door de volgende code in het ConfigMap-bestand te wijzigen. Deze wijziging is van toepassing op alle containers in elke Kubernetes-naamruimte.

   [log_collection_settings.env_var]
       enabled = false
   

4. Als u taken wilt opschonen die zijn voltooid, geeft u het opschoonbeleid op in de yaml van uw taakdefinitie. Hieronder volgt een voorbeeldtaakdefinitie met opschoningsbeleid. Raadpleeg de Kubernetes-documentatie voor meer informatie.

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: pi-with-ttl
   spec:
     ttlSecondsAfterFinished: 100
   

Nadat u een of meer van deze wijzigingen hebt toegepast op uw configuratie Kaarten past u deze toe op uw cluster met de opdrachtkubectl apply -f <config3. map_yaml_file.yaml>. Voer bijvoorbeeld de opdracht kubectl apply -f container-azm-ms-agentconfig.yaml uit om het bestand te openen in de standaardeditor om het te wijzigen en sla het vervolgens op.

Basic-logboeken configureren

U kunt besparen op kosten voor gegevensopname in ContainerLog in uw Log Analytics-werkruimte die u voornamelijk gebruikt voor foutopsporing, probleemoplossing en controle als basislogboeken. Zie Basislogboeken configureren in Azure Monitor voor meer informatie, waaronder de beperkingen van basislogboeken. ContainerLogV2 is de geconfigureerde versie van basislogboeken die Container Insights gebruikt. ContainerLogV2 bevat uitgebreide logboekrecords op basis van tekst.

U moet zich in het ContainerLogV2-schema bevinden om basislogboeken te configureren. Zie Het ContainerLogV2-schema inschakelen (preview) voor meer informatie.

Scraping van metrische prometheus-gegevens

Notitie

In deze sectie wordt de verzameling metrische prometheus-gegevens in uw Log Analytics-werkruimte beschreven. Deze informatie is niet van toepassing als u beheerde Prometheus gebruikt om uw metrische Prometheus-gegevens te scrapen.

Als u metrische prometheus-gegevens in uw Log Analytics-werkruimte verzamelt, moet u ervoor zorgen dat u het aantal metrische gegevens dat u verzamelt van uw cluster beperkt:

• Zorg ervoor dat de scrapingfrequentie optimaal is ingesteld. De standaardwaarde is 60 seconden. U kunt de frequentie verhogen tot 15 seconden, maar u moet ervoor zorgen dat de metrische gegevens die u scrapt, met die frequentie worden gepubliceerd. Anders worden veel dubbele metrische gegevens verwijderd en verzonden naar uw Log Analytics-werkruimte met intervallen die worden toegevoegd aan gegevensopname en retentiekosten, maar hebben ze minder waarde.
• Container insights biedt ondersteuning voor uitsluitings- en opnamelijsten op metrische naam. Als u bijvoorbeeld kubedns-metrische gegevens in uw cluster scrapt, worden er mogelijk honderden standaard gesroot. Maar u bent waarschijnlijk alleen geïnteresseerd in een subset van de metrische gegevens. Controleer of u een lijst met metrische gegevens hebt opgegeven om te scrapen of anderen uit te sluiten, met uitzondering van een paar om gegevensopnamevolume op te slaan. Het is eenvoudig om scraping in te schakelen en niet veel van deze metrische gegevens te gebruiken, waardoor alleen kosten worden toegevoegd aan uw Log Analytics-factuur.
• Wanneer u podaantekeningen doorloopt, moet u filteren op naamruimte, zodat u scraping van metrische podgegevens uitsluit van naamruimten die u niet gebruikt. Een voorbeeld is de dev-test naamruimte.

Gegevens die zijn verzameld uit Kubernetes-clusters

Metrische gegevens

Container insights bevat een vooraf gedefinieerde set metrische gegevens en inventarisitems die worden geschreven als logboekgegevens in uw Log Analytics-werkruimte. Alle metrische gegevens in de volgende tabel worden elke minuut verzameld.

Type	Metrische gegevens voor
Metrische gegevens van knooppunten	cpuUsageNanoCores cpuCapacityNanoCores cpuAllocatableNanoCores memoryRssBytes memoryWorkingSetBytes memoryCapacityBytes memoryAllocatableBytes restartTimeEpoch used (schijf) free (schijf) used_percent (schijf) io_time (diskio) writes (diskio) reads (diskio) write_bytes (diskio) write_time (diskio) iops_in_progress (diskio) read_bytes (diskio) read_time (diskio) err_in (net) err_out (net) bytes_recv (net) bytes_sent (net) Kubelet_docker_operations (kubelet)
Metrische containergegevens	cpuUsageNanoCores cpuRequestNanoCores cpuLimitNanoCores memoryRssBytes memoryWorkingSetBytes memoryRequestBytes memoryLimitBytes restartTimeEpoch

Clusterinventaris

De volgende lijst bevat de clusterinventarisgegevens die standaard worden verzameld:

• KubePodInventory – 1 per pod per minuut
• KubeNodeInventory – 1 per knooppunt per minuut
• KubeServices – 1 per service per minuut
• ContainerInventory – 1 per container per minuut

Volgende stappen

Zie Gebruik analyseren in een Log Analytics-werkruimte om te begrijpen wat de kosten waarschijnlijk zijn op basis van recente gebruikspatronen van gegevens die zijn verzameld met Container Insights.