Esri fiabilise sa cartographie en ligne avec des sondes serveurs

Le défi d’offrir un service à la fois riche et fiable

Esri France publie, d’une part, des bases de données géographiques, dans un format bien plus riche que celui des services comme l’IGN ou Digital Globe, et d’autre part la suite de logiciels ArcGIS pour les manipuler. « Les données publiques ne sont jamais gratuites. Nous en sommes donc d'abord un revendeur. Mais notre intérêt est surtout de packager ces données avec de nombreux champs d’information additionnels : ceux d’OpenStreetMap, ceux que nos clients personnalisent avec leurs données... », décrit Olivier de La Pommeraye.

« Nos logiciels servent à composer des cartes en superposant plusieurs calques d’informations, typiquement les données géographiques de références avec celles de nos clients (population active, etc.), puis à visualiser de manière interactive ces informations. Nous proposons des fonctions de recherche qui savent effectuer des calculs entre les données de différents champs, transformer des adresses en coordonnées, etc. Au final, nos solutions sont utilisées aussi bien pour administrer un patrimoine que pour produire des présentations géospatiales interactives, dont les très à la mode story maps. »

Jusqu’en 2012, Esri France vendait aux entreprises des solutions à installer sur leurs serveurs, tandis que la maison mère, aux USA, publiait déjà une version SaaS du logiciel ArcGIS. Pour répondre aux impératifs réglementaires liés à la localisation des données sur le territoire, tout en offrant le bénéfice de l’élasticité du cloud, Esri France a proposé dès 2012 de s’abonner à plusieurs offres « as-a-Service » locales.

On trouve ainsi les GéoServices, qui correspondent à la base géographique elle-même interrogeable en ligne, ArcGIS Online qui revient à des serveurs virtuels préinstallés avec ArcGIS, ainsi que des serveurs en IaaS, nus, sur lesquels les entreprises peuvent installer leurs licences ArcGIS Pro existantes. La promesse d’Esri France est de faire communiquer tout ce beau monde via un accès privé. Concernant les GéoServices, dont Olivier de La Pommeraye a plus spécialement la responsabilité, il s’agit de données contextuelles, mises à jour régulièrement, et qui sont interrogeables soit en JSON/REST par les serveurs et les applications modernes de décisionnel, soit en SOAP/XML, par les outils bureautiques historiques.

Tous ces services fonctionnent sur les machines physiques qu’Esri France fait héberger dans les datacenters du prestataire IPgarde. « IPgarde nous a spontanément proposé de surveiller nos serveurs au moyen du système de sondes PRTG de l’éditeur Paessler. Par défaut, ce sont des sondes très techniques, qui surveillent les couches basses de l’infrastructure : la consommation de la RAM et du stockage, la charge des processeurs et du réseau. Mais nous nous sommes rapidement aperçus que cela ne suffisait pas. », se souvient Olivier de La Pommeraye.

Avoir des yeux partout

Le défi technique auquel Esri France s’est retrouvé confronté lors de la mise en service de ses offres en ligne est que ses clients utilisent en permanence des fonctions qui font appel à des croisements complexes de processus. Dans ce contexte, le moindre grain de sable pourrait gripper leurs activités, mais il n’est pas trivial de savoir où il se trouve.

« Nous devions donc avoir des yeux partout et, en particulier, sur nos logiciels serveurs. Par exemple, nous devons savoir si le Tomcat que nous utilisons pour lancer les applications ne s’est pas arrêté, voire si nous n’avons pas oublié de le redémarrer sur une machine après une opération de maintenance. Il en va de même pour nos serveurs SQL et Postgre, pour les Windows et les Linux sous-jacents. Et vérifier la mise en route ne suffit pas, il faut aussi s’assurer que tous ces logiciels répondent bien sur les bons ports », indique Olivier de La Pommeraye, en précisant que, à ce jour, ce sont près de 1000 sondes qui ont été déployées.

Dans le détail, les six machines physiques dédiées aux GéoServices, dont deux pour l’encodage des informations et quatre pour la base elle-même, totalisent 270 sondes. Pour le service ArGis Online, ce sont 34 sondes par machine virtuelle Windows.

La vraie difficulté : qualifier les problèmes

En pratique, les sondes PRTG fonctionnent avec des scripts qui interrogent chaque service en Bash, en REST, en SQL, en HTTP. Lorsque le logiciel est installé la première fois, un scan automatique des ports ouverts sur les serveurs génère des sondes de base. Olivier de La Pommeraye précise que si cette étape permet de gagner beaucoup de temps, la première action à entreprendre est de faire le ménage pour ne conserver que les capteurs véritablement utiles.

« Nous avons commencé à déployer des sondes dès 2013. La partie la plus compliquée n’est pas d’avoir des métriques sur tous les processus, mais plutôt de faire le lien entre un problème rencontré par nos utilisateurs et sa cause parmi tous les rouages de l’infrastructure. Nous passons donc beaucoup de temps à qualifier un problème. Ensuite, il nous suffit de personnaliser un script pour les caractéristiques de ce problème », explique Olivier de La Pommeraye.

La personnalisation des capteurs consiste à définir quels paramètres il faut lire en particulier et quels seuils doivent produire des alertes. Un module par exemple, ne devrait déclencher une alerte que lorsque la taille de son stockage descend sous un certain seuil. Sur un autre, on ne s’intéressera qu’à sa bande passante.

« La console de visualisation web sur mon poste est très simple. Elle me permet de ranger les indicateurs selon mes réflexes oculaires. Elle m’envoie un SMS lorsqu’il y a une alerte importante et s’accompagne aussi d’une application mobile qui permet de prendre la main à distance sur l’administration des systèmes », explique-t-il.  

Elasticsearch pour croiser les métriques et identifier les problèmes complexes

Mais Olivier de La Pommeraye a réussi très simplement à aller beaucoup plus loin dans l’identification des problèmes. Entre les capteurs posés par PRTG et les alertes affichées dans la console web de la solution, l’ingénieur a créé des règles dans le moteur de recherche Elasticsearch qui croisent certaines mesures afin d’identifier un événement complexe. Pour exécuter ces règles en permanence, il manipule les scripts de PRTG afin qu’ils communiquent leurs relevés à Logstach, le module d’Elasticsearch dédié à l’ingestion des métriques systèmes.

 « Elasticsearch nous servait initialement à identifier quelles quantités de ressources nos clients utilisent sur notre plateforme afin de pouvoir les facturer. J’ai eu l’idée d’étendre son usage pour améliorer notre qualité de service. »

Parmi les problèmes complexes que cette technique lui permet d’identifier, il cite l’écueil très subtil d’images qui s’affichent plus floues que d’ordinaire, lorsque des représentations pré-calculées dans un certain format sont superposées à des informations conçues pour un autre format.

« De cette erreur découleront ensuite d’autre problèmes dans les scénarios d’usage. J’ai donc écrit une requête qui teste si cette erreur arrive et qui me permet d’intervenir avant que nos utilisateurs souffrent de complications bien plus pénalisantes pour leurs activités », se félicite-t-il.

Des sondes gratuites pour tester la connexion depuis l’extérieur

Mieux encore. PRTG étant gratuit pour les 100 premières sondes, Olivier de La Pommeraye a eu l’idée de déployer un second lot de capteurs, non pas dans le datacenter d’Esri France, mais dans l’agence où il travaille.

« J’ai paramétré ces capteurs sur nos postes de travail pour qu’ils se connectent à nos services en ligne et mesurent toutes les 30 minutes leur rapidité de réponse du point de vue d’un utilisateur. Je détecte non seulement les ralentissements avant qu’on m’appelle pour les signaler, mais, en corrélant dans Elasticsearch les relevés de mon poste avec ceux de nos serveurs, je sais même d’où vient la panne et comment la résoudre. Nous pouvons dès lors véritablement parler de proactivité », se réjouit-il.

Il indique que de telles sondes l’aident aussi à qualifier plus rapidement des problèmes. « C’est en croisant ces informations remontées par PRTG que je me suis rendu compte qu’un ralentissement côté utilisateur était dû, côté datacenter, à la copie de 2 To de données qui, elle, n’avait déclenché aucune alerte. »

Dans l’immédiat, Esri continuera de déployer des capteurs au fur et à mesure qu’il déploie de nouveaux serveurs et de nouveaux modules logiciels. « A court terme, nous nous abonnerons sans doute à Elastic Cloud pour bénéficier de leurs services d’IA susceptibles de détecter et qualifier automatiquement des problèmes que nous n’avons pas encore identifiés.  »