Informationen zur Kostenüberwachung für Container Insights

In diesem Artikel erhalten Sie Informationen rund um Kostenfragen zu Container Insights, um Sie bei Folgendem zu unterstützen:

• Messen der Kosten nach Aktivieren von Container Insights für einen oder mehrere Container
• Verwalten der Datenerfassung und Senken von Kosten

Tipp

Strategien zum Reduzieren Ihrer Azure Monitor-Kosten finden Sie unter Kostenoptimierung und Azure Monitor.

Das Azure Monitor-Preismodell basiert hauptsächlich auf der Datenmenge (in GB), die pro Tag in Ihrem Log Analytics-Arbeitsbereich erfasst wird. Die Kosten eines Log Analytics-Arbeitsbereichs basieren jedoch nicht nur auf dem Umfang der gesammelten Daten, sondern auch auf dem ausgewählten Plan und der Speicherdauer der von den Clustern generierten Daten.

Hinweis

Unter Schätzen von Azure Monitor-Kosten erfahren Sie, wie Sie Ihre Kosten für Containererkenntnisse vor der Aktivierung schätzen können.

Die folgenden Datentypen, die von einem Kubernetes-Cluster mit Container Insights erfasst werden, haben Auswirkungen auf die Kosten und können entsprechend Ihrer Nutzung angepasst werden:

• Perf, Inventory, InsightsMetrics und KubeEvents können über Kostenoptimierungseinstellungen gesteuert werden.
• Containerprotokolle „stdout“ und „stderr“ aus allen überwachten Containern in sämtlichen Kubernetes-Namespaces im Cluster über agent ConfigMap
• Die Containerumgebungsvariablen aus allen überwachten Containern im Cluster.
• Abgeschlossen Kubernetes-Aufträge/-Pods im Cluster, die nicht überwacht werden müssen
• Das aktive Abrufen von Prometheus-Metriken.
• Die Ressourceprotokollsammlung von Kubernetes-Hauptknotenprotokollen in Ihrem AKS-Cluster (Azure Kubernetes Service) zum Analysieren von Protokolldaten, die von Hauptkomponenten wie kube-apiserver und kube-controller-manager generiert wurden.

Steuern der Datenerfassung zum Senken der Kosten

Stellen Sie sich ein Szenario vor, in dem die unterschiedlichen Geschäftseinheiten Ihres Unternehmens sich die Kubernetes-Infrastruktur und einen Log Analytics-Arbeitsbereich teilen. Dabei werden die Geschäftseinheiten durch Kubernetes-Namespaces voneinander getrennt. Mithilfe des Runbooks Datennutzung können Sie die Datenmengen visualisieren, die in den einzelnen Arbeitsbereichen erfasst werden. Das Runbook ist auf der Registerkarte Berichte verfügbar.

Mithilfe dieses Workbooks können Sie die Datenquelle visualisieren, ohne selbst eine Abfragenbibliothek basierend auf den in der Dokumentation freigegebenen Informationen erstellen zu müssen. In diesem Workbook können Sie Diagramme anzeigen, die abrechenbare Daten enthalten, z. B.:

• Gesamtmenge der erfassten abrechenbaren Daten pro Lösung in GB
• In Containerprotokollen (Anwendungsprotokollen) erfasste abrechenbare Daten
• In einem Kubernetes-Namespace erfasste abrechenbare Containerprotokolldaten
• Nach Clusternamen aufgeteilte, erfasste abrechenbare Containerprotokolldaten
• In einem Protokollquelleintrag erfasste abrechenbare Containerprotokolldaten
• In Diagnosehauptknotenprotokollen erfasste abrechenbare Diagnosedaten

Weitere Informationen zum Verwalten von Rechten und Berechtigungen für die Arbeitsmappe finden Sie unter Zugriffssteuerung.

Ermitteln der Grundursache der Datenerfassung

Container Insights-Daten bestehen hauptsächlich aus Metrikindikatoren (Perf, Inventory, InsightsMetrics und benutzerdefinierte Metriken) sowie Protokollen (ContainerLog). Je nach Clusterverwendung und -größe gelten möglicherweise unterschiedliche Voraussetzungen und Überwachungsanforderungen.

Wenn Sie zum Abschnitt „Nach Tabelle“ in der Arbeitsmappe „Datennutzung“ navigieren, sehen Sie die Aufschlüsselung der Tabellengrößen für Container Insights.

Wenn der Großteil Ihrer Daten aus einer der folgenden Tabellen stammt:

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

Sie können Ihre Erfassung mithilfe der Kostenoptimierungseinstellungen und/oder der Migration zum Prometheus-Metrik-Add-On anpassen.

Andernfalls gehören die meisten Daten zur ContainerLog-Tabelle. Und Sie können die folgenden Schritte ausführen, um Ihre ContainerLog-Kosten zu senken.

Reduzieren der ContainerLog-Kosten

Wenn Sie analysiert haben, welche Quellen die Daten generieren, die Ihre Anforderungen überschreiten, können Sie die Datensammlung neu konfigurieren. Weitere Informationen zur Konfiguration der Erfassung von „stdout“, „stderr“ und Umgebungsvariablen finden Sie unter Konfigurieren der Datensammlungseinstellungen des Agents.

Die folgenden Beispiele zeigen Änderungen an Ihrem Cluster durch Ändern der Datei „ConfigMap“ vornehmen, um die Kosten zu verwalten.

1. Deaktivieren Sie „stdout“-Protokolle für alle Namespaces im Cluster, indem Sie den folgenden Code in der Datei „ConfigMap“ für den Azure Container Insights-Dienst ändern, der die Metriken abruft:

   [log_collection_settings]       
      [log_collection_settings.stdout]          
         enabled = false
   

2. Deaktivieren Sie das Erfassen von „stderr“-Protokollen aus Ihrem Entwicklungsnamespace. z. B. dev-test. Fahren Sie mit dem Erfassen von „stderr“-Protokollen aus anderen Namespaces wie prod und default fort, indem Sie den folgenden Code in der Datei „ConfigMap“ ändern:

   Hinweis

   Die Sammlung von kube-system-Protokollen ist standardmäßig deaktiviert. Die Standardeinstellung wird beibehalten. Fügen Sie den Namespace dev-test der Liste mit Ausschlussnamespaces hinzu, die für die „stderr“-Protokollsammlung gilt.

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

3. Deaktivieren Sie die Sammlung von Umgebungsvariablen im gesamten Cluster, indem Sie den folgende Code in der Datei „ConfigMap“ ändern. Diese Änderung gilt für alle Container in sämtlichen Kubernetes-Namespaces.

   [log_collection_settings.env_var]
       enabled = false
   

4. Um beendete Aufträge zu bereinigen, geben Sie die Richtlinie für die Bereinigung in Ihrer YAML-Auftragsdefinition an. Es folgt eine Beispielauftragsdefinition mit einer Richtlinie zur Bereinigung. Weitere Informationen finden Sie in der Kubernetes-Dokumentation.

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

Nachdem Sie eine oder mehrere dieser Änderungen auf die Datei „ConfigMap“ angewendet haben, wenden Sie sie mit dem Befehl kubectl apply -f <config3. map_yaml_file.yaml> auf Ihren Cluster an. Führen Sie beispielsweise den Befehl kubectl apply -f container-azm-ms-agentconfig.yaml aus, um die Datei in Ihrem Standard-Editor zu öffnen, damit Sie sie ändern und speichern können.

Konfigurieren von Basisprotokollen

Sie können Datenerfassungskosten für ContainerLog in Ihrem Log Analytics-Arbeitsbereich sparen, die hauptsächlich zum Debuggen, für die Problembehandlung und für die Überwachung als Basisprotokolle anfallen. Weitere Informationen, einschließlich zu Einschränkungen von Basisprotokollen, finden Sie unter Festlegen des Protokolldatenplans einer Tabelle auf „Basis“ oder „Analyse“. ContainerLogV2 ist die konfigurierte Version von Basisprotokollen, die Container Insights verwendet. ContainerLogV2 enthält ausführliche textbasierte Protokolldatensätze.

Sie müssen das ContainerLogV2-Schema nutzen, um Basisprotokolle zu konfigurieren. Weitere Informationen finden Sie unter Aktivieren des ContainerLogV2-Schemas (Vorschau).

Abfragen von Prometheus-Metriken

Hinweis

In diesem Abschnitt wird die Sammlung von Prometheus-Metriken in Ihrem Log Analytics-Arbeitsbereich beschrieben. Diese Informationen gelten nicht, wenn Sie eine verwaltete Prometheus-Instanz verwenden, um Ihre Prometheus-Metriken auszulesen.

Wenn Sie Prometheus-Metriken in Ihrem Log Analytics-Arbeitsbereich erfassen, stellen Sie sicher, dass Sie die Anzahl der Metriken einschränken, die Sie aus Ihrem Cluster sammeln.

• Stellen Sie sicher, dass die Erfassungshäufigkeit optimal festgelegt ist. Der Standardwert ist 60 Sekunden. Sie können die Häufigkeit auf 15 Sekunden erhöhen, Sie müssen jedoch sicherstellen, dass die Metriken, die Sie erfassen, auch in dieser Häufigkeit veröffentlicht werden. Andernfalls werden viele doppelte Metriken erfasst und an Ihren Log Analytics-Arbeitsbereich gesendet, was nur zu höheren Kosten für die Datenerfassung und -aufbewahrung, jedoch nicht zu weiteren Vorteilen führt.
• Container Insights unterstützt Ausschlusslisten und Aufnahmelisten nach Metrikname. Wenn Sie z. B. kubedns-Metriken in Ihrem Cluster erfassen, werden möglicherweise Hunderte von ihnen standardmäßig ausgelesen. Allerdings sind Sie höchstwahrscheinlich nur an einem Teil der Metriken interessiert. Überprüfen Sie, dass Sie eine Liste mit den zu erfassenden Metriken angegeben haben, oder schließen Sie andere aus, um die Menge der erfassten Daten zu verringern. Das Erfassen von Metriken ist schnell aktiviert. Wenn Sie jedoch nur einen Bruchteil der Metriken auch wirklich nutzen, entstehen unnötige Kosten.
• Filtern Sie beim Erfassen von Podanmerkungen nach Namespaces, damit Sie nicht verwendete Namespaces ausschließen können. Ein Beispiel ist der Namespace dev-test.

Aus Kubernetes-Clustern erfasste Daten

Metrikdaten

Container Insights enthält vordefinierte Metriken und Bestandselemente, die als Protokolldaten in Ihren Log Analytics-Arbeitsbereich geschrieben werden. Die in der folgenden Tabelle aufgeführten Metriken werden im Minutentakt gesammelt:

type	Metriken
Knotenmetriken	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 (net) err_out (net) bytes_recv (net) bytes_sent (net) Kubelet_docker_operations (kubelet)
Containermetriken	cpuUsageNanoCores cpuRequestNanoCores cpuLimitNanoCores memoryRssBytes memoryWorkingSetBytes memoryRequestBytes memoryLimitBytes restartTimeEpoch

Clusterbestand

Die folgenden Clusterbestandsdaten werden standardmäßig gesammelt:

• KubePodInventory: pro Pod 1/min
• KubeNodeInventory: pro Knoten 1/min
• KubeServices: pro Dienst 1/min
• ContainerInventory: pro Container 1/min

Nächste Schritte

Weitere Informationen zu Kostenschätzungen basierend auf aktuellen Verwendungsmustern von Daten, die mit Container Insights erfasst werden, finden Sie unter Analysieren der Nutzung in einem Log Analytics-Arbeitsbereich.