Omówienie kosztów monitorowania dla usługi Container Insights

Ten artykuł zawiera wskazówki dotyczące cen dla usługi Container Insights, które ułatwiają zrozumienie, jak:

• Mierzenie kosztów po włączeniu usługi Container Insights dla co najmniej jednego kontenera.
• Kontrolowanie zbierania danych i obniżanie kosztów.

Napiwek

Aby uzyskać strategie zmniejszenia kosztów usługi Azure Monitor, zobacz Optymalizacja kosztów i Usługa Azure Monitor.

Model cen usługi Azure Monitor opiera się głównie na ilości danych pozyskiwanych w gigabajtach dziennie w obszarze roboczym usługi Log Analytics. Koszt obszaru roboczego usługi Log Analytics nie zależy tylko od ilości zebranych danych, zależy również od wybranego planu oraz czasu, w jaki wybrano przechowywanie danych wygenerowanych z klastrów.

Uwaga

Zobacz Szacowanie kosztów usługi Azure Monitor, aby oszacować koszty usługi Container Insights przed jego włączeniem.

Następujące typy danych zebranych z klastra Kubernetes ze szczegółowymi informacjami o kontenerze wpływają na koszt i można je dostosować na podstawie użycia:

• Wydajności, spisu, Szczegółowe informacje Metrics i KubeEvents można kontrolować za pomocą ustawień optymalizacji kosztów
• Dzienniki kontenerów Stdout i stderr z każdego monitorowanego kontenera w każdej przestrzeni nazw kubernetes w klastrze za pośrednictwem agenta ConfigMap
• Zmienne środowiskowe kontenera z każdego monitorowanego kontenera w klastrze
• Ukończono zadania/zasobniki kubernetes w klastrze, które nie wymagają monitorowania
• Aktywne złomowanie metryk Rozwiązania Prometheus
• Zbieranie dzienników zasobów dzienników głównego węzła Kubernetes w klastrze usługi Azure Kubernetes Service (AKS) w celu analizowania danych dziennika generowanych przez główne składniki, takie jak kube-apiserver i kube-controller-manager.

Kontrolowanie pozyskiwania danych pod kątem zmniejszenia kosztów

Rozważmy scenariusz, w którym różne jednostki biznesowe organizacji współużytkują infrastrukturę Kubernetes i obszar roboczy usługi Log Analytics. Każda jednostka biznesowa jest oddzielona przestrzenią nazw kubernetes. Dane pozyskiwane w poszczególnych obszarach roboczych można wizualizować przy użyciu elementu Runbook Użycie danych. Element Runbook jest dostępny na karcie Raporty .

Ten skoroszyt ułatwia wizualizowanie źródła danych bez konieczności tworzenia własnej biblioteki zapytań z elementów udostępnianych w naszej dokumentacji. W tym skoroszycie można wyświetlić wykresy przedstawiające rozliczane dane, takie jak:

• Łączna liczba rozliczanych danych pozyskanych w GB według rozwiązania.
• Rozliczane dane pozyskane przez dzienniki kontenera (dzienniki aplikacji).
• Rozliczane dane dzienników kontenerów pozyskane przez przestrzeń nazw kubernetes.
• Rozliczane dane dzienników kontenerów pozyskane według nazwy klastra.
• Rozliczane dane dziennika kontenera pozyskiwane przez wpis źródła dziennika.
• Rozliczane dane diagnostyczne pozyskane przez dzienniki głównego węzła diagnostycznego.

Aby dowiedzieć się więcej na temat zarządzania prawami i uprawnieniami do skoroszytu, zapoznaj się z artykułem Kontrola dostępu.

Określanie głównej przyczyny pozyskiwania danych

Dane Szczegółowe informacje kontenera składają się głównie z liczników metryk (wydajności, spisu, Szczegółowe informacje metryki i metryk niestandardowych) i dzienników (ContainerLog). Na podstawie użycia i rozmiaru klastra mogą istnieć różne wymagania i potrzeby monitorowania.

Przechodząc do sekcji Według tabeli skoroszytu Użycie danych, możesz zobaczyć podział rozmiarów tabel dla kontenera Szczegółowe informacje.

Jeśli większość danych pochodzi z jednej z następujących tabel:

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

Pozyskiwanie można dostosować przy użyciu ustawień optymalizacji kosztów i/lub migracji do dodatku metryk Rozwiązania Prometheus

W przeciwnym razie większość danych należy do tabeli ContainerLog. możesz wykonać poniższe kroki, aby zmniejszyć koszty usługi ContainerLog.

Zmniejszanie kosztów usługi ContainerLog

Po zakończeniu analizy w celu określenia, które źródła generują dane przekraczające wymagania, można ponownie skonfigurować zbieranie danych. Aby uzyskać więcej informacji na temat konfigurowania kolekcji zmiennych stdout, stderr i środowiskowych, zobacz Konfigurowanie ustawień zbierania danych agenta.

W poniższych przykładach pokazano, jakie zmiany można zastosować do klastra, modyfikując plik ConfigMap w celu kontrolowania kosztów.

1. Wyłącz dzienniki stdout we wszystkich przestrzeniach nazw w klastrze, modyfikując następujący kod w pliku ConfigMap dla usługi Azure Container Insights, która ściąga metryki:

   [log_collection_settings]       
      [log_collection_settings.stdout]          
         enabled = false
   

2. Wyłącz zbieranie dzienników stderr z przestrzeni nazw programowania. Może to być na przykład dev-test. Kontynuuj zbieranie dzienników stderr z innych przestrzeni nazw, takich jak prod i default, przez zmodyfikowanie następującego kodu w pliku ConfigMap:

   Uwaga

   Zbieranie dzienników kube-system jest domyślnie wyłączone. Ustawienie domyślne jest zachowywane. dev-test Dodanie przestrzeni nazw do listy przestrzeni nazw wykluczeń jest stosowane do kolekcji dzienników stderr.

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

3. Wyłącz zbieranie zmiennych środowiskowych w klastrze, modyfikując następujący kod w pliku ConfigMap. Ta modyfikacja dotyczy wszystkich kontenerów w każdej przestrzeni nazw kubernetes.

   [log_collection_settings.env_var]
       enabled = false
   

4. Aby wyczyścić zadania, które zostały ukończone, określ zasady oczyszczania w pliku yaml definicji zadania. Poniżej przedstawiono przykładową definicję zadania z zasadami czyszczenia. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją platformy Kubernetes.

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

Po zastosowaniu co najmniej jednej z tych zmian do konfiguracji Mapy zastosuj ją do klastra za pomocą polecenia kubectl apply -f <config3. map_yaml_file.yaml>. Na przykład uruchom polecenie kubectl apply -f container-azm-ms-agentconfig.yaml , aby otworzyć plik w edytorze domyślnym, aby go zmodyfikować, a następnie zapisać go.

Konfigurowanie dzienników podstawowych

Możesz zaoszczędzić na kosztach pozyskiwania danych w usłudze ContainerLog w obszarze roboczym usługi Log Analytics, który jest używany głównie do debugowania, rozwiązywania problemów i inspekcji jako dzienniki podstawowe. Aby uzyskać więcej informacji, w tym ograniczenia dzienników podstawowych, zobacz Konfigurowanie dzienników podstawowych w usłudze Azure Monitor. ContainerLogV2 to skonfigurowana wersja dzienników podstawowych używanych przez kontener Szczegółowe informacje. ContainerLogV2 zawiera pełne rekordy dziennika oparte na tekście.

Aby skonfigurować dzienniki podstawowe, musisz być w schemacie ContainerLogV2. Aby uzyskać więcej informacji, zobacz Włączanie schematu ContainerLogV2 (wersja zapoznawcza).

Złomowanie metryk Prometheus

Uwaga

W tej sekcji opisano kolekcję metryk Rozwiązania Prometheus w obszarze roboczym usługi Log Analytics. Te informacje nie mają zastosowania, jeśli używasz zarządzanego rozwiązania Prometheus do złomowania metryk rozwiązania Prometheus.

Jeśli zbierzesz metryki rozwiązania Prometheus w obszarze roboczym usługi Log Analytics, upewnij się, że ograniczasz liczbę metryk zbieranych z klastra:

• Upewnij się, że częstotliwość złomowania jest optymalnie ustawiona. Wartość domyślna to 60 sekund. Możesz zwiększyć częstotliwość do 15 sekund, ale musisz upewnić się, że metryki, które ściskasz, są publikowane z tej częstotliwości. W przeciwnym razie wiele zduplikowanych metryk zostanie zeskromionych i wysłanych do obszaru roboczego usługi Log Analytics w odstępach czasu, które dodają do kosztów pozyskiwania i przechowywania danych, ale mają mniejszą wartość.
• Usługa Container Insights obsługuje listy wykluczeń i dołączania według nazwy metryki. Na przykład w przypadku złomowania metryk kubedns w klastrze setki z nich mogą zostać domyślnie zeskropane. Jednak najprawdopodobniej interesuje Cię tylko podzbiór metryk. Upewnij się, że określono listę metryk do złomowania lub wykluczyć inne, z wyjątkiem kilku, aby zapisać na woluminie pozyskiwania danych. Łatwo jest włączyć złomowanie i nie używać wielu z tych metryk, co spowoduje dodanie opłat tylko do rachunku za usługę Log Analytics.
• Podczas złomowania adnotacji zasobników upewnij się, że filtrujesz według przestrzeni nazw, aby wykluczyć zeskrobanie metryk zasobnika z przestrzeni nazw, których nie używasz. Przykładem jest dev-test przestrzeń nazw.

Dane zebrane z klastrów Kubernetes

Dane metryk

Szczegółowe informacje o kontenerze obejmują wstępnie zdefiniowany zestaw metryk i elementów spisu zebranych, które są zapisywane jako dane dziennika w obszarze roboczym usługi Log Analytics. Wszystkie metryki w poniższej tabeli są zbierane co minutę.

Typ	Metryki
Metryki węzła	cpuUsageNanoCores cpuCapacityNanoCores cpuAllocatableNanoCores memoryRssBytes memoryWorkingSetBytes memoryCapacityBytes memoryAllocatableBytes restartTimeEpoch used (dysk) free (dysk) used_percent (dysk) 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)
Metryki kontenera	cpuUsageNanoCores cpuRequestNanoCores cpuLimitNanoCores memoryRssBytes memoryWorkingSetBytes memoryRequestBytes memoryLimitBytes restartTimeEpoch

Spis klastrów

Poniższa lista to dane spisu klastra zbierane domyślnie:

• KubePodInventory — 1 na zasobnik na minutę
• KubeNodeInventory — 1 na węzeł na minutę
• KubeServices — 1 na usługę na minutę
• ContainerInventory — 1 na kontener na minutę

Następne kroki

Aby ułatwić zrozumienie, jakie koszty mogą być oparte na najnowszych wzorcach użycia z danych zebranych za pomocą usługi Container Insights, zobacz Analizowanie użycia w obszarze roboczym usługi Log Analytics.