Antaŭ du jaroj mi jam faris afiŝon Simpla malsukceso por retejo pri okerr. Nun estas iom da evoluo de la projekto, kaj mi ankaŭ publikigis okerr servila flanko fontkodo sub malferma permesilo, tial mi decidis skribi ĉi tiun mallongan recenzon pri Habr.

[ plena grandeco ]

Al kiu ĝi povas interesi

Ĉi tio povas interesi vin se vi laboras en malgranda teamo aŭ sole. Vi ne havas monitoradon kaj vi ne certas ĉu vi vere bezonas ĝin. Aŭ vi provis iun popularan seriozan monitoradon "por la grandaj knaboj", sed ĝi iel "ne ekflugis" por vi, aŭ ĝi funkcias en preskaŭ defaŭlta agordo kaj ne multe ŝanĝis vian vivon. Kaj ankaŭ - se vi certe ne planas asigni tutan dungiton (aŭ eĉ fakon) por kontroli la monitoran panelon almenaŭ kelkajn horojn tage aŭ agordi ĝin.

Kial okerr estas nekutima

Poste mi montros interesajn trajtojn de la okero, kiuj distingas ĝin de iuj aliaj monitoraj sistemoj.

Okerr estas hibrida monitorado

Dum interna monitorado, "agento" funkcias sur la monitoritaj maŝinoj, kiu transdonas datumojn al la monitora servilo (ekzemple, libera diskospaco). Kiam ekstere, la servilo faras kontrolojn tra la reto (ekzemple, ping aŭ reteja havebleco). Ĉiu aliro havas siajn limojn. Okerr uzas ambaŭ opciojn. Kontroloj ene de serviloj estas faritaj de tre malpeza (30Kb) agento aŭ viaj propraj skriptoj kaj aplikaĵoj, kaj retaj kontroloj estas faritaj per okerr-sensiloj en malsamaj landoj.

okerr ne estas nur programaro, sed ankaŭ servo

La servila parto de iu ajn monitorado estas granda kaj kompleksa, estas malfacile instali kaj agordi, kaj ĝi postulas rimedojn. Per okerr vi povas instali vian propran monitoran servilon (ĝi estas senpaga kaj malfermfonta), aŭ vi povas simple uzi nur la klientparton kaj uzi la servon de nia servilo. Ankaŭ senpaga.

Se monitorado permesas vin kompensi kaj kovri la mankon de fidindeco en serviloj kaj aplikaĵoj, tiam aperas filozofia demando - kiu estas la gardisto? Kiel monitorado informos nin pri problemo, se ĝi mem "mortis" ial, aparte aŭ kune kun viaj aliaj rimedoj (ekzemple, la kanalo al la datumcentro falis)? Kiam vi uzas la eksteran servon okerr - ĉi tiu problemo estas solvita - vi ricevos atentigon eĉ se la tuta datumcentro kun viaj serviloj estas sen potenco aŭ estas atakita de zombioj.

Kompreneble, ekzistas risko, ke la okerr-servilo mem estos neatingebla, tio estas vera (kiel vi scias, 90% de fidindeco ĉiam estas akirita simple kaj "senpaga", 99% kun minimuma peno, kaj ĉiu sekva naŭ estas. eksponente pli malfacila). Sed, unue, la ŝancoj, ke tio okazu estas pli malaltaj, kaj due, la problemo povas resti nerimarkita nur se ĝi koincidas kun problemoj en niaj serviloj. Se ni havas 99.9% fidindecon, kaj vi havas 99.9% (ne tro altajn nombrojn), tiam la ŝanco de nerimarkita fiasko estas 0.1% de 0.1% = 0.0001%. Aldoni tri naŭojn al via fidindeco preskaŭ sen peno kaj sen kosto estas tre bone!

Alia avantaĝo de monitorado kiel servo estas, ke gastiga provizanto aŭ retstudio povas instali okerr-servilon kaj disponigi aliron al klientoj kiel pagita aŭ senpaga kroma servo. Viaj konkurantoj nur havas gastigadon kaj retejojn, sed vi havas fidindan gastigadon kun monitorado.

Okerr temas pri indikiloj

La indikilo estas "ampolo". Ĝi havas du ĉefajn statojn - verda (OK) aŭ ruĝa (ERR). La projekto enhavas multajn grupigitajn (ekzemple, laŭ servilo) indikiloj. Sur la ĉefpaĝo de la projekto, vi tuj vidas, ke aŭ ĉio estas verda (kaj vi povas fermi ĝin), aŭ io estas lumigita ruĝa kaj devas esti korektita. Dum transiro inter ĉi tiuj statoj, atentigo estas sendita. Unufoje tage dum vi agordas ĝin, resumo de la projekto estas sendita.

Ĉiu okerr-indikilo havas enkonstruitajn kondiĉojn per kiuj ĝi ŝanĝas staton (en Zabbix tio estas nomita ellasilo). Ekzemple, ŝarĝa mezumo devus esti ne pli ol 2 (kompreneble, ĉi tio estas agordebla). Kaj por ĉiu interna kontrolo (ŝarĝo averaĝa, sen disko, ...) estas gardhundo. Se ial ni ne ricevas sukcesan konfirmon je la difinita tempo, eraro estas registrita kaj atentigo estas sendita.

Nia kutima laborŝablono estas kontroli retpoŝtojn matene, kaj rigardi la resumon inter aliaj leteroj (ni planas ĝin je la komenco de laboro). Se ĉio estas bone en ĝi, ni faras aliajn gravajn aferojn (sed por esti sekuraj, ni povas rapide rigardi la okerra panelo kaj certigi, ke ĉio estas verda ĉi-momente). Se venas alarmo, ni reagas.

Kompreneble, eblas simple konservi "informajn" indikilojn (por vidi la bildon de la reto de monitorado), sed ĉio estas farita por simple, facile kaj rapide krei indikilojn specife por aŭtomata monitorado kaj sendo de atentigoj.

La celo por kiu vi agordas okerr estas en atentigoj, por ke vi povu krei indikilon en minuto, ĝi povus "dormi" dum jaro, nur akcepti ĝisdatigojn, kaj kiam jaron poste io rompiĝas, ĝi lumiĝas kaj sendas. atentigo. La minuto, kiun vi iam pasigis krei indikilon, pagis; vi eksciis pri la problemo tuj, antaŭ iu ajn alia. Eblas, ke ili riparis ĝin antaŭ ol iu ajn rimarkis. Io, kio estas rapide levita, ne estas konsiderata kiel falinta!

Sekureco

Estus domaĝe, se vi agordus monitoradon por pliigi fidindecon, sed kiel rezulto, vi estas atakita tra la reto per ĝi, kaj estas sufiĉe multaj retaj vundeblecoj en malsamaj monitoraj iloj (Zabbikh, Nagios).

Agento (okerrmod de pako okerrupdate) funkcianta en la sistemo ne estas retservilo, sed kliento. Sekve, ne estas pliaj malfermaj havenoj sur la monitorita servilo, la kliento facile funkcias malantaŭ fajroŝirmilo aŭ NAT kaj estas tre malfacile (mi dirus "neeble") pirati tra la reto, ĉar principe ĝi ne aŭskultas la reton. ingo.

Plena monitora kovrado

Nun nia regulo estas, ke ni lernas pri ĉiuj teknikaj problemoj de okerr. Se subite la regulo estas malobservita (okerr ne avertis pri ĝia baldaŭa okazo (se tio eblas) aŭ ke ĝi jam okazis) - ni aldonas ĉekojn al okerr.

Eksteraj kontroloj

Sufiĉe tipa aro:

ping
http-stato
kontrolante la validecon kaj freŝecon de la SSL-atestilo (avertos ĉu ĝi estas eksvalidiĝonta)
malfermu TCP-havenon kaj standardon sur ĝi
http grep (la paĝo [ne devas] enhavi specifan tekston)
sha1 hash por kapti paĝajn ŝanĝojn.
DNS (DNS-rekordo devas havi specifan valoron)
WHOIS (avertos se la domajno estas malboniĝos)
Antispama DNSBL (gastiga kontrolo kontraŭ 50+ kontraŭspamaj nigraj listoj samtempe)

Internaj kontroloj

Ankaŭ, sufiĉe norma aro (sed facile disetendebla).

df (libera diskospaco)
ŝarĝo mezumo
opentcp (malfermu TCP-aŭskultajn ingojn - sciigos ĉu io komenciĝis aŭ kraŝis)
uptime - nur uptime sur la servilo. Sciigos ĉu ĝi ŝanĝiĝis malsupren (t.e. la servilo troŝarĝis)
kliento_ip
dirsize - ni uzas ĝin por spuri kiam niaj virtualaj maŝinaj radikoj superas la permesitan grandecon, sen enkonduki striktajn restriktojn, kaj la grandecon de uzanthejmdosierujoj
malplena kaj nemalplena - monitoru dosierojn kiuj devus esti malplenaj (aŭ ne malplenaj). Ekzemple, la erarprotokolo de la okerr-servilo mem estu malplena, kaj se eĉ estas linio en ĝi, mi ricevos sciigon kaj kontrolos ĝin. Sed mail.log sur la poŝtservilo NE estu malplena (N minutojn post rotacio). Kaj foje ĝi estis malplena por ni post sistema ĝisdatigo, kiam logrotate ne povis rekomenci rsyslog ĝuste.
linecount - nombro da linioj en la dosiero (kiel wc -l). Ni uzas ĝin kiel pli mola anstataŭaĵo por malplena, kiam la erarprotokolo ankoraŭ povas kreski, sed nur malrapide (ekzemple, Googlebot trafas kelkajn fermitajn paĝojn). Estas limo de 2 linioj en 20 minutoj. Se ĝi estas pli alta, estos atentigo

Interesaj internaj kontroloj

Se vi legis "diagonale" ĝis ĉi tiu punkto, nun estos pli interese legi pli atente.

rezervoj

Monitoras sekurkopiojn en la dosierujo. Niaj rezervaj dosieroj havas nomojn kiel "ServerName-20200530.tar.gz". Por ĉiu servilo en okerr, la indikilo ServerName-DATE.tar.gz estas kreita (la fakta dato ŝanĝiĝas al la linio "DATO"). La ĉeesto mem de freŝa sekurkopio kaj ĝia grandeco ankaŭ estas monitoritaj (ekzemple, ĝi ne povas esti malpli ol 90% de la antaŭa sekurkopio).

Kion oni devas fari por ke nova sekurkopio komencu esti spurita post kiam ni komencis krei ĝin kaj meti ĝin en ĉi tiun dosierujon? Nenio! Ĉi tio estas tre oportuna aliro kiam vi devas fari "nenion" ĉar:

Fari "nenion" estas sufiĉe rapida, ĝi ŝparas tempon
Estas malfacile forgesi fari "nenion"
Estas malfacile fari "nenion" malbone, kun eraro. Nenio estas la plej fidinda metodo

Se subite freŝaj rezervaj dosieroj ĉesos aperi, estos atentigo. Se, ekzemple, vi malŝaltis unu el la serviloj, kaj ne plu ekzistus sekurkopioj, vi devos forigi la indikilon (per la retinterfaco aŭ de la ŝelo per la API).

maxfilesz

Konservas la grandecon de la plej grandaj dosieroj (tipe: /var/log/*). Ĉi tio ebligas al vi kapti neantaŭvideblajn problemojn, ekzemple, pasvortojn de krudforto aŭ sendado de spamo tra la servilo.

runstatus/runline

Ĉi tiuj estas du gravaj prokurmoduloj por ruli aliajn programojn sur la servilo. Runstatus raportas la programelirkodon al la indikilo. Ekzemple, okerr ne (postulas) modulon por kontroli ke systemd servoj funkcias. Ĉi tio estas farita per runstatus (vidu malsupre). Runline - raportas al la servilo la linion, kiun la programo produktas. Ekzemple, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" en la Runline-agordo sur nia servilo kreas indikilon servername:temp kun la procesora temperaturo.

sql

Efektivigas nombran demandon al MySQL kaj raportas la rezulton al la indikilo. En simpla kazo, vi povas fari, ekzemple, "SELECT 1" - ĉi tio kontrolos, ke la DBMS entute funkcias.

Sed multe pli interesa aplikaĵo estas, ekzemple, spuri la nombron da mendoj en reta vendejo. Se vi scias, ke vi havas 100 aŭ pli da mendoj por horo, vi povas agordi la minimuman limon al 100 aŭ 80. Tiam se viaj vendoj subite malaltiĝos, vi ricevos alarmon kaj vi povas eltrovi ĝin.

Notu, ke ne gravas pro kia neantaŭvidebla kialo tio okazis:

La servilo estas simple neatingebla (malŝaltita aŭ sen reto), kaj la atentigo venis de la fakto, ke la indikilo estis "putra".
La servilo estas troŝarĝita per io, ĝi funkcias malrapide aŭ pakoj estas perditaj, ĝi estas maloportuna por uzantoj kaj ili foriras sen fari aĉetojn.
La servilo estas inkluzivita en la spamlistoj kaj poŝto de ĝi ne estas akceptita, uzantoj ne povas registriĝi
La buĝeto pri reklama kampanjo elĉerpiĝis, la standardoj ne turniĝas.

Povas ekzisti iujn ajn kialojn, kaj ĉiuj el ili ne povas esti antaŭvideblaj, kaj estas teknike malfacile spuri. Sed vi povas oportune kontroli la finan parametron (mendoj) kaj determini de ili, ke la situacio estas suspektinda kaj meritas esti traktita.

Logikaj indikiloj

Permesas la uzon de Buleaj esprimoj (Python-sintakso) per modulo validigi(artikolo pri Habré). Datumoj de la projekto kaj ĝiaj indikiloj estas haveblaj por esprimo. Ekzemple, en la ĉapitro pri SQL-kontrolado supre, vi eble rimarkis malfortan punkton - tage ni povas havi 100 vendojn por horo, sed nokte - 20, kaj ĉi tio estas ofta, ne problemo. Kion mi devus fari? La indikilo konstante panikiĝos nokte.

Vi povas krei du indikilojn, tage kaj nokte. Faru ambaŭ "silentu" (ili ne sendos atentigojn). Kaj kreu logikan indikilon, kiu postulas, ke la taga indikilo estu bona antaŭ 20:00, kaj post 20:00 sufiĉas, ke la nokta indikilo estu bona.

Alia ekzemplo de uzado de logika indikilo estas eskalado. Ekzemple, projektestro malabonas de atentigoj (li ne bezonas fari tion, administrantoj devus respondi al normalaj problemoj), sed abonas logika indikilo, kiu fariĝas ruĝa se iu indikilo en la projekto ne estas korektita en la asignita tempo.

Ankaŭ, eblas agordi la permesitan tempon por laboro, ekzemple, de 3 ĝis 5 am. Ni ne zorgas ĉu serviloj kaj retejoj kraŝas dum ĉi tiu tempo. Sed je 5:00 ili devas labori. Se ili ne funkcias alifoje - atentu. La logika indikilo ankaŭ permesas al vi konsideri servilan redundon. Se vi havas 5 retservilojn, tiam administrantoj povas malŝalti 1-2 servilojn iam ajn. Sed se estas malpli ol 3 el 5 serviloj en batalo, estos atentigo.

La ĉi-supraj ekzemploj ne estas oker-funkcioj, ne iuj funkcioj, kiuj devas esti aktivigitaj kaj agordaj. Okerra ne havas ĉiujn ĉi tiujn funkciojn, sed ekzistas logika modulo, kiu ebligas al vi efektivigi ĉi tiun funkcion (Proksimume kiel en programlingvo - se ni havas aritmetikajn operatorojn, tiam ni ne bezonas specialan funkcion por kalkuli 20% AVI). de la lingvo, vi ĉiam povas fari ĝin mem laŭ viaj bezonoj).

Logika Indikilo verŝajne estas unu el la malmultaj relative kompleksaj temoj en okerr, sed la bona novaĵo estas, ke vi ne devas regi ĝin ĝis vi bezonos. Sed samtempe ili multe vastigas la kapablojn, konservante la sistemon mem sufiĉe simpla.

Aldonante viajn proprajn ĉekojn

Mi tre ŝatus transdoni la ideon, ke okerr ne estas aro de miloj da pretaj ĉekoj por ĉiuj okazoj, sed male – antaŭ ĉio – simpla motoro kun simpla kapablo krei viajn proprajn ĉekojn. Krei viajn proprajn ĉekojn en okerr ne estas tasko por retpiratoj, sistemkunprogramistoj aŭ almenaŭ altnivelaj uzantoj de okerr, sed farebla tasko por iu ajn administranto kiu instalis Linukson unuafoje antaŭ monato.

Kontroloj pri minimumaj salajroj estas faritaj per la modulo runstatus:

Ĉi tiu linio en la agordo runstatus sciigos vin se /bin/true subite ne komenciĝas aŭ resendas ion alian ol 0.

true_OK=/bin/true

Nur unu linio — kaj jen ni jam estas iomete disetendiĝis funkcieco okerr.

Eĉ tia kontrolo jam havas sian valoron: se subite via servilo kraŝos, la responda indikilo sur la okerr-servilo ne estos ĝustatempe ĝisdatigita, kaj post la tempo pasis, alarmo aperos.

Ĉi tiu kontrolo sciigos, ke la servilo apache2 kraŝis (nu, vi neniam scias...):

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

Do, se vi parolas iun ajn programlingvon, kaj almenaŭ povas skribi ŝelajn skriptojn, tiam vi jam povas aldoni viajn proprajn ĉekojn.

Pli malfacile - vi povas skribi (en iu ajn lingvo) vian propran modulon por okerrmod. En la plej simpla kazo ĝi aspektas jene:

#!/usr/bin/python3

print("STATUS: OK")

Ĉu ne estas tre malfacile? La modulo devas fari la kontrolon mem kaj eligi la rezultojn al STDOUT. Pli kompleksa modulo donas, ekzemple, ĉi tion:

$ 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

Ĝi ĝisdatigas plurajn indikilojn samtempe (apartigite per malplena linio), kreas ilin se necese, indikas kontrolajn detalojn kaj etikedon per kiu estas facile trovi la necesajn indikilojn en la panelo.

Telegramo

Estas Telegram-bot @OkerrBot. Vi ne bezonas malordigi vian telefonon per apartaj aplikaĵoj (mi ne ŝatas, ke por Pyaterochka vi bezonas unu aplikaĵon kun mapo, por Lenta alian, por MTS trian, kaj tiel plu por ĉiuj, ĉiuj, ĉiuj). Unu telegramo sufiĉas. Per telegramo vi povas tuj ricevi atentigojn, kontroli la staton de la projekto kaj doni komandon por rekontroli ĉiujn problemajn indikilojn. Ni forlasis la teatron/aviadilon, ne tenis nian fingron sur la pulso dum du horoj, ŝaltis la telefonon, premis unu butonon en la babilejo kaj certigis, ke ĉio estas en ordo.

Statusaj Paĝoj

Nuntempe, statuspaĝoj estas preskaŭ nepraj por iu ajn komerco, kiu havas IT, respondecan sintenon al fidindeco kaj kiu traktas siajn klientojn/uzantojn kun respekto.

Imagu situacion - uzanto volas fari ion, vidi informojn aŭ fari mendon, kaj io ne funkcias. Li ne scias kio okazas, de kiu flanko estas la problemo kaj kiam ĝi estos solvita. Eble via kompanio simple havas nefunkcian retejon? Aŭ ĉu ĝi rompis antaŭ ses monatoj kaj ĝi estos riparita post du jaroj? Sed vi devas aĉeti fridujon nun, ĝi jam estas en la ĉaro... Kaj estas tute alia afero, kiam homo vidas, ke io estas malbona ĉe vi (almenaŭ estas klare, ke la problemo ne estas liaflanke), ke la problemo estis malkovrita, ke vi jam laboras pri ĝi, kaj eble eĉ notis la proksimuman tempon por korekto. La uzanto povas aboni kaj ricevi retpoŝtan sciigon kiam la problemo estas riparita kaj li povas fari tion, kion li volis (aĉeti fridujon).

Problemoj kaj malfunkcio okazas al ĉiuj. Sed uzantoj kaj partneroj pli fidas tiujn, kiuj estas pli travideblaj kaj respondecaj en sia aliro al tio.

tie revizio de 10 aliaj projektoj, kiuj ebligas al vi krei statuspaĝojn. Jen ekzemploj de kiel aspektas ĉi tiuj projektpaĝoj python и Dropbox. okerr statuspaĝo.

Failover

Por ne plilongigi ĉi tiun artikolon, mi ree aludos al mia antaŭa artikolo - Simpla malsukceso por retejo . Se vi povas fari duplikatan servilon, tiam uzante malsukceson, vi esence ne havos longan malfunkcion - tuj kiam problemo estos detektita, uzantoj aŭtomate estos redirektitaj al funkcianta rezerva servilo. Kaj ŝajnas al mi, ke ĉi tio estas tre interesa, hela trajto, kiu malofte haveblas ie ajn.

Malaltaj sistemaj postuloj

Por okerr-serviloj, ni uzas maŝinojn kun RAM de 2Gb. Por retaj sensiloj, eĉ 512Mb sufiĉas. La klienta parto estas ĝenerale preskaŭ nula. (Plasta sako okerrupdate pezas 26 Kb, sed postulas Python3 kaj normajn bibliotekojn). La kliento kuras de cron-skripto, do ĝi havas nul konstantan memorkonsumon. Inter la maŝinoj, kiujn ni monitoris, ni havas sensilojn (supermalkara VPS kun 512Mb RAM) kaj Raspberry Pi. Ĝi eblas eĉ sen la klienta parto sendu ĝisdatigojn per buklo! (Vidu sube)

Konsiderante ĉi tion - okerr, verŝajne plej libera monitora sistemo el la disponeblaj, ĉar eĉ por uzi alian senpagan malfermfontan sistemon kiel Zabbix aŭ Nagios, oni devas asigni rimedojn (servilon) al ĝi, kaj ĉi tio jam estas mono. Krome, iom da servila prizorgado ankoraŭ necesas. Kun okerr, ĉi tiu parto povas esti forigita. Aŭ vi ne devas forigi ĝin kaj uzi vian propran servilon, depende de tio, kion vi plej ŝatas.

API kaj integriĝo en proprietan programaron

Simpla kaj malferma arkitekturo. okerr havas sufiĉe simplan API, kun kiu estas facile labori. Ĉu vi bezonas krei 1000 indikilojn? Unu ŝelo-skripto de 3-4 linioj faros tion. Ĉu vi bezonas reagordi 1000 indikilojn? Ĝi ankaŭ estas tre facila. Ekzemple, ni volas duoble kontroli ĉiujn niajn HTTPS-atestojn de rusa sensilo:

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

Vi povas ĝisdatigi la indikilon uzante nian klientmodulon, eĉ sen ĝi, nur per buklo.

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

Vi povas ĝisdatigi indikilojn rekte de via programo. Ekzemple, sendado de korbatsignaloj por ke okerr sciu ke ĝi funkcias kaj vekas alarmon se ĝi kraŝas aŭ frostas. Cetere, okerr-komponentoj faras ĝuste tion - okerr kontrolas sin, kaj problemoj en preskaŭ ajna modulo estos detektitaj kaj generos alarmon pri la problemo. (Kaj en kazo de ĉi tio "preskaŭ" - ili estas kruckontrolitaj de alia servilo)

Jen la kodo (simpligita) en nia telegrambot:

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

Estas biblioteko por ĝisdatigi indikilojn de Python-programoj okerrupdate, por iuj aliaj lingvoj ne ekzistas bibliotekoj, sed vi povas aŭ voki la okerrupdate-skripton aŭ fari HTTP-peton al la okerr-servilo.

Kiel okerr helpas nin

Okerr ŝanĝis niajn vivojn. Fakte. Eble alia monitora sistemo povus fari la samon, sed labori kun okerr estas facila kaj simpla por ni kaj ĝi havas ĉiujn funkciojn, kiujn ni bezonis (ni aldonis tion, kion ĝi ne havis). Cetere, se mankas iuj funkcioj, demandu kaj mi aldonos ilin (mi ne promesas, sed mi volas, ke okerr estu la plej bona monitora sistemo por malgrandaj-mezaj projektoj). Aŭ pli bone, aldonu ĝin mem - ĝi estas facila.

Ni sukcesis vivi laŭ la principo "lerni pri ĉiuj problemoj de la kerra." Se subite okazas problemo pri kiu ni ne lernis de okerr, ni aldonas ĉekon al okerr. (ĉi-kaze, per "ni" mi celas nin kiel uzantoj de la sistemo, ne kunprogramistoj). Komence tio estis ofta, sed nun ĝi fariĝis tre malofta.

Monitorado

Per okerr ni kontrolas la protokolojn sur ĉiuj serviloj. Kompreneble, estas neeble pripense legi ĉiun linion de la ŝtipo per viaj okuloj, sed simple monitori la kreskorapidecon jam donas multon. Per ĉi tio, ni malkovris spam-mesaĝon kaj krudfortajn pasvortojn serĉojn, kaj kiam iuj el la aplikaĵoj "freneziĝas", io ne funkcias por ili kaj ili ripetas ĝin denove kaj denove (ĉiufoje aldonante kelkajn liniojn al la protokolo. ).

SSL-atestiloj. Preskaŭ tuj post lanĉo Lasu Kriptigi nia kliento komencis provizi senpagajn SSL-atestilojn al siaj klientoj (ĉirkaŭ mil el ili). Kaj ĝi montriĝis nur infero por administrado! La fakto estas, ke retejoj estas "vivaj", klientoj periode petas ilin fari ion, programistoj faras ĝin. Ili povas tute libere translokigi la retejon al alia DocumentRoot, ekzemple. Aŭ aldonu senkondiĉan Reskribon al la agordo de virtualhost. Kompreneble, post ĉi tio, la aŭtomata renovigo de atestiloj malfunkcias. Nun ni havas ĉiujn SSL-gastigojn aldonitajn al okerr aŭtomate per alia el niaj utilaj iloj de la pako a2konf. Ni nur lanĉu a2okerr.py — kaj se pluraj novaj retejoj aperas sur la servilo, ili aŭtomate aperos en okerr. Se subite ial la atestilo ne estas renovigita, tri semajnojn antaŭ ol la atestilo eksvalidiĝos, ni scias, kaj ni ekscios kial ĝi ne estas ĝisdatigita, tia hundo. a2certbot.py el la sama pako - ĝi multe helpas pri tio (ĝi tuj kontrolas la plej verŝajnajn problemojn - kaj skribas bone tion, kio estis kontrolita, kaj kie plej verŝajne estas problemo).

Ni kontrolas la limdaton de ĉiuj niaj domajnoj. Kaj ĉiuj niaj poŝtserviloj kiuj sendas poŝton ankaŭ estas kontrolitaj kontraŭ 50+ malsamaj nigraj listoj. (Kaj foje ili falas en ilin). Cetere, ĉu vi sciis, ke Guglaj poŝtserviloj ankaŭ estas nigralistigitaj? Nur por memtestado, ni aldonis mail-wr1-f54.google.com al la monitoritaj serviloj, kaj ĝi ankoraŭ estas en la nigra listo de SORBS! (Ĉi tio temas pri la valoro de "kontraŭ-spamantoj")

Sekurkopioj - mi jam skribis supre, kiel facile estas kontroli ilin per okerr. Sed ni kontrolas kaj la plej novajn sekurkopiojn sur nia servilo kaj (uzante apartan ilon, kiu uzas okerr) la sekurkopiojn, kiujn ni alŝutas al Amazon Glacier. Kaj, jes, problemoj okazas de tempo al tempo. Ne mirinde, ke ili rigardis.

Ni uzas la indikilon de eskalado. Ĝi montras ĉu iu problemo ne estas riparita dum longa tempo. Kaj mi mem, kiam mi solvas iujn problemojn, foje mi povas forgesi pri ili. Eskalado estas bona memorigilo, eĉ se vi kontrolas vin mem.

Ĝenerale, mi kredas, ke la kvalito de nia laboro pliiĝis je ordo de grandeco. Preskaŭ ne estas malfunkcio (aŭ la kliento ne havas tempon por rimarki ĝin. Nur ŝŝ!), dum la kvanto de laboro fariĝis pli malgranda kaj la laborkondiĉoj fariĝis pli trankvilaj. Ni transiris de urĝa laboro kun flikado de truoj per bendo al trankvila kaj mezurita laboro, kiam multaj problemoj estas antaŭviditaj kaj estas tempo por malhelpi ilin. Eĉ problemoj, kiuj okazis, ankaŭ fariĝis pli facile ripareblaj: unue, ni ekscias pri ili antaŭ ol klientoj panikiĝas, kaj due, ofte okazas, ke la problemo rilatas al lastatempa laboro (dum mi faris unu aferon, mi rompis alian) - do estas varme Estas pli facile por spuroj trakti ĝin.

Sed estis alia kazo...

Ĉu vi scias, ke en la populara Debian 9 (Stretch) tia populara pakaĵo kiel phpmyadmin ankoraŭ estas (dum multaj monatoj!) en vundebla stato? (CVE-2019-6798). Kiam la vundebleco aperis, ni rapide kovris ĝin en malsamaj manieroj. Sed mi starigis monitoradon de la paĝo pri sekureca spurilo en okerr por scii kiam aperos "bela" solvo (per la SHA1-sumo de la enhavo). La indikilo svingis min plurfoje, la paĝo ŝanĝiĝis, sed kiel vi povas vidi, ĝi ankoraŭ (ekde januaro 2019!) ne indikas, ke la problemo estas solvita. Eble, cetere, iu scias, kio estas la problemo, ke tia grava pakaĵo ankoraŭ estas vundebla dum pli ol jaro?

Alian fojon en simila situacio: post vundebleco en SSH, necesis ĝisdatigi ĉiujn servilojn. Kaj kiam vi fiksas taskon, vi devas kontroli ekzekuton. (Subuloj emas miskompreni, forgesi, konfuziĝi kaj fari erarojn). Sekve, unue ni aldonis SSH-versionkontrolon al okerr sur ĉiuj serviloj, kaj per okerr ni certigis, ke ĝisdatigoj estas lanĉitaj sur ĉiuj serviloj. (Oportuna! Mi elektis ĉi tiun tipon de indikilo, kaj vi povas tuj vidi kiu servilo havas kiun version). Kiam ni estis certaj, ke la tasko estis kompletigita en ĉiuj serviloj, ni forigis la indikilojn.

Kelkajn fojojn estis situacio kie certa problemo ekestas, kaj poste foriras memstare. (verŝajne konata al ĉiuj?). Kiam vi rimarkas, kiam vi kontrolas—kaj estas nenio por kontroli—ĉio jam funkcias bone. Sed poste ĝi denove rompiĝas. Ni okazis tion, ekzemple, kun produktoj, kiujn ni alŝutis al Amazon Marketplace (MWS). En iu momento, la ŝarĝita inventaro estis malĝusta (malĝustaj kvantoj de varoj kaj malĝustaj prezoj). Ni eltrovis ĝin. Sed por eltrovi ĝin, estis grave ekscii pri la problemo tuj. Bedaŭrinde, MWS, kiel ĉiuj Amazon-servoj, estas iom malrapida, do ĉiam estis malfruo, sed tamen, ni povis almenaŭ proksimume kompreni la ligon inter la problemo kaj la skriptoj kiuj kaŭzas ĝin (ni faris kontrolon, algluiĝis). ĝin al la okerr, kaj kontrolis ĝin tuj ricevante alarmon).

Interesa kazo estis ĵus aldonita al la kolekto de granda kaj multekosta eŭropa gastiganto, kiun nia kliento uzas. Subite, ĈIUJ niaj serviloj malaperis de la radaro! Unue, la kliento mem (pli rapide ol okerra!) rimarkis, ke la retejo, kun kiu li laboris, ne malfermiĝas kaj faris bileton pri ĝi. Sed ne nur unu retejo falis, sed ĉiuj! (Nataŝa, ni faligis ĉion!). Ĉi tie Okerr komencis sendi longajn piedvolvaĵojn kun ĉiuj indikiloj, kiuj lumigis por li. Paniko, paniko, ni kuras ronde (kion alian ni povas fari?). Tiam ĉio leviĝis. Montriĝas, ke estis rutina prizorgado en la datumcentro (unufoje ĉiun multajn jarojn) kaj, kompreneble, ni devus esti avertitaj. Sed ia problemo okazis al ili kaj ili ne avertis nin. Nu, pli da koratakoj, malpli da koratakoj. Sed post kiam ĉio estas restarigita, vi devas duoble kontroli ĉion! Mi ne povas imagi kiel mi farus ĝin per miaj manoj. Okerr provis ĉion en kelkaj minutoj. Montriĝis, ke la plej multaj el la serviloj estis simple provizore neatingeblaj, sed ili funkciis. Kelkaj estis troŝarĝitaj, sed ankaŭ stariĝis kiel ili devus. El ĉiuj perdoj, ni perdis du sekurkopiojn, kiuj laŭ la krono devus esti kreitaj kaj ŝarĝitaj dum ĉi tiu plena banano daŭris. Mi eĉ ne ĝenis krei ilin, nur tagon poste alvenis alarmoj, ke ĉio estas en ordo, sekurkopioj aperis. Mi tre ŝatas ĉi tiun ekzemplon ĉar okerr montriĝis tre utila en situacio, pri kiu ni eĉ ne pensis antaŭe, sed tio estas la celo de monitorado - rezisti la neantaŭvideblan.

Por Okerr-sensiloj, ni uzas la plej malmultekostan ebla gastigado (kie kvalito kaj fidindeco ne gravas, ili asekuras unu la alian). Do, ni lastatempe trovis tre bonan gastigadon kaj super malmultekostan, la komparnormoj estas mirindaj. Sed... foje rezultas, ke elirantaj konektoj de la virtuala maŝino estas faritaj de alia (najbara) IP. Mirakloj. Client_ip-modulo kun https://diagnostic.opendns.com/myip ricevas la malĝustan IP. Kaj de la servilaj protokoloj de la indikilo estas klare, ke la ĝisdatigo ankaŭ venis de ĉi tiu najbara IP. Ni traktu la subtenon nun. Estas bone, ke ni rimarkis tion en paca tempo. Sed, ekzemple, ofte okazas, ke aliro estas registrita laŭ la IP-blanka listo - kaj se la servilo kelkfoje tiel palpebrumas dum mallonga tempo - vi povas provi kapti tiun problemon dum tre longa tempo.

Nu, ankoraŭ unu afero - ĉar ni parolas pri VPS-gastigado - ni ĉiam uzas malmultekostajn (hetzner, ovh, scaleway). Mi tre ŝatas ĝin kaj laŭ komparnormoj kaj stabileco. Ni ankaŭ uzas la multe pli multekostan Amazon EC2 por aliaj projektoj. Do, danke al okerr, ni havas nian propran informitan opinion. Ili ambaŭ falas. Kaj mi ne dirus, ke dum la longa periodo de niaj observoj, malmultekostaj gastigantoj kiel hetzner montriĝis rimarkeble malpli stabilaj ol EC2. Tial, se vi ne estas ligita al aliaj Amazon-funkcioj, kial pagi pli? 🙂

Kio sekvas?

Se en ĉi tiu etapo mi ankoraŭ ne fortimigis vin de Okerr, do provu ĝin! Vi povas iri rekte al ĉi tiu ligilo okerr-demo-konto (Alklaku nun!) Sed memoru, ke ekzistas nur unu demo-konto por ĉiuj, do se vi faras ion, iu alia en la sama konto povas malhelpi vin samtempe. Aŭ (pli bone) registriĝu per la ligilo al offsite okerr - ĉio estas simpla, sen SMS. Se vi ne ŝatas uzi vian veran retpoŝton, vi povas uzi unu-uzeblan, kiel retpoŝtilon (mi rekomendas getnada.com). Tiaj kontoj povas esti forigitaj kun la tempo, sed ili estos bone por testado.

Post registriĝo, oni petos vin trejni (fari plurajn ne tre malfacilajn trejnajn taskojn). La komencaj limoj estas tre malgrandaj, sed por trejnado aŭ unu servilo ili sufiĉas. Post kompletigi la trejnadon, la limoj (ekzemple, la maksimuma nombro da indikiloj) estos pliigitaj.

El la dokumentado - antaŭ ĉio WIKI ĉe la servilo kaj ĉe la kliento (okerrupdate vikio). Sed se io estas neklara, skribu al subteno (ĉe) okerr.com aŭ lasu bileton - ni provos solvi ĉion rapide.

Se vi uzas ĝin serioze kaj ĉi tiuj pliigitaj limoj ne sufiĉas, skribu al subteno kaj ni pliigos ĝin (senpage).

Ĉu vi ŝatus instali la servilon okerr sur via servilo? Jen okerr-dev-deponejo. Ni rekomendas instali sur pura virtuala maŝino, tiam vi povas simple fari ĝin per instala skripto. Sur via virtuala maŝino - sen limigoj :-). Nu, denove, se io okazos, ni ĉiam provos helpi.

Ni volas, ke ĉi tiu projekto ekflugu, por ke la mondo fariĝu pli fidinda danke al ni. Danke al liberaj programoj kaj servoj, la mondo pli amikiĝis kaj pli dinamike disvolviĝas. Fontoj povas esti konservitaj en senpaga github, por poŝto vi povas uzi senpagan gmail. Ni uzas senpage freŝaj verkoj por subteno. Por io el ĉi tio, vi ne bezonas pagi por serviloj, vi ne bezonas elŝuti kaj agordi, kaj vi ne bezonas solvi diversajn funkciajn problemojn. Ĉiu nova projekto, ĉiu teamo tuj havas poŝton, deponejojn kaj CRM. Kaj ĉio ĉi estas tre altkvalita kaj senpaga kaj tuj. Ni volas, ke ĝi estu la sama por monitorado - malgrandaj kompanioj kaj projektoj povus uzi okerr senpage kaj eĉ en la etapo de naskiĝo kaj kresko havas la fidindecon de plenkreskaj seriozaj projektoj.

fonto: www.habr.com

Superrigardo de la hibrida monitoradsistemo Okerr