Kapsayıcı içgörüleri için izleme maliyetlerini anlama

Bu makalede, nasıl yapılacağını anlamanıza yardımcı olmak için Kapsayıcı içgörüleri için fiyatlandırma yönergeleri sağlanır:

• Bir veya daha fazla kapsayıcı için Kapsayıcı içgörüleri etkinleştirildikten sonra maliyetleri ölçün.
• Veri toplamayı denetleme ve maliyet azaltma işlemleri yapma.

Bahşiş

Azure İzleyici maliyetlerinizi azaltma stratejileri için bkz . Maliyet iyileştirme ve Azure İzleyici.

Azure İzleyici fiyatlandırma modeli öncelikle Log Analytics çalışma alanınıza günlük gigabayt cinsinden alınan veri miktarını temel alır. Log Analytics çalışma alanının maliyeti yalnızca toplanan veri hacmine bağlı değildir, aynı zamanda seçilen plana ve kümelerinizden oluşturulan verileri depolamayı ne kadar süreyle seçtiğinize bağlıdır.

Dekont

Etkinleştirmeden önce Kapsayıcı içgörüleri için maliyetlerinizi tahmin etmek için bkz. Azure İzleyici maliyetlerini tahmin etme.

Kapsayıcı içgörüleri içeren bir Kubernetes kümesinden toplanan aşağıdaki veri türleri maliyeti etkiler ve kullanımınıza göre özelleştirilebilir:

• Performans, Stok, Analizler Metrics ve KubeEvents, maliyet iyileştirme ayarları aracılığıyla denetlenebilir
• Stdout ve stderr kapsayıcısı, aracı ConfigMap aracılığıyla kümedeki her Kubernetes ad alanında izlenen her kapsayıcıdan günlükler
• Kümedeki izlenen her kapsayıcıdan kapsayıcı ortamı değişkenleri
• Tamamlandı Kümede izleme gerektirmeyen Kubernetes işleri/podları
• Prometheus ölçümlerinin etkin kazınma
• ve kube-controller-managergibi kube-apiserver ana bileşenler tarafından oluşturulan günlük verilerini analiz etmek için Azure Kubernetes Service (AKS) kümenizdeki Kubernetes ana düğüm günlüklerinin kaynak günlüğü koleksiyonu.

Maliyeti düşürmek için veri alımını denetleme

Kuruluşunuzun farklı iş birimlerinin Kubernetes altyapısını ve Log Analytics çalışma alanını paylaştığı bir senaryo düşünün. Her iş birimi bir Kubernetes ad alanıyla ayrılır. Veri Kullanımı runbook'unu kullanarak her çalışma alanına ne kadar veri alınabileceğini görselleştirebilirsiniz. Runbook'a Raporlar sekmesinden ulaşabilirsiniz.

Bu çalışma kitabı, belgelerimizde paylaştığımız sorgulardan oluşan kendi sorgu kitaplığınızı oluşturmak zorunda kalmadan verilerinizin kaynağını görselleştirmenize yardımcı olur. Bu çalışma kitabında, aşağıdakiler gibi faturalanabilir veriler sunan grafikleri görüntüleyebilirsiniz:

• Çözüme göre GB olarak alınan toplam faturalanabilir veri.
• Kapsayıcı günlükleri (uygulama günlükleri) tarafından alınan faturalanabilir veriler.
• Faturalanabilir kapsayıcı, Kubernetes ad alanı tarafından alınan verileri günlüğe kaydeder.
• Faturalanabilir kapsayıcı, Küme adıyla ayrılmış olarak alınan verileri günlüğe kaydeder.
• Günlük kaynağı girişi tarafından alınan faturalanabilir kapsayıcı günlük verileri.
• Tanılama ana düğüm günlükleri tarafından alınan faturalanabilir tanılama verileri.

Çalışma kitabına yönelik hakları ve izinleri yönetme hakkında bilgi edinmek için Erişim denetimi'ni gözden geçirin.

Veri alımının kök nedenini belirleme

Kapsayıcı Analizler verileri öncelikli olarak ölçüm sayaçlarından (Performans, Envanter, Analizler Metrics ve özel ölçümler) ve günlüklerden (ContainerLog) oluşur. Küme kullanımınıza ve boyutunuz temelinde farklı gereksinimleriniz ve izleme gereksinimleriniz olabilir.

Veri Kullanımı çalışma kitabının Tabloya Göre bölümüne giderek, Kapsayıcı Analizler için tablo boyutlarının dökümünü görebilirsiniz.

Verilerinizin çoğunluğu aşağıdaki tablolardan birinden geliyorsa:

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

Maliyet iyileştirme ayarlarını kullanarak ve/veya Prometheus ölçüm eklentisine geçiş yaparak alımınızı ayarlayabilirsiniz

Aksi takdirde, verilerinizin çoğu ContainerLog tablosuna aittir. ve ContainerLog maliyetlerinizi azaltmak için aşağıdaki adımları izleyebilirsiniz.

ContainerLog maliyetlerinizi azaltma

Gereksinimlerinizi aşan verileri hangi kaynakların oluşturduğunu belirlemek için çözümlemenizi tamamladıktan sonra, veri toplamayı yeniden yapılandırabilirsiniz. stdout, stderr ve ortam değişkenlerinin koleksiyonunu yapılandırma hakkında daha fazla bilgi için bkz . Aracı veri toplama ayarlarını yapılandırma.

Aşağıdaki örneklerde, maliyeti denetlemeye yardımcı olmak için ConfigMap dosyasını değiştirerek kümenize uygulayabileceğiniz değişiklikler gösterilmektedir.

1. Ölçümleri çeken Azure Container insights hizmetinin ConfigMap dosyasında aşağıdaki kodu değiştirerek kümedeki tüm ad alanları genelinde stdout günlüklerini devre dışı bırakın:

   [log_collection_settings]       
      [log_collection_settings.stdout]          
         enabled = false
   

2. Geliştirme ad alanınızdan stderr günlükleri toplamayı devre dışı bırakın. dev-test bunun bir örneğidir. ConfigMap dosyasında aşağıdaki kodu değiştirerek ve defaultgibi prod diğer ad alanlarının stderr günlüklerini toplamaya devam edin:

   Dekont

   kube-system günlük koleksiyonu varsayılan olarak devre dışıdır. Varsayılan ayar korunur. Ad alanını dev-test dışlama ad alanları listesine eklemek stderr günlük koleksiyonuna uygulanır.

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

3. ConfigMap dosyasında aşağıdaki kodu değiştirerek küme genelinde ortam değişkeni koleksiyonunu devre dışı bırakın. Bu değişiklik her Kubernetes ad alanında yer alan tüm kapsayıcılar için geçerlidir.

   [log_collection_settings.env_var]
       enabled = false
   

4. Tamamlanan işleri temizlemek için, iş tanımınızda yaml temizleme ilkesini belirtin. Aşağıda temizleme ilkesiyle örnek İş tanımı verilmiştir. Daha fazla ayrıntı için Kubernetes belgelerine bakın.

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

Yapılandırmanıza bu değişikliklerden birini veya daha fazlasını uyguladıktan sonra Haritalar komutuyla kubectl apply -f <config3. map_yaml_file.yaml>bunu kümenize uygulayın. Örneğin, dosyayı değiştirmek ve kaydetmek üzere varsayılan düzenleyicinizde açmak için komutunu kubectl apply -f container-azm-ms-agentconfig.yaml çalıştırın.

Temel Günlükleri Yapılandırma

Temel Günlükler olarak öncelikle hata ayıklama, sorun giderme ve denetim için kullandığınız Log Analytics çalışma alanınızdaki ContainerLog'da veri alımı maliyetlerinden tasarruf edebilirsiniz. Temel Günlüklerin sınırlamaları da dahil olmak üzere daha fazla bilgi için bkz . Azure İzleyici'de Temel Günlükleri Yapılandırma. ContainerLogV2, Container Analizler tarafından kullanılan Temel Günlüklerin yapılandırılmış sürümüdür. ContainerLogV2 ayrıntılı metin tabanlı günlük kayıtları içerir.

Temel Günlükleri yapılandırmak için ContainerLogV2 şemasında olmanız gerekir. Daha fazla bilgi için bkz . ContainerLogV2 şemasını (önizleme) etkinleştirme.

Prometheus ölçümleri kazıma

Dekont

Bu bölümde Log Analytics çalışma alanınızdaki Prometheus ölçümlerinin koleksiyonu açıklanmaktadır. Prometheus ölçümlerinizi kazımak için Managed Prometheus kullanıyorsanız bu bilgiler geçerli değildir.

Log Analytics çalışma alanınızda Prometheus ölçümlerini toplarsanız kümenizden topladığınız ölçüm sayısını sınırladığınızdan emin olun:

• Kazıma sıklığının en uygun şekilde ayarlandığından emin olun. Varsayılan değer 60 saniyedir. Sıklığı 15 saniyeye çıkarabilirsiniz, ancak kazıdığınız ölçümlerin bu sıklıkta yayımlandığından emin olmanız gerekir. Aksi takdirde birçok yinelenen ölçüm, veri alımı ve saklama maliyetlerine eklenen ancak daha az değerli olan aralıklarla kazınıp Log Analytics çalışma alanınıza gönderilir.
• Kapsayıcı içgörüleri, ölçüm adına göre dışlama ve ekleme listelerini destekler. Örneğin, kümenizde kubedns ölçümlerini kazııyorsanız, bunlardan yüzlercesi varsayılan olarak kazınabilir. Ancak büyük olasılıkla ölçümlerin yalnızca bir alt kümesiyle ilgileniyorsunuz. Veri alımı hacminde kaydedilecek birkaç ölçüm dışında kazınacak veya hariç tutulacak ölçümlerin listesini belirttiğinizi onaylayın. Kazıma özelliğini etkinleştirmek ve bu ölçümlerin çoğunu kullanmamak kolaydır ve bu da yalnızca Log Analytics faturanıza ücret ekler.
• Pod ek açıklamalarını kazıdığınızda, pod ölçümlerinin kazınmasını kullanmadığınız ad alanlarının dışında tutmak için ad alanına göre filtreleme yaptığınızdan emin olun. Ad alanı örnek olarak verilmiştir dev-test .

Kubernetes kümelerinden toplanan veriler

Ölçüm verileri

Kapsayıcı içgörüleri, Log Analytics çalışma alanınızda günlük verileri olarak yazılan, önceden tanımlanmış bir ölçüm ve envanter öğeleri kümesi içerir. Aşağıdaki tabloda yer alan tüm ölçümler bir dakikada bir toplanır.

Tür	Ölçümler
Düğüm ölçümleri	cpuUsageNanoCores cpuCapacityNanoCores cpuAllocatableNanoCores memoryRssBytes memoryWorkingSetBytes memoryCapacityBytes memoryAllocatableBytes restartTimeEpoch used (disk) free (disk) used_percent (disk) io_time (disko) writes (disko) reads (disko) write_bytes (disko) write_time (disko) iops_in_progress (disko) read_bytes (disko) read_time (disko) err_in (net) err_out (net) bytes_recv (net) bytes_sent (net) Kubelet_docker_operations (kubelet)
Kapsayıcı ölçümleri	cpuUsageNanoCores cpuRequestNanoCores cpuLimitNanoCores memoryRssBytes memoryWorkingSetBytes memoryRequestBytes memoryLimitBytes restartTimeEpoch

Küme envanteri

Aşağıdaki liste, varsayılan olarak toplanan küme envanteri verileridir:

• KubePodInventory – Dakikada pod başına 1
• KubeNodeInventory – Dakikada düğüm başına 1
• KubeServices – Dakikada bir hizmet başına 1
• ContainerInventory – Dakikada kapsayıcı başına 1

Sonraki adımlar

Maliyetlerin Container Insights ile toplanan verilerden alınan son kullanım desenlerini temel alma olasılığını anlamanıza yardımcı olmak için bkz . Log Analytics çalışma alanında kullanımı analiz etme.