Differences

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

--- sysadmin:automation [2015/01/11 14:16] – [Standard per metriche] kobe
+++ sysadmin:automation [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-====== 1ring: Automating Ops ======
-L'obiettivo e' di passare da un approccio //artigianale// nell'amministrazione [[inventory|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:
-  * [[automation|questa stessa pagina wiki]]
-  * l'alias ''sysadmin@befair.it''
-  * gli alert arrivano all'alias ''sysadmin-alert@befair.it''
-===== Repository Git =====
-Il **master** (''befair2'') dispone di un repository Git in ''/root/1ring'' contenente del codice per Ansible, strutturato a partire dalle [[http://docs.ansible.com/playbooks_best_practices.html|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 [[Ansible|tutti i dettagli qui]]
-==== FAQ ====
-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
-===== 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
-===== Monitoraggio dei log (TODO) =====
-Da valutare:
-  * [[https://github.com/getsentry/sentry|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
-  * [[https://github.com/etsy/logster|Logster]] (Python)
-  * [[https://github.com/elasticsearch/logstash|Logstash]] (Ruby), componente di [[http://www.elasticsearch.org/overview/|Elastic Search]]
-===== Backups =====
-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
-===== Approfondimenti =====
-  * comparativa principali sw automazione: [[http://www.slideshare.net/fullscreen/geerlingguy/devops-for-humans-ansible-for-drupal-deployment-victory/18 | A]] [[https://devopsu.com/books/Taste-Test-Quick-Look-Grid.pdf | B]]
-  * visita la [[labs|sezione dedicata alla ricerca di nuove soluzioni]]
-  * come reagire automaticamente ad eventuali problemi?  [[https://runbook.io|Runbook]]