Pahami biaya pemantauan untuk insight Kontainer

Artikel ini menyediakan panduan harga untuk wawasan Kontainer untuk membantu Anda memahami cara:

• Mengukur biaya setelah wawasan Kontainer diaktifkan untuk satu atau beberapa kontainer.
• Mengontrol pengumpulan data dan melakukan pengurangan biaya.

Tip

Untuk strategi mengurangi biaya Azure Monitor Anda, lihat Pengoptimalan biaya dan Azure Monitor.

Model harga Azure Monitor terutama didasarkan pada jumlah data yang terserap dalam gigabyte per hari ke ruang kerja Analitik Log Anda. Biaya ruang kerja Analitik Log tidak hanya didasarkan pada volume data yang dikumpulkan, ia juga tergantung pada paket yang dipilih, dan berapa lama Anda memilih untuk menyimpan data yang dihasilkan dari kluster Anda.

Catatan

Lihat Memperkirakan biaya Azure Monitor untuk memperkirakan biaya Anda untuk wawasan Kontainer sebelum Anda mengaktifkannya.

Jenis data berikut yang dikumpulkan dari kluster Kubernetes dengan wawasan Kontainer memengaruhi biaya dan dapat disesuaikan berdasarkan penggunaan Anda:

• Perf, Inventory, InsightsMetrics, dan KubeEvents dapat dikontrol melalui pengaturan pengoptimalan biaya
• Log kontainer stdout dan stderr dari setiap kontainer yang dipantau di setiap namespace Layanan Kubernetes di kluster melalui agen ConfigMap
• Variabel lingkungan kontainer dari setiap kontainer yang dipantau dalam kluster
• Menyelesaikan pekerjaan/pod Kubernetes di kluster yang tidak memerlukan pemantauan
• Pengikisan aktif metrik Prometheus
• Pengumpulan log sumber daya log simpul utama Kubernetes di kluster Azure Kubernetes Service (AKS) Anda untuk menganalisis data log yang dihasilkan oleh komponen utama, seperti kube-apiserver dan kube-controller-manager.

Mengendalikan penyerapan untuk mengurangi biaya

Pertimbangkan skenario di mana unit bisnis organisasi Anda yang berbeda berbagi infrastruktur Kubernetes dan ruang kerja Analitik Log. Setiap unit bisnis dipisahkan oleh namespace Layanan Kubernetes. Anda dapat memvisualisasikan berapa banyak data yang diserap di setiap ruang kerja dengan menggunakan runbook Penggunaan Data. Runbook tersedia dari tab Laporan .

Buku kerja ini membantu Anda memvisualisasikan sumber data Anda tanpa harus membangun pustaka kueri Anda sendiri dari apa yang kami bagikan dalam dokumentasi kami. Dalam buku kerja ini, Anda bisa menampilkan bagan yang menyajikan data yang dapat ditagih seperti:

• Total data yang dapat ditagih yang diserap dalam GB berdasarkan solusi.
• Data yang dapat ditagih yang diserap oleh log Kontainer (log aplikasi).
• Data log kontainer yang dapat ditagih yang diserap oleh namespace Layanan Kubernetes.
• Data log kontainer yang dapat ditagih yang diserap oleh nama Kluster.
• Data log kontainer yang dapat ditagih yang diserap oleh entri sumber log.
• Data diagnostik yang dapat ditagih yang diserap oleh log simpul utama diagnostik.

Untuk mempelajari tentang mengelola hak dan izin akses ke buku kerja, tinjau Kontrol akses.

Menentukan akar penyebab penyerapan data

Data Container Insights terutama terdiri dari penghitung metrik (Perf, Inventory, InsightsMetrics, dan metrik kustom) dan log (ContainerLog). Berdasarkan penggunaan dan ukuran kluster, Anda mungkin memiliki persyaratan dan kebutuhan pemantauan yang berbeda.

Dengan menavigasi ke bagian Menurut Tabel dari buku kerja Penggunaan Data, Anda bisa melihat perincian ukuran tabel untuk Container Insights.

Jika sebagian besar data Anda berasal dari salah satu tabel berikut ini:

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

Anda dapat menyesuaikan penyerapan menggunakan pengaturan pengoptimalan biaya dan/atau migrasi ke addon metrik Prometheus

Jika tidak, sebagian besar data Anda milik tabel ContainerLog dan Anda dapat mengikuti langkah-langkah di bawah ini untuk mengurangi biaya ContainerLog Anda.

Mengurangi biaya ContainerLog Anda

Setelah menyelesaikan analisis untuk menentukan sumber mana yang menghasilkan data yang melebihi kebutuhan Anda, Anda dapat mengonfigurasi ulang pengumpulan data. Untuk informasi selengkapnya tentang mengonfigurasi pengumpulan variabel stdout, stderr, dan lingkungan, lihat Mengonfigurasi pengaturan pengumpulan data agen.

Contoh berikut menunjukkan perubahan apa yang dapat Anda terapkan ke kluster Anda dengan memodifikasi file ConfigMap untuk membantu mengontrol biaya.

1. Nonaktifkan log stdout di semua namespace dalam kluster dengan memodifikasi kode berikut dalam file ConfigMap untuk layanan wawasan Azure Container yang menarik metrik:

   [log_collection_settings]       
      [log_collection_settings.stdout]          
         enabled = false
   

2. Nonaktifkan pengumpulan log stderr dari namespace layanan pengembangan Anda. Contohnya dev-test. Lanjutkan mengumpulkan log stderr dari namespace layanan lain, seperti, prod dan default, dengan memodifikasi kode berikut dalam file ConfigMap:

   Catatan

   Koleksi log kube-system dinonaktifkan secara default. Pengaturan default dipertahankan. dev-test Menambahkan namespace ke daftar namespace pengecualian diterapkan ke kumpulan log stderr.

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

3. Nonaktifkan pengumpulan variabel lingkungan di seluruh kluster dengan memodifikasi kode berikut dalam file ConfigMap. Modifikasi ini berlaku untuk semua kontainer di setiap namespace Layanan Kubernetes.

   [log_collection_settings.env_var]
       enabled = false
   

4. Untuk membersihkan pekerjaan yang selesai, tentukan kebijakan pembersihan dalam yaml definisi kerja Anda. Berikut ini adalah contoh Definisi pekerjaan dengan kebijakan pembersihan. Untuk detail selengkapnya, lihat dokumentasi Kubernetes.

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

Setelah Anda menerapkan satu atau beberapa perubahan ini ke ConfigMaps Anda, terapkan ke kluster Anda dengan perintah kubectl apply -f <config3. map_yaml_file.yaml>. Misalnya, jalankan perintah kubectl apply -f container-azm-ms-agentconfig.yaml untuk membuka file di editor default Anda untuk memodifikasi lalu menyimpannya.

Mengonfigurasi Log Dasar

Anda dapat menghemat biaya penyerapan data di ContainerLog di ruang kerja Analitik Log yang terutama Anda gunakan untuk penelusuran kesalahan, pemecahan masalah, dan audit sebagai Log Dasar. Untuk informasi selengkapnya, termasuk batasan Log Dasar, lihat Mengonfigurasi Log Dasar di Azure Monitor. ContainerLogV2 adalah versi Log Dasar terkonfigurasi yang digunakan Container Insights. ContainerLogV2 mencakup rekaman log berbasis teks verbose.

Anda harus berada di skema ContainerLogV2 untuk mengonfigurasi Log Dasar. Untuk informasi selengkapnya, lihat Mengaktifkan skema ContainerLogV2.

Pengikisan metrik Prometheus

Catatan

Bagian ini menjelaskan kumpulan metrik Prometheus di ruang kerja Analitik Log Anda. Informasi ini tidak berlaku jika Anda menggunakan Prometheus Terkelola untuk mengikis metrik Prometheus Anda.

Jika Anda mengumpulkan metrik Prometheus di ruang kerja Analitik Log, pastikan Anda membatasi jumlah metrik yang Anda kumpulkan dari kluster:

• Pastikan frekuensi pengikisan diatur secara optimal. Defaultnya adalah 60 detik. Anda dapat meningkatkan frekuensi menjadi 15 detik, tetapi Anda harus memastikan bahwa metrik yang Anda scraping diterbitkan pada frekuensi tersebut. Jika tidak, banyak metrik duplikat akan diekstraksi dan dikirim ke ruang kerja Analitik Log Anda dengan interval yang menambah biaya penyerapan dan retensi data tetapi memiliki nilai yang lebih sedikit.
• Wawasan kontainer mendukung daftar pengecualian dan penyertaan berdasarkan nama metrik. Misalnya, jika Anda mengikis metrik kubedns di kluster Anda, ratusan metrik tersebut mungkin akan diekstraksi secara default. Tetapi Kemungkinan besar Anda hanya tertarik pada subset metrik. Konfirmasikan bahwa Anda menentukan daftar metrik untuk diekstraksi, atau mengecualikan yang lain kecuali beberapa untuk menghemat volume penyerapan data. Sangat mudah untuk mengaktifkan pengikisan dan tidak menggunakan banyak metrik tersebut, yang hanya akan menambahkan biaya ke tagihan Analitik Log Anda.
• Saat Anda mengekstrak melalui anotasi pod, pastikan Anda memfilter menurut namespace sehingga Anda mengecualikan pengikisan metrik pod dari namespace yang tidak Anda gunakan. Contohnya dev-test adalah namespace layanan.

Data yang dikumpulkan dari kluster Kubernetes

Data metrik

Insight kontainer mencakup set metrik dan item inventaris yang telah ditentukan sebelumnya lalu dikumpulkan, yang ditulis sebagai data log di ruang kerja Analitik Log Anda. Semua metrik dalam tabel berikut dikumpulkan setiap satu menit.

Jenis	Metrik
Metrik simpul	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)
Metrik kontainer	cpuUsageNanoCores cpuRequestNanoCores cpuLimitNanoCores memoryRssBytes memoryWorkingSetBytes memoryRequestBytes memoryLimitBytes restartTimeEpoch

Inventaris kluster

Daftar berikut adalah data inventaris kluster yang dikumpulkan secara default:

• KubePodInventory – 1 per pod per menit
• KubeNodeInventory – 1 per simpul per menit
• KubeServices – 1 per layanan per menit
• ContainerInventory - 1 per kontainer per menit

Langkah berikutnya

Untuk membantu Anda memahami biaya yang mungkin didasarkan pada pola penggunaan terbaru dari data yang dikumpulkan dengan wawasan Kontainer, lihat Menganalisis penggunaan di ruang kerja Analitik Log.