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 che pero' verra' risolto nel 2015 con l'aggiunta di un backend). 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

Su befair2 si possono visualizzare le metriche delle applicazioni servite con uWSGI.

Ad esempio per visualizzare le info relativa all'installazione in produzione di gasista felice (gf_prod):

# workon admin
# uwsgitop 127.0.0.1:11001

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.

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

Avevo in mente di realizzare un modulo personalizzato ping_icmp come consigliato da Andrea, a questo punto possiamo farlo un po' piu' complesso per fare anche questo.

Questo modulo potrebbe prendere in ingresso:

• server da pingare
• numero di pacchetti (con un default tipo a 10)
• timeout warning (oltre il quale pacchetto lento, colore giallo, con

default a… 5?)

• timeout assoluto (oltre il quale pacchetto perso, colore rosso, con

default a… 30?)

In output potrebbe essere qualcosa come:

{
  pacchetti_ok:  valore
  pacchetti_lenti:  valore
  pacchetti_persi:  valore
  percentuale_pacchetti_ok:  valore_percentuale
  percentuale_pacchetti_lenti:  valore_percentuale
  percentuale_pacchetti_persi:  valore_percentuale
}

I casi d'uso sarebbero:

• verificare che, pingango dal nostro master, un nostro server sia raggiungibile (caso proposto da Andrea, sulla scia di CloudWatch)
• verificare i tempi di latenza da quel server verso un server esterno tipo 8.8.8.8

Come in Sanet si dovrebbe registrare la latenza nella serie e mostrare una barra rossa in caso di pacchetti persi. Gialla se possibile quando la latenza supera una certa soglia.

TODO:

• dashboard per tutti i server
• torte per spazio partizioni
• ping con latenza

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:

• dati relativi all'occupazione di spazio delle partizioni
• ping con latenza

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

Proposte come nomi delle serie.

machine.machineA.loadavg machine.machineA.mem_usage

container.container1.ram_usage

apps.appA.ram_usage

Se abbiamo:

• 10 machines
• 5 app /machine
• 3 container /app

Numero di serie:

• 5 values /machine /minute
• 10 values /app /second
• 20 values /container /second

In un secondo abbiamo circa:

• valori delle macchine trascurabili
• 10 values * 5 apps * 10 machines → 500/s
• 20 values * 3 container * 5 apps * 10 machines → 3000/s

Attualmente il limite con un cluster da 3 e' sui 1-2M/s