Les services natifs du cloud provider pour les métriques et les alertes, OpenTelemetry pour les traces.

Un article paru il y a quelques semaines dans l’International Journal of Computer Techniques propose cette stratégie d’observabilité pour le serverless. On le doit à une ancienne de Microsoft, qui fut notamment directrice scientifique au sein de l’activité Azure AI.

Son analyse porte plus précisément sur un sous-ensemble du calcul sans serveur : le FaaS (functions as a service). Dans ces environnements, les ressources sont généralement éphémères, distribuées et à haute concurrence. Les points d’intégration peuvent par ailleurs être nombreux… et inclure des services managés « en boîte noire » qui exigent de l’instrumentation.

Natif, full OpenTelemetry ou hybride ?

Les conclusions n’ont pas valeur de vérité absolue : l’expérimentation a été effectuée à petite échelle – de sorte qu’on peut la reproduire en local ou dans un compte de test – et tous les paramètres étaient sous contrôle.

Le cas d’usage exploré reposait sur des traces synthétiques de type e-commerce. Le workflow – présenté uniquement à haut niveau – comprenait 4 étapes : passerelle API -> fonction A -> fonction B (appel HTTP à une API externe non spécifiée) -> DynamoDB. Il s’agissait d’y adosser diverses stratégies d’observabilité, en mesurant 4 indicateurs :

• Allongement médian de la durée d’exécution des fonctions
• Proportion de traces complètes
• Délai médian pour découvrir la cause racine sur des simulations d’erreurs à partir de la télémétrie disponible
• Coût par million de requêtes (base : tarification publique de X-Ray et CloudWatch + estimations pour un back-end Jaeger autohébergé)

La première stratégie évaluée reposait intégralement sur les outils d’observabilité d’AWS (CloudWatch pour métriques et alertes, X-Ray pour les traces). La deuxième était full OpenTelemetry. La troisième, hybride, associait CloudWatch (télémétrie pilotée par les SLO) et OpenTelemetry (back-end Jaeger/Tempo ou managé), avec un échantillonnage adaptatif.

La méthode native est celle qui entraîne le moins de surcharge. Mais elle produit le plus de traces incomplètes, sauf à ajouter de l’instrumentation. Et s’il simplifie l’exploitation, X-Ray implique un certain verrouillage (limites de portabilité et de conservation de la télémétrie).
En centralisant sur OpenTelemetry, les traces sont plus « riches ». Mais l’overhead augmente. Comme les coûts, en plus des compétences nécessaires.
L’approche hybride orientée SLO (on ne collecte en haute fidélité que pour les éléments critiques de ce point de vue) n’est ni la plus « légère », ni la plus précise, ni la plus économique. Mais elle constitue un compromis.

À consulter en complément, une étude universitaire qui pointe – et chiffre – divers facteurs techniques et contractuels générateurs de surcoûts sur les principales plates-formes serverless.

Illustration © Aryan – Adobe Stock

The post Serverless : faut-il privilégier l’observabilité native ? appeared first on Silicon.fr.