Ang pangalan ko ay Anton Baderin. Nagtatrabaho ako sa High Technology Center at gumagawa ng system administration. Isang buwan na ang nakalipas, natapos ang aming corporate conference, kung saan ibinahagi namin ang aming naipon na karanasan sa komunidad ng IT ng aming lungsod. Nagsalita ako tungkol sa pagsubaybay sa mga web application. Ang materyal ay inilaan para sa junior o middle level, na hindi nagtayo ng prosesong ito mula sa simula.
Ang pundasyong pinagbabatayan ng anumang sistema ng pagsubaybay ay ang paglutas ng mga problema sa negosyo. Ang pagsubaybay para sa kapakanan ng pagsubaybay ay walang interes sa sinuman. Ano ang gusto ng negosyo? Upang ang lahat ay gumana nang mabilis at walang mga pagkakamali. Nais ng mga negosyo na maging maagap, upang tayo mismo ay matukoy ang mga problema sa serbisyo at ayusin ang mga ito sa lalong madaling panahon. Ito, sa katunayan, ang mga problemang nalutas ko noong nakaraang taon sa isang proyekto para sa isa sa aming mga customer.
tungkol sa
Ang proyekto ay isa sa pinakamalaking loyalty program sa bansa. Tinutulungan namin ang mga retail chain na pataasin ang dalas ng mga benta sa pamamagitan ng iba't ibang tool sa marketing tulad ng mga bonus card. Sa kabuuan, ang proyekto ay may kasamang 14 na application na tumatakbo sa sampung server.
Sa proseso ng pakikipanayam, paulit-ulit kong napansin na ang mga admin ay hindi palaging lumalapit nang tama sa pagsubaybay sa mga web application: marami pa rin ang tumutuon sa mga sukatan ng operating system at paminsan-minsan ay sinusubaybayan ang mga serbisyo.
Sa aking kaso, ang sistema ng pagsubaybay ng customer ay dating nakabatay sa Icinga. Hindi nito nalutas ang mga problema sa itaas sa anumang paraan. Kadalasan ang kliyente mismo ang nagpapaalam sa amin tungkol sa mga problema, at mas madalas kaysa sa hindi, wala kaming sapat na data upang makuha ang ilalim ng dahilan.
Bilang karagdagan, nagkaroon ng malinaw na pag-unawa sa kawalang-saysay ng karagdagang pag-unlad nito. Maiintindihan naman yata ako ng mga pamilyar kay Icinga. Kaya, nagpasya kaming ganap na muling idisenyo ang web application monitoring system para sa proyekto.
Promiteyus
Pinili namin ang Prometheus batay sa tatlong pangunahing tagapagpahiwatig:
- Isang malaking bilang ng mga magagamit na sukatan. Sa aming kaso mayroong 60 libo sa kanila. Siyempre, nararapat na tandaan na hindi namin ginagamit ang karamihan sa mga ito (marahil mga 95%). Sa kabilang banda, lahat sila ay medyo mura. Para sa amin, ito ang iba pang sukdulan kumpara sa dating ginamit na Icinga. Sa loob nito, ang pagdaragdag ng mga sukatan ay isang partikular na sakit: ang mga umiiral na ay mahal (tingnan lamang ang source code ng anumang plugin). Ang anumang plugin ay isang script sa Bash o Python, ang paglulunsad nito ay mahal sa mga tuntunin ng mga mapagkukunang natupok.
- Ang sistemang ito ay gumagamit ng medyo maliit na halaga ng mga mapagkukunan. Ang 600 MB ng RAM, 15% ng isang core at ilang dosenang IOPS ay sapat na para sa lahat ng aming sukatan. Siyempre, kailangan mong magpatakbo ng mga metrics exporter, ngunit lahat sila ay nakasulat sa Go at hindi rin masyadong gutom sa kapangyarihan. Hindi ko iniisip na sa modernong mga katotohanan ito ay isang problema.
- Nagbibigay ng kakayahang mag-migrate sa Kubernetes. Isinasaalang-alang ang mga plano ng customer, ang pagpili ay halata.
ELK
Dati, hindi kami nangongolekta o nagpoproseso ng mga log. Ang mga pagkukulang ay malinaw sa lahat. Pinili namin ang ELK dahil mayroon na kaming karanasan sa sistemang ito. Nag-iimbak lamang kami ng mga log ng aplikasyon doon. Ang pangunahing pamantayan sa pagpili ay full-text na paghahanap at ang bilis nito.
Π‘lickhouse
Sa una, ang pagpipilian ay nahulog sa InfluxDB. Napagtanto namin ang pangangailangang mangolekta ng mga log ng Nginx, istatistika mula sa pg_stat_statements, at mag-imbak ng makasaysayang data ng Prometheus. Hindi namin nagustuhan ang Influx dahil panaka-nakang nagsimula itong kumonsumo ng malaking halaga ng memorya at nag-crash. Bilang karagdagan, gusto kong ipangkat ang mga query sa pamamagitan ng remote_addr, ngunit ang pagpapangkat sa DBMS na ito ay sa pamamagitan lamang ng mga tag. Ang mga tag ay mahal (memorya), ang kanilang bilang ay limitado sa kondisyon.
Sinimulan namin muli ang aming paghahanap. Ang kailangan ay isang analytical database na may kaunting resource consumption, mas mabuti na may data compression sa disk.
Natutugunan ng Clickhouse ang lahat ng pamantayang ito, at hindi namin kailanman pinagsisihan ang aming pinili. Hindi kami nagsusulat ng anumang pambihirang dami ng data dito (ang bilang ng mga pagpapasok ay halos limang libo kada minuto).
NewRelic
Ang NewRelic ay dating kasama namin dahil ito ang pinili ng customer. Ginagamit namin ito bilang isang APM.
Zabbix
Eksklusibong ginagamit namin ang Zabbix para subaybayan ang Black Box ng iba't ibang API.
Pagtukoy ng Pamamaraan sa Pagsubaybay
Nais naming i-decompose ang gawain at sa gayon ay gawing sistematiko ang diskarte sa pagsubaybay.
Upang gawin ito, hinati ko ang aming system sa mga sumusunod na antas:
- hardware at VMS;
- operating system;
- mga serbisyo ng system, software stack;
- aplikasyon;
- lohika ng negosyo.
Bakit maginhawa ang diskarteng ito:
- alam namin kung sino ang responsable para sa gawain ng bawat antas at, batay dito, maaari kaming magpadala ng mga alerto;
- maaari nating gamitin ang istraktura kapag pinipigilan ang mga alerto - kakaibang magpadala ng alerto tungkol sa hindi magagamit ng database kapag hindi available ang virtual machine sa kabuuan.
Dahil ang aming gawain ay tukuyin ang mga paglabag sa pagpapatakbo ng system, dapat naming i-highlight sa bawat antas ang isang tiyak na hanay ng mga sukatan na dapat bigyang pansin kapag nagsusulat ng mga alituntuning nagpapaalerto. Susunod, dumaan tayo sa mga antas ng "VMS", "Operating system" at "System services, software stack".
Mga virtual machine
Ang pagho-host ay naglalaan sa amin ng isang processor, disk, memorya at network. At nagkaroon kami ng mga problema sa unang dalawa. Kaya, ang mga sukatan:
Oras ninakaw ng CPU - kapag bumili ka ng virtual machine sa Amazon (t2.micro, halimbawa), dapat mong maunawaan na hindi ka inilalaan ng isang buong core ng processor, ngunit isang quota lamang ng oras nito. At kapag naubos mo ito, ang processor ay aalisin sa iyo.
Nagbibigay-daan sa iyo ang sukatang ito na subaybayan ang mga ganoong sandali at gumawa ng mga desisyon. Halimbawa, kailangan bang kumuha ng mas mataba na taripa o ipamahagi ang pagproseso ng mga gawain sa background at mga kahilingan sa API sa iba't ibang mga server?
IOPS + CPU iowait time - sa ilang kadahilanan, maraming cloud hosting ang nagkakasala sa hindi pagbibigay ng sapat na IOPS. Bukod dito, ang isang iskedyul na may mababang IOPS ay hindi isang argumento para sa kanila. Samakatuwid, ito ay nagkakahalaga ng pagkolekta ng CPU iowait. Sa pares ng mga graph na ito - na may mababang IOPS at mataas na paghihintay ng I/O - maaari ka nang makipag-usap sa hosting at malutas ang problema.
Operating system
Mga sukatan ng operating system:
- dami ng magagamit na memorya sa %;
- aktibidad sa paggamit ng swap: vmstat swapin, swapout;
- bilang ng mga magagamit na inode at libreng espasyo sa file system sa %
- average na pagkarga;
- bilang ng mga koneksyon sa tw estado;
- conntrack kapunuan ng talahanayan;
- Ang kalidad ng network ay maaaring subaybayan gamit ang ss utility, ang iproute2 package - kumuha ng indicator ng RTT connections mula sa output nito at pangkatin ito ayon sa dest port.
Gayundin sa antas ng operating system mayroon kaming isang entity bilang mga proseso. Mahalagang tukuyin sa system ang isang hanay ng mga proseso na may mahalagang papel sa pagpapatakbo nito. Kung, halimbawa, mayroon kang ilang mga pgpool, kailangan mong mangolekta ng impormasyon para sa bawat isa sa kanila.
Ang hanay ng mga sukatan ay ang mga sumusunod:
- Mga CPU;
- memorya ay pangunahing residente;
- IO - mas mabuti sa IOPS;
- FileFd - bukas at limitahan;
- makabuluhang mga pagkabigo sa pahina - sa paraang ito ay mauunawaan mo kung anong proseso ang pinapalitan.
Idini-deploy namin ang lahat ng pagsubaybay sa Docker, at ginagamit namin ang Advisor upang mangolekta ng data ng mga sukatan. Sa ibang mga makina ginagamit namin ang process-exporter.
Mga serbisyo ng system, stack ng software
Ang bawat application ay may sariling mga detalye, at mahirap mag-isa ng isang partikular na hanay ng mga sukatan.
Ang unibersal na hanay ay:
- rate ng kahilingan;
- bilang ng mga pagkakamali;
- latency;
- saturation
Ang aming pinaka-kapansin-pansin na mga halimbawa ng pagsubaybay sa antas na ito ay Nginx at PostgreSQL.
Ang pinaka-load na serbisyo sa aming system ay ang database. Noong nakaraan, madalas kaming nahihirapang malaman kung ano ang ginagawa ng database.
Nakita namin ang isang mataas na pagkarga sa mga disk, ngunit ang mabagal na mga log ay hindi talaga nagpapakita ng anuman. Nalutas namin ang problemang ito gamit ang pg_stat_statements, isang view na nangongolekta ng mga istatistika ng query.
Iyon lang ang kailangan ng admin.
Bumubuo kami ng mga graph ng aktibidad ng mga kahilingan sa pagbasa at pagsulat:
Ang lahat ay simple at malinaw, ang bawat kahilingan ay may sariling kulay.
Ang isang pantay na kapansin-pansin na halimbawa ay ang mga log ng Nginx. Hindi kataka-taka na kakaunti ang nag-parse sa kanila o nagbabanggit sa kanila sa listahan ng mga dapat na mayroon. Ang karaniwang format ay hindi masyadong nagbibigay-kaalaman at kailangang palawakin.
Sa personal, nagdagdag ako ng request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Nagplano kami ng oras ng pagtugon at bilang ng mga error:
Bumubuo kami ng mga graph ng oras ng pagtugon at bilang ng mga error. Tandaan? Nagsalita ba ako tungkol sa mga layunin ng negosyo? Upang mabilis at walang mga error? Nasaklaw na namin ang mga isyung ito gamit ang dalawang chart. At maaari mo nang tawagan ang mga administrator na naka-duty gamit ang mga ito.
Ngunit isa pang problema ang nananatili - upang matiyak ang mabilis na pag-aalis ng mga sanhi ng insidente.
Resolusyon ng insidente
Ang buong proseso mula sa pagtukoy hanggang sa paglutas ng problema ay maaaring hatiin sa ilang hakbang:
- pagkilala sa problema;
- abiso sa tagapangasiwa ng tungkulin;
- tugon sa isang insidente;
- pag-aalis ng mga sanhi.
Mahalagang gawin natin ito sa lalong madaling panahon. At kung sa mga yugto ng pagtukoy ng isang problema at pagpapadala ng isang abiso hindi kami makakakuha ng maraming oras - dalawang minuto ang gugugol sa kanila sa anumang kaso, kung gayon ang mga kasunod ay simpleng hindi naararo na larangan para sa mga pagpapabuti.
Isipin na lang natin na tumunog ang telepono ng duty officer. Ano ang gagawin niya? Maghanap ng mga sagot sa mga tanong - ano ang nasira, saan ito nasira, kung paano mag-react? Narito kung paano namin sinasagot ang mga tanong na ito:
Isasama lang namin ang lahat ng impormasyong ito sa teksto ng notification, bigyan ito ng link sa isang pahina ng wiki na naglalarawan kung paano tumugon sa problemang ito, kung paano ito lutasin at palakihin ito.
Wala pa rin akong sinabi tungkol sa layer ng application at logic ng negosyo. Sa kasamaang palad, ang aming mga aplikasyon ay hindi pa nagpapatupad ng pagkolekta ng sukatan. Ang tanging mapagkukunan ng anumang impormasyon mula sa mga antas na ito ay mga log.
Ilang puntos.
Una, magsulat ng mga structured na log. Hindi na kailangang isama ang konteksto sa teksto ng mensahe. Ito ay nagpapahirap sa kanila na pangkatin at pag-aralan. Ang Logstash ay tumatagal ng mahabang panahon upang gawing normal ang lahat ng ito.
Pangalawa, gamitin nang tama ang mga antas ng kalubhaan. Ang bawat wika ay may kanya-kanyang pamantayan. Sa personal, nakikilala ko ang apat na antas:
- walang pagkakamali;
- error sa panig ng kliyente;
- ang pagkakamali ay nasa ating panig, hindi tayo nawawalan ng pera, hindi tayo nangangasiwa;
- Nasa panig natin ang pagkakamali, nalulugi tayo.
Hayaan akong mag-summarize. Kailangan mong subukang bumuo ng pagsubaybay batay sa lohika ng negosyo. Subukang subaybayan ang mismong application at magpatakbo gamit ang mga sukatan gaya ng bilang ng mga benta, ang bilang ng mga bagong pagpaparehistro ng user, ang bilang ng mga kasalukuyang aktibong user, at iba pa.
Kung ang iyong buong negosyo ay isang button sa browser, kailangan mong subaybayan kung nag-click ito at gumagana nang maayos. Ang lahat ng natitira ay hindi mahalaga.
Kung wala ka nito, maaari mong subukang abutin ito sa mga log ng application, mga log ng Nginx, at iba pa, tulad ng ginawa namin. Dapat ay malapit ka sa aplikasyon hangga't maaari.
Ang mga sukatan ng operating system ay siyempre mahalaga, ngunit ang negosyo ay hindi interesado sa kanila, hindi kami binabayaran para sa kanila.
Pinagmulan: www.habr.com