Differences

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

--- sysadmin:resmonitor [2015/01/11 14:48] – creata 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.
-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 ''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%.
-===== 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''.
-===== 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 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: [[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