Quelles réponses apportées aux contraintes de volumétrie et performance ? Présentation réalisée par Ikoula lors du Meet-up Paris Monitoring.

1. Évolution de la supervision 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. Un peu d’histoire

4. 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

5. Fping & rsyslog
et les escalades par e-mail

6.  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

7.  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

8. 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

9. Servers Alive

10.  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

11.  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

12. 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

13. Automatisation de l’inventaire

14.  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

15.  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

16.  Solution open source
 Modulable
 Gestion dynamique de l’inventaire
 Processus PHP multithread
 Grande réactivité
 Solution nouvelle et peu connue
Zabbix

17. Utilisation de templates

18.  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…

19. 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

20. Utilisation d’agents

21.  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

22.  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

23. 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

24. Éclatement de l’infra

25. 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

26.  Analyse des slow 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 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

28. Zabbix 2.x

29.  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 ?

30.  Utilisation de XtraDB
 Partitionnement des tables d’historique pour archivage des
valeurs les plus anciennes
Optimisations bdd

31.  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

32.  https://www.ikoula-blog.com
 https://fr.ikoula.wiki
 https://zabbix.org
Ressources

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
Ikoula Hosting Services
Ikoula
Ikoula
Gardez le contact !
AUTEUR : NICOLAS TRAUWAEN