Post de Zenika

L’observabilité est un composant essentiel pour le MCO d’une infrastructure. Grâce aux logs, aux metrics et aux traces, l’observabilité permet, entre autres : * D’avoir une vision globale (full-stack) de la situation de l’infrastructure * De détecter plus rapidement, voire anticiper, les incidents et leur origine * De faciliter les analyses des incidents en cours et les analyses post-mortem avec une utilité transversale pour les équipes support, DevOps et SRE. De nombreuses solutions Open Source sont disponibles pour répondre à ce besoin. Historiquement, les outils de monitoring étaient plutôt du type Nagios, Centreon, Zabbix... avec des données collectées par tests distants ou via un agent installé sur les équipements. La centralisation des logs étaient plutôt basiques, de type Rsyslog. Avec l’essor de virtualisation, du cloud, les infrastructures se sont densifiées et complexifiées. Est arrivée la stack ELK : Elasticsearch, Logstash et Kibana qui a permis de prendre en charge de gros volumes de données et une grande diversité de composants. Puis la stack LGTM, une solution majeure proposée par Grafana. LGTM = Loki + Grafana + Tempo + Mimir Grafana propose une galaxie de solutions Open Source déployables on-premise, qui gèrent l’observabilité de bout en bout. * « Grafana Flow Agent » pour collecter les logs, les metrics, les traces (remplace Prometheus, Promtail,...) * « Grafana » pour les dashboards (exemples : https://lnkd.in/e2YuqNES ) * « Loki » pour agréger les logs * « Tempo » pour stocker et analyser facilement les traces * « Mimir » pour gérer les metrics dans une TSDB (Time Series DataBase) * « OnCall » pour transmettre les alertes aux équipes * « Pyroscope » pour le profiling continu du code déployé (pour le DevOps) Ces solutions peuvent se déployer aussi bien pour du cloud externe que interne, que sans cloud. Il est reconnu que le volume stocké par la stack LGTM est bien moindre que celui de la stack ELK. L’étape suivante de l’observabilité est l’utilisation de l’intelligence artificielle (AIOps), qui permettrait une meilleure détection automatique des anomalies, notamment dans les logs.

Comment choisir la bonne solution d’observabilité ? Comment évaluer ses capacités et les comparer ? Ce sont les questions qui m'occupent en ce moment. 🤔 Le marché regorge de solutions : du SaaS uniquement, de l'open source, des outils spécialisés dans les logs, etc. Il est facile de se laisser influencer par le marketing. 📢 Je suis encore en phase de réflexion, mais voici comment je m'y prendrais pour démarrer : 1. Tester des démos disponibles : - La démo d'OpenTelemetry est un incontournable pour la partie microservices. Sa version Google, sans OpenTelemetry, peut servir d'alternative si l’on veut tester des scénarios non instrumentalisés. - Une démo d’un monolithe avec une base de données (je suis encore en quête de la bonne solution). - Un outil de CI/CD comme GitLab pour évaluer la surveillance des pipelines. 2. Simuler un environnement On-Premise : Pour l'infrastructure, le cloud ☁️ offre la flexibilité nécessaire, mais il est crucial d'éviter les services trop spécifiques et de se concentrer sur des instances et des clusters Kubernetes aussi standards que possible. L’objectif est de recréer les contraintes réelles que le client connaît en production. ❌ Mais il y a un hic... Supposons que j'installe mon application de monitoring, que je la connecte, et que je déploie même des agents. Tout semble calme : pas de trafic, pas de problèmes... Cela ne ressemble pas à un environnement de production ! Certes, la démo d'OpenTelemetry fournit un générateur de trafic et un feature flag qui simule des incidents, mais c’est léger 👎🏼. Ces incidents sont là pour montrer l’utilité d’OpenTelemetry, pas pour vraiment tester ma solution d’observabilité. C’est là que le Chaos Engineering entre en jeu ! 💥 Il existe plusieurs outils : Chaos Monkey, le plus connu, mais aussi Gremlin ou Litmus Chaos. Ces solutions permettent de réaliser des tests de chaos en continu, en simulant des pannes pour tester la résilience de votre système. 🔥 Je continue mon exploration, mais il y a définitivement une stack intéressante à construire autour de ce besoin. 🚀 #Observabilité #ChaosEngineering #CloudComputing #DevOps #Microservices #Kubernetes #OpenSource #Innovation

👀 Nouvelle tendance en vue : "as Prompt" - La prochaine norme ?   🚀 Impulsées par l’avènement du Cloud et du DevOps, les mouvances “as Code” et “Software Defined X” ont grandement amélioré la gestion du cycle de vie des actifs informatiques. Mais que diriez-vous de troquer le "as Code" par du "as Prompt" ?    🔍 Nous explorons dans cet article signé par Clément Lefranc les avancées significatives de l'Infrastructure as Prompt (IaP) et comment cette nouvelle approche pourrait simplifier radicalement vos processus de gestion des ressources informatiques. Ne manquez pas cette lecture captivante !   👉🏼 Lisez l'article complet sur notre blog : https://lnkd.in/ehchpVce   #AsPrompt #InfrastructureAsCode #IaC #InfrastructureAsPrompt #IaP #IT #Cloud #DevOps #RhapsodiesConseil

L'enjeu de l'observabilité dans Kubernetes Dans les environnements cloud modernes, la surveillance d’un cluster Kubernetes devient un enjeu crucial. Avec des centaines de nœuds et de pods à gérer, la complexité du monitoring est un véritable défi pour assurer la disponibilité et les performances des applications. Prometheus, une solution de monitoring open-source, se démarque en apportant une innovation majeure dans le suivi des métriques. Grâce à ses capacités d'auto-découverte des services dans Kubernetes, il permet de suivre en temps réel les ressources sans intervention manuelle. L’intérêt de Prometheus réside dans sa capacité à offrir un monitoring granulaire : Non seulement il permet de suivre les performances des nœuds, pods et services, mais il s'adapte parfaitement à l'environnement dynamique de Kubernetes, où les services et pods sont constamment créés et supprimés. Grâce à sa flexibilité, vous pouvez surveiller une multitude de métriques personnalisées, allant des ressources CPU et mémoire, à des données spécifiques aux applications. De plus, l’intégration de Prometheus avec des outils comme Grafana vous permet de visualiser ces données en temps réel avec des tableaux de bord interactifs. Ce niveau de visibilité aide les équipes DevOps à anticiper les problèmes avant qu’ils ne deviennent critiques, réduisant ainsi les risques d’interruption de service. La mise en place de Prometheus dans votre infrastructure Kubernetes offre une réponse complète aux défis de l’observabilité. En automatisant la découverte des services et en configurant des alertes personnalisées, vous garantissez une surveillance proactive de votre environnement. Par exemple, si un pod dépasse ses limites de CPU ou si un service tombe en panne, vous pouvez configurer Prometheus pour envoyer des alertes avant que cela n’affecte vos utilisateurs finaux. Cela permet non seulement de résoudre rapidement les incidents, mais aussi d’optimiser les ressources en temps réel. Prometheus, couplé avec Grafana, devient un véritable tableau de bord de contrôle pour gérer les performances de vos applications, tout en assurant une scalabilité à mesure que vos besoins grandissent. #Monitoring #Kubernetes #Prometheus #DevOps #CloudComputing #Observabilité #OpenSource

Le serverless : plus qu'un simple buzzword 🚀 On en parle beaucoup, mais savez-vous vraiment ce que signifie "serverless" ? 🤔 Contrairement à ce que son nom indique, il y a bien des serveurs derrière vos applications... mais vous n'avez plus à vous en soucier 😉 ➡️ Le serverless vous permet de : 🔑 Déployer vos applications en un clin d'œil ⚡ 🔑 Ne payer que pour ce que vous utilisez 💰 🔑 Vous concentrer sur votre code, pas sur l'infrastructure 💻 Envie d'en savoir plus sur cette révolution technologique ? C'est par ici : https://lnkd.in/eEcQ8yaf Merci à Benoit Touron pour la rédaction de cet article !

Dans un précédent post on avait parlé du concept de "vendor locking" qu'on peut résumer en disant qu'il s'agit de l'ensemble des stratégies mises en place par un fournisseur pour vous contraindre à rester chez lui ou du moins rendre complexe la "réversibilité". Dans le monde de l'observabilité il y a des solutions qui font référence dans chacun des piliers Prometheus pour les métriques, Elastic pour les logs, Dynatrace pour les traces. La question du jour est donc lorsque vous choisissez un fournisseur Cloud Computing par exemple Microsoft Azure faut-il déployer son infrastructure d'observabilité ou utiliser les solutions du fournisseur ? Avec l'évolution des ces outils fournisseurs je pense que c'est de plus en plus un débat. exemple : Dans ma formation Dynatrace je présente le langage DQL (Dynatrace Query Language) qui vous permet de requêter les données dans le Data Lakehouse Grail. J'ai testé le langage KQL (Kusto Query Language) pour interroger les données dans Azure Data Explorer. Mon constat l'approche des deux langages est identique !!! Et si l'avenir de l'observabilité était dans le Data Lakehouse ? #DQL #KQL #observabilité #vendorlocking #Azure Si vous pouvez partagez la stratégie choisie par votre entreprise ? https://lnkd.in/eZVy2373

Jour 5 / 30 sur l’observabilité et OpenTelemetry, on va explorer les avantages d'utiliser OpenTelemetry. Pourquoi devriez-vous l'adopter dans vos projets ? Voici quelques raisons clés : 1️⃣. Standardisation OpenTelemetry offre un standard unifié. Cela simplifie l'instrumentation de vos applications, car vous utilisez une seule API et un SDK standardisé, quelle que soit la technologie ou le langage de programmation. Fini les casse-têtes liés à l'intégration de multiples outils de télémétrie ! 2️⃣. Compatibilité Multi-Fournisseurs Avec OpenTelemetry, vous n'êtes plus lié à un fournisseur unique. Vous pouvez facilement envoyer vos données de télémétrie vers divers backends comme Prometheus, Jaeger, ou même des services cloud comme AWS CloudWatch et Google Cloud Monitoring. 3️⃣. Communauté et Évolutivité En tant que projet open-source soutenu par une large communauté, OpenTelemetry évolue constamment. Même des fois un peu trop vite. De plus, la modularité d'OpenTelemetry permet une évolutivité facile, que vous gériez une petite application ou une infrastructure à grande échelle. 4️⃣. Réduction des Coûts et de la Complexité En standardisant votre pile de télémétrie, vous réduisez la complexité de gestion et les coûts associés à l'intégration et à la maintenance de multiples solutions. J’ai déjà bossé chez des clients qui utilisait 2 agents par machine à cause d’une séparation des responsabilités infra/application. Sur 5000 hosts, l’emprunte CPU et RAM peut faire mal Prochaine publication, on parlera de l'historique et de l'évolution d'OpenTelemetry. #DevOps #Observabilité #OpenTelemetry #Standardisation #Compatibilité #OpenSource

>> 🔎Aux équipes #SOC et autodidactes souhaitant monter en compétence en réseau/architecture et sur #Azure, voici un schéma "High-level design" qu'il est possible de reproduire. L'idée est de s'exercer à envoyer des logs via le protocole #Syslog vers Microsoft Sentinel, en passant par plusieurs intermédiaires à savoir : Chiffreur --> Load Balancer --> Relais syslog --> #SIEM. Une fois réalisé, les opérations d'optimisations sont nombreuses. Vous pouvez par exemple filtrer vos logs en amont, superviser vos ressources Azure puis définir des alertes avec Azure Monitor, ajouter/enlever des nœuds du cluster syslog, évaluer le nombre d'EPS, tester les limites de l'architecture etc ... Bref c'est un terrain de jeu à la limite des outils utilisés, de votre imagination (... et de votre CB 😅, pensez à définir des alertes budgétaires sur Azure). Alors ... testez, cassez des choses, reconstruisez, comprenez. Enjoy !   NB : Dans ce schéma, le cluster de relais syslog contient des VM Azure avec l'agent Azure Monitor Agent (AMA) installé, mais rien ne vous empêche d'utiliser d'autres relais comme #Logstash ou #Cribl !

Le cloud a été une révolution, docker la révolution dans la révolution. Pour l'IA on a la même chose. *Ollama* c'est la révolution dans la révolution. Parfaitement packagé pour tous les OS vous pouvez récupérer en une ligne un modèle LLM : mistral, llama ou encore llava pour la vision. Vous avez une interface texte pour un usage personnel et un point d'API pour coder. Des bibliothèques sont disponibles pour les différents langages. Après 6 mois sans avancer pour cause de manque de temps de setup. J'ai pu en 2 soirs booster mon MVP : 💡 avec 10 ligne de code une fonction de traduction automatique 💡 avec 40 lignes de code un module de recherche sémantique qui explose la recherche classique elastic search. Pour les rubyiste: un concern mixable sur n'importe quel modèle active record Pour le deuxième sujet, la vectorisation seule (chromadb) marche mieux que le RAG (chromadb + LLM). Mais ça c'est parce que je débute. On retiendra : Maintenant, n'importe quel MVP peut introduire des fonctions LLMs sans cout d'API supplémentaire et surtout en gardant la localisation dans le datacenter choisi (Confidentialité + RGPD + souveraineté), cela quasiment sans expertise. J'attends vos impressions sur ce sujet ! PS: Igor ZLOBINE on en discute pour ORGE.IO ?

Est-ce que vous pensez vraiment que Kubernetes est réservé aux experts ? Vous n'avez pas besoin d'être un génie pour maîtriser Kubernetes. Imaginez transformer votre façon de gérer vos applications en quelques clics. Kubernetes n'est pas seulement à la mode, c'est un game changer. Vous méritez un déploiement sans stress et sans erreurs. Déployez vos applications avec la certitude qu'elles seront toujours disponibles. Réduisez vos interruptions et optimisez vos performances. Fini les configurations manuelles et les mises à jour laborieuses. Automatisez l'administration et concentrez-vous sur l'innovation. Faites confiance à Kubernetes et voyez votre infrastructure évoluer avec vous. Vos équipes vous remercieront pour la simplicité et l'efficacité. N'attendez plus pour simplifier votre vie avec Kubernetes. Commentez "Je passe à Kubernetes" si vous êtes prêt à révolutionner votre gestion d'applications. ------ Je suis 🔴 Julien GOURMELEN 🧙♂️, j'accompagne l'excellence opérationnelle des adminsys au travers d'une communauté engagée sur le discord WizOps ! Rejoins-nous en cliquant ici https://lnkd.in/eZ5HztX3 !