För två år sedan gjorde jag redan ett inlägg En enkel failover för webbplatsen om okerr. Det har nu skett viss utveckling av projektet, och jag har också publicerat källkoden för serverdelen av okerr under öppen licens, så jag beslutade mig för att skriva denna lilla översikt på Habr.

[ full storlek ]

Vem kan vara intresserad av detta

Det kan vara intressant för dig om du arbetar i ett litet team eller helt ensam. Du har ingen övervakning och är osäker på om det verkligen behövs. Eller så har du provat någon populär, seriös övervakning "för stora killar", men den fungerade inte riktigt för dig, eller så fungerar den nästan i standardkonfiguration och har inte förändrat ditt liv särskilt mycket. Och dessutom — om du definitivt inte planerar att avsätta en hel anställd (eller till och med en avdelning) för att övervaka instrumentpanelen i några timmar varje dag eller konfigurera den.

Vad som gör okerr ovanligt

Vidare ska jag visa intressanta funktioner hos okerr som skiljer det från vissa andra övervakningar.

Okerr är en hybridövervakning

Vid intern övervakning körs en "agent" på de observerade maskinerna som skickar data till övervakningsservern (t.ex. ledigt utrymme på diskarna). Vid extern övervakning kontrollerar servern över nätverk (t.ex. ping eller tillgänglighet av webbplatsen). Varje metod har sina begränsningar. Okerr använder båda alternativen. Kontroller inuti servrarna utförs av en mycket lätt (30Kb) agent eller av dina egna skript och applikationer, medan nätverkskontroller görs via okerr-sensorer i olika länder.

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

Serverdelen av vilken övervakning som helst är stor och komplex, det är svårt att installera och konfigurera den, och den kräver resurser. Med okerr kan du sätta upp din egen övervakningsserver (den är gratis och öppen källkod), eller så kan du bara använda klientdelen och utnyttja tjänsten från vår server. Också gratis.

Om övervakningen kan kompensera för bristen på tillförlitlighet hos servrar och applikationer, uppstår den filosofiska frågan – vem vaktar vakten? Hur ska övervakningen rapportera ett problem om den själv "dör" av någon anledning, separat eller tillsammans med andra resurser (till exempel, om kanalen till datacentret går ner)? Genom att använda den externa tjänsten okerr löses detta problem – du får en alert även om hela datacentret med dina servrar är strömlöst eller utsatt för en zombieattack.

Självklart finns det en risk att servern okerr själv inte är tillgänglig, det är sant (som bekant får man alltid 90% tillförlitlighet ganska enkelt och "gratis", 99% med minimala ansträngningar, och varje följande nio blir exponentiellt svårare). Men för det första är chansen för detta lägre, och för det andra kan problemet förbli obemärkt endast om det sammanfaller i tid med problem på våra servrar. Om vi har 99,9% tillförlitlighet och du har 99,9% (inte alltför höga siffror), så är chansen för en obemärkt nedgång – 0,1% av 0,1% = 0,0001%. Att lägga till tre nior i tillförlitlighet nästan utan ansträngning och utan kostnad – det är ganska bra!

En annan fördel med övervakning som en tjänst är att en hostingleverantör eller webbyrå kan installera servern okerr och erbjuda tillgång till kunder som en betald eller gratis extra tjänst. Dine konkurrenter har bara hosting och webbplatser – men du har pålitlig hosting med övervakning.

Okerr handlar om indikatorer

En indikator är en "lampa". Den har två huvudsakliga tillstånd – grön (OK) eller röd (ERR). I projektet finns det många grupperade (till exempel efter servrar) indikatorer. På projektets huvudsida ser du direkt antingen att allt är grönt (och kan stängas av), eller att något lyser rött och måste åtgärdas. Vid övergång mellan dessa tillstånd skickas en notifikation. En gång om dagen, så länge du ställer in det, skickas en sammanställning av projektet.

Varje indikator okerr har inbyggda villkor enligt vilka den ändrar tillstånd (i Zabbix kallas detta trigger). Till exempel, lastgenomsnittet får inte överstiga 2 (detta kan självklart ställas in). För varje intern kontroll (lastgenomsnitt, ledig disk, …) finns det en watchdog. Om vi av någon anledning inte får en lyckad bekräftelse vid avsatt tid registreras ett fel och en alert skickas.

Vår vanliga arbetsmetod är att kontrollera e-posten på morgonen, däribland tittar vi på sammanfattningen (vi sätter dess tid till början av arbetsdagen). Om allt ser bra ut där, sysslar vi med andra viktiga uppgifter (men vi kan snabbt kolla på okerr-dashboarden för att försäkra oss om att allt fortfarande är grönt). Om en varning kommer in reagerar vi.

Självklart finns det möjlighet att bara hålla «informations» indikatorer (för att se nätverksläget från övervakningen), men allt är gjort för att enkelt, lätt och snabbt skapa indikatorer för automatisk övervakning och varningsutsändning.

Meningen med att du ställer in okerr är varningarna, att du kan skapa en indikator på en minut, den kan ha «sovit» i åratal, bara tagit emot uppdateringar, och när något går sönder om ett år tänds den och skickar ut en varning. Minuten du en gång lade ner på att skapa indikatorn har lönat sig, du fick veta om problemet omedelbart, före alla andra. Kanske lagade du det innan någon märkte. Snabbt upprättad räknas inte som nedfallen!

Säkerhet

Det skulle vara tråkigt om du sätter upp övervakning för att öka pålitligheten, och istället blir du attackerad via den, och det finns många nätverksutsattheter hos olika övervakningsverktyg (Zabbix, Nagios).

Agent (okerrmod från paketet okerrupdate), som arbetar 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 det är mycket svårt (jag skulle säga «omöjligt») att hacka den via nätet, eftersom den i princip inte lyssnar på nätverksocket.

Fullständig övervakningstäckning

Nu har vi en regel — vi får veta om alla tekniska problem från okerr. Om regeln plötsligt bryts (om okerr inte varnar om ett problem som kan komma (om möjligt) eller om det redan har inträffat) — vi lägger till kontroller i okerr.

Externa kontroller

En ganska typisk uppsättning:

• ping
• http-status
• kontroll av giltighet och aktualitet för SSL-certifikat (varnar om giltighetstiden snart går ut)
• öppen TCP-port och banner på den
• http grep (på sidan [ska] inte finnas viss text)
• sha1-hash för att fånga ändringar av sidan.
• DNS (DNS-posten måste ha ett visst värde)
• WHOIS (varnar om domänen snart går ut)
• Antispam DNSBL (kontroll av värden direkt mot 50+ antispam-svartlistor)

Interna kontroller

Även en ganska typisk uppsättning (men lätt utbyggbar).

• df (ledig diskplats)
• load average
• opentcp (öppna lyssnande TCP-sockets — meddelar om något har startat eller stängts ner)
• uptime — visar bara uptime för servern. Meddelar om den förändras nedåt (d.v.s. servern har startats om)
• client_ip
• dirsize — vi använder den för att övervaka när våra rootfs för virtuella maskiner överskrider den tillåtna storleken, utan att införa strikta begränsningar, och för storlekarna på användarens hemkataloger.
• empty och nonempty — övervakar filer som ska vara tomma (eller inte tomma). Till exempel, error log för servern okerr — ska vara tom, och om det finns ens en rad — får jag ett meddelande och kontrollerar. Men mail.log på mailservern ska INTE vara tom (efter N minuter efter rotation). Ibland har det ändå varit tomt efter systemuppdateringar, när logrotate inte kunde starta om rsyslog korrekt.
• linecount — antalet rader i en fil (som wc -l). Vi använder det som en mjukare ersättning för empty, när error log faktiskt kan växa, men bara långsamt (till exempel, googlebot har problem med vissa skyddade sidor). Det finns en gräns på 2 rader på 20 minuter. Om det överskrider — blir det ett alert.

Intressanta interna kontroller

Om du har läst "diagonalt" fram till nu, kommer det bli intressantare att läsa noggrant.

backups

Övervakar säkerhetskopior i katalogen. Våra backupfiler har namn som "ServerName-20200530.tar.gz". För varje server skapas en indikator i okerr som heter ServerName-DATE.tar.gz (det faktiska datumet ändras till strängen "DATE"). Både närvaron av en ny backup och dess storlek övervakas (till exempel, den får inte vara mindre än 90 % av den föregående backupen).

Vad behöver göras för att den nya backuppen ska börja övervakas efter att vi har påbörjat skapandet och lagt den i denna katalog? Ingenting! Det är ett mycket bekvämt tillvägagångssätt när man inte behöver göra "något", för att:

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

Om plötsligt inga nya backupfiler dyker upp — blir det ett alert. Om du till exempel stängde av en av servrarna, och dess backuper inte borde finnas längre — måste du ta bort indikatorn (via webgränssnittet eller från terminalen via API).

maxfilesz

Övervakar storleken på de största filerna (vanligtvis: /var/log/*). Detta hjälper till att fånga oförutsägbara problem, som till exempel lösenordsattacker eller utskick av skräppost via servern.

runstatus/runline

Detta är två viktiga proxy-moduler för att köra andra program på servern. Runstatus rapporterar en indikator för programmets utgångskod. Till exempel finns det ingen (ingen behövs) modul för att kontrollera att systemd-tjänsterna fungerar i okerr. Detta hanteras via runstatus (se nedan). Runline rapporterar den rad som programmet ger på servern. Till exempel, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" i konfigurationen skapar Runline på vår server en indikator servername:temp med processor-temperaturen.

sql

Utför en numerisk fråga till MySQL och rapporterar resultatet i en indikator. I det enklaste fallet kan man till exempel göra "SELECT 1" — detta kommer kontrollera att databasen fungerar i allmänhet.

Men en mycket mer intressant tillämpning är att till exempel spåra antalet beställningar i en nätbutik. Om du vet att du har mellan 100 beställningar i timmen kan du ställa in en minimi-gräns på 100 eller 80. Då får du en alert om försäljningen plötsligt sjunker — så kan du ta itu med det.

Observera — det spelar ingen roll av vilken oförutsägbar anledning detta inträffade:

• Servern är helt enkelt otillgänglig (strömlös eller utan nätverk), och alerten kom från att indikatorn "blev gammal".
• Servern är belastad, arbetar långsamt eller tappar paket, och användarna har svårt att använda den och lämnar utan att handla.
• Servern har hamnat på skräppostlistor, och mail från den tas inte emot, användare kan inte registrera sig.
• Budgeten för reklamkampanjen är slut, annonser körs inte.

Det kan finnas hur många orsaker som helst, och man kan inte förutse dem alla i förväg, och det är tekniskt svårt att spåra. Men det är möjligt att bekvämt övervaka den slutliga parametern (beställningarna) och utifrån det avgöra att situationen är misstänkt och värd att undersöka.

Logiska indikatorer

Möjliggör användning av logiska uttryck (Python-syntax) via modulen evalidate(artikel på habra). För uttrycket är projektets och dess indikatorers data tillgängliga. Till exempel, i kapitlet om SQL-kontrollen ovan, kanske du märkte en svaghet — på dagen kan vi ha upp till 100 försäljningar i timmen, men på natten har vi bara 20, och det är normalt, inget problem. Hur ska vi göra? Indikatorn kommer ju ständigt att larma på nätterna.

Det går att skapa två indikatorer, en för dagen och en för natten. Båda kan göras "tysta" (de kommer inte att skicka aviseringar). Och skapa en logikindikator som kräver att dagindikatorn är OK före klockan 20:00, och efter klockan 20:00 är det tillräckligt att natindikatorn är OK.

Ett annat exempel på användningen av en logikindikator är eskalering. Till exempel avregistrerar projektledaren sig från alertar (han behöver inte dem, administratörerna ska reagera på vanliga problem), men registrerar sig på en logikindikator som blir röd om någon indikator i projektet inte har åtgärdats inom angiven tid.

Dessutom finns det möjlighet att ställa in tillåten driftid, till exempel från 3 till 5 på morgonen. Vi bryr oss inte om servrarna och webbplatserna "går ner" under denna tid. Men klockan 5:00 ska de fungera. Om de inte fungerar vid någon annan tidpunkt blir det en alert. Logikindikatorn tar också hänsyn till serverreserv. Om du har 5 webbservrar kan administratörerna stänga av 1-2 servrar när som helst. Men om det är mindre än 3 av 5 servrar i drift - kommer det att bli en alert.

Exemplen ovan är inte funktioner i okerr, inte några funktioner som behöver aktiveras och konfigureras. Alla dessa funktioner finns inte i okerr, men det finns en logikmodul som möjliggör att implementera denna funktionalitet (ungefär som i ett programmeringsspråk - om vi har aritmetiska operatorer, behöver vi inte ett särskilt språk för att beräkna 20% moms, det kan alltid göras av oss själva efter behov).

Logikindikatorn är förmodligen ett av de få relativt komplexa ämnena inom okerr, men den goda nyheten är att du inte behöver behärska dem förrän det behövs. Men de utökar mycket funktionaliteten samtidigt som systemet förblir ganska enkelt.

Att lägga till egna kontroller

Jag skulle verkligen vilja framföra tanken att okerr inte är en samling av tusen färdiga kontroller för alla livssituationer, utan tvärtom - först och främst - en enkel motor med en enkel möjlighet att skapa egna kontroller. Att skapa egna kontroller i okerr är inte en uppgift för hackare, medutvecklare av systemet, eller åtminstone avancerade användare av okerr, utan en genomförbar uppgift för varje administratör som för en månad sedan först installerade linux.

Kontroller på miniminivå görs genom modulen runstatus:

Denna rad i konfigurationen runstatus skickar ett meddelande om /bin/true skulle misslyckas med att starta eller återlämna något annat än 0.

true_OK=\/bin\/true

Bara en enda rad — och här har vi redan utökat lite funktionaliteten för okerr. Även en sådan kontroll har sitt värde: om din server skulle gå ner — kommer den motsvarande indikatorn på servern okerr inte att uppdateras i tid, och efter en tid kommer en varning att uppstå.

Denna kontroll kommer att meddela att servern apache2 har kraschat (man vet aldrig…):

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

Så om du kan något programmeringsspråk, åtminstone kan skriva shell-skript — då kan du redan lägga till egna kontroller.

Mer komplicerat — du kan skriva (i vilket språk som helst) din egen modul för okerrmod. I enklaste fall ser den ut så här:

Är det inte så svårt? Modulen ska göra själva kontrollen och visa resultaten på STDOUT. En mer avancerad modul ger till exempel följande:

#!/usr/bin/python3

print("STATUS: OK")

$ okerrmod --dump df NAMN: pi:df-\/\nTAGGAR: df METOD: numerisk|maxlim=90 DETLER: 49,52%, 13,9G\/28,2G använd, 13,0G ledigt STATUS: 49,52NAMN: pi:df-\/boot TAGGAR: df METOD: numerisk|maxlim=90 DETLER: 84,32%, 53,1M\/62,9M använd, 9,9M ledigt STATUS: 84,32

Den uppdaterar flera indikatorer samtidigt (separerade med en tom rad), skapar dem vid behov, anger detaljer om kontrollen och en tagg som gör det lätt att hitta de nödvändiga indikatorerna i dashboards.

Det finns en Telegram-bot

Telegram

@OkerrBot . Du behöver inte belasta telefonen med separata appar (jag gillar inte heller att för Pjatjorlka behövs en app med ett kort, för Lenta en annan, för MTS en tredje, och så för alla). Ett Telegram — räcker. Via Telegram kan man få varningar direkt, kolla projektstatus och ge kommandon för att kontrollera alla problematiska indikatorer. Gick ut från teatern\/flygplanet, har inte hållit handen på pulsen i två timmar, slog på telefonen, tryckte på en knapp i chatbotten och försäkrade mig om att allt är okej.Statussidor

I dagens läge är statusidor nästan ett måste för alla företag som har IT, en ansvarsfull inställning till tillförlitlighet och som respekterar sina kunder\/användare.

I vår tid är statusidor nästan ett måste för vilket företag som helst som har IT, ansvar för pålitlighet och som har respekt för sina kunder\/användare.

Tänk dig en situation – en användare vill göra något, se information eller lägga en beställning, och något fungerar inte. Han vet inte vad problemet är, vem det beror på och när det kan lösas. Kanske har ditt företag bara en trasig webbplats? Eller så gick det sönder för ett halvår sedan och kommer att repareras om två år? Men kylskåpet måste köpas nu, det ligger redan i varukorgen… Det är helt annat när en person ser att det är något fel hos er (åtminstone är det klart att problemet inte ligger hos honom), att problemet har upptäckts, att ni redan arbetar med det, och kanske till och med har skrivit en ungefärlig tid för när det kommer att åtgärdas. Användaren kan prenumerera och få ett meddelande via e-post när problemet är löst och han kan göra det han ville (köpa kylskåpet).

Problem och driftstopp – det händer alla. Men användare och partners litar mer på dem som är mer transparenta och tar ansvar för detta.

Här är översikt över 10 andra projekt som kan skapa status sidor. Här är exempel på hur dessa sidor ser ut hos projekten Python och Dropbox. Statussidan okerr.

Failover

För att inte göra den här artikeln ännu längre, hänvisar jag återigen till min tidigare artikel – En enkel failover för webbplatsen . Om du kan skapa en duplicerad server, så med användning av failover, så kommer du i princip inte ha lång driftstopp – så snart problemet upptäcks kommer användarna automatiskt att omdirigeras till den fungerande reservservern. Och jag tycker att det här är en väldigt intressant och unik funktion som knappt finns någon annanstans.

Låga systemkrav

För servrarna okerr – använder vi maskiner med RAM från 2Gb. För nätverksensorer – till och med 512Mb räcker. Klientdelen – nästan inget överhuvudtaget. (Paketet okerrupdate väger 26 Kb, men kräver Python3 och standardbibliotek). Klienten körs från ett cron-skript, så den har noll konstant minnesanvändning. Bland de observerade maskinerna har vi sensorer (superbilliga VPS:er med 512Mb RAM) och Raspberry Pi. Man kan till och med utan klientdelen skicka uppdateringar via curl! (se nedan)

Med detta i åtanke – okerr är nog den mest kostnadsfria Övervakningssystemet är tillgängligt, eftersom även för att använda ett annat gratis open source-system som Zabbix eller Nagios behövs resurser (server), vilket kostar pengar. Dessutom krävs viss serverunderhåll. Med okerr kan den delen tas bort. Det går också att behålla en egen server — beroende på vad som passar bäst för dig.

API och integration i egen programvara

En enkel och öppen arkitektur. Okerr har en ganska enkel API, som är lätt att arbeta med. Behöver du skapa 1000 indikatorer? Ett shell-skript på 3-4 rader klarar det. Måste du omkonfigurera 1000 indikatorer? Det är också väldigt enkelt. Till exempel, vi vill kontrollera alla våra HTTPS-certifikat just med 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

Indikatorn kan uppdateras antingen med vår klientmodul eller till och med 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 genom att skicka heartbeat-signaler så att okerr vet att den är igång och kan larma om den slocknar eller hänger sig. För övrigt gör komponenter i okerr precis detta — okerr övervakar sig själv, och problem i nästan vilken modul som helst kommer att upptäckas och generera en meddelande om problem. (Och för den där "nästan" — de kontrolleras korsvis med en annan server)

Så här ser koden ut (förenklat) i vår Telegram-bot:

from okerrupdate import OkerrProject, OkerrExc

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

För att uppdatera indikatorer från Python-program finns det ett bibliotek okerrupdate, för alla andra språk finns det inget bibliotek, men du kan antingen kalla skriptet okerrupdate eller göra en HTTP-förfrågan till servern okerr.

Hur okerr hjälper oss

Okerr har förändrat vårt liv. Verkligen. Kanske kunde ett annat övervakningssystem också ha gjort det, men det är enkelt och smidigt att arbeta med okerr, och det innehåller alla funktioner vi behövde (det som saknades — har vi lagt till). Om någon funktion saknas — fråga, så ska jag lägga till dem (jag lovar inget, men jag vill att okerr ska vara det bästa övervakningssystemet för små och medelstora projekt). Eller ännu bättre, lägg till dem själv — det är enkelt.

Vi har lyckats leva efter principen "att veta om alla problem genom okerr". Om det plötsligt uppstår ett problem som vi inte fått veta från okerr — lägger vi till en kontroll i okerr. (I det här fallet menar jag "vi" som användare av systemet, inte som medutvecklare). Till en början hände detta ofta, men nu har det blivit mycket sällsynt.

Övervakning

Genom okerr övervakar vi storleken på loggarna på alla servrar. Att noggrant läsa varje rad i loggen — är förstås omöjligt, men att bara följa tillväxttakten — ger redan mycket. Genom detta har vi upptäckt både skräppostutskick och bruteforce-lösenordsattacker, samt när några av applikationerna "går bananas", där de inte lyckas med något och de försöker igen och igen (och varje gång lägger till ett par rader i loggen).

SSL-certifikat. Nästan omedelbart efter starten LetsEncrypt började vår kund ge sina egna kunder gratis SSL-certifikat (ungefär tusen av dem). Och det visade sig vara rent helvete att administrera! Grejen är att webbplatserna är "levande", kunder ber ibland om ändringar, utvecklarna gör dem. De kan helt fritt flytta webbplatsen till en annan DocumentRoot till exempel. Eller lägga till en fast Rewrite i virtuella värdars konfig. Naturligtvis, efter sådana ändringar, slutar automatisk uppdatering av certifikat att fungera. Nu läggs alla våra SSL-värdar till i okerr automatisk via ett av våra användbara verktyg från paketet a2conf. Vi kör bara a2okerr.py — och om det finns flera nya webbplatser på servern — kommer de automatiskt att dyka upp i okerr. Om av någon anledning certifikatet inte uppdateras, får vi veta tre veckor innan certifikatet går ut — och vi tar reda på varför det inte uppdateras, den hunden. a2certbot.py från samma paket — är mycket hjälpsam i detta (den kontrollerar direkt de mest sannolika problemen — och skriver vad som har kontrollerats väl, och var det troligen finns problem).

Vi övervakar utgångsdatum för alla våra domäner. Och alla våra postservrar, som skickar e-post — kontrolleras dessutom mot mer än 50 olika svartlistor. (Och ibland hamnar de i dem). För övrigt, vet ni att Googles postservrar också finns på svartlistor? Bara för självkontroll har vi lagt till mail-wr1-f54.google.com till de övervakade servrarna, och den ligger faktiskt på SORBS svartlistan! (Detta är en kommentar om värdet av "antispam"-tjänster)

Backuper — jag nämnde tidigare hur enkelt det är att övervaka dem med okerr. Men vi övervakar också färska backuper på vår server, och (med hjälp av ett separat verktyg som använder okerr) — backuperna som vi laddar upp till Amazon Glacier. Och ja — problem inträffar periodvis. Det är därför vi följer upp.

Vi använder en eskalering indikator. Den visar om ett problem inte har åtgärdats under lång tid. Och jag själv, när jag löser vissa uppgifter, kan ibland glömma bort dem. Eskalering är en bra påminnelse, även om man håller koll på sig själv.

Generellt anser jag att kvalitén på vårt arbete har ökat avsevärt. Nerstängning nästan inte förekommer (eller så hinner klienten inte märka det. Tyst nu!), samtidigt har arbetsbelastningen minskat och arbetsvillkoren blivit lugnare. Vi har gått från att jobba i panik och laga hål med tejp till ett lugnt och jämnt arbete, där många problem förutses i förväg och det finns tid att förhindra dem. Även när problem faktiskt inträffar — det har blivit lättare att åtgärda: för det första, vi får veta om dem innan klienterna får panik, och för det andra, det är oftast så att problemet är relaterat till nyligen utförda arbeten (medan jag gjorde en sak, skadade jag en annan) — därför är det lättare att hantera dem direkt.

Och här är en annan händelse...

Visste du att i den populära Debian 9 (Stretch) så har ett så populärt paket som phpmyadmin fortfarande (efter många månader!) status som sårbart?CVE-2019-6798). När sårbarheten först rapporterades — åtgärdade vi den snabbt på olika sätt. Men jag har lagt till övervakning i okerr för säkerhetsspårningssidan, för att veta när en 'ren' lösning (genom SHA1-kontrollsumma) kommer. Flera gånger har indikatorsignalen dragit i mig, sidan har ändrats, men som du ser — fortfarande (sedan januari 2019!) finns det inget som tyder på att problemet har lösts. Kanske vet någon förresten vad problemet är, som gör att ett så viktigt paket är sårbart i över ett år?

En annan gång i en liknande situation: efter en sårbarhet i SSH behövde vi uppdatera alla servrar. Och när man sätter en uppgift — måste man kontrollera genomförandet. (Underdåare har en tendens att inte förstå, glömma, bli förvirrade, göra misstag). Därför lade vi först till en kontroll av SSH-versionen på alla servrar i okerr, och genom okerr övervakade vi att uppdateringarna genomfördes på alla servrar. (Praktiskt! Jag valde denna typ av indikator, och det är direkt synligt vilken version som finns på vilken server). När vi var säkra på att uppgiften var utförd på alla servrar — tog vi bort indikatorerna.

Några gånger har det hänt att ett visst problem uppstår, för att sedan försvinna av sig själv. (Kanske bekant för alla?). När man väl upptäcker det, kontrollerar — och då finns det inget att kontrollera längre — allt fungerar bra igen. Men sedan bryts det ner igen. Vi upplevde detta till exempel med varor som vi laddade upp till Amazon Marketplace (MWS). Vid ett tillfälle var den uppladdade inventeringen felaktig (inte rätt antal varor och inte rätt priser). Vi löste det. Men för att förstå problemet — var det viktigt att få veta om det direkt. Tyvärr är MWS, som alla Amazons tjänster, lite seg, så det har alltid funnits en fördröjning, men vi lyckades åtminstone fånga sambandet mellan problemet och skripten som orsakade det (vi gjorde en kontroll, kopplade den till okerr, och kontrollerade direkt efter att vi fick en varning).

Ny intressant incident har nyligen lagts till i samlingen av en stor och dyr europeisk hostingleverantör som vår kund använder. Plötsligt försvann ALLA våra servrar från radarena! Först märkte kunden själv "med händerna" (snabbare än Okerr!) att webbplatsen han arbetade med inte öppnade sig och gjorde en ticket för detta. Men det var inte bara en webbplats, utan faktiskt alla! (Natasha, vi kraschade allt!). Här började även Okerr skicka långa meddelanden med alla indikatorer som hade aktiverats. Panik, panik, vi springer i cirklar (vad ska vi annars göra?). Sedan kom allt tillbaka. Det visade sig att det hade varit schemalagt underhåll i datacentret (en gång på många år) och vi borde självklart ha blivit informerade. Men något gick snett hos dem och de informerade inte oss. Nåväl, med eller utan hjärtinfarkt. Men efter att allt var återställt måste man kontrollera allt! Jag kan inte föreställa mig hur jag skulle ha gjort det för hand. Okerr testade allt på några minuter. Det visade sig att större delen av servrarna bara var tillfälligt otillgängliga, men fungerade ändå. Några – överbelastades, men kom också tillbaka som de skulle. Av alla förluster – förlorade vi två backuper som enligt schemat skulle skapas och laddas upp under tiden som denna totala katastrof pågick. Jag skapade dem inte ens, det kom bara larm efter ett dygn om att allt var OK, backuperna dök upp. Jag gillar verkligen detta exempel, eftersom Okerr visade sig vara mycket användbart i en situation som vi inte ens hade förutsett, men det är just uppgiften för övervakning – att motverka det oförutsägbara.

För sensorerna Okerr använder vi så billiga hostingtjänster som möjligt (kvalitet och pålitlighet spelar ingen roll, de täcker för varandra). Så nyligen hittade vi en mycket energisk hostingleverantör till superlågt pris, benchmarkresultaten är fantastiska. Men… ibland visar det sig att utgående anslutningar från virtuella maskiner görs med en annan (grann-) IP. Underverk. Modul client_ip med https://diagnostic.opendns.com/myip får inte rätt IP. Och enligt serverloggarna för indikatorn är det tydligt att uppdateringen också kom från den grann-IP:n. Vi håller på att reda ut detta med supporten. Tur att vi märkte det under lugna omständigheter. Men, det händer ju ofta att åtkomst skrivs upp med vita listor av IP – och om servern ibland blinkar kortvarigt på detta sätt – kan man försöka fånga detta problem under en lång tid.

Och ännu en sak – när vi pratar om VPS-hosting – använder vi alltid prisvärda alternativ (hetzner, ovh, scaleway). Både när det kommer till prestanda och stabilitet är de mycket bra. Vi använder också det betydligt dyrare Amazon EC2 för andra projekt. Så tack vare okerr har vi en välgrundad åsikt. Båda kan falla. Och jag skulle inte säga att de billigare hostingenheter som hetzner har visat sig vara betydligt mindre stabila än EC2 under vår långa observationsperiod. Så om ni inte är bundna till andra funktioner hos Amazon – varför betala mer? 🙂

Vad händer härnäst?

Om jag inte har avskräckt dig från Okerr ännu – prova! Du kan gå direkt till demokontot okerr (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 i samma konto störa dig samtidigt. Eller (bättre) registrera dig via länken på okerrs officiella webbplats – allt är enkelt, utan SMS. Om du inte gillar att använda din riktiga e-post kan du använda en engångse-post, som mailinator (jag rekommenderar getnada.com). Sådana konton kan tas bort med tiden – men för testing kommer det att fungera.

Efter registreringen kommer du att erbjudas att genomgå en träning (utföra några inte så svåra utbildningsuppgifter). De initiala gränserna är mycket små, men för träning eller en server är de tillräckliga. Efter att träningen genomförts – kommer gränserna (till exempel det maximala antalet indikatorer) att ökas.

Från dokumentationen – i första hand WIKI för serverdelen och klienten (okerrupdate wiki). Men om något är oklart – skriv till support (at) okerr.com eller lämna en ticket – vi ska försöka lösa det snabbt.

Om du använder det seriöst och de ökade gränserna visar sig inte vara tillräckliga – tveka inte att kontakta support, så ökar vi dem (kostnadsfritt).

Vill du installera okerr-servern på din egen server? Här är okerr-dev repository. Vi rekommenderar att installera på en ren virtuell maskin, då kan du enkelt göra det med installationsskriptet. På din egen virtuella maskin – inga begränsningar :-). Och igen – om något, vi hjälper gärna till.

Vi vill att det här projektet ska lyfta, att världen ska bli tryggare tack vare oss. Tack vare gratis programvara och tjänster har världen blivit mer vänlig och utvecklas snabbare. Källkoden kan lagras på gratis GitHub, och för e-post kan man använda gratis Gmail. Vi använder gratis freshworks för support. Inget av detta kräver att man betalar för servrar, man behöver inte ladda ner och konfigurera eller lösa olika driftsproblem. Varje nytt projekt, varje team – får direkt tillgång till både e-post, repository och CRM. Och allt detta är av hög kvalitet, gratis och tillgängligt direkt. Vi vill att det ska vara samma för övervakning – små företag och projekt skulle kunna använda Okerr gratis även i sina tidigaste och växande skeden, med samma pålitlighet som stora, etablerade projekt.

Källa: habr.com