Catatan. terjemahan: Untuk perhatian Anda, kami sampaikan detail teknis tentang alasan downtime baru-baru ini pada layanan cloud yang dikelola oleh pembuat Grafana. Ini adalah contoh klasik tentang bagaimana fitur baru dan tampaknya sangat berguna yang dirancang untuk meningkatkan kualitas infrastruktur... dapat menimbulkan kerugian jika Anda tidak memperhitungkan berbagai nuansa penerapannya dalam realitas produksi. Sangat menyenangkan bila muncul materi seperti ini yang memungkinkan Anda belajar tidak hanya dari kesalahan Anda. Detailnya ada dalam terjemahan teks ini dari wakil presiden produk dari Grafana Labs.
Pada hari Jumat, 19 Juli, layanan Hosted Prometheus di Grafana Cloud berhenti berfungsi selama kurang lebih 30 menit. Saya mohon maaf kepada semua pelanggan yang terkena dampak pemadaman ini. Tugas kami adalah menyediakan alat pemantauan yang Anda perlukan, dan kami memahami bahwa tidak tersedianya alat tersebut dapat membuat hidup Anda lebih sulit. Kami menanggapi kejadian ini dengan sangat serius. Catatan ini menjelaskan apa yang terjadi, bagaimana kami merespons, dan apa yang kami lakukan untuk memastikan hal serupa tidak terjadi lagi.
prasejarah
Layanan Grafana Cloud Hosted Prometheus didasarkan pada β Proyek CNCF untuk menciptakan layanan Prometheus multi-penyewa yang dapat diskalakan secara horizontal, sangat tersedia. Arsitektur Cortex terdiri dari sekumpulan layanan mikro individual, yang masing-masing menjalankan fungsinya sendiri: replikasi, penyimpanan, kueri, dll. Cortex sedang dalam pengembangan aktif dan terus menambahkan fitur baru serta meningkatkan kinerja. Kami secara teratur menyebarkan rilis Cortex baru ke cluster sehingga pelanggan dapat memanfaatkan fitur-fitur ini - untungnya, Cortex dapat diperbarui tanpa downtime.
Untuk pembaruan yang lancar, layanan Ingester Cortex memerlukan replika Ingester tambahan selama proses pembaruan. (Catatan. terjemahan: - komponen dasar Korteks. Tugasnya adalah mengumpulkan aliran sampel secara konstan, mengelompokkannya ke dalam potongan Prometheus dan menyimpannya dalam database seperti DynamoDB, BigTable, atau Cassandra.) Hal ini memungkinkan Ingester lama meneruskan data saat ini ke Ingester baru. Perlu dicatat bahwa Ingester membutuhkan sumber daya. Agar dapat berfungsi, Anda harus memiliki 4 core dan memori 15 GB per pod, mis. 25% dari kekuatan pemrosesan dan memori mesin dasar dalam kasus cluster Kubernetes kami. Secara umum, kami biasanya memiliki lebih banyak sumber daya yang tidak terpakai di cluster daripada 4 inti dan memori 15 GB, sehingga kami dapat dengan mudah menjalankan ingester tambahan ini selama peningkatan.
Namun, sering kali selama operasi normal tidak ada mesin yang memiliki 25% sumber daya yang tidak terpakai. Ya, kami bahkan tidak berusaha: CPU dan memori akan selalu berguna untuk proses lainnya. Untuk mengatasi masalah ini, kami memutuskan untuk menggunakan . Idenya adalah untuk memberikan prioritas yang lebih tinggi kepada Ingesters dibandingkan layanan mikro (tanpa kewarganegaraan) lainnya. Saat kami perlu menjalankan Ingester tambahan (N+1), kami akan menggantikan pod lain yang lebih kecil untuk sementara. Pod ini ditransfer ke sumber daya gratis di mesin lain, meninggalkan βlubangβ yang cukup besar untuk menjalankan Ingester tambahan.
Pada hari Kamis, 18 Juli, kami meluncurkan empat tingkat prioritas baru pada klaster kami: kritis, tinggi, sedang ΠΈ rendah. Mereka diuji pada cluster internal tanpa lalu lintas klien selama sekitar satu minggu. Secara default, pod tanpa prioritas tertentu akan diterima sedang prioritas, kelas ditetapkan untuk Ingesters dengan tinggi prioritas. Kritis dicadangkan untuk pemantauan (Prometheus, Alertmanager, node-exporter, kube-state-metrics, dll.). Konfigurasi kami terbuka, dan Anda dapat melihat PR-nya .
Kecelakaan
Pada hari Jumat, 19 Juli, salah satu insinyur meluncurkan cluster Cortex khusus baru untuk klien besar. Konfigurasi untuk cluster ini tidak menyertakan prioritas pod baru, sehingga semua pod baru diberi prioritas default - sedang.
Cluster Kubernetes tidak memiliki sumber daya yang cukup untuk cluster Cortex baru, dan cluster Cortex produksi yang ada tidak diperbarui (Ingester dibiarkan tanpa tinggi prioritas). Karena Ingester dari cluster baru secara default memiliki sedang prioritas, dan pod yang ada dalam produksi bekerja tanpa prioritas sama sekali, Ingester dari cluster baru menggantikan Ingester dari cluster produksi Cortex yang ada.
ReplicaSet untuk Ingester yang dikeluarkan di kluster produksi mendeteksi pod yang dikeluarkan dan membuat yang baru untuk mempertahankan jumlah salinan yang ditentukan. Pod baru ditetapkan secara default sedang prioritasnya, dan Ingester βlamaβ lainnya yang sedang berproduksi kehilangan sumber dayanya. Hasilnya adalah proses longsoran salju, yang menyebabkan perpindahan semua pod dari kluster produksi Ingester ke Cortex.
Ingester bersifat stateful dan menyimpan data selama 12 jam sebelumnya. Hal ini memungkinkan kami mengompresinya dengan lebih efisien sebelum menyimpannya ke penyimpanan jangka panjang. Untuk mencapai hal ini, Cortex membagi data ke seluruh rangkaian menggunakan Tabel Hash Terdistribusi (DHT) dan mereplikasi setiap rangkaian di tiga Ingester menggunakan konsistensi kuorum gaya Dynamo. Cortex tidak menulis data ke Ingester yang dinonaktifkan. Jadi, ketika sejumlah besar Ingester meninggalkan DHT, Cortex tidak dapat menyediakan replikasi entri yang memadai, dan entri tersebut mogok.
Deteksi dan Remediasi
Pemberitahuan Prometheus baru berdasarkan "anggaran kesalahan" (berbasis kesalahan anggaran β detailnya akan muncul di artikel mendatang) mulai membunyikan alarm 4 menit setelah dimulainya pematian. Selama sekitar lima menit berikutnya, kami menjalankan beberapa diagnostik dan meningkatkan skala klaster Kubernetes yang mendasarinya untuk menampung klaster produksi baru dan yang sudah ada.
Setelah lima menit berikutnya, Ingester lama berhasil menulis datanya, yang baru dimulai, dan cluster Cortex tersedia kembali.
10 menit lainnya dihabiskan untuk mendiagnosis dan memperbaiki kesalahan kehabisan memori (OOM) dari proxy terbalik otentikasi yang terletak di depan Cortex. Kesalahan OOM disebabkan oleh peningkatan QPS sepuluh kali lipat (kami yakin karena permintaan yang terlalu agresif dari server Prometheus klien).
Buntut
Total waktu henti adalah 26 menit. Tidak ada data yang hilang. Ingester telah berhasil memuat semua data dalam memori ke dalam penyimpanan jangka panjang. Selama penutupan, buffer server klien Prometheus dihapus (terpencil) rekaman menggunakan berdasarkan WAL (ditulis oleh dari Grafana Labs) dan mengulangi penulisan yang gagal setelah crash.
Operasi penulisan cluster produksi
Temuan
Penting untuk mengambil pelajaran dari kejadian ini dan mengambil langkah-langkah yang diperlukan untuk menghindari terulangnya kejadian ini.
Kalau dipikir-pikir, kita seharusnya tidak menetapkan default sedang prioritas sampai semua Ingester dalam produksi telah menerima tinggi Sebuah prioritas. Selain itu, mereka perlu dirawat terlebih dahulu tinggi prioritas. Semuanya sudah diperbaiki sekarang. Kami berharap pengalaman kami dapat membantu organisasi lain mempertimbangkan penggunaan prioritas pod di Kubernetes.
Kami akan menambahkan tingkat kontrol tambahan atas penerapan objek tambahan apa pun yang konfigurasinya bersifat global ke cluster. Mulai sekarang, perubahan tersebut akan dinilai bΠΎlebih banyak orang. Selain itu, modifikasi yang menyebabkan kerusakan dianggap terlalu kecil untuk dokumen proyek terpisah - hanya dibahas dalam masalah GitHub. Mulai sekarang, semua perubahan konfigurasi tersebut akan disertai dengan dokumentasi proyek yang sesuai.
Terakhir, kami akan mengotomatiskan pengubahan ukuran proxy balik autentikasi untuk mencegah kelebihan beban OOM yang kami saksikan, dan akan meninjau pengaturan default Prometheus terkait dengan fallback dan penskalaan untuk mencegah masalah serupa di masa mendatang.
Kegagalan tersebut juga memiliki beberapa konsekuensi positif: setelah menerima sumber daya yang diperlukan, Cortex secara otomatis pulih tanpa intervensi tambahan. Kami juga memperoleh pengalaman berharga bekerja dengannya - sistem agregasi log baru kami - yang membantu memastikan bahwa semua Ingester berperilaku baik selama dan setelah kegagalan.
PS dari penerjemah
Baca juga di blog kami:
- «»;
- «»;
- «»;
- Β«'.
Sumber: www.habr.com