Prieš dvejus metus jau parašiau įrašą Paprastas svetainės perkėlimas apie okerr. Dabar vyksta šioks toks projekto vystymas, aš taip pat paskelbiau okerr serverio šaltinio kodas pagal atvira licencija, todėl nusprendžiau parašyti šią trumpą apžvalgą apie Habr.

[ Visas vaizdas ]

Kam tai gali sudominti

Tai gali jus sudominti, jei dirbate mažoje komandoje arba vienas. Neturite stebėjimo ir nesate tikri, ar jums to tikrai reikia. Arba išbandėte populiarų rimtą stebėjimą „didiesiems berniukams“, bet jis jums kažkaip „nepasirodė“, arba jis veikia beveik pagal numatytąją konfigūraciją ir jūsų gyvenimo labai nepakeitė. Ir taip pat – jei tikrai neplanuojate skirti viso darbuotojo (ar net skyriaus) stebėti stebėjimo prietaisų skydelį bent porą valandų per dieną ar jį konfigūruoti.

Kodėl okerr yra neįprasta

Toliau parodysiu įdomias okerros savybes, kurios išskiria ją iš kai kurių kitų stebėjimo sistemų.

Okerr yra hibridinis stebėjimas

Vidinio stebėjimo metu stebimose mašinose veikia „agentas“, kuris perduoda duomenis į stebėjimo serverį (pavyzdžiui, laisvą vietą diske). Išorinis serveris atlieka patikrinimus tinkle (pavyzdžiui, ping arba svetainės prieinamumas). Kiekvienas požiūris turi savo apribojimus. Okerr naudoja abi parinktis. Patikrinimus serverių viduje atlieka labai lengvas (30Kb) agentas arba jūsų pačių scenarijai ir programos, o tinklo patikrinimai atliekami per okerr jutiklius įvairiose šalyse.

okerr yra ne tik programinė įranga, bet ir paslauga

Bet kokio stebėjimo serverio dalis yra didelė ir sudėtinga, ją sunku įdiegti ir konfigūruoti, be to, tam reikia išteklių. Su okerr galite įdiegti savo stebėjimo serverį (jis nemokamas ir atvirojo kodo), arba galite tiesiog naudoti tik kliento dalį ir naudotis mūsų serverio paslauga. Taip pat nemokamai.

Jei stebėjimas leidžia kompensuoti ir nuslėpti serverių ir programų patikimumo trūkumą, tada kyla filosofinis klausimas – kas yra sargas? Kaip stebėjimas pasakys mums apie problemą, jei ji pati dėl kokių nors priežasčių „numirė“ atskirai arba kartu su kitais jūsų ištekliais (pavyzdžiui, nukrito kanalas į duomenų centrą)? Naudodamiesi išorine paslauga okerr - ši problema išspręsta - gausite įspėjimą net jei visas duomenų centras su jūsų serveriais bus be maitinimo arba jį užpuls zombiai.

Žinoma, yra rizika, kad pats „okerr“ serveris bus nepasiekiamas. Kaip žinome, 90 % patikimumas visada pasiekiamas lengvai ir „nemokamai“, 99 % – minimaliomis pastangomis, o kiekvienas paskesnis devynis kartus yra eksponentiškai sunkesnis. Tačiau, pirma, tikimybė, kad tai įvyks, yra mažesnė, ir, antra, problema gali likti nepastebėta tik tuo atveju, jei ji sutampa su problemomis mūsų serveriuose. Jei turime patikimumą, 99.9%, ir tu 99.9% (ne per dideli skaičiai), tai nepastebėto gedimo tikimybė yra 0.1 % iš 0.1 % = 0.0001 %. Pridėjus tris devynis prie savo patikimumo beveik be jokių pastangų ir išlaidų, yra gana gerai!

Kitas stebėjimo kaip paslaugos privalumas yra tas, kad prieglobos paslaugų teikėjas arba žiniatinklio studija gali įdiegti okerr serverį ir suteikti prieigą klientams kaip mokamą arba nemokamą papildomą paslaugą. Jūsų konkurentai turi tik prieglobą ir svetaines, bet jūs turite patikimą prieglobą su stebėjimu.

Okerr yra apie rodiklius

Indikatorius yra "lemputė". Jis turi dvi pagrindines būsenas – žalią (OK) arba raudoną (ERR). Projekte yra daug sugrupuotų (pavyzdžiui, pagal serverį) rodiklių. Pagrindiniame projekto puslapyje iš karto matosi, kad arba viskas žaliai (ir galima uždaryti), arba kažkas užsidega raudonai ir reikia taisyti. Pereinant tarp šių būsenų, siunčiamas įspėjimas. Kartą per dieną, kol jį nustatote, siunčiama projekto santrauka.

Kiekvienas okerr indikatorius turi įmontuotas sąlygas, kuriomis jis keičia būseną (Zabbix tai vadinama trigeriu). Pavyzdžiui, apkrovos vidurkis turi būti ne didesnis kaip 2 (žinoma, tai galima konfigūruoti). Ir kiekvienam vidiniam patikrinimui (vidutinė apkrova, diskas laisvas, ...) yra sargas. Jei dėl kokių nors priežasčių nustatytu laiku negauname sėkmingo patvirtinimo, registruojama klaida ir siunčiamas įspėjimas.

Mūsų įprastas darbo modelis yra ryte tikrinti el. laiškus ir peržiūrėti santrauką tarp kitų laiškų (suplanuojame darbo pradžioje). Jei jame viskas gerai, atliekame kitus svarbius dalykus (tačiau, kad būtų saugu, galime greitai pažvelgti į okerra prietaisų skydelį ir įsitikinti, kad šiuo metu viskas yra žalia). Jei gaunamas įspėjimas, mes reaguojame.

Žinoma, galima tiesiog pasilikti „informacinius“ indikatorius (kad būtų matomas tinklo vaizdas nuo stebėjimo), tačiau daroma viskas, kad būtų galima paprastai, lengvai ir greitai sukurti rodiklius, skirtus būtent automatiniam stebėjimui ir įspėjimų siuntimui.

Tikslas, dėl kurio jūs nustatote okerr yra perspėjimai, kad per minutę sukurtumėte indikatorių, jis galėtų "pamiegoti" metus, tik priimti atnaujinimus, o kai po metų kažkas sugenda, užsidega ir siunčia įspėjimas. Minutė, kurią kažkada praleidote kurdami indikatorių, atsipirko iš karto, anksčiau nei kas nors kitas. Gali būti, kad jie tai sutvarkė niekam nepastebėjus. Tai, kas greitai pakelta, nelaikoma nukritusiu!

saugumas

Būtų gaila, jei nustatytumėte stebėjimą, kad padidintumėte patikimumą, tačiau dėl to esate užpultas per tinklą, o įvairiose stebėjimo priemonėse yra gana daug tinklo spragų (Zabbix, Nagios).

Agentas (okerrmod iš pakuotės okerrupdate) sistemoje veikia ne tinklo serveris, o klientas. Todėl stebimame serveryje nėra papildomų atvirų prievadų, klientas lengvai dirba už ugniasienės ar NAT ir jį labai sunku (sakyčiau „neįmanoma“) nulaužti per tinklą, nes iš esmės jis neklauso tinklo. lizdas.

Visa stebėjimo aprėptis

Dabar mūsų taisyklė yra ta, kad apie visas technines problemas sužinome iš okerr. Jei staiga pažeidžiama taisyklė (okerr neįspėjo apie jos neišvengiamą įvykį (jei tai įmanoma) arba kad ji jau įvyko) – prie okerr pridedame čekius.

Išoriniai patikrinimai

Gana tipiškas rinkinys:

zvimbimas
http būsena
tikrinti SSL sertifikato galiojimą ir naujumą (įspės, jei netrukus baigsis)
atidarykite TCP prievadą ir jame esančią reklamjuostę
http grep (puslapyje [neturi] būti tam tikro teksto)
sha1 maiša, kad užfiksuotų puslapio pakeitimus.
DNS (DNS įrašas turi turėti konkrečią reikšmę)
WHOIS (perspės, jei domenas greitai suges)
Antispam DNSBL (prieglobos serverio tikrinimas pagal 50 ir daugiau juodųjų antispam sąrašų vienu metu)

Vidiniai patikrinimai

Taip pat gana standartinis komplektas (bet nesunkiai plečiamas).

df (laisvos vietos diske)
apkrovos vidurkis
opentcp (atidaryti TCP klausymosi lizdus – praneš, jei kas nors prasidejo arba sugenda)
veiksnumo laikas – tik serverio veikimo laikas. Pranešimas, jei jis pasikeitė (t. y. serveris perkrautas)
kliento_ip
dirsize – mes naudojame jį stebėti, kada mūsų virtualios mašinos rootfs viršija leistiną dydį, neįvedant griežtų apribojimų ir vartotojo namų katalogų dydžiui.
tuščias ir netuščias – stebėti failus, kurie turi būti tušti (arba netušti). Pavyzdžiui, paties okerr serverio klaidų žurnalas turėtų būti tuščias, o jei jame yra net eilutė, gausiu pranešimą ir patikrinsiu. Tačiau pašto serverio mail.log NETURI būti tuščias (N minučių po pasukimo). Ir kartais jis buvo tuščias mums po sistemos atnaujinimo, kai logrotate negalėjo tinkamai paleisti rsyslog.
eilučių skaičius – failo eilučių skaičius (pvz., wc -l). Naudojame jį kaip švelnesnį tuščio pakaitalą, kai klaidų žurnalas vis dar gali augti, bet tik lėtai (pavyzdžiui, Googlebot pasiekia kai kuriuos uždarytus puslapius). Yra 2 eilučių per 20 minučių limitas. Jei jis didesnis, bus perspėjimas

Įdomūs vidiniai patikrinimai

Jei iki šiol skaitėte „įstrižai“, dabar bus įdomiau skaityti atidžiau.

atsargines kopijas

Stebi atsargines kopijas kataloge. Mūsų atsarginių kopijų failų pavadinimai yra „ServerName-20200530.tar.gz“. Kiekvienam serveriui okerr sukuriamas indikatorius ServerioPavadinimas-DATE.tar.gz (faktinė data pakeičiama į eilutę „DATE“). Taip pat stebimas pačios naujos atsarginės kopijos buvimas ir jos dydis (pavyzdžiui, ji negali būti mažesnė nei 90% ankstesnės atsarginės kopijos).

Ką reikia padaryti, kad nauja atsarginė kopija būtų sekama po to, kai pradėjome ją kurti ir įdėti į šį katalogą? Nieko! Tai labai patogus būdas, kai reikia nieko nedaryti, nes:

„Nieko“ nedaryti yra gana greita, tai sutaupo laiko
Sunku pamiršti „nieko“ nedaryti
Sunku padaryti „nieko“ blogo, su klaida. Niekas nėra pats patikimiausias būdas

Jei staiga nustos rodyti nauji atsarginės kopijos failai, bus įspėjimas. Jei, pavyzdžiui, išjungėte vieną iš serverių ir nebeturėsite atsarginių kopijų, turėsite ištrinti indikatorių (per žiniatinklio sąsają arba iš apvalkalo per API).

maxfilesz

Seka didžiausių failų dydį (paprastai: /var/log/*). Tai leidžia sugauti nenuspėjamas problemas, pavyzdžiui, brutalios jėgos slaptažodžius arba šlamšto siuntimą per serverį.

runstatus/runline

Tai du svarbūs tarpinio serverio moduliai, skirti kitoms programoms serveryje paleisti. „Runstatus“ praneša programos išėjimo kodą indikatoriui. Pavyzdžiui, okerr nereikalauja (nereikalauja) modulio, kad patikrintų, ar veikia systemd paslaugos. Tai atliekama naudojant „runstatus“ (žr. toliau). Runline – praneša serveriui programos sukurtą eilutę. Pavyzdžiui, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" „Runline“ konfigūracijoje mūsų serveryje sukuria indikatorių servername:temp su procesoriaus temperatūra.

SQL

Vykdo skaitmeninę užklausą MySQL ir praneša apie rezultatą indikatoriui. Paprastu atveju galite padaryti, pavyzdžiui, „SELECT 1“ - tai patikrins, ar veikia visa DBVS.

Tačiau daug įdomesnė programa yra, pavyzdžiui, užsakymų skaičiaus stebėjimas internetinėje parduotuvėje. Jei žinote, kad turite 100 ar daugiau užsakymų per valandą, galite nustatyti minimalų limitą iki 100 arba 80. Tada, jei jūsų pardavimai staiga sumažės, gausite įspėjimą ir galėsite tai išsiaiškinti.

Atminkite, kad nesvarbu, dėl kokios nenuspėjamos priežasties taip atsitiko:

Serveris tiesiog nepasiekiamas (išjungtas arba be tinklo), o įspėjimas kilo dėl to, kad indikatorius buvo „supuvęs“.
Serveris kažkuo perkrautas, veikia lėtai arba pametami paketai, nepatogu vartotojams ir jie išeina nenusipirkę
Serveris įtrauktas į šiukšlių sąrašus, o laiškai iš jo nepriimami, vartotojai negali registruotis
Reklaminės kampanijos biudžetas išseko, baneriai nesisuka.

Priežasčių gali būti daugybė, ir visų jų negalima numatyti iš anksto, be to, techniškai sunku atsekti. Bet jūs galite patogiai stebėti galutinį parametrą (užsakymus) ir pagal juos nustatyti, kad situacija yra įtartina ir verta ją spręsti.

Loginiai rodikliai

Leidžia naudoti Būlio išraiškas (Python sintaksę) per modulį patvirtinti(straipsnis apie Habré). Pateikiami projekto duomenys ir jo rodikliai. Pavyzdžiui, aukščiau esančiame skyriuje apie SQL tikrinimą galbūt pastebėjote silpnąją vietą – dieną galime turėti 100 pardavimų per valandą, o naktį – 20, ir tai įprasta, ne problema. Ką turėčiau daryti? Indikatorius naktį nuolat panikuoja.

Galite sukurti du indikatorius – dieną ir naktį. Padarykite abu „tylius“ (jie nesiųs įspėjimų). Ir sukurti loginį indikatorių, kuris reikalauja, kad dienos indikatorius būtų gerai iki 20:00, o po 20:00 užtenka, kad naktinis būtų gerai.

Kitas loginio rodiklio naudojimo pavyzdys yra eskalacija. Pavyzdžiui, projekto vadovas atsisako įspėjimų (jam to daryti nereikia, administratoriai turėtų reaguoti į įprastas problemas), tačiau užsiprenumeruoja loginį indikatorių, kuris nusidažo raudonai, jei kuris nors projekto indikatorius per skirtą laiką nepataisomas.

Taip pat galima nustatyti leistiną darbo laiką, pavyzdžiui, nuo 3 iki 5 val. Mums nerūpi, jei serveriai ir svetainės sugenda šiuo metu. Bet 5:00 jie turi dirbti. Jeigu jie neveikia kitu metu – perspėkite. Loginis indikatorius taip pat leidžia atsižvelgti į serverio dubliavimą. Jei turite 5 žiniatinklio serverius, administratoriai gali bet kada išjungti 1–2 serverius. Bet jei mūšyje bus mažiau nei 3 iš 5 serverių, bus įspėjimas.

Aukščiau pateikti pavyzdžiai nėra oker funkcijos, o ne kai kurios funkcijos, kurias reikia suaktyvinti ir sukonfigūruoti. Okerra neturi visų šių funkcijų, tačiau yra loginis modulis, leidžiantis įgyvendinti šią funkciją (Maždaug kaip programavimo kalboje – jei turime aritmetinius operatorius, tai mums nereikia specialios funkcijos 20% PVM apskaičiavimui iš kalbos, visada galite tai padaryti patys, kad atitiktų jūsų poreikius).

„Logic Indicator“ tikriausiai yra viena iš nedaugelio gana sudėtingų okerr temų, tačiau gera žinia ta, kad jums nereikia jos įvaldyti, kol to neprireiks. Tačiau tuo pat metu jie labai išplečia galimybes, o pati sistema yra gana paprasta.

Pridėkite savo čekius

Labai norėčiau perteikti mintį, kad okerr yra ne tūkstančių paruoštų čekių rinkinys visoms progoms, o priešingai – visų pirma – paprastas variklis su paprasta galimybe susikurti savo čekius. Sukurti savo čekius sistemoje okerr nėra įsilaužėlių, sistemų bendradarbių ar bent jau pažengusių okerr vartotojų užduotis, bet įmanoma užduotis bet kuriam administratoriui, kuris pirmą kartą įdiegė Linux prieš mėnesį.

Minimalaus darbo užmokesčio patikrinimai atliekami per modulį paleidimo būsena:

Ši konfigūracijos eilutė paleidimo būsena praneš, jei /bin/true staiga nepasileidžia arba grąžins ką nors kita nei 0.

true_OK=/bin/true

Tik viena eilutė – ir štai mes jau šiek tiek išplėstas funkcionalumas okerr.

Net ir toks patikrinimas jau turi savo vertę: jei staiga jūsų serveris sugenda, atitinkamas indikatorius okerr serveryje nebus laiku atnaujintas, o praėjus laikui pasirodys įspėjimas.

Šis patikrinimas praneš, kad apache2 serveris sudužo (na, niekada negali žinoti...):

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

Taigi, jei kalbate kokia nors programavimo kalba ir bent jau galite rašyti apvalkalo scenarijus, tuomet jau galite pridėti savo čekius.

Sunkiau - galite parašyti (bet kuria kalba) savo modulį okerrmod. Paprasčiausiu atveju tai atrodo taip:

#!/usr/bin/python3

print("STATUS: OK")

Ar tai nėra labai sunku? Modulis turi pats atlikti patikrinimą ir išvesti rezultatus į STDOUT. Sudėtingesnis modulis suteikia, pavyzdžiui, tai:

$ 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

Jis vienu metu atnaujina kelis indikatorius (atskiriamas tuščia eilute), prireikus juos sukuria, nurodo patikros detales ir žymą, pagal kurią prietaisų skydelyje lengva rasti reikiamus rodiklius.

Yra „Telegram“ robotas @OkerrBot. Nereikia apkrauti telefono atskiromis programomis (man nepatinka, kad Pyaterochka reikia vienos programos su žemėlapiu, Lentai kitos, MTS trečios ir taip visiems, visiems, visiems). Pakanka vienos telegramos. Per telegramą galite iš karto gauti įspėjimus, patikrinti projekto būseną ir duoti komandą dar kartą patikrinti visus probleminius rodiklius. Išėjome iš teatro/lėktuvo, dvi valandas nelaikėme piršto ant pulso, įjungėme telefoną, paspaudėme vieną mygtuką pokalbių robote ir įsitikinome, kad viskas gerai.

Būsenos puslapiai

Šiais laikais statuso puslapiai yra beveik privalomi kiekvienam verslui, kuris turi IT, atsakingai žiūri į patikimumą ir pagarbiai elgiasi su savo klientais/vartotojais.

Įsivaizduokite situaciją – vartotojas nori ką nors padaryti, peržiūrėti informaciją arba pateikti užsakymą, bet kažkas neveikia. Jis nežino, kas vyksta, kieno pusėje yra problema ir kada ji bus išspręsta. Galbūt jūsų įmonė tiesiog turi neveikiančią svetainę? O gal jis sugedo prieš šešis mėnesius ir bus sutvarkytas po dvejų metų? Bet šaldytuvą reikia nusipirkti dabar, jis jau vežimėlyje... Ir visai kitas reikalas, kai žmogus mato, kad tau kažkas negerai (bent jau aišku, kad problema ne jo pusėje), kad problema buvo aptikta, kad jau dirbate su ja, o gal net užsirašėte apytikslį pataisymo laiką. Vartotojas gali užsiprenumeruoti ir gauti pranešimą el. paštu, kai problema išspręsta ir jis gali daryti tai, ką norėjo (pirkti šaldytuvą).

Problemų ir prastovų pasitaiko visiems. Tačiau vartotojai ir partneriai labiau pasitiki tais, kurie yra skaidresni ir atsakingesni.

Čia 10 kitų projektų, leidžiančių kurti būsenos puslapius, apžvalga. Štai pavyzdžiai, kaip atrodo šie projekto puslapiai Pitonas и Dropbox. okerr būsenos puslapis.

Perkėlimas

Kad šis straipsnis netaptų dar ilgesnis, dar kartą kreipsiuosi į savo ankstesnį straipsnį - Paprastas svetainės perkėlimas . Jei galite sukurti dublikatą serverį, tada naudodami perjungimą iš esmės neturėsite ilgos prastovos – kai tik bus aptikta problema, vartotojai bus automatiškai nukreipti į veikiantį atsarginį serverį. Ir man atrodo, kad tai labai įdomi, ryški funkcija, kuri retai kur pasiekiama.

Žemi sistemos reikalavimai

Okerr serveriams naudojame mašinas su RAM nuo 2Gb. Tinklo jutikliams užtenka net 512Mb. Kliento dalis paprastai yra beveik nulis. (Plastikinis maišelis okerrupdate sveria 26 Kb, bet reikia Python3 ir standartinių bibliotekų). Klientas veikia iš cron scenarijaus, todėl jis nenaudoja jokio nuolatinio atminties. Tarp mūsų stebimų mašinų turime jutiklius (ypač pigius VPS su 512 Mb RAM) ir Raspberry Pi. Tai įmanoma net ir be kliento dalies siųsti atnaujinimus per curl! (žr. žemiau)

Atsižvelgiant į tai – okerr, tikriausiai labiausiai nemokama stebėjimo sistemą iš turimų, nes net norint naudotis kita nemokama atvirojo kodo sistema kaip Zabbix ar Nagios, reikia jai skirti resursus (serverį), o tai jau pinigai. Be to, vis dar reikalinga tam tikra serverio priežiūra. Su okerr šią dalį galima nuimti. Arba jums nereikia jo pašalinti ir naudoti savo serverį, atsižvelgiant į tai, kas jums labiausiai patinka.

API ir integravimas į patentuotą programinę įrangą

Paprasta ir atvira architektūra. okerr turi gana paprastą API, su kuriuo lengva dirbti. Reikia sukurti 1000 rodiklių? Tai padarys vienas 3–4 eilučių apvalkalo scenarijus. Reikia iš naujo sukonfigūruoti 1000 indikatorių? Tai taip pat labai lengva. Pavyzdžiui, norime dar kartą patikrinti visus HTTPS sertifikatus iš Rusijos jutiklio:

#!/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

Indikatorių galite atnaujinti naudodami mūsų kliento modulį, net ir be jo, tiesiog per 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/

Rodiklius galite atnaujinti tiesiai iš savo programos. Pavyzdžiui, siunčiami širdies plakimo signalai, kad okerr žinotų, kad jis veikia, ir sukeltų pavojaus signalą, jei jis sugenda ar užšąla. Beje, okerr komponentai būtent tai ir daro – okerr stebi save, o beveik bet kurio modulio problemos bus aptiktos ir sugeneruos įspėjimą apie problemą. (O šiuo atveju „beveik“ - jie tikrinami iš kito serverio)

Štai kodas (supaprastintas) mūsų telegramos robote:

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))

Yra biblioteka, skirta atnaujinti indikatorius iš Python programų okerrupdate, jokioms kitoms kalboms bibliotekų nėra, tačiau galite iškviesti okerrupdate scenarijų arba pateikti HTTP užklausą okerr serveriui.

Kaip okerr mums padeda

Okerras pakeitė mūsų gyvenimus. Iš tikrųjų. Galbūt tą patį galėtų padaryti ir kita stebėjimo sistema, bet dirbti su okerr mums lengva ir paprasta ir ji turi visas reikalingas funkcijas (pridėjome tai, ko neturėjo). Beje, jei trūksta kokių nors funkcijų, klauskite ir pridėsiu (nežadu, bet noriu, kad okerr būtų geriausia stebėjimo sistema mažiems-vidutiniams projektams). Arba dar geriau, pridėkite patys – tai paprasta.

Mums pavyko gyventi pagal principą „sužinokite apie visas problemas iš Kerros“. Jei staiga iškyla problema, apie kurią nesužinojome iš okerr, prie okerr pridedame čekį. (šiuo atveju „mes“ turiu omenyje mus kaip sistemos vartotojus, o ne bendradarbius). Iš pradžių tai buvo įprasta, bet dabar tapo labai reta.

Stebėjimas

Per okerr stebime žurnalų dydžius visuose serveriuose. Akimis apgalvotai perskaityti kiekvienos rąsto eilutės, žinoma, neįmanoma, bet tiesiog augimo tempo stebėjimas jau duoda daug. Per tai atradome šlamšto siuntimą ir žiaurios jėgos slaptažodžių paieškas, o kai kurioms programoms „išprotėjus“, kažkas joms nepavyksta ir jie tai kartoja vėl ir vėl (kiekvieną kartą įrašant po kelias eilutes prie žurnalo ).

SSL sertifikatai. Beveik iš karto po paleidimo Leidžia šifruoti mūsų klientas pradėjo teikti nemokamus SSL sertifikatus savo klientams (jų apie tūkstantį). O administracijai tai pasirodė tiesiog pragaras! Faktas yra tas, kad svetainės yra „gyvai“, klientai periodiškai prašo ką nors padaryti, programuotojai tai daro. Pavyzdžiui, jie gali visiškai laisvai perkelti svetainę į kitą DocumentRoot. Arba pridėkite besąlyginį perrašymą prie virtualios prieglobos konfigūracijos. Natūralu, kad po to automatinis sertifikatų atnaujinimas nutrūksta. Dabar mes turime visus SSL pagrindinius kompiuterius, kurie automatiškai pridedami prie okerr per kitą naudingą paslaugų paketą a2conf. Tiesiog paleiskite a2okerr.py — ir jei serveryje atsiras kelios naujos svetainės, jos automatiškai atsiras okerr. Jei staiga dėl kokių nors priežasčių sertifikatas nebus pratęstas, likus trims savaitėms iki pažymėjimo galiojimo pabaigos, mes žinome, ir išsiaiškinsime, kodėl jis neatnaujintas, toks šuo. a2certbot.py iš to paties paketo - tai labai padeda (iš karto patikrina labiausiai tikėtinas problemas - ir parašo, kas buvo gerai patikrinta, o kur greičiausiai yra problema).

Stebime visų savo domenų galiojimo datą. Visi mūsų pašto serveriai, siunčiantys laiškus, taip pat yra patikrinti pagal daugiau nei 50 skirtingų juodųjų sąrašų. (Ir kartais jie patenka į juos). Beje, ar žinojote, kad Google pašto serveriai taip pat yra juodajame sąraše? Tik savęs patikrinimui mail-wr1-f54.google.com įtraukėme į stebimus serverius ir jis vis dar yra SORBS juodajame sąraše! (Tai yra apie „anti-spamer“ vertę)

Atsarginės kopijos – jau rašiau aukščiau, kaip paprasta jas stebėti naudojant okerr. Bet mes stebime ir naujausias atsargines kopijas savo serveryje, ir (naudodami atskirą priemonę, kuri naudoja okerr) atsargines kopijas, kurias įkeliame į „Amazon Glacier“. Ir taip, karts nuo karto pasitaiko problemų. Nenuostabu, kad jie žiūrėjo.

Mes naudojame eskalavimo indikatorių. Tai rodo, ar kokia nors problema nebuvo išspręsta ilgą laiką. Ir aš pats, kai spręsiu kokias nors problemas, kartais galiu jas pamiršti. Eskalavimas yra geras priminimas, net jei stebite save.

Apskritai manau, kad mūsų darbo kokybė pagerėjo dydžiu. Prastovos beveik nėra (arba klientas nespėja to pastebėti. Tiesiog ššš!), o darbų kiekis sumažėjo ir darbo sąlygos tapo ramesnės. Nuo avarinių darbų su skylių lopymu juostele perėjome prie ramaus ir pamatuoto darbo, kai daug problemų nuspėjama iš anksto ir yra laiko joms užkirsti kelią. Net ir iškilusias problemas taip pat tapo lengviau išspręsti: pirma, apie jas sužinome prieš klientams panikuojant, antra, dažnai nutinka taip, kad problema yra susijusi su neseniai atliktais darbais (darydamas vieną dalyką sulaužiau kitą) todėl karšta Su juo lengviau susidoroti pėdsakams.

Bet buvo ir kitas atvejis...

Ar žinojote, kad populiariame Debian 9 (Stretch) toks populiarus paketas kaip phpmyadmin vis dar (jau daug mėnesių!) yra pažeidžiamas? (CVE-2019-6798). Kai atsirado pažeidžiamumas, mes greitai jį padengėme įvairiais būdais. Bet aš nustatiau saugos sekimo puslapio stebėjimą okerr, kad žinočiau, kada pasirodys „gražus“ sprendimas (per SHA1 turinio sumą). Indikatorius kelis kartus trūktelėjo, puslapis pasikeitė, bet kaip matote vis tiek (nuo 2019 m. sausio mėn.!) nerodo, kad problema išspręsta. Gal, beje, kas nors žino, kokia problema, kad toks svarbus paketas vis dar yra pažeidžiamas daugiau nei metus?

Kitą kartą panašioje situacijoje: po SSH pažeidžiamumo reikėjo atnaujinti visus serverius. O kai nustatote užduotį, turite kontroliuoti vykdymą. (Pavaldiniai linkę nesuprasti, užsimiršti, susipainioti ir klysti). Todėl pirmiausia pridėjome SSH versijos patikrą prie okerr visuose serveriuose, o per okerr įsitikinome, kad naujinimai buvo įdiegti visuose serveriuose. (Patogu! Aš pasirinkau tokio tipo indikatorių, ir iškart matai, kuris serveris turi kokią versiją). Kai įsitikinome, kad užduotis atlikta visuose serveriuose, pašalinome indikatorius.

Porą kartų buvo situacija, kai iškyla tam tikra problema, o paskui praeina savaime. (turbūt visiems pažįstamas?). Tuo metu, kai pastebite, kol patikrinate – ir nėra ką tikrinti – viskas jau veikia gerai. Bet tada vėl sugenda. Taip nutiko, pavyzdžiui, su produktais, kuriuos įkėlėme į „Amazon Marketplace“ (MWS). Kažkuriuo momentu pakrautas inventorius buvo neteisingas (netinkami prekių kiekiai ir neteisingos kainos). Mes tai išsiaiškinome. Tačiau norint tai išsiaiškinti, buvo svarbu iš karto išsiaiškinti problemą. Deja, MWS, kaip ir visos „Amazon“ paslaugos, yra šiek tiek lėtos, todėl visada buvo vėlavimas, bet vis tiek galėjome bent apytiksliai suvokti ryšį tarp problemos ir ją sukeliančių scenarijų (patikrinome, užstrigome jį okerr ir iš karto patikrino, gavęs įspėjimą).

Įdomų dėklą neseniai kolekciją papildė didelis ir brangus Europos šeimininkas, kuriuo naudojasi mūsų klientas. Staiga VISI mūsų serveriai dingo iš radaro! Pirma, pats klientas (greičiau nei okerra!) pastebėjo, kad svetainė, su kuria jis dirbo, neatsidaro ir padarė apie tai bilietą. Tačiau sugriuvo ne viena svetainė, o visos! (Nataša, mes viską numetėme!). Čia Okerras pradėjo siųsti ilgus pėdų įvyniojimus su visais jam užsidegančiais indikatoriais. Panika, panika, bėgame ratu (ką dar galime padaryti?). Tada viskas pakilo. Pasirodo, duomenų centre buvo atliekama eilinė priežiūra (kartą per daugelį metų) ir, žinoma, turėjome būti perspėti. Bet jiems nutiko kažkokia problema ir jie mūsų neįspėjo. Na, daugiau infarktų, mažiau infarktų. Bet kai viskas bus atkurta, reikia dar kartą viską patikrinti! Neįsivaizduoju, kaip tai padaryčiau savo rankomis. Okerras viską išbandė per kelias minutes. Paaiškėjo, kad dauguma serverių buvo tiesiog laikinai nepasiekiami, tačiau jie veikė. Kai kurie buvo perkrauti, bet taip pat atsistojo kaip reikiant. Iš visų nuostolių netekome dviejų atsarginių kopijų, kurios pagal karūną turėjo būti sukurtos ir įkeltos, kol vyko šis pilnas bananas. Net nesivarginau jų kurti, tik po dienos atėjo įspėjimai, kad viskas gerai, atsirado atsarginės kopijos. Man labai patinka šis pavyzdys, nes okerr pasirodė labai naudingas situacijoje, apie kurią iš anksto net nesusimąstėme, bet toks ir yra stebėjimo tikslas – atsispirti nenuspėjamai.

Okerr jutikliams naudojame pigiausią įmanomą hostingą (kur kokybė ir patikimumas nėra svarbūs, jie vienas kitą apdraudžia). Taigi, neseniai radome labai gerą prieglobą ir labai pigų, etalonai yra nuostabūs. Bet... kartais paaiškėja, kad iš virtualios mašinos išeinantys ryšiai atliekami iš kito (kaimyninio) IP. Stebuklai. Client_ip modulis su https://diagnostic.opendns.com/myip gauna neteisingą IP. O iš indikatoriaus serverio žurnalų aišku, kad atnaujinimas atkeliavo ir iš šio kaimyninio IP. Dabar spręskime su parama. Gerai, kad tai pastebėjome taikos metu. Bet, pavyzdžiui, dažnai atsitinka taip, kad prieiga registruojama pagal IP baltąjį sąrašą – o jei serveris kartais taip trumpai mirksi – šią problemą galima bandyti gaudyti labai ilgai.

Na, dar vienas dalykas – kadangi kalbame apie VPS hostingą – visada naudojame nebrangius (hetzner, ovh, scaleway). Man tai labai patinka tiek etalonų, tiek stabilumo atžvilgiu. Taip pat kitiems projektams naudojame daug brangesnį „Amazon EC2“. Taigi, okerr dėka mes turime savo pagrįstą nuomonę. Jie abu krenta. Ir nepasakyčiau, kad per ilgą mūsų stebėjimų laikotarpį pigūs hostingai, tokie kaip hetzner, pasirodė esąs pastebimai mažiau stabilūs nei EC2. Todėl, jei nesate susieti su kitomis „Amazon“ funkcijomis, kam mokėti daugiau? 🙂

Kas toliau?

Jei šiame etape dar neatbaidžiau jūsų nuo Okerr, išbandykite! Galite eiti tiesiai į šią nuorodą okerr demonstracinė sąskaita (Spustelėkite dabar!) Tačiau atminkite, kad visiems yra tik viena demonstracinė paskyra, todėl jei ką nors darysite, kažkas kitas toje pačioje paskyroje gali jums trukdyti tuo pačiu metu. Arba (geriau) užsiregistruokite per nuorodą ne vietoje okerr - viskas paprasta, be SMS. Jei nemėgstate naudoti tikrojo el. pašto, galite naudoti vienkartinį, pvz., mailinator (rekomenduoju getnada.com). Laikui bėgant tokios paskyros gali būti ištrintos, tačiau jos bus tinkamos testavimui.

Po registracijos jūsų bus paprašyta treniruotis (atlikti keletą ne itin sunkių treniruočių užduočių). Pradiniai limitai labai maži, bet treniruotėms ar vienam serveriui jų pakanka. Baigus mokymus, limitai (pvz., maksimalus rodiklių skaičius) bus didinami.

Iš dokumentacijos – pirmiausia WIKI serverio pusėje ir kliente (okerrupdate wiki). Bet jei kas neaišku, rašykite į support (at) okerr.com arba palikite bilietą – pasistengsime viską išspręsti greitai.

Jei naudojatės rimtai ir šių padidintų limitų neužtenka, rašykite į supportą ir mes padidinsime (nemokamai).

Ar norite įdiegti okerr serverį savo serveryje? čia okerr-dev saugykla. Rekomenduojame įdiegti švarioje virtualioje mašinoje, tada galite tai padaryti tiesiog naudodami diegimo scenarijų. Jūsų virtualioje mašinoje – jokių apribojimų :-). Na, vėlgi, jei kas nutiks, visada stengsimės padėti.

Norime, kad šis projektas įsibėgėtų, kad mūsų dėka pasaulis taptų patikimesnis. Dėl nemokamos programinės įrangos ir paslaugų pasaulis tapo draugiškesnis ir vystosi dinamiškiau. Šaltiniai gali būti saugomi nemokamame github, paštui galite naudoti nemokamą gmail. Naudojame nemokamai nauji darbai už paramą. Norėdami tai padaryti, jums nereikia mokėti už serverius, jums nereikia atsisiųsti ir konfigūruoti ir jums nereikia spręsti įvairių veiklos problemų. Kiekvienas naujas projektas, kiekviena komanda iš karto turi paštą, saugyklas ir CRM. Ir visa tai labai kokybiškai ir nemokamai bei iš karto. Norime, kad taip būtų ir stebėsenai – mažos įmonės ir projektai galėtų nemokamai naudotis okerr ir net gimimo bei augimo stadijoje turėtų suaugusiųjų rimtų projektų patikimumą.

Šaltinis: www.habr.com