Not. tercüme: Grafana'nın yaratıcıları tarafından sağlanan bulut hizmetindeki son dönemdeki kesintilerin nedenlerine ilişkin teknik detayları dikkatinize sunuyoruz. Bu, altyapının kalitesini artırmak için tasarlanmış yeni ve görünüşte son derece yararlı bir özelliğin, üretim gerçeklerindeki uygulamasının sayısız nüansını sağlamazsanız nasıl zarar verebileceğinin klasik bir örneğidir. Sadece hatalarınızdan ders çıkarmanıza olanak tanıyan bunun gibi materyallerin ortaya çıkması harika. Ayrıntılar bu metnin Grafana Labs'ın ürün başkan yardımcısından çevirisinde bulunmaktadır.
19 Temmuz Cuma günü, Grafana Cloud'daki Barındırılan Prometheus hizmeti yaklaşık 30 dakika boyunca çalışmayı durdurdu. Kesintiden etkilenen tüm müşterilerimizden özür dileriz. Bizim işimiz ihtiyacınız olan izleme araçlarını sağlamaktır ve bunların mevcut olmamasının hayatınızı daha da zorlaştırabileceğinin bilincindeyiz. Bu olayı son derece ciddiye alıyoruz. Bu notta ne olduğu, nasıl tepki verdiğimiz ve bunun bir daha yaşanmamasını sağlamak için ne yaptığımız açıklanmaktadır.
tarih öncesi
Grafana Bulutta Barındırılan Prometheus hizmeti, — Yatay olarak ölçeklenebilir, yüksek düzeyde kullanılabilir, çok kiracılı bir Prometheus hizmeti oluşturmaya yönelik CNCF projesi. Cortex mimarisi, her biri kendi işlevini yerine getiren bir dizi bireysel mikro hizmetten oluşur: çoğaltma, depolama, sorgular vb. Cortex aktif olarak geliştirilme aşamasındadır ve sürekli olarak yeni özellikler ekleyerek performansı geliştirmektedir. Müşterilerin bu özelliklerden yararlanabilmesi için düzenli olarak yeni Cortex sürümlerini kümelere dağıtıyoruz; neyse ki Cortex, kesinti olmadan güncellenebiliyor.
Sorunsuz güncellemeler için Ingester Cortex hizmeti, güncelleme işlemi sırasında ek bir Ingester kopyası gerektirir. (Not. tercüme: - Korteksin temel bileşeni. Görevi, sürekli bir örnek akışı toplamak, bunları Prometheus parçaları halinde gruplamak ve DynamoDB, BigTable veya Cassandra gibi bir veritabanında depolamaktır.) Bu, eski Yiyenlerin mevcut verileri yeni Yiyenlere iletmesine olanak tanır. Sindiricilerin kaynak talep ettiğini belirtmekte fayda var. Bunların çalışması için 4 çekirdeğe ve kapsül başına 15 GB belleğe sahip olmanız gerekir; Kubernetes kümelerimizde temel makinenin işlem gücünün ve belleğinin %25'i. Genel olarak kümede genellikle 4 çekirdek ve 15 GB bellekten çok daha fazla kullanılmayan kaynak bulunur, dolayısıyla yükseltmeler sırasında bu ek besleyicileri kolayca hızlandırabiliriz.
Ancak normal çalışma sırasında hiçbir makinenin bu %25'lik kullanılmayan kaynaklara sahip olmadığı sıklıkla görülür. Evet, çabalamıyoruz bile: CPU ve bellek diğer işlemler için her zaman faydalı olacaktır. Bu sorunu çözmek için kullanmaya karar verdik. . Buradaki fikir, Ingester'lara diğer (durum bilgisi olmayan) mikro hizmetlerden daha yüksek öncelik vermektir. Ek bir (N+1) Besleyici çalıştırmamız gerektiğinde, diğer daha küçük bölmeleri geçici olarak değiştiririz. Bu kapsüller diğer makinelerdeki boş kaynaklara aktarılarak ek bir Ingester'ın çalıştırılmasına yetecek kadar büyük bir "delik" bırakılır.
18 Temmuz Perşembe günü kümelerimize dört yeni öncelik düzeyi sunduk: kritik, uzun boylu, ortalama и düşük. Yaklaşık bir hafta boyunca müşteri trafiği olmayan dahili bir kümede test edildiler. Varsayılan olarak, belirli bir önceliğe sahip olmayan bölmeler alınır ortalama öncelik, sınıf şu özelliklere sahip olan Yemeciler için belirlendi: yüksek önceliği. kritik izleme için ayrılmıştı (Prometheus, Alertmanager, node-exporter, kube-state-metrics, vb.). Yapılandırmamız açık ve PR'yi görüntüleyebilirsiniz .
Авария
19 Temmuz Cuma günü mühendislerden biri büyük bir müşteri için yeni bir özel Cortex kümesi başlattı. Bu kümenin yapılandırması yeni bölme önceliklerini içermiyordu, dolayısıyla tüm yeni bölmelere varsayılan bir öncelik atandı - ortalama.
Kubernetes kümesinin yeni Cortex kümesi için yeterli kaynağı yoktu ve mevcut üretim Cortex kümesi güncellenmedi (Yükleyiciler eksik kaldı) высокого öncelik). Yeni kümenin Yiyenleri varsayılan olarak ortalama öncelikliyse ve üretimdeki mevcut bölmeler hiçbir öncelik olmadan çalışıyorsa, yeni kümenin İçicileri, mevcut Cortex üretim kümesindeki İçicilerin yerini aldı.
Üretim kümesindeki çıkarılan Ingester için ReplicaSet, çıkarılan bölmeyi algıladı ve belirtilen sayıda kopyayı korumak için yeni bir tane oluşturdu. Yeni bölme varsayılan olarak atandı ortalama öncelik ve üretimdeki başka bir "eski" Ingester kaynaklarını kaybetti. Sonuç şuydu: çığ sürecibu da Cortex üretim kümeleri için tüm kapsüllerin Ingester'den taşınmasına yol açtı.
Besleyiciler durum bilgilidir ve önceki 12 saate ait verileri depolar. Bu, bunları uzun süreli depolamaya yazmadan önce daha verimli bir şekilde sıkıştırmamıza olanak tanır. Bunu başarmak için Cortex, Dağıtılmış Karma Tablo (DHT) kullanarak verileri seriler arasında parçalar ve Dinamo tarzı çekirdek tutarlılığı kullanarak her seriyi üç Alıcıda çoğaltır. Cortex, devre dışı bırakılan Alıcılara veri yazmaz. Bu nedenle, çok sayıda Alıcı DHT'den ayrıldığında Cortex, girişlerin yeterli düzeyde replikasyonunu sağlayamaz ve çöker.
Tespit ve Düzeltme
"Hata bütçesine" dayalı yeni Prometheus bildirimleri (hata bütçesine dayalı — ayrıntılar gelecek bir makalede yer alacaktır) kapatmanın başlamasından 4 dakika sonra alarm çalmaya başladı. Önümüzdeki beş dakika boyunca bazı teşhisler yürüttük ve temeldeki Kubernetes kümesinin ölçeğini hem yeni hem de mevcut üretim kümelerini barındıracak şekilde büyüttük.
Beş dakika daha geçtikten sonra eski Ingester'lar verilerini başarıyla yazdı, yenileri başlatıldı ve Cortex kümeleri yeniden kullanılabilir hale geldi.
Cortex'in önünde bulunan kimlik doğrulama ters proxy'lerinden kaynaklanan yetersiz bellek (OOM) hatalarını teşhis etmek ve düzeltmek için 10 dakika daha harcandı. OOM hataları, QPS'deki on kat artıştan kaynaklandı (müşterinin Prometheus sunucularından gelen aşırı agresif isteklerden kaynaklandığına inanıyoruz).
Sonrası
Toplam kesinti süresi 26 dakikaydı. Hiçbir veri kaybolmadı. Besleyiciler, tüm bellek içi verileri uzun vadeli depolamaya başarıyla yükledi. Kapatma sırasında istemci Prometheus sunucularının arabelleğe alınması silindi (uzaktan) kullanarak kayıtlar WAL'a dayalı (yazar: Grafana Labs'tan) ve kazadan sonra başarısız olan yazma işlemlerini tekrarladı.
Üretim kümesi yazma işlemleri
Bulgular
Bu olaydan ders çıkarıp bir daha tekrarlanmaması için gerekli adımların atılması çok önemli.
Geriye dönüp baktığımızda, varsayılanı ayarlamamalıydık ortalama Üretimdeki tüm Yiyenler alınana kadar öncelik uzun boylu bir öncelik. Ayrıca onlarla önceden ilgilenmek gerekiyordu. yüksek öncelik. Artık her şey düzeldi. Deneyimimizin Kubernetes'te pod önceliklerini kullanmayı düşünen diğer kuruluşlara yardımcı olacağını umuyoruz.
Yapılandırmaları küme için genel olan ek nesnelerin dağıtımı üzerinde ek bir denetim düzeyi ekleyeceğiz. Artık bu tür değişiklikler değerlendirilecek.оDaha fazla insan. Ayrıca, çökmeye neden olan değişikliğin ayrı bir proje belgesi için çok küçük olduğu değerlendirildi; yalnızca GitHub sayısında tartışıldı. Şu andan itibaren yapılandırmalarda yapılan tüm bu değişikliklere uygun proje belgeleri eşlik edecek.
Son olarak, tanık olduğumuz aşırı OOM'u önlemek için kimlik doğrulama ters proxy'sinin yeniden boyutlandırılmasını otomatikleştireceğiz ve gelecekte benzer sorunları önlemek için geri dönüş ve ölçeklendirmeyle ilgili Prometheus varsayılan ayarlarını gözden geçireceğiz.
Başarısızlığın bazı olumlu sonuçları da oldu: Gerekli kaynakları alan Cortex, ek müdahaleye gerek kalmadan otomatik olarak iyileşti. Ayrıca aşağıdakilerle çalışarak değerli deneyimler kazandık: - tüm Kayıt Kullanıcılarının arıza sırasında ve sonrasında düzgün davranmasını sağlamaya yardımcı olan yeni günlük toplama sistemimiz.
çevirmenden PS
Blogumuzda da okuyun:
- «";
- «";
- «";
- «'.
Kaynak: habr.com