Myn namme is Anton Baderin. Ik wurkje by it High Technology Center en doch systeemadministraasje. In moanne lyn einige ús bedriuwskonferinsje, wêr't wy ús sammele ûnderfining dielde mei de IT-mienskip fan ús stêd. Ik hie it oer it kontrolearjen fan webapplikaasjes. It materiaal wie bedoeld foar junior of middelbere nivo, dy't net bouwe dit proses fanôf it begjin.
De hoekstien ûnderlizzende elk tafersjochsysteem is it oplossen fan saaklike problemen. Tafersjoch omwille fan tafersjoch is foar gjinien fan belang. Wat wol it bedriuw? Sadat alles wurket fluch en sûnder flaters. Bedriuwen wolle proaktyf wêze, sadat wy sels problemen yn 'e tsjinst identifisearje en sa gau mooglik oplosse. Dit binne trouwens de problemen dy't ik it hiele jier oplost haw op in projekt foar ien fan ús klanten.
Oer it projekt
It projekt is ien fan de grutste loyaliteit programma yn it lân. Wy helpe detailhannel keatlingen fergrutsje de frekwinsje fan ferkeap troch ferskate marketing ark lykas bonus kaarten. Yn totaal omfettet it projekt 14 applikaasjes dy't rinne op tsien servers.
Tidens it ynterviewproses haw ik ferskate kearen opmurken dat admins it kontrolearjen fan webapplikaasjes net altyd korrekt benaderje: in protte rjochtsje har noch op bestjoeringssysteemmetriken en kontrolearje soms tsjinsten.
Yn myn gefal wie it tafersjochsysteem fan 'e klant earder basearre op Icinga. It hat de boppesteande problemen op gjin inkelde manier oplost. Faak hat de klant ús sels ynformearre oer problemen, en faker as net hiene wy gewoan net genôch gegevens om nei de boaiem fan 'e reden te kommen.
Dêrneist wie der in dúdlik begryp fan 'e nutteloosheid fan syn fierdere ûntwikkeling. Ik tink dat dyjingen dy't bekend binne mei Icinga my sille begripe. Dat, wy besletten om it tafersjochsysteem foar webapplikaasje foar it projekt folslein opnij te ûntwerpen.
Prometheus
Wy hawwe Prometheus keazen op basis fan trije haadyndikatoaren:
- In grut oantal beskikbere metriken. Yn ús gefal binne der 60 tûzen fan harren. Fansels is it de muoite wurdich op te merken dat wy de grutte mearderheid fan har net brûke (wierskynlik sawat 95%). Oan 'e oare kant binne se allegear relatyf goedkeap. Foar ús is dit it oare ekstreem yn ferliking mei de earder brûkte Icinga. Dêryn wie it tafoegjen fan metriken in bysûndere pine: de besteande wiene djoer (sjoch gewoan nei de boarnekoade fan elke plugin). Elke plugin wie in skript yn Bash of Python, wêrfan de lansearring djoer is yn termen fan konsumeare boarnen.
- Dit systeem ferbrûkt in relatyf lyts bedrach fan boarnen. 600 MB RAM, 15% fan ien kearn en in pear tsientallen IOPS binne genôch foar al ús metriken. Fansels moatte jo metrike eksporteurs útfiere, mar se binne allegear skreaun yn Go en binne ek net heul machtich. Ik tink net dat dit yn moderne realiteiten in probleem is.
- Biedt de mooglikheid om te migrearjen nei Kubernetes. Sjoen de plannen fan de klant is de kar fanselssprekkend.
ELK
Earder hawwe wy gjin logs sammele of ferwurke. De tekoartkommingen binne foar elkenien dúdlik. Wy hawwe ELK keazen om't wy al ûnderfining hiene mei dit systeem. Wy bewarje dêr allinich applikaasjelogboeken. De wichtichste seleksjekritearia wiene folsleine tekstsykjen en de snelheid dêrfan.
Slickhouse
Yn earste ynstânsje foel de kar op InfluxDB. Wy realisearre de needsaak om Nginx-logs te sammeljen, statistiken fan pg_stat_statements, en Prometheus histoaryske gegevens op te slaan. Wy hâlde net fan Influx, om't it periodyk begon in grutte hoemannichte ûnthâld te konsumearjen en ferûngelokke. Derneist woe ik fragen groepearje troch remote_addr, mar groepearje yn dizze DBMS is allinich troch tags. Tags binne djoer (ûnthâld), har oantal is betingst beheind.
Wy begûnen ús syktocht wer. Wat nedich wie wie in analytyske databank mei minimale boarne konsumpsje, leafst mei gegevens kompresje op skiif.
Clickhouse foldocht oan al dizze kritearia, en wy hawwe nea spyt fan ús kar. Wy skriuwe der gjin bûtengewoane hoemannichten gegevens yn (it oantal ynfoegingen is mar sa'n fiif tûzen per minuut).
NewRelic
NewRelic hat histoarysk west by ús omdat it wie de klant syn kar. Wy brûke it as APM.
Zabbix
Wy brûke Zabbix eksklusyf om de Black Box fan ferskate API's te kontrolearjen.
It definiearjen fan in tafersjochoanpak
Wy woenen de taak ûntbine en dêrmei de oanpak fan tafersjoch systematisearje.
Om dit te dwaan, ferdielde ik ús systeem yn 'e folgjende nivo's:
- hardware en VMS;
- bestjoeringssysteem;
- systeem tsjinsten, software stack;
- oanfraach;
- saaklike logika.
Wêrom dizze oanpak handich is:
- wy witte wa't ferantwurdlik is foar it wurk fan elk nivo en op grûn dêrfan kinne wy warskôgings stjoere;
- wy kinne de struktuer brûke by it ûnderdrukken fan warskôgings - it soe nuver wêze om in warskôging te stjoeren oer databankûnbeskikberens as de firtuele masine as gehiel net beskikber is.
Sûnt ús taak is om oertredings te identifisearjen yn 'e wurking fan it systeem, moatte wy op elk nivo in bepaalde set metriken markearje dy't it wurdich binne om omtinken te jaan by it skriuwen fan warskôgingsregels. Litte wy dan troch de nivo's "VMS", "Bestjoeringssysteem" en "Systeemtsjinsten, softwarestapel" gean.
Firtuele masines
Hosting allocates ús in prosessor, skiif, ûnthâld en netwurk. En wy hiene problemen mei de earste twa. Dus, de metriken:
CPU stellen tiid - as jo keapje in firtuele masine op Amazon (t2.micro, bygelyks), Jo moatte begripe dat jo net tawiisd in hiele prosessor kearn, mar allinnich in kwota fan syn tiid. En as jo it útputte, sil de prosessor fan jo ôfnommen wurde.
Dizze metrik lit jo sokke mominten folgje en besluten nimme. Is it bygelyks nedich om in feter taryf te nimmen of de ferwurking fan eftergrûntaken en API-oanfragen te fersprieden nei ferskate servers?
IOPS + CPU wachttiid - om ien of oare reden sûndigje in protte wolkhostings troch net genôch IOPS te leverjen. Boppedat, in skema mei lege IOPS is gjin argumint foar harren. Dêrom is it wurdich sammeljen CPU iowait. Mei dit pear grafiken - mei lege IOPS en hege I / O-wachtsjen - kinne jo al prate mei de hosting en it probleem oplosse.
bestjoeringssysteem
Bestjoeringssysteemmetriken:
- bedrach fan beskikber ûnthâld yn %;
- swap gebrûk aktiviteit: vmstat swapin, swapout;
- oantal beskikbere ynoden en frije romte op it bestânsysteem yn %
- gemiddelde lading;
- oantal ferbinings yn twa steat;
- conntrack tabel folsleinens;
- De kwaliteit fan it netwurk kin wurde kontrolearre mei it ss-hulpprogramma, it iproute2-pakket - krije in yndikator fan RTT-ferbiningen fan syn útfier en groepearje it op dest-poarte.
Ek op it bestjoeringssysteemnivo hawwe wy sa'n entiteit as prosessen. It is wichtich om te identifisearjen yn it systeem in set fan prosessen dy't spylje in wichtige rol yn syn wurking. As jo bygelyks ferskate pgpools hawwe, dan moatte jo ynformaasje sammelje foar elk fan har.
De set fan metriken is as folget:
- CPUs;
- ûnthâld is benammen resident;
- IO - by foarkar yn IOPS;
- FileFd - iepen en limyt;
- signifikante sidefouten - op dizze manier kinne jo begripe hokker proses wurdt wiksele.
Wy sette alle tafersjoch yn Docker yn, en wy brûke Advisor om metrike gegevens te sammeljen. Op oare masines brûke wy proses-eksporteur.
Systeemtsjinsten, softwarestapel
Elke applikaasje hat syn eigen spesifikaasjes, en it is lestich om in spesifike set metriken út te lizzen.
De universele set is:
- fersyk rate;
- oantal flaters;
- latency;
- sêding.
Us meast opfallende foarbylden fan tafersjoch op dit nivo binne Nginx en PostgreSQL.
De meast laden tsjinst yn ús systeem is de databank. Yn it ferline hiene wy faaks problemen om út te finen wat de databank die.
Wy seagen in hege lading op 'e skiven, mar de trage logs lieten neat sjen. Wy hawwe dit probleem oplost mei pg_stat_statements, in werjefte dy't querystatistiken sammelt.
Dat is alles wat de admin nedich hat.
Wy bouwe grafiken fan 'e aktiviteit fan lês- en skriuwfersiken:
Alles is ienfâldich en dúdlik, elk fersyk hat syn eigen kleur.
In like opfallend foarbyld is Nginx-logs. It is net ferrassend dat in pear minsken se parse of neame se yn 'e list fan must-haves. It standertformaat is net heul ynformatyf en moat útwreide wurde.
Persoanlik haw ik request_time, upstream_response_time, body_bytes_sent, request_length, request_id tafoege. Wy plotje reaksjetiid en oantal flaters:
Wy bouwe grafiken fan reaksjetiid en oantal flaters. Unthâld? Ha ik it oer saaklike taken? Om fluch en sûnder flaters? Wy hawwe dizze problemen al behannele mei twa charts. En jo kinne de tsjinstbehearders al belje mei har.
Mar noch ien probleem bliuwt - te garandearjen de flugge eliminaasje fan 'e oarsaken fan it ynsidint.
Incident resolúsje
It hiele proses fan it identifisearjen oant it oplossen fan in probleem kin ferdield wurde yn in oantal stappen:
- identifisearje it probleem;
- melding oan de plichtbehearder;
- reaksje op in ynsidint;
- eliminaasje fan oarsaken.
It is wichtich dat wy dit sa gau mooglik dwaan moatte. En as wy yn 'e stadia fan it identifisearjen fan in probleem en it ferstjoeren fan in notifikaasje net folle tiid winne kinne - yn alle gefallen sille twa minuten oan har wurde bestege, dan wurde de folgjende gewoan fjild foar ferbetteringen unplowed.
Lit ús mar yntinke dat de telefoan fan de tsjinstoffisier gie. Wat sil er dwaan? Sykje nei antwurden op fragen - wat bruts, wêr barde it, hoe reagearje? Hjir is hoe't wy dizze fragen beantwurdzje:
Wy befetsje al dizze ynformaasje gewoan yn 'e tekst fan' e notifikaasje, jouwe it in keppeling nei in wiki-side dy't beskriuwt hoe't jo kinne reagearje op dit probleem, hoe't jo it oplosse kinne en it eskalearje.
Ik haw noch altyd neat sein oer de applikaasjelaach en bedriuwslogika. Spitigernôch implementearje ús applikaasjes noch gjin sammeljen fan metriken. De ienige boarne fan ynformaasje fan dizze nivo's is logs.
In pear punten.
Skriuw earst strukturearre logs. D'r is gjin ferlet om kontekst op te nimmen yn 'e tekst fan it berjocht. Dit makket se lestich te groepearjen en te analysearjen. Logstash duorret in lange tiid om dit alles te normalisearjen.
Twad, brûk de earnstnivo's korrekt. Elke taal hat syn eigen standert. Persoanlik ûnderskiede ik fjouwer nivo's:
- gjin flater;
- client side flater;
- de flater is oan ús kant, wy ferlieze gjin jild, wy drage gjin risiko's;
- De flater is oan ús kant, wy ferlieze jild.
Lit my gearfetsje. Jo moatte besykje tafersjoch op te bouwen basearre op bedriuwslogika. Besykje de applikaasje sels te kontrolearjen en operearje mei sokke metriken as it oantal ferkeapen, it oantal nije brûkersregistraasjes, it oantal op it stuit aktive brûkers, ensfh.
As jo hiele bedriuw ien knop is yn 'e browser, moatte jo kontrolearje oft it klikt en goed wurket. Al de rest makket neat út.
As jo dit net hawwe, kinne jo besykje it yn te heljen yn applikaasjelogs, Nginx-logs, ensafuorthinne, lykas wy diene. Jo moatte sa ticht mooglik by de applikaasje wêze.
Bestjoeringssysteem metrics binne fansels wichtich, mar bedriuw is net ynteressearre yn harren, wy wurde net betelle foar harren.
Boarne: www.habr.com