Two years ago nakagawa na ako ng post Simpleng failover para sa isang website tungkol sa okerr. Ngayon ay may ilang pag-unlad ng proyekto, at nai-publish ko rin okerr server side source code sa ilalim bukas na lisensya, kaya naman nagpasya akong isulat ang maikling pagsusuri na ito sa Habr.

[ buong laki ]

Kung kanino ito maaaring interesado

Ito ay maaaring maging interesado sa iyo kung nagtatrabaho ka sa isang maliit na koponan o nag-iisa. Wala kang monitoring at hindi ka sigurado kung talagang kailangan mo ito. Sinubukan mo man ang ilang sikat na seryosong pagsubaybay "para sa mga malalaking lalaki", ngunit sa paanuman ay "hindi nag-alis" para sa iyo, o gumagana ito sa halos default na configuration at hindi gaanong nagbago sa iyong buhay. At din - kung talagang hindi mo planong maglaan ng isang buong empleyado (o kahit isang departamento) upang subaybayan ang dashboard ng pagsubaybay nang hindi bababa sa ilang oras sa isang araw o i-configure ito.

Bakit hindi pangkaraniwan ang okerr

Susunod na ipapakita ko ang mga kagiliw-giliw na tampok ng okerra na nakikilala ito mula sa ilang iba pang mga sistema ng pagsubaybay.

Ang Okerr ay isang hybrid na pagsubaybay

Sa panahon ng panloob na pagsubaybay, isang "ahente" ang tumatakbo sa mga sinusubaybayang makina, na nagpapadala ng data sa server ng pagsubaybay (halimbawa, libreng puwang sa disk). Kapag panlabas, ang server ay nagsasagawa ng mga pagsusuri sa network (halimbawa, pag-ping o pagkakaroon ng website). Ang bawat diskarte ay may mga limitasyon. Ginagamit ng Okerr ang parehong mga pagpipilian. Ang mga pagsusuri sa loob ng mga server ay isinasagawa ng isang napakagaan (30Kb) na ahente o ng sarili mong mga script at application, at ang mga pagsusuri sa network ay isinasagawa sa pamamagitan ng mga okerr sensor sa iba't ibang bansa.

Ang okerr ay hindi lamang software, kundi isang serbisyo din

Ang bahagi ng server ng anumang pagsubaybay ay malaki at kumplikado, mahirap i-install at i-configure, at nangangailangan ito ng mga mapagkukunan. Sa okerr maaari mong i-install ang iyong sariling monitoring server (ito ay libre at opensource), o maaari mong gamitin lamang ang bahagi ng kliyente at gamitin ang serbisyo ng aming server. Libre din.

Kung ang pagsubaybay ay nagpapahintulot sa iyo na magbayad at pagtakpan ang kakulangan ng pagiging maaasahan sa mga server at application, pagkatapos ay isang pilosopikal na tanong ang lumitaw - sino ang bantay? Paano sasabihin sa amin ng pagsubaybay ang tungkol sa isang problema kung ito mismo ay "namatay" sa ilang kadahilanan, nang hiwalay o kasama ng iyong iba pang mga mapagkukunan (halimbawa, nahulog ang channel sa data center)? Kapag gumagamit ng panlabas na serbisyo okerr - ang problemang ito ay nalutas - makakatanggap ka ng isang alerto kahit na ang buong data center sa iyong mga server ay walang kapangyarihan o inaatake ng mga zombie.

Siyempre, may panganib na ang server ng okerr mismo ay hindi magagamit, ito ay totoo (tulad ng alam mo, 90% ng pagiging maaasahan ay palaging nakuha nang simple at "libre", 99% na may isang minimum na pagsisikap, at bawat kasunod na siyam ay exponentially mas mahirap). Ngunit, una, ang mga pagkakataon na mangyari ito ay mas mababa, at pangalawa, ang problema ay maaaring hindi napapansin lamang kung ito ay kasabay ng mga problema sa aming mga server. Kung mayroon kaming 99.9% na pagiging maaasahan, at mayroon kang 99.9% (hindi masyadong mataas na mga numero), kung gayon ang pagkakataon ng isang hindi natukoy na kabiguan ay 0.1% ng 0.1% = 0.0001%. Ang pagdaragdag ng tatlong siyam sa iyong pagiging maaasahan halos walang pagsisikap at walang gastos ay napakahusay!

Ang isa pang bentahe ng pagsubaybay bilang isang serbisyo ay ang isang hosting provider o web studio ay maaaring mag-install ng isang okerr server at magbigay ng access sa mga kliyente bilang isang bayad o libreng karagdagang serbisyo. Ang iyong mga kakumpitensya ay mayroon lamang pagho-host at mga website, ngunit mayroon kang maaasahang pagho-host na may pagsubaybay.

Ang Okerr ay tungkol sa mga indicator

Ang indicator ay isang "light bulb". Mayroon itong dalawang pangunahing estado - berde (OK) o pula (ERR). Ang proyekto ay naglalaman ng maraming nakagrupong (halimbawa, ayon sa server) na mga tagapagpahiwatig. Sa pangunahing pahina ng proyekto, makikita mo kaagad na ang alinman sa lahat ay berde (at maaari mong isara ito), o ang isang bagay ay may ilaw na pula at kailangang itama. Kapag lumilipat sa pagitan ng mga estadong ito, ipinapadala ang isang alerto. Minsan sa isang araw habang sine-set up mo ito, isang buod ng proyekto ang ipinapadala.

Ang bawat okerr indicator ay may built-in na mga kondisyon kung saan ito nagbabago ng estado (sa Zabbix ito ay tinatawag na trigger). Halimbawa, ang average ng pag-load ay dapat na hindi hihigit sa 2 (siyempre, ito ay maaaring i-configure). At para sa bawat panloob na tseke (load average, disk free, ...) mayroong isang asong tagapagbantay. Kung sa ilang kadahilanan ay hindi kami nakatanggap ng matagumpay na kumpirmasyon sa itinakdang oras, isang error ay naka-log at isang alerto ay ipinadala.

Ang aming karaniwang pattern ng trabaho ay suriin ang mga email sa umaga, at tingnan ang buod kasama ng iba pang mga sulat (iiskedyul namin ito sa simula ng trabaho). Kung ok ang lahat sa loob nito, gumagawa kami ng iba pang mahahalagang bagay (ngunit para maging ligtas, maaari naming mabilis na tingnan ang dashboard ng okerra at siguraduhing berde ang lahat sa sandaling ito). Kung may dumating na alerto, nagre-react kami.

Siyempre, posible na panatilihin lamang ang "impormasyon" na mga tagapagpahiwatig (upang makita ang larawan ng network mula sa pagsubaybay), ngunit ang lahat ay ginagawa upang simple, madali at mabilis na lumikha ng mga tagapagpahiwatig na partikular para sa awtomatikong pagsubaybay at pagpapadala ng mga alerto.

Ang layunin kung saan ka nagse-set up ng okerr ay nasa mga alerto, upang makagawa ka ng indicator sa isang minuto, maaari itong "makatulog" sa loob ng isang taon, tanggapin lamang ang mga update, at kapag lumipas ang isang taon ay may nasira, ito ay nag-iilaw at nagpapadala isang alerto. Nagbunga ang minutong minsan mong ginugol sa paggawa ng indicator; natutunan mo kaagad ang tungkol sa problema, bago ang sinuman. Posibleng naayos na nila ito bago pa may makapansin. Ang isang bagay na mabilis na itinaas ay hindi itinuturing na nahulog!

katiwasayan

Nakakahiya kung magse-set up ka ng pagsubaybay para sa pagtaas ng pagiging maaasahan, ngunit bilang resulta, inaatake ka sa network sa pamamagitan nito, at napakaraming mga kahinaan sa network sa iba't ibang mga tool sa pagsubaybay (Zabbix, Nagios).

Ahente (okerrmod mula sa package okerrupdate) na tumatakbo sa system ay hindi isang network server, ngunit isang kliyente. Samakatuwid, walang karagdagang mga bukas na port sa sinusubaybayan na server, ang kliyente ay madaling gumana sa likod ng isang firewall o NAT at napakahirap (sabihin kong "imposible") na mag-hack sa network, dahil sa prinsipyo ay hindi ito nakikinig sa network. saksakan.

Buong saklaw ng pagsubaybay

Ngayon ang aming panuntunan ay natutunan namin ang tungkol sa lahat ng mga teknikal na problema mula sa okerr. Kung biglang nilabag ang panuntunan (hindi nagbabala ang okerr tungkol sa nalalapit na pangyayari nito (kung posible ito) o nangyari na ito) - nagdaragdag kami ng mga tseke sa okerr.

Mga panlabas na tseke

Isang tipikal na hanay:

i-ping
katayuan ng http
pagsuri sa bisa at pagiging bago ng SSL certificate (magbabala kung malapit na itong mag-expire)
buksan ang TCP port at banner dito
http grep (ang pahina [ay hindi dapat] naglalaman ng tiyak na teksto)
sha1 hash upang mahuli ang mga pagbabago sa pahina.
DNS (Dapat na may partikular na halaga ang tala ng DNS)
WHOIS (magbabala kung malapit nang masira ang domain)
Antispam DNSBL (host check laban sa 50+ antispam blacklists nang sabay-sabay)

Mga panloob na pagsusuri

Gayundin, isang medyo karaniwang hanay (ngunit madaling mapalawak).

df (libreng espasyo sa disk)
Katamtamang karga
opentcp (bukas na TCP listening sockets - aabisuhan kung may nagsimula o nag-crash)
uptime - uptime lang sa server. Aabisuhan kung ito ay nabago (ibig sabihin, ang server ay nag-overload)
client_ip
dirsize - ginagamit namin ito upang subaybayan kung ang aming mga virtual machine rootf ay lumampas sa pinapayagang laki, nang hindi nagpapakilala ng mga mahigpit na paghihigpit, at ang laki ng mga home directory ng user
walang laman at walang laman - subaybayan ang mga file na dapat walang laman (o walang laman). Halimbawa, ang error log ng okerr server mismo ay dapat na walang laman, at kung mayroong kahit isang linya dito, makakatanggap ako ng isang abiso at suriin ito. Ngunit HINDI dapat walang laman ang mail.log sa mail server (N minuto pagkatapos ng pag-ikot). At kung minsan ito ay walang laman para sa amin pagkatapos ng isang pag-update ng system, kapag ang logrotate ay hindi ma-restart nang tama ang rsyslog.
linecount - bilang ng mga linya sa file (tulad ng wc -l). Ginagamit namin ito bilang isang mas malambot na kapalit para sa walang laman, kapag ang log ng error ay maaari pa ring lumaki, ngunit dahan-dahan lamang (halimbawa, ang Googlebot ay tumama sa ilang saradong pahina). May limitasyon na 2 linya sa loob ng 20 minuto. Kung ito ay mas mataas, magkakaroon ng alerto

Mga kawili-wiling panloob na pagsusuri

Kung nagbabasa ka ng "diagonal" hanggang sa puntong ito, ngayon ay mas kawili-wiling basahin nang mas maingat.

pag-backup

Sinusubaybayan ang mga backup sa direktoryo. Ang aming mga backup na file ay may mga pangalan tulad ng "ServerName-20200530.tar.gz". Para sa bawat server sa okerr, ang indicator na ServerName-DATE.tar.gz ay nilikha (ang aktwal na petsa ay nagbabago sa linyang "DATE"). Ang mismong presensya ng isang bagong backup at ang laki nito ay sinusubaybayan din (halimbawa, hindi ito maaaring mas mababa sa 90% ng nakaraang backup).

Ano ang kailangang gawin para magsimulang masubaybayan ang isang bagong backup pagkatapos naming simulan ang paggawa nito at ilagay ito sa direktoryong ito? Wala! Ito ay isang napaka-maginhawang diskarte kapag kailangan mong gawin ang "wala" dahil:

Ang paggawa ng "wala" ay medyo mabilis, nakakatipid ito ng oras
Mahirap kalimutan ang "wala"
Mahirap gumawa ng "walang" mali, na may pagkakamali. Wala ang pinaka maaasahang paraan

Kung biglang huminto sa paglabas ang mga sariwang backup na file, magkakaroon ng alerto. Kung, halimbawa, hindi mo pinagana ang isa sa mga server, at dapat wala nang mga backup, kakailanganin mong tanggalin ang indicator (sa pamamagitan ng web interface o mula sa shell sa pamamagitan ng API).

maxfilesz

Sinusubaybayan ang laki ng pinakamalaking mga file (karaniwang: /var/log/*). Nagbibigay-daan ito sa iyo na mahuli ang mga hindi mahuhulaan na problema, halimbawa, mga brute force na password o pagpapadala ng spam sa pamamagitan ng server.

runstatus/runline

Ito ay dalawang mahalagang proxy module para sa pagpapatakbo ng iba pang mga program sa server. Iniuulat ng Runstatus ang exit code ng program sa indicator. Halimbawa, ang okerr ay hindi (nangangailangan) ng isang module upang suriin na ang mga serbisyo ng systemd ay tumatakbo. Ginagawa ito sa pamamagitan ng runstatus (tingnan sa ibaba). Runline - iniuulat sa server ang linya na ginagawa ng programa. Halimbawa, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" sa Runline config sa aming server ay lumilikha ng indicator servername:temp na may temperatura ng processor.

SQL

Nagsasagawa ng numeric na query sa MySQL at nag-uulat ng resulta sa indicator. Sa isang simpleng kaso, maaari mong gawin, halimbawa, "PUMILI 1" - susuriin nito kung gumagana ang DBMS sa kabuuan.

Ngunit ang isang mas kawili-wiling application ay, halimbawa, pagsubaybay sa bilang ng mga order sa isang online na tindahan. Kung alam mo na mayroon kang 100 o higit pang mga order bawat oras, maaari mong itakda ang minimum na limitasyon sa 100 o 80. Pagkatapos kung biglang bumaba ang iyong mga benta, makakatanggap ka ng isang alerto at maaari mong malaman ito.

Tandaan na hindi mahalaga para sa kung anong hindi mahuhulaan na dahilan ito nangyari:

Ang server ay simpleng hindi magagamit (de-energized o walang network), at ang alerto ay nagmula sa katotohanan na ang indicator ay "bulok".
Ang server ay na-overload ng isang bagay, ito ay gumagana nang mabagal o ang mga packet ay nawala, ito ay hindi maginhawa para sa mga gumagamit at sila ay umalis nang hindi bumibili
Ang server ay kasama sa mga listahan ng spam at ang mail mula dito ay hindi tinatanggap, ang mga gumagamit ay hindi maaaring magparehistro
Naubos na ang budget ng advertising campaign, hindi umiikot ang mga banner.

Maaaring mayroong anumang bilang ng mga dahilan, at lahat ng mga ito ay hindi mahulaan nang maaga, at ito ay teknikal na mahirap subaybayan. Ngunit maaari mong maginhawang subaybayan ang panghuling parameter (mga order) at matukoy mula sa kanila na ang sitwasyon ay kahina-hinala at nararapat na harapin.

Mga lohikal na tagapagpahiwatig

Pinapayagan ang paggamit ng mga Boolean na expression (Python syntax) sa pamamagitan ng isang module patunayan(artikulo sa Habré). Ang data mula sa proyekto at ang mga tagapagpahiwatig nito ay magagamit para sa pagpapahayag. Halimbawa, sa kabanata tungkol sa SQL checking sa itaas, maaaring napansin mo ang isang mahinang punto - sa araw ay maaari tayong magkaroon ng 100 benta kada oras, ngunit sa gabi - 20, at ito ay karaniwan, hindi isang problema. Anong gagawin ko? Ang tagapagpahiwatig ay patuloy na panic sa gabi.

Maaari kang lumikha ng dalawang tagapagpahiwatig, araw at gabi. Gawing parehong "tahimik" (hindi sila magpapadala ng mga alerto). At lumikha ng isang lohikal na tagapagpahiwatig na nangangailangan na ang tagapagpahiwatig ng araw ay maging OK bago ang 20:00, at pagkatapos ng 20:00 ito ay sapat na para sa tagapagpahiwatig ng gabi na maging OK.

Ang isa pang halimbawa ng paggamit ng lohikal na tagapagpahiwatig ay pagdako. Halimbawa, ang isang project manager ay nag-unsubscribe mula sa mga alerto (hindi niya kailangang gawin ito, ang mga admin ay dapat tumugon sa mga normal na problema), ngunit nag-subscribe sa isang lohikal na tagapagpahiwatig na nagiging pula kung ang anumang tagapagpahiwatig sa proyekto ay hindi naitama sa loob ng inilaang oras.

Gayundin, posible na itakda ang pinahihintulutang oras para sa trabaho, halimbawa, mula 3 hanggang 5 ng umaga. Wala kaming pakialam kung mag-crash ang mga server at site sa panahong ito. Ngunit sa 5:00 kailangan nilang magtrabaho. Kung hindi sila gumana sa ibang oras - alerto. Ang lohikal na tagapagpahiwatig ay nagpapahintulot din sa iyo na isaalang-alang ang kalabisan ng server. Kung mayroon kang 5 web server, maaaring i-off ng mga admin ang 1-2 server anumang oras. Ngunit kung wala pang 3 sa 5 server sa labanan, magkakaroon ng alerto.

Ang mga halimbawa sa itaas ay hindi oker function, hindi ilang feature na kailangang i-activate at i-configure. Wala sa Okerra ang lahat ng mga pag-andar na ito, ngunit mayroong isang lohikal na module na nagbibigay-daan sa iyo upang ipatupad ang pag-andar na ito (Humigit-kumulang tulad ng sa isang programming language - kung mayroon kaming mga operator ng aritmetika, kung gayon hindi namin kailangan ang isang espesyal na function para sa pagkalkula ng 20% VAT mula sa wika, maaari mong gawin ito sa iyong sarili palagi upang umangkop sa iyong mga pangangailangan).

Ang Logic Indicator ay malamang na isa sa ilang medyo kumplikadong mga paksa sa okerr, ngunit ang magandang balita ay hindi mo kailangang pag-aralan ito hangga't kailangan mo. Ngunit sa parehong oras, lubos nilang pinalawak ang mga kakayahan, habang pinapanatili ang system mismo na medyo simple.

Pagdaragdag ng sarili mong mga tseke

Gusto ko talagang ihatid ang ideya na ang okerr ay hindi isang hanay ng libu-libong handa na mga tseke para sa lahat ng okasyon, ngunit sa kabaligtaran - una sa lahat - isang simpleng makina na may simpleng kakayahang lumikha ng iyong sariling mga tseke. Ang paggawa ng sarili mong mga tseke sa okerr ay hindi isang gawain para sa mga hacker, system co-developer, o hindi bababa sa mga advanced na user ng okerr, ngunit isang magagawang gawain para sa sinumang admin na nag-install ng Linux sa unang pagkakataon noong isang buwan.

Ang mga pagsusuri sa pinakamababang sahod ay ginagawa sa pamamagitan ng module runstatus:

Ang linyang ito sa config runstatus aabisuhan ka kung ang /bin/true ay biglang hindi nagsimula o nagbabalik ng isang bagay maliban sa 0.

true_OK=/bin/true

Isang linya lang - at narito na tayo ng kaunti pinalawak functionality okerr.

Kahit na ang naturang tseke ay mayroon nang halaga: kung biglang nag-crash ang iyong server, ang kaukulang tagapagpahiwatig sa server ng okerr ay hindi maa-update sa isang napapanahong paraan, at pagkatapos na lumipas ang oras, isang alerto ang lilitaw.

Ang pagsusuring ito ay mag-aabiso na ang apache2 server ay nag-crash (well, hindi mo alam...):

apache_OK="systemctl is-active --quiet apache2"

Kaya, kung nagsasalita ka ng anumang programming language, at hindi bababa sa maaaring magsulat ng mga script ng shell, pagkatapos ay maaari ka nang magdagdag ng iyong sariling mga tseke.

Mas mahirap - maaari mong isulat (sa anumang wika) ang iyong sariling module para sa okerrmod. Sa pinakasimpleng kaso, ganito ang hitsura:

#!/usr/bin/python3

print("STATUS: OK")

Hindi ba napakahirap? Dapat gawin mismo ng module ang pagsusuri at ilabas ang mga resulta sa STDOUT. Ang isang mas kumplikadong module ay nagbibigay, halimbawa, ito:

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

Nag-a-update ito ng ilang mga indicator nang sabay-sabay (na pinaghihiwalay ng isang walang laman na linya), ginagawa ang mga ito kung kinakailangan, nagpapahiwatig ng mga detalye ng pag-verify at isang tag kung saan madaling mahanap ang mga kinakailangang indicator sa dashboard.

Telegrama

Mayroong Telegram bot @OkerrBot. Hindi mo kailangang kalat ang iyong telepono gamit ang hiwalay na mga application (Hindi ko gusto iyon para sa Pyaterochka kailangan mo ng isang application na may mapa, para sa Lenta isa pa, para sa MTS isang pangatlo, at iba pa para sa lahat, lahat, lahat). Sapat na ang isang telegrama. Sa pamamagitan ng telegrama maaari kang agad na makatanggap ng mga alerto, suriin ang katayuan ng proyekto at magbigay ng isang utos na muling suriin ang lahat ng mga may problemang tagapagpahiwatig. Umalis kami sa teatro/eroplano, hindi pinapanatili ang aming daliri sa pulso sa loob ng dalawang oras, binuksan ang telepono, pinindot ang isang button sa chatbot, at tinitiyak na maayos ang lahat.

Mga Pahina ng Katayuan

Sa panahon ngayon, ang mga status page ay halos isang dapat na taglayin para sa anumang negosyong may IT, isang responsableng saloobin sa pagiging maaasahan at gumagalang sa mga kliyente/user nito.

Isipin ang isang sitwasyon - may gustong gawin ang isang user, tingnan ang impormasyon o mag-order, at may hindi gumana. Hindi niya alam kung ano ang nangyayari, kung kaninong panig ang problema at kung kailan ito malulutas. Siguro ang iyong kumpanya ay may isang hindi gumaganang website? O nasira ba ito anim na buwan na ang nakakaraan at ito ay aayusin sa loob ng dalawang taon? Ngunit kailangan mong bumili ng refrigerator ngayon, ito ay nasa cart na... At ito ay isang ganap na naiibang bagay kapag ang isang tao ay nakikita na may isang bagay na mali sa iyo (kahit na ito ay malinaw na ang problema ay hindi sa kanyang panig), na ang ang problema ay natuklasan, na ginagawa mo na ito, at marahil ay isinulat pa ang tinatayang oras para sa pagwawasto. Ang gumagamit ay maaaring mag-subscribe at makatanggap ng isang abiso sa email kapag naayos na ang problema at magagawa niya ang gusto niya (bumili ng refrigerator).

Ang mga problema at downtime ay nangyayari sa lahat. Ngunit mas pinagkakatiwalaan ng mga user at partner ang mga mas transparent at responsable sa kanilang diskarte dito.

Dito pagsusuri ng 10 iba pang proyekto na nagbibigay-daan sa iyong lumikha ng mga pahina ng katayuan. Narito ang mga halimbawa ng kung ano ang hitsura ng mga pahina ng proyektong ito Sawa и Dropbox. pahina ng katayuan ng okerr.

Pagkabigo

Upang hindi na mapahaba pa ang artikulong ito, muling sasangguni ako sa aking naunang artikulo - Simpleng failover para sa isang website . Kung makakagawa ka ng duplicate na server, pagkatapos gamit ang failover, karaniwang hindi ka magkakaroon ng mahabang downtime - sa sandaling matukoy ang isang problema, awtomatikong mare-redirect ang mga user sa isang gumaganang backup na server. At tila sa akin ito ay isang napaka-kawili-wili, maliwanag na tampok na bihirang magagamit kahit saan.

Mababang mga kinakailangan sa system

Para sa mga server ng okerr, gumagamit kami ng mga makina na may RAM mula sa 2Gb. Para sa mga sensor ng network, kahit 512Mb ay sapat na. Ang bahagi ng kliyente ay karaniwang halos zero. (Plastik na bag okerrupdate tumitimbang ng 26 Kb, ngunit nangangailangan ng Python3 at mga karaniwang aklatan). Ang kliyente ay tumatakbo mula sa isang cron script, kaya wala itong patuloy na pagkonsumo ng memorya. Kabilang sa mga machine na sinusubaybayan namin, mayroon kaming mga sensor (super-cheap na VPS na may 512Mb RAM) at isang Raspberry Pi. Posible kahit wala ang bahagi ng kliyente magpadala ng mga update sa pamamagitan ng curl! (tingnan sa ibaba)

Isinasaalang-alang ito - okerr, malamang pinaka libre monitoring system mula sa mga magagamit, dahil kahit na gumamit ng isa pang libreng open-source system tulad ng Zabbix o Nagios, kailangan mong maglaan ng mga mapagkukunan (server) dito, at ito ay pera na. Bilang karagdagan, ang ilang pagpapanatili ng server ay kinakailangan pa rin. Sa okerr, maaaring tanggalin ang bahaging ito. O hindi mo kailangang alisin ito at gamitin ang iyong sariling server, depende sa kung ano ang pinakagusto mo.

API at pagsasama sa proprietary software

Simple at bukas na arkitektura. Ang okerr ay may medyo simple API, na madaling gamitin. Kailangang gumawa ng 1000 indicator? Isang shell script ng 3-4 na linya ang gagawa nito. Kailangang i-reconfigure ang 1000 indicator? Napakadali din nito. Halimbawa, gusto naming i-double check ang lahat ng aming HTTPS certificate mula sa isang Russian sensor:

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

Maaari mong i-update ang indicator gamit ang aming client module, kahit wala ito, sa pamamagitan lamang ng curl.

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

Maaari mong i-update ang mga indicator nang direkta mula sa iyong programa. Halimbawa, ang pagpapadala ng mga signal ng tibok ng puso upang malaman ni okerr na ito ay tumatakbo at magtataas ng alarm kung ito ay bumagsak o nag-freeze. Sa pamamagitan ng paraan, ang mga bahagi ng okerr ay ginagawa iyon - sinusubaybayan ng okerr ang sarili nito, at ang mga problema sa halos anumang module ay makikita at bubuo ng isang alerto tungkol sa problema. (At sa kaso ng "halos" na ito - sila ay na-cross-check mula sa isa pang server)

Narito ang code (pinasimple) sa aming telegram bot:

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

Mayroong library para sa pag-update ng mga indicator mula sa mga programang Python okerrupdate, para sa anumang iba pang mga wika ay walang mga aklatan, ngunit maaari mong tawagan ang script ng okerrupdate o gumawa ng kahilingan sa HTTP sa server ng okerr.

Paano tayo tinutulungan ng okerr

Binago ni Okerr ang aming buhay. Sa totoo lang. Marahil ang isa pang sistema ng pagsubaybay ay maaaring gawin ang parehong, ngunit ang pagtatrabaho sa okerr ay madali at simple para sa amin at mayroon itong lahat ng mga pag-andar na kailangan namin (idinagdag namin kung ano ang wala nito). Sa pamamagitan ng paraan, kung may ilang mga tampok na nawawala, magtanong at idadagdag ko ang mga ito (hindi ko ipinapangako, ngunit gusto ko ang okerr na maging pinakamahusay na sistema ng pagsubaybay para sa mga maliliit na katamtamang proyekto). O mas mabuti pa, idagdag mo ito - madali lang.

Nagawa naming mamuhay ayon sa prinsipyong "matuto tungkol sa lahat ng problema mula sa kerra." Kung biglang may dumating na problema na hindi namin natutunan mula sa okerr, nagdaragdag kami ng tseke sa okerr. (sa kasong ito, sa pamamagitan ng "kami" ang ibig kong sabihin ay kami bilang mga gumagamit ng system, hindi mga co-developer). Noong una ay karaniwan ito, ngunit ngayon ay naging napakabihirang.

Pagsubaybay

Sa pamamagitan ng okerr sinusubaybayan namin ang mga laki ng log sa lahat ng mga server. Siyempre, imposibleng maingat na basahin ang bawat linya ng log gamit ang iyong mga mata, ngunit ang simpleng pagsubaybay sa rate ng paglago ay nagbibigay na ng maraming. Sa pamamagitan nito, natuklasan namin ang spam mail at brute force na paghahanap ng password, at kapag ang ilan sa mga application ay “nabaliw,” may hindi gumagana para sa kanila at paulit-ulit nila itong inuulit (sa bawat oras na nagdaragdag ng ilang linya sa log ).

Mga SSL certificate. Halos kaagad pagkatapos ng paglulunsad LetsEncrypt nagsimulang magbigay ang aming customer ng mga libreng SSL certificate sa mga kliyente nito (mga isang libo sa kanila). At ito ay naging impiyerno lamang para sa administrasyon! Ang katotohanan ay ang mga site ay "live", ang mga kliyente ay pana-panahong humihiling sa kanila na gumawa ng isang bagay, ginagawa ito ng mga programmer. Maaari nilang ganap na malayang ilipat ang site sa isa pang DocumentRoot, halimbawa. O magdagdag ng walang kondisyon na Rewrite sa virtualhost config. Naturally, pagkatapos nito, ang awtomatikong pag-renew ng mga sertipiko ay nasira. Ngayon mayroon kaming lahat ng SSL host na awtomatikong naidagdag sa okerr sa pamamagitan ng isa pa sa aming mga kapaki-pakinabang na utility mula sa package a2conf. Ilunsad na lang natin a2okerr.py — at kung maraming bagong site ang lalabas sa server, awtomatiko silang lalabas sa okerr. Kung biglang sa ilang kadahilanan ay hindi na-renew ang sertipiko, tatlong linggo bago mag-expire ang sertipiko, alam namin, at malalaman namin kung bakit hindi ito na-update, tulad ng isang aso. a2certbot.py mula sa parehong pakete - nakakatulong ito ng malaki dito (agad itong sinusuri ang malamang na mga problema - at isinulat kung ano ang nasuri nang mabuti, at kung saan malamang na may problema).

Sinusubaybayan namin ang petsa ng pag-expire ng lahat ng aming mga domain. At lahat ng aming mail server na nagpapadala ng mail ay sinusuri din laban sa 50+ iba't ibang mga blacklist. (At kung minsan ay nahuhulog sila sa kanila). By the way, alam mo bang naka-blacklist din ang mga Google mail server? Para lang sa self-testing, nagdagdag kami ng mail-wr1-f54.google.com sa mga sinusubaybayang server, at nasa blacklist pa rin ito ng SORBS! (Ito ay tungkol sa halaga ng "anti-spammers")

Mga Backup - Naisulat ko na sa itaas kung gaano kadaling subaybayan ang mga ito gamit ang okerr. Ngunit sinusubaybayan namin pareho ang pinakabagong mga backup sa aming server at (gamit ang isang hiwalay na utility na gumagamit ng okerr) ang mga backup na ina-upload namin sa Amazon Glacier. At, oo, ang mga problema ay nangyayari paminsan-minsan. No wonder nanonood sila.

Ginagamit namin ang indicator ng escalation. Ipinapakita nito kung ang ilang problema ay hindi naayos nang mahabang panahon. At ako mismo, kapag nalutas ko ang ilang mga problema, minsan ay nakakalimutan ko ang mga ito. Ang escalation ay isang magandang paalala, kahit na sinusubaybayan mo ang iyong sarili.

Sa pangkalahatan, naniniwala ako na ang kalidad ng aming trabaho ay tumaas ng isang order of magnitude. Halos walang downtime (o ang kliyente ay walang oras upang mapansin ito. Shh!), habang ang dami ng trabaho ay naging mas maliit at ang mga kondisyon sa pagtatrabaho ay naging mas kalmado. Lumipat kami mula sa trabahong pang-emerhensiya na may mga butas na may tape patungo sa kalmado at sinusukat na trabaho, kapag maraming problema ang hinulaan nang maaga at may oras upang maiwasan ang mga ito. Kahit na ang mga problema na nangyari ay naging mas madaling ayusin: una, nalaman namin ang tungkol sa mga ito bago mag-panic ang mga kliyente, at pangalawa, madalas na nangyayari na ang problema ay nauugnay sa kamakailang trabaho (habang ginagawa ko ang isang bagay, sinira ko ang isa pa) - kaya mainit Ito ay mas madali para sa mga bakas na harapin ito.

Pero may isa pang kaso...

Alam mo ba na sa sikat na Debian 9 (Stretch) ang sikat na package gaya ng phpmyadmin ay nasa vulnerable status pa rin (sa loob ng maraming buwan!) (CVE-2019-6798). Nang lumitaw ang kahinaan, mabilis naming tinakpan ito sa iba't ibang paraan. Ngunit nag-set up ako ng pagsubaybay sa pahina ng security-tracker sa okerr para malaman kung kailan lalabas ang isang "maganda" na solusyon (sa pamamagitan ng SHA1 na kabuuan ng nilalaman). Ilang beses akong na-twitch ng indicator, nagbago ang page, ngunit tulad ng nakikita mo, hindi pa rin ito (mula noong Enero 2019!) ay hindi nagpapahiwatig na ang problema ay nalutas na. Siguro, sa pamamagitan ng paraan, may nakakaalam kung ano ang problema na ang isang mahalagang pakete ay mahina pa rin sa loob ng higit sa isang taon?

Isa pang pagkakataon sa isang katulad na sitwasyon: pagkatapos ng isang kahinaan sa SSH, ito ay kinakailangan upang i-update ang lahat ng mga server. At kapag nagtakda ka ng isang gawain, kailangan mong kontrolin ang pagpapatupad. (Ang mga nasa ilalim ay may posibilidad na hindi maunawaan, makalimot, malito, at magkamali). Samakatuwid, nagdagdag muna kami ng pagsusuri sa bersyon ng SSH sa okerr sa lahat ng mga server, at sa pamamagitan ng okerr tinitiyak namin na ang mga update ay inilunsad sa lahat ng mga server. (Maginhawa! Pinili ko ang ganitong uri ng indicator, at makikita mo kaagad kung aling server ang may kung anong bersyon). Kapag natitiyak namin na ang gawain ay nakumpleto sa lahat ng mga server, inalis namin ang mga tagapagpahiwatig.

Ilang beses nagkaroon ng sitwasyon kung saan lumitaw ang isang tiyak na problema, at pagkatapos ay kusang mawawala. (malamang pamilyar sa lahat?). Sa oras na mapansin mo, sa oras na suriin mo-at walang dapat suriin-lahat ay gumagana nang maayos. Ngunit pagkatapos ay nasira muli. Nangyari ito, halimbawa, sa mga produktong na-upload namin sa Amazon Marketplace (MWS). Sa ilang mga punto, ang na-load na imbentaryo ay hindi tama (maling dami ng mga produkto at maling presyo). Naisip namin ito. Ngunit upang malaman ito, mahalagang malaman kaagad ang problema. Sa kasamaang palad, ang MWS, tulad ng lahat ng mga serbisyo ng Amazon, ay medyo mabagal, kaya palaging may lag, ngunit gayunpaman, halos naunawaan namin ang koneksyon sa pagitan ng problema at ng mga script na sanhi nito (nag-check kami, natigil ito sa okerr, at sinuri ito kaagad na nakatanggap ng alerto).

Isang kawili-wiling case ang idinagdag kamakailan sa koleksyon ng isang malaki at mamahaling European hoster, na ginagamit ng aming customer. Biglang nawala ang LAHAT ng aming mga server sa radar! Una, ang customer mismo (mas mabilis kaysa okerra!) ay napansin na ang site na pinagtatrabahuhan niya ay hindi nagbubukas at gumawa ng tiket tungkol dito. Ngunit hindi lang isang site ang bumaba, kundi lahat sila! (Natasha, ibinagsak namin ang lahat!). Dito nagsimulang magpadala si Okerr ng mahabang pambalot sa paa kasama ang lahat ng mga indicator na lumiwanag para sa kanya. Panic, panic, paikot-ikot kaming tumatakbo (ano pa ba ang magagawa namin?). Pagkatapos ay tumaas ang lahat. Lumalabas na may nakagawiang pagpapanatili sa data center (isang beses bawat maraming taon) at, siyempre, dapat tayo ay binigyan ng babala. Ngunit may isang uri ng problema ang nangyari sa kanila at hindi nila kami binalaan. Well, mas maraming atake sa puso, mas kaunting atake sa puso. Ngunit pagkatapos na maibalik ang lahat, kailangan mong i-double-check ang lahat! Hindi ko maisip kung paano ko ito gagawin gamit ang aking mga kamay. Sinubukan ni Okerr ang lahat sa loob ng ilang minuto. Ito ay lumabas na ang karamihan sa mga server ay pansamantalang hindi magagamit, ngunit gumagana ang mga ito. Ang ilan ay na-overload, ngunit tumayo din gaya ng nararapat. Sa lahat ng mga pagkalugi, nawalan kami ng dalawang backup, na ayon sa korona ay dapat na nilikha at na-load habang ang buong saging ay nangyayari. Hindi man lang ako nag-abala sa paggawa ng mga ito, makalipas ang isang araw ay dumating ang mga alerto na OK na ang lahat, lumitaw ang mga backup. Talagang gusto ko ang halimbawang ito dahil naging kapaki-pakinabang ang okerr sa isang sitwasyon na hindi natin naisip nang maaga, ngunit iyon ang layunin ng pagsubaybay - upang labanan ang hindi mahuhulaan.

Para sa mga sensor ng Okerr, ginagamit namin ang pinakamurang posibleng pagho-host (kung saan hindi mahalaga ang kalidad at pagiging maaasahan, sinisiguro nila ang isa't isa). Kaya, kamakailan lamang ay nakakita kami ng napakahusay na pagho-host at sobrang mura, ang mga benchmark ay kahanga-hanga. Ngunit... minsan lumalabas na ang mga papalabas na koneksyon mula sa virtual machine ay ginawa mula sa isa pang (katabing) IP. Mga himala. Client_ip module na may https://diagnostic.opendns.com/myip nakakakuha ng maling IP. At mula sa mga log ng server ng indicator ay malinaw na ang pag-update ay nagmula rin sa kalapit na IP na ito. Harapin natin ang suporta ngayon. Buti na lang napansin natin ito sa panahon ng kapayapaan. Ngunit, halimbawa, madalas na nangyayari na ang pag-access ay nakarehistro ayon sa puting listahan ng IP - at kung minsan ang server ay kumikislap tulad nito sa maikling panahon - maaari mong subukang mahuli ang problemang ito sa napakatagal na panahon.

Well, isa pang bagay - dahil pinag-uusapan natin ang tungkol sa pagho-host ng VPS - palagi kaming gumagamit ng mga mura (hetzner, ovh, scaleway). Talagang gusto ko ito pareho sa mga tuntunin ng mga benchmark at katatagan. Ginagamit din namin ang mas mahal na Amazon EC2 para sa iba pang mga proyekto. Kaya, salamat sa okerr, mayroon kaming sariling matalinong opinyon. Pareho silang bumagsak. At hindi ko sasabihin na sa mahabang panahon ng aming mga obserbasyon, ang mga murang hosting tulad ng hetzner ay naging kapansin-pansing hindi gaanong matatag kaysa sa EC2. Samakatuwid, kung hindi ka nakatali sa iba pang mga tampok ng Amazon, bakit magbayad ng higit pa? 🙂

Ano ang susunod?

Kung sa yugtong ito ay hindi pa kita tinatakot na malayo sa Okerr, pagkatapos ay subukan ito! Maaari kang pumunta nang direkta sa link na ito okerr demo account (I-click ngayon!) Ngunit tandaan na mayroon lamang isang demo account para sa lahat, kaya kung gagawin mo ang isang bagay, maaaring makagambala sa iyo ang ibang tao sa parehong account sa parehong oras. O (mas mahusay) magparehistro sa pamamagitan ng link sa offsite okerr - lahat ay simple, walang SMS. Kung hindi mo gustong gamitin ang iyong tunay na email, maaari kang gumamit ng disposable, tulad ng mailinator (inirerekumenda ko getnada.com). Maaaring ma-delete ang mga naturang account sa paglipas ng panahon, ngunit magiging maayos ang mga ito para sa pagsubok.

Pagkatapos ng pagpaparehistro, hihilingin sa iyo na sumailalim sa pagsasanay (magsagawa ng ilang hindi masyadong mahirap na mga gawain sa pagsasanay). Ang mga paunang limitasyon ay napakaliit, ngunit para sa pagsasanay o isang server ay sapat na ang mga ito. Pagkatapos makumpleto ang pagsasanay, ang mga limitasyon (halimbawa, ang maximum na bilang ng mga tagapagpahiwatig) ay tataas.

Mula sa dokumentasyon - una sa lahat WIKI sa gilid ng server at sa kliyente (okerrupdate wiki). Ngunit kung may hindi malinaw, sumulat sa suporta (sa) okerr.com o mag-iwan ng tiket - susubukan naming lutasin ang lahat nang mabilis.

Kung sineseryoso mo itong ginagamit at hindi sapat ang mga tumaas na limitasyong ito, sumulat sa suporta at dadagdagan namin ito (nang libre).

Gusto mo bang i-install ang okerr server sa iyong server? Dito okerr-dev repository. Inirerekumenda namin ang pag-install sa isang malinis na virtual machine, pagkatapos ay maaari mo lamang itong gawin gamit ang isang script ng pag-install. Sa iyong virtual machine - walang mga paghihigpit :-). Buweno, muli, kung may mangyari, palagi kaming susubukan na tumulong.

Nais naming magsimula ang proyektong ito, upang ang mundo ay maging mas maaasahan salamat sa amin. Salamat sa libreng software at mga serbisyo, ang mundo ay naging mas palakaibigan at umuunlad nang mas pabago-bago. Ang mga mapagkukunan ay maaaring maimbak sa libreng github, at para sa mail maaari mong gamitin ang libreng gmail. Libre ang gamit namin mga freshworks para sa Suporta. Para sa alinman sa mga ito, hindi mo kailangang magbayad para sa mga server, hindi mo kailangang mag-download at mag-configure, at hindi mo kailangang lutasin ang iba't ibang mga problema sa pagpapatakbo. Bawat bagong proyekto, ang bawat koponan ay may kaagad na mail, mga repositoryo at CRM. At lahat ng ito ay napakataas na kalidad at libre at kaagad. Nais naming maging pareho ito para sa pagsubaybay - ang mga maliliit na kumpanya at proyekto ay maaaring gumamit ng okerr nang libre at kahit na sa yugto ng kapanganakan at paglaki ay may pagiging maaasahan ng mga seryosong proyekto ng nasa hustong gulang.

Pinagmulan: www.habr.com

Pangkalahatang-ideya ng Okerr hybrid monitoring system