Tandaan. transl.: Ipinakikita namin sa iyong pansin ang mga teknikal na detalye tungkol sa mga dahilan para sa kamakailang downtime sa cloud service na pinananatili ng mga creator ng Grafana. Ito ay isang klasikong halimbawa kung paano ang isang bago at tila lubhang kapaki-pakinabang na tampok na idinisenyo upang mapabuti ang kalidad ng imprastraktura... ay maaaring magdulot ng pinsala kung hindi mo ibibigay ang maraming mga nuances ng aplikasyon nito sa mga katotohanan ng produksyon. Napakahusay kapag lumitaw ang mga materyal na tulad nito na nagbibigay-daan sa iyong matuto hindi lamang mula sa iyong mga pagkakamali. Ang mga detalye ay nasa pagsasalin ng tekstong ito mula sa bise presidente ng produkto mula sa Grafana Labs.
Noong Biyernes, Hulyo 19, huminto sa paggana ang serbisyo ng Hosted Prometheus sa Grafana Cloud nang humigit-kumulang 30 minuto. Humihingi ako ng paumanhin sa lahat ng mga customer na apektado ng outage. Ang aming trabaho ay ibigay ang mga tool sa pagsubaybay na kailangan mo, at naiintindihan namin na ang hindi pagkakaroon ng mga ito ay maaaring magpahirap sa iyong buhay. Lubos naming sineseryoso ang pangyayaring ito. Ipinapaliwanag ng talang ito kung ano ang nangyari, kung paano kami tumugon, at kung ano ang ginagawa namin upang matiyak na hindi na ito mauulit.
prehistory
Ang serbisyo ng Grafana Cloud Hosted Prometheus ay nakabatay sa β Proyekto ng CNCF upang lumikha ng isang pahalang na nasusukat, lubos na magagamit, multi-tenant na serbisyo ng Prometheus. Ang arkitektura ng Cortex ay binubuo ng isang hanay ng mga indibidwal na microservice, na ang bawat isa ay gumaganap ng sarili nitong function: pagtitiklop, imbakan, mga query, atbp. Ang Cortex ay nasa ilalim ng aktibong pag-unlad at patuloy na nagdaragdag ng mga bagong tampok at pagpapabuti ng pagganap. Regular kaming nagde-deploy ng mga bagong Cortex release sa mga cluster para mapakinabangan ng mga customer ang mga feature na ito - sa kabutihang palad, maaaring ma-update ang Cortex nang walang downtime.
Para sa tuluy-tuloy na pag-update, nangangailangan ang serbisyo ng Ingester Cortex ng karagdagang replika ng Ingester sa panahon ng proseso ng pag-update. (Tandaan. transl.: - ang pangunahing bahagi ng Cortex. Ang trabaho nito ay upang mangolekta ng isang tuluy-tuloy na stream ng mga sample, ipangkat ang mga ito sa Prometheus chunks at iimbak ang mga ito sa isang database tulad ng DynamoDB, BigTable o Cassandra.) Nagbibigay-daan ito sa mga lumang Ingesters na ipasa ang kasalukuyang data sa bagong Ingesters. Ito ay nagkakahalaga ng pagpuna na ang Ingesters ay nangangailangan ng mapagkukunan. Para gumana ang mga ito, kailangan mong magkaroon ng 4 na core at 15 GB ng memory bawat pod, i.e. 25% ng kapangyarihan sa pagproseso at memorya ng base machine sa kaso ng aming mga Kubernetes cluster. Sa pangkalahatan, kadalasan ay mas marami kaming hindi nagamit na mapagkukunan sa cluster kaysa sa 4 na core at 15 GB ng memorya, kaya madali naming paikutin ang mga karagdagang ingester na ito sa panahon ng mga pag-upgrade.
Gayunpaman, madalas na nangyayari na sa panahon ng normal na operasyon, wala sa mga makina ang may ganitong 25% ng hindi nagamit na mapagkukunan. Oo, hindi man lang kami nagsusumikap: Ang CPU at memorya ay palaging magiging kapaki-pakinabang para sa iba pang mga proseso. Upang malutas ang problemang ito, nagpasya kaming gamitin . Ang ideya ay bigyan ang Ingesters ng mas mataas na priyoridad kaysa sa iba pang (walang estado) na mga microservice. Kapag kailangan naming magpatakbo ng karagdagang (N+1) Ingester, pansamantala naming pinapalitan ang iba pang mas maliliit na pod. Ang mga pod na ito ay inililipat sa mga libreng mapagkukunan sa iba pang mga makina, na nag-iiwan ng sapat na malaking "butas" upang magpatakbo ng karagdagang Ingester.
Noong Huwebes, Hulyo 18, inilunsad namin ang apat na bagong antas ng priyoridad sa aming mga cluster: mapanganib, mataas, ΡΡΠ΅Π΄Π½ΠΈΠΉ ΠΈ mababa. Sinuri sila sa isang panloob na kumpol na walang trapiko ng kliyente sa loob ng halos isang linggo. Bilang default, natanggap ang mga pod na walang tinukoy na priyoridad ΡΡΠ΅Π΄Π½ΠΈΠΉ priority, itinakda ang klase para sa Ingesters na may mataas priority. Mapanganib ay nakalaan para sa pagsubaybay (Prometheus, Alertmanager, node-exporter, kube-state-metrics, atbp.). Ang aming config ay bukas, at maaari mong tingnan ang PR .
Pag-crash
Noong Biyernes, Hulyo 19, naglunsad ang isa sa mga inhinyero ng isang bagong nakalaang Cortex cluster para sa isang malaking kliyente. Ang config para sa cluster na ito ay hindi nagsama ng mga bagong priyoridad ng pod, kaya lahat ng bagong pod ay itinalaga ng default na priyoridad - ΡΡΠ΅Π΄Π½ΠΈΠΉ.
Ang Kubernetes cluster ay walang sapat na mapagkukunan para sa bagong Cortex cluster, at ang kasalukuyang production na Cortex cluster ay hindi na-update (Ang mga Ingesters ay naiwan nang walang mataas priyoridad). Dahil ang Ingesters ng bagong cluster bilang default ay nagkaroon ΡΡΠ΅Π΄Π½ΠΈΠΉ priyoridad, at ang mga kasalukuyang pod sa produksyon ay gumana nang walang priyoridad, pinalitan ng Ingesters ng bagong cluster ang Ingesters mula sa umiiral na Cortex production cluster.
Natukoy ng ReplicaSet para sa pinaalis na Ingester sa cluster ng produksyon ang pinaalis na pod at gumawa ng bago upang mapanatili ang tinukoy na bilang ng mga kopya. Ang bagong pod ay itinalaga bilang default ΡΡΠ΅Π΄Π½ΠΈΠΉ priority, at isa pang "matandang" Ingester sa produksyon ang nawalan ng mga mapagkukunan. Ang resulta ay proseso ng avalanche, na humantong sa pag-alis ng lahat ng pod mula sa Ingester para sa mga cluster ng produksyon ng Cortex.
Ang mga ingester ay stateful at nag-iimbak ng data para sa nakaraang 12 oras. Nagbibigay-daan ito sa amin na i-compress ang mga ito nang mas mahusay bago isulat ang mga ito sa pangmatagalang imbakan. Upang makamit ito, ang Cortex ay naghahati ng data sa mga serye gamit ang isang Distributed Hash Table (DHT) at ginagaya ang bawat serye sa tatlong Ingester gamit ang Dynamo-style quorum consistency. Hindi nagsusulat ng data ang Cortex sa mga Ingesters na hindi pinagana. Kaya, kapag ang isang malaking bilang ng mga Ingester ay umalis sa DHT, ang Cortex ay hindi makakapagbigay ng sapat na pagtitiklop ng mga entry, at sila ay bumagsak.
Detection at Remediation
Mga bagong notification ng Prometheus batay sa "error budget" (batay sa error sa badyet β lalabas ang mga detalye sa isang artikulo sa hinaharap) nagsimulang tumunog ang alarma 4 minuto pagkatapos ng pagsisimula ng shutdown. Sa susunod na limang minuto o higit pa, nagpatakbo kami ng ilang diagnostics at pinalaki ang pinagbabatayan na cluster ng Kubernetes upang i-host ang bago at kasalukuyang mga production cluster.
Pagkatapos ng isa pang limang minuto, matagumpay na naisulat ng mga lumang Ingesters ang kanilang data, nagsimula ang mga bago, at naging available muli ang mga cluster ng Cortex.
Isa pang 10 minuto ang ginugol sa pag-diagnose at pagwawasto ng mga out-of-memory (OOM) na error mula sa authentication reverse proxy na matatagpuan sa harap ng Cortex. Ang mga error sa OOM ay sanhi ng sampung beses na pagtaas sa QPS (naniniwala kami dahil sa sobrang agresibong mga kahilingan mula sa mga server ng Prometheus ng kliyente).
Resulta
Ang kabuuang downtime ay 26 minuto. Walang data na nawala. Matagumpay na na-load ng mga ingester ang lahat ng in-memory na data sa pangmatagalang storage. Sa panahon ng pag-shutdown, tinanggal ang mga buffer ng client na Prometheus server (malayo) pag-record gamit ang batay sa WAL (isinulat ni mula sa Grafana Labs) at inulit ang mga nabigong pagsusulat pagkatapos ng pag-crash.
Mga operasyon sa pagsulat ng cluster ng produksyon
Natuklasan
Mahalagang matuto mula sa pangyayaring ito at gawin ang mga kinakailangang hakbang upang maiwasan ang pag-ulit nito.
Sa pagbabalik-tanaw, hindi natin dapat itakda ang default ΡΡΠ΅Π΄Π½ΠΈΠΉ priyoridad hanggang sa matanggap ng lahat ng Ingesters sa produksyon mataas ang prioridad. Bilang karagdagan, ito ay kinakailangan upang pangalagaan ang mga ito nang maaga mataas priority. Naayos na ang lahat. Umaasa kaming makakatulong ang aming karanasan sa iba pang organisasyon na isinasaalang-alang ang paggamit ng mga priyoridad ng pod sa Kubernetes.
Magdaragdag kami ng karagdagang antas ng kontrol sa pag-deploy ng anumang karagdagang mga bagay na ang mga configuration ay pandaigdigan sa cluster. Mula ngayon, susuriin ang mga naturang pagbabago bΠΎmaraming tao. Bukod pa rito, ang pagbabago na naging sanhi ng pag-crash ay itinuturing na masyadong maliit para sa isang hiwalay na dokumento ng proyekto - tinalakay lamang ito sa isang isyu sa GitHub. Mula ngayon, lahat ng naturang pagbabago sa mga config ay sasamahan ng naaangkop na dokumentasyon ng proyekto.
Panghuli, i-automate namin ang pagbabago ng laki ng reverse proxy ng pagpapatotoo para maiwasan ang labis na OOM na aming nasaksihan, at susuriin namin ang mga default na setting ng Prometheus na nauugnay sa fallback at scaling upang maiwasan ang mga katulad na isyu sa hinaharap.
Ang pagkabigo ay nagkaroon din ng ilang positibong kahihinatnan: nang matanggap ang mga kinakailangang mapagkukunan, awtomatikong nakabawi ang Cortex nang walang karagdagang interbensyon. Nagkamit din kami ng mahalagang karanasan sa pagtatrabaho - ang aming bagong log aggregation system - na tumulong na matiyak na ang lahat ng Ingester ay kumilos nang maayos sa panahon at pagkatapos ng pagkabigo.
PS mula sa tagasalin
Basahin din sa aming blog:
- Β«";
- Β«";
- Β«";
- Β«'.
Pinagmulan: www.habr.com