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

[ full size ]

A chi può interessare

Potrebbe interessarvi se lavorate in una piccola squadra o addirittura da soli. Non avete un monitoraggio e non siete sicuri se sia davvero necessario. Oppure avete provato qualche popolare e serio strumento di monitoraggio "per grandi ragazzi", ma per voi non ha funzionato, oppure funziona in una configurazione quasi predefinita e non ha cambiato in modo significativo la vostra vita. E anche — se non pianificate di assegnare un dipendente (o addirittura un'intera divisione) per monitorare per almeno un paio d'ore al giorno il dashboard di monitoraggio o configurarlo.

Cosa rende okerr insolito

Adesso vi mostrerò le caratteristiche interessanti di okerr che lo distinguono da altri strumenti di monitoraggio.

Okerr è un monitoraggio ibrido

Con il monitoraggio interno, su macchine osservate viene eseguito un "agente" che invia dati al server di monitoraggio (ad esempio, spazio libero sui dischi). Con il monitoraggio esterno, il server esegue controlli sulla rete (ad esempio, ping o disponibilità del sito web). Ogni approccio ha le sue limitazioni. Okerr utilizza entrambe le opzioni. I controlli all'interno dei server vengono eseguiti da un agente molto leggero (30Kb) o dai vostri script e applicazioni, mentre quelli di rete tramite i sensori okerr in diversi paesi.

okerr non è solo un software, ma anche un servizio

La parte server di qualsiasi monitoraggio è un elemento grande e complesso, difficile da installare e configurare, e richiede risorse. Con okerr, potete installare il vostro server di monitoraggio (è gratuito e open source), oppure semplicemente utilizzare solo la parte client e approfittare del servizio del nostro server. Anche questo è gratuito.

Se il monitoraggio consente di compensare e coprire la mancanza di affidabilità dei server e delle applicazioni, sorge un interrogativo filosofico: chi vigila il guardiano? Come ci informerà il monitoraggio di un problema se lui stesso è "morto" per qualche motivo, separatamente o insieme ad altre risorse (ad esempio, se salta il canale verso il data center)? Utilizzando il servizio esterno okerr, questo problema viene risolto: riceverai un avviso anche se l'intero data center con i tuoi server è senza energia o soggetto a un attacco di zombie.

Certo, c'è il rischio che il server okerr stesso non sia disponibile, è così (come è noto, il 90% di affidabilità si ottiene sempre in modo semplice e "gratuito", il 99% con il minimo sforzo e ogni successivo 9 è esponenzialmente più complesso). Ma, da un lato, le probabilità che ciò accada sono più basse e, dall'altro, il problema può rimanere inosservato solo se si verifica contemporaneamente a problemi sui nostri server. Se abbiamo un'affidabilità del 99,9% e tu hai il 99,9% (numeri non troppo elevati), allora la possibilità di un guasto non rilevato è dello 0,1% su 0,1% = 0,0001%. Aggiungere tre nove alla propria affidabilità quasi senza sforzo e senza costi è davvero ottimo!

Un altro vantaggio del monitoraggio come servizio è che il fornitore di hosting o lo studio web possono installare un server okerr e fornire accesso ai clienti come servizio aggiuntivo a pagamento o gratuito. I tuoi concorrenti offrono semplicemente hosting e siti web, mentre tu hai un hosting affidabile con monitoraggio.

Okerr è tutto sugli 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 homepage del progetto puoi subito vedere se hai tutto verde (e puoi chiudere), oppure se qualcosa lampeggia in rosso e deve essere sistemato. Al passaggio tra questi stati viene inviato un avviso. Una volta al giorno, finché non lo imposti, viene inviata una sintesi del progetto.

Ogni indicatore di okerr ha condizioni incorporate secondo le quali cambia stato (in Zabbix si chiama trigger). Ad esempio, la media di carico non deve superare 2 (ovviamente, questo è configurabile). E per ciascun controllo interno (media di carico, spazio disco libero, ...) c'è un watchdog. Se per qualche motivo non riceviamo una conferma positiva entro il tempo prestabilito, viene registrato un errore e viene inviato un avviso.

Il nostro schema di lavoro è semplice: controlliamo la posta al mattino e, tra le altre email, guardiamo il riepilogo (che pianifichiamo all'inizio del lavoro). Se va tutto bene, ci occupiamo di altre cose importanti (ma possiamo dare un rapido sguardo al dashboard di okerr per assicurarci che anche in quel momento tutto sia verde). Se arriva un avviso, interveniamo.

Certo, è possibile mantenere semplicemente degli "indicatori informativi" (per vedere la situazione della rete dal monitoraggio), ma tutto è stato progettato affinché sia semplice, veloce e facile creare indicatori per il monitoraggio automatico e l'invio di avvisi.

Il motivo per cui configuri okerr è negli avvisi, per poter creare un indicatore in un minuto. Può rimanere "inattivo" per un anno, ricevendo semplicemente aggiornamenti, e quando qualcosa si rompe dopo un anno, si accende e invia un avviso. Il minuto speso una volta per creare un indicatore si ripaga, perché sei informato del problema subito, prima di chiunque altro. È probabile che tu possa anche ripararlo prima che qualcun altro lo noti. Quello che è stato ripristinato rapidamente non è considerato caduto!

Sicurezza

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

L'agente (okerrmod dal pacchetto okerrupdate), che opera 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 un NAT ed è molto difficile (direi "impossibile") da hackerare tramite rete, poiché non ascolta un socket di rete.

Copertura completa del monitoraggio

Adesso abbiamo questa regola: veniamo a conoscenza di tutti i problemi tecnici tramite okerr. Se improvvisamente la regola viene violata (okerr non avvisa della sua imminente manifestazione (se possibile) o che è già avvenuta) – aggiungiamo controlli in okerr.

Controlli esterni

Un insieme abbastanza tipico:

ping
stato http
controllo della validità e della freschezza del certificato SSL (avviserà se la scadenza si avvicina)
porta TCP aperta e banner su di essa
grep http (una certa stringa [non] dovrebbe trovarsi sulla pagina)
hash sha1 per rilevare le modifiche della pagina.
DNS (il record DNS deve avere un certo valore)
WHOIS (avviserà se il dominio sta per scadere)
Antispam DNSBL (controllo dell'host immediatamente su oltre 50 blacklist antispam)

Controlli interni

Anch'esso, un insieme piuttosto standard (ma facilmente espandibile).

df (spazio libero sui dischi)
carico medio
opentcp (socket TCP in ascolto aperti - notifierà se qualcosa è stato avviato o è crollato)
uptime - semplicemente uptime del server. Notificherà se è cambiato in giù (cioè, il server si è riavviato)
client_ip
dirsize - lo usiamo per monitorare quando i nostri rootfs delle macchine virtuali superano la dimensione consentita, senza imporre limiti rigidi, e per le dimensioni delle directory home degli utenti
empty e nonempty - monitorano i file che dovrebbero essere vuoti (o non vuoti). Per esempio, l'error log del server stesso okerr - deve essere vuoto, e se contiene anche solo una riga - riceverò una notifica e controllerò. Mentre mail.log sul server di posta non deve essere vuoto (dopo N minuti dalla rotazione). A volte può essere vuoto, dopo un aggiornamento del sistema, quando logrotate non è riuscito a riavviare correttamente rsyslog.
linecount - numero di righe nel file (come wc -l). Lo usiamo come una sostituzione più morbida per empty, quando l'error log può comunque crescere, ma solo lentamente (per esempio, il googlebot scansiona alcune pagine riservate). C'è un limite di 2 righe ogni 20 minuti. Se supera - ci sarà un avviso

Controlli interni interessanti

Se finora hai letto «di fretta», ora sarà più interessante leggere attentamente.

backups

Monitora i backup nella directory. I file di backup hanno nomi del tipo «ServerName-20200530.tar.gz». Per ogni server in okerr viene creato un indicatore ServerName-DATE.tar.gz (la data effettiva viene sostituita con la riga «DATE»). Viene monitorata sia la presenza di un backup recente che la sua dimensione (ad esempio, non può essere inferiore al 90% del backup precedente).

Cosa bisogna fare affinché un nuovo backup inizi a essere monitorato, dopo che lo abbiamo iniziato a creare e a mettere in questa directory? Niente! È un approccio molto comodo, quando non bisogna fare «niente», perché:

Fare «niente» è piuttosto veloce, fa risparmiare tempo
È difficile dimenticare di fare «niente»
È difficile fare «niente» in modo errato, con errori. Nulla è il metodo più affidabile

Se all'improvviso smettono di apparire nuovi file di backup - ci sarà un avviso. Se ad esempio hai spento uno dei server, e i suoi backup non devono più esserci - sarà necessario eliminare l'indicatore (tramite interfaccia web o da shell tramite API).

maxfilesz

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

runstatus/runline

Questi sono due moduli proxy importanti per eseguire altri programmi sul server. Runstatus fornisce un'indicazione del codice di uscita del programma. Ad esempio, in okerr non c'è (non richiesto) un modulo per verificare che i servizi systemd siano attivi. Questo viene fatto tramite runstatus (vedi sotto). Runline informa sul server la stringa restituita dal programma. Ad esempio, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" nel configuratore Runline sul nostro server crea un indicatore servername:temp con la temperatura del processore.

sql

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

Ma un'applicazione molto più interessante è, ad esempio, monitorare il numero di ordini in un negozio online. Se sai che durante l'ora hai 100 ordini, puoi impostare una soglia minima di 100 o 80. Allora, se improvvisamente le vendite calano — riceverai un avviso e potrai affrontare la situazione.

Nota che non importa per quale imprevisto motivo ciò sia accaduto:

Il server è semplicemente non disponibile (senza energia o senza rete), e l'allerta è arrivata perché l'indicatore è 'scaduto'.
Il server è sotto carico, gira lentamente o ci sono pacchetti persi, rendendo difficile per gli utenti e molti se ne vanno senza acquistare
Il server è finito in liste di spam e le email non vengono accettate, gli utenti non possono registrarsi
Il budget per la campagna pubblicitaria è esaurito, i banner non vengono mostrati.

Le possibilità possono essere infinite, e non è possibile prevederle tutte in anticipo, ed è tecnicamente difficile da monitorare. Ma è possibile tenere d'occhio l'indicatore finale (gli ordini) e sulla base di essi determinare che la situazione è sospetta e merita attenzione.

Indicatori logici

Consente di utilizzare espressioni logiche (sintassi Python) tramite un modulo evalidate(articolo su habra). Per l'espressione sono disponibili i dati del progetto e dei suoi indicatori. Ad esempio, nel capitolo precedente sulla verifica SQL, potresti aver notato un punto debole: durante il giorno possiamo avere da 100 vendite all'ora, ma di notte — 20, ed è normale, non è un problema. Come gestirlo? 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). E creare un indicatore logico che richiede entro le 20:00 che l'indicatore diurno sia OK, e dopo le 20:00 basta che l'indicatore notturno sia OK.

Un altro esempio di utilizzo dell'indicatore logico è l'escalation. Ad esempio, il manager del progetto si disiscrive dagli avvisi (non ne ha bisogno, gli amministratori devono reagire ai problemi comuni), ma si iscrive all'indicatore logico che diventa rosso se qualsiasi indicatore nel progetto non è corretto entro il tempo prestabilito.

Inoltre, c'è la possibilità di assegnare un tempo autorizzato per il lavoro, ad esempio, dalle 3 alle 5 del mattino. Non ci interessa se i server e i siti "crollano" in questo momento. Ma alle 5:00 devono funzionare. Se non funzionano in qualsiasi altro momento — avviso. L'indicatore logico consente anche di considerare la riserva dei server. Se hai 5 server web, gli amministratori possono spegnere 1-2 server in qualsiasi momento. Ma se in funzione ci sono meno di 3 dei 5 server — ci sarà un avviso.

Gli esempi sopra non sono funzioni di okerr, né alcune funzionalità da attivare e configurare. Tutte queste funzioni non sono presenti in okerr, ma esiste un modulo logico che consente di implementare questa funzionalità (circa come in un linguaggio di programmazione — se abbiamo operatori aritmetici, allora non abbiamo bisogno di una funzione speciale del linguaggio per calcolare il 20% di IVA, può sempre essere fatta da soli per le proprie necessità).

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

Aggiunta delle proprie verifiche

Vorrei molto trasmettere l'idea che okerr non è un insieme di mille controlli pronti per ogni evenienza, ma piuttosto, prima di tutto, un motore semplice con la possibilità di creare i propri controlli. Creare i propri controlli in okerr non è un compito per hacker, co-sviluppatori del sistema, o almeno utenti avanzati di okerr, ma un compito fattibile per qualsiasi amministratore che un mese fa ha installato linux per la prima volta.

Le verifiche sui minimi vengono effettuate 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

Solo una riga — ed ecco che già siamo un po' espansi le funzionalità di okerr.

Anche un controllo di questo tipo — ha già il suo valore: se per caso il vostro server si arresta — l'indicatore corrispondente sul server okerr non verrà aggiornato in tempo, e dopo un certo periodo si attiverà un avviso.

Questo controllo avviserà che il server apache2 è andato giù (può succedere…):

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

Quindi, se possedete un linguaggio di programmazione, perlomeno potete scrivere degli script shell — allora potete già aggiungere i vostri controlli.

Più complesso — si può scrivere (in qualsiasi linguaggio) un modulo per okerrmod. Nel caso più semplice appare così:

#!/usr/bin/python3

print("STATUS: OK")

Non è vero che non è molto difficile? Il modulo deve effettuare il controllo stesso e restituire i risultati su STDOUT. Un modulo più complesso, ad esempio, fornisce quanto segue:

$ okerrmod --dump df
NOME: pi:df-\/ 
TAG: df
METODO: numerico|maxlim=90
DETTAGLI: 49.52%, 13.9G\/28.2G utilizzati, 13.0G liberi
STATO: 49.52

NOME: pi:df-\/boot
TAG: df
METODO: numerico|maxlim=90
DETTAGLI: 84.32%, 53.1M\/62.9M utilizzati, 9.9M liberi
STATO: 84.32

Aggiorna immediatamente diversi indicatori (separati da una riga vuota), crea loro se necessario, indica i dettagli del controllo e il tag, tramite il quale è facile trovare gli indicatori necessari nel dashboard.

C'è un bot di Telegram @OkerrBot. Non è necessario sovraccaricare il telefono con applicazioni separate (non mi piace affatto che per un supermercato serva un'app con la carta, per un altro un'altra, per MTS un'altra ancora, e così via per tutti). Un solo Telegram è sufficiente. Attraverso Telegram è possibile ricevere avvisi immediatamente, controllare lo stato del progetto e dare un comando per ricontrollare tutti gli indicatori problematici. Siamo usciti dal teatro\/aeroporto, dopo due ore che non tenevamo d'occhio la situazione, accendiamo la TV, premiamo un pulsante nel chatbot e ci assicuriamo che tutto sia a posto.

Pagine di stato

Al giorno d'oggi, le pagine di stato sono già quasi un must have per ogni azienda che possiede un IT, che ha un'attenzione responsabile alla affidabilità e che rispetta i propri clienti\/utenti.

Immagina una situazione: l'utente vuole fare qualcosa, cercare informazioni o effettuare un ordine, e qualcosa non funziona. Non sa qual è il problema, da che parte si trova e quando sarà risolto. Forse il sito della tua azienda è semplicemente inaccessibile? O si è rotto sei mesi fa e sarà riparato tra due anni? Ma il frigorifero deve essere acquistato subito, è già nel carrello... E tutto cambia quando l'utente vede che c'è un problema da parte vostra (almeno è chiaro che il problema non è dalla sua parte), che il problema è stato individuato, che state già lavorando per risolverlo e che magari avete anche fornito un tempo approssimativo per la riparazione. L'utente può iscriversi e ricevere un'email di notifica quando il problema sarà risolto e potrà fare ciò che voleva (comprare il frigorifero).

I problemi e i tempi di inattività capitano a tutti. Ma gli utenti e i partner si fidano di più di chi è più trasparente e affronta la situazione in modo responsabile.

Ecco una panoramica di 10 altri progetti che consentono di creare pagine di stato. Ecco alcuni esempi di come appaiono queste pagine nei progetti Python e Dropbox. Pagina di stato okerr.

Failover

Per non rendere questo articolo ancora più lungo, rimando ancora una volta al mio articolo precedente — Failover semplice per il sito web . Se puoi creare un server di backup, utilizzando il failover, non avrai praticamente tempi di inattività prolungati: non appena il problema viene rilevato, gli utenti vengono automaticamente reindirizzati a un server di backup funzionante. E mi sembra una funzione molto interessante e distintiva, che non si trova in molti luoghi.

Requisiti di sistema ridotti

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

Tenendo conto di questo — okerr, probabilmente, è il più gratuito un sistema di monitoraggio tra quelli esistenti, perché anche per utilizzare un altro sistema gratuito open source come Zabbix o Nagios, è necessario dedicare risorse (server), e questo comporta già dei costi. Inoltre, è comunque necessario un certo livello di manutenzione del server. Con okerr, questa parte può essere eliminata. Ma si può anche non eliminarla e utilizzare un proprio server, a seconda di come si preferisce.

API e integrazione nel proprio software

Un'architettura semplice e aperta. okerr ha un'interfaccia piuttosto intuitiva API, con la quale è facile lavorare. Vuoi creare 1000 indicatori? Un singolo script shell di 3-4 righe può farlo. Devi riconfigurare 1000 indicatori? Anche questo è molto semplice. Ad esempio, vogliamo ricontrollare tutti i nostri certificati HTTPS proprio utilizzando 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

È possibile aggiornare un indicatore sia usando il nostro modulo client che 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/

È possibile aggiornare gli indicatori direttamente dal proprio programma. Ad esempio, inviando segnali heartbeat affinché okerr sappia che è in esecuzione e generi un allerta se si arresta o si blocca. Tra l'altro, i componenti di okerr fanno esattamente questo: okerr sorveglia se stesso, e i problemi in quasi ogni modulo verranno rilevati e genereranno avvisi. (E per quanto riguarda questo «quasi», vengono verificati incrociando i dati con 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, è disponibile una libreria okerrupdate, per gli altri linguaggi non esistono librerie, ma si può chiamare lo script okerrupdate oppure eseguire una richiesta HTTP al server okerr.

Come ci aiuta okerr

Okerr ha cambiato la nostra vita. Davvero. Forse un altro sistema di monitoraggio potrebbe fare lo stesso, ma lavorare con okerr è semplice e intuitivo e include tutte le funzioni di cui avevamo bisogno (ciò che mancava l'abbiamo aggiunto noi). A proposito, se manca qualche funzionalità, chiedi e la aggiungerò (non lo prometto, ma voglio che okerr diventi il miglior sistema di monitoraggio per progetti medio-piccoli). Oppure, meglio ancora, aggiungila tu stesso: è semplice.

Abbiamo cominciato a vivere secondo il principio «scoprire tutti i problemi tramite okerr». Se, per caso, si verifica un problema di cui non abbiamo sentito parlare da okerr, aggiungiamo un controllo in okerr. (In questo caso, per «noi» intendo noi utenti del sistema, non i co-sviluppatori). All'inizio accadeva di frequente, ma ora è diventato molto raro.

Monitoraggio

Attraverso okerr monitoriamo le dimensioni dei log su tutti i server. Leggere ogni riga di log con attenzione è, ovviamente, impossibile, ma il monitoraggio semplice della crescita ci offre già molte informazioni. Grazie a questo abbiamo scoperto sia invii di spam sia attacchi di brute force per elencare le password, e quando alcune delle applicazioni «impazziscono», qualcosa non funziona e si ripetono di continuo (ogni volta aggiungendo qualche riga in più al log).

Certificati SSL. Poco dopo il lancio LetsEncrypt il nostro cliente ha iniziato a fornire ai propri clienti certificati SSL gratuiti (circa mille di essi). E questo si è rivelato un vero calvario per la gestione! Il fatto è che i siti sono «vivi», i clienti chiedono periodicamente di fare modifiche e i programmatori eseguono. Possono, ad esempio, trasferire liberamente il sito su un altro DocumentRoot. Oppure aggiungere un Rewrite incondizionato nella configurazione del virtual host. Naturalmente, dopo tali operazioni, l’aggiornamento automatico dei certificati si interrompe. Ora tutti i nostri host SSL vengono aggiunti automaticamente a okerr attraverso un'altra nostra utile utility del pacchetto a2conf. Basta eseguire a2okerr.py — e se sul server compaiono nuovi siti, essi appariranno automaticamente in okerr. Se per qualche motivo il certificato non si aggiorna, tre settimane prima della scadenza del certificato — siamo a conoscenza della situazione e ci occupiamo di capire perché non si aggiorna, che fastidio. a2certbot.py dello stesso pacchetto — è molto utile in questo (controlla immediatamente i problemi più probabili e segnala ciò che è andato bene e dove probabilmente ci sono problemi).

Monitoriamo la scadenza di tutti i nostri domini. Inoltre, tutti i nostri server di posta, che inviano email, vengono controllati su più di 50 blacklist diverse. (E a volte ci finiscono dentro). A proposito, sapevate che anche i server di posta di Google sono in blacklist? Semplicemente per autovalutarci, abbiamo aggiunto mail-wr1-f54.google.com ai server monitorati, e risulta essere nella blacklist SORBS! (Questo a proposito del valore degli «antispam»)

I backup — ho già scritto sopra come sia semplice tenerli d'occhio con okerr. Ma monitoriamo anche i backup freschi sul nostro server e (con l'aiuto di un'utilità separata che utilizza okerr) — i backup che carichiamo su Amazon Glacier. E, sì — a volte si presentano problemi. Non senza motivo che abbiamo monitorato.

Utilizziamo un indicatore di escalation. Mostra se qualche problema non viene risolto per lungo tempo. E anche io, quando risolvo alcuni compiti, a volte posso dimenticarli. L'escalation è una buona promemoria, anche se stai prestando attenzione a te stesso.

In generale, ritengo che la qualità del nostro lavoro sia migliorata notevolmente. Il downtime è quasi inesistente (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ù tranquille. Siamo passati da un lavoro frenetico a una gestione più pacata, in cui molti problemi possono essere previsti in anticipo e c'è tempo per prevenirli. Anche i problemi già verificatisi sono più facili da correggere: prima di tutto, li scopriamo prima che i clienti entrino nel panico; in secondo luogo, spesso accade che il problema è collegato a un lavoro recente (mentre si faceva una cosa, si è rotta un'altra) — quindi, a caldo, è più semplice intervenire.

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

Sapevate che nel popolare Debian 9 (Stretch) un pacchetto molto noto come phpmyadmin è ancora (da molti mesi!) in stato di vulnerabilità? (CVE-2019-6798). Quando è emersa la vulnerabilità, l'abbiamo rapidamente messa in sicurezza in vari modi. Ma ho impostato in okerr il monitoraggio della pagina di security-tracker, per sapere quando uscirà una soluzione "elegante" (tramite il checksum SHA1 del contenuto). Diverse volte l'indicatore mi ha allertato, la pagina è cambiata, ma come potete vedere — è ancora (da gennaio 2019!) che non è indicato che il problema sia stato risolto. Forse qualcuno sa di cosa si tratta, visto che un pacchetto così importante è vulnerabile da 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, è fondamentale controllarne l'esecuzione. (I subordinati tendono a non comprendere bene, a dimenticare, a confondersi, a commettere errori). Pertanto, prima di tutto abbiamo aggiunto un controllo della versione SSH su tutti i server in okerr e attraverso okerr abbiamo monitorato che gli aggiornamenti venissero applicati su tutti i server. (Comodo! Ho scelto questo tipo di indicatore e si vede subito su quale server è installata quale versione). Quando ci siamo assicurati che il compito fosse completato su tutti i server, abbiamo rimosso gli indicatori.

Un paio di volte ci siamo trovati nella situazione in cui un certo problema si presenta, ma poi si risolve da solo. (Probabilmente è familiare a tutti?). Finché ti accorgi, finché verifichi — e nel frattempo non c'è più nulla da controllare — funziona già tutto bene. Ma poi si rompe di nuovo. Questo è successo, ad esempio, con i prodotti che caricavamo su Amazon Marketplace (MWS). A un certo punto, l'inventario caricato era errato (quantità e prezzi sbagliati). Siamo riusciti a risolverlo. Ma per comprendere il problema era importante essere informati immediatamente. Sfortunatamente, MWS, come tutti i servizi di Amazon, è un po' lento, quindi c'era sempre un ritardo, ma comunque siamo riusciti a inquadrare almeno in parte il legame tra il problema e gli script che lo causano (abbiamo fatto un controllo, l'abbiamo collegato a okerr e abbiamo verificato immediatamente al ricevimento dell'allerta).

Un caso interessante è stato recentemente aggiunto al nostro bagaglio da un importante e costoso host europeo, utilizzato dal nostro cliente. Improvvisamente, tutti i nostri server sono scomparsi dai radar! All'inizio, il cliente stesso ha notato "manualmente" (più velocemente di Okerr!) che il sito con cui stava lavorando non si apriva e ha creato un ticket al riguardo. Ma non si trattava di un solo sito, ma di tutti! (Natasha, abbiamo fatto cadere tutto!). Qui Okerr ha iniziato a inviare lunghi report con tutti gli indicatori accesi. Panico, panico, corriamo in tondo (cosa altro possiamo fare?). Poi tutto è ripartito. Si è scoperto che nel data center erano in corso lavori programmati (una volta ogni molti anni) e ovviamente avrebbero dovuto avvertirci. Ma qualcosa è andato storto e non ci hanno informato. Un infarto in più, un infarto in meno. Ma dopo il ripristino di tutto, è necessario ricontrollare tutto! Non riesco nemmeno a immaginare come avrei fatto 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 anche ripresi correttamente. Tra tutte le perdite, abbiamo perso due backup che avrebbero dovuto essere creati e caricati in quel periodo in base alla programmazione, mentre si verificava questo completo disastro. Non li ho nemmeno creati, semplicemente dopo un giorno sono arrivati gli avvisi che era tutto OK, e i backup sono apparsi. Questo esempio mi piace molto, perché Okerr si è rivelato molto utile in una situazione di cui non avevamo nemmeno pensato in anticipo, ma è proprio questo il compito del monitoraggio: affrontare l'imprevedibile.

Per i sensori Okerr utilizziamo hosting il più economico possibile (qualità e affidabilità non sono importanti, si coprono a vicenda). Così, di recente, abbiamo trovato un hosting molto promettente e super economico, benchmark incredibili. Ma... a volte risulta che le connessioni in uscita dalle virtual machine vengono effettuate con un altro (adiacente) IP. Un miracolo. Il modulo client_ip con https://diagnostic.opendns.com/myip non riceve l'IP corretto. Inoltre, dai log del server di indicatori risulta che l'update è arrivato anch'esso da questo IP adiacente. Stiamo attualmente valutando la situazione con il supporto. È un bene che ce ne siamo accorti in tempo pacifico. Ma, ad esempio, spesso accade che l'accesso sia definito tramite una lista bianca di IP — e se il server a volte lampeggia per un breve periodo in questo modo — si potrebbe impiegare molto tempo a risolvere questo problema.

E un'altra cosa: dato che abbiamo parlato di hosting VPS, utilizziamo sempre soluzioni economiche (hetzner, ovh, scaleway). Sia per i benchmark che per la stabilità, ci piacciono molto. Usando anche l'Amazon EC2 molto più costoso per altri progetti, grazie a Okerr abbiamo un'opinione ben motivata. Entrambi cadono, sia quelli economici che quelli costosi. E non direi che, nel lungo periodo delle nostre osservazioni, gli hosting economici come hetzner siano stati significativamente meno stabili rispetto a EC2. Quindi, se non siete legati ad altre funzionalità di Amazon, perché pagare di più? 🙂

Cosa succede dopo?

Se a questo punto non vi ho già spaventato troppo da Okerr, provate! Potete accedere direttamente a un account demo di okerr (Cliccate subito!). Ma tenete conto che l'account demo è condiviso, quindi, se fate qualcosa, qualcun altro potrebbe disturbarvi nello stesso momento. Oppure (meglio) registratevi tramite il link sul sito ufficiale di okerr — tutto semplice, senza SMS. Se non volete utilizzare la vostra email reale, potete usare una temporanea, come quella di mailinator (Consiglio getnada.com). Tali account possono essere eliminati nel tempo, ma andrà bene per un test.

Dopo la registrazione, vi verrà chiesto di seguire un corso di formazione (completare alcuni compiti formativi piuttosto semplici). I limiti iniziali sono molto bassi, ma per il corso o un server sono sufficienti. Dopo aver completato la formazione, i limiti (ad esempio, il numero massimo di indicatori) verranno aumentati.

Dalla documentazione, in primo luogo WIKI per la parte server e il client (okerrupdate wiki). Ma se non è chiaro, scrivete a support (at) okerr.com o create un ticket e cercheremo di risolvere tutto rapidamente.

Se lo utilizzerete seriamente e questi limiti aumentati non saranno sufficienti, scrivete comunque al supporto, aumenteremo (gratuitamente).

Volete installare un server okerr sul vostro server? Ecco il repository okerr-dev. Consigliamo di installarlo su una virtual machine pulita, così sarà semplice farlo con uno script di installazione. Sulla propria virtuale, nessuna limitazione :-). E di nuovo, se avete bisogno di aiuto, saremo sempre disponibili.

Vogliamo che questo progetto decolli, affinché il mondo diventi più sicuro grazie a noi. Grazie a software e servizi gratuiti, il mondo è diventato più amichevole e si sviluppa in modo più dinamico. Il codice sorgente può essere conservato su github gratuito, per le email si può utilizzare gmail gratuito. Noi utilizziamo gratuiti freshworks per il supporto. Non è necessario pagare per nessuno di questi server, non è necessario scaricare e configurare e risolvere diversi problemi di utilizzo. Ogni nuovo progetto, ogni team ha subito email, repository e CRM. E tutto questo è di ottima qualità e gratuito, e immediatamente disponibile. Vogliamo che anche per il monitoraggio sia così: piccole aziende e progetti possano utilizzare gratuitamente okerr e avere affidabilità come quella di progetti seri già affermati, anche nella fase di nascita e crescita.

Fonte: habr.com