1ring: Automating Ops

L'obiettivo e' di passare da un approccio artigianale nell'amministrazione di tutti i server gestiti da beFair ad uno piu' industriale, ovvero automatizzando tutta una serie di operazioni tra cui:

deploy e monitoraggio delle applicazioni

monitoraggio dei processi principali (attivi e disattivi)

monitoraggio delle risorse hardware (CPU load, RAM, Swap, disco..)

assicurarsi che tutti i server siano sempre accessibili via SSH

test sugli URL e redirect (verifica ritorno status code 200/30x su richieste HTTP)

inviare notifiche a sysadmin-alert@befair.it nel caso di errori o superamento di alcune soglie

I luoghi di riferimento di questo progetto sono:

questa stessa pagina wiki

l'alias sysadmin@befair.it

gli alert arrivano all'alias sysadmin-alert@befair.it

Repository Git

Il master (befair2) dispone di un repository Git in /root/1ring contenente del codice per Ansible, strutturato a partire dalle buone pratiche consigliate. In breve:

doc/ documentazione
inventories/ info su tutti gli host e gruppi di host
group_vars/ dati sui gruppi di host
group_files/ file ricorrenti tra piu' host, come le chiavi SSH
host_vars/ dati per ogni singolo host
host_files/ file specifici per host
prod.ini inventario con tutti gli host e i gruppi
dev.ini inventario per i test
playbooks/ script da lanciare, applica 1+ role ad 1+ host
jobs_high.yml script per i task ad alta priorita' (ogni 10 minuti)
jobs_low.yml script per i task giornalieri
roles/ contiene i role, cioe' i "pacchetti" di Ansible
secrets/ contiene l'archivio keepassx ed eventualmente altri file cifrati
utils/ script di varia utilita'
ansible.cfg file principale di configurazione
README.rst guida per installare/configurare Ansible

Nota: per info sui nostri role tutti i dettagli qui

FAQ

Alcune FAQ su dove trovare cosa:

archivio keepassx? secrets/befair.kdb

chiavi SSH? inventories/group_files/all/ssh/id_*.pub

info sulle installazioni di Gasista Felice? inventories/host_vars/befair2.yml → gf_flavours

messaggio motd per host befair0? inventories/host_vars/befair0.yml → motd

demoni/processi per host spes_hosting? inventories/host_vars/spes_hosting.yml

limite swap su tutti i server spes? inventories/group_vars/spes.yml → swap_perc_limit

info per accedere via SSH ai server? inventories/group_vars/staff.yml → hosts

ci sono variabili globali? inventories/group_vars/all.yml

Il repository Git disponde di 2 branch:

master: branch di sviluppo dove pushiamo direttamente le modifiche (dopo aver fatto pull + rebase)

prod: branch di checkout, attivo sul server che verra' usato

L'idea e' fare periodicamente il rebase del branch prod con il master.

E' possibile clonarsi il repository in locale con:

$ git clone root@befair2.befair.it:1ring

Monitoraggio delle risorse

Al momento vengono archiviati i dati relativi al load_avg e alla memoria. Con l'imminente uscita di InfluxDB 0.9 che dovrebbe aggiungere funzionalita' e standardizzare la struttura dei dati, aggiungeremo anche il supporto alle partizioni che e' rimasto temporaneamente escluso.

E' possibile accedere all'interaccia web Grafana:

$ ssh root@befair2 -L 8889:localhost:8889 -L 8086:localhost:8086

Ora visitare http://localhost:8889/

Ho aggiunto solo un paio di grafici, ma se ne possono aggiungere altri (anche se non vengono memorizzati sul server ← IMHO questo e' l'unico vero problema di Grafana). Per ulteriori info sulla configurazione di Grafana vedere http://grafana.org/docs/features/influxdb/

Inoltre e' possibile accedere ai dati da client Python:

$ ssh root@befair2

# workon 1ring && ipython

> from influxdb import InfluxDBClient
> client = InfluxDBClient(host='127.0.0.1', port=8086,
username='1ring', password='fajw49849f4jp', database='1ring')

Ecco 3 query di esempio:

> client.get_list_series()
> client.query('select mem_usage from befair1')
> client.query('select * from befair1')

Per info sul linguaggio per le query vedere http://influxdb.com/docs/v0.8/api/query_language.html

Alert per CPU

Il limite e' sul load_avg normalizzato, ovvero il load_avg diviso per il numero di core. Se il limite e' 3 e un VPS ha 2 core, viene inviata una mail nel caso il load_avg supera 6 (3 * 2).

Alert per memoria e disco

Sono attive notifiche via Mail e XMPP (che in futuro potrebbero passare a Telegram, al momento non c'e' un modulo apposito):

se un valore supera il limite che ci siamo dati (es: 80% spazio di una partizione) –> warning –> notifica XMPP

se un valore supera la meta' di quel che e' rimasto (es: 90% di una partizione) –> critical –> notifica mail a tutti i sysadmin

Quindi se un limite e' all'85%, la notifica via mail arriva al 92.5%, se invece il limite e' al 50%, la notifica via mail arriva al 75%.

Ricevere gli alert

Per modificare gli account a cui inviare gli alert via XMPP, modificare il file inventories/group_vars/all.yml variabile alert_xmpp_accounts in 1ring.

Per gli alert via mail, modificare il file /etc/aliases variabile sysadmin-alert nel server befair/jagom, quindi dare newaliases && service postfix reload.

Monitoraggio dei log (TODO)

Da valutare:

Sentry (Python)

Logster (Python)

Logstash (Ruby), componente di Elastic Search

Approfondimenti

comparativa principali sw automazione: A B

visita la sezione dedicata alla ricerca di nuove soluzioni

come reagire automaticamente ad eventuali problemi? Runbook