je suis Christophe & les Compagnons depuis quelques temps déjà, mais n’ai jamais pris le temps de poster ici.
Je suis Rémi, 39 ans, Consultant “OpenSource, Observability & Automation”, chez un intégrateur du Sud Est de la France.
J’ai donc 3 casquettes technos, pour aider nos chers clients, que ce soit sur du conseil, avant-vente, delivery ou MCO:
Sysadmin Linux en général
Observabilité, avec un focus supervision à l’ancienne avec “Eyes Of Network” (ma boite est sponsor principal de la solution) ou bien Prometheus pour les trucs un peu plus récents, et logs avec ELK (gros focus dessus ces temps-ci)
Automation, étant fan d’Ansible sur la partie infra.
Le tout sur des infras plutôt classiques en clientèle, peu de k8s en prod mais ça arrive doucement (beaucoup de veille / POC / labs).
Côté CI/CD, mes clients étant plutôt des Ops, on en parle moins, même si j’adore Gitlab en perso (on a quelques jobs de CI en interne pour valider nos playbooks). Et oui l’infra-as-code & gitops n’est pas encore super bien généralisé, mais on y travaille !
J’aime beaucoup la philosophie DevOps, et vu mon profil j’ai une appétence particulière pour la partie tooling (observabilité & automation). J’ai commencé dans une R&D, puis passé côté ops afin de mettre tout en œuvre pour faciliter la vie des devs, et je trouve ça cool
Au plaisir d’échanger sur ces sujets, sur ce je vais poser qq questions !
Selon moi il y a une différence entre “Consultant DevOps” et ingénieur DevOps.
Le premier est un consultant qui aide les entreprises à passé au DevOps.
Enfin c’est comme ça que je le perçois.
“Eyes Of Network” : ca me rappelle des souvenirs, j’avais évalué le produit quand il était encore très jeune pour remplacer notre Nagios brut de fonderie. Finalement on est parti quelque temps plus tard sur du Centreon.
Je viens de voir que le produit est toujours maintenu, c’est bien.
Nous sommes toujours sous Centreon et je trouve qu’il fait toujours le travail, même si c’est de la supervision à l’ancienne. Je serais curieux de savoir si des équipes utilisent Prometheus et son écosystème (Grafana par exemple) pour de la supervision de gros parcs, et pas pour juste de la métrologie.
Hehe, en effet “Eyes Of Network” est un produit “mature”, c’est stable, ça évolue tranquillement (API, ajout de Grafana pour les dashboards).
Et c’est vrai qu’avec Prometheus & Grafana, pour les équipes pur systèmes, j’ai pas encore vu d’équivalent de la gestion des équipements classiques (gestion des arrêts planifiés, acquittement des alertes, etc…).
Pour la petite histoire, j’avais mis Prometheus il y a quelques années dans mon ancienne boite, j’avais développé l’exporter VMware qui n’existait pas à l’époque. Ça tournait bien, mais la gestion des alertes et dashboards étaient asez complexe à gérer (côté réseau, pour avoir un truc équivalent à weathermap par ex c’était chaud).
Perso je n’ai jamais utilisé EoN, j’utilisais à l’époque Zabbix qui a continué à bien évolué et qui a toujours été pour moi mieux foutu que Nagios et ses dérivés.
Le souci de ces outils de monitoring c’est qu’ils ont longtemps été fortement imprégnés d’une philosophie classique de monitoring d’infrastructure on-premise, avec des services forcément rattaché à un hote ce qui n’est pas en adéquation avec le cloud et l’approche moderne d’observabilité et de monitoring.
Ils ont aussi échoués à aboutir à un standard ouvert. Là ils rattrapent petit à petit leur retard notamment via des intégrations avec Prometheus et la gestion de l’open metrics.
L’approche plus moderne consiste à ne pas se limiter à observer les machines (physiques ou virtuelles) mais élargir l’observation aux applications et aux services tierces, ce qui nécessite que l’outil puisse analyser le fonctionnement des applications et les interactions entres elles. On va d’avantage s’intéresser à l’impact business ou fonctionnel sur le système d’information.
C’est d’autant plus vrai avec le cloud où l’approche consiste à ne plus traiter les serveurs comme des animaux de compagnie mais plutôt comme un troupeau de bétail, dans le sens où la perte d’une machine n’est plus quelque chose de grave, c’est même une chose normal qui s’inscrit dans un flot de va et vient de machines (comme du bétail à l’abattoir).
Tien c’est marrant, c’est exactement sur quoi je travail en ce moment, on s’occupe de suivre les différentes informations qui passent dans les basses de données de nos services pour s’assurer que fonctionnellement tous ce passe bien et qu’il n’y a pas un composant qui aurai cesser de fonctionner malgré que le service soit up.
Et je ne trouve absolument aucune information/bonne pratique sur comment faire
Le problème des outils comme Nagios et Zabbix c’est qu’ils font purement du monitoring d’infrastructure, ils ne gèrent pas la partie APM ni logs. C’est clairement des outils adaptés à une organisation en silos avec une équipe infrastructure qui ne s’intéresse qu’à l’état des machines.
Ils ne sont pas non plus adaptés aux infrastructures cloud ou hybride.
Il y a des implémentations différentes selon les SaaS mais grosso-modo ils disposent d’un agent capable de décortiquer le fonctionnement d’une application (java, php, nodejs, python, go, …) et ainsi remontrer différentes metrics et informations (temps d’exécution, transactions, tracing, erreurs, …).
Cela permet d’avoir une vue multi-niveau : de l’utilisateur jusqu’aux hosts.
Voici un exemple d’écran de l’outil Dynatrace (tiré d’internet) :
L’outil est capable de comprendre que ton app tourne sous tomcat sur tel et tel host de tel datacenter, qu’elle communique avec telle autre app ou telle base de données. L’IA de l’outil permet des choses sympa comme :
Automatiser le RCA (Root Cause Analysis).
Déterminer les seuils d’alertes de façon intelligente (analyse comportementale des systèmes).
…etc.
Ces outils ne sont pas données mais dans une approche DevOps ils font vraiment la différence.
Cela dépend ce que tu veux faire exactement. Si tu pars d’une approche APM alors il faut analyser l’application elle même pour comprendre les interactions qu’elle a avec la ou les bases de données.
Du coup j’ai commencé a chercher Obesrvability au lieu de Monitoring sur Google et je commence trouver plus lecture intéressante, j’etais complètement passé a coté de cette branche
Oui je pense que j’ai du passé un peu a coté ou oublié vu que je ne connaissais pas le sujet a ce moment la, et de mémoire il etait assez long, donc je faisait certainement autre chose a coté . Du coup je vais le reecouter prochainement
. Du coup je vais le reecouter prochainement