Agen Prometheus telah diperbarui ke v4.0.0, dengan versi Helm yang sesuai yaitu v1.1.17. Versi ini menawarkan berbagai fitur baru, meningkatkan stabilitas pengumpulan data, memperbaiki bug, serta mengoptimalkan konsumsi sumber daya.
Jika Anda menggunakan Agen Prometheus v3.x.x, segera perbarui ke versi terbaru karena versi tersebut belum dioptimalkan sepenuhnya dan berpotensi menyebabkan gangguan pada data.
Perubahan pada v4.0.0
Jenis Perubahan | Deskripsi |
Fitur Baru | Pekerjaan pengumpulan data deret waktu dapat dibuat untuk peristiwa kluster. Peristiwa kluster dapat ditampilkan di dasbor Kubernetes Deployment. |
Fitur Baru | Metrik pemantauan diri dapat diinstrumen berdasarkan Service-Level Agreement (SLA) untuk menstabilkan data dasbor. Data stabilitas SLA dapat ditampilkan di dasbor pemantauan diri. |
Fitur Baru | ServiceMonitor mendukung metode autentikasi BasicAuth. Rahasia harus berada di namespace yang sama dengan ServiceMonitor. |
Fitur Baru | Kemampuan Metadata Metrik disediakan untuk menampilkan deskripsi dari metrik tertentu. |
Fitur Baru | Versi Agent Chart dapat diteruskan ke server. Kemudian, server menginisialisasi atau memperbarui dasbor berdasarkan versi tersebut. |
Fitur Baru | Metrik pemantauan diri remote write didukung untuk menghitung waktu yang dikonsumsi untuk mengirim data dalam setiap batch. |
Fitur Baru | Metrik tentang kesalahan dan latensi pengumpulan metrik dasar didukung. |
Fitur Baru | Metrik tentang kesalahan dan latensi pengumpulan metrik dasar didukung. |
Optimisasi | Parameter queue_config dalam pengaturan remote write mendukung nilai default berikut: min_shards=10, max_samples_per_send=5000, dan capacity=10.000. Ini meningkatkan adaptabilitas kluster berskala besar. |
Optimisasi | Metode penemuan layanan, terutama pengaturan PV pengumpulan data Container Storage Interface (CSI), dioptimalkan. |
Optimisasi | Frekuensi distribusi senderLoop dioptimalkan, dan frekuensi syncWorkersSeries dimodifikasi untuk mengurangi gangguan yang tidak perlu. |
Optimisasi | Beberapa log disederhanakan. Informasi rinci, seperti waktu yang dikonsumsi untuk penangkapan jejak, dapat ditampilkan di beberapa log. |
Optimisasi | Periode pengumpulan dan pengaturan timeout pekerjaan pengumpulan metrik dasar dikonfigurasi secara terpisah, dan konfigurasi global tidak lagi digunakan. Ini mengurangi gangguan yang tidak perlu pada pengumpulan data metrik dasar. |
Optimisasi | Logika interaksi dalam mode multi-replika master-slave dioptimalkan. Masters dan Workers tidak lagi saling memengaruhi. Ini membantu meningkatkan stabilitas. |
Optimisasi | Kebijakan yang menentukan bagaimana Master mendistribusikan Targets dioptimalkan. Ini menghemat sekitar 30% pemanfaatan CPU dan 40% sumber daya memori, serta meningkatkan kinerja pengumpulan data. |
Optimisasi | metrics_relabel dioptimalkan. Pemanfaatan CPU berkurang hingga 70%. |
Optimisasi | Logika pendengaran multi-tenansi Informer dioptimalkan untuk menghemat pemanfaatan CPU sebesar 20% dalam skenario multi-tenansi. |
Optimisasi | Alamat IP cache dapat digunakan secara otomatis jika CoreDNS gagal menyelesaikan nama domain secara real-time. Ini meningkatkan tingkat keberhasilan transmisi data. |
Optimisasi | Logika konfigurasi distribusi dan pengumpulan SendConfig dioptimalkan untuk meningkatkan stabilitas konfigurasi. |
Optimisasi | Kebijakan pra-pengambilan Master dioptimalkan untuk mengurangi overhead sumber daya Master, serta meningkatkan kemampuan penemuan layanan dan penjadwalan target Master. |
Optimisasi | Kontrol adaptif diimplementasikan pada paket data yang melebihi 1 MB dalam satu batch. Ini mengurangi kehilangan data yang disebabkan oleh batasan backend. |
Perbaikan Bug | Masalah bahwa beberapa ScrapeLoop Targets dikumpulkan secara berulang kali telah diperbaiki. |
Perbaikan Bug | Dalam skenario multi-tenansi, cache Label pod tidak diperbarui secara tepat waktu. Akibatnya, garis waktu duplikat dihasilkan. Masalah ini telah diperbaiki. |
Perbaikan Bug | Beberapa target terkait kesalahan kehabisan memori (OOM) atau restart replika tidak dikumpulkan. Masalah ini telah diperbaiki. |
Perbaikan Bug | Masalah parsing rahasia dan masalah transmisi Header remote write telah diperbaiki. |
Perbaikan Bug | Sesekali, Kubernetes-pods tidak dapat dimatikan. Masalah ini telah diperbaiki. |
Perbaikan Bug | Masalah bahwa parameter default global dan parameter external_labels tidak berlaku telah diperbaiki. Parameter dapat dimodifikasi. |
Risiko
Pembaruan ke Helm v1.1.17 atau Agen Prometheus v4.0.0 bersifat lossy. Data pemantauan mungkin terputus, terutama jika jumlah Targets dan Series yang dikumpulkan semakin besar. Estimasi waktu putusnya data berkisar antara 0 hingga 5 menit, tergantung pada kluster.
Sebelum memperbarui Helm atau Agen Prometheus, periksa parameter relevan untuk meminimalkan dampak pada data pemantauan kluster. Untuk informasi lebih lanjut, lihat bagian 1. Item Pemeriksaan Sebelum Pembaruan (Wajib).
Jika terjadi anomali setelah pembaruan Helm atau Agen Prometheus, segera selesaikan masalah tersebut. Untuk panduan pemeriksaan pasca-pembaruan, lihat bagian 3. Item Pemeriksaan Pasca-Pembaruan (Opsional). Untuk pemecahan masalah, lihat bagian FAQ. Jika masalah tetap ada, hubungi dukungan teknis (ID DingTalk: aliprometheus).
Metode Pembaruan
1. Item Pra-Pemeriksaan (Wajib)
Jika Anda memperbarui Helm dari versi sebelum 1.1.16 ke 1.1.17, beberapa parameter yang dimodifikasi tidak akan dipertahankan. Oleh karena itu, catat dan konfigurasikan ulang parameter tersebut secara manual.
Jika Anda memperbarui Helm dari versi 1.1.16 atau yang lebih baru ke 1.1.17, semua parameter akan dipertahankan. Ikuti langkah-langkah berikut untuk memeriksa parameter sebelum pembaruan:
Klik nama kluster. Di panel navigasi di sebelah kiri, pilih Workloads > Deployments. Atur parameter Namespace ke
arms-prom. Temukanarms-prometheus-ack-arms-prometheus, lalu pilih More > View in YAML di kolom Actions untuk melihat file YAML lengkap.Periksa parameter berikut:
spec.replicas: Jumlah replika. Helm v1.1.17 dan Agen Prometheus v4.0.0 menetapkan nilai default 1. Jika nilai saat ini juga 1, abaikan parameter ini.
args of spec.containers: Parameter startup. Parameter ini hanya tersedia dalam mode multi-tenansi. Jika Anda menentukan nilai kustom, pastikan untuk memasukkan nilai tersebut kembali setelah pembaruan.
tenant_userid
tenant_clusterid
tenant_token
spec.containers.resources.limits dan spec.containers.resources.requests: Batas CPU default adalah 3, dan batas memori adalah 4. Permintaan CPU default dan permintaan memori keduanya adalah 1.
Anda dapat memodifikasi nilai default, lalu mencatat dan mengonfigurasi ulang parameter yang dimodifikasi setelah pembaruan.
Jika Anda perlu memodifikasi dan mempertahankan parameter di atas, catat nilainya. Setelah memperbarui Helm atau Agen Prometheus, ikuti Langkah 2 untuk mendapatkan file YAML lengkap, modifikasi nilainya, lalu klik Update.
2. Prosedur
Disarankan untuk memperbarui versi Helm melalui Konsol ACK.
Masuk ke Konsol ACK.
Klik nama kluster. Di panel navigasi di sebelah kiri, pilih Operations > Add-ons. Klik tab Logs and Monitoring. Temukan ack-arms-prometheus dan klik Upgrade.
Setelah pembaruan selesai, pilih Operations > Prometheus Monitoring di panel navigasi di sebelah kiri. Klik Go to ARMS Prometheus di pojok kanan atas. Anda akan dialihkan ke dasbor instance Prometheus yang sesuai di konsol Managed Service for Prometheus.
Di panel navigasi di sebelah kiri, klik Settings. Di tab Settings, periksa apakah Helm telah diperbarui ke 1.1.17.
3. Item Pemeriksaan Pasca-Pembaruan (Opsional)
Masuk ke Konsol Managed Service for Prometheus.
Di panel navigasi di sebelah kiri, klik Instances.
Klik nama instance Prometheus. Di panel navigasi di sebelah kiri, klik Service Discovery. Klik tab Targets untuk memeriksa apakah pekerjaan koleksi selesai sesuai harapan.
Di panel navigasi di sebelah kiri, klik Settings. Di tab Self-Monitoring, klik View Grafana Dashboard. Periksa status Agen Prometheus dengan memeriksa item berikut: laju transmisi data, pengecualian saat pengiriman data, konsumsi sumber daya, dan jumlah replika.
Di tab Agent self-monitoring dari tab Self-Monitoring, Anda dapat melihat dasbor pemantauan diri Agen Managed Service for Prometheus.
Periksa status pekerjaan pengumpulan dengan memeriksa metrik dasar berikut: _arms/kubelet/cadvisor, _arms/kubelet/metric, _kube-state-metrics, dan node-exporter. Di pojok kanan atas halaman, pilih rentang waktu untuk memeriksa apakah pengecualian terjadi sebelum dan sesudah pembaruan.
FAQ
Mengapa jumlah replika yang berjalan aktual setelah pembaruan berbeda dari jumlah replika yang diharapkan?
Periksa apakah semua replika sedang berjalan. Jika satu atau lebih replika tertunda, Agen Prometheus tidak dapat bekerja sesuai harapan. Untuk melihat status replika, ikuti langkah-langkah berikut di Konsol ACK: Di panel navigasi di sebelah kiri halaman detail kluster, pilih Workloads > Deployments. Atur parameter Namespace ke arms-prom. Lalu, Anda dapat melihat status replika.
Mengapa agen ARMS mengonsumsi sejumlah besar memori dan sumber daya CPU setelah pembaruan?
Periksa apakah terjadi pengecualian saat data dikirim. Jika terjadi pengecualian, agen ARMS menyimpan data di memori, meningkatkan konsumsi sumber daya. Masuk ke Konsol ACK. Di panel navigasi di sebelah kiri halaman detail kluster, pilih Operations > Prometheus Monitoring. Di halaman Pemantauan Prometheus, klik tab Others lalu klik tab Prometheus Agent untuk melihat penggunaan memori dan pemanfaatan CPU.
Mengapa metrik dasar terputus atau tidak kontinu setelah pembaruan?
Jika metrik seperti node_***, container_***, kubelet_***, dan kube_*** terputus atau tidak kontinu, periksa apakah pesan kesalahan dilaporkan selama pekerjaan pengumpulan data. Anda dapat melihat status metrik ini di tab Targets dari halaman Service Discovery di Konsol Managed Service for Prometheus. Jika pesan kesalahan dilaporkan, hubungi dukungan teknis (ID DingTalk: aliprometheus).
Mengapa lalu lintas jarak jauh berkurang dan mengapa data remote write hilang?
Bidang write_relabel_configs dalam pengaturan remote write Agen Prometheus v4.0.0 berlaku secara otomatis. Namun, bidang ini tidak tersedia di versi sebelumnya. Jika Anda mengonfigurasi tindakan seperti drop dan keep, lalu lintas akan turun sampai batas tertentu. Anda dapat memodifikasi bidang ini sesuai kebutuhan bisnis. Klik Edit Prometheus.yaml di tab Settings dari halaman Settings di Konsol Managed Service for Prometheus. Di kotak dialog yang muncul, modifikasi bidang tersebut.