Évolution de la supervision chez Ikoula

É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

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

 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

 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

 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

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

 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

Contenu connexe

Similaire à Évolution de la supervision chez Ikoula

Évolution de la supervision chez Ikoula