For to år siden lavede jeg allerede et indlæg Simpel failover til en hjemmeside про okerr. Nu er der lidt udvikling af projektet, og jeg har også publiceret okerr server side kildekode under åben licens, derfor besluttede jeg at skrive denne korte anmeldelse på Habr.

[ fuld størrelse ]

For hvem det måtte have interesse

Dette kan være interessant for dig, hvis du arbejder i et lille team eller alene. Du har ikke overvågning, og du er ikke sikker på, om du virkelig har brug for det. Enten prøvede du en populær seriøs overvågning "for de store drenge", men det "tog ikke fart" for dig, eller også fungerer det i en næsten standardkonfiguration og ændrede ikke dit liv meget. Og også - hvis du bestemt ikke planlægger at tildele en hel medarbejder (eller endda en afdeling) til at overvåge overvågningsdashboardet mindst et par timer om dagen eller konfigurere det.

Hvorfor okerr er usædvanligt

Dernæst vil jeg vise interessante funktioner ved okerra, der adskiller den fra nogle andre overvågningssystemer.

Okerr er en hybrid overvågning

Under intern overvågning kører en "agent" på de overvågede maskiner, som overfører data til overvågningsserveren (f.eks. ledig diskplads). Når den er ekstern, udfører serveren kontrol over netværket (f.eks. ping eller websteds tilgængelighed). Hver tilgang har sine begrænsninger. Okerr bruger begge muligheder. Tjek inde i serverne udføres af en meget let (30Kb) agent eller dine egne scripts og applikationer, og netværkstjek udføres gennem okerr-sensorer i forskellige lande.

okerr er ikke kun software, men også en service

Serverdelen af enhver overvågning er stor og kompleks, den er svær at installere og konfigurere, og den kræver ressourcer. Med okerr kan du installere din egen overvågningsserver (den er gratis og opensource), eller du kan blot bruge klientdelen og bruge vores servers service. Også gratis.

Hvis overvågning giver dig mulighed for at kompensere og dække over den manglende pålidelighed i servere og applikationer, så opstår et filosofisk spørgsmål - hvem er vagten? Hvordan vil overvågning fortælle os om et problem, hvis det selv "døde" af en eller anden grund, separat eller sammen med dine andre ressourcer (f.eks. faldt kanalen til datacentret)? Når du bruger den eksterne tjeneste okerr - dette problem er løst - vil du modtage en advarsel selvom hele datacenteret med dine servere er uden strøm eller er angrebet af zombier.

Selvfølgelig er der en risiko for, at selve okerr-serveren ikke er tilgængelig, dette er sandt (som du ved, opnås 90% af pålideligheden altid enkelt og "gratis", 99% med et minimum af indsats, og hver efterfølgende ni er eksponentielt sværere). Men for det første er chancerne for at dette sker mindre, og for det andet kan problemet kun forblive ubemærket, hvis det falder sammen med problemer på vores servere. Hvis vi har 99.9% pålidelighed, og du har 99.9% (ikke for høje tal), så er chancen for en uopdaget fejl 0.1% af 0.1% = 0.0001%. At tilføje tre niere til din pålidelighed næsten uden anstrengelse og uden omkostninger er meget godt!

En anden fordel ved overvågning som en service er, at en hostingudbyder eller et webstudie kan installere en okerr-server og give adgang til klienter som en betalt eller gratis ekstra service. Dine konkurrenter har bare hosting og hjemmesider, men du har pålidelig hosting med overvågning.

Okerr handler om indikatorer

Indikatoren er en "pære". Den har to hovedtilstande - grøn (OK) eller rød (ERR). Projektet indeholder mange grupperede (for eksempel efter server) indikatorer. På projektets hovedside ser du med det samme, at enten er alt grønt (og du kan lukke det), eller noget lyser rødt og skal rettes. Ved overgang mellem disse tilstande sendes en advarsel. En gang om dagen, mens du sætter det op, sendes en oversigt over projektet.

Hver okerr-indikator har indbyggede betingelser, hvorved den ændrer tilstand (i Zabbix kaldes dette en trigger). For eksempel bør belastningsgennemsnittet ikke være mere end 2 (selvfølgelig kan dette konfigureres). Og for hver intern kontrol (indlæsningsgennemsnit, diskfri, ...) er der en vagthund. Hvis vi af en eller anden grund ikke modtager en vellykket bekræftelse på det aftalte tidspunkt, logges en fejl, og der sendes en advarsel.

Vores sædvanlige arbejdsmønster er at tjekke e-mails om morgenen og se oversigten blandt andre breve (vi planlægger det ved arbejdets start). Hvis alt er ok i det, gør vi andre vigtige ting (men for at være sikker kan vi hurtigt se på okerra-dashboardet og sikre os, at alt er grønt i dette øjeblik). Hvis der kommer en alarm, reagerer vi.

Det er selvfølgelig muligt blot at beholde "informations"-indikatorer (for at se billedet af netværket fra overvågning), men alt er gjort for enkelt, nemt og hurtigt at skabe indikatorer specifikt til automatisk overvågning og afsendelse af alarmer.

Formålet med, du opsætter okerr er i alarmer, så du kan oprette en indikator på et minut, den kunne "sove" i et år, bare acceptere opdateringer, og når et år efter noget går i stykker, lyser den og sender en advarsel. Det minut, du engang brugte på at oprette en indikator, gav pote; du lærte om problemet med det samme, før nogen anden. Det er muligt, at de har rettet det, før nogen lagde mærke til det. Noget, der hæves hurtigt, anses ikke for at være faldet!

Безопасность

Det ville være en skam, hvis du sætter overvågning op for at øge pålideligheden, men som et resultat bliver du angrebet over netværket gennem det, og der er en del netværkssårbarheder i forskellige overvågningsværktøjer (Zabbix, Nagios).

Agent (okerrmod fra pakken okerrupdate) der kører på systemet er ikke en netværksserver, men en klient. Derfor er der ingen yderligere åbne porte på den overvågede server, klienten arbejder nemt bag en firewall eller NAT og er meget svær (jeg vil sige "umulig") at hacke over netværket, da den i princippet ikke lytter til netværket stikkontakt.

Fuld overvågningsdækning

Nu er vores regel, at vi lærer om alle tekniske problemer fra okerr. Hvis reglen pludselig overtrædes (okerr advarede ikke om dens forestående forekomst (hvis dette er muligt) eller at det allerede er sket) - tilføjer vi checks til okerr.

Ekstern kontrol

Et ganske typisk sæt:

ping
http-status
kontrol af gyldigheden og friskheden af SSL-certifikatet (vil advare, hvis det er ved at udløbe)
åben TCP-port og banner på den
http grep (siden [må ikke] indeholde bestemt tekst)
sha1 hash for at fange sideændringer.
DNS (DNS-post skal have en bestemt værdi)
WHOIS (vil advare, hvis domænet er ved at gå dårligt)
Antispam DNSBL (værtstjek mod 50+ antispam-sortlister på én gang)

Interne kontroller

Også et ret standard sæt (men nemt at udvide).

df (fri diskplads)
belastning gennemsnit
opentcp (åbne TCP-lyttestik - giver besked, hvis noget startede eller gik ned)
oppetid - kun oppetid på serveren. Giver besked, hvis det har ændret sig (dvs. serveren er overbelastet)
klient_ip
dirsize - vi bruger det til at spore, hvornår vores virtuelle maskine rootfs overstiger den tilladte størrelse, uden at indføre strenge begrænsninger, og størrelsen af brugerens hjemmemapper
tomme og ikke tomme - overvåg filer, der skal være tomme (eller ikke tomme). For eksempel skulle fejlloggen på selve okerr-serveren være tom, og hvis der overhovedet er en linje i den, vil jeg modtage en notifikation og tjekke den. Men mail.log på mailserveren bør IKKE være tom (N minutter efter rotation). Og nogle gange var det tomt for os efter en systemopdatering, når logrotate ikke kunne genstarte rsyslog korrekt.
linecount - antal linjer i filen (som wc -l). Vi bruger det som en blødere erstatning for tomme, når fejlloggen stadig kan vokse, men kun langsomt (f.eks. rammer Googlebot nogle lukkede sider). Der er en grænse på 2 linjer på 20 minutter. Hvis den er højere, vil der være en alarm

Interessante interne kontroller

Hvis du har læst "diagonalt" indtil dette tidspunkt, vil det nu være mere interessant at læse mere omhyggeligt.

sikkerhedskopier

Overvåger sikkerhedskopier i mappen. Vores backup-filer har navne som "ServerName-20200530.tar.gz". For hver server i okerr oprettes indikatoren ServerName-DATE.tar.gz (den faktiske dato ændres til linjen "DATE"). Selve tilstedeværelsen af en ny sikkerhedskopi og dens størrelse overvåges også (f.eks. kan den ikke være mindre end 90 % af den tidligere sikkerhedskopi).

Hvad skal der gøres for at en ny sikkerhedskopi begynder at blive sporet, efter at vi er begyndt at oprette den og lægge den i denne mappe? Ikke noget! Dette er en meget praktisk tilgang, når du skal gøre "ingenting", fordi:

At gøre "intet" er ret hurtigt, det sparer tid
Det er svært at glemme at gøre "ingenting"
Det er svært at gøre "intet" forkert med en fejl. Intet er den mest pålidelige metode

Hvis der pludselig ikke længere vises friske backupfiler, vil der være en advarsel. Hvis du for eksempel har deaktiveret en af serverne, og der ikke skulle være flere sikkerhedskopier, skal du slette indikatoren (via webgrænsefladen eller fra shellen via API'en).

maxfilesz

Holder styr på størrelsen af de største filer (typisk: /var/log/*). Dette giver dig mulighed for at fange uforudsigelige problemer, for eksempel brute force-adgangskoder eller afsendelse af spam gennem serveren.

runstatus/runline

Disse er to vigtige proxy-moduler til at køre andre programmer på serveren. Runstatus rapporterer programafslutningskoden til indikatoren. For eksempel, okerr (kræver) ikke et modul for at kontrollere, at systemd-tjenester kører. Dette gøres via runstatus (se nedenfor). Runline - rapporterer til serveren den linje, som programmet producerer. For eksempel, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" i Runline-konfigurationen på vores server opretter en indikator servernavn:temp med processortemperaturen.

sql

Udfører en numerisk forespørgsel til MySQL og rapporterer resultatet til indikatoren. I et simpelt tilfælde kan du for eksempel gøre "SELECT 1" - dette vil kontrollere, at DBMS som helhed fungerer.

Men en meget mere interessant applikation er for eksempel at spore antallet af ordrer i en netbutik. Hvis du ved, at du har 100 eller flere ordrer i timen, kan du sætte minimumsgrænsen til 100 eller 80. Hvis dit salg pludselig falder, vil du modtage en advarsel, og du kan finde ud af det.

Bemærk, at det er ligegyldigt af hvilken uforudsigelig årsag dette skete:

Serveren er ganske enkelt utilgængelig (strømløs eller uden netværk), og advarslen kom fra det faktum, at indikatoren var "rådden".
Serveren er overbelastet med noget, den virker langsomt eller pakker går tabt, det er ubelejligt for brugerne, og de forlader uden at foretage køb
Serveren er inkluderet i spamlisterne og mail fra den accepteres ikke, brugere kan ikke registrere sig
Annoncekampagnebudgettet er løbet op, bannerne snurrer ikke.

Der kan være en række årsager, og dem alle kan ikke forudses på forhånd, og det er teknisk vanskeligt at spore. Men du kan bekvemt overvåge den endelige parameter (ordrer) og afgøre ud fra dem, at situationen er mistænkelig og fortjener at blive behandlet.

Logiske indikatorer

Tillader brug af boolske udtryk (Python-syntaks) via et modul validere(artikel om Habré). Data fra projektet og dets indikatorer er tilgængelige til udtryk. For eksempel, i kapitlet om SQL-tjek ovenfor, har du måske bemærket et svagt punkt - om dagen kan vi have 100 salg i timen, men om natten - 20, og det er almindeligt, ikke et problem. Hvad skal jeg gøre? Indikatoren vil konstant gå i panik om natten.

Du kan oprette to indikatorer, dag og nat. Gør begge "stille" (de sender ikke advarsler). Og lav en logisk indikator, der kræver, at dagindikatoren er OK før 20:00, og efter 20:00 er det nok til, at natindikatoren er OK.

Et andet eksempel på brug af en logisk indikator er eskalering. For eksempel afmelder en projektleder sig fra alarmer (han har ikke behov for at gøre dette, administratorer bør reagere på normale problemer), men abonnerer på en logisk indikator, der bliver rød, hvis en indikator i projektet ikke bliver rettet inden for den tildelte tid.

Det er også muligt at indstille den tilladte tid for arbejde, for eksempel fra 3 til 5 om morgenen. Vi er ligeglade med, om servere og websteder går ned i løbet af denne tid. Men klokken 5 skal de arbejde. Hvis de ikke virker på noget andet tidspunkt - vær opmærksom. Den logiske indikator giver dig også mulighed for at tage hensyn til serverredundans. Hvis du har 00 webservere, kan administratorer til enhver tid slukke for 5-1 servere. Men hvis der er mindre end 2 ud af 3 servere i kamp, vil der være en alarm.

Eksemplerne ovenfor er ikke okere funktioner, ikke nogle funktioner, der skal aktiveres og konfigureres. Okerra har ikke alle disse funktioner, men der er et logisk modul, der giver dig mulighed for at implementere denne funktionalitet (omtrent som i et programmeringssprog - hvis vi har aritmetiske operatorer, har vi ikke brug for en speciel funktion til at beregne 20% moms fra sproget, kan du altid gøre det selv, så det passer til dine behov).

Logic Indicator er nok et af de få relativt komplekse emner i okerr, men den gode nyhed er, at du ikke behøver at mestre det, før du skal. Men samtidig udvider de mulighederne kraftigt, samtidig med at de holder selve systemet ret simpelt.

Tilføjelse af dine egne checks

Jeg vil rigtig gerne formidle tanken om, at okerr ikke er et sæt af tusindvis af færdige checks til alle lejligheder, men tværtimod - først og fremmest - en simpel motor med en simpel mulighed for at lave dine egne checks. At oprette dine egne checks i okerr er ikke en opgave for hackere, systemudviklere eller i det mindste avancerede okerr-brugere, men en gennemførlig opgave for enhver administrator, der installerede Linux for første gang for en måned siden.

Kontrol af mindsteløn sker gennem modulet kørestatus:

Denne linje i konfigurationen kørestatus vil give dig besked, hvis /bin/true pludselig ikke starter eller returnerer noget andet end 0.

true_OK=/bin/true

Bare en streg - og her er vi allerede lidt udvidet funktionalitet okerr.

Selv en sådan kontrol har allerede sin værdi: Hvis din server pludselig går ned, vil den tilsvarende indikator på okerr-serveren ikke blive opdateret rettidigt, og efter at tiden er gået, vises en advarsel.

Denne kontrol vil give besked om, at apache2-serveren er gået ned (ja, man ved aldrig...):

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

Så hvis du taler et hvilket som helst programmeringssprog og i det mindste kan skrive shell-scripts, så kan du allerede tilføje dine egne checks.

Mere vanskeligt - du kan skrive (på ethvert sprog) dit eget modul til okerrmod. I det enkleste tilfælde ser det sådan ud:

#!/usr/bin/python3

print("STATUS: OK")

Er det ikke meget svært? Modulet skal selv foretage kontrollen og udsende resultaterne til STDOUT. Et mere komplekst modul giver for eksempel dette:

$ 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

Den opdaterer flere indikatorer på én gang (adskilt af en tom linje), opretter dem om nødvendigt, angiver verifikationsdetaljer og et tag, hvormed det er nemt at finde de nødvendige indikatorer i dashboardet.

Der er en Telegram-bot @OkerrBot. Du behøver ikke at fylde din telefon med separate applikationer (jeg kan ikke lide, at du til Pyaterochka har brug for en applikation med et kort, til Lenta en anden, til MTS en tredje, og så videre for alle, alle, alle). Et telegram er nok. Via telegram kan du straks modtage advarsler, kontrollere projektets status og give en kommando til at kontrollere alle problematiske indikatorer igen. Vi forlod teatret/flyet, havde ikke fingeren på pulsen i to timer, tændte for telefonen, trykkede på en knap i chatbotten og sikrede os, at alt var i orden.

Status sider

I dag er statussider nærmest et must have for enhver virksomhed, der har IT, en ansvarlig holdning til pålidelighed og som behandler sine kunder/brugere med respekt.

Forestil dig en situation - en bruger vil gøre noget, se information eller afgive en ordre, og noget virker ikke. Han ved ikke, hvad der foregår, på hvis side problemet er, og hvornår det vil blive løst. Måske har din virksomhed simpelthen en ikke-funktionel hjemmeside? Eller gik det i stykker for seks måneder siden, og det vil blive rettet om to år? Men du skal købe et køleskab nu, det ligger allerede i vognen... Og det er en helt anden sag, når en person ser, at der er noget galt med dig (det er i hvert fald tydeligt, at problemet ikke er på hans side), at problemet er blevet opdaget, at du allerede arbejder på det, og måske endda nedskrevet det omtrentlige tidspunkt for rettelse. Brugeren kan abonnere og modtage en e-mail-meddelelse, når problemet er løst, og han kan gøre, hvad han vil (købe et køleskab).

Problemer og nedetid sker for alle. Men brugere og partnere stoler mere på dem, der er mere gennemsigtige og ansvarlige i deres tilgang til dette.

her gennemgang af 10 andre projekter, der giver dig mulighed for at oprette statussider. Her er eksempler på, hvordan disse projektsider ser ud Python и Dropbox. okerr status side.

Failover

For ikke at gøre denne artikel endnu længere, vil jeg endnu en gang henvise til min tidligere artikel - Simpel failover til en hjemmeside . Hvis du kan lave en duplikatserver, vil du ved hjælp af failover stort set ikke have lang nedetid - så snart et problem opdages, vil brugerne automatisk blive omdirigeret til en fungerende backupserver. Og det forekommer mig, at dette er en meget interessant, lys funktion, som sjældent er tilgængelig nogen steder.

Lave systemkrav

Til okerr servere bruger vi maskiner med RAM fra 2Gb. Til netværkssensorer er selv 512Mb nok. Klientdelen er generelt næsten nul. (Plastikpose okerrupdate vejer 26 Kb, men kræver Python3 og standardbiblioteker). Klienten kører fra et cron-script, så den har nul vedvarende hukommelsesforbrug. Blandt de maskiner, vi overvågede, har vi sensorer (superbillig VPS med 512 Mb RAM) og en Raspberry Pi. Det er muligt selv uden klientdelen send opdateringer via curl! (se nedenunder)

Tager dette i betragtning - okerr, sandsynligvis mest gratis overvågningssystem fra de tilgængelige, for selv for at bruge et andet gratis open source-system som Zabbix eller Nagios, skal du allokere ressourcer (server) til det, og det er allerede penge. Derudover kræves der stadig noget servervedligeholdelse. Med okerr kan denne del fjernes. Eller du behøver ikke at fjerne den og bruge din egen server, alt efter hvad du bedst kan lide.

API og integration i proprietær software

Enkel og åben arkitektur. okerr har en ret simpel en API, som er nem at arbejde med. Har du brug for at oprette 1000 indikatorer? Et shell-script på 3-4 linjer vil gøre dette. Har du brug for at omkonfigurere 1000 indikatorer? Det er også meget nemt. For eksempel vil vi dobbelttjekke alle vores HTTPS-certifikater fra en russisk 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

Du kan opdatere indikatoren ved hjælp af vores klientmodul, selv uden den, blot via 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/

Du kan opdatere indikatorer direkte fra dit program. For eksempel at sende hjerteslagssignaler, så okerr ved, at den kører og slår alarm, hvis den styrter eller fryser. Okerr-komponenter gør i øvrigt netop det - okerr overvåger sig selv, og problemer i næsten ethvert modul vil blive opdaget og generere en advarsel om problemet. (Og i tilfælde af dette "næsten" - de krydstjekkes fra en anden server)

Her er koden (forenklet) i vores 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))

Der er et bibliotek til opdatering af indikatorer fra Python-programmer okerrupdate, for alle andre sprog er der ingen biblioteker, men du kan enten kalde okerrupdate-scriptet eller lave en HTTP-anmodning til okerr-serveren.

Hvordan okerr hjælper os

Okerr ændrede vores liv. Ja. Måske kunne et andet overvågningssystem gøre det samme, men at arbejde med okerr er nemt og enkelt for os, og det har alle de funktioner, vi havde brug for (vi tilføjede, hvad det ikke havde). Forresten, hvis der mangler nogle funktioner, så spørg, og jeg vil tilføje dem (jeg lover det ikke, men jeg vil have okerr til at være det bedste overvågningssystem til små og mellemstore projekter). Eller endnu bedre, tilføje det selv – det er nemt.

Vi formåede at leve efter princippet "lær om alle problemer fra kerraen." Hvis der pludselig opstår et problem, som vi ikke har lært om fra okerr, tilføjer vi en check til okerr. (i dette tilfælde mener jeg med "vi" os som brugere af systemet, ikke co-udviklere). Først var dette almindeligt, men nu er det blevet meget sjældent.

overvågning

Gennem okerr overvåger vi logstørrelserne på alle servere. Det er selvfølgelig umuligt at gennemlæse hver eneste linje i loggen med øjnene, men blot at overvåge vækstraten giver allerede en masse. Gennem dette opdagede vi spam-mailing og brute force-adgangskodesøgninger, og når nogle af applikationerne "går amok", fungerer noget ikke for dem, og de gentager det igen og igen (hver gang tilføjer et par linjer til loggen ).

SSL-certifikater. Næsten umiddelbart efter lanceringen Lader krypteres vores kunde begyndte at levere gratis SSL-certifikater til sine kunder (ca. tusind af dem). Og det viste sig bare at være et helvede for administrationen! Faktum er, at websteder er "live", klienter beder dem med jævne mellemrum om at gøre noget, programmører gør det. De kan f.eks. helt frit overføre siden til en anden DocumentRoot. Eller tilføj en ubetinget omskrivning til virtualhost-konfigurationen. Herefter bryder den automatiske fornyelse af certifikater naturligvis sammen. Nu har vi alle SSL-værter tilføjet til okerr automatisk gennem et andet af vores nyttige hjælpeprogrammer fra pakken a2conf. Lad os bare starte a2okerr.py — og hvis der dukker flere nye sider op på serveren, vil de automatisk dukke op i okerr. Hvis certifikatet pludselig af en eller anden grund ikke bliver fornyet, tre uger før certifikatet udløber, er vi ved, og vi vil finde ud af, hvorfor det ikke er opdateret, sådan en hund. a2certbot.py fra samme pakke - det hjælper meget på dette (det tjekker straks de mest sandsynlige problemer - og skriver godt, hvad der blev tjekket, og hvor der højst sandsynligt er et problem).

Vi overvåger udløbsdatoen for alle vores domæner. Og alle vores mailservere, der sender mail, bliver også tjekket mod 50+ forskellige sortlister. (Og nogle gange falder de ind i dem). Vidste du forresten, at Googles mailservere også er sortlistet? Blot til selvtestning føjede vi mail-wr1-f54.google.com til de overvågede servere, og det er stadig på SORBS-sortlisten! (Dette handler om værdien af "anti-spammere")

Sikkerhedskopier - jeg har allerede skrevet ovenfor, hvor nemt det er at overvåge dem med okerr. Men vi overvåger både de seneste sikkerhedskopier på vores server og (ved hjælp af et separat hjælpeprogram, der bruger okerr) de sikkerhedskopier, som vi uploader til Amazon Glacier. Og ja, problemer opstår fra tid til anden. Ikke underligt, at de så på.

Vi bruger eskaleringsindikatoren. Det viser, om et eller andet problem ikke er blevet løst i lang tid. Og jeg selv, når jeg løser nogle problemer, kan jeg nogle gange glemme dem. Eskalering er en god påmindelse, selvom du overvåger dig selv.

Samlet set mener jeg, at kvaliteten af vores arbejde er steget med en størrelsesorden. Der er næsten ingen nedetid (eller klienten har ikke tid til at mærke det. Bare shh!), mens arbejdsmængden er blevet mindre og arbejdsforholdene er blevet roligere. Vi er gået fra akut arbejde med lapning af huller med tape til roligt og afmålt arbejde, når mange problemer er forudsagt på forhånd, og der er tid til at forebygge dem. Selv problemer, der er sket, er også blevet nemmere at løse: For det første finder vi ud af dem, før kunderne går i panik, og for det andet sker det ofte, at problemet er relateret til nyligt arbejde (mens jeg lavede én ting, brød jeg en anden) - så det er varmt Det er nemmere for spor at håndtere det.

Men der var en anden sag...

Vidste du, at i den populære Debian 9 (Stretch) er en så populær pakke som phpmyadmin stadig (i mange måneder!) i sårbar status? (CVE-2019-6798). Da sårbarheden dukkede op, dækkede vi den hurtigt på forskellige måder. Men jeg satte overvågning af sikkerheds-tracker-siden op i okerr for at vide, hvornår en "smuk" løsning kommer ud (via SHA1-summen af indholdet). Indikatoren rykkede mig flere gange, siden ændrede sig, men som du kan se, tyder den stadig (siden januar 2019!) ikke på, at problemet er løst. Måske er der i øvrigt nogen, der ved, hvad problemet er, at en så vigtig pakke stadig er sårbar i mere end et år?

En anden gang i en lignende situation: efter en sårbarhed i SSH var det nødvendigt at opdatere alle servere. Og når du sætter en opgave, skal du kontrollere udførelsen. (Underordnede har en tendens til at misforstå, glemme, blive forvirrede og lave fejl). Derfor tilføjede vi først et SSH-versionstjek til okerr på alle servere, og gennem okerr sørgede vi for, at opdateringer blev rullet ud på alle servere. (Bekvemt! Jeg valgte denne type indikator, og du kan med det samme se, hvilken server der har hvilken version). Da vi var sikre på, at opgaven var fuldført på alle servere, fjernede vi indikatorerne.

Et par gange var der en situation, hvor et bestemt problem opstår, og derefter går over af sig selv. (sandsynligvis bekendt for alle?). Når du bemærker, når du tjekker - og der er intet at tjekke - fungerer alt allerede godt. Men så går det i stykker igen. Det skete for eksempel med produkter, som vi uploadede til Amazon Marketplace (MWS). På et tidspunkt var den indlæste beholdning forkert (forkerte mængder af varer og forkerte priser). Vi fandt ud af det. Men for at finde ud af det, var det vigtigt at finde ud af problemet med det samme. Desværre er MWS, ligesom alle Amazon-tjenester, lidt langsom, så der var altid en forsinkelse, men alligevel var vi i det mindste i stand til i det mindste nogenlunde at forstå forbindelsen mellem problemet og de scripts, der forårsagede det (vi gjorde en kontrol, fast det til okerren, og tjekkede det straks modtog en advarsel).

En interessant sag blev for nylig tilføjet samlingen af en stor og dyr europæisk hoster, som vores kunde bruger. Pludselig forsvandt ALLE vores servere fra radaren! Først bemærkede kunden selv (hurtigere end okerra!) at siden han arbejdede med ikke åbnede og lavede en billet om det. Men ikke kun et websted gik ned, men dem alle! (Natasha, vi droppede alt!). Her begyndte Okerr at sende lange fodindpakninger med alle de indikatorer, der lyste op for ham. Panik, panik, vi løber i cirkler (hvad kan vi ellers gøre?). Så steg alt. Det viser sig, at der var rutinemæssig vedligeholdelse i datacentret (en gang hvert mange år), og vi skulle selvfølgelig have været advaret. Men der skete et eller andet problem med dem, og de advarede os ikke. Nå, flere hjerteanfald, færre hjerteanfald. Men efter alt er gendannet, skal du dobbelttjekke alt! Jeg kan ikke forestille mig, hvordan jeg ville gøre det med mine hænder. Okerr testede alt på få minutter. Det viste sig, at de fleste af serverne simpelthen var midlertidigt utilgængelige, men de virkede. Nogle var overbelastede, men rejste sig også, som de skulle. Af alle tabene mistede vi to backups, som ifølge kronen skulle være oprettet og indlæst, mens denne fulde banan stod på. Jeg gad ikke engang oprette dem, bare en dag senere ankom advarsler om, at alt var OK, sikkerhedskopier var dukket op. Jeg kan virkelig godt lide dette eksempel, fordi okerr viste sig at være meget nyttig i en situation, som vi ikke engang havde tænkt over på forhånd, men det er formålet med overvågning - at modstå det uforudsigelige.

Til Okerr sensorer bruger vi den billigst mulige hosting (hvor kvalitet og pålidelighed ikke er vigtigt, forsikrer de hinanden). Så vi har for nylig fundet en meget god hosting og super billig, benchmarks er fantastiske. Men... nogle gange viser det sig, at udgående forbindelser fra den virtuelle maskine er lavet fra en anden (nabo) IP. Mirakler. Client_ip modul med https://diagnostic.opendns.com/myip får den forkerte IP. Og fra indikatorens serverlogfiler er det klart, at opdateringen også kom fra denne nabo-IP. Lad os håndtere støtten nu. Det er godt, at vi bemærkede det i fredstid. Men det sker for eksempel ofte, at adgangen registreres efter IP-hvidlisten - og hvis serveren nogle gange blinker sådan i kort tid - kan du forsøge at fange dette problem i meget lang tid.

Nå, en ting mere – da vi taler om VPS-hosting – bruger vi altid billige (hetzner, ovh, scaleway). Jeg kan virkelig godt lide det både med hensyn til benchmarks og stabilitet. Vi bruger også den meget dyrere Amazon EC2 til andre projekter. Så takket være okerr har vi vores egen informerede mening. De falder begge. Og jeg vil ikke sige, at i løbet af den lange periode af vores observationer viste billige hostings som hetzner sig at være mærkbart mindre stabile end EC2. Derfor, hvis du ikke er bundet til andre Amazon-funktioner, hvorfor betale mere? 🙂

Hvad er det næste?

Hvis jeg på dette tidspunkt ikke har skræmt dig væk fra Okerr endnu, så prøv det! Du kan gå direkte til dette link okerr demo konto (Klik nu!) Men husk på, at der kun er én demokonto til alle, så hvis du gør noget, kan en anden på samme konto forstyrre dig på samme tid. Eller (bedre) tilmeld dig via linket til offsite okerr - alt er enkelt, uden SMS. Hvis du ikke kan lide at bruge din rigtige e-mail, kan du bruge en engangs-e-mail, som mailinator (jeg anbefaler getnada.com). Sådanne konti kan blive slettet over tid, men de vil være fine til test.

Efter tilmelding vil du blive bedt om at gennemgå træning (udføre flere ikke særlig svære træningsopgaver). De indledende grænser er meget små, men til træning eller én server er de nok. Efter endt træning vil grænserne (for eksempel det maksimale antal indikatorer) blive øget.

Fra dokumentationen - først og fremmest WIKI på serversiden og på klienten (okerrupdate wiki). Men hvis noget er uklart, så skriv til support (at) okerr.com eller efterlad en billet - vi vil forsøge at løse alt hurtigt.

Hvis du bruger det seriøst, og disse øgede grænser ikke er nok, så skriv til support, så øger vi det (gratis).

Vil du installere okerr-serveren på din server? Her okerr-dev repository. Vi anbefaler at installere på en ren virtuel maskine, så kan du blot gøre det med et installationsscript. På din virtuelle maskine - ingen begrænsninger :-). Nå, igen, hvis der sker noget, vil vi altid forsøge at hjælpe.

Vi ønsker, at dette projekt tager fart, så verden bliver mere pålidelig takket være os. Takket være gratis software og tjenester er verden blevet venligere og udvikler sig mere dynamisk. Kilderne kan gemmes i den gratis github, og til mail kan du bruge den gratis gmail. Vi bruger gratis friskværker for støtte. For noget af dette behøver du ikke betale for servere, du behøver ikke at downloade og konfigurere, og du behøver ikke at løse forskellige driftsproblemer. Hvert nyt projekt, hvert team har straks mail, repositories og CRM. Og alt dette er af meget høj kvalitet og gratis og med det samme. Vi ønsker, at det skal være det samme for overvågning - små virksomheder og projekter kunne bruge okerr gratis, og selv på fødslen og vækststadiet have pålideligheden af seriøse voksne projekter.

Kilde: www.habr.com

Oversigt over Okerr hybrid overvågningssystem