Panoramica del sistema di monitoraggio ibrido Okerr

Due anni fa avevo già scritto un post Failover semplice per un sito Web circa okerr. Ora c'è qualche sviluppo del progetto e ho anche pubblicato codice sorgente lato server di okerr sotto licenza aperta, ecco perché ho deciso di scrivere questa breve recensione su Habr.

Panoramica del sistema di monitoraggio ibrido Okerr
[ dimensione piena ]

A chi può interessare

Questo potrebbe interessarti se lavori in una piccola squadra o da solo. Non hai il monitoraggio e non sei sicuro di averne davvero bisogno. O hai provato qualche popolare monitoraggio serio "per i grandi", ma in qualche modo "non è decollato" per te, oppure funziona in una configurazione quasi predefinita e non ti ha cambiato molto la vita. E anche - se sicuramente non prevedi di assegnare un intero dipendente (o anche un dipartimento) per monitorare la dashboard di monitoraggio almeno un paio d'ore al giorno o configurarla.

Perché okerr è insolito

Successivamente mostrerò le caratteristiche interessanti dell'okerra che lo distinguono da altri sistemi di monitoraggio.

Okerr è un monitoraggio ibrido

Durante il monitoraggio interno, sulle macchine monitorate è in esecuzione un "agente" che trasmette i dati al server di monitoraggio (ad esempio, spazio libero su disco). Quando è esterno, il server esegue controlli sulla rete (ad esempio, ping o disponibilità del sito web). Ogni approccio ha i suoi limiti. Okerr utilizza entrambe le opzioni. I controlli all'interno dei server vengono eseguiti da un agente molto leggero (30 KB) o da script e applicazioni personalizzati, mentre i controlli di rete vengono eseguiti tramite sensori okerr in diversi paesi.

okerr non è solo un software, ma anche un servizio

La parte server di qualsiasi monitoraggio è ampia e complessa, difficile da installare e configurare e richiede risorse. Con okerr puoi installare il tuo server di monitoraggio (è gratuito e opensource), oppure puoi semplicemente utilizzare solo la parte client e utilizzare il servizio del nostro server. Anche gratuito.

Se il monitoraggio consente di compensare e coprire la mancanza di affidabilità di server e applicazioni, allora sorge una domanda filosofica: chi è la guardia? In che modo il monitoraggio ci indicherà un problema se esso stesso "morì" per qualche motivo, separatamente o insieme alle altre risorse (ad esempio, il canale al data center è caduto)? Quando utilizzi il servizio esterno okerr - questo problema è risolto - riceverai un avviso anche se l'intero data center con i tuoi server è senza alimentazione o viene attaccato da zombie.

Naturalmente, c'è il rischio che il server okerr stesso non sia disponibile, questo è vero (come sapete, il 90% dell'affidabilità si ottiene sempre in modo semplice e “gratuito”, il 99% con il minimo sforzo, e ogni nove successivi è esponenzialmente più difficile). Ma, in primo luogo, le probabilità che ciò accada sono inferiori e, in secondo luogo, il problema può passare inosservato solo se coincide con problemi sui nostri server. Se abbiamo un'affidabilità del 99.9% e tu hai il 99.9% (numeri non troppo alti), la possibilità di un guasto non rilevato è 0.1% di 0.1% = 0.0001%. Aggiungere tre nove alla tua affidabilità quasi senza sforzo e senza costi è molto positivo!

Un altro vantaggio del monitoraggio come servizio è che un provider di hosting o uno studio web può installare un server okerr e fornire l'accesso ai clienti come servizio aggiuntivo a pagamento o gratuito. I tuoi concorrenti hanno solo hosting e siti Web, ma tu disponi di un hosting affidabile con monitoraggio.

Okerr riguarda gli indicatori

L'indicatore è una “lampadina”. Ha due stati principali: verde (OK) o rosso (ERR). Il progetto contiene molti indicatori raggruppati (ad esempio, per server). Nella pagina principale del progetto, vedi immediatamente che o tutto è verde (e puoi chiuderlo), oppure qualcosa è illuminato in rosso e deve essere corretto. Durante la transizione tra questi stati, viene inviato un avviso. Una volta al giorno durante la configurazione, viene inviato un riepilogo del progetto.

Panoramica del sistema di monitoraggio ibrido Okerr

Ogni indicatore okerr ha condizioni integrate in base alle quali cambia stato (in Zabbix questo è chiamato trigger). Ad esempio, il carico medio non dovrebbe essere superiore a 2 (ovviamente è configurabile). E per ogni controllo interno (carico medio, spazio libero sul disco, ...) c'è un watchdog. Se per qualche motivo non riceviamo una conferma di successo all'ora stabilita, viene registrato un errore e viene inviato un avviso.

Il nostro normale schema di lavoro prevede di controllare le e-mail al mattino e di guardare il riepilogo tra le altre lettere (lo pianifichiamo all'inizio del lavoro). Se tutto va bene, facciamo altre cose importanti (ma per sicurezza, possiamo dare un'occhiata veloce alla dashboard di okerra e assicurarci che sia tutto verde in questo momento). Se arriva un avviso, reagiamo.

Certo, è possibile mantenere semplicemente degli indicatori “informativi” (per vedere il quadro della rete da monitorare), ma tutto viene fatto per creare in modo semplice, facile e veloce indicatori specifici per il monitoraggio automatico e l'invio di alert.

Lo scopo per cui stai configurando okerr è negli avvisi, in modo da poter creare un indicatore in un minuto, potrebbe "dormire" per un anno, accettare solo aggiornamenti e quando un anno dopo qualcosa si rompe, si accende e invia un avviso. Il minuto che hai dedicato alla creazione di un indicatore ha dato i suoi frutti: hai scoperto il problema immediatamente, prima di chiunque altro. È possibile che l'abbiano riparato prima che qualcuno se ne accorgesse. Qualcosa che si solleva velocemente non è considerato caduto!

sicurezza

Sarebbe un peccato se impostassi il monitoraggio per aumentare l'affidabilità, ma di conseguenza verrai attaccato sulla rete attraverso di esso e ci sono molte vulnerabilità di rete in diversi strumenti di monitoraggio (Zabbix, Nagios).

Agente (okerrmod dal pacchetto okerrupdate) in esecuzione sul sistema non è un server di rete, ma un client. Pertanto non ci sono porte aperte aggiuntive sul server monitorato, il client funziona facilmente dietro un firewall o NAT ed è molto difficile (direi “impossibile”) hackerare la rete, poiché in linea di principio non ascolta la rete PRESA.

Copertura di monitoraggio completa

Ora la nostra regola è che veniamo informati su tutti i problemi tecnici da okerr. Se all'improvviso la regola viene violata (okerr non ha avvisato del suo imminente verificarsi (se ciò è possibile) o che si è già verificato), aggiungiamo controlli a okerr.

Controlli esterni

Un insieme abbastanza tipico:

  • ping
  • stato http
  • verificando la validità e l'aggiornamento del certificato SSL (avviserà se sta per scadere)
  • aprire la porta TCP e il banner su di essa
  • http grep (la pagina [non deve] contenere determinato testo)
  • sha1 hash per catturare le modifiche alla pagina.
  • DNS (il record DNS deve avere un valore specifico)
  • WHOIS (avviserà se il dominio sta per deteriorarsi)
  • DNSBL antispam (controllo dell'host contro oltre 50 liste nere antispam contemporaneamente)

Verifiche interne

Inoltre, un set abbastanza standard (ma facilmente espandibile).

  • df (spazio libero su disco)
  • carico medio
  • opentcp (socket di ascolto TCP aperti - avviserà se qualcosa è iniziato o si è bloccato)
  • uptime: solo uptime sul server. Avviserà se è cambiato (cioè il server è sovraccarico)
  • ip_cliente
  • dirsize: lo utilizziamo per monitorare quando i rootf della nostra macchina virtuale superano la dimensione consentita, senza introdurre restrizioni rigide, e la dimensione delle directory home dell'utente
  • vuoto e non vuoto: monitora i file che dovrebbero essere vuoti (o non vuoti). Ad esempio, il registro degli errori del server okerr stesso dovrebbe essere vuoto e, se contiene anche solo una riga, riceverò una notifica e la controllerò. Ma mail.log sul server di posta NON deve essere vuoto (N minuti dopo la rotazione). E a volte era vuoto per noi dopo un aggiornamento del sistema, quando logrotate non riusciva a riavviare correttamente rsyslog.
  • linecount - numero di righe nel file (come wc -l). Lo utilizziamo come sostituto più morbido di vuoto, quando il registro degli errori può ancora crescere, ma solo lentamente (ad esempio, Googlebot raggiunge alcune pagine chiuse). C'è un limite di 2 linee in 20 minuti. Se è più alto, verrà visualizzato un avviso

Controlli interni interessanti

Se fino a questo punto hai letto “in diagonale”, ora sarà più interessante leggere con più attenzione.

backup

Monitora i backup nella directory. I nostri file di backup hanno nomi come "ServerName-20200530.tar.gz". Per ogni server in okerr viene creato l'indicatore ServerName-DATE.tar.gz (la data effettiva cambia nella riga "DATE"). Viene monitorata anche la presenza stessa di un nuovo backup e la sua dimensione (ad esempio, non può essere inferiore al 90% del backup precedente).

Cosa è necessario fare affinché un nuovo backup inizi a essere tracciato dopo aver iniziato a crearlo e inserirlo in questa directory? Niente! Questo è un approccio molto conveniente quando non devi fare “niente” perché:

  • Non fare “niente” è piuttosto veloce, fa risparmiare tempo
  • È difficile dimenticare di non fare “niente”
  • È difficile non fare “niente” di male, con un errore. Niente è il metodo più affidabile

Se improvvisamente i nuovi file di backup smettono di apparire, verrà visualizzato un avviso. Se, ad esempio, hai disabilitato uno dei server, e non dovessero esserci più backup, dovrai eliminare l'indicatore (tramite l'interfaccia web o dalla shell tramite API).

maxfilesz

Tiene traccia della dimensione dei file più grandi (tipicamente: /var/log/*). Ciò consente di individuare problemi imprevedibili, ad esempio password di forza bruta o invio di spam attraverso il server.

statoesecuzione/linea di esecuzione

Questi sono due importanti moduli proxy per l'esecuzione di altri programmi sul server. Runstatus segnala il codice di uscita del programma all'indicatore. Ad esempio, okerr non richiede (richiede) un modulo per verificare che i servizi systemd siano in esecuzione. Questo viene fatto tramite runstatus (vedi sotto). Runline: segnala al server la riga prodotta dal programma. Per esempio, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" nella configurazione Runline sul nostro server crea un indicatore nomeserver:temp con la temperatura del processore.

sql

Esegue una query numerica su MySQL e segnala il risultato all'indicatore. In un caso semplice, puoi fare, ad esempio, "SELECT 1": questo controllerà che il DBMS nel suo insieme funzioni.

Ma un'applicazione molto più interessante è, ad esempio, il monitoraggio del numero di ordini in un negozio online. Se sai di avere 100 o più ordini all'ora, puoi impostare il limite minimo su 100 o 80. Quindi, se le tue vendite diminuiscono improvvisamente, riceverai un avviso e potrai capirlo.

Tieni presente che non importa per quale motivo imprevedibile ciò sia accaduto:

  • Il server semplicemente non è disponibile (disalimentato o senza rete) e l'avviso deriva dal fatto che l'indicatore era "marcio".
  • Il server è sovraccarico di qualcosa, funziona lentamente o si perdono i pacchetti, è scomodo per gli utenti che se ne vanno senza fare acquisti
  • Il server è incluso negli elenchi di spam e la posta da esso non viene accettata, gli utenti non possono registrarsi
  • Il budget della campagna pubblicitaria è esaurito, i banner non girano.

Le ragioni possono essere molteplici e non tutte possono essere previste in anticipo ed è tecnicamente difficile tracciarle. Ma puoi monitorare comodamente i parametri finali (ordini) e determinare da essi che la situazione è sospetta e merita di essere affrontata.

Indicatori logici

Consente l'uso di espressioni booleane (sintassi Python) tramite un modulo validare(articolo su Habré). I dati del progetto e i suoi indicatori sono disponibili per l'espressione. Ad esempio, nel capitolo precedente sul controllo SQL, potresti aver notato un punto debole: durante il giorno possiamo avere 100 vendite all'ora, ma di notte - 20, e questo è comune, non è un problema. Cosa dovrei fare? L'indicatore andrà costantemente nel panico di notte.

Puoi creare due indicatori, giorno e notte. Rendi entrambi “silenziosi” (non invieranno avvisi). E crea un indicatore logico che richieda che l'indicatore del giorno sia OK prima delle 20:00 e dopo le 20:00 è sufficiente che l'indicatore notturno sia OK.

Un altro esempio di utilizzo di un indicatore logico è intensificazione. Ad esempio, un project manager annulla l'iscrizione agli avvisi (non ha bisogno di farlo, gli amministratori dovrebbero rispondere ai normali problemi), ma si iscrive a un indicatore logico che diventa rosso se qualsiasi indicatore nel progetto non viene corretto entro il tempo assegnato.

Inoltre, è possibile impostare l'orario consentito per il lavoro, ad esempio dalle 3 alle 5 del mattino. Non ci interessa se server e siti si bloccano durante questo periodo. Ma alle 5:00 devono lavorare. Se non funzionano in qualsiasi altro momento, avvisa. L'indicatore logico consente inoltre di tenere conto della ridondanza del server. Se disponi di 5 server web, gli amministratori possono disattivare 1-2 server in qualsiasi momento. Ma se ci sono meno di 3 server su 5 in battaglia, verrà visualizzato un avviso.

Gli esempi sopra riportati non riguardano le funzioni di Oker, né alcune funzionalità che devono essere attivate e configurate. Okerra non ha tutte queste funzioni, ma esiste un modulo logico che ti consente di implementare questa funzionalità (approssimativamente come in un linguaggio di programmazione - se abbiamo operatori aritmetici, non abbiamo bisogno di una funzione speciale per il calcolo dell'IVA al 20% dalla lingua, puoi sempre farlo tu stesso adattandolo alle tue esigenze).

L'indicatore logico è probabilmente uno dei pochi argomenti relativamente complessi in okerr, ma la buona notizia è che non è necessario padroneggiarlo finché non è necessario. Ma allo stesso tempo espandono notevolmente le capacità, pur mantenendo il sistema stesso abbastanza semplice.

Aggiunta dei tuoi controlli

Vorrei davvero trasmettere l'idea che okerr non è un insieme di migliaia di assegni già pronti per tutte le occasioni, ma al contrario - prima di tutto - un semplice motore con una semplice possibilità di creare i propri assegni. Creare i propri controlli in okerr non è un compito per hacker, co-sviluppatori di sistema o almeno utenti avanzati di okerr, ma un compito fattibile per qualsiasi amministratore che ha installato Linux per la prima volta un mese fa.

I controlli sui salari minimi vengono effettuati attraverso il modulo runstatus:

Questa riga nel file config runstatus ti avviserà se /bin/true improvvisamente non si avvia o restituisce qualcosa di diverso da 0.

true_OK=/bin/true

Solo una riga - ed eccoci già un po' qui si sono espansi funzionalità okerr.

Anche un controllo del genere ha già il suo valore: se improvvisamente il tuo server si blocca, l'indicatore corrispondente sul server okerr non verrà aggiornato in modo tempestivo e, trascorso il tempo, verrà visualizzato un avviso.

Questo controllo avviserà che il server Apache2 è andato in crash (beh, non si sa mai...):

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

Quindi, se parli un linguaggio di programmazione e almeno sai scrivere script di shell, puoi già aggiungere i tuoi controlli.

Più difficile: puoi scrivere (in qualsiasi lingua) il tuo modulo per okerrmod. Nel caso più semplice assomiglia a questo:

#!/usr/bin/python3

print("STATUS: OK")

Non è molto difficile? Il modulo deve eseguire il controllo stesso e inviare i risultati a STDOUT. Un modulo più complesso fornisce, ad esempio, questo:

$ 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

Aggiorna più indicatori contemporaneamente (separati da una riga vuota), li crea se necessario, indica i dettagli di verifica e un tag grazie al quale è facile trovare gli indicatori necessari nella dashboard.

Telegram

Esiste un bot di Telegram @OkerrBot. Non è necessario ingombrare il telefono con applicazioni separate (non mi piace che per Pyaterochka sia necessaria un'applicazione con una mappa, per Lenta un'altra, per MTS una terza e così via per tutti, tutti, tutti). È sufficiente un telegramma. Tramite Telegram puoi ricevere immediatamente avvisi, verificare lo stato del progetto e dare un comando per ricontrollare tutti gli indicatori problematici. Abbiamo lasciato il teatro/aereo, non abbiamo tenuto il dito sul polso per due ore, abbiamo acceso il telefono, premuto un pulsante nel chatbot e ci siamo assicurati che tutto andasse bene.

Pagine di stato

Al giorno d'oggi, le pagine di stato sono quasi un must per qualsiasi azienda che abbia IT, un atteggiamento responsabile nei confronti dell'affidabilità e che tratti i propri clienti/utenti con rispetto.

Immagina una situazione: un utente vuole fare qualcosa, visualizzare informazioni o effettuare un ordine e qualcosa non funziona. Non sa cosa sta succedendo, da che parte sta il problema e quando verrà risolto. Forse la tua azienda ha semplicemente un sito web non funzionante? Oppure si è rotto sei mesi fa e verrà riparato tra due anni? Ma devi comprare un frigorifero adesso, è già nel carrello... Ed è tutta un'altra cosa quando una persona vede che qualcosa non va in te (almeno è chiaro che il problema non è dalla sua parte), che il hai scoperto il problema, che ci stai già lavorando e forse hai anche annotato il tempo approssimativo per la correzione. L'utente può iscriversi e ricevere una notifica via email quando il problema viene risolto e può fare ciò che desidera (acquistare un frigorifero).

Panoramica del sistema di monitoraggio ibrido Okerr

Problemi e tempi di inattività capitano a tutti. Ma utenti e partner si fidano di più di coloro che sono più trasparenti e responsabili nel loro approccio a questo problema.

Qui revisione di altri 10 progetti che consentono di creare pagine di stato. Ecco alcuni esempi di come appaiono queste pagine di progetto Python и dropbox. pagina di stato di okerr.

failover

Per non rendere questo articolo ancora più lungo, farò ancora riferimento al mio articolo precedente - Failover semplice per un sito Web . Se riesci a creare un server duplicato, quindi utilizzando il failover, sostanzialmente non avrai lunghi tempi di inattività: non appena viene rilevato un problema, gli utenti verranno automaticamente reindirizzati a un server di backup funzionante. E mi sembra che questa sia una funzionalità molto interessante e brillante che raramente è disponibile ovunque.

Bassi requisiti di sistema

Per i server okerr utilizziamo macchine con RAM da 2Gb. Per i sensori di rete bastano anche 512Mb. La parte cliente è generalmente quasi pari a zero. (Sacchetto di plastica okerrupdate pesa 26 Kb, ma richiede Python3 e librerie standard). Il client viene eseguito da uno script cron, quindi ha un consumo di memoria persistente pari a zero. Tra le macchine che abbiamo monitorato abbiamo dei sensori (VPS super economici con 512Mb di RAM) e un Raspberry Pi. È possibile anche senza la parte client inviare aggiornamenti tramite curl! (vedi sotto)

Tenendo conto di questo - okerr, probabilmente più libero sistema di monitoraggio tra quelli disponibili, perché anche per utilizzare un altro sistema open source gratuito come Zabbix o Nagios, è necessario allocargli risorse (server), e questo è già denaro. Inoltre, è ancora necessaria una certa manutenzione del server. Con okerr, questa parte può essere rimossa. Oppure non devi rimuoverlo e utilizzare il tuo server, a seconda di cosa ti piace di più.

API e integrazione in software proprietario

Architettura semplice e aperta. okerr ne ha uno piuttosto semplice API, con cui è facile lavorare. Hai bisogno di creare 1000 indicatori? Uno script di shell di 3-4 righe farà questo. Hai bisogno di riconfigurare 1000 indicatori? È anche molto semplice. Ad esempio, vogliamo ricontrollare tutti i nostri certificati HTTPS da un sensore russo:

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

Puoi aggiornare l'indicatore utilizzando il nostro modulo client, anche senza di esso, solo tramite 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/

Puoi aggiornare gli indicatori direttamente dal tuo programma. Ad esempio, inviando segnali di battito cardiaco in modo che okerr sappia che è in esecuzione e lanci un allarme se si blocca o si blocca. A proposito, i componenti di okerr fanno proprio questo: okerr si automonitora e i problemi in quasi tutti i moduli verranno rilevati e genereranno un avviso sul problema. (E in questo caso "quasi" vengono verificati da un altro server)

Ecco il codice (semplificato) nel nostro bot di Telegram:

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

Esiste una libreria per aggiornare gli indicatori dai programmi Python okerrupdate, per qualsiasi altro linguaggio non ci sono librerie, ma puoi chiamare lo script okerrupdate o fare una richiesta HTTP al server okerr.

In che modo okerr ci aiuta

Okerr ha cambiato le nostre vite. Infatti. Forse un altro sistema di monitoraggio potrebbe fare lo stesso, ma lavorare con okerr per noi è facile e semplice e ha tutte le funzioni di cui avevamo bisogno (abbiamo aggiunto quello che non aveva). A proposito, se mancano alcune funzionalità, chiedi e le aggiungerò (non lo prometto, ma voglio che okerr sia il miglior sistema di monitoraggio per progetti medio-piccoli). O meglio ancora, aggiungilo tu stesso: è facile.

Siamo riusciti a vivere secondo il principio “imparare tutti i problemi dalla Kerra”. Se all'improvviso si verifica un problema che non abbiamo appreso da okerr, aggiungiamo un controllo a okerr. (in questo caso con “noi” intendo noi come utenti del sistema, non come co-sviluppatori). All’inizio era comune, ma ora è diventato molto raro.

Monitoraggio

Attraverso okerr monitoriamo le dimensioni dei log su tutti i server. Ovviamente è impossibile leggere attentamente ogni riga del registro con i tuoi occhi, ma il semplice monitoraggio del tasso di crescita dà già molto. In questo modo, abbiamo scoperto la posta indesiderata e le ricerche di password con forza bruta e quando alcune applicazioni "impazziscono", qualcosa non funziona e lo ripetono ancora e ancora (ogni volta aggiungendo un paio di righe al registro ).

Certificati SSL. Quasi immediatamente dopo il lancio LetsEncrypt il nostro cliente ha iniziato a fornire certificati SSL gratuiti ai propri clienti (circa un migliaio). E si è rivelato un vero inferno per l'amministrazione! Il fatto è che i siti sono “live”, i clienti periodicamente chiedono loro di fare qualcosa, i programmatori lo fanno. Possono trasferire il sito in modo completamente libero, ad esempio, su un altro DocumentRoot. Oppure aggiungi una riscrittura incondizionata alla configurazione dell'host virtuale. Naturalmente, dopodiché il rinnovo automatico dei certificati viene meno. Ora abbiamo tutti gli host SSL aggiunti automaticamente a okerr tramite un'altra delle nostre utili utilità incluse nel pacchetto a2conf. Lanciamoci e basta a2okerr.py - e se sul server compaiono diversi nuovi siti, appariranno automaticamente in okerr. Se all'improvviso per qualche motivo il certificato non viene rinnovato, tre settimane prima della scadenza del certificato, ne siamo al corrente e scopriremo perché non viene aggiornato, un cane del genere. a2certbot.py dallo stesso pacchetto - aiuta molto in questo (controlla immediatamente i problemi più probabili - e scrive cosa è stato controllato bene e dove è più probabile che ci sia un problema).

Monitoriamo la data di scadenza di tutti i nostri domini. Inoltre, tutti i nostri server di posta che inviano posta vengono confrontati con oltre 50 liste nere diverse. (E a volte ci cadono dentro). A proposito, sapevi che anche i server di posta di Google sono nella lista nera? Solo per autotest, abbiamo aggiunto mail-wr1-f54.google.com ai server monitorati ed è ancora nella lista nera di SORBS! (Si tratta del valore degli “anti-spammer”)

Backup: ho già scritto sopra quanto sia facile monitorarli con okerr. Ma monitoriamo sia gli ultimi backup sul nostro server sia (utilizzando un'utilità separata che utilizza okerr) i backup che carichiamo su Amazon Glacier. E sì, i problemi si verificano di tanto in tanto. Non c'è da stupirsi che stessero guardando.

Usiamo l'indicatore di escalation. Mostra se qualche problema non è stato risolto per molto tempo. E io stesso, quando risolvo alcuni problemi, a volte riesco a dimenticarmene. L'escalation è un buon promemoria, anche se stai monitorando te stesso.

Nel complesso, credo che la qualità del nostro lavoro sia aumentata di un ordine di grandezza. Non ci sono quasi tempi di inattività (o il cliente non ha il tempo di accorgersene. Basta shh!), mentre la quantità di lavoro è diminuita e le condizioni di lavoro sono diventate più tranquille. Siamo passati dal lavoro di emergenza, tappando i buchi con il nastro adesivo, al lavoro calmo e misurato, quando molti problemi sono previsti in anticipo e c'è tempo per prevenirli. Anche i problemi che si sono verificati sono diventati più facili da risolvere: in primo luogo, li scopriamo prima che i clienti si facciano prendere dal panico e, in secondo luogo, capita spesso che il problema sia legato al lavoro recente (mentre stavo facendo una cosa, ne ho rotta un'altra) - quindi fa caldo È più facile per le tracce affrontarlo.

Ma c'era un altro caso...

Sapevi che nella popolare Debian 9 (Stretch) un pacchetto così popolare come phpmyadmin è ancora (per molti mesi!) nello stato vulnerabile? (CVE-2019-6798). Quando è emersa la vulnerabilità, l’abbiamo rapidamente coperta in diversi modi. Ma ho impostato il monitoraggio della pagina di monitoraggio della sicurezza in okerr per sapere quando uscirà una soluzione "bella" (tramite la somma SHA1 del contenuto). L'indicatore mi ha scosso più volte, la pagina è cambiata, ma come puoi vedere, ancora (da gennaio 2019!) non indica che il problema è stato risolto. Forse, a proposito, qualcuno sa qual è il problema nel fatto che un pacchetto così importante è ancora vulnerabile per più di un anno?

Un'altra volta in una situazione simile: dopo una vulnerabilità in SSH è stato necessario aggiornare tutti i server. E quando imposti un'attività, devi controllarne l'esecuzione. (I subordinati tendono a fraintendere, dimenticare, confondersi e commettere errori). Pertanto, per prima cosa abbiamo aggiunto un controllo della versione SSH a okerr su tutti i server e, tramite okerr, ci siamo assicurati che gli aggiornamenti fossero implementati su tutti i server. (Comodo! Ho scelto questo tipo di indicatore e puoi vedere immediatamente quale server ha quale versione). Quando siamo stati sicuri che l'attività fosse stata completata su tutti i server, abbiamo rimosso gli indicatori.

Un paio di volte si è verificata una situazione in cui si presenta un certo problema e poi scompare da solo. (probabilmente familiare a tutti?). Quando te ne accorgi, quando controlli, e non c'è niente da controllare, tutto funziona già bene. Ma poi si rompe di nuovo. Ciò è accaduto, ad esempio, con i prodotti che abbiamo caricato su Amazon Marketplace (MWS). Ad un certo punto, l'inventario caricato era errato (quantità errate di merci e prezzi errati). L'abbiamo capito. Ma per capirlo era importante scoprire subito il problema. Purtroppo MWS, come tutti i servizi Amazon, è un po' lento, quindi c'è sempre stato un ritardo, ma comunque siamo riusciti a cogliere almeno approssimativamente il collegamento tra il problema e gli script che lo causano (abbiamo fatto un controllo, bloccato all'okerr e l'ho controllato ricevendo immediatamente un avviso).

Un caso interessante è stato recentemente aggiunto alla collezione da un grande e costoso hoster europeo, utilizzato dal nostro cliente. All'improvviso TUTTI i nostri server sono scomparsi dal radar! Innanzitutto, il cliente stesso (più veloce di okerra!) ha notato che il sito con cui stava lavorando non si apriva e ha creato un ticket a riguardo. Ma non solo un sito è andato in tilt, ma tutti! (Natasha, abbiamo mollato tutto!). Qui Okerr ha iniziato a inviare lunghi bendaggi ai piedi con tutti gli indicatori che si accendevano per lui. Panico, panico, corriamo in tondo (cos'altro possiamo fare?). Poi tutto è risorto. Si scopre che nel data center veniva effettuata una manutenzione ordinaria (una volta ogni molti anni) e, ovviamente, avremmo dovuto essere avvisati. Ma è successo loro qualche tipo di problema e non ci hanno avvisato. Ebbene, più attacchi di cuore, meno attacchi di cuore. Ma dopo che tutto è stato ripristinato, è necessario ricontrollare tutto! Non riesco a immaginare come lo farei con le mie mani. Okerr ha testato tutto in pochi minuti. Si è scoperto che la maggior parte dei server erano semplicemente temporaneamente non disponibili, ma funzionavano. Alcuni erano sovraccarichi, ma si alzavano anche come dovevano. Di tutte le perdite, abbiamo perso due backup, che secondo la corona avrebbero dovuto essere creati e caricati mentre questa banana piena era in corso. Non mi sono nemmeno preso la briga di crearli, solo il giorno dopo sono arrivati ​​gli avvisi che tutto andava bene, erano comparsi i backup. Questo esempio mi piace molto perché okerr si è rivelato molto utile in una situazione a cui non avevamo nemmeno pensato in anticipo, ma che è lo scopo del monitoraggio: resistere all'imprevedibile.

Per i sensori Okerr utilizziamo l'hosting più economico possibile (dove la qualità e l'affidabilità non sono importanti, si assicurano a vicenda). Quindi, di recente abbiamo trovato un ottimo hosting e super economico, i parametri di riferimento sono fantastici. Ma... a volte capita che le connessioni in uscita dalla macchina virtuale vengano effettuate da un altro IP (vicino). Miracoli. Modulo Client_ip con https://diagnostic.opendns.com/myip ottiene l'IP sbagliato. E dai log del server dell'indicatore è chiaro che l'aggiornamento proveniva anche da questo IP vicino. Affrontiamo ora il supporto. È positivo che lo abbiamo notato in tempo di pace. Ma, ad esempio, accade spesso che l'accesso sia registrato secondo la lista bianca IP - e se il server a volte lampeggia in questo modo per un breve periodo - puoi provare a rilevare questo problema per un tempo molto lungo.

Bene, ancora una cosa – visto che parliamo di hosting VPS – utilizziamo sempre quelli economici (hetzner, ovh, scaleway). Mi piace molto sia in termini di benchmark che di stabilità. Utilizziamo anche Amazon EC2, molto più costoso, per altri progetti. Quindi, grazie a okerr, abbiamo la nostra opinione informata. Cadono entrambi. E non direi che nel lungo periodo delle nostre osservazioni, gli hosting economici come Hetzner si siano rivelati notevolmente meno stabili di EC2. Pertanto, se non sei legato ad altre funzionalità di Amazon, perché pagare di più? 🙂

Quali sono le prospettive?

Se a questo punto non ti ho ancora spaventato e allontanato da Okerr, allora provalo! Puoi andare direttamente a questo link Conto demo okerr (Clicca ora!) Ma tieni presente che esiste un solo account demo per tutti, quindi se fai qualcosa, qualcun altro nello stesso account potrebbe interferire con te allo stesso tempo. O (meglio) registrarsi tramite il link a okerr fuori sede - tutto è semplice, senza SMS. Se non ti piace usare la tua vera email, puoi usarne una usa e getta, come mailinator (mi raccomando getnada.com). Tali account potrebbero essere eliminati nel tempo, ma andranno bene per i test.

Dopo la registrazione, ti verrà chiesto di seguire una formazione (eseguire diversi compiti di formazione non molto difficili). I limiti iniziali sono molto piccoli, ma sono sufficienti per l'allenamento o per un server. Dopo aver completato la formazione, i limiti (ad esempio il numero massimo di indicatori) verranno aumentati.

Dalla documentazione, prima di tutto WIKI lato server e lato client (wiki di okerrupdate). Ma se qualcosa non è chiaro, scrivi a support (at) okerr.com o lascia un ticket: cercheremo di risolvere tutto rapidamente.

Se lo usi seriamente e questi limiti aumentati non bastano, scrivi al supporto e lo aumenteremo (gratuitamente).

Desideri installare il server okerr sul tuo server? Qui repository okerr-dev. Ti consigliamo di installare su una macchina virtuale pulita, quindi puoi farlo semplicemente con uno script di installazione. Sulla tua macchina virtuale: nessuna restrizione :-). Bene, ancora una volta, se succede qualcosa, cercheremo sempre di aiutare.

Vogliamo che questo progetto decolli, affinché il mondo diventi più affidabile grazie a noi. Grazie al software e ai servizi gratuiti, il mondo è diventato più amichevole e si sta sviluppando in modo più dinamico. I sorgenti possono essere archiviati in Github gratuito, per la posta puoi utilizzare Gmail gratuito. Usiamo gratuitamente freshworks per supporto. Per tutto questo, non è necessario pagare i server, non è necessario scaricarli e configurarli e non è necessario risolvere vari problemi operativi. Ogni nuovo progetto, ogni team ha immediatamente posta, repository e CRM. E tutto questo è di altissima qualità, gratuito e immediato. Vogliamo che sia lo stesso per il monitoraggio: le piccole aziende e i progetti potrebbero utilizzare okerr gratuitamente e anche nella fase di nascita e crescita avere l'affidabilità di progetti seri per adulti.

Fonte: habr.com