Заўв. перав.: Прадстаўляем вашай увазе тэхнічныя падрабязнасці аб прычынах нядаўняга прастою ў рабоце хмарнага сэрвісу, які абслугоўваецца стваральнікамі Grafana. Гэта класічны прыклад таго, як новая і, здавалася б, выключна карысная магчымасць, закліканая палепшыць якасць інфраструктуры ... можа нашкодзіць, калі не прадугледзець шматлікія нюансы яе прымянення ў рэаліях production. Выдатна, калі з'яўляюцца такія матэрыялы, якія дазваляюць вучыцца не толькі на сваіх памылках. Падрабязнасці - у перакладзе гэтага тэксту ад віцэ-прэзідэнта па прадукце з Grafana Labs.
У пятніцу, 19 ліпеня, сэрвіс Hosted Prometheus у Grafana Cloud перастаў функцыянаваць прыкладна на 30 хвілін. Прыношу прабачэнні ўсім кліентам, якія пацярпелі ад збою. Наша задача - прадастаўляць патрэбныя інструменты для маніторынгу, і мы разумеем, што іх недаступнасць ўскладняе ваша жыццё. Мы вельмі сур'ёзна ставімся да гэтага інцыдэнту. У гэтай нататцы тлумачыцца, што адбылося, як мы на гэта адрэагавалі і што робім для таго, каб падобнае больш не паўтаралася.
перадгісторыя
Сэрвіс Grafana Cloud Hosted Prometheus заснаваны на — праекце CNCF па стварэнні гарызантальна які маштабуецца, высокадаступнага, мультытэнантнага (multi-tenant) сэрвісу Prometheus. Архітэктура Cortex складаецца з набору асобных мікрасэрвісаў, кожны з якіх выконвае сваю функцыю: рэплікацыю, захоўванне, запыты і г.д. Cortex актыўна распрацоўваецца, у яго ўвесь час з'яўляюцца новыя магчымасці і павялічваецца прадукцыйнасць. Мы рэгулярна дэплоім новыя рэлізы Cortex у кластары, каб кліенты маглі скарыстацца гэтымі магчымасцямі - балазе, Cortex умее абнаўляцца без прастояў.
Для непростых абнаўленняў сэрвіс Ingester Cortex'а патрабуе дадатковую рэпліку Ingester'а падчас працэсу абнаўлення. (Заўв. перав.: - базавы кампанент Cortex'а. Яго задача - збіраць сталы струмень sample'ов, групаваць іх у chunk'і Prometheus і захоўваць у базе дадзеных накшталт DynamoDB, BigTable ці Cassandra.) Гэта дазваляе старым Ingester'ам перасылаць бягучыя дадзеныя новым Ingester'ам. Варта адзначыць, што Ingester'ы патрабавальныя да рэсурсаў. Для іх працы неабходна мець па 4 ядры і 15 Гб памяці на pod, г.зн. 25% працэсарнай магутнасці і памяці базавай машыны ў выпадку нашых кластарах Kubernetes. У цэлым у нас звычайна значна больш нявыкарыстаных рэсурсаў у кластары, чым 4 ядры і 15 Гб памяці, таму мы можам лёгка запускаць гэтыя дадатковыя Ingester'ы падчас абнаўленняў.
Аднак часта бывае так, што падчас нармальнай працы ні на адной з машын няма гэтых 25% незапатрабаваных рэсурсаў. Ды мы і не імкнемся: CPU і памяць заўсёды спатрэбяцца для іншых працэсаў. Для вырашэння гэтай праблемы мы вырашылі скарыстацца . Ідэя ў тым, каб прысвойваць Ingester'ам больш высокі прыярытэт, чым іншым (stateless) мікрасэрвісам. Калі нам трэба запусціць дадатковы (N+1) Ingester, мы часова выцясняем іншыя, малодшыя pod'ы. Гэтыя pod'ы пераносяцца ў вольныя рэсурсы на іншых машынах, пакідаючы досыць вялікую "дзюру" для запуску дадатковага Ingester'а.
У чацвер, 18 ліпеня, мы разгарнулі чатыры новыя ўзроўні прыярытэтаў у сваіх кластарах: крытычны, высокі, сярэдні и нізкі. Яны тэсціравалі на ўнутраным кластары без кліенцкага трафіку прыкладна адзін тыдзень. Па змаўчанні pod'ы без зададзенага прыярытэту атрымлівалі сярэдні прыярытэт, для Ingester'аў быў усталяваны клас з высокім прыярытэтам. Крытычны быў зарэзерваваны для маніторынгу (Prometheus, Alertmanager, node-exporter, kube-state-metrics і г.д.). Наш канфіг - адкрыты, і паглядзець PR можна .
аварыя
У пятніцу, 19 ліпеня, адзін з інжынераў запусціў новы выдзелены кластар Cortex для буйнога кліента. Канфіг для гэтага кластара не ўключаў новыя прыярытэты pod'ов, таму ўсім новым pod'ам прысвойваўся прыярытэт па змаўчанні сярэдні.
У кластары Kubernetes не хапіла рэсурсаў для новага кластара Cortex, а існуючы production-кластар Cortex не быў абноўлены (Ingester'ы засталіся без высокага прыярытэту). Паколькі Ingester'ы новага кластара па змаўчанні мелі сярэдні прыярытэт, а існуючыя ў production pod'ы працавалі наогул без прыярытэту, Ingester'ы новага кластара выцеснілі Ingester з існуючага production-кластара Cortex.
ReplicaSet для выцесненага Ingester'а ў production-кластары выявіў выцеснены pod і стварыў новы для падтрымання зададзенай колькасці дзід. Новаму pod'у па змаўчанні быў прысвоены сярэдні прыярытэт, і чарговы стары Ingester у production пазбавіўся рэсурсаў. Вынікам стаў лавінападобны працэс, які прывёў да выцяснення ўсіх pod'аў з Ingester для production-кластэраў Cortex'а.
Ingester'ы захоўваюць стан (stateful) і захоўваюць дадзеныя за папярэднія 12 гадзін. Гэта дазваляе нам больш эфектыўна сціскаць іх перад запісам у доўгатэрміновае сховішча. Для гэтага Cortex праводзіць шардынг дадзеных па серыях, выкарыстаючы размеркаваную хэш-табліцу (Distributed Hash Table, DHT), і рэплікуе кожную серыю на тры Ingester'а з дапамогай кворумнай узгодненасці ў стылі Dynamo. Cortex не піша дадзеныя ў Ingester'ы, якія адключаюцца. Такім чынам, калі вялікі лік Ingester'аў пакідаюць DHT, Cortex не можа забяспечыць дастатковую рэплікацыю запісаў, і яны "падаюць".
Выяўленне і ўстараненне
Новыя апавяшчэння Prometheus на аснове «бюджэту памылак» (error-budget-based - падрабязнасці з'явяцца ў будучым артыкуле) сталі біць трывогу праз 4 хвіліны з моманту пачатку адключэння. На працягу наступных прыкладна пяці хвілін мы правялі дыягностыку і нарасцілі ніжэйлеглы кластар Kubernetes для размяшчэння як новага, так і існуючых production-кластэраў.
Яшчэ праз пяць хвілін старыя Ingester'ы паспяхова запісалі свае дадзеныя, а новыя запусціліся, і кластары Cortex зноў сталі даступныя.
Яшчэ 10 хвілін сышло на дыягностыку і выпраўленне out-of-memory (OOM) памылак ад зваротных проксі-сервераў аўтэнтыфікацыі, размешчаных перад Cortex. ООМ-памылкі былі выкліканыя дзесяціразовым ростам QPS (як мы лічым, з-за празмеру агрэсіўных запытаў з сервераў Prometheus кліента).
наступствы
Агульная працягласць прастою склала 26 хвілін. Дадзеныя не былі страчаныя. Ingester'ы паспяхова загрузілі ўсе in-memory-дадзеныя ў доўгачасовае сховішча. Падчас адключэння Prometheus-серверы кліентаў захоўвалі ў буфер выдаленыя (remote) запісы з дапамогай на аснове WAL (за аўтарствам з Grafana Labs) і паўтарылі няўдалыя запісы пасля збою.
Аперацыі запісу production-кластара
Высновы
Важна атрымаць урокі з гэтага інцыдэнту і прыняць неабходныя меры, каб пазбегнуць яго паўтарэння.
Азіраючыся назад, варта прызнаць, што нам не трэба было задаваць па змаўчанні сярэдні прыярытэт, пакуль усе Ingester'ы ў production не атрымалі высокі прыярытэт. Акрамя таго, трэба было загадзя паклапаціцца пра іх высокім прыярытэце. Цяпер усё выпраўлена. Спадзяемся, што наш досвед дапаможа іншым арганізацыям, якія разглядаюць магчымасць выкарыстання прыярытэтаў pod'аў у Kubernetes.
Мы дадамо дадатковы ўзровень кантролю за разгортваннем любых дадатковых аб'ектаў, канфігурацыі якіх глабальныя для кластара. Надалей падобныя змены будуць ацэньвацца бовялікай колькасцю людзей. Акрамя таго, мадыфікацыя, якая прывяла да збою, лічылася занадта нязначнай для асобнага праектнага дакумента - яна абмяркоўвалася толькі ў GitHub issue. З гэтага моманту ўсе падобныя змены канфігаў будуць суправаджацца адпаведнай праектнай дакументацыяй.
Нарэшце, мы аўтаматызуем змену памеру ў зваротнага проксі-сервера аўтэнтыфікацыі для прадухілення ООМ пры перагрузцы, сведкамі чаго мы сталі, і прааналізуем параметры Prometheus па змаўчанні, злучаныя з адкатам і маштабаваннем, для папярэджання ў будучыні падобных праблем.
Перажыты збой меў і некаторыя пазітыўныя наступствы: атрымаўшы ў распараджэнне неабходныя рэсурсы, Cortex аўтаматычна аднавіўся без дадатковага ўмяшання. Мы таксама атрымалі каштоўны досвед працы з – нашай новай сістэмай агрэгацыі логаў, – якая дапамагла пераканацца, што ўсе Ingester'ы належным чынам павялі сябе падчас і пасля збою.
PS ад перакладчыка
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «»;
- «.
Крыніца: habr.com