Évolution de la supervision chez Ikoula
Quellessontlesréponses apportéesauxcontraintes
devolumétrieetdeperformance?
AUTEUR : NICOLAS TRAUWAEN
Qui est ikoula ?
Création : 1998
8 000 OS en
production
Effectif : 47 employés
5 000 serveurs
physiques
2 datacenters en
France et présence
sur 3 continents
Un peu d’histoire
Volumétrie
0
5
10
15
20
25
1998
Nb serveurs
0
5
10
15
20
25
1998
Nb OS
0
0,2
0,4
0,6
0,8
1
1,2
1998
Mires par OS
0
5
10
15
20
25
1998
Nb mires totales
Fping & rsyslog
et les escalades par e-mail
 Un script fping au milieu du réseau
 Une simple configuration rsyslog + un relai SMTP
 Configuration appliquée dans l’image de déploiement
 Pas besoin de se connecter aux machines pour consulter les logs
Avantages
 Devient vite chronophage pour détecter les alarmes des
avertissements
 Difficulté à gérer les changements
 Pas adapté à une quantité de serveurs grandissante
 N’assure pas une supervision de la disponibilité des machines
Inconvénients
Volumétrie
0
20
40
60
80
100
120
1998 2000
Nb serveurs
0
20
40
60
80
100
120
1998 2000
Nb OS
0
0,5
1
1,5
2
2,5
1998 2000
Mires par OS
0
50
100
150
200
250
1998 2000
Nb mires totales
Servers Alive
 Supervision simple via le réseau
 Test des ports en écoute
 ICMP ping
 Pas d’agent ni de configuration locale
 Serveur central avec un tableau de bord des alarmes
Avantages
 Gestion de l’inventaire manuel
 Obligation de couper / relancer le service à chaque mise à jour
de l’inventaire
 Pas de redondance du service de supervision
Inconvénients
Volumétrie
0
200
400
600
800
1000
1200
1998 2000 2004
Nb serveurs
0
200
400
600
800
1000
1200
1998 2000 2004
Nb OS
0
1
2
3
4
5
6
1998 2000 2004
Mires par OS
0
1000
2000
3000
4000
5000
6000
1998 2000 2004
Nb mires totales
Automatisation de l’inventaire
 Fichier d’inventaire en XML
 Script pour synchronisation entre SI et SAlive
 Toutes les alarmes sont réinitialisées à chaque relance du service
 Quelle fréquence de synchronisation ?
SAlive
 Solution open source
 Modulable
 Gestion dynamique de l’inventaire
 Processus CGI mono thread
 Peu réactif
 Développement nécessaire pour améliorer les performances
Nagios
 Solution open source
 Modulable
 Gestion dynamique de l’inventaire
 Processus PHP multithread
 Grande réactivité
 Solution nouvelle et peu connue
Zabbix
Utilisation de templates
 Tout modéliser est impossible
 Multiplication des mires « inutiles » avec des templates à large spectre
 Attention au « il vaut mieux trop que trop peu »
 Trouver l’équilibre entre modèle et personnalisation
Les templates c’est bien, mais…
Volumétrie
0
500
1000
1500
2000
2500
1998 2000 2004 2006
Nb serveurs
0
500
1000
1500
2000
2500
1998 2000 2004 2006
Nb OS
0
2
4
6
8
10
12
1998 2000 2004 2006
Mires par OS
0
5000
10000
15000
20000
25000
1998 2000 2004 2006
Nb mires totales
Utilisation d’agents
 Les mires systèmes en « built-in »
 Possibilité de personnaliser la supervision avec des
« UserParameters »
 Agent en mode passif
 Si le serveur ne répond pas, l’agent conserve les relevés jusqu’à
la prochaine synchronisation
Avantages
 Gestion des configurations personnalisées
 Risque d’ « information disclosure » avec les UserParameters
 Charge de traitement sur le serveur maître avec agents passifs
 Ouverture de ports supplémentaires par machine
Inconvénients
Volumétrie
0
1000
2000
3000
4000
5000
1998 2000 2004 2006 2010
Nb serveurs
0
1000
2000
3000
4000
5000
6000
1998 2000 2004 2006 2010
Nb OS
0
5
10
15
20
25
1998 2000 2004 2006 2010
Mires par OS
0
20000
40000
60000
80000
100000
120000
1998 2000 2004 2006 2010
Nb mires totales
Éclatement de l’infra
Base de données
redondée
Moteur zabbix central
Proxy
zabbix
Proxy
zabbix
Proxy
zabbix
Proxy
zabbix
Proxy
zabbix
Tableau
de bord
dans
l’intranet
Proxy zabbix
Base de
données
Moteur zabbix
Tableau
de bord
dans
l’intranet
et
extranet
Avant Après
3 serveurs 9 serveurs et plus
 Analyse des slow queries
 Ajout d’index sur les tables les plus consultées
 Passage des tables temporaires en RAMDISK
 Optimisations InnoDB
Optimisations bdd
Volumétrie
0
1000
2000
3000
4000
5000
6000
1998 2000 2004 2006 2010 2015
Nb serveurs
0
2000
4000
6000
8000
10000
1998 2000 2004 2006 2010 2015
Nb OS
0
10
20
30
40
50
1998 2000 2004 2006 2010 2015
Mires par OS
0
50000
100000
150000
200000
250000
300000
350000
1998 2000 2004 2006 2010 2015
Nb mires totales
Zabbix 2.x
 Autodiscover des ressources locales
 Utilisation de macros
 Possibilité de placer les personnalisations en base (scripts,
commandes, etc.)
 Passage des agents en mode actif
 Modélisation des webscénarii
 API zabbix
Changements ?
 Utilisation de XtraDB
 Partitionnement des tables d’historique pour archivage des
valeurs les plus anciennes
Optimisations bdd
 Découverte automatique des instances dans le Cloud public et
privé
 Meilleure intégration de la supervision des OS « dockerisés »
(CoreOS, rancherOS)
 Supervision des ressources par conteneur (cadvisor like)
 Analyse prédictive de comportements
Évolutions à venir
 https://www.ikoula-blog.com
 https://fr.ikoula.wiki
 https://zabbix.org
Ressources
Rejoignez-nous !
R & D
Reims (51)
Créatifs et passionnés par l’innovation,
intégrez la R&D !
Commerciaux
Boulogne-Billancourt (92)
Conseiller et imaginer des solutions pour
répondre à un besoin vous motive ?
Rejoignez nos équipes commerciales et
avant-vente
Exploitation
Reims (51)
Attirés par l’accompagnement utilisateur
et l’administration système, le support
est fait pour vous.
D’autres compétences ?
N’hésitez pas à nous proposer votre
candidature spontanée !
jobs@ikoula.com
https://www.ikoula.com/fr/emploi
@ikoula ou @ikoula_EN
Ikoula Hosting Services
Ikoula
Ikoula
Gardez le contact !
AUTEUR : NICOLAS TRAUWAEN

Évolution de la supervision chez Ikoula

  • 1.
    Évolution de lasupervision chez Ikoula Quellessontlesréponses apportéesauxcontraintes devolumétrieetdeperformance? AUTEUR : NICOLAS TRAUWAEN
  • 2.
    Qui est ikoula? Création : 1998 8 000 OS en production Effectif : 47 employés 5 000 serveurs physiques 2 datacenters en France et présence sur 3 continents
  • 3.
  • 4.
  • 5.
    Fping & rsyslog etles escalades par e-mail
  • 6.
     Un scriptfping au milieu du réseau  Une simple configuration rsyslog + un relai SMTP  Configuration appliquée dans l’image de déploiement  Pas besoin de se connecter aux machines pour consulter les logs Avantages
  • 7.
     Devient vitechronophage pour détecter les alarmes des avertissements  Difficulté à gérer les changements  Pas adapté à une quantité de serveurs grandissante  N’assure pas une supervision de la disponibilité des machines Inconvénients
  • 8.
    Volumétrie 0 20 40 60 80 100 120 1998 2000 Nb serveurs 0 20 40 60 80 100 120 19982000 Nb OS 0 0,5 1 1,5 2 2,5 1998 2000 Mires par OS 0 50 100 150 200 250 1998 2000 Nb mires totales
  • 9.
  • 10.
     Supervision simplevia le réseau  Test des ports en écoute  ICMP ping  Pas d’agent ni de configuration locale  Serveur central avec un tableau de bord des alarmes Avantages
  • 11.
     Gestion del’inventaire manuel  Obligation de couper / relancer le service à chaque mise à jour de l’inventaire  Pas de redondance du service de supervision Inconvénients
  • 12.
    Volumétrie 0 200 400 600 800 1000 1200 1998 2000 2004 Nbserveurs 0 200 400 600 800 1000 1200 1998 2000 2004 Nb OS 0 1 2 3 4 5 6 1998 2000 2004 Mires par OS 0 1000 2000 3000 4000 5000 6000 1998 2000 2004 Nb mires totales
  • 13.
  • 14.
     Fichier d’inventaireen XML  Script pour synchronisation entre SI et SAlive  Toutes les alarmes sont réinitialisées à chaque relance du service  Quelle fréquence de synchronisation ? SAlive
  • 15.
     Solution opensource  Modulable  Gestion dynamique de l’inventaire  Processus CGI mono thread  Peu réactif  Développement nécessaire pour améliorer les performances Nagios
  • 16.
     Solution opensource  Modulable  Gestion dynamique de l’inventaire  Processus PHP multithread  Grande réactivité  Solution nouvelle et peu connue Zabbix
  • 17.
  • 18.
     Tout modéliserest impossible  Multiplication des mires « inutiles » avec des templates à large spectre  Attention au « il vaut mieux trop que trop peu »  Trouver l’équilibre entre modèle et personnalisation Les templates c’est bien, mais…
  • 19.
    Volumétrie 0 500 1000 1500 2000 2500 1998 2000 20042006 Nb serveurs 0 500 1000 1500 2000 2500 1998 2000 2004 2006 Nb OS 0 2 4 6 8 10 12 1998 2000 2004 2006 Mires par OS 0 5000 10000 15000 20000 25000 1998 2000 2004 2006 Nb mires totales
  • 20.
  • 21.
     Les miressystèmes en « built-in »  Possibilité de personnaliser la supervision avec des « UserParameters »  Agent en mode passif  Si le serveur ne répond pas, l’agent conserve les relevés jusqu’à la prochaine synchronisation Avantages
  • 22.
     Gestion desconfigurations personnalisées  Risque d’ « information disclosure » avec les UserParameters  Charge de traitement sur le serveur maître avec agents passifs  Ouverture de ports supplémentaires par machine Inconvénients
  • 23.
    Volumétrie 0 1000 2000 3000 4000 5000 1998 2000 20042006 2010 Nb serveurs 0 1000 2000 3000 4000 5000 6000 1998 2000 2004 2006 2010 Nb OS 0 5 10 15 20 25 1998 2000 2004 2006 2010 Mires par OS 0 20000 40000 60000 80000 100000 120000 1998 2000 2004 2006 2010 Nb mires totales
  • 24.
  • 25.
    Base de données redondée Moteurzabbix central Proxy zabbix Proxy zabbix Proxy zabbix Proxy zabbix Proxy zabbix Tableau de bord dans l’intranet Proxy zabbix Base de données Moteur zabbix Tableau de bord dans l’intranet et extranet Avant Après 3 serveurs 9 serveurs et plus
  • 26.
     Analyse desslow queries  Ajout d’index sur les tables les plus consultées  Passage des tables temporaires en RAMDISK  Optimisations InnoDB Optimisations bdd
  • 27.
    Volumétrie 0 1000 2000 3000 4000 5000 6000 1998 2000 20042006 2010 2015 Nb serveurs 0 2000 4000 6000 8000 10000 1998 2000 2004 2006 2010 2015 Nb OS 0 10 20 30 40 50 1998 2000 2004 2006 2010 2015 Mires par OS 0 50000 100000 150000 200000 250000 300000 350000 1998 2000 2004 2006 2010 2015 Nb mires totales
  • 28.
  • 29.
     Autodiscover desressources locales  Utilisation de macros  Possibilité de placer les personnalisations en base (scripts, commandes, etc.)  Passage des agents en mode actif  Modélisation des webscénarii  API zabbix Changements ?
  • 30.
     Utilisation deXtraDB  Partitionnement des tables d’historique pour archivage des valeurs les plus anciennes Optimisations bdd
  • 31.
     Découverte automatiquedes instances dans le Cloud public et privé  Meilleure intégration de la supervision des OS « dockerisés » (CoreOS, rancherOS)  Supervision des ressources par conteneur (cadvisor like)  Analyse prédictive de comportements Évolutions à venir
  • 32.
  • 33.
    Rejoignez-nous ! R &D Reims (51) Créatifs et passionnés par l’innovation, intégrez la R&D ! Commerciaux Boulogne-Billancourt (92) Conseiller et imaginer des solutions pour répondre à un besoin vous motive ? Rejoignez nos équipes commerciales et avant-vente Exploitation Reims (51) Attirés par l’accompagnement utilisateur et l’administration système, le support est fait pour vous. D’autres compétences ? N’hésitez pas à nous proposer votre candidature spontanée ! jobs@ikoula.com https://www.ikoula.com/fr/emploi
  • 34.
    @ikoula ou @ikoula_EN IkoulaHosting Services Ikoula Ikoula Gardez le contact ! AUTEUR : NICOLAS TRAUWAEN

Notes de l'éditeur

  • #5 Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • #9 Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • #13 Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • #16 Modulable : plugins, scripts Réactivité « out of the box » : plus de 30 minutes pour faire le tour de l’inventaire et détecter un changement, pour le temps réel… c’est loupé
  • #17 Modulable : plugins, scripts Réactivité « out of the box » : moins d’une minute pour détecter un problème De mémoire, on a commencé à travailler avec la v0.6 ou v0.8
  • #19 Il y a forcément des cas particuliers Attention : fréquence de check entre 2 valeurs trop haute
  • #20 Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • #22 Mode passif : le serveur vient chercher l’information. Agent peu gourmand en ressources locales
  • #23 Ex : MDP MySQL en clair dans le fichier de configuration
  • #24 Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • #26 Problèmes de perf au niveau du master Nvps (nouvelles valeurs par seconde) trop élevé pour notre infra -> obligation de se raisonner Charge de consultation induite par le tableau de bord interne et client
  • #27 Innodb : augmentation des caches et du buffer pool
  • #28 Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • #29 Choix sur 2.2 parce que LTS Mieux adaptée aux grosses infra Amélioration des perfs sur la consultation des données (cache, etc.) Refonte de l’infra matérielle
  • #30 Autodiscover des ressources locale Macros : utilisation de variables pour les MDP, hostname, etc. stockées en base et non dans le fichier de conf de l’agent UserParameters : la conf des agents peut enfin devenir standard Mode actif : permet de réduire la charge de traitement du serveur zabbix Seules les IP des relais et du serveur zabbix sont diffusées API : intéressante mais certaines améliorations à faire… toutes fonnctions non dispo perf parfois inférieures à un appel direct en base
  • #31 Passage à percona : XtraDB en mode standalone, pas cluster parce que pb lock de table Zabbix a besoin de lock ses tables, lorsque ça arrivait, les autres nœuds n’étaient pas au courant du statut ce qui engendrait des erreurs Partitionnement : Housekeeper : (garbage collector) très consommateur en ressources sur master une partition par mois d’historique delete de la partition en fin d’archivage désactivation du housekeeper gain de perf globale car les
  • #32 Zabbix 3.x Etc.