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

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

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

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

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

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 sysadmin-alert@befair.it

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%.

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.

Formato proposto da Luca:

server: [
  {
    timestamp: unix epoch,
    id-del-controllo1 : <valore1>,
    id-del-controllo2 : <valore2>,
    alert-limit : {
      id-del-controllo1 : <soglia>,
      id-del-controllo2 : <soglia>,
    }
  },
  { ... },
  { ... }
]

Questa proposta e' stata poi riadattata per InfluxDB 0.8 ed entrata in produzione da inizio dicembre 2014:

[{
   "name": "server",
   "columns": [
      "id-del-controllo1",
      "id-del-controllo2",
      "id-del-controllo3"
   ],
   "points": [
      [
        timestamp,
        valore1,
        valore2,
        valore3
      ],
      [
        timestampB,
        valore1B,
        valore2B,
        valore3B
      ],
      ...
   ]
}]

Al momento mancano tuttavia da archiviare i dati relativi all'occupazione di spazio nelle partizioni.

Inoltre bisognerebbe standardizzare il formato su InfluxDB secondo le nuove funzionalita' introdotte nella versione 0.9 (attualmente in sviluppo) e in generale guardando un po' piu' in la' secondo degli standard ad esempio introdotti da cAdvisor.

• cAdvisor: machine metrics, container metrics
• Salt ha il modulo status che fa proprio il lavoro dettagliato di monitoraggio, potremo riusare gli stessi nomi come standard. In particolare, loadavg puo' essere usato cosi' (e possiamo prenderne spunto):

check_load:
  status.loadavg:
    - name: 1-min
    - maximum: 1.2
    - minimum: 0.05
    - onfail:
      - pagerduty: loadavg_trigger

Da valutare:

• Sentry (Python)

Sentry è adatto per ricevere errori ed eccezioni, purtroppo non si presta molto bene a ricevere una serie di log temporali che devono essere poi in seguito aggregati ed analizzati

• Logster (Python)
• Logstash (Ruby), componente di Elastic Search

In una condizione ideale, le directory “stateful” da salvare in fase di migrazione di un server dovrebbero essere solamente queste:

• /root
• /home
• /var in generale
• /var/backups

Tutto il resto infatti dovrebbe essere rigenerato automaticamente dai playbook di Ansible.

TODO:

• prendere i vari scripts in /usr/local/bin e metterli in 1ring

• comparativa principali sw automazione: A B
• visita la sezione dedicata alla ricerca di nuove soluzioni
• come reagire automaticamente ad eventuali problemi? Runbook