Due anni fa ho già scritto un post Failover semplice per il sito web su okerr. Ora ci sono alcuni sviluppi del progetto, e ho anche pubblicato il codice sorgente della parte server di okerr sotto licenza open source, quindi ho deciso di scrivere questa breve panoramica su Habr.

[ full size ]

A chi può interessare

Può interessarti se lavori in un piccolo team o anche da solo. Non hai un sistema di monitoraggio e non sei sicuro di averne realmente bisogno. Oppure hai provato qualche monitoraggio serio e popolare "per grandi ragazzi", ma non ha funzionato per te, oppure funziona con una configurazione quasi di default e non ha cambiato molto la tua vita. E anche — se non hai intenzione di dedicare un intero dipendente (o addirittura un intero reparto) per monitorare il dashboard di monitoraggio per almeno un paio d'ore al giorno o per configurarlo.

Cosa rende okerr unico

Successivamente mostrerò alcune caratteristiche interessanti di okerr, che lo differenziano da altri sistemi di monitoraggio.

Okerr è un monitoraggio ibrido

Durante il monitoraggio interno, su macchine monitorate viene eseguito un 'agente' che trasmette i dati al server di monitoraggio (ad esempio, lo spazio libero sui dischi). Con il monitoraggio esterno, il server esegue controlli sulla rete (ad esempio, ping o disponibilità del sito web). Ciascun approccio ha le proprie limitazioni. Okerr utilizza entrambe le modalità. I controlli interni ai server vengono eseguiti da un agente molto leggero (30Kb) o dai vostri script e applicazioni, mentre quelli di rete avvengono tramite sensori okerr in diversi paesi.

okerr non è solo software, ma anche servizio.

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

Se il monitoraggio può compensare e coprire la mancanza di affidabilità dei server e delle applicazioni, sorge una domanda filosofica: chi sorveglia il sorvegliante? Come ci avviserà il monitoraggio di un problema se esso stesso è "morto" per qualche motivo, separatamente o insieme ad altre tue risorse (ad esempio, se il canale verso il data center è caduto)? Con l'uso del servizio esterno okerr, questo problema viene risolto: riceverai un alert anche se l'intero data center con i tuoi server è privo di energia o sotto attacco di zombie.

Certo, c'è il rischio che il server okerr sia esso stesso non disponibile, è vero (come si sa, il 90% dell'affidabilità si ottiene sempre in modo semplice e "gratuito", il 99% con il minimo sforzo, e ogni ulteriore nove diventa esponenzialmente più difficile). Ma, in primo luogo, le probabilità di ciò sono più basse e, in secondo luogo, un problema potrebbe rimanere inosservato solo se coincide temporalmente con i 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 osservato è dello 0,1% su 0,1% = 0,0001%. Aggiungere tre nove alla propria affidabilità quasi senza sforzo e senza costi è davvero un buon affare!

Un ulteriore vantaggio del monitoraggio come servizio è che un provider di hosting o uno studio web può installare il server okerr e fornire accesso ai clienti come servizio aggiuntivo a pagamento o gratuito. I tuoi concorrenti offrono solo hosting e siti web, mentre tu hai un hosting affidabile con monitoraggio.

Okerr riguarda gli indicatori

Un indicatore è una "lampadina". Ha due stati principali: verde (OK) o rosso (ERR). Nel progetto ci sono molti indicatori raggruppati (ad esempio, per server). Nella pagina principale del progetto puoi vedere immediatamente se tutto è verde (e puoi chiudere) o se qualcosa è acceso di rosso e necessita di correzione. Durante il passaggio tra questi stati viene inviato un avviso. Una volta al giorno, mentre imposti, viene inviata una sintesi del progetto.

Ogni indicatore okerr ha condizioni incorporate che ne determinano lo stato (in Zabbix si chiama trigger). Ad esempio, il carico medio non deve superare 2 (ovviamente, questo è configurabile). E per ogni controllo interno (carico medio, spazio su disco, ...) c'è un watchdog. Se per qualche motivo non riceviamo una conferma positiva entro il tempo stabilito, viene registrato un errore e viene inviato un avviso.

La nostra consueta procedura prevede una verifica mattutina della posta, dove tra le altre e-mail controlliamo il riepilogo (l'orario è impostato all'inizio del lavoro). Se è tutto a posto, ci occupiamo di altre questioni importanti (ma possiamo rapidamente dare un'occhiata al dashboard di okerr per assicurarci che anche in quel momento tutto sia verde). Se arriva un avviso, interveniamo.

Certo, c'è la possibilità di mantenere indicatori "informativi" (per visualizzare la situazione della rete dal monitoraggio), ma tutto è stato progettato per facilitare e velocizzare la creazione di indicatori per un monitoraggio automatico e l'invio di avvisi.

Il motivo per cui configuri okerr è negli avvisi, per cui puoi creare un indicatore in un minuto; potrebbe «dormire» per un anno, ricevendo solo aggiornamenti, e quando dopo un anno qualcosa si rompe, si accende e invia un avviso. Il minuto speso una volta per creare l'indicatore è stato ripagato: hai scoperto il problema immediatamente, prima di chiunque altro. È possibile che l'abbia anche riparato prima che qualcuno se ne accorgesse. Quello che è stato rapidamente attivato non è considerato caduto!

Sicurezza

Sarebbe deludente se imposti il monitoraggio per aumentare l'affidabilità, e invece vieni attaccato attraverso di esso, dato che ci sono molte vulnerabilità di rete nei diversi strumenti di monitoraggio.Zabbix, Nagios).

L'agente (okerrmod del pacchetto okerrupdate) che lavora sul sistema non è un server di rete, ma un client. Pertanto, sul server monitorato non ci sono porte aperte aggiuntive; il client funziona facilmente dietro un firewall o NAT e risulta molto difficile (direi «impossibile») da hackerare attraverso la rete, poiché in linea di principio non ascolta alcun socket di rete.

Copertura completa del monitoraggio

Attualmente abbiamo una regola: apprendiamo di tutti i problemi tecnici da okerr. Se, per caso, la regola viene violata (okerr non ci avvisa del suo imminente verificarsi (se possibile) o che è già avvenuto) — aggiungiamo controlli in okerr.

Controlli esterni

Un insieme piuttosto tipico:

ping
http status
controllo della validità e della freschezza del certificato SSL (avviserà se la scadenza è prossima)
porta TCP aperta e banner su di essa
http grep (sulla pagina [non] deve trovarsi un certo testo)
sha1 hash per catturare modifiche alla pagina.
DNS (il record DNS deve avere un certo valore)
WHOIS (avviserà se il dominio sta per scadere)
Antispam DNSBL (controllo dell'host immediato su più di 50 blacklist antispam)

Controlli interni

Anche questo è un insieme piuttosto tipico (ma facilmente estendibile).

df (spazio libero sui dischi)
carico medio
opentcp (socket TCP in ascolto aperti — notificherà se qualcosa è stato avviato o è caduto)
uptime — semplicemente l'uptime del server. Notificherà se è cambiato in negativo (cioè, se il server si è riavviato)
client_ip
dirsize — lo usiamo per monitorare quando il nostro rootfs delle VM supera la dimensione consentita, senza imporre restrizioni rigide, e per le dimensioni delle home directory degli utenti.
empty e nonempty — seguono i file che devono essere vuoti (o non vuoti). Ad esempio, il file di log degli errori del server okerr — deve essere vuoto, e se contiene anche una sola riga, riceverò una notifica e controllerò. Mentre mail.log sul server di posta deve essere NON vuoto (dopo N minuti dalla rotazione). A volte si è rivelato vuoto, dopo l'aggiornamento di sistema, quando logrotate non è riuscito a riavviare correttamente rsyslog.
linecount — numero di righe nel file (come wc -l). Lo usiamo come una sostituzione più blanda per empty, quando il log degli errori potrebbe comunque crescere, ma solo lentamente (ad esempio, abbiamo il bot di Google che tenta di accedere ad alcune pagine riservate). C'è un limite di 2 righe ogni 20 minuti. Se supera questo limite, ci sarà un avviso.

Controlli interni interessanti

Se finora hai letto «di corsa», ora sarà più interessante leggerlo con attenzione.

backups

Monitora i backup nel catalogo. I nostri file di backup hanno nomi come «ServerName-20200530.tar.gz». Per ciascun server in okerr viene creato un indicatore ServerName-DATE.tar.gz (la data effettiva viene sostituita dalla stringa «DATE»). Si controlla non solo la presenza di un backup recente, ma anche la sua dimensione (ad esempio, non può essere più piccolo del 90% rispetto al backup precedente).

Cosa bisogna fare affinché il nuovo backup venga monitorato, dopo che abbiamo iniziato a crearlo e a inserirlo in questo catalogo? Niente! Questo approccio è molto comodo perché:

Fare «niente» è piuttosto veloce, risparmia tempo.
È difficile dimenticare di fare «niente».
È difficile fare «niente» in modo errato. Niente è il metodo più affidabile.

Se improvvisamente smettono di apparire nuovi file di backup, verrà emesso un avviso. Se, per esempio, hai disattivato uno dei server, e non dovrebbero più esserci backup di questo, dovrai rimuovere l'indicatore (tramite l'interfaccia web o dal terminale tramite API).

maxfilesz

Monitora la dimensione dei file più grandi (di solito: /var/log/*). Questo aiuta a catturare problemi imprevisti, come tentativi di accesso non autorizzati o invio di spam tramite il server.

runstatus/runline

Questi sono due importanti moduli proxy per eseguire altri programmi sul server. Runstatus riporta il codice di uscita del programma. Ad esempio, in okerr non è (non necessario) un modulo per verificare che i servizi systemd siano attivi. Questo è gestito tramite runstatus (vedi sotto). Runline comunica al server la stringa fornita dal programma. Ad esempio, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" nel config di Runline sul nostro server crea un indicatore servername:temp con la temperatura del processore.

sql

Esegue una query numerica su MySQL e riporta il risultato nell'indicatore. In un caso semplice, si può fare, ad esempio, "SELECT 1" — questo verificherà che il DBMS in generale funzioni.

Ma un'applicazione molto più interessante è, ad esempio, monitorare il numero di ordini in un negozio online. Se sai che hai da 100 ordini all'ora, puoi impostare un limite minimo di 100 o 80. Allora, se le vendite dovessero improvvisamente calare — riceverai un avviso e potrai intervenire.

Nota — non importa per quale ragione imprevedibile sia successo:

Il server è semplicemente non disponibile (senza energia o senza rete), e l'allerta è arrivata perché l'indicatore è 'scaduto'.
Il server è carico, funziona lentamente o ci sono pacchetti persi, gli utenti trovano difficile utilizzare il servizio e abbandonano senza effettuare acquisti.
Il server è finito nelle liste di spam e le email non vengono accettate, gli utenti non possono registrarsi.
Il budget della campagna pubblicitaria è esaurito, i banner non vengono mostrati.

Le cause possono essere molteplici e non sempre è possibile prevederle, e tecnicamente è difficile monitorarle. Tuttavia, è possibile tenere d'occhio il parametro finale (gli ordini) e valutare se la situazione è sospetta e merita di essere approfondita.

Indicatori logici

Permette di utilizzare espressioni logiche (sintassi Python) tramite il modulo evalidate(articolo su Habré). Per l'espressione sono disponibili i dati del progetto e dei suoi indicatori. Ad esempio, nel capitolo sulla verifica SQL sopra, avrete notato un punto debole: durante il giorno possiamo avere fino a 100 vendite all'ora, ma di notte solo 20, ed è normale, non è un problema. Come procedere? L'indicatore continuerà a segnalare panico durante la notte.

È possibile creare due indicatori, uno diurno e uno notturno. Entrambi possono essere impostati come "silenziosi" (non invieranno notifiche). Inoltre, si può creare un indicatore logico che richiede entro le 20:00 che l'indicatore diurno sia OK, mentre dopo le 20:00 basta che l'indicatore notturno sia OK.

Un altro esempio di utilizzo di un indicatore logico è l'escalation. Ad esempio, il project manager si disiscrive dalle notifiche (non gli serve, gli amministratori devono reagire ai problemi normali), ma si iscrive all'indicatore logico, che diventa rosso se qualsiasi indicatore del progetto non viene corretto entro il tempo stabilito.

Inoltre, è possibile assegnare un intervallo di tempo consentito per i lavori, ad esempio dalle 3 alle 5 del mattino. Non ci importa se i server e i siti "cadono" durante quel periodo. Ma alle 5:00 devono essere operativi. Se non lo sono in qualsiasi altro momento, scatta un allerta. L'indicatore logico tiene conto anche del bilanciamento dei server. Se hai 5 server web, gli amministratori possono spegnere 1-2 server in qualsiasi momento. Ma se ci sono meno di 3 dei 5 server attivi, verrà emessa un'allerta.

Esempi sopra non sono funzionalità di okerr, né qualche caratteristica da attivare e configurare. Queste funzioni non esistono in okerr, ma c'è un modulo logico che permette di implementare anche questa funzionalità (Un po' come nel linguaggio di programmazione: se abbiamo operatori aritmetici, non abbiamo bisogno di una specifica funzione del linguaggio per calcolare il 20% di IVA, possiamo sempre farlo noi stessi secondo le nostre necessità).

L'indicatore logico è, probabilmente, uno dei pochi temi relativamente complessi in okerr, ma la buona notizia è che non è necessario masterizzarli finché non si rende necessario. Tuttavia, ampliano notevolmente le possibilità, mantenendo il sistema stesso piuttosto semplice.

Aggiunta delle proprie verifiche

Vorrei veramente far passare il concetto che okerr non è un insieme di mille verifiche pronte per ogni evenienza, ma al contrario — prima di tutto — un motore semplice con la possibilità di creare le proprie verifiche. Creare le proprie verifiche in okerr non è un compito da hacker, co-sviluppatori del sistema o almeno utenti avanzati di okerr, ma un compito realizzabile per qualsiasi amministratore che ha installato Linux per la prima volta un mese fa.

I controlli sui minimi vengono effettuati tramite il modulo runstatus:

Questa riga nel file di configurazione runstatus segnalerà se per caso /bin/true non si avvia o restituisce un valore diverso da 0.

true_OK=/bin/true

Basta una riga — ecco che abbiamo già un po' espanso il funzionamento di okerr.

Anche un controllo di questo tipo ha il suo valore: se per caso il vostro server si blocca, l'indicatore corrispondente su okerr non si aggiornerà in tempo, e dopo un certo periodo verrà generato un avviso.

Questo controllo segnalerà che il server apache2 è crashato (dopotutto...):

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

Quindi, se conoscete qualche linguaggio di programmazione, potete scrivere script shell — quindi siete già in grado di aggiungere i vostri controlli.

Più complesso — potete scrivere (in qualsiasi linguaggio) il vostro modulo per okerrmod. Nel caso più semplice, appare così:

#!/usr/bin/python3

print("STATUS: OK")

In verità, non è poi così difficile? Il modulo deve effettuare il controllo e restituire i risultati su STDOUT. Un modulo più complesso fornisce, ad esempio, quanto segue:

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G usato, 13.0G libero
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M usato, 9.9M libero
STATUS: 84.32

Aggiorna più indicatori contemporaneamente (separati da una riga vuota), crea quelli necessari, specifica i dettagli di verifica e il tag sotto il quale trovare facilmente gli indicatori nel dashboard.

C'è un bot Telegram @OkerrBot. Non è necessario riempire il telefono con app separate (anch'io non amo avere un'app per ogni servizio, come un'app per la carta di Pyaterochka, una per Lenta, un'altra per MTS e così via per tutti). Un solo Telegram è sufficiente. Attraverso Telegram puoi ricevere subito gli avvisi, controllare lo stato del progetto e dare il comando di ricontrollare tutti gli indicatori problematici. Esci dal teatro/dall'aereo, dopo due ore senza aggiornamenti, accendi il telefono, premi un pulsante nel chat bot e assicurati che tutto sia a posto.

Pagine di stato

Ogni giorno, le pagine di stato sono diventate quasi un must-have per qualsiasi azienda con un reparto IT, un approccio responsabile alla sicurezza e che ha rispetto per i propri clienti/utenti.

Immagina questa situazione: un utente vuole fare qualcosa, cercare informazioni o effettuare un ordine, e qualcosa non funziona. Non sa dove sia il problema, di chi sia la responsabilità e quando sarà risolto. Potrebbe essere che il sito della tua azienda non funzioni? O è rotto da sei mesi e verrà riparato tra due anni? Ma il frigorifero va acquistato ora, è già nel carrello… E tutto cambia quando una persona vede che c'è qualcosa che non va da parte vostra (almeno è chiaro che il problema non è suo), che il problema è stato identificato, che state già lavorando su di esso, e magari avete persino indicato un tempo approssimativo per la risoluzione. L'utente può iscriversi e ricevere un'email di avviso quando il problema sarà risolto e potrà finalmente fare ciò che voleva (comprare il frigorifero).

I problemi, i tempi di inattività, capitano a tutti. Ma gli utenti e i partner si fidano di più di chi è più trasparente e responsabile riguardo a queste situazioni.

Ecco panoramica di 10 altri progetti che permettono di creare pagine di stato. Ecco degli esempi di come appaiono queste pagine nei vari progetti Python e Dropbox. Pagina di stato okerr.

Failover

Per evitare di rendere questo articolo ancora più lungo, farò di nuovo riferimento al mio articolo precedente — Failover semplice per il sito web . Se puoi creare un server di backup, utilizzando il failover, non avrai praticamente downtime prolungato: non appena il problema viene rilevato, gli utenti vengono automaticamente reindirizzati al server di backup attivo. E penso che questa sia una funzione molto interessante e brillante, che non si trova facilmente.

Bassi requisiti di sistema

Per i server okerr — utilizziamo macchine con RAM da 2 Gb. Per i sensori di rete — anche 512 Mb sono sufficienti. La parte client — praticamente quasi zero. (Il pacchetto okerrupdate pesa 26 Kb, ma richiede Python3 e librerie standard). Il client viene avviato da uno script cron, quindi ha un consumo di memoria costante nullo. Tra le macchine monitorate abbiamo sensori (super-economici VPS con 512 Mb di RAM) e Raspberry Pi. È possibile anche inviare aggiornamenti attraverso curl ! (vedi sotto)Tenendo conto di ciò — okerr, probabilmente,

il più gratuito è il più gratuito Un sistema di monitoraggio a disposizione, poiché anche per utilizzare un altro sistema open source gratuito come Zabbix o Nagios, è necessario allocare risorse (server) e questo comporta già dei costi. Inoltre, è comunque necessaria una certa manutenzione del server. Con okerr, questa parte può essere eliminata. Ma si può anche decidere di non eliminarla e utilizzare un proprio server, a seconda delle preferenze.

API e integrazione nel proprio software

Architettura semplice e aperta. okerr ha un'architettura piuttosto semplice API, con cui è facile lavorare. Vuoi creare 1000 indicatori? Un singolo script shell di 3-4 righe farà il lavoro. Vuoi riconfigurare 1000 indicatori? Allo stesso modo, è molto facile. Ad esempio, vogliamo verificare nuovamente tutti i nostri certificati HTTPS proprio utilizzando il 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 sia utilizzando il nostro modulo client, sia anche senza di esso, semplicemente 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 heartbeat affinché okerr sappia che è attivo e generi un allerta se si ferma o si blocca. A proposito, i componenti di okerr fanno proprio così: okerr si controlla autonomamente e problemi in quasi qualsiasi modulo saranno rilevati e genereranno una notifica di problema. (E per quel 'quasi', vengono verificati anche da un altro server.)

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

Per aggiornare gli indicatori da programmi Python, esiste una libreria okerrupdate, per altri linguaggi non ci sono librerie, ma si può chiamare lo script okerrupdate o effettuare una richiesta HTTP al server okerr.

Come ci aiuta okerr

Okerr ha cambiato la nostra vita. Davvero. Forse un altro sistema di monitoraggio potrebbe farlo, ma lavorare con okerr è facile e semplice e ha tutte le funzionalità di cui avevamo bisogno (ciò che mancava — noi lo abbiamo aggiunto). A proposito, se manca qualche funzionalità — chiedi e la aggiungerò (non prometto, ma mi piacerebbe che okerr fosse il miglior sistema di monitoraggio per piccoli e medi progetti). O, ancora meglio, aggiungila tu stesso — è semplice.

Siamo riusciti a vivere secondo il principio «scoprire tutti i problemi tramite okerr». Se succede qualche problema di cui non abbiamo saputo tramite okerr — aggiungiamo il controllo in okerr. (in questo caso con «noi» intendo noi come utenti del sistema, e non come co-sviluppatori). All'inizio accadeva spesso, ma ora è diventato molto raro.

Monitoraggio

Attraverso okerr monitoriamo le dimensioni dei log su tutti i server. Leggere attentamente ogni riga del log è ovviamente impossibile, ma semplicemente monitorare la velocità di crescita fornisce già molte informazioni. In questo modo abbiamo scoperto sia l'invio di spam che le forzature di password, oltre a quando alcune applicazioni 'impazziscono', quando qualcosa non funziona e ripetono continuamente (ogni volta aggiungendo alcune righe al log).

Certificati SSL. Quasi subito dopo il lancio LetsEncrypt il nostro cliente ha iniziato a fornire ai propri clienti certificati SSL gratuiti (circa mille). E questo è diventato un vero incubo per la gestione! Il fatto è che i siti sono 'vivi', i clienti chiedono periodicamente di fare modifiche, gli sviluppatori eseguono. Possono facilmente spostare il sito in un'altra DocumentRoot, ad esempio. Oppure aggiungere un rewrite senza condizioni nella configurazione del virtual host. Naturalmente, dopo tali modifiche, l'aggiornamento automatico dei certificati si rompe. Ora tutti i nostri host SSL vengono aggiunti a okerr automaticamente tramite un'altra nostra utile utility del pacchetto a2conf. Basta eseguire a2okerr.py — e se sul server compaiono diversi nuovi siti, essi appariranno automaticamente in okerr. Nel caso in cui, per qualche motivo, il certificato non venga aggiornato, tre settimane prima della sua scadenza, saremo già al corrente e ci occuperemo di capire perché non si aggiorna, maledizione. a2certbot.py dello stesso pacchetto — aiuta molto in questo (controlla subito i problemi più probabili e segnala ciò che è andato bene e dove potrebbe esserci un problema).

Seguiamo la scadenza di tutti i nostri domini. E tutti i nostri server di posta che inviano email sono controllati anche su oltre 50 diversi blacklist. (E talvolta ci finiscono). A proposito, sapevate che anche i server di posta di Google sono nelle blacklist? Per il nostro auto-test abbiamo aggiunto mail-wr1-f54.google.com ai server monitorati, e risulta essere effettivamente nella blacklist SORBS! (Questo per sottolineare il valore dei "contrastanti allo spam")

I backup — ho già scritto sopra come seguirli facilmente con okerr. Ma monitoriamo anche i backup freschi sul nostro server e (con l'aiuto di un'altra piccola utility che usa okerr) i backup che carichiamo su Amazon Glacier. E sì — a volte si presentano problemi. Non seguiamo senza motivo.

Utilizziamo un indicatore di escalation. Questo consente di vedere se un problema non è stato risolto per lungo tempo. E anche io, quando affronto alcune questioni, a volte posso dimenticarle. L'escalation è un buon promemoria, anche se si tiene d'occhio tutto.

In generale, ritengo che la qualità del nostro lavoro sia migliorata notevolmente. Il downtime è quasi assente (o il cliente non ha il tempo di notarlo. Solo tsss!), mentre il volume di lavoro è diminuito e le condizioni di lavoro sono diventate più serene. Siamo passati da un lavoro precipitato alla riparazione delle falle con nastro adesivo a un lavoro tranquillo e misurato, dove molti problemi vengono previsti in anticipo e c'è tempo per prevenirli. Anche se si sono già verificati problemi, è diventato più facile risolverli: in primo luogo, ne veniamo a conoscenza prima che i clienti entrino nel panico; in secondo luogo, spesso è così che il problema è legato a un lavoro recente (mentre risolvevo una cosa, ne ho rotta un'altra) — quindi è più facile affrontarlo a caldo.

Ecco, c'è stato anche un caso...

Sapevate che in Debian 9 (Stretch) un pacchetto così popolare come phpmyadmin è ancora (da molti mesi!) in uno stato vulnerabile? (CVE-2019-6798). Quando è emersa la vulnerabilità, l'abbiamo rapidamente mitigata in vari modi. Ho impostato in okerr il monitoraggio della pagina del security-tracker per sapere quando verrà rilasciata una soluzione “definitiva” (tramite SHA1 del contenuto). Diverse volte il segnale mi ha avvisato, la pagina è cambiata, ma come vedete – ad oggi (da gennaio 2019!) non è ancora indicato che il problema sia stato risolto. Forse, qualcuno sa cosa c'è dietro questo problema, dal momento che un pacchetto così importante è rimasto vulnerabile per più di un anno?

Un'altra volta in una situazione simile: dopo la vulnerabilità in SSH è stato necessario aggiornare tutti i server. E quando si assegna un compito, è necessario monitorare l'esecuzione. (I subordinati tendono a interpretare diversamente, dimenticare, confondersi, commettere errori). Perciò, inizialmente abbiamo aggiunto in okerr un controllo della versione di SSH su tutti i server, e attraverso okerr abbiamo monitorato che gli aggiornamenti fossero applicati su tutti i server. (Comodo! Ho scelto questo tipo di indicatore, e subito si vede su quale server è installata quale versione). Quando ci siamo assicurati che il compito fosse completato su tutti i server, abbiamo rimosso gli indicatori.

A volte capita che si presenti un problema e poi, per qualche motivo, si risolva da solo. (Sicuramente è un'esperienza comune). Nel frattempo, mentre cerchi di capire cosa sta succedendo, ti rendi conto che il problema si è già risolto — tutto funziona di nuovo correttamente. Tuttavia, in seguito, il problema può ripresentarsi. A noi è successo, ad esempio, con i prodotti che caricavamo su Amazon Marketplace (MWS). In un certo momento, l'inventario caricato era errato (quantità e prezzi sbagliati). Siamo riusciti a risolvere la situazione. Ma per farlo, era fondamentale scoprire subito il problema. Purtroppo, MWS come tutti i servizi di Amazon, è un po' lento, quindi c'era sempre un ritardo, ma siamo riusciti comunque a stabilire una connessione tra il problema e gli script che lo provocavano (abbiamo effettuato dei controlli, collegandoli agli errori, e verificavamo immediatamente al ricevimento dell'allerta).

Un caso interessante è stato recentemente aggiunto alla nostra raccolta da un importante e costoso fornitore di hosting europeo, di cui è cliente uno dei nostri. All'improvviso tutti i nostri server sono scomparsi dai radar! In un primo momento, il cliente, notando che il sito su cui stava lavorando non si apriva, ha fatto un ticket per segnalare il problema. Ma non si trattava di un solo sito, bensì di tutti! (Natasha, abbiamo fatto un disastro!). A quel punto, Okerr ha iniziato a inviare lunghe segnalazioni con tutti i parametri che si erano accesi. Panico, panico, correvamo in cerchio (cosa altro potevamo fare?). Poi tutto è stato ripristinato. Si è scoperto che c'erano lavori di routine nel data center (una volta ogni molti anni) e, ovviamente, avrebbero dovuto avvisarci. Ma è successo qualche imprevisto e non ci hanno avvisato. Ma a parte un infarto in più o in meno... dopo il ripristino di tutto, era necessario controllare tutto! Non riesco a immaginare come avrei fatto a farlo manualmente. Okerr ha testato tutto in pochi minuti. Si è scoperto che la maggior parte dei server era semplicemente temporaneamente non disponibile, ma funzionava. Alcuni si erano sovraccaricati, ma si sono ripresi come dovevano. Tra tutte le perdite, abbiamo perso due backup che avrebbero dovuto essere creati e caricati durante il periodo di questo disastro totale. Non ho nemmeno tentato di crearli, poiché dopo un giorno sono arrivati gli avvisi che tutto era a posto, i backup erano riapparsi. Mi piace molto questo esempio, perché Okerr si è rivelato molto utile in una situazione di cui non avevamo nemmeno ipotizzato prima, ma questo è precisamente l'obiettivo del monitoraggio: affrontare l'imprevedibile.

Per i sensori Okerr utilizziamo gli hosting più economici (lì la qualità e l'affidabilità non sono importanti, si coprono a vicenda). Recentemente abbiamo scoperto un hosting molto veloce e super economico, con benchmark eccezionali. Tuttavia… a volte succede che le connessioni in uscita dalle macchine virtuali vengano effettuate da un altro (IP vicino). Meraviglie. Il modulo client_ip non https://diagnostic.opendns.com/myip ottiene l'IP corretto. Dalle registrazioni del server è evidente che l'aggiornamento è arrivato anch'esso da questo IP vicino. Stiamo attualmente indagando con il supporto tecnico. È fortunato che ce ne siamo accorti in un momento tranquillo. Ma, ad esempio, succede spesso che l'accesso venga configurato nella whitelist degli IP — e se il server lampeggia in quel modo per brevi periodi — può essere molto difficile individuare questo problema.

E comunque, dato che parliamo di hosting VPS, noi utilizziamo sempre soluzioni convenienti (hetzner, ovh, scaleway). Sia per i benchmark che per la stabilità, ci piacciono molto. Utilizziamo anche Amazon EC2, che è molto più costoso, per altri progetti. Grazie a okerr, abbiamo un'opinione ben fondata. Entrambi possono avere problemi. E, dopo un lungo periodo di osservazione, non direi che gli hosting economici come hetzner risultano significativamente meno stabili rispetto ad EC2. Quindi, se non siete legati ad altre funzionalità di Amazon, perché pagare di più? 🙂

E ora?

Se a questo punto non vi ho spaventato troppo da Okerr, provate! Potete accedere direttamente a un account di dimostrazione di okerr (Cliccate subito!). Ma tenete a mente che l'account demo è uno per tutti, quindi, se fate qualcosa, un altro nello stesso account potrebbe disturbarti nel frattempo. Oppure (meglio) registratevi tramite il link su sito ufficiale di okerr — è facile, senza SMS. Se non vi piace usare la vostra email reale, potete utilizzare una temporanea, come mailinator (consiglio getnada.com). Questi account possono essere eliminati nel tempo, ma sono perfetti per un test.

Dopo la registrazione, ti verrà proposto di seguire un corso di formazione (completare alcune semplici attività didattiche). I limiti iniziali sono molto ridotti, ma per la formazione o un server bastano. Dopo aver completato il corso di formazione, i limiti (ad esempio, il numero massimo di indicatori) verranno aumentati.

Dalla documentazione — prima di tutto WIKI per la parte server e per il client (okerrupdate wiki). Ma se qualcosa non ti è chiaro, scrivi a support (at) okerr.com oppure apri un ticket: cercheremo di risolvere tutto rapidamente.

Se utilizzerai seriamente e questi limiti aumentati non saranno sufficienti, scrivi anche al supporto, li aumenteremo (gratuitamente).

Vuoi installare un server okerr sul tuo server? Ecco il repository okerr-dev. Ti consigliamo di installarlo su una macchina virtuale pulita, così sarà facile farlo con uno script di installazione. Sulla tua macchina virtuale — nessun limite :-). E, di nuovo, se hai bisogno di aiuto, saremo sempre disponibili.

Vogliamo che questo progetto decolli, rendendo il mondo più sicuro grazie a noi. Grazie ai software e servizi gratuiti, il mondo è diventato più amichevole e si sviluppa in modo più dinamico. I codici sorgente possono essere conservati nel gratuito github, e per la posta si può utilizzare il gratuito gmail. Noi utilizziamo freshworks per il supporto. Non è necessario pagare server per nulla di tutto ciò, né scaricare e configurare, né risolvere vari problemi operativi. Ogni nuovo progetto, ogni team, ha immediatamente sia la posta, sia i repository, sia il CRM. E tutto ciò è di alta qualità, gratuito e disponibile subito. Vogliamo che anche il monitoraggio sia così: piccole aziende e progetti dovrebbero poter utilizzare gratuitamentel' okerr e avere, fin dalla fase di avvio e crescita, affidabilità come quella dei grandi progetti professionali. freshworks per il supporto. Non è necessario pagare server per nulla di tutto ciò, né scaricare e configurare, né risolvere vari problemi operativi. Ogni nuovo progetto, ogni team, ha immediatamente sia la posta, sia i repository, sia il CRM. E tutto ciò è di alta qualità, gratuito e disponibile subito. Vogliamo che anche il monitoraggio sia così: piccole aziende e progetti dovrebbero poter utilizzare gratuitamentel' okerr e avere, fin dalla fase di avvio e crescita, affidabilità come quella dei grandi progetti professionali.

Fonte: habr.com