Qeyd. tərcümə.: Grafana yaradıcıları tərəfindən saxlanılan bulud xidmətində son fasilələrin səbəbləri haqqında texniki detalları diqqətinizə təqdim edirik. Bu, infrastrukturun keyfiyyətini yaxşılaşdırmaq üçün nəzərdə tutulmuş yeni və zahirən son dərəcə faydalı funksiyanın... onun istehsal reallıqlarında tətbiqinin çoxsaylı nüanslarını təmin etməsəniz zərər verə biləcəyinin klassik nümunəsidir. Nəinki səhvlərinizdən öyrənməyə imkan verən bu kimi materiallar ortaya çıxdıqda əladır. Təfərrüatlar bu mətnin Grafana Labs məhsul üzrə vitse-prezidentinin tərcüməsindədir.
Cümə günü, iyulun 19-da Grafana Cloud-da Hosted Prometheus xidməti təxminən 30 dəqiqə fəaliyyətini dayandırdı. Kesintidən təsirlənən bütün müştərilərdən üzr istəyirəm. Bizim işimiz sizə lazım olan monitorinq alətlərini təmin etməkdir və biz başa düşürük ki, onların mövcud olmaması həyatınızı çətinləşdirə bilər. Biz bu hadisəyə son dərəcə ciddi yanaşırıq. Bu qeyd nə baş verdiyini, necə cavab verdiyimizi və bunun bir daha təkrarlanmaması üçün nə etdiyimizi izah edir.
Prehistorya
Grafana Cloud Hosted Prometheus xidmətinə əsaslanır — CNCF layihəsi üfüqi olaraq genişlənə bilən, yüksək əlçatan, çox kirayəçi Prometheus xidmətini yaratmaq üçün. Cortex arxitekturası hər biri öz funksiyasını yerinə yetirən fərdi mikroservislər dəstindən ibarətdir: replikasiya, saxlama, sorğular və s. Korteks aktiv inkişaf mərhələsindədir və daim yeni funksiyalar əlavə edir və performansını artırır. Biz mütəmadi olaraq yeni Cortex relizlərini klasterlərə yerləşdiririk ki, müştərilər bu xüsusiyyətlərdən yararlana bilsinlər - xoşbəxtlikdən, Cortex fasiləsiz yenilənə bilər.
Problemsiz yeniləmələr üçün Ingester Cortex xidməti yeniləmə prosesi zamanı əlavə Ingester replikasını tələb edir. (Qeyd. tərcümə.: - Korteksin əsas komponenti. Onun işi daimi nümunələr axını toplamaq, onları Prometey parçalarına qruplaşdırmaq və DynamoDB, BigTable və ya Cassandra kimi verilənlər bazasında saxlamaqdır.) Bu, köhnə Ingesterlərə cari məlumatları yeni Ingesterlərə ötürməyə imkan verir. Qeyd etmək lazımdır ki, Ingesterlər resurs tələb edir. Onların işləməsi üçün hər podda 4 nüvə və 15 GB yaddaş olmalıdır, yəni. Kubernetes klasterlərimizdə əsas maşının emal gücü və yaddaşının 25%-i. Ümumiyyətlə, biz adətən klasterdə 4 nüvə və 15 GB yaddaşdan daha çox istifadə olunmayan resurslara sahibik, ona görə də təkmilləşdirmələr zamanı bu əlavə qəbulediciləri asanlıqla fırlada bilərik.
Bununla belə, tez-tez olur ki, normal işləmə zamanı maşınların heç birində istifadə olunmamış resursların bu 25% -i yoxdur. Bəli, biz səy göstərmirik: CPU və yaddaş həmişə digər proseslər üçün faydalı olacaq. Bu problemi həll etmək üçün istifadə etməyə qərar verdik . İdeya Ingester-ə digər (vətəndaşlığı olmayan) mikroservislərdən daha yüksək prioritet verməkdir. Əlavə (N+1) Ingester-i işə salmaq lazım olduqda, biz müvəqqəti olaraq digər kiçik podları yerindən qoyuruq. Bu podlar digər maşınlarda pulsuz resurslara ötürülür və əlavə Ingester-i işə salmaq üçün kifayət qədər böyük “deşik” buraxır.
Cümə axşamı, iyulun 18-də biz klasterlərimiz üçün dörd yeni prioritet səviyyəni təqdim etdik: kritik, yüksək, orta и aşağı. Onlar təxminən bir həftə ərzində heç bir müştəri trafiki olmayan daxili klasterdə sınaqdan keçirilib. Varsayılan olaraq, müəyyən bir prioriteti olmayan podlar qəbul edildi orta prioritet, sinif ilə Ingesters üçün müəyyən edilmişdir yüksək prioritet. Tənqidi monitorinq üçün ayrılmışdır (Prometheus, Alertmanager, node-exporter, kube-state-metrics və s.). Konfiqurasiyamız açıqdır və siz PR-a baxa bilərsiniz .
Qəza
Cümə günü, iyulun 19-da mühəndislərdən biri böyük bir müştəri üçün yeni xüsusi Cortex klasterini işə saldı. Bu klaster üçün konfiqurasiyaya yeni pod prioritetləri daxil deyildi, ona görə də bütün yeni podlara defolt prioritet təyin edildi - orta.
Kubernetes klasterində yeni Cortex klasteri üçün kifayət qədər resurs yox idi və mövcud istehsal Cortex klasteri yenilənmədi (İngesterlər высокого prioritet). Defolt olaraq yeni klasterin Ingesterləri olduğundan orta prioritet idi və istehsalda mövcud pods ümumiyyətlə prioritetsiz işlədi, yeni klasterin Ingesterləri mövcud Cortex istehsal klasterindən Ingesterləri əvəz etdi.
İstehsal klasterində çıxarılan Ingester üçün ReplicaSet çıxarılan podu aşkar etdi və müəyyən edilmiş nüsxə sayını saxlamaq üçün yenisini yaratdı. Yeni pod defolt olaraq təyin edilib orta prioritet oldu və istehsaldakı başqa bir "köhnə" Ingester resurslarını itirdi. Nəticə belə oldu uçqun prosesi, bütün podların Cortex istehsal qrupları üçün Ingester-dən yerdəyişməsinə səbəb oldu.
Ingesters statusludur və məlumatları əvvəlki 12 saat ərzində saxlayır. Bu, uzunmüddətli yaddaşa yazmadan əvvəl onları daha səmərəli şəkildə sıxışdırmağa imkan verir. Buna nail olmaq üçün Cortex, Paylanmış Hash Cədvəli (DHT) istifadə edərək seriyalar üzrə məlumatları parçalayır və Dinamo tipli kvorum ardıcıllığından istifadə edərək hər seriyanı üç Ingester arasında təkrarlayır. Cortex əlil olan Ingesterlərə məlumat yazmır. Beləliklə, çox sayda Ingester DHT-ni tərk etdikdə, Cortex girişlərin kifayət qədər təkrarlanmasını təmin edə bilmir və onlar çökür.
Aşkarlama və Təmir
"Səhv büdcəsi" əsasında yeni Prometheus bildirişləri (səhv büdcəyə əsaslanan — təfərrüatlar gələcək məqalədə göstəriləcək) söndürmə başlayandan 4 dəqiqə sonra həyəcan siqnalı çalmağa başladı. Növbəti beş dəqiqə ərzində biz bəzi diaqnostika apardıq və həm yeni, həm də mövcud istehsal qruplarını yerləşdirmək üçün əsas Kubernetes klasterini genişləndirdik.
Daha beş dəqiqədən sonra köhnə Ingesterlər öz məlumatlarını uğurla yazdılar, yeniləri işə düşdü və Cortex klasterləri yenidən əlçatan oldu.
Daha 10 dəqiqə Cortex-in qarşısında yerləşən identifikasiyanın əks proksi-lərindən kənar yaddaş (OOM) səhvlərinin diaqnostikasına və korreksiyasına sərf olundu. OOM xətaları QPS-də on qat artımdan qaynaqlanır (biz inanırıq ki, müştərinin Prometheus serverlərindən hədsiz aqressiv sorğular səbəbindən).
Nəticələr
Ümumi fasilə 26 dəqiqə idi. Heç bir məlumat itirilməyib. Ingesters bütün yaddaşdaxili məlumatları uzunmüddətli yaddaşa uğurla yüklədi. Bağlanma zamanı buferlənmiş müştəri Prometheus serverləri silindi (uzaqdan) istifadə edərək yazılar WAL əsasında (müəllif Grafana Labs) və qəzadan sonra uğursuz yazıları təkrarladı.
İstehsal klasterinin yazılması əməliyyatları
Tapıntılar
Bu hadisədən nəticə çıxarmaq və təkrarlanmamaq üçün lazımi addımları atmaq vacibdir.
Geriyə baxanda biz standartı təyin etməməliydik orta istehsalda olan bütün Ingesterlər alınana qədər prioritet yüksək prioritetdir. Bundan əlavə, onlara əvvəlcədən qayğı göstərmək lazım idi yüksək prioritet. İndi hər şey düzəldi. Ümid edirik ki, təcrübəmiz Kubernetes-də pod prioritetlərindən istifadə etməyi düşünən digər təşkilatlara kömək edəcək.
Konfiqurasiyaları klaster üçün qlobal olan istənilən əlavə obyektlərin yerləşdirilməsi üzərində əlavə nəzarət səviyyəsini əlavə edəcəyik. Bundan sonra belə dəyişikliklər qiymətləndiriləcək bоdaha çox insan. Bundan əlavə, qəzaya səbəb olan dəyişiklik ayrıca layihə sənədi üçün çox kiçik hesab edildi - bu, yalnız GitHub məsələsində müzakirə edildi. Bundan sonra konfiqurasiyalara edilən bütün bu cür dəyişikliklər müvafiq layihə sənədləri ilə müşayiət olunacaq.
Nəhayət, biz şahidi olduğumuz OOM-un həddən artıq yüklənməsinin qarşısını almaq üçün identifikasiya tərs proksinin ölçüsünün dəyişdirilməsini avtomatlaşdıracağıq və gələcəkdə oxşar problemlərin qarşısını almaq üçün geri qaytarma və miqyasla bağlı Prometheus standart parametrlərini nəzərdən keçirəcəyik.
Uğursuzluğun bəzi müsbət nəticələri də oldu: lazımi resursları əldə edərək, Cortex əlavə müdaxilə olmadan avtomatik olaraq bərpa edildi. Biz həm də işləyərkən dəyərli təcrübə qazandıq - bizim yeni log aqreqasiya sistemimiz - bu, bütün Ingesterlərin uğursuzluq zamanı və sonra düzgün davranmasını təmin etməyə kömək etdi.
Tərcüməçidən PS
Bloqumuzda da oxuyun:
- «";
- «";
- «";
- «.
Mənbə: www.habr.com