Kā mēs izveidojām uzraudzību uz Prometheus, Clickhouse un ELK

Mani sauc Antons Baderins. Strādāju Augsto tehnoloÄ£iju centrā un nodarbojos ar sistēmu administrÄ“Å”anu. Pirms mēneÅ”a noslēdzās mÅ«su korporatÄ«vā konference, kurā dalÄ«jāmies savā uzkrātajā pieredzē ar mÅ«su pilsētas IT kopienu. Es runāju par tÄ«mekļa lietojumprogrammu uzraudzÄ«bu. Materiāls bija paredzēts jaunākajam vai vidējam lÄ«menim, kuri Å”o procesu nebÅ«vēja no nulles.

Kā mēs izveidojām uzraudzību uz Prometheus, Clickhouse un ELK

Jebkuras uzraudzÄ«bas sistēmas stÅ«rakmens ir uzņēmējdarbÄ«bas problēmu risināŔana. Monitorings monitoringa dēļ nevienu neinteresē. Ko vēlas bizness? Lai viss darbotos ātri un bez kļūdām. Uzņēmumi vēlas bÅ«t proaktÄ«vi, lai mēs paÅ”i identificētu pakalpojuma problēmas un pēc iespējas ātrāk tās novērstu. PatiesÄ«bā Ŕīs ir problēmas, kuras es visu pagājuÅ”o gadu atrisināju vienam no mÅ«su klientiem paredzētā projekta ietvaros.

Par projektu

Projekts ir viena no lielākajām lojalitātes programmām valstÄ«. Mēs palÄ«dzam mazumtirdzniecÄ«bas ķēdēm palielināt pārdoÅ”anas biežumu, izmantojot dažādus mārketinga rÄ«kus, piemēram, bonusa kartes. Kopumā projektā iekļautas 14 lietojumprogrammas, kas darbojas uz desmit serveriem.

Intervijas laikā es vairākkārt pamanīju, ka administratori ne vienmēr pareizi pieiet tīmekļa lietojumprogrammu uzraudzībai: daudzi joprojām koncentrējas uz operētājsistēmas metriku un laiku pa laikam uzrauga pakalpojumus.

Manā gadÄ«jumā klienta uzraudzÄ«bas sistēma iepriekÅ” bija balstÄ«ta uz Icinga. Tas nekādā veidā neatrisināja iepriekÅ” minētās problēmas. Bieži vien klients pats mÅ«s informēja par problēmām, un visbiežāk mums vienkārÅ”i nebija pietiekami daudz datu, lai noskaidrotu iemeslu.

Turklāt bija skaidra izpratne par tās turpmākās attīstības veltīgumu. Domāju, ka tie, kas pazīst Icingu, mani sapratīs. Tāpēc mēs nolēmām pilnībā pārveidot tīmekļa lietojumprogrammu uzraudzības sistēmu projektam.

Prometejs

Mēs izvēlējāmies Prometheus, pamatojoties uz trim galvenajiem rādītājiem:

  1. Liels skaits pieejamo rādÄ«tāju. MÅ«su gadÄ«jumā tādu ir 60 tÅ«kstoÅ”i. Protams, ir vērts atzÄ«mēt, ka lielāko daļu no tiem mēs neizmantojam (iespējams, apmēram 95%). No otras puses, tie visi ir salÄ«dzinoÅ”i lēti. Mums Ŕī ir otra galējÄ«ba, salÄ«dzinot ar iepriekÅ” lietoto Icinga. Tajā metrikas pievienoÅ”ana bija Ä«paÅ”i sāpÄ«ga: esoÅ”ie bija dārgi (tikai paskatieties uz jebkura spraudņa pirmkodu). JebkurÅ” spraudnis bija Bash vai Python skripts, kura palaiÅ”ana ir dārga patērēto resursu ziņā.
  2. Å Ä« sistēma patērē salÄ«dzinoÅ”i nelielu resursu daudzumu. Visiem mÅ«su rādÄ«tājiem pietiek ar 600 MB RAM, 15% no viena kodola un pāris desmitiem IOPS. Protams, jums ir jāvada metriku eksportētāji, taču tie visi ir rakstÄ«ti Go un arÄ« nav ļoti izsalkuÅ”i. Es nedomāju, ka mÅ«sdienu realitātē tā ir problēma.
  3. NodroÅ”ina iespēju migrēt uz Kubernetes. Ņemot vērā klienta plānus, izvēle ir acÄ«mredzama.

ELK

IepriekÅ” mēs neapkopojām un neapstrādājām žurnālus. TrÅ«kumi ir skaidri visiem. Mēs izvēlējāmies ELK, jo mums jau bija pieredze ar Å”o sistēmu. Mēs tur glabājam tikai lietojumprogrammu žurnālus. Galvenie atlases kritēriji bija pilna teksta meklÄ“Å”ana un tās ātrums.

Š”lickhouse

Sākotnēji izvēle krita uz InfluxDB. Mēs sapratām, ka ir jāapkopo Nginx žurnāli, statistika no pg_stat_statements un jāsaglabā Prometheus vēsturiskie dati. Mums nepatika Influx, jo tas periodiski sāka patērēt lielu daudzumu atmiņas un avarēja. Turklāt es gribēju grupēt vaicājumus pēc remote_addr, bet grupÄ“Å”ana Å”ajā DBVS notiek tikai pēc tagiem. Birkas ir dārgas (atmiņa), to skaits ir nosacÄ«ti ierobežots.

Atkal sākām meklējumus. Bija nepiecieÅ”ama analÄ«tiska datu bāze ar minimālu resursu patēriņu, vēlams ar datu saspieÅ”anu diskā.

Clickhouse atbilst visiem Å”iem kritērijiem, un mēs nekad neesam nožēlojuÅ”i savu izvēli. Mēs tajā neierakstām nekādus ārkārtējus datu apjomus (ievietojumu skaits ir tikai aptuveni pieci tÅ«kstoÅ”i minÅ«tē).

NewRelic

NewRelic vēsturiski ir bijis ar mums, jo tā bija klienta izvēle. Mēs to izmantojam kā APM.

Zabbix

Mēs izmantojam Zabbix tikai, lai uzraudzītu dažādu API Black Box.

Uzraudzības pieejas definēŔana

Mēs vēlējāmies sadalīt uzdevumu un tādējādi sistematizēt pieeju monitoringam.

Lai to izdarÄ«tu, es sadalÄ«ju mÅ«su sistēmu Ŕādos lÄ«meņos:

  • aparatÅ«ra un VMS;
  • operētājsistēma;
  • sistēmas pakalpojumi, programmatÅ«ras steks;
  • pieteikums;
  • biznesa loÄ£ika.

Kāpēc Ŕī pieeja ir ērta:

  • mēs zinām, kurÅ” ir atbildÄ«gs par katra lÄ«meņa darbu, un, pamatojoties uz to, mēs varam nosÅ«tÄ«t brÄ«dinājumus;
  • mēs varam izmantot struktÅ«ru, apspiežot brÄ«dinājumus - bÅ«tu dÄ«vaini nosÅ«tÄ«t brÄ«dinājumu par datu bāzes nepieejamÄ«bu, ja virtuālā maŔīna kopumā nav pieejama.

Tā kā mÅ«su uzdevums ir identificēt pārkāpumus sistēmas darbÄ«bā, tad katrā lÄ«menÄ« ir jāizceļ noteikta metriku kopa, kurai ir vērts pievērst uzmanÄ«bu, rakstot brÄ«dināŔanas noteikumus. Tālāk apskatÄ«sim lÄ«meņus ā€œVMSā€, ā€œOperētājsistēmaā€ un ā€œSistēmas pakalpojumi, programmatÅ«ras steksā€.

Virtuālās maŔīnas

Hostings pieŔķir mums procesoru, disku, atmiņu un tÄ«klu. Un mums bija problēmas ar pirmajiem diviem. Tātad, rādÄ«tāji:

CPU nozagÅ”anas laiks - pērkot virtuālo maŔīnu Amazon (piemēram, t2.micro), jums jāsaprot, ka jums nav atvēlēts viss procesora kodols, bet tikai tā laika kvota. Un, kad jÅ«s to iztērēsit, procesors jums tiks atņemts.

Å is rādÄ«tājs ļauj izsekot Ŕādiem brīžiem un pieņemt lēmumus. Piemēram, vai ir jāņem trekns tarifs vai jāizplata fona uzdevumu un API pieprasÄ«jumu apstrāde dažādiem serveriem?

IOPS + CPU gaidÄ«Å”anas laiks ā€” kāda iemesla dēļ daudzi mākoņa mitināŔanas pakalpojumi grēko, nenodroÅ”inot pietiekami daudz IOPS. Turklāt grafiks ar zemu IOPS viņiem nav arguments. Tāpēc ir vērts savākt CPU iowait. Izmantojot Å”o grafiku pāri ā€” ar zemu IOPS un lielu I/O gaidÄ«Å”anas laiku ā€” jÅ«s jau varat runāt ar mitināŔanu un atrisināt problēmu.

Operētājsistēmas

Operētājsistēmas rādītāji:

  • pieejamās atmiņas apjoms %;
  • mijmaiņas izmantoÅ”anas aktivitāte: vmstat swapin, swapout;
  • pieejamo inodu skaits un brÄ«vā vieta failu sistēmā %
  • vidējā slodze;
  • savienojumu skaits tw stāvoklÄ«;
  • conntrack galda pilnÄ«ba;
  • TÄ«kla kvalitāti var uzraudzÄ«t, izmantojot ss utilÄ«tu, iproute2 pakotni - iegÅ«stiet RTT savienojumu indikatoru no tā izvades un grupējiet to pēc gala porta.

Arī operētājsistēmas līmenī mums ir tāda entītija kā procesi. Sistēmā ir svarīgi identificēt procesu kopumu, kam ir svarīga loma tās darbībā. Ja, piemēram, jums ir vairāki pgpool, tad jums ir jāapkopo informācija par katru no tiem.

Metrikas kopa ir Ŕāda:

  • PROCESORS;
  • atmiņa galvenokārt ir pastāvÄ«ga;
  • IO - vēlams IOPS;
  • FileFd - atvērts un ierobežots;
  • bÅ«tiskas lapas kļūmes ā€“ tādā veidā var saprast, kāds process tiek apmainÄ«ts.

Mēs izvietojam visu uzraudzību programmā Docker, un mēs izmantojam Advisor, lai apkopotu metrikas datus. Citās iekārtās mēs izmantojam procesa eksportētāju.

Sistēmas pakalpojumi, programmatūras kaudze

Katrai lietojumprogrammai ir sava specifika, un ir grūti izcelt konkrētu metrikas kopu.

Universālais komplekts ir:

  • pieprasÄ«juma likme;
  • kļūdu skaits;
  • latentums;
  • piesātinājums.

MÅ«su spilgtākie uzraudzÄ«bas piemēri Å”ajā lÄ«menÄ« ir Nginx un PostgreSQL.

Visvairāk ielādēts pakalpojums mūsu sistēmā ir datu bāze. Agrāk mums bieži bija problēmas noskaidrot, ko dara datubāze.

Mēs redzējām lielu disku slodzi, bet lēnie žurnāli Ä«sti neko nerādÄ«ja. Mēs atrisinājām Å”o problēmu, izmantojot pg_stat_statements ā€” skatu, kas apkopo vaicājumu statistiku.

Tas ir viss, kas nepiecieŔams administratoram.

Mēs veidojam lasÄ«Å”anas un rakstÄ«Å”anas pieprasÄ«jumu aktivitāŔu grafikus:

Kā mēs izveidojām uzraudzību uz Prometheus, Clickhouse un ELK
Kā mēs izveidojām uzraudzību uz Prometheus, Clickhouse un ELK

Viss ir vienkārŔi un skaidri, katram pieprasījumam ir sava krāsa.

Tikpat spilgts piemērs ir Nginx žurnāli. Nav pārsteidzoÅ”i, ka daži cilvēki tos analizē vai piemin obligātajā sarakstā. Standarta formāts nav Ä«paÅ”i informatÄ«vs, un tas ir jāpaplaÅ”ina.

Es personīgi pievienoju request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Mēs attēlojam atbildes laiku un kļūdu skaitu:

Kā mēs izveidojām uzraudzību uz Prometheus, Clickhouse un ELK
Kā mēs izveidojām uzraudzību uz Prometheus, Clickhouse un ELK

Mēs veidojam reakcijas laika un kļūdu skaita grafikus. Atceries? Vai es runāju par biznesa uzdevumiem? Ātri un bez kļūdām? Mēs jau esam aplÅ«kojuÅ”i Å”os jautājumus ar divām diagrammām. Un ar to palÄ«dzÄ«bu jau var zvanÄ«t dežurējoÅ”ajiem administratoriem.

Taču paliek vēl viena problēma ā€“ nodroÅ”ināt ātru incidenta cēloņu novērÅ”anu.

Negadījuma atrisināŔana

Visu procesu no problēmas noteikÅ”anas lÄ«dz tās risināŔanai var iedalÄ«t vairākos posmos:

  • problēmas identificÄ“Å”ana;
  • paziņojums dežūras administratoram;
  • reakcija uz incidentu;
  • cēloņu likvidÄ“Å”ana.

Ir svarÄ«gi, lai mums tas jādara pēc iespējas ātrāk. Un, ja problēmas identificÄ“Å”anas un paziņojuma nosÅ«tÄ«Å”anas posmā mēs nevaram iegÅ«t daudz laika - jebkurā gadÄ«jumā tām tiks veltÄ«tas divas minÅ«tes, tad nākamās ir vienkārÅ”i neapstrādāts lauks uzlabojumiem.

Iedomāsimies, ka iezvanÄ«jās dežuranta telefons. Ko viņŔ darÄ«s? Meklē atbildes uz jautājumiem ā€“ kas salÅ«za, kur salÅ«za, kā reaģēt? LÅ«k, kā mēs atbildam uz Å”iem jautājumiem:

Kā mēs izveidojām uzraudzību uz Prometheus, Clickhouse un ELK

Mēs vienkārÅ”i iekļaujam visu Å”o informāciju paziņojuma tekstā, sniedzam tai saiti uz wiki lapu, kurā ir aprakstÄ«ts, kā reaģēt uz Å”o problēmu, kā to atrisināt un eskalēt.

Es joprojām neko neesmu teicis par lietojumprogrammas slāni un biznesa loÄ£iku. Diemžēl mÅ«su lietojumprogrammās vēl nav ieviesta metrikas vākÅ”ana. VienÄ«gais informācijas avots no Å”iem lÄ«meņiem ir žurnāli.

Pāris punkti.

Pirmkārt, uzrakstiet strukturētus žurnālus. Ziņojuma tekstā nav jāiekļauj konteksts. Tas apgrÅ«tina to grupÄ“Å”anu un analizÄ“Å”anu. Logstash prasa ilgu laiku, lai to visu normalizētu.

Otrkārt, pareizi izmantojiet smaguma pakāpes. Katrai valodai ir savs standarts. PersonÄ«gi es izŔķiru četrus lÄ«meņus:

  1. nav kļūdu;
  2. klienta puses kļūda;
  3. kļūda ir mūsu pusē, mēs nezaudējam naudu, mēs neuzņemamies risku;
  4. Kļūda ir mūsu pusē, mēs zaudējam naudu.

Ä»aujiet man apkopot. Jums jāmēģina izveidot uzraudzÄ«bu, pamatojoties uz biznesa loÄ£iku. Mēģiniet uzraudzÄ«t paÅ”u lietojumprogrammu un darboties ar tādiem rādÄ«tājiem kā pārdoÅ”anas skaits, jaunu lietotāju reÄ£istrāciju skaits, paÅ”laik aktÄ«vo lietotāju skaits utt.

Ja viss jÅ«su uzņēmums pārlÅ«kprogrammā ir viena poga, jums jāuzrauga, vai tas noklikŔķina un darbojas pareizi. Visam pārējam nav nozÄ«mes.

Ja jums tas nav, varat mēģināt to atrast lietojumprogrammu žurnālos, Nginx žurnālos un tā tālāk, kā mēs to darījām. Jums jāatrodas pēc iespējas tuvāk lietojumprogrammai.

Operētājsistēmas rādītāji, protams, ir svarīgi, taču biznesu tie neinteresē, mums par tiem nemaksā.

Avots: www.habr.com

Pievieno komentāru