Pourquoi diable l'observabilité est-elle si chère !?

N'attendez plus ! OFFRE À DURÉE LIMITÉE ! OPÉRATEURS À VOTRE DISPOSITION ! Je suis prêt(e) pour ma prochaine aventure en tant que défenseur(e) du développement, évangéliste technique et conteur(euse) informatique. Si cela vous intéresse, contactez-moi par e-mail ou sur LinkedIn.

Je suis spécialisé dans la surveillance et l'observabilité depuis 27 ans, et j'ai vu de nombreux outils et techniques apparaître et disparaître (RMon, ça vous dit ?) ; et plus d'un rester (les rumeurs sur la mort de SNMP ont été – et continuent d'être – largement exagérées). Dernièrement, j'ai exploré l'une des avancées les plus récentes dans ce domaine : OpenTelemetry (que j'abrégerai en « OTel » pour la suite de ce blog). J'ai récemment évoqué ma décision de me lancer dans OTel .

Dans l'ensemble, j'apprécie le voyage. Cependant, un problème d'observabilité persiste depuis un certain temps, et OTel ne résout pas ce problème. Le titre de cet article laisse entrevoir le problème, mais je souhaite être plus explicite. Commençons par comparer les offres.

Avant de m'en prendre à tous les fournisseurs, je tiens à préciser qu'il s'agit de chiffres généraux, approximatifs et de haut niveau. J'ai mis un lien vers les pages de tarifs si vous souhaitez consulter les détails, et je reconnais que ce que vous voyez ci-dessous n'est pas nécessairement représentatif du prix que vous pourriez payer après avoir obtenu un devis pour un environnement de production réel.

• Charges de New Relic

  • 35¢ par Go pour toutes les données que vous leur envoyez.
  • …bien que la page de tarification ne le précise pas clairement

  
  

• Datadog dispose d'une véritable liste d'options, mais à un niveau élevé, ils facturent :

  • 15 à 34 $ par hôte

  • 60 ¢ – 1,22 $ par million d'enregistrements de flux net

  • 1,06 à 3,75 $ par million d'enregistrements de journaux

  • 1,27 $ à 3,75 $ par million de travées

    
    

• La page de tarification de Dynatrace présente une liste presque aussi longue que celle de Datadog, mais quelques éléments clés :

  • 15¢ pour 100 000 métriques

    • plus 0,07 ¢ par Go par jour pour la rétention

  • 2¢ par gigaoctet pour les journaux

    • plus 0,07¢ par gig par jour pour les conserver
    • plus 0,035¢ par gig demandé

  • Les événements ont le même taux que les journaux

  • 0,014¢ pour 1 000 travées

    
    

• Grafana, qui, il faut le souligner, est open source et vous offre tout gratuitement si vous êtes prêt à vous investir dans l'installation et l'hébergement. Mais leur prix peut se résumer ainsi :

  • 8,00 $ pour 1 000 métriques (jusqu’à 1/minute)
  • 50¢ par Go pour les journaux et les traces, avec une conservation de 30 jours

Cette liste n'est ni exhaustive ni complète. J'ai omis de nombreux fournisseurs, non pas parce qu'ils ne proposent pas de tarification à la consommation, mais parce que ce serait du pareil au même. Même avec ceux mentionnés ci-dessus, les détails ici ne sont pas exhaustifs. Certaines entreprises facturent non seulement la consommation (ingestion), mais aussi le stockage des données et l'interrogation des données (comme New Relic). Certaines entreprises vous poussent à choisir un niveau de service, et si vous ne le faites pas, elles vous factureront un tarif estimé basé sur le 99e percentile d'utilisation du mois ( comme Datadog ).

Personne ne sera surpris d'apprendre que les informations figurant sur leur page de tarification ne sont pas définitives. Certaines de ces entreprises envisagent déjà de redéfinir leur interprétation du concept de « tarification à la consommation », ce qui pourrait rendre les choses encore plus opaques (je te regarde encore, New Relic).

Même avec tout cela dit, je prends des risques et je déclare officiellement que chacun de ces prix est si bas que même le mot « trivial » est trop gros.

Du moins, jusqu'à ce que les charges de production atteignent le prix annoncé. À ce stade, ces chiffres infimes se transforment rapidement en véritables gains.

Le pluriel d'anecdote

J'ai posé cette question à des amis, leur demandant s'ils avaient vécu des expériences vraiment choquantes. Comme toujours, ils ne m'ont pas déçu.

Il y a quelques années, j'ai effectué une comparaison détaillée des prix de New Relic et de Datadog, principalement avec Fargate. New Relic était nettement moins cher jusqu'à l'envoi des logs, puis Datadog est soudainement devenu 30 à 40 % moins cher, même avec APM. [Mais] leur coût par hôte est également pris en compte, ce qui rend APM peu attractif, sauf pour une solution sans serveur. Nous voulions l'utiliser sur Kubernetes, mais c'était tellement cher que la direction refusait de croire aux coûts des services sur Fargate ; je présentais donc généralement mes chiffres tous les 2 ou 3 mois. » – Evelyn Osman, responsable de la plateforme chez enmacc

« Tout ce que j’ai, c’est le souvenir du visage du directeur financier lorsqu’il a vu la facture. » – quelqu’un qui préfère rester anonyme, même si cette citation est vraiment épique.

Et bien sûr, il y a le mystère (désormais tristement célèbre dans les cercles d'observabilité) du projet de loi Datadog de 65 millions de dollars .

La première étape consiste à admettre que vous avez un problème

Il était une fois (j'entends par là le début des années 2000), le défi de la surveillance (l'observabilité n'était pas encore un terme que nous utilisions) était de savoir comment identifier les données dont nous avions besoin, puis faire en sorte que les systèmes fournissent ces données, puis les stocker d'une manière qui permette (sans parler de manière efficace) de les utiliser dans des requêtes, des affichages, des alertes, etc.

C'est là que résidait la quasi-totalité des coûts. Les systèmes eux-mêmes étaient sur site et, une fois le matériel acheté, ils étaient pratiquement « gratuits ». Par conséquent, la pratique courante était de collecter le plus d'informations possible et de les conserver indéfiniment. Et malgré l'évolution technologique, le raisonnement de nombreuses organisations est resté le même.

Alec Isaacson, architecte de solutions Grafana, souligne que ses conversations avec les clients se déroulent parfois ainsi :

« Je collecte les mesures CDM de mes systèmes les plus critiques toutes les 5 secondes car une fois, il y a longtemps, quelqu'un s'est fait crier dessus parce que le système était lent et les mesures ne lui disaient pas pourquoi. »

Aujourd'hui, collecter des données de surveillance et d'observabilité (« télémétrie ») est relativement simple, mais, tant en tant qu'individus qu'organisations, nous n'avons pas modifié notre façon de concevoir le problème. Nous continuons donc à exploiter toutes les données disponibles. Nous instrumentons notre code avec toutes les balises et étendues possibles ; s'il y a un message de journal, nous l'envoyons ; s'il y a des métriques matérielles ? Mieux vaut les récupérer, car elles fourniront du contexte ; s'il y a de la télémétrie réseau (NetFlow, journaux de flux VPC, télémétrie de streaming), nous l'exploitons également.

Mais nous ne prenons jamais le temps de réfléchir à ce que nous allons en faire. L'expérience de Mme Osman illustre bien ce résultat :

« [Ils] n'avaient aucune idée de ce qu'ils faisaient en matière de surveillance […]. Toute l'instrumentation et la journalisation étaient activées, puis il y avait une longue conservation « au cas où ». Ils gaspillaient donc des sommes astronomiques. »

Pour relier cela à un autre mauvais comportement dont nous nous sommes (plus ou moins) débarrassés : aux débuts du « lift and shift » (souvent plus précisément appelé « lift and shit ») vers le cloud, nous ne nous contentions pas de migrer les applications en bloc ; nous les déplacions sur les plus gros systèmes proposés par la plateforme. Pourquoi ? Parce que dans l'ancien contexte sur site, on ne pouvait demander un serveur qu'une seule fois, et donc on exigeait la plus grande chose possible, afin de pérenniser son investissement. Cette décision s'est avérée non seulement d'une naïveté amusante, mais aussi extrêmement coûteuse, et il a fallu quelques années à tout le monde pour comprendre le fonctionnement du « calcul élastique » et adapter ses applications au nouveau paradigme.

De même, il est grand temps que nous reconnaissions et admettions que nous ne pouvons pas nous permettre de collecter toutes les données de télémétrie dont nous disposons et, de plus, que nous n’avons pas de plan pour ces données, même si l’argent n’était pas un problème.

Admettez-le : votre problème a aussi un problème

Permettez-moi de revenir brièvement sur l'hôtellerie-restauration. L'une des principales raisons – peut-être LA principale – de s'y engager est de supprimer définitivement le problème de la dépendance vis-à-vis d'un fournisseur. J'ai abordé ce sujet dans mon dernier article de blog et un ami m'en a récemment fait part :

OTel résout de nombreux problèmes du type « Super ! Maintenant, on est coincés avec le fournisseur x et ça va nous coûter des millions de dollars pour refactoriser tout ce code », plutôt que « Oh, on change de fournisseur ? Super, je vais juste mettre à jour mon terminal… » – Matt Macdonald-Wallace, architecte de solutions, Grafana Labs

Pour être clair, OTel fait un travail remarquable pour résoudre ce problème, ce qui est déjà incroyable en soi. MAIS… OTel présente un inconvénient que les gens ne remarquent pas immédiatement, voire pas du tout. Ce problème aggrave encore le précédent.

OTel collecte toutes vos données (métriques, journaux, traces, etc.) et les envoie où vous le souhaitez. Mais OTel ne le fait pas toujours de manière efficace.

Exemple 1 : messages de journal

Prenons le message de journal ci-dessous, directement issu de Syslog. Oui, la bonne vieille RFC 5424. Née dans les années 80, normalisée en 2009, elle est devenue le « babillard » incontesté des protocoles de messagerie réseau. J'ai vu des réseaux de taille modeste générer plus de 4 millions de messages Syslog par heure. La plupart étaient des balivernes absolument inutiles, remarquez. Mais ces messages devaient bien aller quelque part et être traités (ou supprimés) par un système en cours de route. C'est l'une des raisons pour lesquelles je suggère un « système de filtrage » Syslog et Trap depuis presque toujours .

Au-delà des critiques sur le volume des messages, certains d'entre eux présentent parfois une valeur pour certains professionnels de l'informatique. Il est donc essentiel de les prendre en compte (et de les collecter) également.

 <134>1 2018-12-13T14:17:40.000Z myserver myapp 10 - [http_method="GET"; http_uri="/example"; http_version="1.1"; http_status="200"; client_addr="127.0.0.1"; http_user_agent="my.service/1.0.0"] HTTP request processed successfully

Tel quel, ce message de journal fait 228 octets, soit à peine une goutte d'eau dans la masse de données télémétriques collectées chaque minute, et encore moins chaque jour. Mais pour ce qui m'intéresse, je souhaite une comparaison concrète. Voici donc à quoi cela ressemblerait si je le transformais en JSON :

 {  "pri": 134,  "version": 1,  "timestamp": "2018-12-13T14:17:40.000Z",  "hostname": "myserver",  "appname": "myapp",  "procid": 10,  "msgid": "-",  "structuredData": { "http_method": "GET", "http_uri": "/example", "http_version": "1.1", "http_status": "200", "client_addr": "127.0.0.1", "http_user_agent": "my.service/1.0.0"  },  "message": "HTTP request processed successfully" }

Cela porte la charge utile à 336 octets sans espaces, ou 415 octets avec. À titre de comparaison, voici un exemple de message de journal OTLP :

 { "resource": { "service.name": "myapp", "service.instance.id": "10", "host.name": "myserver" }, "instrumentationLibrary": { "name": "myapp", "version": "1.0.0" }, "severityText": "INFO",  "timestamp": "2018-12-13T14:17:40.000Z",  "body": { "text": "HTTP request processed successfully"  },  "attributes": { "http_method": "GET", "http_uri": "/example", "http_version": "1.1", "http_status": "200", "client_addr": "127.0.0.1", "http_user_agent": "my.service/1.0.0"  } }

Ce message (générique et minimal) pèse 420 octets (sans les espaces ; il fait 520 octets tout compris). C'est encore petit, mais malgré cela, la version OTel avec les espaces est 25 % plus volumineuse que le message JSON-ifié (avec les espaces), et plus de deux fois plus volumineuse que le message de journal d'origine.

Dès que nous commençons à appliquer des données réelles, les choses s'amplifient encore. Ce que je veux dire, c'est que si OTel applique cette procédure à chaque message de journal, ces coûts minimes s'accumulent rapidement.

Exemple 2 : Prométhée

Il s’avère que les méthodes modernes de gestion des métriques sont tout aussi sensibles à l’inflation.

• Une métrique Prometheus typique, formatée en JSON, est de 291 octets.
• Mais cette même métrique convertie au format métrique OTLP pèse 751 octets.

Certes, OTLP dispose d'une fonction de traitement par lots qui atténue ce problème, mais cela ne facilite que le transfert par câble. Une fois arrivé à destination, de nombreux fournisseurs (pas tous, mais la plupart) le dégroupent avant de le stocker, ce qui le rend 2,5 fois plus volumineux que le message d'origine. Comme l'a dit mon ami Josh Biggley :

« Les métriques 2,5x ingérées ont mieux à raconter sur le contexte pour justifier ce coût. »

Ce n'est pas toi, OTel, c'est nous. (Mais c'est aussi toi)

Si tout cela vous semble un peu trop critique envers OTel, donnez-moi l'occasion de m'expliquer. Je suis sincèrement convaincu qu'OTel représente une avancée considérable et que toute personne soucieuse de la surveillance et de l'observabilité doit l'adopter comme norme, tant pour les utilisateurs que pour les fournisseurs. La possibilité d'émettre une multitude de journaux, de métriques et de traces tout en conservant leur contexte, quelle que soit la destination, est inestimable.

(Mais…) OTel a été conçu par (et pour) des ingénieurs logiciels. Il est né à une époque révolue (j'entends par là « 2016 »), où nous étions encore plus préoccupés par la difficulté d'obtenir les données que par le coût de leur transfert, de leur traitement et de leur stockage. OTel est, par nature, axé sur le volume.

Malgré l'humour du titre de cette section, le problème ne vient pas vraiment d'OTel. C'est nous qui sommes en cause. Plus précisément, notre relation malsaine avec la télémétrie. Si nous insistons pour collecter et transmettre chaque point de données, nous ne pouvons nous en prendre qu'à nous-mêmes pour les factures exorbitantes que nous recevons à la fin du mois.

Ces données vous apportent-elles de la joie ?

Il est facile de laisser votre solution d'observabilité faire le gros du travail et de transférer chaque octet de données vers une interface unifiée. C'est facile à mettre en œuvre si vous êtes un ingénieur logiciel qui (du moins théoriquement) possède les solutions de surveillance et d'observabilité.

C'est encore plus simple si vous êtes un simple consommateur de ces services, un simple observateur. Parmi ces personnes figurent celles étroitement liées à un silo particulier (base de données, stockage, réseau, etc.) ; les équipes d'assistance et de centre d'exploitation réseau (NOC) qui reçoivent les tickets et fournissent une assistance, mais ne sont impliquées ni dans l'instrumentation ni dans les outils auxquels elle est connectée ; ou encore les équipes ayant des besoins plus spécialisés qui recoupent néanmoins la surveillance et l'observabilité, comme la sécurité de l'information.

Mais soyons honnêtes : si vous êtes ingénieur en sécurité, comment pouvez-vous justifier de payer deux fois plus cher pour ingérer des journaux ou des métriques, par rapport aux normes parfaitement fiables qui existent déjà et qui fonctionnent bien depuis des années ? Cela signifie-t-il que vous utilisez plusieurs outils ? Oui. Mais comme je l’ai souligné ( à maintes reprises ), il n’existe pas (et n’a jamais existé, et n’existera jamais) de solution universelle. Et dans la plupartdes cas , il n’existe même pas de solution universelle. La surveillance et l’observabilité ont toujours reposé sur des implémentations hétérogènes. Plus tôt vous adopterez cet idéal, plus tôt vous commencerez à construire des écosystèmes d’observabilité adaptés à vos besoins, à ceux de votre équipe et à ceux de votre entreprise.

À cette fin, il y a une discussion sérieuse sur le retour sur investissement à mener avant de vous lancer à fond dans OTel ou toute autre solution d'observabilité.

<EOF> (pour l'instant)

Nous avons déjà assisté par le passé à l'évolution d'une tarification par poste (ou interface, châssis ou processeur) vers un modèle à la consommation. Nous avons également assisté à un retour en arrière technologique (comme le passage du service mobile à la minute ou au SMS à des données illimitées avec un abonnement mensuel). Je soupçonne que nous assisterons à un retour en arrière similaire en matière de surveillance et d'observabilité. Mais pour l'instant, nous devons composer avec le système de tarification actuel et avec notre propre compulsion – née à un autre moment de l'histoire de la surveillance – à collecter, transmettre et stocker chaque bit (et octet) de télémétrie qui passe sous notre nez.

Bien sûr, le coût n'est pas le seul facteur. La performance, le risque (et bien d'autres) doivent être pris en compte. Mais au cœur de tout cela se trouve la nécessité impérieuse de commencer à nous poser les questions suivantes :

• Que vais-je faire de ces données ?
• Qui l'utilisera ?
• Combien de temps dois-je le conserver ?

Et bien sûr, qui diable va payer pour ça ?