Monitorings kā pakalpojums: modulāra sistēma mikropakalpojumu arhitektūrai

MÅ«sdienās mÅ«su projektā papildus monolÄ«tam kodam ir vairāki desmiti mikropakalpojumu. Katrs no tiem ir jāuzrauga. To izdarÄ«t Ŕādā mērogā, izmantojot DevOps inženierus, ir problemātiski. Mēs esam izstrādājuÅ”i uzraudzÄ«bas sistēmu, kas darbojas kā serviss izstrādātājiem. Viņi var neatkarÄ«gi ierakstÄ«t metriku uzraudzÄ«bas sistēmā, izmantot tos, veidot informācijas paneļus, pamatojoties uz tiem, un pievienot tiem brÄ«dinājumus, kas tiks aktivizēti, kad tiks sasniegtas sliekŔņa vērtÄ«bas. DevOps inženieriem tikai infrastruktÅ«ra un dokumentācija.

Å is ieraksts ir atÅ”ifrējums manai runai ar mÅ«su sadaļas vietnē RIT++. Daudzi cilvēki mums lÅ«dza izveidot ziņojumu teksta versijas no turienes. Ja bijāt konferencē vai skatÄ«jāties video, neko jaunu neatradÄ«siet. Un visi pārējie - laipni lÅ«gti kaÄ·Ä«. Es jums pastāstÄ«Å”u, kā mēs nonācām pie Ŕādas sistēmas, kā tā darbojas un kā mēs plānojam to atjaunināt.

Monitorings kā pakalpojums: modulāra sistēma mikropakalpojumu arhitektūrai

Pagātne: shēmas un plāni

Kā mēs nonācām pie paÅ”reizējās uzraudzÄ«bas sistēmas? Lai atbildētu uz Å”o jautājumu, jādodas uz 2015. gadu. Toreiz tas izskatÄ«jās Ŕādi:

Monitorings kā pakalpojums: modulāra sistēma mikropakalpojumu arhitektūrai

Mums bija aptuveni 24 mezgli, kas bija atbildÄ«gi par uzraudzÄ«bu. Ir vesela paka dažādu kroņu, skriptu, dēmonu, kas kaut kā kaut ko uzrauga, sÅ«ta ziņas un pilda funkcijas. Domājām, jo ā€‹ā€‹tālāk, jo mazāk dzÄ«votspējÄ«ga bÅ«s Ŕāda sistēma. Nav jēgas to attÄ«stÄ«t: tas ir pārāk apgrÅ«tinoÅ”i.
Nolēmām izvēlēties tos monitoringa elementus, kurus paturēsim un attÄ«stÄ«sim, un tos, no kuriem atteiksimies. To bija 19. Palika tikai grafÄ«ti, agregatori un Grafana kā informācijas panelis. Bet kāda bÅ«s jaunā sistēma? Kā Å”is:

Monitorings kā pakalpojums: modulāra sistēma mikropakalpojumu arhitektūrai

Mums ir metrikas krātuve: tie ir grafÄ«ti, kuru pamatā bÅ«s ātri SSD diskdziņi, tie ir noteikti metriku apkopotāji. Nākamais - Grafana informācijas paneļu parādÄ«Å”anai un Moira brÄ«dināŔanai. Mēs arÄ« vēlējāmies izstrādāt sistēmu anomāliju meklÄ“Å”anai.

Standarts: Monitorings 2.0

Šādi plāni izskatÄ«jās 2015. gadā. Taču mums bija jāsagatavo ne tikai infrastruktÅ«ra un pats serviss, bet arÄ« dokumentācija tam. Mēs esam izstrādājuÅ”i sev korporatÄ«vo standartu, ko saucam par monitoringu 2.0. Kādas bija prasÄ«bas sistēmai?

  • pastāvÄ«ga pieejamÄ«ba;
  • metriku glabāŔanas intervāls = 10 sekundes;
  • strukturēta metrikas un informācijas paneļu glabāŔana;
  • SLA > 99,99%
  • notikumu metrikas apkopoÅ”ana, izmantojot UDP (!).

Mums bija nepiecieÅ”ams UDP, jo mums ir liela trafika un notikumu plÅ«sma, kas Ä£enerē metriku. Ja tos visus vienlaikus ierakstÄ«sit grafÄ«tā, krātuve sabruks. Mēs arÄ« izvēlējāmies pirmā lÄ«meņa prefiksus visiem rādÄ«tājiem.

Monitorings kā pakalpojums: modulāra sistēma mikropakalpojumu arhitektūrai

Katram no prefiksiem ir kāds Ä«paÅ”ums. Ir metrika serveriem, tÄ«kliem, konteineriem, resursiem, lietojumprogrammām utt. Ir ieviesta skaidra, stingra, drukāta filtrÄ“Å”ana, kurā mēs pieņemam pirmā lÄ«meņa metriku, bet pārējos vienkārÅ”i atmetam. Tā mēs Å”o sistēmu plānojām 2015. gadā. Kas ir tagadnē?

Klāt: monitoringa komponentu mijiedarbības diagramma

Pirmkārt, mēs uzraugām lietojumprogrammas: mūsu PHP kodu, lietojumprogrammas un mikropakalpojumus - īsi sakot, visu, ko raksta mūsu izstrādātāji. Visas lietojumprogrammas nosūta metriku, izmantojot UDP, uz Brubeck apkopotāju (statsd, pārrakstīts C valodā). Sintētikas testos tas izrādījās ātrākais. Un tas nosūta jau apkopotos rādītājus uz Graphite, izmantojot TCP.

Tam ir sava veida metrika, ko sauc par taimeriem. Å Ä« ir ļoti ērta lieta. Piemēram, par katru lietotāja savienojumu ar pakalpojumu Brubeck nosÅ«tāt metriku ar reakcijas laiku. Tika saņemts miljons atbilžu, bet apkopotājs atgrieza tikai 10 metriku. Jums ir atnākuÅ”o cilvēku skaits, maksimālais, minimālais un vidējais atbildes laiks, mediāna un 4. procentile. Pēc tam dati tiek pārsÅ«tÄ«ti uz Graphite un mēs to visu redzam tieÅ”raidē.

Mums ir arÄ« datu apkopojums par aparatÅ«ru, programmatÅ«ru, sistēmas metriku un mÅ«su veco Munin uzraudzÄ«bas sistēmu (tā mums darbojās lÄ«dz 2015. gadam). Mēs to visu apkopojam, izmantojot C dēmonu CollectD (tajā ir iebÅ«vēts vesels virkne dažādu spraudņu, tas var aptaujāt visus resursdatora sistēmas resursus, kurā tas ir instalēts, tikai konfigurācijā norādiet, kur rakstÄ«t datus) un caur to ierakstiet datus Graphite. Tas atbalsta arÄ« python spraudņus un čaulas skriptus, lai jÅ«s varētu rakstÄ«t savus pielāgotos risinājumus: CollectD apkopos Å”os datus no vietējā vai attālā resursdatora (pieņemot, ka Curl) un nosÅ«tÄ«s tos Graphite.

Pēc tam mēs nosÅ«tām visus apkopotos rādÄ«tājus uz Carbon-c-relay. Å is ir Carbon Relay risinājums no Graphite, kas modificēts C valodā. Å is ir marÅ”rutētājs, kas apkopo visus datus, ko mēs nosÅ«tām no mÅ«su apkopotājiem, un novirza tos uz mezgliem. ArÄ« marÅ”rutÄ“Å”anas posmā tā pārbauda metrikas derÄ«gumu. Pirmkārt, tiem jāatbilst prefiksu shēmai, kuru es parādÄ«ju iepriekÅ”, un, otrkārt, tie ir derÄ«gi grafÄ«tam. Pretējā gadÄ«jumā tie nokritÄ«s.

Pēc tam oglekļa-c-relejs nosÅ«ta metriku uz grafÄ«ta kopu. Kā galveno metrikas krātuvi mēs izmantojam Carbon-keÅ”atmiņu, kas ir pārrakstÄ«ta programmā Go. Go-carbon tā daudzpavedienu dēļ ievērojami pārspēj Carbon-keÅ”atmiņu. Tas saņem datus un ieraksta tos diskos, izmantojot čukstu pakotni (standarta, rakstÄ«ts python). Lai nolasÄ«tu datus no mÅ«su krātuvēm, mēs izmantojam Graphite API. Tas ir daudz ātrāk nekā standarta Graphite WEB. Kas notiks ar datiem tālāk?

Viņi dodas uz Grafānu. Mēs izmantojam mÅ«su grafÄ«ta kopas kā galveno datu avotu, kā arÄ« mums ir Grafana kā tÄ«mekļa saskarne metrikas attēloÅ”anai un informācijas paneļu izveidei. Katram pakalpojumam izstrādātāji izveido savu informācijas paneli. Pēc tam viņi, pamatojoties uz tiem, veido diagrammas, kurās tiek parādÄ«ta metrika, ko viņi raksta no savām lietojumprogrammām. Papildus Grafana mums ir arÄ« SLAM. Å is ir pitona dēmons, kas aprēķina SLA, pamatojoties uz datiem no grafÄ«ta. Kā jau teicu, mums ir vairāki desmiti mikropakalpojumu, no kuriem katram ir savas prasÄ«bas. Izmantojot SLAM, mēs pārejam uz dokumentāciju un salÄ«dzinām to ar Graphite saturu un salÄ«dzinām, cik labi prasÄ«bas atbilst mÅ«su pakalpojumu pieejamÄ«bai.

Dosimies tālāk: brÄ«dinājums. Tas tiek organizēts, izmantojot spēcÄ«gu sistēmu - Moira. Tas ir neatkarÄ«gs, jo tam zem pārsega ir savs grafÄ«ts. IzstrādājuÅ”i puiÅ”i no SKB "Kontur", rakstÄ«ts python un Go, pilnÄ«bā atvērtā koda valodā. Moira saņem tādu paÅ”u plÅ«smu, kas nonāk grafÄ«tos. Ja kāda iemesla dēļ jÅ«su krātuve tiek pārtraukta, jÅ«su brÄ«dinājums joprojām darbosies.

Mēs izvietojām Moira Kubernetes; tā kā galveno datu bāzi izmanto Redis serveru kopu. Rezultāts bija pret defektiem izturīga sistēma. Tas salīdzina metrikas straumi ar aktivizētāju sarakstu: ja tajā nav pieminējumu, metrika tiek noņemta. Tātad tas spēj sagremot gigabaitus metrikas minūtē.

Tam pievienojām arÄ« korporatÄ«vo LDAP, ar kura palÄ«dzÄ«bu katrs korporatÄ«vās sistēmas lietotājs var izveidot sev paziņojumus, pamatojoties uz esoÅ”ajiem (vai jaunizveidotajiem) trigeriem. Tā kā Moira satur grafÄ«tu, tas atbalsta visas tā funkcijas. Tāpēc vispirms paņemiet lÄ«niju un iekopējiet to Grafana. Skatiet, kā dati tiek parādÄ«ti grafikos. Un tad jÅ«s paņemat to paÅ”u rindiņu un iekopējat to Moirā. JÅ«s pakārt to ar ierobežojumiem un saņemat brÄ«dinājumu pie izejas. Lai to visu izdarÄ«tu, jums nav vajadzÄ«gas Ä«paÅ”as zināŔanas. Moira var brÄ«dināt, izmantojot SMS, e-pastu, Jira, Slack... Tā atbalsta arÄ« pielāgotu skriptu izpildi. Kad ar viņu notiek trigeris un viņa ir abonējusi pielāgotu skriptu vai bināru, viņa to palaiž un nosÅ«ta JSON uz Å”o bināro failu stdin. AttiecÄ«gi jÅ«su programmai tas ir jāparsē. Tas, ko darÄ«sit ar Å”o JSON, ir atkarÄ«gs no jums. Ja vēlaties, nosÅ«tiet uz Telegram, ja vēlaties, atveriet uzdevumus Jirā, dariet visu.

Mēs arÄ« izmantojam savu izstrādāto brÄ«dinājumu - Imagotag. Paneli, ko parasti izmanto elektroniskajām cenu zÄ«mēm veikalos, pielāgojām savām vajadzÄ«bām. Mēs atvedām no Moiras uz to. Tas norāda, kādā stāvoklÄ« tie atrodas un kad tie raduÅ”ies. Daži izstrādātāji atteicās no paziņojumiem Slack un e-pasta ziņojumos par labu Å”im panelim.

Monitorings kā pakalpojums: modulāra sistēma mikropakalpojumu arhitektūrai

Nu tā kā esam progresÄ«vs uzņēmums, tad Kubernetes arÄ« uzraudzÄ«jām Å”ajā sistēmā. Mēs to iekļāvām sistēmā, izmantojot Heapster, kuru uzstādÄ«jām klasterÄ«, tas apkopo datus un nosÅ«ta tos uz Graphite. Rezultātā diagramma izskatās Ŕādi:

Monitorings kā pakalpojums: modulāra sistēma mikropakalpojumu arhitektūrai

Uzraudzības komponenti

Å eit ir saraksts ar saitēm uz komponentiem, kurus izmantojām Å”im uzdevumam. Visi no tiem ir atvērtā koda.

Grafīts:

Oglekļa-c relejs:

github.com/grobian/carbon-c-relay

Brubeka:

github.com/github/brubeck

Savākts:

collectiond.org

Moira:

github.com/moira-alert

Grafana:

grafana.com

Heapster:

github.com/kubernetes/heapster

Statistika

Un Å”eit ir daži skaitļi par to, kā sistēma darbojas mÅ«su labā.

Apkopotājs (Brubeck)

Metrikas skaits: ~300 000/sek
Intervāls metrikas nosūtīŔanai uz Graphite: 30 sek
Servera resursu izmantoÅ”ana: ~ 6% CPU (runa ir par pilnvērtÄ«giem serveriem); ~ 1Gb RAM; ~3 Mb/s LAN

Grafīts (ogleklis)

Metrikas skaits: ~ 1 600 000 / min
Metrikas atjaunināŔanas intervāls: 30 sek
Metrikas glabāŔanas shēma: 30 s 35 d, 5 min 90 d, 10 min 365 d (nodroÅ”ina izpratni par to, kas notiek ar pakalpojumu ilgākā laika periodā)
Servera resursu lietojums: ~10% CPU; ~ 20Gb RAM; ~30 Mbps LAN

Elastīgums

Mēs, Avito, ļoti novērtējam mÅ«su uzraudzÄ«bas pakalpojuma elastÄ«bu. Kāpēc viņŔ patiesÄ«bā izrādÄ«jās tāds? Pirmkārt, tā sastāvdaļas ir savstarpēji aizvietojamas: gan paÅ”as sastāvdaļas, gan to versijas. Otrkārt, atbalstāmÄ«ba. Tā kā viss projekts ir atvērtā koda avots, varat pats rediģēt kodu, veikt izmaiņas un ieviest funkcijas, kas nav pieejamas. Tiek izmantoti diezgan izplatÄ«ti skursteņi, galvenokārt Go un Python, tāpēc tas tiek darÄ«ts pavisam vienkārÅ”i.

Å eit ir reālas problēmas piemērs. Graphite metrika ir fails. Tam ir nosaukums. Faila nosaukums = metrikas nosaukums. Un ir veids, kā tur nokļūt. Linux failu nosaukumi ir ierobežoti lÄ«dz 255 rakstzÄ«mēm. Un mums ir (kā ā€œiekŔējie klientiā€) puiÅ”i no datu bāzes nodaļas. Viņi mums saka: ā€œMēs vēlamies pārraudzÄ«t savus SQL vaicājumus. Un tie nav 255 rakstzÄ«mes, bet katrs 8 MB. Mēs vēlamies tos parādÄ«t Grafana, redzēt Ŕī pieprasÄ«juma parametrus un vēl labāk, mēs vēlamies redzēt Ŕādu pieprasÄ«jumu augŔējo daļu. Tas bÅ«s lieliski, ja tas tiks parādÄ«ts reāllaikā. BÅ«tu ļoti forÅ”i viņus brÄ«dināt.

Monitorings kā pakalpojums: modulāra sistēma mikropakalpojumu arhitektūrai
SQL vaicājuma piemērs ir ņemts kā piemērs no vietne postgrespro.ru

Mēs uzstādām Redis serveri un izmantojam mÅ«su Collectd spraudņus, kas nonāk Postgres un no turienes paņem visus datus, nosÅ«tot metriku uz Graphite. Bet metrikas nosaukumu mēs aizstājam ar jaucējzÄ«mēm. Mēs vienlaikus nosÅ«tām to paÅ”u jaucējkodu Redis kā atslēgu un visu SQL vaicājumu kā vērtÄ«bu. Mums tikai jāpārliecinās, ka Grafana var doties uz Redisu un paņemt Å”o informāciju. Mēs atveram Graphite API, jo... Ŕī ir galvenā saskarne visu uzraudzÄ«bas komponentu mijiedarbÄ«bai ar grafÄ«tu, un mēs tur ievadām jaunu funkciju ar nosaukumu aliasByHash() - no Grafana mēs iegÅ«stam metrikas nosaukumu un izmantojam to pieprasÄ«jumā Redis kā atslēgu. atbildē mēs iegÅ«stam atslēgas vērtÄ«bu, kas ir mÅ«su ā€œSQL vaicājumsā€ Tādējādi mēs Grafana parādÄ«jām SQL vaicājuma displeju, kuru teorētiski tur nebija iespējams parādÄ«t, kopā ar statistiku par to (zvani, rindas, kopējais_laiks, ...).

Rezultāti

Pieejamība. Mūsu uzraudzības pakalpojums ir pieejams 24/7 no jebkuras lietojumprogrammas un jebkura koda. Ja jums ir piekļuve krātuvēm, varat ierakstīt datus pakalpojumā. Valoda nav svarīga, lēmumi nav svarīgi. Jums tikai jāzina, kā atvērt kontaktligzdu, ievietot tur metriku un aizvērt ligzdu.

Uzticamību. Visas sastāvdaļas ir izturīgas pret defektiem un labi iztur mūsu kravas.

Zema barjera ienākÅ”anai. Lai izmantotu Å”o sistēmu, Grafana nav jāapgÅ«st programmÄ“Å”anas valodas un vaicājumi. VienkārÅ”i atveriet savu lietojumprogrammu, ievadiet tajā ligzdu, kas nosÅ«tÄ«s metriku uz Graphite, aizveriet to, atveriet Grafana, izveidojiet tur informācijas paneļus un apskatiet savu metrikas darbÄ«bu, saņemot paziņojumus, izmantojot Moira.

NeatkarÄ«ba. To visu varat izdarÄ«t pats, neizmantojot DevOps inženieru palÄ«dzÄ«bu. Un tā ir priekÅ”rocÄ«ba, jo jÅ«s varat uzraudzÄ«t savu projektu jau tagad, jums nav nevienam jālÅ«dz - ne sākt darbu, ne veikt izmaiņas.

Uz ko mēs tiecamies?

Viss, kas uzskaitīts zemāk, nav tikai abstraktas domas, bet gan kaut kas, uz ko ir sperti vismaz pirmie soļi.

  1. Anomāliju detektors. Mēs vēlamies izveidot pakalpojumu, kas nonāks mūsu grafīta krātuvēs un pārbaudīs katru metriku, izmantojot dažādus algoritmus. Jau ir algoritmi, kurus gribam apskatīt, ir dati, mēs zinām, kā ar tiem strādāt.
  2. Metadati. Mums ir daudz pakalpojumu, tie laika gaitā mainās, tāpat kā cilvēki, kas ar tiem strādā. PastāvÄ«ga dokumentācijas manuāla uzturÄ“Å”ana nav risinājums. Tāpēc tagad savos mikropakalpojumos ievietojam metadatus. Tajā ir norādÄ«ts, kas to izstrādājis, valodas, ar kurām tas mijiedarbojas, SLA prasÄ«bas, kur un kam jānosÅ«ta paziņojumi. Izvietojot pakalpojumu, visi entÄ«tijas dati tiek izveidoti neatkarÄ«gi. Rezultātā jÅ«s saņemat divas saites ā€” vienu uz aktivizētājiem, otru ā€” uz Grafana informācijas paneļiem.
  3. UzraudzÄ«ba katrā mājā. Mēs uzskatām, ka visiem izstrādātājiem ir jāizmanto Ŕāda sistēma. Å ajā gadÄ«jumā jÅ«s vienmēr saprotat, kur atrodas jÅ«su satiksme, kas ar to notiek, kur tā krÄ«t, kur ir tās vājās vietas. Ja, piemēram, kaut kas atnāk un avarē jÅ«su pakalpojumu, tad par to uzzināsiet nevis pārziņa zvana laikā, bet gan brÄ«dinājuma laikā, un uzreiz varēsiet atvērt jaunākos žurnālus un redzēt, kas tur noticis.
  4. Augsta veiktspēja. MÅ«su projekts pastāvÄ«gi attÄ«stās, un Å”odien tas apstrādā aptuveni 2 000 000 metriskās vērtÄ«bas minÅ«tē. Pirms gada Å”is skaitlis bija 500 000. Un izaugsme turpinās, un tas nozÄ«mē, ka pēc kāda laika GrafÄ«ts (čuksts) sāks smagi noslogot diska apakÅ”sistēmu. Kā jau teicu, Ŕī uzraudzÄ«bas sistēma ir diezgan universāla, pateicoties komponentu savstarpējai aizvietojamÄ«bai. Kāds uztur un pastāvÄ«gi paplaÅ”ina savu infrastruktÅ«ru tieÅ”i Graphite, taču mēs nolēmām iet citu ceļu: izmantot NoklikŔķiniet uz Māja kā mÅ«su metrikas krātuve. Å Ä« pāreja ir gandrÄ«z pabeigta, un pavisam drÄ«z es jums pastāstÄ«Å”u sÄ«kāk, kā tas tika izdarÄ«ts: kādas grÅ«tÄ«bas bija un kā tās tika pārvarētas, kā noritēja migrācijas process, aprakstÄ«Å”u kā saistoÅ”os izvēlētos komponentus un to konfigurācijas.

Paldies par jÅ«su uzmanÄ«bu! Uzdodiet savus jautājumus par tēmu, es mēģināŔu atbildēt Å”eit vai turpmākajos ierakstos. VarbÅ«t kādam ir pieredze lÄ«dzÄ«gas uzraudzÄ«bas sistēmas veidoÅ”anā vai lÄ«dzÄ«gā situācijā pārejot uz Clickhouse - padalieties komentāros.

Avots: www.habr.com

Pievieno komentāru