Catatan. terjemah: Kami membentangkan kepada perhatian anda butiran teknikal tentang sebab masa henti baru-baru ini dalam perkhidmatan awan yang diselenggarakan oleh pencipta Grafana. Ini adalah contoh klasik tentang cara ciri baharu dan kelihatan sangat berguna yang direka bentuk untuk meningkatkan kualiti infrastruktur... boleh menyebabkan kemudaratan jika anda tidak menyediakan pelbagai nuansa penerapannya dalam realiti pengeluaran. Sangat bagus apabila bahan seperti ini muncul yang membolehkan anda belajar bukan sahaja daripada kesilapan anda. Butiran ada dalam terjemahan teks ini daripada naib presiden produk daripada Grafana Labs.
Pada hari Jumaat, 19 Julai, perkhidmatan Hosted Prometheus di Grafana Cloud berhenti berfungsi selama kira-kira 30 minit. Saya memohon maaf kepada semua pelanggan yang terjejas akibat gangguan tersebut. Tugas kami adalah untuk menyediakan alat pemantauan yang anda perlukan, dan kami faham bahawa tidak mempunyainya boleh menyukarkan hidup anda. Kami memandang serius kejadian ini. Nota ini menerangkan perkara yang berlaku, cara kami bertindak balas dan perkara yang kami lakukan untuk memastikan perkara itu tidak berlaku lagi.
prasejarah
Perkhidmatan Prometheus Hosted Cloud Grafana adalah berdasarkan β Projek CNCF untuk mencipta perkhidmatan Prometheus multi-penyewa yang boleh berskala mendatar, sangat tersedia. Seni bina Cortex terdiri daripada satu set perkhidmatan mikro individu, setiap satunya menjalankan fungsinya sendiri: replikasi, penyimpanan, pertanyaan, dsb. Korteks sedang dalam pembangunan aktif dan sentiasa menambah ciri baharu dan meningkatkan prestasi. Kami kerap menggunakan keluaran Cortex baharu ke kluster supaya pelanggan boleh memanfaatkan ciri ini - mujurlah, Cortex boleh dikemas kini tanpa masa henti.
Untuk kemas kini yang lancar, perkhidmatan Ingester Cortex memerlukan replika Ingester tambahan semasa proses kemas kini. (Catatan. terjemah: - komponen asas Korteks. Tugasnya adalah untuk mengumpul aliran sampel yang berterusan, mengumpulkannya ke dalam ketulan Prometheus dan menyimpannya dalam pangkalan data seperti DynamoDB, BigTable atau Cassandra.) Ini membolehkan Ingesters lama memajukan data semasa kepada Ingesters baharu. Perlu diingat bahawa Ingesters memerlukan sumber. Untuk mereka berfungsi, anda perlu mempunyai 4 teras dan 15 GB memori setiap pod, i.e. 25% daripada kuasa pemprosesan dan memori mesin asas dalam kes kelompok Kubernetes kami. Secara umum, kami biasanya mempunyai lebih banyak sumber yang tidak digunakan dalam gugusan daripada 4 teras dan memori 15 GB, jadi kami boleh memutarkan penyedut tambahan ini dengan mudah semasa peningkatan.
Walau bagaimanapun, selalunya berlaku bahawa semasa operasi biasa tidak ada mesin yang mempunyai 25% sumber yang tidak digunakan ini. Ya, kami tidak berusaha: CPU dan memori akan sentiasa berguna untuk proses lain. Untuk menyelesaikan masalah ini, kami memutuskan untuk menggunakan . Ideanya adalah untuk memberi Ingesters keutamaan yang lebih tinggi daripada perkhidmatan mikro (tanpa negara) lain. Apabila kami perlu menjalankan Ingester tambahan (N+1), kami menggantikan pod lain yang lebih kecil buat sementara waktu. Pod ini dipindahkan ke sumber percuma pada mesin lain, meninggalkan "lubang" yang cukup besar untuk menjalankan Ingester tambahan.
Pada hari Khamis, 18 Julai, kami melancarkan empat tahap keutamaan baharu kepada kluster kami: kritikal, tinggi, sederhana ΠΈ rendah. Mereka telah diuji pada kluster dalaman tanpa trafik pelanggan selama kira-kira satu minggu. Secara lalai, pod tanpa keutamaan tertentu diterima sederhana keutamaan, kelas telah ditetapkan untuk Ingesters dengan tinggi keutamaan. kritikal telah dikhaskan untuk pemantauan (Prometheus, Alertmanager, pengeksport nod, kube-state-metrics, dll.). Konfigurasi kami terbuka, dan anda boleh melihat PR .
Kemalangan
Pada hari Jumaat, 19 Julai, salah seorang jurutera melancarkan kluster Cortex khusus baharu untuk pelanggan yang besar. Konfigurasi untuk kluster ini tidak termasuk keutamaan pod baharu, jadi semua pod baharu diberikan keutamaan lalai - sederhana.
Kluster Kubernetes tidak mempunyai sumber yang mencukupi untuk kluster Korteks baharu dan kluster Korteks pengeluaran sedia ada tidak dikemas kini (Ingesters dibiarkan tanpa tinggi keutamaan). Oleh kerana Ingesters kluster baharu secara lalai mempunyai sederhana keutamaan, dan pod sedia ada dalam pengeluaran berfungsi tanpa keutamaan sama sekali, Ingesters kluster baharu menggantikan Ingesters daripada kluster pengeluaran Cortex sedia ada.
ReplicaSet untuk Ingester yang diusir dalam kluster pengeluaran mengesan pod yang diusir dan mencipta yang baharu untuk mengekalkan bilangan salinan yang ditentukan. Pod baharu telah ditetapkan secara lalai sederhana keutamaan, dan seorang lagi "lama" Ingester dalam pengeluaran kehilangan sumbernya. Hasilnya ialah proses runtuhan salji, yang membawa kepada anjakan semua pod daripada Ingester untuk kelompok pengeluaran Cortex.
Ingester adalah stateful dan menyimpan data untuk 12 jam sebelumnya. Ini membolehkan kami memampatkannya dengan lebih cekap sebelum menulisnya ke storan jangka panjang. Untuk mencapai matlamat ini, serpihan Cortex data merentas siri menggunakan Jadual Hash Teragih (DHT) dan mereplikasi setiap siri merentas tiga Ingester menggunakan ketekalan kuorum gaya Dynamo. Korteks tidak menulis data kepada Ingesters yang dilumpuhkan. Oleh itu, apabila sebilangan besar Ingester meninggalkan DHT, Cortex tidak dapat menyediakan replikasi yang mencukupi bagi entri, dan mereka ranap.
Pengesanan dan Pemulihan
Pemberitahuan Prometheus baharu berdasarkan "belanjawan ralat" (berasaskan belanjawan ralat β butiran akan muncul dalam artikel akan datang) mula membunyikan penggera 4 minit selepas permulaan penutupan. Dalam tempoh lima minit seterusnya, kami menjalankan beberapa diagnostik dan meningkatkan kluster asas Kubernetes untuk menjadi hos kepada kluster pengeluaran baharu dan sedia ada.
Selepas lima minit lagi, Ingesters lama berjaya menulis data mereka, yang baharu dimulakan, dan gugusan Cortex tersedia semula.
10 minit lagi dibelanjakan untuk mendiagnosis dan membetulkan ralat di luar ingatan (OOM) daripada proksi terbalik pengesahan yang terletak di hadapan Cortex. Ralat OOM disebabkan oleh peningkatan sepuluh kali ganda dalam QPS (kami percaya disebabkan oleh permintaan yang terlalu agresif daripada pelayan Prometheus pelanggan).
Selepas
Jumlah masa rehat ialah 26 minit. Tiada data yang hilang. Ingesters telah berjaya memuatkan semua data dalam memori ke dalam storan jangka panjang. Semasa penutupan, pelayan Prometheus pelanggan penimbal dipadamkan (jauh) rakaman menggunakan berdasarkan WAL (dikarang oleh daripada Grafana Labs) dan mengulangi penulisan yang gagal selepas ranap sistem.
Operasi tulis kelompok pengeluaran
Penemuan
Adalah penting untuk belajar daripada kejadian ini dan mengambil langkah-langkah yang perlu untuk mengelakkan kejadian itu berulang.
Di belakang, kita tidak sepatutnya menetapkan lalai sederhana keutamaan sehingga semua Ingester dalam pengeluaran telah menerima tinggi keutamaan. Di samping itu, adalah perlu untuk menjaga mereka terlebih dahulu tinggi keutamaan. Semuanya telah ditetapkan sekarang. Kami berharap pengalaman kami akan membantu organisasi lain mempertimbangkan untuk menggunakan keutamaan pod dalam Kubernetes.
Kami akan menambah tahap kawalan tambahan ke atas penggunaan mana-mana objek tambahan yang konfigurasinya global kepada kluster. Mulai sekarang, perubahan tersebut akan dinilai bΠΎlebih ramai orang. Selain itu, pengubahsuaian yang menyebabkan ranap sistem dianggap terlalu kecil untuk dokumen projek yang berasingan - ia hanya dibincangkan dalam isu GitHub. Mulai sekarang, semua perubahan pada konfigurasi akan disertakan dengan dokumentasi projek yang sesuai.
Akhir sekali, kami akan mengautomasikan saiz semula proksi songsang pengesahan untuk mengelakkan beban berlebihan OOM yang kami saksikan, dan akan menyemak tetapan lalai Prometheus yang berkaitan dengan sandaran dan penskalaan untuk mengelakkan isu serupa pada masa hadapan.
Kegagalan itu juga mempunyai beberapa akibat positif: setelah menerima sumber yang diperlukan, Cortex pulih secara automatik tanpa campur tangan tambahan. Kami juga mendapat pengalaman berharga bekerja dengannya - sistem pengagregatan log baharu kami - yang membantu memastikan semua Ingester berkelakuan betul semasa dan selepas kegagalan.
PS daripada penterjemah
Baca juga di blog kami:
- «»;
- «»;
- «»;
- Β«'.
Sumber: www.habr.com