shinken - scaler et redonder sa supervision
TRANSCRIPT
Scaler et redonder sa supervisionShinken a
a
a
400 Gbit/s de traffic
49 600m2 de datacenter production: DC{1..3}
construction: DC{4,5} 60 000 serveurs350 000 sites web
87 collaborateurs dont40 au support
30 ingés (13 Online / 17 cloud)
Online
Ce que ce talk n’est pas…
‣ Une comparaison des solutions de monitoring existantes ‣ Une thèse sur toutes les features de Shinken ‣ La possibilité de bakchich un admin en bière pour un mois de Dedibox gratis
(enfin…)
‣ Se rendre compte de la possibilité d’un soft cool ‣ La possibilité d’avoir une invit pour cloud.online.net (coucou moul)
Mais…
Problématiques (1)
Nagios Centreon ?
Problématiques (2)
Sysadm : « Nous n’avons pas reçu l’alerte, le monitoring était en carafe » Arnaud : « Allo quoi, toute ton infra est redontante mais pas ton monitoring »
Shinken
Quelques infos cools
✓ Nagios backward-compatible (conf/plugins)
✓ Loader sa conf autrement (Puppet/Salt/*SQL/…)
✓ Remontée MySQL (ndo2db) -> /dev/null
✓ Influxdb, graphite, … (modules en Python, rapide à développer)
✓ Soft cocorico
✓ Bonne doc, devs ouverts à la contribution
✓ Orienté business
define service{ use standard-service host_name ma-vraie-prod service_description mon-vraie-check-qui-me-reveille check_command bp_rule!(h1,database1 | h2,database2) & (h3,Http1 | h4,Http4) & (h5,IPVS1 | h6,IPVS2) }
Shinken, in a "nutshell"Arbiter: * Centralise la config, la déploie en la splittant, monitoring des autres éléments
Scheduler: * Gère 3 queues : « actions », « reactions », « stockages » Reactionner: * Demande au schedulers les actions à exec puis les ./actions (mail/sms/curl/…)
Poller: * Recup les checks via le Scheduler, les exec, renvoie les résultats au Scheduler
Broker: * Récupère les données sur les schedulers pour envoyervia des modules de "données brutes" (mysql, couchbase, influxdb, …)
Scaler (ou graduer*)
Arnaud: « Je veux un check toutes les minutes » Esclave: « Mais la machine est déjà saturée en CPU, on peut pas »
Solution: Ajouter un scheduler + pollerredéployer…
respirer…
* Journal officiel du 14/12/2004
Arnaud: « On met en prod 1000 nouveaux serveurs semaine prochaine » Esclave: « Mais le monitoring ne tiendra jamais la charge »
ou
Dormir tranquille
Poller
Sched.
Broker
React.
DC1 DC2
«RAID1» puis…
Arbiter
Poller
Sched.
Broker
React.
Arbiter
Cas pratique
Monitoring client Dedibox:
# rm ping.pl # pip install shinken
PollerDC2-1
ArbiterPollerDC3-2
SchedDC2-1
SchedDC3-2
BrokerDC2-1
BrokerDC3-2
React.DC2-1
PollerDC3-1
SchedDC3-1
BrokerDC3-1
React.DC3-1
React.DC3-2
PollerDC2-2
SchedDC2-2
BrokerDC2-2
React.DC2-2
DC2 DC3
le client, premier beta-testeur depuis 1884
Cas pratique
Monitoring client Dedibox:
# rm ping.pl # pip install shinken
PollerDC2-1
Arbiter
PollerDC2-N
PollerDC3-2
SchedDC2-1
SchedDC2-N
SchedDC3-2
BrokerDC2-1
BrokerDC3-2
React.DC2-1
PollerDC3-1
SchedDC3-1
BrokerDC3-1
React.DC3-1
PollerDC3-N
SchedDC3-N
React.DC3-2
PollerDC2-2
SchedDC2-2
BrokerDC2-2
React.DC2-2
DC2 DC3
le client, premier beta-testeur depuis 1884
… …
Cas pratique
Monitoring client Dedibox:
• 2 serveurs par datacenter • 4 pollers
• 40 000 serveurs monitorés ✓ 1x check Ping ✓ 2x check IPMI ✓ checks additionnels du client
le client, premier beta-testeur depuis 1884
define service{ use standard-service host_name srv1 service_description mon-service-qui-reboot-elec-auto check_command bp_rule!(srv1,check_ping & srv1,check_ping_ipmi & srv1,check_ipmi_mc_status) }
➡Tour du parc en moins de 5 min
