Pertimbangkan konsep pemantauan Kubernetes, berkenalan dengan alat Prometheus dan bercakap tentang amaran.
Topik pemantauan adalah besar, ia tidak boleh dibongkar dalam satu artikel. Tujuan teks ini adalah untuk memberikan gambaran keseluruhan tentang alat, konsep dan pendekatan.
Bahan artikel adalah picitan daripada . Jika anda ingin mengikuti kursus penuh - daftarlah untuk kursus .
Perkara yang dipantau dalam gugusan Kubernetes
pelayan fizikal. Jika gugusan Kubernetes digunakan pada pelayannya, anda perlu memantau kesihatan mereka. Zabbix mengendalikan tugas ini; jika anda bekerja dengannya, maka anda tidak perlu menolak, tidak akan ada konflik. Zabbixlah yang memantau keadaan pelayan kami.
Mari kita beralih kepada pemantauan di peringkat kluster.
Komponen Satah Kawalan: API, Penjadual dan lain-lain. Sekurang-kurangnya, anda perlu memastikan bahawa API pelayan atau etcd adalah lebih besar daripada 0. Etcd boleh mengembalikan banyak metrik: mengikut cakera di mana ia berputar, oleh kesihatan kluster etcdnya dan lain-lain.
buruh pelabuhan muncul lama dahulu dan semua orang menyedari masalahnya: banyak bekas menjana pembekuan dan masalah lain. Oleh itu, Docker sendiri, sebagai sistem, juga harus dikawal, sekurang-kurangnya untuk ketersediaan.
dns. Jika DNS terputus dalam kluster, maka keseluruhan perkhidmatan Discovery akan gugur selepasnya, panggilan dari pod ke pod akan berhenti berfungsi. Dalam amalan saya, tidak ada masalah seperti itu, tetapi ini tidak bermakna keadaan DNS tidak perlu dipantau. Kependaman permintaan dan beberapa metrik lain boleh dijejaki pada CoreDNS.
Masuk. Adalah perlu untuk mengawal ketersediaan kemasukan (termasuk Pengawal Ingress) sebagai pintu masuk ke projek.
Komponen utama kluster telah dibongkar - sekarang mari kita turun ke tahap abstraksi.
Nampaknya aplikasi berjalan dalam pod, yang bermaksud ia perlu dikawal, tetapi sebenarnya tidak. Pod bersifat sementara: hari ini ia dijalankan pada satu pelayan, esok pada pelayan yang lain; hari ini ada 10 daripadanya, esok 2. Oleh itu, tiada siapa yang memantau pod. Dalam seni bina perkhidmatan mikro, adalah lebih penting untuk mengawal ketersediaan aplikasi secara keseluruhan. Khususnya, semak ketersediaan titik akhir perkhidmatan: adakah apa-apa berfungsi? Jika permohonan itu tersedia, maka apa yang berlaku di belakangnya, berapa banyak replika sekarang - ini adalah soalan urutan kedua. Tidak perlu memantau keadaan individu.
Pada peringkat terakhir, anda perlu mengawal operasi aplikasi itu sendiri, mengambil metrik perniagaan: bilangan pesanan, tingkah laku pengguna dan sebagainya.
Prometheus
Sistem terbaik untuk memantau kluster ialah . Saya tidak tahu mana-mana alat yang boleh menandingi Prometheus dari segi kualiti dan kemudahan penggunaan. Ia bagus untuk infrastruktur yang fleksibel, jadi apabila mereka menyebut "pemantauan Kubernetes", mereka biasanya bermaksud Prometheus.
Terdapat beberapa pilihan untuk bermula dengan Prometheus: menggunakan Helm, anda boleh memasang Prometheus atau Operator Prometheus biasa.
- Prometheus biasa. Semuanya baik-baik saja dengannya, tetapi anda perlu mengkonfigurasi ConfigMap - sebenarnya, tulis fail konfigurasi berasaskan teks, seperti yang kami lakukan sebelum ini, sebelum seni bina perkhidmatan mikro.
- Prometheus Operator adalah sedikit lebih tersebar, sedikit lebih rumit dari segi logik dalaman, tetapi lebih mudah untuk bekerja dengannya: terdapat objek yang berasingan, abstraksi ditambah pada kluster, jadi mereka lebih mudah untuk dikawal dan dikonfigurasikan.
Untuk memahami produk, saya mengesyorkan memasang Prometheus biasa terlebih dahulu. Anda perlu mengkonfigurasi segala-galanya melalui konfigurasi, tetapi ini akan memberi manfaat: anda akan mengetahui apa yang dimiliki dan bagaimana ia dikonfigurasikan. Dalam Operator Prometheus, anda serta-merta meningkat kepada abstraksi yang lebih tinggi, walaupun anda juga boleh menyelidiki kedalaman jika anda mahu.
Prometheus disepadukan dengan baik dengan Kubernetes: ia boleh mengakses dan berinteraksi dengan Pelayan API.
Prometheus popular, itulah sebabnya sebilangan besar aplikasi dan bahasa pengaturcaraan menyokongnya. Sokongan diperlukan, kerana Prometheus mempunyai format metriknya sendiri, dan untuk memindahkannya, anda memerlukan sama ada perpustakaan di dalam aplikasi atau pengeksport sedia. Dan terdapat beberapa pengeksport sedemikian. Sebagai contoh, terdapat PostgreSQL Exporter: ia mengambil data daripada PostgreSQL dan menukarnya kepada format Prometheus supaya Prometheus boleh bekerja dengannya.
Seni bina Prometheus
Pelayan Prometheus adalah bahagian belakang, otak Prometheus. Metrik disimpan dan diproses di sini.
Metrik disimpan dalam pangkalan data siri masa (TSDB). TSDB bukanlah pangkalan data yang berasingan, tetapi pakej dalam bahasa Go yang dibenamkan dalam Prometheus. Secara kasarnya, semuanya dalam satu binari.
Jangan simpan data dalam TSDB untuk masa yang lama
Infrastruktur Prometheus tidak sesuai untuk penyimpanan metrik jangka panjang. Tempoh pengekalan lalai ialah 15 hari. Anda boleh melebihi had ini, tetapi perlu diingat: lebih banyak data yang anda simpan dalam TSDB dan lebih lama anda melakukannya, lebih banyak sumber yang akan digunakan. Menyimpan data sejarah dalam Prometheus dianggap amalan buruk.
Jika anda mempunyai trafik yang besar, bilangan metrik ialah ratusan ribu sesaat, maka adalah lebih baik untuk mengehadkan storannya mengikut ruang cakera atau mengikut tempoh. Biasanya, "data panas" disimpan dalam TSDB, metrik dalam beberapa jam sahaja. Untuk storan yang lebih lama, storan luaran digunakan dalam pangkalan data yang benar-benar sesuai untuk ini, contohnya, InfluxDB, ClickHouse, dan sebagainya. Saya melihat lebih banyak ulasan bagus tentang ClickHouse.
Pelayan Prometheus berfungsi pada model tarik: dia pergi untuk metrik ke titik akhir yang kami berikan kepadanya. Mereka berkata: "pergi ke Pelayan API", dan dia pergi ke sana setiap bilangan ke-n saat dan mengambil metrik.
Untuk objek dengan jangka hayat yang singkat (kerja atau tugas cron) yang boleh muncul antara tempoh mengikis, terdapat komponen Pushgateway. Metrik daripada objek jangka pendek ditolak ke dalamnya: tugas telah meningkat, melakukan tindakan, menghantar metrik ke Pushgateway dan selesai. Selepas beberapa ketika, Prometheus akan turun mengikut rentaknya sendiri dan mengambil metrik ini daripada Pushgateway.
Untuk mengkonfigurasi pemberitahuan dalam Prometheus terdapat komponen yang berasingan - Pengurus amaran. Dan peraturan amaran. Sebagai contoh, anda perlu membuat makluman jika API pelayan ialah 0. Apabila acara berlaku, makluman dihantar kepada pengurus makluman untuk penghantaran selanjutnya. Pengurus makluman mempunyai tetapan penghalaan yang agak fleksibel: satu kumpulan makluman boleh dihantar ke sembang telegram pentadbir, satu lagi ke sembang pembangun dan satu pertiga ke sembang pekerja infrastruktur. Pemberitahuan boleh dihantar ke Slack, Telegram, e-mel dan saluran lain.
Dan akhirnya, saya akan memberitahu anda tentang ciri pembunuh Prometheus - Discovering. Apabila bekerja dengan Prometheus, anda tidak perlu menentukan alamat objek tertentu untuk pemantauan, cukup untuk menetapkan jenisnya. Iaitu, anda tidak perlu menulis "di sini adalah alamat IP, di sini adalah port - monitor", sebaliknya, anda perlu menentukan dengan prinsip apa untuk mencari objek ini (sasaran - matlamat). Prometheus sendiri, bergantung pada objek yang sedang aktif, menarik yang diperlukan dan menambahkannya ke pemantauan.
Pendekatan ini sesuai dengan struktur Kubernetes, di mana segala-galanya juga terapung: hari ini terdapat 10 pelayan, esok 3. Untuk tidak menentukan alamat IP pelayan setiap kali, mereka menulis sekali cara mencarinya - dan Discovering akan melakukannya .
Bahasa Prometheus dipanggil PromQL. Menggunakan bahasa ini, anda boleh mendapatkan nilai metrik tertentu dan kemudian menukarnya, membina pengiraan analitik berdasarkannya.
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)Antara muka web Prometheus
Prometheus mempunyai antara muka webnya yang agak minimalis. Hanya sesuai untuk nyahpepijat atau demonstrasi.
Dalam baris Ungkapan, anda boleh menulis pertanyaan dalam bahasa PromQL.
Tab Makluman mengandungi peraturan makluman dan ia mempunyai tiga status:
- tidak aktif - jika amaran tidak aktif pada masa ini, iaitu, semuanya baik-baik saja dengannya, dan ia tidak berfungsi;
- belum selesai - ini adalah jika amaran berfungsi, tetapi penghantaran belum berlalu. Kelewatan ditetapkan untuk mengimbangi rangkaian berkelip: jika perkhidmatan yang ditentukan telah meningkat dalam masa seminit, maka penggera tidak seharusnya dibunyikan lagi;
- menembak ialah status ketiga apabila amaran menyala dan menghantar mesej.
Dalam menu Status anda akan mendapat akses kepada maklumat tentang apa itu Prometheus. Terdapat juga peralihan kepada sasaran (sasaran), yang kita bincangkan di atas.
Untuk gambaran keseluruhan yang lebih terperinci mengenai antara muka Prometheus, lihat .
Integrasi dengan Grafana
Dalam antara muka web Prometheus, anda tidak akan menemui graf yang cantik dan mudah difahami dari mana anda boleh membuat kesimpulan tentang keadaan kluster. Untuk membinanya, Prometheus disepadukan dengan Grafana. Kami mendapat papan pemuka sedemikian.
Menyediakan integrasi Prometheus dan Grafana tidak sukar sama sekali, anda boleh mendapatkan arahan dalam dokumentasi: Baiklah, saya akan berakhir dengan ini.
Dalam artikel berikut, kami akan meneruskan topik pemantauan: kami akan bercakap tentang mengumpul dan menganalisis log menggunakan Grafana Loki dan alat alternatif.
Pengarang: Marcel Ibraev, pentadbir Kubernetes bertauliah, berlatih jurutera dalam syarikat itu , penceramah dan pembangun kursus Slurm.
Sumber: www.habr.com
