Dans un monde de plateformes, les API sont reines

Les API permettent aux programmes informatiques d’interagir entre eux. Indispensables et omniprésentes, elles sont le moteur d’une nouvelle économie.

Aucun homme n’est une île. Ce célèbre vers du poète anglais John Donne de 1624 résonne particulièrement en ce début de 21ème siècle. A l’époque de la 5G et de l’hyper-connexion, l’Homme ressemble plus à une carte du métro parisien, avec ses nœuds et ses lacets, qu’à une terre isolée au milieu d’un océan. On vise même à supprimer les derniers bastions insulaires, les fameuses zones blanches, pour sauver les naufragés du numérique et les embarquer avec nous sur le paquebot de l’internet. La France ne veut pas de Robinsons dans l’accès au digital.

Pourquoi parler de littérature britannique du XVIIème dans un billet sur les API ? Parce que la vision de John Donne s’adapte étonnamment bien à la situation actuelle du numérique (et qu’un peu de poésie n’a jamais tué personne). Aucun logiciel n’est une île. Ou plutôt, aucun logiciel ne devrait être une île.

No man is an island

Les API, définition et mise en oeuvre

Pour bien comprendre les API, intéressons-nous en premier lieu à ce qu’Accenture qualifiait en 2016 de « révolution industrielle silencieuse » : l’économie de plateforme.

Raisonner en plateforme c’est passer de la fourniture d’opportunités de consommation à la fourniture d’opportunités de création de valeur. Les interfaces de programmation applicatives (API donc) sont les piliers de cette nouvelle économie. Elles représentent une façon pour un logiciel de se brancher à un autre pour bénéficier de ses fonctionnalités et de ses données. Les API connectent des systèmes, des services et des technologies disparates. Ce sont elles qui rendent possible l’infrastructure virtuelle du cloud.

Les organisations peuvent ainsi intégrer les capacités logicielles d’autres plateformes dans leurs propres applications ou sites web. Cela permet de proposer des fonctionnalités supplémentaires qu’elles ne pourraient pas normalement fournir à leurs clients. On pense par exemple au « Click to Call » (appel téléphonique) d’Avencall que l’on peut ajouter à sa messagerie, carnets d’adresses et agendas BlueMind.

click to call Bluemind Avencall

Pour les mettre en œuvre, les organisations doivent d’abord comprendre où les appliquer au mieux. L’analyse du parcours client est souvent le meilleur moyen d’identifier les opportunités d’API. Il permet d’identifier les points de friction et les endroits où l’on peut créer ou récupérer de la valeur. Par exemple, quand vous commandez une voiture sur Uber, la connexion avec votre banque qui permet de régler la course directement depuis votre téléphone, s’effectue via une API. Dans le parcours client de ce type de service, il est important de pouvoir régler une somme fixe (pas de surprise de la part du chauffeur) simplement (sans avoir à utiliser une carte bleue ou un autre outil que l’application Uber). En enlevant cette friction du parcours client, Uber assure un taux de transformation plus important.

Les données sont l’un des actifs les plus précieux d’une entreprise. En tant que clés de manipulation et exploitation de ces données, les API elles-mêmes deviennent extrêmement précieuses. Pour le MagIT « ces interfaces de programmation permettent d’ouvrir des SI préhistoriques à l’innovation et de relancer des secteurs de plus en plus sous pression, » comme les compagnies aériennes ou les banques par exemple.

BlueMind et les API

La messagerie de BlueMind fait partie des solutions conçues dès le départ sur le principe des API, permettant à notre écosystème de co-construire le produit au travers d’une marketplace.

BlueMind Marketplace

Toutes les opérations de BlueMind passent par des APIs webservices, qui sont donc l’unique point d’entrée aux données de la solution. Ce choix technique garantit la cohérence et la complétude de toutes les opérations effectuées via le composant BM-Core. Il permet surtout une intégration simple avec tous types de composants et logiciels tiers et apporte ainsi une interconnexion facilitée au système d’informations.

En plus d’interagir via les webservices, BlueMind a conçu un système de plugins permettant de modifier ou d’étendre les fonctionnalités. Grâce à cette technologie, il est maintenant possible d’adapter ou d’enrichir la solution mail, facilement, sans la modifier. Par exemple BlueMind permet de définir ou modifier par plugin les règles de la création de mot de passe afin de laisser la liberté aux administrateur d’établir leurs propres normes de sécurité. Pour définir un format standard de mot de passe (majuscule, caractères spéciaux etc.) vous pouvez utiliser un add-on de la marketplace.

De plus, via des points d’extension maintenus entre les versions, les plugins BlueMind restent compatibles avec les versions à venir de la solution : les modifications faites par vous-même ou votre intégrateur restent utilisables même après des mises à jour mineures ou majeures.

Les plugins vous permettent aussi de modifier dynamiquement les interfaces utilisateur et administrateur. En combinant API web-services et plugins, BlueMind vous facilite le développement de fonctionnalités additionnelles comme la gestion des signatures d’entreprise, l’intégration de logiciels tiers (nextcloud) etc.

Côté technique, notre API est constituée de web services REST, soit accessibles directement via des appels HTTP REST, soit via l’utilisation des clients fournis (aujourd’hui pour Java, Javascript, C#, Python et PHP). Le repository bluemind-samples est disponible et rassemble tout ce qui est nécessaire pour contribuer à BlueMind en développant un Add-On. Un archetype maven est également disponible pour faciliter la définition d’un nouveau projet.

Bluemind système API

Que peut-on imaginer avec des API dans la messagerie ? A peu près tout ! Reliez votre messagerie à votre logiciel de congés par exemple afin que les congés validés soient automatiquement renseignés dans les agendas des personnes ou faites correspondre vos contacts BlueMind a votre annuaire RH en temps réel.

A ce jour, plusieurs partenaires technologiques ont publié leurs travaux:  Avencall pour la communication unifiée, VadeRetro pour une intégration à ses outils de sécurité, ou encore Numvision, Teclib ou Nextcloud sur des intégrations du partage de fichier volumineux.

Et si on ne veut pas ? L’iceberg qui a coulé Google+

Google+ fermera définitivement ses portes le 2 avril 2019 pour aller rejoindre le cimetière des services Google qui n’ont pas su convaincre. La tentative de réseau social de Google est née en 2011, 8 ans après Linkedin, 7 ans après Facebook, 5 ans après Twitter, soit avec des siècles de retard dans le monde accéléré du digital. Mais ce n’est pas ce démarrage tardif qui est en cause dans l’échec du produit. Après tout, les très populaires Snapchat et Instagram ont été lancés à la même période. Alors qu’est ce qui a coulé G+ et quel est le rapport avec les « Interface de Programmation applicative », les fameuses API ?

C’est un ancien salarié de Google qui nous donne la réponse. Steve Yegge a travaillé 12 ans chez le G de GAFA en tant que « Senior Staff Software Engineer » après avoir passé 6 ans chez Amazon. Il est devenu célèbre dans le microcosme des ingénieurs logiciels pour avoir diffusé par erreur un « blog rant » – une diatribe par blog (beaucoup moins sexy traduit en français) – très critique envers à la fois Google et Jeff Bezos, l’emblématique patron d’Amazon.

Steve Yegge
Steve Yegge (from https://medium.com/@steve.yegge)

Steve expliquait dans cet article que, bien que Bezos soit un « infâme micro-manager » obsédé par le contrôle, il a réalisé avant tout le monde l’importance des plateformes. Dès 2002 il aurait ordonné à ses troupes de ne concevoir que des interfaces qui puissent être externalisables, réutilisables par des développeurs en dehors d’Amazon. Avec l’effritement des marges de son core business (la librairie en ligne), il devait trouver une autre source possible de revenus. Tout ce que Bezos avait entre les mains pour envisager un changement de business model, c’était un grand nombre d’ingénieurs et d’ordinateurs. Il lui fallait pouvoir monétiser cette compétence.

En quelques années sous l’effet Bezos, Amazon a changé totalement de culture, depuis la librairie en ligne vers une entreprise de service web : l’incontournable AWS. En 2018 le Cloud Amazon pesait 17,46 milliards de dollar, soit 10% du chiffre d’affaires du Groupe.

Si Bezos a su pivoter dès 2002, Google n’a pas du tout compris ce qu’était une plateforme. Ses dirigeants de 2011, Larry Page, Sergueï Brin et Eric Schmidt cherchaient à créer le produit parfait qui convienne à tout le monde. Pour cela ils ont déployé une philosophie de la simplicité extrême. Chrome par exemple est un produit à « configuration zéro », on ne peut même pas changer la taille des polices de caractère. Tant pis pour les malvoyants, Chrome est obstinément le même pour tout le monde.

Ce manque d’accessibilité est l’iceberg qui a fait couler le Titanic Google+. Ce réseau social était une réaction spontanée court termiste, basée sur l’idée erronée que Facebook a du succès parce que son produit est excellent. C’est faux.  Facebook a du succès parce qu’il a construit toute une constellation de produits en permettant à d’autres personnes de faire le travail. Facebook est donc différent pour tout le monde. Certaines personnes passent tout leur temps sur un jeu, d’autres pour organiser des événements, d’autres sur messenger… Il y a des centaines, voire des milliers de façons de perdre du temps sur Facebook, chacun y trouve son compte.

Google+ s’est contenté de proposer un produit « one size fits all » qui ne proposait aucune API à son lancement. Le raisonnement plateforme est un raisonnement long terme qui implique de concevoir dès le départ une architecture permettant à n’importe qui de construire par-dessus et une philosophie qui valorise l’émergence et le développement d’un écosystème. En 2011 cela ne faisait pas partie de la culture de Google.

La mort de G+

Pour conclure

Les API permettent à l’économie numérique hyper-connectée d’exister, rien que ça. Elles sont devenues des canaux indispensables à la valorisation de la data. Si aucun logiciel n’est une île les API sont tout ce qui permet de les relier entre eux.

Attention cependant à un point crucial : la sécurité des données. Qui peut y avoir accès ? Comment sont-elles utilisées ? Malgré le RGPD qui exige un consentement éclairé il n’est pas toujours simple de comprendre les implications du partage avant d’approuver. Cocher « J’accepte » en bas d’une liste de conditions ne permet pas de justifier de la compréhension de l’usage exact qui sera fait de vos données.

Saviez-vous par exemple que confier des données à un acteur américain, même si elles sont hébergées en Europe, autorise les autorités US à les consulter ? Dans un monde d’API, il est essentiel d’éduquer et de responsabiliser les consommateurs.

Suivez nous :

DevOps et Intégration continue : focus sur la démarche qualité de BlueMind

BlueMind a intégré le mouvement DevOps dans sa démarche qualité. Grâce à l’intégration continue nous produisons plus rapidement et de meilleure qualité.

Le terme DevOps est apparu assez récemment dans le paysage informatique mondial, mais s’est déjà hissé au sommet des pratiques les plus efficaces. D’après le cabinet Gartner en 2015, 25% des 2000 plus grands groupes mondiaux s’orientaient vers la démarche DevOps. Plus qu’une méthode de travail, il s’agit surtout d’un changement culturel qui vise, comme son nom l’indique, à rapprocher le développement des opérations. L’objectif est double : raccourcir les délais de déploiement de mises à jour et garantir un haut niveau de qualité.

Le secret de la démarche réside dans la coopération et le partage ; les développeurs et les responsables de l’exploitation des systèmes collaborent pour délivrer le logiciel en continu. Les cycles de développement sont plus courts, la qualité est évaluée tout au long du projet et les déploiements sont plus fréquents.

« DevOps est un ensemble de pratiques et de valeurs culturelles qui a fait ses preuves pour aider les organisations de toutes tailles à améliorer leurs cycles de sortie de logiciels, leur qualité, la sécurité et la capacité à obtenir rapidement un feedback sur le développement. »Puppet Labs, rapport «State of DevOps», 2017

BlueMind a choisi d’implémenter une démarche DevOps au travers du processus d’intégration continue. Focus sur les enjeux et bénéfices.

Un nouveau paradigme

Traditionnellement, les développeurs ne partageaient pas leur travail avec le reste de l’équipe et avançaient  individuellement sur de longues périodes. Ils n’intégraient leurs modifications au code qu’une fois leur travail terminé. Le développeur n’avait pas de vision sur l’impact réel d’une mise à jour sur l’ensemble de l’application. En conséquence, on ne peut identifier les problèmes qu’en bout de chaîne et il est difficile de les localiser précisément, retardant la livraison des mises à jour.

De leur côté, les directions opérationnelles doivent attendre parfois plusieurs mois que les tests et le déploiement soient enfin satisfaisants pour répondre à un besoin utilisateur… qui a probablement déjà évolué. Les deux équipes, développement et opérations ne partagent pas les mêmes objectifs et donc n’ont pas les mêmes priorités.

Sur le papier les exigences du logiciel sont claires, définies à l’avance et stables. Les développeurs s’occupent du code, les équipes opérationnelles de sa mise en œuvre sur les systèmes de l’entreprise. Sur le papier…

Dans le monde réel l’informatique évolue trop rapidement pour permettre de conserver un cahier des charges fixe tout au long du projet. Dans le cadre d’un éditeur de logiciel, le « projet » ne se termine jamais ! Les logiciels doivent pouvoir être mis sur le marché plus rapidement, mais ils doivent aussi pouvoir évoluer constamment. De nouvelles fonctions doivent pouvoir être ajoutées le plus simplement possible, et les bugs découverts doivent pouvoir être corrigés. Les nouveautés ne doivent pas casser l’existant et prendre en compte toutes les configurations et cas possibles. Il n’y a plus de jour «J » pour délivrer le produit comme auparavant.

DevOps et ses pratiques (dont l’innovation continue) visent à mettre fin à cette bataille entre Dev et Ops – pour parvenir à l’équilibre entre innovation et stabilité.

DevOps : un meilleur dialogue entre les équipes

La démarche DevOps consiste à mettre en place un processus global impliquant tous les intéressés quel que soit leur rôle initial. Fini les individus isolés et hyper-spécialisés, les équipes de développement et d’exploitation travaillent en commun sur tout le cycle de vie d’une application, de sa conception et son test jusqu’à son déploiement et à son exploitation.

Les équipes partagent de nombreuses responsabilités et combinent leurs workflows. Cela leur permet de limiter les pertes d’efficacité et de gagner du temps.

Dominique Eav – Chef d’orchestre de la qualité BlueMind

« Chez BlueMind personne n’avance seul dans son coin. Nous cultivons la collaboration et le partage pour favoriser l’efficacité opérationnelle. Nous avons un objectif commun et un plan – défendu par le product ou feature owner – pour l’atteindre ensemble. Toute l’équipe peut suivre les projets, les idées et les difficultés de chacun. »

Ce temps passé à partager les savoir-faire, idées et connaissances doit être largement rentabilisé par l’efficacité gagnée dans la qualité des livraisons, l’anticipation des problèmes/erreurs et la rapidité des dépannages.

Intégrer en continu

Expliquée simplement, l’intégration consiste à rassembler des morceaux de code et à les faire fonctionner ensemble. Souvent, c’est un vrai sacerdoce ! En effet, les projets et les environnements sont nombreux, chaque environnement impliquant une organisation différente du module concerné, des étapes de construction, de test, de validation et de déploiement. L’intégration continue permet de résoudre ces problèmes en faisant collaborer tous les acteurs d’un projet du développement à l’exploitation.

L’intégration continue désigne l’ensemble des pratiques qui permettent aux développeurs d’intégrer régulièrement leurs modifications de code à un référentiel centralisé, de créer et mener automatiquement des sessions de test automatisés, puis de déployer les résultats du build si les voyants sont au vert. Ce processus permet de repérer et corriger plus rapidement les bugs, d’améliorer la qualité et de réduire les temps de validation et de publication de nouvelles mises à jour.

Historique des résultats de tests.
Pour un test donné on voit ce qu’il se passe maintenant et l’historique, un FAIL sur un test qui passait auparavant est signe d’une régression

Elle  permet de vérifier, à chaque modification du code source, que le résultat ne produit pas de régression ou de défaut dans les parties non modifiées de l’application. Les bugs sont identifiés et donc corrigés plus rapidement, les temps de validation et de publication sont réduits et bien entendu la qualité finale est améliorée.

« Nous utilisons largement le principe de pull request. Il s’agit d’un mécanisme permettant à un développeur de partager et valider son travail sans qu’il ne soit forcément terminé. Le développeur peut proposer à tout moment une pull request pour solliciter une revue des personnes impliquées. C’est beaucoup plus qu’une simple validation – il s’agit d’une vraie discussion sur les partis pris techniques de la fonctionnalité proposée. Ainsi nous nous assurons d’une part que l’ensemble de l’équipe puisse suivre les évolutions techniques et d’autre part de l’intégrité des choix »

— Dominique Eav responsable qualité BlueMind.

Tableau de bord sur le build d’une branche (master)
Ce diagramme présente les résultats de tests, les différentes étapes du build et les builds précédents

L’automatisation : clé de voûte de l’intégration continue

Compilation, tests unitaires et fonctionnels, validation produit, tests de performance… sont des activités essentielles mais chronophages, sans parler de l’erreur humaine, toujours possible. Le principe de l’intégration continue repose sur leur automatisation pour gagner du temps et assurer toujours le meilleur niveau de qualité possible.

Ainsi, dès que le développeur produit du code, l’outil vérifie automatiquement qu’il respecte les règles communes mises en place pour l’ensemble de l’équipe. Cette procédure garantit la qualité du code produit et sa stabilité dans le temps par le respect des bonnes pratiques de développement.

Cet outil d’analyse du code permet de voir la couverture de test sur le code. Il faut tendre vers la plus grande couverture possible.

BlueMind utilise Jenkins pour piloter sa chaîne d’intégration continue. Ce logiciel permet de tester et de rapporter les changements effectués sur une large base de code en temps réel pour détecter rapidement les problèmes.

Jenkins nous permet de construire et tester nos branches de développement (features ou corrections), dont les changements intègrent en continu nos branches de release (3.0, 3.5, 4.0), et ce sur toutes les distributions linux supportées (8 pour BlueMind 3.5.9). Le coeur de BlueMind comprend plus de 500 modules, et interagit avec de nombreux AddOns que l’on retrouve sur le Marketplace, eux aussi construits, testés et déployés par notre chaîne d’intégration continue, avec les mêmes contraintes de compatibilité et de qualité. Plus de 3000 tests sont réalisés sur chaque build. Ce degré de complexité serait impossible à gérer manuellement ! Toute l’intelligence de l’intégration continue réside dans l’enchaînement automatique des différentes tâches, dans une logique d’industrialisation des processus.

« Nous avons une approche consensuelle et pragmatique. Nous mettons en œuvre et améliorons nos processus de façon à faciliter la vie des membres de l’équipe, pas pour répondre à un cahier des charges qui nous serait imposé. L’automatisation qui en résulte permet d’aller vite et de faire émerger les éventuels problèmes au plus tôt. Chaque brique de notre chaîne d’intégration continue est une ceinture de sécurité »

— Dominique Eav responsable qualité BlueMind.

Cet outil d’analyse statique de code qui examine les différentes classes, mesure la dette technique c’est à dire le temps nécessaire pour corriger les problèmes que présente telle ou telle partie du code.

En plus de supprimer des tâches fastidieuses, cette automatisation permet de fiabiliser le processus de déploiement tout en augmentant la fréquence des livraisons. Les équipes peuvent se consacrer à améliorer les fonctions existantes ou assurer un suivi de qualité plutôt que d’effectuer des tests manuellement.

Des bénéfices concrets

L’intégration continue fait gagner énormément de temps aux équipes de développement puisque chaque modification du logiciel est immédiatement testée. Un code compilé régulièrement permet d’identifier rapidement les modifications qui posent problème en cas d’erreur. Le développeur a un aperçu rapide des régressions qu’il a causé. Les incompatibilités entre le logiciel et l’écosystème dans lequel il devra évoluer sont elles aussi repérées très tôt.

Durant tout le processus de développement et de déploiement, toute l’équipe collabore étroitement dans un but commun : la réussite du projet dans son intégralité, et pas uniquement de leur partie.

Lorsque toute l’équipe de projet est agile, le développement d’une nouvelle fonctionnalité ou la correction d’un bug peuvent être rapidement mis en production – ou annulés si nécessaire. Une version fonctionnelle du logiciel est toujours disponible et il n’est pas utile d’attendre que le logiciel soit mis en production pour s’apercevoir qu’il ne fonctionne pas. Dans le cas de BlueMind, nous mettons d’abord ces nouvelles fonctionnalités ou correctifs en production en interne. Un procédé que l’on appelle « eating your own dog food« , ce qui signifie que nous sommes les premiers utilisateurs de notre solution.

Côté client, l’intégration continue permet de livrer plus rapidement et plus fréquemment des mises à jour tout en garantissant le plus haut niveau de qualité possible.

Pour conclure

Installer un ordonnanceur comme Jenkins n’est pas suffisant pour faire de l’intégration continue. Comme le stipule le Manifesto de l’Agilité logicielle, les individus et les interactions passent avant les processus et les outils. Une démarche DevOps relève donc de la responsabilité de tous. La culture DevOps implique d’adopter une approche transparente basée sur la communication et la collaboration entre les équipes informatiques/opérationnelles et de développement. DevOps est une excellente approche pour les entreprises qui innovent sans cesse !

BlueMind s’est structurée dès le départ autour de ces principes pour assurer le meilleur niveau de qualité dans un environnement complexe. Grâce à cette agilité nous pouvons livrer des produits stables et performants à travers des processus industrialisés entre exploitation et développement.

Suivez nous :

Supervision d’une installation BlueMind

Lorsque une panne se produit ou que des dysfonctionnements sont constatés, il est souvent complexe d’en trouver la cause. Voilà pourquoi BlueMind 3.5.9 intègre désormais un stack complet (et open source) de métriques, alerting et de visualisation de l’état de la plateforme.

Un système BlueMind ou un serveur de messagerie en général est un système complexe. Il intègre de nombreux composants avec des rôles bien définis mais parfois obscurs. Lorsque une panne se produit ou que des dysfonctionnements sont constatés, il est souvent complexe d’en trouver la cause.

Une panne du système de messagerie est souvent source de panique car le service est critique pour la majorité des utilisateurs. Des mesures d’urgence sont alors prises, qui conduisent souvent à des redémarrages qui solutionnent (parfois) le problème mais vont rendre l’analyse post-mortem particulièrement complexe.

L’existant

Un système BlueMind, composé de nombreux services et de nombreuses machine virtuelles Java, essaie le plus souvent de ne pas mourir en silence.

On va trouver :
• Des fichiers /var/log/java_pid1234.hprof ; des dumps mémoires générés automatiquement lorsque le système rencontre un manque de mémoire
• Des fichiers de logs, très nombreux, où l’on va trouver des vilaines choses comme des index elastiscsearch qui nous disent « disk high watermark reached, disabling shards » (le disque dur est plein)

Dans ces différents cas, le problème ne sera pas pris en compte tout de suite, et un redémarrage ou un nettoyage du disque va avoir lieu avant qu’une anomalie ne soit remontée pour analyse.

Laisser un disque dur se remplir quand on gère un système n’est pas un fait d’arme très glorieux. On arrive à la situation suivante : l’administrateur système nettoie le disque dur, puis déclare une anomalie pour indiquer que la recherche n’est plus fonctionnelle.

Ce petit mensonge est problématique, mais ce qui nous intéresse, c’est d’empêcher la situation de se produire.

La supervision

Les systèmes de supervision existent, mais leur déploiement était jusqu’à maintenant laissé à la charge des personnes supervisant des installations BlueMind. La supervision des systèmes Java est un sujet assez complexe et les métriques généralistes ne sont ni intéressantes ni parlantes.

Avec BlueMind 3.5.9, nous avons intégré un stack complet de métriques, alerting et de visualisation de l’état de la plateforme.
Notre ADN étant open-source, nous nous sommes tournés vers une solution open-source : la TICK stack (Telegraf, Influxdb, Chronograf, Kapacitor) http://influxdata.com. Un agent telegraf est installé sur chaque nœud de votre installation. Telegraf transmet ces données à Influxdb, Kapacitor les analyse pour produire des alertes et Chronograf affiche des tableaux de bord pour aider à anticiper les problèmes.

Notre intégration

Pour la 3.5.9 toute la stack est disponible mais n’est pas déployée par défaut. Sur un serveur (votre serveur principal, avec bm-core, ou un serveur de supervision dédié) il faut installer le paquet bm-tick-full.

Ce dernier va déployer toute la stack TICK (que nous avons intégré dans nos dépôts pour contrôler les versions utilisées). Sur chaque serveur de votre installation BlueMind, il faut installer bm-tick-node. Si vous faites cela avant le passage en 3.5.9, l’assistant de mise à jour va s’occuper de tout. Sinon il est préférable après redémarrage de forcer la configuration de toute la stack :

curl -H « X-Bm-ApiKey: $(cat /etc/bm/bm-core.tok) » -XPOST http://localhost:8090/internal-api/tick/mgmt/_reconfigure

depuis votre serveur bm-core.

Agent Java

Les administrateurs les plus attentifs vont remarquer que les processus Java de BlueMind sont lancés avec une option supplémentaire :

/usr/lib/jvm/bm-jdk/bin/java -Dlogback.configurationFile=/etc/bm/local/bm-core.log.xml -Dio.netty.native.workdir=/var/lib/bm-core/work -Xloggc:/var/log/garbage-collector/bm-core/gc.pause.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=4 -XX:GCLogFileSize=4M -XX:+PrintGCApplicationStoppedTime -server -Xms812m -Xmx812m -Xss256k -XX:+UseCompressedOops -XX:MaxDirectMemorySize=812m -XX:+UseG1GC -XX:MaxGCPauseMillis=500 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log -Djava.net.preferIPv4Stack=true -Dnet.bluemind.property.product=bm-core -javaagent:/var/lib/bm-metrics-agent/bm-metrics-agent.jar -Djava.awt.headless=true -Dosgi.noShutdown=true -Duser.timezone=GMT -cp /usr/share/bm-core/plugins/org.eclipse.equinox.launcher_1.3.201.v20161025-1711.jar org.eclipse.equinox.launcher.Main -registryMultiLanguage -debug -application net.bluemind.application.launcher.coreLauncher

C’est cet agent, attaché à nos machines virtuelles, qui nous permet d’exposer nos métriques applicatives à Telegraf. Que fait-il ?
Il ouvre un socket unix dans /var/run/bm-metrics, pour chaque JVM :

Ces sockets unix sont interrogés par Telegraf pour obtenir les métriques de chaque composant :

curl –unix-socket /var/run/bm-metrics/metrics-bm-lmtpd.sock http://bm/metrics

Qui nous donne en version simplifiée :

Ces données vont être consommées par Telegraf toutes les 10 secondes et…

Dashboards !

Ceci est un exemple de tableau de bord sur le flux de mail pre-configuré dans BlueMind 3.5.9.
Mais de nombreuses autres métriques sont disponibles : système (disques, charge, trafic réseau), postgresql (QPS, shared buffers usage), nginx.

Les données sont historisées sur une fenêtre de 7 jours, donc plus de mystère sur le disque dur qui était encore plein 2 heures avant de remonter un incident.

Alerting

Connaître le nombre de processus IMAP actifs, c’est bien. Le comparer avec le maximum configuré c’est mieux.

Cette métrique est observée en permanence par Kapacitor (le script imap-connections est configuré par bluemind) pour comparer le nombre de process à un instant avec celui configuré dans BlueMind.

Ces alertes sont visibles sur l’accueil du monitoring/tick/ de votre BlueMind avec le mot de passe de l’assistant d’installation.

Annotations

En corrolaire des alertes viennent les annotations, qui nous permettent de pointer des points dans le temps (ou des plages de temps) sur nos graphes.
Si le Core est redémarré par un administrateur, la supervision l’archive et le montre sur tous les graphes :

Les tâches programmées qui s’exécutent dans votre système sont aussi intégrées sur les graphes dès qu’elles prennent plus de 30 secondes. Plus de doute désormais pour diagnostiquer que les lenteurs ressenties par les utilisateurs sont dues à une sauvegarde ou un import d’annuaire.

La suite

De nombreuses métriques sont enregistrées par notre produit mais toutes ne sont pas encore exploitées dans des graphes ou des scripts d’alerting. Les dashboards et scripts d’alerting peuvent être ajoutés à BlueMind via des plugins et les prochaines versions devraient en amener de nouveaux et proposer des fonctions de « self healing » (quand tel problème survient, la solution est connue et donc appliquée de manière automatique).

Découvrez toute la documentation ici

Suivez nous :