Évolution de la supervision chez Ikoula
Quellessontlesréponses apportéesauxcontraintes
devolumétrieetdeperformance?
AUTEUR...
Qui est ikoula ?
Création : 1998
8 000 OS en
production
Effectif : 47 employés
5 000 serveurs
physiques
2 datacenters en
F...
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...
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’...
 Devient vite chronophage pour détecter les alarmes des
avertissements
 Difficulté à gérer les changements
 Pas adapté ...
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
M...
Servers Alive
 Supervision simple via le réseau
 Test des ports en écoute
 ICMP ping
 Pas d’agent ni de configuration locale
 Serve...
 Gestion de l’inventaire manuel
 Obligation de couper / relancer le service à chaque mise à jour
de l’inventaire
 Pas d...
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...
Automatisation de l’inventaire
 Fichier d’inventaire en XML
 Script pour synchronisation entre SI et SAlive
 Toutes les alarmes sont réinitialisées à ...
 Solution open source
 Modulable
 Gestion dynamique de l’inventaire
 Processus CGI mono thread
 Peu réactif
 Dévelop...
 Solution open source
 Modulable
 Gestion dynamique de l’inventaire
 Processus PHP multithread
 Grande réactivité
 S...
Utilisation de templates
 Tout modéliser est impossible
 Multiplication des mires « inutiles » avec des templates à large spectre
 Attention au ...
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...
Utilisation d’agents
 Les mires systèmes en « built-in »
 Possibilité de personnaliser la supervision avec des
« UserParameters »
 Agent en ...
 Gestion des configurations personnalisées
 Risque d’ « information disclosure » avec les UserParameters
 Charge de tra...
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 ...
É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...
 Analyse des slow queries
 Ajout d’index sur les tables les plus consultées
 Passage des tables temporaires en RAMDISK
...
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...
Zabbix 2.x
 Autodiscover des ressources locales
 Utilisation de macros
 Possibilité de placer les personnalisations en base (scrip...
 Utilisation de XtraDB
 Partitionnement des tables d’historique pour archivage des
valeurs les plus anciennes
Optimisati...
 Découverte automatique des instances dans le Cloud public et
privé
 Meilleure intégration de la supervision des OS « do...
 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-Billanco...
@ikoula ou @ikoula_EN
Ikoula Hosting Services
Ikoula
Ikoula
Gardez le contact !
AUTEUR : NICOLAS TRAUWAEN
Prochain SlideShare
Chargement dans…5
×

Évolution de la supervision chez Ikoula

743 vues

Publié le

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.

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
743
Sur SlideShare
0
Issues des intégrations
0
Intégrations
26
Actions
Partages
0
Téléchargements
5
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • 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é
  • 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
  • Il y a forcément des cas particuliers

    Attention : fréquence de check entre 2 valeurs trop haute
  • Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • Mode passif : le serveur vient chercher l’information. Agent peu gourmand en ressources locales
  • Ex : MDP MySQL en clair dans le fichier de configuration
  • Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • 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
  • Innodb : augmentation des caches et du buffer pool
  • Multiplication des modèles « cloud » : plus d’hyperviseurs, moins de serveurs dédiés
  • 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
  • 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
  • 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
  • Zabbix 3.x
    Etc.
  • Évolution de la supervision chez Ikoula

    1. 1. Évolution de la supervision chez Ikoula Quellessontlesréponses apportéesauxcontraintes devolumétrieetdeperformance? AUTEUR : NICOLAS TRAUWAEN
    2. 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. 3. Un peu d’histoire
    4. 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. 5. Fping & rsyslog et les escalades par e-mail
    6. 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. 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. 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. 9. Servers Alive
    10. 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. 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. 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. 13. Automatisation de l’inventaire
    14. 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. 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. 16.  Solution open source  Modulable  Gestion dynamique de l’inventaire  Processus PHP multithread  Grande réactivité  Solution nouvelle et peu connue Zabbix
    17. 17. Utilisation de templates
    18. 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. 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. 20. Utilisation d’agents
    21. 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. 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. 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. 24. Éclatement de l’infra
    25. 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. 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. 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. 28. Zabbix 2.x
    29. 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. 30.  Utilisation de XtraDB  Partitionnement des tables d’historique pour archivage des valeurs les plus anciennes Optimisations bdd
    31. 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. 32.  https://www.ikoula-blog.com  https://fr.ikoula.wiki  https://zabbix.org Ressources
    33. 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. 34. @ikoula ou @ikoula_EN Ikoula Hosting Services Ikoula Ikoula Gardez le contact ! AUTEUR : NICOLAS TRAUWAEN

    ×