Memantau Klaster Kubernetes: Gambaran Umum dan Pengantar Prometheus

Pertimbangkan konsep pemantauan Kubernetes, kenali alat Prometheus, dan bahas tentang peringatan.

Topik pemantauan sangat banyak dan tidak dapat dibongkar dalam satu artikel. Tujuan dari teks ini adalah untuk memberikan gambaran umum tentang alat, konsep dan pendekatan.

Bahan artikelnya adalah pemerasan dari kuliah terbuka sekolah "Slurm". Jika Anda ingin mengambil kursus penuh - daftarlah untuk kursus tersebut Infrastruktur pemantauan dan logging di Kubernetes.

Apa yang dipantau di cluster Kubernetes

server fisik. Jika cluster Kubernetes di-deploy di servernya, Anda perlu memantau kesehatannya. Zabbix menangani tugas ini; jika Anda bekerja dengannya, maka Anda tidak perlu menolak, tidak akan ada konflik. Zabbix-lah yang memantau keadaan server kami.

Mari beralih ke pemantauan di tingkat cluster.

Komponen Bidang Kontrol: API, Penjadwal, dan lainnya. Minimal, Anda perlu memastikan bahwa API server atau etcd lebih besar dari 0. Etcd dapat mengembalikan banyak metrik: berdasarkan disk tempat ia berputar, berdasarkan kesehatan cluster etcd, dan lain-lain.

Buruh pelabuhan muncul sejak lama dan semua orang sangat menyadari masalahnya: banyak container menyebabkan macet dan masalah lainnya. Oleh karena itu, Docker sendiri sebagai sebuah sistem juga harus dikontrol, setidaknya untuk ketersediaannya.

dns. Jika DNS di cluster tidak berfungsi, maka seluruh layanan Discovery akan mati setelahnya, panggilan dari pod ke pod akan berhenti berfungsi. Dalam praktik saya, tidak ada masalah seperti itu, tetapi ini tidak berarti bahwa keadaan DNS tidak perlu dipantau. Latensi permintaan dan beberapa metrik lainnya dapat dilacak di CoreDNS.

Masuknya. Penting untuk mengontrol ketersediaan ingress (termasuk Ingress Controller) sebagai titik masuk ke proyek.

Komponen utama cluster telah dibongkar - sekarang mari kita turun ke tingkat abstraksi.

Tampaknya aplikasi berjalan di pod, yang berarti aplikasi tersebut perlu dikontrol, namun kenyataannya tidak. Pod bersifat sementara: hari ini dijalankan di satu server, besok di server lain; hari ini ada 10, besok 2. Oleh karena itu, tidak ada yang memantau pod. Dalam arsitektur layanan mikro, yang lebih penting adalah mengontrol ketersediaan aplikasi secara keseluruhan. Secara khusus, periksa ketersediaan titik akhir layanan: apakah ada yang berfungsi? Jika aplikasinya tersedia, lalu apa yang terjadi di baliknya, berapa banyak replikanya sekarang - ini adalah pertanyaan tingkat kedua. Tidak perlu memantau kejadian satu per satu.

Pada tingkat terakhir, Anda perlu mengontrol pengoperasian aplikasi itu sendiri, mengambil metrik bisnis: jumlah pesanan, perilaku pengguna, dan sebagainya.

Prometheus

Sistem terbaik untuk memantau cluster adalah Prometheus. Saya tidak tahu alat apa pun yang dapat menandingi Prometheus dalam hal kualitas dan kemudahan penggunaan. Ini bagus untuk infrastruktur yang fleksibel, jadi ketika mereka mengatakan “pemantauan Kubernetes”, yang mereka maksud biasanya adalah Prometheus.

Ada beberapa opsi untuk memulai Prometheus: menggunakan Helm, Anda dapat menginstal Prometheus atau Operator Prometheus biasa.

1. Prometheus biasa. Semuanya baik-baik saja dengannya, tetapi Anda perlu mengkonfigurasi ConfigMap - sebenarnya, menulis file konfigurasi berbasis teks, seperti yang kami lakukan sebelumnya, sebelum arsitektur layanan mikro.
2. Operator Prometheus sedikit lebih tersebar, sedikit lebih rumit dalam hal logika internal, tetapi lebih mudah untuk bekerja dengannya: ada objek terpisah, abstraksi ditambahkan ke cluster, sehingga lebih nyaman untuk dikontrol dan dikonfigurasi.

Untuk memahami produknya, saya sarankan menginstal Prometheus biasa terlebih dahulu. Anda harus mengonfigurasi semuanya melalui konfigurasi, tetapi ini akan bermanfaat: Anda akan mengetahui apa yang termasuk dalam apa dan bagaimana konfigurasinya. Di Operator Prometheus, Anda segera naik ke abstraksi yang lebih tinggi, meskipun Anda juga dapat mempelajari lebih dalam jika Anda mau.

Prometheus terintegrasi dengan baik dengan Kubernetes: ia dapat mengakses dan berinteraksi dengan Server API.

Prometheus populer, itulah sebabnya banyak aplikasi dan bahasa pemrograman mendukungnya. Dukungan diperlukan, karena Prometheus memiliki format metriknya sendiri, dan untuk mentransfernya, Anda memerlukan perpustakaan di dalam aplikasi atau eksportir yang sudah jadi. Dan eksportir seperti itu cukup banyak. Misalnya, ada Pengekspor PostgreSQL: ia mengambil data dari PostgreSQL dan mengonversinya ke format Prometheus sehingga Prometheus dapat bekerja dengannya.

Arsitektur Prometheus

Server Prometheus adalah bagian belakang, otak Prometheus. Metrik disimpan dan diproses di sini.

Metrik disimpan dalam database deret waktu (TSDB). TSDB bukanlah database terpisah, melainkan sebuah paket dalam bahasa Go yang tertanam di Prometheus. Secara kasar, semuanya ada dalam satu biner.

Jangan menyimpan data di TSDB dalam waktu lama

Infrastruktur Prometheus tidak cocok untuk penyimpanan metrik jangka panjang. Periode retensi default adalah 15 hari. Anda dapat melampaui batas ini, namun perlu diingat: semakin banyak data yang Anda simpan di TSDB dan semakin lama Anda melakukannya, semakin banyak sumber daya yang akan dikonsumsi. Menyimpan data historis di Prometheus dianggap praktik buruk.

Jika Anda memiliki lalu lintas yang besar, jumlah metriknya ratusan ribu per detik, lebih baik batasi penyimpanannya berdasarkan ruang disk atau periode. Biasanya, “data panas” disimpan di TSDB, metrik hanya dalam beberapa jam. Untuk penyimpanan lebih lama, digunakan penyimpanan eksternal pada database yang memang cocok untuk itu, misalnya InfluxDB, ClickHouse, dan sebagainya. Saya melihat lebih banyak ulasan bagus tentang ClickHouse.

Server Prometheus berfungsi pada model tersebut menarik: dia mencari metrik ke titik akhir yang kami berikan kepadanya. Mereka berkata: "pergi ke Server API", dan dia pergi ke sana setiap beberapa detik dan mengambil metriknya.

Untuk objek dengan masa hidup pendek (tugas atau tugas cron) yang dapat muncul di antara periode pengikisan, terdapat komponen Pushgateway. Metrik dari objek jangka pendek dimasukkan ke dalamnya: pekerjaan telah meningkat, melakukan tindakan, mengirim metrik ke Pushgateway, dan selesai. Setelah beberapa saat, Prometheus akan mengambil langkahnya sendiri dan mengambil metrik ini dari Pushgateway.

Untuk mengonfigurasi notifikasi di Prometheus ada komponen terpisah - Manajer peringatan. Dan aturan peringatan. Misalnya, Anda perlu membuat peringatan jika API server adalah 0. Saat peristiwa terjadi, peringatan diteruskan ke manajer peringatan untuk pengiriman lebih lanjut. Manajer peringatan memiliki pengaturan perutean yang cukup fleksibel: satu kelompok peringatan dapat dikirim ke obrolan telegram admin, kelompok lainnya ke obrolan pengembang, dan kelompok ketiga ke obrolan pekerja infrastruktur. Notifikasi dapat dikirim ke Slack, Telegram, email, dan saluran lainnya.

Dan terakhir, saya akan memberi tahu Anda tentang fitur pembunuh Prometheus - Menemukan. Saat bekerja dengan Prometheus, Anda tidak perlu menentukan alamat spesifik objek untuk pemantauan, cukup mengatur tipenya. Artinya, Anda tidak perlu menulis "ini alamat IP, ini port - monitor", sebagai gantinya, Anda perlu menentukan prinsip apa untuk menemukan objek-objek ini (target - sasaran). Prometheus sendiri, bergantung pada objek mana yang sedang aktif, mengambil objek yang diperlukan dan menambahkannya ke pemantauan.

Pendekatan ini sangat cocok dengan struktur Kubernetes, di mana semuanya juga mengambang: hari ini ada 10 server, besok 3. Agar tidak menentukan alamat IP server setiap kali, mereka menulis sekali cara menemukannya - dan Discovering akan melakukannya .

Bahasa Prometheus disebut PromQL. Dengan menggunakan bahasa ini, Anda bisa mendapatkan nilai metrik tertentu dan kemudian mengonversinya, membuat perhitungan analitis berdasarkan metrik tersebut.

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

Antarmuka web Prometheus

Prometheus memiliki antarmuka webnya sendiri yang cukup minimalis. Hanya cocok untuk debug atau demonstrasi.

Di baris Ekspresi, Anda bisa menulis kueri dalam bahasa PromQL.

Tab Peringatan berisi aturan pemberitahuan, dan aturan tersebut memiliki tiga status:

1. tidak aktif - jika peringatan tidak aktif saat ini, artinya semuanya baik-baik saja, dan tidak berfungsi;
2. tertunda - ini jika peringatan berhasil, tetapi pengiriman belum selesai. Penundaan diatur untuk mengkompensasi kedipan jaringan: jika layanan yang ditentukan telah meningkat dalam satu menit, maka alarm belum berbunyi;
3. menyala adalah status ketiga ketika peringatan menyala dan mengirim pesan.

Pada menu Status Anda akan menemukan akses informasi tentang apa itu Prometheus. Ada juga transisi ke target (target) yang telah kita bicarakan di atas.

Untuk ikhtisar lebih rinci tentang antarmuka Prometheus, lihat dalam kuliah Slurm tentang pemantauan cluster Kubernetes.

Integrasi dengan Grafana

Di antarmuka web Prometheus, Anda tidak akan menemukan grafik yang indah dan mudah dipahami yang dapat digunakan untuk menarik kesimpulan tentang status cluster. Untuk membangunnya, Prometheus terintegrasi dengan Grafana. Kami mendapatkan dasbor seperti itu.

Menyiapkan integrasi Prometheus dan Grafana sama sekali tidak sulit, Anda dapat menemukan petunjuk di dokumentasi: DUKUNGAN GRAFANA UNTUK PROMETHEUSBaiklah, saya akan mengakhirinya dengan ini.

Pada artikel berikut, kami akan melanjutkan topik pemantauan: kami akan membahas tentang pengumpulan dan analisis log menggunakan Grafana Loki dan alat alternatif.

Penulis: Marcel Ibraev, administrator Kubernetes bersertifikat, teknisi praktik di perusahaan Southbridge, pembicara dan pengembang kursus Slurm.

Sumber: www.habr.com