För två år sedan gjorde jag redan ett inlägg Enkel failover för en webbplats про okerr. Nu sker en del utveckling av projektet, och jag publicerade också okerr serversidans källkod enligt öppen licens, det var därför jag bestämde mig för att skriva denna korta recension på Habr.

[ full storlek ]

För vem det kan vara av intresse

Detta kan vara av intresse för dig om du arbetar i ett litet team eller ensam. Du har ingen övervakning och du är inte säker på om du verkligen behöver det. Antingen provade du en populär seriös övervakning "för de stora pojkarna", men den "tog inte fart" för dig på något sätt, eller så fungerar den i en nästan standardkonfiguration och förändrade inte ditt liv mycket. Och även - om du definitivt inte planerar att tilldela en hel anställd (eller ens en avdelning) för att övervaka övervakningsinstrumentpanelen minst ett par timmar om dagen eller konfigurera den.

Varför okerr är ovanligt

Därefter kommer jag att visa intressanta egenskaper hos okerra som skiljer den från vissa andra övervakningssystem.

Okerr är en hybridövervakning

Under intern övervakning körs en "agent" på de övervakade maskinerna, som överför data till övervakningsservern (till exempel ledigt diskutrymme). När den är extern utför servern kontroller över nätverket (till exempel ping eller webbplatsens tillgänglighet). Varje tillvägagångssätt har sina begränsningar. Okerr använder båda alternativen. Kontroller inuti servrar utförs av en mycket lätt (30Kb) agent eller dina egna skript och applikationer, och nätverkskontroller utförs genom okerr-sensorer i olika länder.

okerr är inte bara programvara, utan också en tjänst

Serverdelen av all övervakning är stor och komplex, den är svår att installera och konfigurera, och den kräver resurser. Med okerr kan du installera din egen övervakningsserver (den är gratis och öppen källkod), eller så kan du helt enkelt bara använda klientdelen och använda vår servers tjänst. Också gratis.

Om övervakning gör att du kan kompensera och täcka över bristen på tillförlitlighet i servrar och applikationer, då uppstår en filosofisk fråga - vem är vakten? Hur kommer övervakning att berätta för oss om ett problem om det självt "dött" av någon anledning, separat eller tillsammans med dina andra resurser (till exempel kanalen till datacentret föll)? När du använder den externa tjänsten okerr - detta problem är löst - får du en varning även om hela datacentret med dina servrar är utan ström eller attackeras av zombies.

Naturligtvis finns det en risk att själva okerr-servern inte är tillgänglig, detta är sant (som ni vet, 90% av tillförlitligheten erhålls alltid enkelt och "gratis", 99% med ett minimum av ansträngning, och varje efterföljande nio är exponentiellt svårare). Men för det första är chansen att detta händer mindre, och för det andra kan problemet förbli obemärkt bara om det sammanfaller med problem på våra servrar. Om vi har 99.9 % tillförlitlighet och du har 99.9 % (inte för höga siffror), så är chansen för ett oupptäckt fel 0.1 % av 0.1 % = 0.0001 %. Att lägga till tre nior till din tillförlitlighet nästan utan ansträngning och utan kostnad är mycket bra!

En annan fördel med övervakning som tjänst är att en värdleverantör eller webbstudio kan installera en okerr-server och ge åtkomst till klienter som en betald eller gratis tilläggstjänst. Dina konkurrenter har bara hosting och webbplatser, men du har pålitlig hosting med övervakning.

Okerr handlar om indikatorer

Indikatorn är en "glödlampa". Den har två huvudlägen - grön (OK) eller röd (ERR). Projektet innehåller många grupperade (till exempel efter server) indikatorer. På projektets huvudsida ser du direkt att antingen är allt grönt (och du kan stänga det), eller så lyser något rött och behöver korrigeras. Vid övergång mellan dessa tillstånd skickas en varning. En gång om dagen medan du sätter upp det skickas en sammanfattning av projektet.

Varje okerr-indikator har inbyggda villkor genom vilka den ändrar tillstånd (i Zabbix kallas detta en trigger). Till exempel bör belastningsgenomsnittet inte vara mer än 2 (naturligtvis är detta konfigurerbart). Och för varje intern kontroll (belastningsgenomsnitt, diskfri, ...) finns det en vakthund. Om vi av någon anledning inte får en lyckad bekräftelse vid utsatt tid, loggas ett fel och en varning skickas.

Vårt vanliga arbetsmönster är att kolla e-postmeddelanden på morgonen och titta på sammanfattningen bland andra brev (vi schemalägger det i början av arbetet). Om allt är ok i den gör vi andra viktiga saker (men för säkerhets skull kan vi snabbt titta på okerra instrumentpanelen och se till att allt är grönt i detta ögonblick). Om en varning kommer in reagerar vi.

Naturligtvis är det möjligt att helt enkelt behålla "informations" indikatorer (för att se bilden av nätverket från övervakning), men allt görs för att enkelt, enkelt och snabbt skapa indikatorer specifikt för automatisk övervakning och skicka varningar.

Syftet med vilket du ställer in okerr är i varningar, så att du kan skapa en indikator på en minut, den skulle kunna "sova" i ett år, bara acceptera uppdateringar, och när något år senare går sönder tänds den och skickar en varning. Minuten du en gång spenderade på att skapa en indikator lönade sig; du lärde dig om problemet omedelbart, före någon annan. Det är möjligt att de fixade det innan någon märkte det. Något som höjs snabbt anses inte ha fallit!

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

Det skulle vara synd om du ställer in övervakning för att öka tillförlitligheten, men som ett resultat attackeras du över nätverket genom det, och det finns ganska många nätverkssårbarheter i olika övervakningsverktyg (Zabbix, Nagios).

Agent (okerrmod från paketet okerrupdate) som körs på systemet är inte en nätverksserver, utan en klient. Därför finns det inga ytterligare öppna portar på den övervakade servern, klienten fungerar enkelt bakom en brandvägg eller NAT och är mycket svår (jag skulle säga "omöjligt") att hacka över nätverket, eftersom den i princip inte lyssnar på nätverket uttag.

Full övervakningstäckning

Nu är vår regel att vi lär oss om alla tekniska problem från okerr. Om regeln plötsligt överträds (okerr varnade inte om dess förestående inträffande (om detta är möjligt) eller att det redan har inträffat) - lägger vi till checkar till okerr.

Externa kontroller

Ganska typiskt set:

ping
http-status
kontrollera giltigheten och färskheten av SSL-certifikatet (kommer att varna om det är på väg att löpa ut)
öppna TCP-porten och banner på den
http grep (sidan [får inte] innehålla viss text)
sha1 hash för att fånga sidändringar.
DNS (DNS-post måste ha ett specifikt värde)
WHOIS (kommer att varna om domänen är på väg att bli dålig)
Antispam DNSBL (värdkontroll mot 50+ antispamsvarta listor samtidigt)

Interna kontroller

Dessutom en ganska standarduppsättning (men lätt utbyggbar).

df (fritt diskutrymme)
belastningsmedelvärde
opentcp (öppna TCP-lyssningsuttag - meddelar om något startade eller kraschade)
upptid - bara upptid på servern. Kommer att meddela om det har ändrats (dvs. servern har överbelastad)
client_ip
dirsize - vi använder det för att spåra när vår virtuella maskins rootfs överskrider den tillåtna storleken, utan att införa strikta begränsningar, och storleken på användarhemkataloger
tomma och icke tomma - övervaka filer som ska vara tomma (eller inte tomma). Till exempel bör felloggen för själva okerr-servern vara tom, och om det till och med finns en rad i den kommer jag att få ett meddelande och kontrollera det. Men mail.log på mailservern ska INTE vara tom (N minuter efter rotation). Och ibland var det tomt för oss efter en systemuppdatering, när logrotate inte kunde starta om rsyslog korrekt.
linecount - antal rader i filen (som wc -l). Vi använder det som en mjukare ersättning för tomma, när felloggen fortfarande kan växa, men bara långsamt (till exempel Googlebot träffar några stängda sidor). Det finns en gräns på 2 rader på 20 minuter. Om den är högre kommer det att finnas en varning

Intressanta interna kontroller

Om du har läst "diagonalt" fram till denna punkt, kommer det nu att bli mer intressant att läsa mer noggrant.

säkerhetskopior

Övervakar säkerhetskopior i katalogen. Våra säkerhetskopior har namn som "ServerName-20200530.tar.gz". För varje server i okerr skapas indikatorn ServerName-DATE.tar.gz (det faktiska datumet ändras till raden "DATE"). Själva närvaron av en ny säkerhetskopia och dess storlek övervakas också (till exempel kan den inte vara mindre än 90 % av den tidigare säkerhetskopian).

Vad behöver göras för att en ny säkerhetskopia ska börja spåras efter att vi har börjat skapa den och lägga den i den här katalogen? Ingenting! Detta är ett mycket bekvämt tillvägagångssätt när du behöver göra "inget" eftersom:

Att göra "ingenting" går ganska snabbt, det sparar tid
Det är svårt att glömma att göra "ingenting"
Det är svårt att göra "inget" fel, med ett fel. Ingenting är den mest pålitliga metoden

Om nya säkerhetskopior plötsligt slutar visas kommer det att finnas en varning. Om du till exempel har inaktiverat en av servrarna, och det inte skulle finnas fler säkerhetskopior, måste du ta bort indikatorn (via webbgränssnittet eller från skalet via API).

maxfilesz

Håller reda på storleken på de största filerna (vanligtvis: /var/log/*). Detta gör att du kan fånga oförutsägbara problem, till exempel brute force-lösenord eller att skicka spam via servern.

körstatus/runline

Dessa är två viktiga proxymoduler för att köra andra program på servern. Runstatus rapporterar programavslutskoden till indikatorn. Till exempel, okerr (kräver) inte en modul för att kontrollera att systemd-tjänster körs. Detta görs via runstatus (se nedan). Runline - rapporterar till servern den linje som programmet producerar. Till exempel, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" i Runline-konfigurationen på vår server skapar en indikator servernamn:temp med processortemperaturen.

sql

Utför en numerisk fråga till MySQL och rapporterar resultatet till indikatorn. I ett enkelt fall kan du till exempel göra "SELECT 1" - detta kommer att kontrollera att DBMS som helhet fungerar.

Men en mycket intressantare applikation är till exempel att spåra antalet beställningar i en webbutik. Om du vet att du har 100 eller fler beställningar per timme kan du sätta minimigränsen till 100 eller 80. Om din försäljning plötsligt sjunker får du en varning och du kan räkna ut det.

Observera att det inte spelar någon roll av vilken oförutsägbar anledning detta hände:

Servern är helt enkelt otillgänglig (strömlös eller utan nätverk), och varningen kom från det faktum att indikatorn var "rutten".
Servern är överbelastad med något, den fungerar långsamt eller paket går förlorade, det är obekvämt för användarna och de lämnar utan att göra inköp
Servern ingår i skräppostlistorna och e-post från den accepteras inte, användare kan inte registrera sig
Annonskampanjens budget har tagit slut, banderollerna snurrar inte.

Det kan finnas hur många orsaker som helst, och alla kan inte förutses i förväg, och det är tekniskt svårt att spåra. Men du kan bekvämt övervaka den slutliga parametern (beställningar) och avgöra från dem att situationen är misstänkt och förtjänar att hanteras.

Logiska indikatorer

Tillåter användning av booleska uttryck (Python-syntax) via en modul validera(artikel om Habré). Data från projektet och dess indikatorer finns tillgängliga för uttryck. Till exempel, i kapitlet om SQL-kontroll ovan, kan du ha märkt en svag punkt - under dagen kan vi ha 100 försäljningar per timme, men på natten - 20, och det är vanligt, inte ett problem. Vad ska jag göra? Indikatorn kommer ständigt att få panik på natten.

Du kan skapa två indikatorer, dag och natt. Gör båda "tysta" (de kommer inte att skicka varningar). Och skapa en logisk indikator som kräver att dagindikatorn är OK före 20:00, och efter 20:00 räcker det för att nattindikatorn ska vara OK.

Ett annat exempel på att använda en logisk indikator är upptrappning. Till exempel, en projektledare avregistrerar sig från varningar (han har inget behov av att göra detta, administratörer ska svara på vanliga problem), men prenumererar på en logisk indikator som blir röd om någon indikator i projektet inte korrigeras inom den tilldelade tiden.

Det är också möjligt att ställa in den tillåtna tiden för arbete, till exempel från 3 till 5 på morgonen. Vi bryr oss inte om servrar och webbplatser kraschar under denna tid. Men klockan 5:00 måste de jobba. Om de inte fungerar någon annan gång – varna. Den logiska indikatorn låter dig också ta hänsyn till serverredundans. Om du har 5 webbservrar kan administratörer stänga av 1-2 servrar när som helst. Men om det finns färre än 3 av 5 servrar i strid kommer det att finnas en varning.

Exemplen ovan är inte okända funktioner, inte några funktioner som behöver aktiveras och konfigureras. Okerra har inte alla dessa funktioner, men det finns en logisk modul som låter dig implementera denna funktionalitet (ungefär som i ett programmeringsspråk - om vi har aritmetiska operatorer behöver vi inte en speciell funktion för att beräkna 20% moms från språket kan du alltid göra det själv så att det passar dina behov).

Logic Indicator är förmodligen ett av de få relativt komplexa ämnena i okerr, men den goda nyheten är att du inte behöver bemästra det förrän du behöver. Men samtidigt utökar de kapaciteten avsevärt, samtidigt som systemet i sig själv är ganska enkelt.

Lägger till dina egna checkar

Jag skulle verkligen vilja förmedla tanken att okerr inte är en uppsättning av tusentals färdiga checkar för alla tillfällen, utan tvärtom – först och främst – en enkel motor med en enkel möjlighet att skapa egna checkar. Att skapa dina egna checkar i okerr är inte en uppgift för hackare, systemutvecklare eller åtminstone avancerade okerr-användare, utan en genomförbar uppgift för alla administratörer som installerade Linux för första gången för en månad sedan.

Kontroller av minimilöner görs genom modulen körstatus:

Denna rad i konfigurationen körstatus kommer att meddela dig om /bin/true plötsligt inte startar eller returnerar något annat än 0.

true_OK=/bin/true

Bara en rad – och här är vi redan lite expanderat funktionalitet okerr.

Även en sådan kontroll har redan sitt värde: om din server plötsligt kraschar kommer motsvarande indikator på okerr-servern inte att uppdateras i tid, och efter att tiden har gått visas en varning.

Denna kontroll kommer att meddela att apache2-servern har kraschat (ja, man vet aldrig...):

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

Så om du talar något programmeringsspråk och åtminstone kan skriva skalskript, kan du redan lägga till dina egna kontroller.

Svårare - du kan skriva (på vilket språk som helst) din egen modul för okerrmod. I det enklaste fallet ser det ut så här:

#!/usr/bin/python3

print("STATUS: OK")

Är det inte väldigt svårt? Modulen måste göra kontrollen själv och mata ut resultaten till STDOUT. En mer komplex modul ger till exempel detta:

$ 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 uppdaterar flera indikatorer på en gång (avgränsade med en tom rad), skapar dem vid behov, indikerar verifieringsdetaljer och en tagg med vilken det är lätt att hitta de nödvändiga indikatorerna i instrumentpanelen.

Det finns en Telegram-bot @OkerrBot. Du behöver inte belamra din telefon med separata applikationer (jag gillar inte att för Pyaterochka behöver du en applikation med en karta, för Lenta en annan, för MTS en tredje, och så vidare för alla, alla, alla). Ett telegram räcker. Genom telegram kan du omedelbart ta emot varningar, kontrollera projektets status och ge ett kommando för att kontrollera alla problematiska indikatorer igen. Vi lämnade teatern/flygplanet, höll inte fingret på pulsen på två timmar, slog på telefonen, tryckte på en knapp i chatboten och såg till att allt var bra.

Statussidor

Nuförtiden är statussidor nästan ett måste för alla företag som har IT, en ansvarsfull inställning till pålitlighet och som behandlar sina kunder/användare med respekt.

Föreställ dig en situation - en användare vill göra något, se information eller göra en beställning, och något fungerar inte. Han vet inte vad som händer, på vems sida problemet ligger och när det kommer att lösas. Kanske har ditt företag helt enkelt en icke-fungerande webbplats? Eller gick det sönder för ett halvår sedan och det ska fixas om två år? Men du behöver köpa ett kylskåp nu, det ligger redan i varukorgen... Och det är en helt annan sak när en person ser att något är fel på dig (det är åtminstone tydligt att problemet inte är på hans sida), att problemet har upptäckts, att du redan arbetar med det, och kanske till och med skrev ner den ungefärliga tiden för korrigering. Användaren kan prenumerera och få ett e-postmeddelande när problemet är åtgärdat och han kan göra vad han vill (köpa ett kylskåp).

Problem och driftstopp händer alla. Men användare och partners litar mer på dem som är mer transparenta och ansvarsfulla i sin inställning till detta.

Här granskning av 10 andra projekt som låter dig skapa statussidor. Här är exempel på hur dessa projektsidor ser ut Python и dropbox. okerr statussida.

failover

För att inte göra den här artikeln ännu längre hänvisar jag än en gång till min tidigare artikel - Enkel failover för en webbplats . Om du kan skapa en dubblettserver och sedan använda failover kommer du i princip inte att ha en lång driftstopp - så snart ett problem upptäcks kommer användare automatiskt att omdirigeras till en fungerande backupserver. Och det verkar för mig att detta är en mycket intressant, ljus funktion som sällan är tillgänglig någonstans.

Låga systemkrav

För okerr-servrar använder vi maskiner med RAM från 2Gb. För nätverkssensorer räcker till och med 512Mb. Klientdelen är i allmänhet nästan noll. (Plastpåse okerrupdate väger 26 Kb, men kräver Python3 och standardbibliotek). Klienten körs från ett cron-skript, så den har noll ihållande minnesförbrukning. Bland maskinerna vi övervakade har vi sensorer (superbillig VPS med 512Mb RAM) och en Raspberry Pi. Det är möjligt även utan klientdelen skicka uppdateringar via curl! (se nedan)

Med hänsyn till detta - okej, förmodligen mest gratis övervakningssystem från de tillgängliga, för även för att använda ett annat gratis system med öppen källkod som Zabbix eller Nagios måste du allokera resurser (server) till det, och det här är redan pengar. Dessutom krävs fortfarande visst serverunderhåll. Med okerr kan denna del tas bort. Eller så behöver du inte ta bort den och använda din egen server, beroende på vad du gillar bäst.

API och integration i proprietär programvara

Enkel och öppen arkitektur. okerr har en ganska enkel sådan API, som är lätt att arbeta med. Behöver du skapa 1000 indikatorer? Ett skalskript på 3-4 rader kommer att göra detta. Behöver du konfigurera om 1000 indikatorer? Det är också väldigt enkelt. Till exempel vill vi dubbelkolla alla våra HTTPS-certifikat från en rysk 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 uppdatera indikatorn med vår klientmodul, även utan den, bara 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 uppdatera indikatorer direkt från ditt program. Till exempel skicka hjärtslagssignaler så att okerr vet att den är igång och larmar om den kraschar eller fryser. Förresten, okerr-komponenter gör just det - okerr övervakar sig själv, och problem i nästan alla moduler kommer att upptäckas och generera en varning om problemet. (Och i händelse av detta "nästan" - de krysskontrolleras från en annan server)

Här är koden (förenklad) i vår 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))

Det finns ett bibliotek för uppdatering av indikatorer från Python-program okerrupdate, för alla andra språk finns det inga bibliotek, men du kan antingen anropa okerrupdate-skriptet eller göra en HTTP-förfrågan till okerr-servern.

Hur okerr hjälper oss

Okerr förändrade våra liv. Verkligen. Kanske ett annat övervakningssystem skulle kunna göra detsamma, men att arbeta med okerr är lätt och enkelt för oss och det har alla funktioner som vi behövde (vi lade till vad det inte hade). Förresten, om det saknas några funktioner, fråga så lägger jag till dem (jag lovar inte, men jag vill att okerr ska vara det bästa övervakningssystemet för små och medelstora projekt). Eller ännu bättre, lägg till det själv – det är enkelt.

Vi lyckades leva efter principen "lär oss om alla problem från kerra." Om det plötsligt uppstår ett problem som vi inte har lärt oss om från okerr lägger vi till en bock på okerr. (i det här fallet menar jag med "vi" oss som användare av systemet, inte medutvecklare). Först var detta vanligt, men nu har det blivit väldigt sällsynt.

övervakning

Genom okerr övervakar vi loggstorlekarna på alla servrar. Det är naturligtvis omöjligt att eftertänksamt läsa varje rad i loggen med ögonen, men att bara övervaka tillväxttakten ger redan mycket. Genom detta upptäckte vi skräppost och brute force-lösenordssökningar, och när några av applikationerna "blir galna" fungerar något inte för dem och de upprepar det om och om igen (varje gång de lägger till ett par rader i loggen ).

SSL-certifikat. Nästan direkt efter lanseringen LetsEncrypt vår kund började tillhandahålla gratis SSL-certifikat till sina kunder (ungefär tusen av dem). Och det visade sig bara vara ett helvete för administrationen! Faktum är att sajter är "live", klienter ber dem med jämna mellanrum att göra något, programmerare gör det. De kan helt fritt överföra sajten till en annan DocumentRoot, till exempel. Eller lägg till en ovillkorlig omskrivning till virtualhost-konfigurationen. Naturligtvis, efter detta, går den automatiska förnyelsen av certifikaten sönder. Nu har vi lagt till alla SSL-värdar till okerr automatiskt genom ett annat av våra användbara verktyg från paketet a2conf. Låt oss bara starta a2okerr.py — och om flera nya sajter dyker upp på servern kommer de automatiskt att dyka upp i okerr. Om certifikatet plötsligt av någon anledning inte förnyas, tre veckor innan certifikatet går ut, är vi i vetskap, och vi kommer att ta reda på varför det inte uppdateras, en sådan hund. a2certbot.py från samma paket - det hjälper mycket med detta (det kontrollerar omedelbart de mest troliga problemen - och skriver vad som kontrollerades bra, och var det med största sannolikhet finns ett problem).

Vi övervakar utgångsdatumet för alla våra domäner. Och alla våra e-postservrar som skickar e-post kontrolleras också mot 50+ olika svarta listor. (Och ibland faller de in i dem). Visste du förresten att Googles e-postservrar också är svartlistade? Bara för självtestning lade vi till mail-wr1-f54.google.com till de övervakade servrarna, och den finns fortfarande på SORBS svarta lista! (Detta handlar om värdet av "anti-spammare")

Säkerhetskopieringar – jag skrev redan ovan hur lätt det är att övervaka dem med okerr. Men vi övervakar både de senaste säkerhetskopiorna på vår server och (med hjälp av ett separat verktyg som använder okerr) säkerhetskopiorna som vi laddar upp till Amazon Glacier. Och ja, problem uppstår då och då. Inte konstigt att de tittade.

Vi använder eskaleringsindikatorn. Det visar om något problem inte har åtgärdats på länge. Och jag själv, när jag löser vissa problem, kan jag ibland glömma dem. Eskalering är en bra påminnelse, även om du övervakar dig själv.

Sammantaget tror jag att kvaliteten på vårt arbete har ökat med en storleksordning. Det finns nästan ingen stilleståndstid (eller så hinner kunden inte märka det. Bara shh!), samtidigt som arbetsmängden har blivit mindre och arbetsförhållandena har blivit lugnare. Vi har gått från akutarbete med att lappa hål med tejp till lugnt och uppmätt arbete, då många problem är förutspådda i förväg och det finns tid att förebygga. Även problem som har hänt har också blivit lättare att åtgärda: för det första får vi reda på dem innan kunderna får panik, och för det andra händer det ofta att problemet är relaterat till det senaste arbetet (medan jag gjorde en sak, bröt jag en annan) - så det är varmt Det är lättare för spår att hantera det.

Men det var ett annat fall...

Visste du att i populära Debian 9 (Stretch) är ett så populärt paket som phpmyadmin fortfarande (i många månader!) i sårbar status? (CVE-2019-6798). När sårbarheten dök upp täckte vi snabbt upp den på olika sätt. Men jag satte upp övervakning av säkerhetsspårningssidan i okerr för att veta när en "vacker" lösning kommer ut (via SHA1-summan av innehållet). Indikatorn ryckte mig flera gånger, sidan ändrades, men som du kan se tyder den fortfarande (sedan januari 2019!) inte på att problemet är löst. Kanske, förresten, någon vet vad problemet är att ett så viktigt paket fortfarande är sårbart i mer än ett år?

En annan gång i en liknande situation: efter en sårbarhet i SSH var det nödvändigt att uppdatera alla servrar. Och när du ställer in en uppgift måste du kontrollera utförandet. (Underordnade tenderar att missförstå, glömma, bli förvirrade och göra misstag). Därför lade vi först till en SSH-versionskontroll till okerr på alla servrar, och genom okerr såg vi till att uppdateringar rullades ut på alla servrar. (Bekvämt! Jag valde den här typen av indikator, och du kan direkt se vilken server som har vilken version). När vi var säkra på att uppgiften var klar på alla servrar tog vi bort indikatorerna.

Ett par gånger var det en situation där ett visst problem uppstår, och sedan går över av sig själv. (förmodligen bekant för alla?). När du märker det, när du kontrollerar – och det finns inget att kontrollera – fungerar allt redan bra. Men så går det sönder igen. Det här hände till exempel med produkter som vi laddade upp till Amazon Marketplace (MWS). Vid något tillfälle var det laddade lagret felaktigt (fel mängd varor och fel priser). Vi kom på det. Men för att reda ut det var det viktigt att ta reda på problemet direkt. Tyvärr är MWS, precis som alla Amazon-tjänster, lite långsam, så det fanns alltid en fördröjning, men ändå kunde vi åtminstone grovt förstå sambandet mellan problemet och skripten som orsakade det (vi gjorde en kontroll, fastnade den till okerren och kontrollerade den omedelbart och fick en varning).

Ett intressant fall lades nyligen till samlingen av en stor och dyr europeisk hoster, som vår kund använder. Plötsligt försvann ALLA våra servrar från radarn! Först märkte kunden själv (snabbare än okerra!) att sajten han arbetade med inte öppnade och gjorde en biljett om det. Men inte bara en sida gick ner, utan alla! (Natasha, vi tappade allt!). Här började Okerr skicka långa fotinpackningar med alla indikatorer som tändes för honom. Panik, panik, vi springer i cirklar (vad mer kan vi göra?). Sedan steg allt. Det visar sig att det var rutinunderhåll i datacentret (en gång vart många år) och vi borde naturligtvis ha blivit varnade. Men något slags problem hände dem och de varnade oss inte. Jo, fler hjärtinfarkter, mindre hjärtinfarkter. Men efter att allt är återställt måste du dubbelkolla allt! Jag kan inte föreställa mig hur jag skulle göra det med mina händer. Okerr testade allt på några minuter. Det visade sig att de flesta servrarna helt enkelt var tillfälligt otillgängliga, men de fungerade. En del var överbelastade, men stod också upp som de skulle. Av alla förluster förlorade vi två säkerhetskopior, som enligt kronan skulle ha skapats och laddats medan denna fulla banan pågick. Jag brydde mig inte ens om att skapa dem, bara en dag senare kom varningar om att allt var OK, säkerhetskopior hade dykt upp. Jag gillar verkligen det här exemplet eftersom okerr visade sig vara väldigt användbar i en situation som vi inte ens hade tänkt på i förväg, men det är syftet med övervakningen - att stå emot det oförutsägbara.

För Okerr-sensorer använder vi billigast möjliga hosting (där kvalitet och tillförlitlighet inte är viktigt försäkrar de varandra). Så vi hittade nyligen ett mycket bra värd och superbilligt, riktmärkena är fantastiska. Men... ibland visar det sig att utgående anslutningar från den virtuella maskinen görs från en annan (intilliggande) IP. Mirakel. Client_ip-modul med https://diagnostic.opendns.com/myip får fel IP. Och från indikatorns serverloggar är det tydligt att uppdateringen också kom från denna angränsande IP. Låt oss ta itu med stödet nu. Det är bra att vi märkte detta i fredstid. Men det händer till exempel ofta att åtkomsten registreras enligt IP-vitlistan – och om servern ibland blinkar så här en kort stund – kan man försöka fånga detta problem väldigt länge.

Tja, en sak till – eftersom vi pratar om VPS-värd – använder vi alltid billiga (hetzner, ovh, scaleway). Jag gillar det verkligen både när det gäller riktmärken och stabilitet. Vi använder även den mycket dyrare Amazon EC2 för andra projekt. Så tack vare okerr har vi vår egen informerade åsikt. De faller båda. Och jag skulle inte säga att under den långa perioden av våra observationer visade sig billiga värdar som hetzner vara märkbart mindre stabila än EC2. Därför, om du inte är bunden till andra Amazon-funktioner, varför betala mer? 🙂

Vad händer nu?

Om jag i det här skedet inte har skrämt bort dig från Okerr än, försök då! Du kan gå direkt till denna länk okerr demokonto (Klicka nu!) Men tänk på att det bara finns ett demokonto för alla, så om du gör något kan någon annan på samma konto störa dig samtidigt. Eller (bättre) registrera dig via länken till offsite okerr - allt är enkelt, utan SMS. Om du inte gillar att använda din riktiga e-post kan du använda en engångspost, som mailinator (jag rekommenderar getnada.com). Sådana konton kan raderas med tiden, men de går bra att testa.

Efter registrering kommer du att bli ombedd att genomgå utbildning (utför flera inte särskilt svåra träningsuppgifter). De initiala gränserna är mycket små, men för träning eller en server räcker de. Efter avslutad utbildning kommer gränserna (till exempel det maximala antalet indikatorer) att ökas.

Från dokumentationen - först och främst WIKI på serversidan och på klienten (okerrupdate wiki). Men om något är oklart, skriv till support (at) okerr.com eller lämna en biljett - vi ska försöka lösa allt snabbt.

Om du använder det seriöst och dessa ökade gränser inte räcker, skriv till supporten så ökar vi det (gratis).

Vill du installera okerr-servern på din server? Här okerr-dev repository. Vi rekommenderar att du installerar på en ren virtuell maskin, sedan kan du helt enkelt göra det med ett installationsskript. På din virtuella maskin - inga begränsningar :-). Tja, igen, om något händer kommer vi alltid att försöka hjälpa till.

Vi vill att det här projektet ska ta fart, så att världen blir mer pålitlig tack vare oss. Tack vare gratis programvara och tjänster har världen blivit vänligare och utvecklas mer dynamiskt. Källorna kan lagras i gratis github, och för e-post kan du använda gratis gmail. Vi använder gratis freshworks för support. För något av detta behöver du inte betala för servrar, du behöver inte ladda ner och konfigurera, och du behöver inte lösa olika driftsproblem. Varje nytt projekt, varje team har omedelbart e-post, arkiv och CRM. Och allt detta är mycket hög kvalitet och gratis och omedelbart. Vi vill att det ska vara likadant för övervakning - små företag och projekt kan använda okerr gratis och även i födelse- och tillväxtstadiet ha tillförlitligheten hos vuxna seriösa projekt.

Källa: will.com

Översikt över Okerr hybridövervakningssystem