Differences

This shows you the differences between two versions of the page.

--- sysadmin:resmonitor [2015/01/11 15:08] – [WebUI] kobe
+++ sysadmin:resmonitor [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-====== 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.
-===== Quickstart =====
-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/
-==== CLI ====
-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
-===== Alerts =====
-==== Come ricere 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''.
-==== CPU, carico del sistema ====
-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).
-==== 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 ''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%.
-==== Ping latency ====
-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.
-===== Dashboard =====
-TODO:
-  * dashboard per tutti i server
-  * torte per spazio partizioni
-  * ping con latenza
-===== Standard per metriche =====
-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: [[https://github.com/google/cadvisor/blob/master/info/machine.go|machine metrics]], [[https://github.com/google/cadvisor/blob/master/info/container.go|container metrics]]
-  * Salt ha il modulo [[http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.status.html|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