Förstå övervakningskostnader för containerinsikter

Den här artikeln innehåller prisvägledning för containerinsikter som hjälper dig att förstå hur du:

• Mät kostnader när Container Insights har aktiverats för en eller flera containrar.
• Kontrollera insamlingen av data och gör kostnadsminskningar.

Dricks

Strategier för att minska dina Azure Monitor-kostnader finns i Kostnadsoptimering och Azure Monitor.

Prismodellen för Azure Monitor baseras främst på mängden data som matas in i gigabyte per dag till Din Log Analytics-arbetsyta. Kostnaden för en Log Analytics-arbetsyta baseras inte bara på mängden data som samlas in, den är också beroende av den valda planen och hur länge du valde att lagra data som genererats från dina kluster.

Kommentar

Se Beräkna Azure Monitor-kostnader för att beräkna dina kostnader för Container Insights innan du aktiverar det.

Följande typer av data som samlas in från ett Kubernetes-kluster med Container Insights påverkar kostnaden och kan anpassas baserat på din användning:

• Perf, Inventory, InsightsMetrics och KubeEvents kan styras via inställningar för kostnadsoptimering
• Stdout- och stderr-containerloggar från varje övervakad container i varje Kubernetes-namnområde i klustret via agenten ConfigMap
• Miljövariabler för containrar från varje övervakad container i klustret
• Slutförda Kubernetes-jobb/poddar i klustret som inte kräver övervakning
• Aktiv skrapning av Prometheus-mått
• Resursloggsamling av Kubernetes-huvudnodloggar i ditt AKS-kluster (Azure Kubernetes Service) för att analysera loggdata som genereras av huvudkomponenter, till exempel kube-apiserver och kube-controller-manager.

Styra inmatning för att minska kostnaderna

Tänk dig ett scenario där organisationens olika affärsenheter delar Kubernetes-infrastrukturen och en Log Analytics-arbetsyta. Varje affärsenhet avgränsas med ett Kubernetes-namnområde. Du kan visualisera hur mycket data som matas in på varje arbetsyta med hjälp av runbooken dataanvändning . Runbooken är tillgänglig på fliken Rapporter .

Den här arbetsboken hjälper dig att visualisera datakällan utan att behöva skapa ett eget bibliotek med frågor från det vi delar i vår dokumentation. I den här arbetsboken kan du visa diagram som visar fakturerbara data, till exempel:

• Totalt antal fakturerbara data som matas in i GB per lösning.
• Fakturerbara data som matas in av containerloggar (programloggar).
• Fakturerbara containerloggdata som matas in av Kubernetes-namnområdet.
• Fakturerbara containerloggar data som matas in åtskilda med klusternamn.
• Fakturerbara containerloggdata som matas in av loggkällans post.
• Fakturerbara diagnostikdata som matas in av diagnostikens huvudnodloggar.

Mer information om hur du hanterar rättigheter och behörigheter för arbetsboken finns i Åtkomstkontroll.

Fastställa rotorsaken till datainmatningen

Container Insights-data består främst av måtträknare (Perf, Inventory, InsightsMetrics och anpassade mått) och loggar (ContainerLog). Baserat på din klusteranvändning och storlek kan du ha olika krav och övervakningsbehov.

Genom att gå till avsnittet Efter tabell i arbetsboken Dataanvändning kan du se uppdelningen av tabellstorlekar för Container Insights.

Om majoriteten av dina data kommer från någon av följande tabeller:

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

Du kan justera inmatningen med hjälp av inställningarna för kostnadsoptimering och/eller migrera till prometheus-måtttillägget

Annars tillhör majoriteten av dina data tabellen ContainerLog. och du kan följa stegen nedan för att minska dina ContainerLog-kostnader.

Minska dina ContainerLog-kostnader

När du har slutfört analysen för att avgöra vilka källor som genererar de data som överskrider dina krav kan du konfigurera om datainsamlingen. Mer information om hur du konfigurerar insamling av stdout-, stderr- och miljövariabler finns i Konfigurera inställningar för agentdatainsamling.

I följande exempel visas vilka ändringar du kan tillämpa på klustret genom att ändra ConfigMap-filen för att styra kostnaden.

1. Inaktivera stdout-loggar i alla namnområden i klustret genom att ändra följande kod i ConfigMap-filen för Azure Container Insights-tjänsten som hämtar måtten:

   [log_collection_settings]       
      [log_collection_settings.stdout]          
         enabled = false
   

2. Inaktivera insamling av stderr-loggar från ditt namnområde för utveckling. Ett exempel är dev-test. Fortsätt att samla in stderr-loggar från andra namnområden, till exempel prod och default, genom att ändra följande kod i ConfigMap-filen:

   Kommentar

   Kube-system-loggsamlingen är inaktiverad som standard. Standardinställningen behålls. dev-test Att lägga till namnområdet i listan över exkluderingsnamnområden tillämpas på stderr-loggsamlingen.

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

3. Inaktivera miljövariabelsamlingen i klustret genom att ändra följande kod i ConfigMap-filen. Den här ändringen gäller för alla containrar i varje Kubernetes-namnområde.

   [log_collection_settings.env_var]
       enabled = false
   

4. Om du vill rensa jobb som är klara anger du rensningsprincipen i din jobbdefinitions yaml. Nedan visas exempel på jobbdefinition med rensningsprincip. Mer information finns i Kubernetes-dokumentationen.

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

När du har tillämpat en eller flera av dessa ändringar på din konfiguration Kartor använder du den på klustret med kommandot kubectl apply -f <config3. map_yaml_file.yaml>. Kör till exempel kommandot kubectl apply -f container-azm-ms-agentconfig.yaml för att öppna filen i standardredigeraren för att ändra och sedan spara den.

Konfigurera grundläggande loggar

Du kan spara på kostnader för datainmatning på ContainerLog på din Log Analytics-arbetsyta som du främst använder för felsökning, felsökning och granskning som grundläggande loggar. Mer information, inklusive begränsningarna för grundläggande loggar, finns i Konfigurera grundläggande loggar i Azure Monitor. ContainerLogV2 är den konfigurerade versionen av Grundläggande loggar som Container Insights använder. ContainerLogV2 innehåller utförliga textbaserade loggposter.

Du måste vara i ContainerLogV2-schemat för att konfigurera grundläggande loggar. Mer information finns i Aktivera ContainerLogV2-schemat (förhandsversion).

Prometheus-måttskrapa

Kommentar

I det här avsnittet beskrivs en samling Prometheus-mått på din Log Analytics-arbetsyta. Den här informationen gäller inte om du använder Managed Prometheus för att skrapa dina Prometheus-mått.

Om du samlar in Prometheus-mått på Log Analytics-arbetsytan kontrollerar du att du begränsar antalet mått som du samlar in från klustret:

• Se till att skrapfrekvensen är optimalt inställd. Standardvärdet är 60 sekunder. Du kan öka frekvensen till 15 sekunder, men du måste se till att de mått som du skrapar publiceras med den frekvensen. Annars kommer många duplicerade mått att skrapas och skickas till Log Analytics-arbetsytan med intervall som lägger till datainmatnings- och kvarhållningskostnader men är av mindre värde.
• Containerinsikter stöder undantags- och inkluderingslistor efter måttnamn. Om du till exempel skrapar kubedns-mått i klustret kan hundratals av dem skrapas som standard. Men du är förmodligen bara intresserad av en delmängd av måtten. Bekräfta att du har angett en lista med mått som ska skrapas eller exkludera andra förutom några få som ska sparas på datainmatningsvolymen. Det är enkelt att aktivera skrapning och inte använda många av dessa mått, vilket bara lägger till avgifter till Din Log Analytics-faktura.
• När du skrapar genom poddkommentarer ska du filtrera efter namnområde så att du undantar skrapning av poddmått från namnområden som du inte använder. Ett exempel är dev-test namnområdet.

Data som samlas in från Kubernetes-kluster

Måttdata

Containerinsikter innehåller en fördefinierad uppsättning mått och inventeringsobjekt som samlas in som loggdata på Log Analytics-arbetsytan. Alla mått i följande tabell samlas in var minut.

Typ	Mått
Nodmått	cpuUsageNanoCores cpuCapacityNanoCores cpuAllocatableNanoCores memoryRssBytes memoryWorkingSetBytes memoryCapacityBytes memoryAllocatableBytes restartTimeEpoch used (disk) free (disk) used_percent (disk) 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 (netto) err_out (netto) bytes_recv (netto) bytes_sent (netto) Kubelet_docker_operations (kubelet)
Containermått	cpuUsageNanoCores cpuRequestNanoCores cpuLimitNanoCores memoryRssBytes memoryWorkingSetBytes memoryRequestBytes memoryLimitBytes restartTimeEpoch

Klusterinventering

Följande lista är klusterinventeringsdata som samlas in som standard:

• KubePodInventory – 1 per podd per minut
• KubeNodeInventory – 1 per nod per minut
• KubeServices – 1 per tjänst per minut
• ContainerInventory – 1 per container per minut

Nästa steg

Information om vilka kostnader som sannolikt kommer att baseras på de senaste användningsmönstren från data som samlats in med containerinsikter finns i Analysera användning på en Log Analytics-arbetsyta.