For to år siden skrev jeg allerede et innlegg Enkel failover for et nettsted про okerr. Nå er det litt utvikling av prosjektet, og jeg publiserte også okerr server side kildekode etter åpen lisens, det er derfor jeg bestemte meg for å skrive denne korte anmeldelsen på Habr.

[ full størrelse ]

For hvem det kan være av interesse

Dette kan være av interesse for deg om du jobber i et lite team eller alene. Du har ikke overvåking, og du er ikke sikker på om du virkelig trenger det. Enten har du prøvd noen populær seriøs overvåking "for de store guttene", men det "tok ikke av" for deg, eller så fungerer det i en nesten standardkonfigurasjon og endret ikke livet ditt mye. Og også - hvis du definitivt ikke planlegger å tildele en hel ansatt (eller til og med en avdeling) til å overvåke overvåkingsdashbordet minst et par timer om dagen eller konfigurere det.

Hvorfor okerr er uvanlig

Deretter vil jeg vise interessante funksjoner ved okerra som skiller den fra noen andre overvåkingssystemer.

Okerr er en hybrid overvåking

Under intern overvåking kjører en "agent" på de overvåkede maskinene, som overfører data til overvåkingsserveren (for eksempel ledig diskplass). Når den er ekstern, utfører serveren kontroller over nettverket (for eksempel ping eller nettstedtilgjengelighet). Hver tilnærming har sine begrensninger. Okerr bruker begge alternativene. Kontroller inne på servere utføres av en veldig lett (30Kb) agent eller dine egne skript og applikasjoner, og nettverkssjekker utføres gjennom okerr-sensorer i forskjellige land.

okerr er ikke bare programvare, men også en tjeneste

Serverdelen av enhver overvåking er stor og kompleks, den er vanskelig å installere og konfigurere, og den krever ressurser. Med okerr kan du installere din egen overvåkingsserver (den er gratis og åpen kildekode), eller du kan bare bruke klientdelen og bruke tjenesten til serveren vår. Også gratis.

Hvis overvåking lar deg kompensere og dekke over mangelen på pålitelighet i servere og applikasjoner, oppstår et filosofisk spørsmål - hvem er vakten? Hvordan vil overvåking fortelle oss om et problem hvis det selv "døde" av en eller annen grunn, separat eller sammen med dine andre ressurser (for eksempel kanalen til datasenteret falt)? Når du bruker den eksterne tjenesten okerr - dette problemet er løst - vil du motta et varsel selv om hele datasenteret med dine servere er uten strøm eller blir angrepet av zombier.

Selvfølgelig er det en risiko for at selve okerr-serveren vil være utilgjengelig, dette er sant (som du vet, oppnås alltid 90% av påliteligheten enkelt og "gratis", 99% med et minimum av innsats, og hver påfølgende ni er eksponentielt vanskeligere). Men for det første er sjansene for at dette skjer mindre, og for det andre kan problemet forbli ubemerket bare hvis det sammenfaller med problemer på serverne våre. Hvis vi har 99.9 % reliabilitet, og du har 99.9 % (ikke for høye tall), så er sjansen for en uoppdaget feil 0.1 % av 0.1 % = 0.0001 %. Å legge til tre niere til påliteligheten din nesten uten anstrengelse og uten kostnad er veldig bra!

En annen fordel med overvåking som en tjeneste er at en hostingleverandør eller webstudio kan installere en okerr-server og gi tilgang til klienter som en betalt eller gratis tilleggstjeneste. Konkurrentene dine har bare hosting og nettsteder, men du har pålitelig hosting med overvåking.

Okerr handler om indikatorer

Indikatoren er en "lyspære". Den har to hovedtilstander - grønn (OK) eller rød (ERR). Prosjektet inneholder mange grupperte (for eksempel etter server) indikatorer. På hovedsiden til prosjektet ser du umiddelbart at enten er alt grønt (og du kan lukke det), eller noe lyser rødt og må rettes opp. Ved overgang mellom disse tilstandene sendes et varsel. En gang om dagen mens du setter opp, sendes en oppsummering av prosjektet.

Hver okerr-indikator har innebygde forhold som gjør at den endrer tilstand (i Zabbix kalles dette en trigger). For eksempel bør belastningsgjennomsnittet ikke være mer enn 2 (selvfølgelig er dette konfigurerbart). Og for hver intern sjekk (lastgjennomsnitt, diskfri, ...) er det en vakthund. Hvis vi av en eller annen grunn ikke mottar en vellykket bekreftelse til avtalt tid, logges en feil og et varsel sendes.

Vårt vanlige arbeidsmønster er å sjekke e-post om morgenen, og se på sammendraget blant andre brev (vi planlegger det ved arbeidsstart). Hvis alt er ok i det, gjør vi andre viktige ting (men for å være sikker kan vi raskt se på okerra-dashbordet og sørge for at alt er grønt i dette øyeblikket). Kommer et varsel, reagerer vi.

Selvfølgelig er det mulig å bare beholde "informasjons"-indikatorer (for å se bildet av nettverket fra overvåking), men alt gjøres for enkelt, enkelt og raskt å lage indikatorer spesifikt for automatisk overvåking og sending av varsler.

Formålet du setter opp okerr for er i varsler, slik at du kan lage en indikator på et minutt, den kan "sove" i et år, bare godta oppdateringer, og når et år senere går i stykker, lyser den og sender et varsel. Minuttet du en gang brukte på å lage en indikator betalte seg; du lærte om problemet umiddelbart, før noen andre. Det er mulig at de fikset det før noen la merke til det. Noe som heves raskt regnes ikke for å ha falt!

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

Det ville være synd om du setter opp overvåking for å øke påliteligheten, men som et resultat blir du angrepet over nettverket gjennom det, og det er ganske mange nettverkssårbarheter i forskjellige overvåkingsverktøy (Zabbix, Nagios).

Agent (okerrmod fra pakken okerrupdate) som kjører på systemet er ikke en nettverksserver, men en klient. Derfor er det ingen ekstra åpne porter på den overvåkede serveren, klienten fungerer lett bak en brannmur eller NAT og er veldig vanskelig (jeg vil si "umulig") å hacke over nettverket, siden den i prinsippet ikke lytter til nettverket stikkontakt.

Full overvåkingsdekning

Nå er regelen vår at vi lærer om alle tekniske problemer fra okerr. Hvis regelen plutselig brytes (okerr advarte ikke om at den skulle skje (hvis dette er mulig) eller at den allerede har skjedd) - legger vi til sjekker til okerr.

Eksterne kontroller

Ganske typisk sett:

ping
http-status
kontrollere gyldigheten og ferskheten til SSL-sertifikatet (vil varsle hvis det er i ferd med å utløpe)
åpne TCP-porten og banner på den
http grep (siden [må ikke] inneholde bestemt tekst)
sha1 hash for å fange opp sidendringer.
DNS (DNS-post må ha en spesifikk verdi)
WHOIS (vil advare hvis domenet er i ferd med å bli dårlig)
Antispam DNSBL (vertssjekk mot 50+ antispam-svartelister samtidig)

Interne kontroller

Også et ganske standard sett (men lett utvidbart).

df (fri diskplass)
gjennomsnittlig belastning
opentcp (åpne TCP-lyttekontakter - vil varsle hvis noe startet eller krasjet)
oppetid - bare oppetid på serveren. Vil varsle hvis den har endret seg (dvs. serveren har overbelastet)
klient_ip
dirsize - vi bruker den til å spore når rotfsene våre for virtuelle maskiner overskrider den tillatte størrelsen, uten å innføre strenge restriksjoner, og størrelsen på brukerhjemmekataloger
tomme og ikke tomme - overvåk filer som skal være tomme (eller ikke tomme). For eksempel skal feilloggen til selve okerr-serveren være tom, og hvis det til og med er en linje i den, vil jeg motta et varsel og sjekke det. Men mail.log på mailserveren skal IKKE være tom (N minutter etter rotasjon). Og noen ganger var det tomt for oss etter en systemoppdatering, når logrotate ikke kunne starte rsyslog på nytt på riktig måte.
linecount - antall linjer i filen (som wc -l). Vi bruker den som en mykere erstatning for tomme, når feilloggen fortsatt kan vokse, men bare sakte (for eksempel treffer Googlebot noen lukkede sider). Det er en grense på 2 linjer på 20 minutter. Hvis det er høyere, vil det være et varsel

Interessante interne kontroller

Hvis du har lest "diagonalt" frem til dette punktet, vil det nå være mer interessant å lese mer nøye.

sikkerhetskopier

Overvåker sikkerhetskopier i katalogen. Sikkerhetskopiene våre har navn som "ServerName-20200530.tar.gz". For hver server i okerr opprettes indikatoren ServerName-DATE.tar.gz (den faktiske datoen endres til linjen "DATE"). Selve tilstedeværelsen av en ny sikkerhetskopi og dens størrelse overvåkes også (for eksempel kan den ikke være mindre enn 90 % av den forrige sikkerhetskopien).

Hva må gjøres for at en ny sikkerhetskopi skal begynne å spores etter at vi har begynt å lage den og legge den i denne katalogen? Ingenting! Dette er en veldig praktisk tilnærming når du trenger å gjøre "ingenting" fordi:

Å gjøre "ingenting" er ganske raskt, det sparer tid
Det er vanskelig å glemme å gjøre "ingenting"
Det er vanskelig å gjøre "ingenting" galt, med en feil. Ingenting er den mest pålitelige metoden

Hvis nye sikkerhetskopifiler plutselig slutter å vises, vil det komme et varsel. Hvis du for eksempel har deaktivert en av serverne, og det ikke skulle være flere sikkerhetskopier, må du slette indikatoren (via nettgrensesnittet eller fra skallet via API).

maxfilesz

Holder styr på størrelsen på de største filene (vanligvis: /var/log/*). Dette lar deg fange opp uforutsigbare problemer, for eksempel brute force-passord eller sending av spam gjennom serveren.

runstatus/runline

Dette er to viktige proxy-moduler for å kjøre andre programmer på serveren. Runstatus rapporterer programavslutningskoden til indikatoren. For eksempel, okerr (krever) ikke en modul for å sjekke at systemd-tjenester kjører. Dette gjøres via runstatus (se nedenfor). Runline - rapporterer til serveren linjen som programmet produserer. For eksempel, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" i Runline-konfigurasjonen på serveren vår oppretter en indikator servernavn:temp med prosessortemperaturen.

sql

Utfører en numerisk spørring til MySQL og rapporterer resultatet til indikatoren. I et enkelt tilfelle kan du for eksempel gjøre "SELECT 1" - dette vil sjekke at DBMS som helhet fungerer.

Men en mye mer interessant applikasjon er for eksempel å spore antall bestillinger i en nettbutikk. Hvis du vet at du har 100 eller flere bestillinger i timen, kan du sette minimumsgrensen til 100 eller 80. Hvis salget ditt plutselig faller, vil du motta et varsel og du kan finne ut av det.

Merk at det ikke spiller noen rolle av hvilken uforutsigbar grunn dette skjedde:

Serveren er ganske enkelt utilgjengelig (strømløs eller uten nettverk), og varselet kom fra det faktum at indikatoren var "råtten".
Serveren er overbelastet med noe, den fungerer sakte eller pakker går tapt, det er upraktisk for brukere og de drar uten å foreta kjøp
Serveren er inkludert i spamlistene og e-post fra den godtas ikke, brukere kan ikke registrere seg
Budsjettet for annonsekampanjen har gått tom, bannerne snurrer ikke.

Det kan være en rekke årsaker, og alle kan ikke forutses på forhånd, og det er teknisk vanskelig å spore. Men du kan enkelt overvåke den endelige parameteren (ordre) og avgjøre fra dem at situasjonen er mistenkelig og fortjener å bli behandlet.

Logiske indikatorer

Tillater bruk av boolske uttrykk (Python-syntaks) via en modul validere(artikkel om Habré). Data fra prosjektet og dets indikatorer er tilgjengelige for uttrykk. For eksempel, i kapittelet om SQL-sjekking ovenfor, har du kanskje lagt merke til et svakt punkt - på dagtid kan vi ha 100 salg i timen, men om natten - 20, og dette er vanlig, ikke et problem. Hva burde jeg gjøre? Indikatoren vil konstant få panikk om natten.

Du kan lage to indikatorer, dag og natt. Gjør begge "stille" (de vil ikke sende varsler). Og lag en logisk indikator som krever at dagindikatoren er OK før 20:00, og etter 20:00 er det nok til at nattindikatoren er OK.

Et annet eksempel på bruk av en logisk indikator er eskalering. For eksempel avmelder en prosjektleder seg fra varsler (han har ikke behov for å gjøre dette, administratorer bør svare på vanlige problemer), men abonnerer på en logisk indikator som blir rød hvis en indikator i prosjektet ikke blir rettet innen den tildelte tiden.

Det er også mulig å stille inn tillatt tid for arbeid, for eksempel fra 3 til 5 om morgenen. Vi bryr oss ikke om servere og nettsteder krasjer i løpet av denne tiden. Men klokken 5 må de jobbe. Hvis de ikke fungerer på noe annet tidspunkt - varsle. Den logiske indikatoren lar deg også ta hensyn til serverredundans. Hvis du har 00 webservere, kan administratorer slå av 5-1 servere når som helst. Men hvis det er mindre enn 2 av 3 servere i kamp, vil det være et varsel.

Eksemplene ovenfor er ikke oke funksjoner, ikke noen funksjoner som må aktiveres og konfigureres. Okerra har ikke alle disse funksjonene, men det er en logisk modul som lar deg implementere denne funksjonaliteten (Omtrent som i et programmeringsspråk - hvis vi har aritmetiske operatorer, trenger vi ikke en spesiell funksjon for å beregne 20% mva. fra språket, kan du alltid gjøre det selv slik at det passer dine behov).

Logic Indicator er sannsynligvis et av få relativt komplekse emner i okerr, men den gode nyheten er at du ikke trenger å mestre det før du trenger det. Men samtidig utvider de mulighetene kraftig, samtidig som de holder selve systemet ganske enkelt.

Legger til dine egne sjekker

Jeg vil veldig gjerne formidle ideen om at okerr ikke er et sett med tusenvis av ferdige sjekker for alle anledninger, men tvert imot – først og fremst – en enkel motor med en enkel mulighet til å lage dine egne sjekker. Å lage dine egne sjekker i okerr er ikke en oppgave for hackere, systemutviklere eller i det minste avanserte okerr-brukere, men en gjennomførbar oppgave for enhver administrator som installerte Linux for første gang for en måned siden.

Kontroll av minstelønn gjøres gjennom modulen kjørestatus:

Denne linjen i konfigurasjonen kjørestatus vil varsle deg hvis /bin/true plutselig ikke starter eller returnerer noe annet enn 0.

true_OK=/bin/true

Bare en linje - og her er vi allerede litt utvidet funksjonalitet okerr.

Selv en slik sjekk har allerede sin verdi: hvis serveren din plutselig krasjer, vil den tilsvarende indikatoren på okerr-serveren ikke bli oppdatert i tide, og etter at tiden har gått, vises et varsel.

Denne sjekken vil varsle at apache2-serveren har krasjet (vel, du vet aldri...):

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

Så hvis du snakker et hvilket som helst programmeringsspråk, og i det minste kan skrive shell-skript, kan du allerede legge til dine egne sjekker.

Vanskeligere - du kan skrive (på hvilket som helst språk) din egen modul for okerrmod. I det enkleste tilfellet ser det slik ut:

#!/usr/bin/python3

print("STATUS: OK")

Er det ikke veldig vanskelig? Modulen må gjøre kontrollen selv og sende ut resultatene til STDOUT. En mer kompleks modul gir 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 oppdaterer flere indikatorer på en gang (atskilt med en tom linje), oppretter dem om nødvendig, indikerer bekreftelsesdetaljer og en kode som det er lett å finne de nødvendige indikatorene med i dashbordet.

Det er en Telegram-bot @OkerrBot. Du trenger ikke fylle telefonen med separate applikasjoner (jeg liker ikke at for Pyaterochka trenger du en applikasjon med et kart, for Lenta en annen, for MTS en tredje, og så videre for alle, alle, alle). Ett telegram er nok. Gjennom telegram kan du umiddelbart motta varsler, sjekke statusen til prosjektet og gi en kommando for å sjekke alle problematiske indikatorer på nytt. Vi forlot teatret/flyet, holdt ikke fingeren på pulsen på to timer, slo på telefonen, trykket på en knapp i chatboten og sørget for at alt var bra.

Statussider

I dag er statussider nesten et must for enhver virksomhet som har IT, en ansvarlig holdning til pålitelighet og som behandler sine kunder/brukere med respekt.

Se for deg en situasjon - en bruker vil gjøre noe, se informasjon eller legge inn en bestilling, og noe fungerer ikke. Han vet ikke hva som skjer, på hvem sin side problemet er og når det vil bli løst. Kanskje din bedrift rett og slett har en ikke-funksjonell nettside? Eller gikk den i stykker for seks måneder siden, og den vil bli fikset om to år? Men du må kjøpe et kjøleskap nå, det ligger allerede i handlekurven... Og det er en helt annen sak når en person ser at noe er galt med deg (det er i hvert fall tydelig at problemet ikke er på hans side), at problemet har blitt oppdaget, at du allerede jobber med det, og kanskje til og med skrev ned den omtrentlige tiden for korrigering. Brukeren kan abonnere og motta et e-postvarsel når problemet er løst og han kan gjøre det han vil (kjøpe et kjøleskap).

Problemer og nedetid skjer for alle. Men brukere og partnere stoler mer på de som er mer transparente og ansvarlige i sin tilnærming til dette.

Her gjennomgang av 10 andre prosjekter som lar deg lage statussider. Her er eksempler på hvordan disse prosjektsidene ser ut Python и dropbox. okerr statusside.

Failover

For ikke å gjøre denne artikkelen enda lengre, vil jeg nok en gang referere til min forrige artikkel - Enkel failover for et nettsted . Hvis du kan lage en duplikatserver, og deretter bruke failover, vil du i utgangspunktet ikke ha lang nedetid - så snart et problem oppdages, vil brukere automatisk bli omdirigert til en fungerende backupserver. Og det virker for meg som om dette er en veldig interessant, lys funksjon som sjelden er tilgjengelig hvor som helst.

Lave systemkrav

For okerr servere bruker vi maskiner med RAM fra 2Gb. For nettverkssensorer er til og med 512Mb nok. Klientdelen er generelt nesten null. (Plastpose okerrupdate veier 26 Kb, men krever Python3 og standardbiblioteker). Klienten kjører fra et cron-skript, så den har null vedvarende minneforbruk. Blant maskinene vi overvåket har vi sensorer (superbillig VPS med 512Mb RAM) og en Raspberry Pi. Det er mulig selv uten klientdelen send oppdateringer via curl! (se nedenfor)

Tar dette i betraktning - okerr, sannsynligvis mest gratis overvåkingssystem fra de tilgjengelige, fordi selv for å bruke et annet gratis åpen kildekodesystem som Zabbix eller Nagios, må du allokere ressurser (server) til det, og dette er allerede penger. I tillegg er noe servervedlikehold fortsatt nødvendig. Med okerr kan denne delen fjernes. Eller du trenger ikke å fjerne den og bruke din egen server, avhengig av hva du liker best.

API og integrasjon i proprietær programvare

Enkel og åpen arkitektur. okerr har en ganske enkel en API, som er lett å jobbe med. Trenger du å lage 1000 indikatorer? Ett shell-script på 3-4 linjer vil gjøre dette. Trenger du å rekonfigurere 1000 indikatorer? Det er også veldig enkelt. For eksempel ønsker vi å dobbeltsjekke alle våre HTTPS-sertifikater 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 oppdatere indikatoren ved å bruke vår klientmodul, selv uten den, bare 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 oppdatere indikatorer direkte fra programmet. For eksempel å sende hjerteslagsignaler slik at okerr vet at den kjører og slår alarm hvis den krasjer eller fryser. Forresten, okerr-komponenter gjør nettopp det - okerr overvåker seg selv, og problemer i nesten alle moduler vil bli oppdaget og generere et varsel om problemet. (Og i tilfelle dette "nesten" - krysssjekkes de fra en annen server)

Her er koden (forenklet) 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 er et bibliotek for oppdatering av indikatorer fra Python-programmer okerrupdate, for alle andre språk er det ingen biblioteker, men du kan enten kalle opp okerrupdate-skriptet eller lage en HTTP-forespørsel til okerr-serveren.

Hvordan okerr hjelper oss

Okerr forandret livene våre. Faktisk. Kanskje et annet overvåkingssystem kan gjøre det samme, men å jobbe med okerr er enkelt og enkelt for oss, og det har alle funksjonene vi trengte (vi la til det det ikke hadde). Forresten, hvis det mangler noen funksjoner, spør og jeg vil legge dem til (jeg lover ikke, men jeg vil at okerr skal være det beste overvåkingssystemet for små og mellomstore prosjekter). Eller enda bedre, legg det til selv – det er enkelt.

Vi klarte å leve etter prinsippet "lær om alle problemer fra kerraen." Hvis det plutselig oppstår et problem som vi ikke har lært om fra okerr, legger vi en sjekk til okerr. (i dette tilfellet, med "vi" mener jeg oss som brukere av systemet, ikke medutviklere). Først var dette vanlig, men nå har det blitt svært sjeldent.

overvåking

Gjennom okerr overvåker vi loggstørrelsene på alle servere. Det er selvfølgelig umulig å nøye lese hver linje i loggen med øynene, men bare å overvåke veksthastigheten gir allerede mye. Gjennom dette oppdaget vi spam-e-post og brute force-passordsøk, og når noen av applikasjonene «går gale», fungerer noe ikke for dem, og de gjentar det igjen og igjen (hver gang de legger til et par linjer i loggen ).

SSL-sertifikater. Nesten umiddelbart etter lansering La oss kryptere vår kunde begynte å tilby gratis SSL-sertifikater til sine kunder (omtrent tusen av dem). Og det viste seg bare å være et helvete for administrasjonen! Faktum er at nettsteder er "live", klienter ber dem med jevne mellomrom om å gjøre noe, programmerere gjør det. De kan helt fritt overføre siden til en annen DocumentRoot, for eksempel. Eller legg til en ubetinget omskriving til virtualhost-konfigurasjonen. Naturligvis, etter dette, bryter den automatiske fornyelsen av sertifikater sammen. Nå har vi alle SSL-verter lagt til okerr automatisk gjennom et annet av våre nyttige verktøy fra pakken a2conf. La oss bare starte a2okerr.py — og hvis flere nye nettsteder dukker opp på serveren, vil de automatisk vises i okerr. Hvis sertifikatet plutselig av en eller annen grunn ikke blir fornyet, tre uker før sertifikatet utløper, er vi orientert, og vi vil finne ut hvorfor det ikke er oppdatert, en slik hund. a2certbot.py fra samme pakke - det hjelper mye med dette (det sjekker umiddelbart de mest sannsynlige problemene - og skriver det som ble sjekket godt, og hvor det mest sannsynlig er et problem).

Vi overvåker utløpsdatoen for alle våre domener. Og alle våre e-postservere som sender e-post blir også sjekket mot 50+ forskjellige svartelister. (Og noen ganger faller de inn i dem). Visste du forresten at Googles e-postservere også er svartelistet? Bare for selvtesting la vi mail-wr1-f54.google.com til de overvåkede serverne, og den er fortsatt på SORBS-svartelisten! (Dette handler om verdien av "anti-spammere")

Sikkerhetskopier - jeg har allerede skrevet ovenfor hvor enkelt det er å overvåke dem med okerr. Men vi overvåker både de siste sikkerhetskopiene på serveren vår og (ved hjelp av et eget verktøy som bruker okerr) sikkerhetskopiene som vi laster opp til Amazon Glacier. Og, ja, problemer oppstår fra tid til annen. Ikke rart de så på.

Vi bruker eskaleringsindikatoren. Den viser om et eller annet problem ikke har blitt løst på lenge. Og jeg selv, når jeg løser noen problemer, kan jeg noen ganger glemme dem. Eskalering er en god påminnelse, selv om du overvåker deg selv.

Samlet sett tror jeg at kvaliteten på arbeidet vårt har økt med en størrelsesorden. Det er nesten ingen nedetid (eller klienten har ikke tid til å legge merke til det. Bare shh!), mens arbeidsmengden har blitt mindre og arbeidsforholdene har blitt roligere. Vi har gått fra akuttarbeid med lapping av hull med tape til rolig og avmålt arbeid, når mange problemer er spådd på forhånd og det er tid til å forebygge. Selv problemer som har skjedd har også blitt lettere å fikse: For det første finner vi ut om dem før kundene får panikk, og for det andre skjer det ofte at problemet er relatert til nylig arbeid (mens jeg gjorde en ting, knuste jeg en annen) - så det er varmt Det er lettere for spor å håndtere det.

Men det var en annen sak...

Visste du at i den populære Debian 9 (Stretch) er en så populær pakke som phpmyadmin fortsatt (i mange måneder!) i sårbar status? (CVE-2019-6798). Da sårbarheten dukket opp, dekket vi det raskt på forskjellige måter. Men jeg satte opp overvåking av sikkerhetssporingssiden i okerr for å vite når en "vakker" løsning vil komme ut (via SHA1-summen av innholdet). Indikatoren rykket meg flere ganger, siden endret seg, men som du kan se, tyder den fortsatt (siden januar 2019!) ikke på at problemet er løst. Kanskje er det forresten noen som vet hva problemet er at en så viktig pakke fortsatt er sårbar i mer enn ett år?

En annen gang i en lignende situasjon: etter en sårbarhet i SSH var det nødvendig å oppdatere alle servere. Og når du angir en oppgave, må du kontrollere utførelsen. (Underordnede har en tendens til å misforstå, glemme, bli forvirret og gjøre feil). Derfor la vi først til en SSH-versjonssjekk til okerr på alle servere, og gjennom okerr sørget vi for at oppdateringer ble rullet ut på alle servere. (Praktisk! Jeg valgte denne typen indikator, og du kan umiddelbart se hvilken server som har hvilken versjon). Da vi var sikre på at oppgaven var fullført på alle servere, fjernet vi indikatorene.

Et par ganger var det en situasjon hvor et visst problem oppstår, og så går det over av seg selv. (sannsynligvis kjent for alle?). Når du legger merke til det, når du sjekker – og det er ingenting å sjekke – fungerer alt allerede bra. Men så ryker det igjen. Dette skjedde for eksempel med produkter som vi lastet opp til Amazon Marketplace (MWS). På et tidspunkt var det innlastede varelageret feil (feil varemengde og feil priser). Vi fant det ut. Men for å finne ut av det, var det viktig å finne ut av problemet med en gang. Dessverre er MWS, som alle Amazon-tjenester, litt treg, så det var alltid en forsinkelse, men likevel klarte vi i det minste omtrent å forstå sammenhengen mellom problemet og skriptene som forårsaker det (vi gjorde en sjekk, fast den til okerren, og sjekket den umiddelbart og mottok et varsel).

En interessant sak ble nylig lagt til samlingen av en stor og kostbar europeisk hoster, som vår kunde bruker. Plutselig forsvant ALLE serverne våre fra radaren! Først la kunden selv (raskere enn okerra!) merke til at siden han jobbet med ikke åpnet og laget en billett om det. Men ikke bare ett nettsted gikk ned, men alle sammen! (Natasha, vi droppet alt!). Her begynte Okerr å sende lange fotinnpakninger med alle indikatorene som lyste opp for ham. Panikk, panikk, vi løper i sirkler (hva annet kan vi gjøre?). Så steg alt. Det viser seg at det var rutinemessig vedlikehold i datasenteret (en gang hvert mange år), og vi burde selvfølgelig ha blitt advart. Men et slags problem skjedde med dem, og de advarte oss ikke. Vel, flere hjerteinfarkt, mindre hjerteinfarkt. Men etter at alt er gjenopprettet, må du dobbeltsjekke alt! Jeg kan ikke forestille meg hvordan jeg skulle gjøre det med hendene mine. Okerr testet alt på noen få minutter. Det viste seg at de fleste serverne rett og slett var midlertidig utilgjengelige, men de fungerte. Noen ble overbelastet, men sto også opp som de skulle. Av alle tapene mistet vi to sikkerhetskopier, som ifølge kronen skulle ha blitt opprettet og lastet mens denne fulle bananen pågikk. Jeg gadd ikke engang å lage dem, bare en dag senere kom varsler om at alt var OK, sikkerhetskopier hadde dukket opp. Jeg liker veldig godt dette eksemplet fordi okerr viste seg å være veldig nyttig i en situasjon som vi ikke engang hadde tenkt på på forhånd, men det er hensikten med overvåking - å motstå det uforutsigbare.

For Okerr-sensorer bruker vi billigst mulig hosting (der kvalitet og pålitelighet ikke er viktig, forsikrer de hverandre). Så vi har nylig funnet en veldig god hosting og superbillig, referansene er fantastiske. Men... noen ganger viser det seg at utgående tilkoblinger fra den virtuelle maskinen lages fra en annen (nabo) IP. Mirakler. Client_ip-modul med https://diagnostic.opendns.com/myip får feil IP. Og fra serverloggene til indikatoren er det klart at oppdateringen også kom fra denne nabo-IP. La oss håndtere støtten nå. Det er bra at vi la merke til dette i fredstid. Men for eksempel hender det ofte at tilgang registreres i henhold til IP-hvitelisten – og hvis serveren noen ganger blinker slik i kort tid – kan du prøve å fange opp dette problemet i svært lang tid.

Vel, en ting til – siden vi snakker om VPS-hosting – bruker vi alltid rimelige (hetzner, ovh, scaleway). Jeg liker det veldig godt både når det gjelder benchmarks og stabilitet. Vi bruker også den mye dyrere Amazon EC2 til andre prosjekter. Så takket være okerr har vi vår egen informerte mening. De faller begge. Og jeg vil ikke si at i løpet av den lange perioden av våre observasjoner, viste billige hostinger som hetzner seg å være merkbart mindre stabile enn EC2. Derfor, hvis du ikke er bundet til andre Amazon-funksjoner, hvorfor betale mer? 🙂

Hva blir det neste?

Hvis jeg på dette stadiet ikke har skremt deg vekk fra Okerr ennå, så prøv det! Du kan gå direkte til denne linken okerr demokonto (Klikk nå!) Men husk at det bare er én demokonto for alle, så hvis du gjør noe, kan noen andre på samme konto forstyrre deg samtidig. Eller (bedre) registrer deg via lenken til offsite okerr - alt er enkelt, uten SMS. Hvis du ikke liker å bruke den ekte e-posten din, kan du bruke en engangs, som mailinator (jeg anbefaler getnada.com). Slike kontoer kan bli slettet over tid, men de vil være fine for testing.

Etter registrering vil du bli bedt om å gjennomgå opplæring (utføre flere ikke veldig vanskelige treningsoppgaver). De første grensene er svært små, men for trening eller én server er de nok. Etter å ha fullført opplæringen vil grensene (for eksempel maksimalt antall indikatorer) økes.

Fra dokumentasjonen - først og fremst WIKI på serversiden og på klienten (okerrupdate wiki). Men hvis noe er uklart, skriv til support (at) okerr.com eller legg igjen en billett - vi vil prøve å løse alt raskt.

Hvis du bruker det seriøst og disse økte grensene ikke er nok, skriv til support, så øker vi det (gratis).

Vil du installere okerr-serveren på serveren din? Her okerr-dev repository. Vi anbefaler å installere på en ren virtuell maskin, så kan du ganske enkelt gjøre det med et installasjonsskript. På din virtuelle maskin - ingen begrensninger :-). Vel, igjen, hvis noe skjer, vil vi alltid prøve å hjelpe.

Vi ønsker at dette prosjektet skal ta av, slik at verden blir mer pålitelig takket være oss. Takket være gratis programvare og tjenester har verden blitt vennligere og utvikler seg mer dynamisk. Kildene kan lagres i gratis github, og for post kan du bruke gratis gmail. Vi bruker gratis freshworks for støtte. For noe av dette trenger du ikke å betale for servere, du trenger ikke å laste ned og konfigurere, og du trenger ikke å løse ulike driftsproblemer. Hvert nytt prosjekt, hvert team har umiddelbart post, repositories og CRM. Og alt dette er av veldig høy kvalitet og gratis og umiddelbart. Vi ønsker at det skal være det samme for overvåking - små selskaper og prosjekter kan bruke okerr gratis, og selv på fødsels- og vekststadiet har påliteligheten til seriøse voksne prosjekter.

Kilde: www.habr.com

Oversikt over Okerr hybrid overvåkingssystem