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