Dzmitry Lazerka, cofondateur de VictoriaMetrics – Série d’interviews

Dzmitry Lazerka, cofondateur de VictoriaMetrics est un ingénieur logiciel chevronné et un leader technologique doté d’une expertise approfondie en apprentissage automatique, systèmes de données à grande échelle, observabilité et infrastructure. Avant de co‑fonder VictoriaMetrics en 2018, il a travaillé comme ingénieur en apprentissage automatique chez la division de véhicules autonomes Level 5 de Lyft, où il a contribué au développement de systèmes de reconnaissance et d’analyse de scénarios de conduite réels. Auparavant, il a dirigé des projets d’apprentissage automatique et d’infrastructure de données chez Spire Global, a été cofondateur technique chez Bellgram, et a travaillé sur des systèmes de données et d’analytique chez Duetto Research et Google via EPAM Systems. Tout au long de sa carrière, Lazerka a construit et dirigé des projets couvrant la conduite autonome, la prévision maritime, la recherche, l’analytique, le traitement distribué de données et des systèmes back‑end hautement évolutifs.

VictoriaMetrics est une société d’observabilité open source qui développe des outils de collecte, de stockage, d’interrogation et d’analyse de grands volumes de données opérationnelles. Sa technologie a commencé avec VictoriaMetrics, une base de données de séries temporelles haute performance et une solution de surveillance conçue pour l’évolutivité, les requêtes rapides, le stockage efficace et une faible surcharge opérationnelle, et s’est depuis étendue en une pile d’observabilité plus large couvrant les métriques, les journaux et les traces distribuées via VictoriaMetrics, VictoriaLogs et VictoriaTraces. L’entreprise propose également des déploiements cloud d’entreprise et entièrement gérés, ainsi que des capacités de détection d’anomalies qui appliquent l’apprentissage automatique aux données de séries temporelles. Sa plateforme prend en charge des technologies telles qu’OpenTelemetry, les flux de travail compatibles Prometheus, Grafana et Kubernetes, offrant aux organisations la flexibilité d’intégrer VictoriaMetrics dans leurs environnements d’observabilité existants.

Avant de co‑fonder VictoriaMetrics, vous avez travaillé sur des systèmes de données à grande échelle, d’analytique et d’apprentissage automatique chez Google, Spire Global, la division de véhicules autonomes de Lyft et d’autres startups. Qu’est‑ce qui vous a finalement conduit à créer VictoriaMetrics, et quels problèmes rencontrés dans ces fonctions antérieures vous ont convaincu que la surveillance et l’observabilité nécessitaient une approche fondamentalement différente ?

J’ai passé ma carrière à travailler avec de grandes quantités de données. Chez Google, Spire, Lyft et d’autres entreprises, on apprend rapidement qu’une solution qui fonctionne bien à une certaine échelle peut devenir coûteuse ou difficile à exploiter à une autre échelle. La surveillance présente exactement ce problème.

À mesure que l’infrastructure se développe, vous créez davantage de métriques. Vous ajoutez plus de services, plus d’instances et plus d’étiquettes jusqu’à ce que, soudainement, le système de surveillance lui‑même nécessite une quantité importante d’infrastructure, ce qui n’a jamais eu de sens pour nous. Un système conçu pour surveiller votre environnement de production ne devrait pas devenir plus compliqué et coûteux à exploiter.

Voici ce que mes co‑fondateurs Aliaksandr Valialkin et Roman Khavronenko ont constaté directement. Ils avaient de l’expérience dans l’exploitation de Prometheus et ont rencontré des limites de mémoire. L’ajout de systèmes comme Thanos a résolu certains problèmes d’évolutivité, mais a également introduit davantage de composants et une complexité opérationnelle accrue. Et avec InfluxDB, nous avons vu comment un changement de licence pouvait influencer les décisions d’ingénierie après que les équipes aient déjà investi dans la technologie.

L’idée derrière VictoriaMetrics était donc pratique : pouvons‑nous créer une base de données de séries temporelles qui accomplit la même tâche avec nettement moins de ressources et qui soit plus simple à exploiter ?

Nous n’avions pas pour objectif de créer une grande société d’observabilité. Nous avons commencé par résoudre un problème d’ingénierie.

Le rendre open source faisait partie de cela. Les ingénieurs pouvaient télécharger VictoriaMetrics, y soumettre de vraies charges de travail de production et comparer les résultats eux‑mêmes. Nous n’avions pas besoin de leur dire que c’était plus rapide ou plus efficace. Ils pouvaient le mesurer.

C’est la meilleure façon de construire des logiciels d’infrastructure. Si la technologie est bonne, les ingénieurs devraient pouvoir le prouver eux‑mêmes.

Les coûts d’observabilité peuvent discrètement devenir une part importante de la facture cloud d’une entreprise. Où ces coûts explosent‑ils généralement, et quelles décisions architecturales ou d’achat les équipes d’ingénierie se trompent‑elles le plus souvent ?

Je commencerais par examiner la cardinalité.

Supposons que vous commenciez avec une métrique raisonnable, puis ajoutiez une étiquette avec des valeurs possibles. Soudain, une métrique se transforme en milliers ou millions de séries temporelles uniques. Le système doit désormais ingérer, indexer, stocker et interroger davantage de données, ce qui entraîne une consommation accrue de CPU, de mémoire et de stockage.

Le point difficile, c’est que cela ne survient pas parce que quelqu’un a pris une mauvaise décision. Cela se produit progressivement. Ajoutez plus de services, de pods K8s, de clients et d’étiquettes, et le coût se multiplie.

Le deuxième problème est de stocker tout à la même résolution pendant la même durée. Toutes les données d’observabilité n’ont pas la même valeur. Les métriques dont vous avez besoin pour une alerte ou un SLO diffèrent de la télémétrie diagnostique à haut volume que vous ne consultez qu’une fois lors d’un incident.

Si vous traitez toutes ces données de la même façon, vous finissez par payer des prix premium d’infrastructure ou de SaaS pour des données qui n’en nécessitent pas.

C’est pourquoi certaines entreprises abordent l’observabilité comme un problème d’achat, en se demandant quelle plateforme est la plus facile à déployer aujourd’hui. Je pose des questions telles que : « Que se passe‑t‑il lorsque la quantité de télémétrie augmente de 10 fois ? Que devient la cardinalité ? Que stockons‑nous ? Pendant combien de temps ? Et que se passe‑t‑il avec le coût ? »

Il existe des solutions d’ingénierie à ces problèmes. Par exemple, grâce à l’agrégation en flux, vous pouvez agréger les métriques avant qu’elles n’atteignent le stockage au lieu de stocker chaque série brute puis de l’agréger ultérieurement. Vous pouvez séparer les charges de travail à haute cardinalité de la surveillance critique pour l’entreprise. Vous pouvez également appliquer des politiques de rétention et de résolution différentes en fonction de la valeur des données.

L’objectif n’est pas de collecter le moins de télémétrie possible. Vous avez besoin de suffisamment d’informations pour comprendre ce que font vos systèmes.

L’objectif est d’éviter de dépenser des ressources à collecter, traiter et stocker des données d’une manière qui ne vous apporte aucune valeur supplémentaire.

L’observabilité est un système d’ingénierie. Son coût doit également être conçu.

Grammarly a déclaré que son proof‑of‑concept avec VictoriaMetrics s’est traduit par une facture AWS dix fois plus basse. Lorsque les entreprises réalisent des économies à cette échelle, qu’est‑ce qui change réellement sous le capot : la compression des données, les besoins en calcul, l’architecture de stockage, la complexité opérationnelle, ou une combinaison de ces facteurs ?

C’est une combinaison, mais la compression et l’empreinte des ressources font la majeure partie du travail. VictoriaMetrics utilise une compression spécialement conçue pour les données de séries temporelles, de sorte que les mêmes métriques occupent une fraction de l’espace disque qu’elles prendraient dans une base de données à usage général. De plus, nous consommons quatre à cinq fois moins de RAM que Prometheus à des débits d’ingestion équivalents, et jusqu’à dix fois moins de disque. Lorsque Grammarly a réalisé son proof‑of‑concept, cela s’est reflété directement sur sa facture AWS, car ils ne stockaient pas seulement moins de données ; ils exécutaient également moins d’instances, et des instances plus petites.

La composante de complexité opérationnelle compte également, mais de façon plus indirecte. De nombreuses équipes qui évaluent les coûts d’observabilité ne considèrent que les lignes de stockage et de calcul et négligent les heures d’ingénierie consacrées à l’exploitation d’une pile Thanos à cinq composants versus un seul binaire. C’est de l’argent réel ; c’est simplement plus difficile à quantifier.

Prometheus est devenu incontournable pour la surveillance cloud‑native, mais certaines organisations finissent par rencontrer des limites d’évolutivité ou opérationnelles. Qu’est‑ce qui pousse généralement une entreprise à envisager des solutions au‑delà d’un déploiement Prometheus conventionnel, et à quel moment VictoriaMetrics devient‑il une alternative logique ?

Prometheus excelle dans ce pour quoi il a été conçu : un moteur de collecte et d’alerte mononœud. Les équipes se heurtent généralement à deux limites : soit leur cardinalité dépasse ce qu’une instance unique de Prometheus peut contenir en mémoire, soit elles ont besoin d’une rétention à long terme et de requêtes globales sur plusieurs clusters, ce que Prometheus n’a jamais été conçu pour faire seul. C’est alors que l’on ajoute Thanos ou Cortex, ce qui est généralement le moment où la douleur opérationnelle commence. Vous passez d’un seul binaire à un système distribué avec un compresseur, un interrogeur, une passerelle de stockage et bien d’autres composants qui peuvent tomber en panne à 3 h du matin.

VictoriaMetrics devient l’étape logique suivante parce qu’il s’agit d’un remplacement direct, pas d’une réarchitecture. Les équipes pointent leur configuration de collecte Prometheus existante vers VictoriaMetrics et conservent chaque tableau de bord Grafana, alerte et règle d’enregistrement déjà créés. La migration se résume à un changement de configuration, pas à un projet, et elles obtiennent l’échelle sans ajouter cinq nouveaux composants à gérer.

Nous constatons que les équipes d’ingénierie reconsidèrent la nécessité de grandes plateformes d’observabilité entièrement gérées ou la possibilité de construire des piles plus efficaces à partir de composants open source. Voyez‑vous cela comme un changement structurel plus large du marché de l’observabilité, et dans quelle mesure l’open source fait‑il pression sur les modèles de tarification traditionnels ?

C’est structurel ; ce n’est pas une réaction temporaire à une mauvaise année budgétaire. Les fournisseurs d’observabilité ont historiquement facturé soit en fonction du volume d’ingestion, soit du nombre d’hôtes, et ce modèle pénalise le client à mesure que son activité se développe. Plus une entreprise réussit, plus elle paie, et le prix n’a aucune réelle corrélation avec la valeur livrée. Les équipes d’ingénierie ont commencé à faire leurs propres calculs, réalisant qu’une pile open source auto‑hébergée et efficace change complètement cette équation. En effet, le coût évolue avec l’infrastructure réellement utilisée plutôt qu’avec une formule de mesure contrôlée par le fournisseur.

Cela exerce une vraie pression sur les tarifs des acteurs historiques. Lorsqu’une équipe peut pointer sa configuration de collecte existante vers une alternative open source et réduire la facture de 60 à 80 % sans perdre de fonctionnalité, la discussion interne devient nettement plus simple. Les fournisseurs qui facturent encore par hôte ou par métrique personnalisée continueront à perdre les clients qui ne font pas ces calculs.

L’infrastructure IA introduit une ressource nouvelle et très coûteuse dans l’équation : les GPU. Que doivent surveiller les entreprises qui exécutent des entraînements ou des inférences IA au‑delà de l’utilisation basique des GPU, et où une meilleure observabilité peut‑elle se traduire directement en réduction des coûts d’infrastructure IA ?

L’utilisation du GPU à elle seule ne suffit pas.

Vous pouvez voir 90 % d’utilisation sur un tableau de bord et supposer que tout va bien. Mais ce que vous voulez réellement savoir, c’est : que fait le GPU ?

Il faut aller plus loin. Quels noyaux CUDA s’exécutent ? Comment la mémoire du GPU est‑elle allouée ? Combien de temps est‑il passé à déplacer de la mémoire plutôt qu’à effectuer des calculs ? La charge de travail utilise‑t‑elle les Tensor Cores quand elle le devrait ? Le GPU est‑il réellement le goulot d’étranglement, ou attend‑il des données provenant d’ailleurs ?

Ce sont des questions importantes parce que les GPU sont coûteux. Une petite inefficacité répétée sur des centaines ou des milliers de GPU représente une très grosse somme d’argent.

Par exemple, si les GPU attendent parce que le pipeline de données ne les alimente pas assez rapidement, acheter plus de GPU ne résoudra pas le problème. Il faut identifier le goulot d’étranglement. Il en va de même pour la mémoire. Si les charges de travail allouent la mémoire de façon inefficace, une meilleure visibilité peut aider les ingénieurs à ajuster les tailles de lots ou à exécuter davantage de charges sur le même matériel.

C’est là que l’observabilité devient intéressante pour l’infrastructure IA. Il ne s’agit pas seulement de détecter qu’un problème existe. Elle peut indiquer où vous gaspillez du calcul.

Il existe également un problème d’observabilité créé par toute cette surveillance. Les GPU peuvent générer une grande quantité de télémétrie détaillée et à haute cardinalité. Si vous collectez tout et l’envoyez directement vers une plateforme SaaS coûteuse, vous pouvez réduire vos coûts GPU puis consacrer une partie des économies au stockage des données de surveillance. Mais ce n’est pas une optimisation judicieuse.

Avec OpenTelemetry et des projets tels qu’OpenLIT, nous pouvons obtenir une visibilité bien plus profonde sur les charges de travail GPU. Ensuite, avec VictoriaMetrics, nous pouvons agréger les données, supprimer les dimensions inutiles et conserver efficacement les informations dont les ingénieurs ont réellement besoin.

La question utile n’est pas : « Quel est le taux d’utilisation de mes GPU ? »

C’est : « Quel travail utile tire‑je des GPU que je paie ? »

Une fois que vous pouvez répondre à cela, vous pouvez commencer à prendre de meilleures décisions d’ingénierie et de coûts.

Les agents IA créent des défis d’observabilité très différents de ceux des logiciels traditionnels, car une seule requête peut déclencher des appels de modèle, l’utilisation d’outils, des requêtes de bases de données vectorielles, des transferts, et potentiellement de longues chaînes d’actions autonomes. Comment l’observabilité doit‑elle évoluer à mesure que les applications d’entreprise deviennent de plus en plus agentiques ?

L’observabilité traditionnelle suppose qu’une requête suit un chemin assez prévisible à travers votre infrastructure. Les charges de travail agentiques ne fonctionnent pas ainsi. Un seul agent peut appeler un modèle, puis un outil, puis un autre modèle et réessayer trois fois avant de renvoyer quoi que ce soit. Chacune de ces étapes nécessite sa propre visibilité.

Les modes d’échec sont également différents. Un service traditionnel répond correctement ou ne répond pas. Un agent peut répondre avec succès et être tout de même erroné, lent ou coûteux, et rien de cela n’apparaît comme une erreur typique dans un tableau de bord conçu pour la disponibilité.

Ce qui surprend les équipes, c’est la cardinalité. Un flux de travail d’agent unique peut générer des métriques liées à un utilisateur, une invite et un appel d’outil spécifiques, et ce volume s’accumule rapidement, surtout avec des boucles récursives où un planificateur continue d’appeler le même outil. Tout système destiné à observer les charges de travail agentiques doit gérer cette échelle sans que la courbe de coût ne devienne verticale, ce qui est exactement le problème que nous résolvons. Les métriques, les journaux et les traces restent les bons blocs de construction. Ce qui doit changer, c’est le volume et le modèle de coût sous‑jacent.

VictoriaMetrics applique également l’apprentissage automatique et les flux de travail assistés par IA à la détection d’anomalies. Où pensez‑vous que l’IA peut réellement améliorer la surveillance et la réponse aux incidents aujourd’hui, et où le jugement humain reste‑t‑il difficile à remplacer ?

Il est important de garder une personne dans la boucle pour générer des idées, orienter la mise en œuvre et valider les résultats. En d’autres termes, rien n’a vraiment changé par rapport au flux de travail traditionnel. Ce qui a changé, c’est que les capacités de génération de solutions sont amplifiées. Tout le monde peut créer des logiciels maintenant, mais cela ne doit pas abaisser les critères d’acceptation. Au contraire, ils doivent être nettement renforcés.

L’IA aide réellement à faire ressortir ce qu’une personne manquerait autrement dans le bruit, comme les valeurs aberrantes et les tendances qui ne déclenchent pas un seuil manuel. Chez VictoriaMetrics, nous avons une politique interne simple en matière d’IA : les employés sont libres d’automatiser leur flux de travail comme ils le souhaitent, mais ils restent responsables du résultat final. C’est à peu près le même standard que nous appliquerions à la détection d’anomalies dans l’environnement de production d’un client. Le modèle peut le signaler, mais une personne doit encore décider de ce que cela signifie et de la marche à suivre.

VictoriaMetrics est resté open source et a adopté une approche autofinancée, financée par les clients, plutôt que de suivre le modèle traditionnel de startup d’infrastructure soutenue par du capital risque. Comment cela a‑t‑il influencé votre façon de construire le produit, de le tarifer et de décider quelles technologies restent open source ?

Être autofinancé modifie la structure d’incitation plus que les gens ne l’imaginent. Sans conseil d’administration nous demandant d’atteindre un chiffre d’affaires récurrent à un trimestre donné, nous n’avons pas eu à faire les compromis habituellement imposés par cette pression, comme affaiblir la version open source pour forcer les utilisateurs à passer à un niveau payant, ou changer la licence comme l’ont fait InfluxDB ou HashiCorp lorsqu’ils ont dû protéger leurs revenus face aux fournisseurs de cloud. VictoriaMetrics OSS est aujourd’hui sous licence Apache 2.0, et nous n’envisageons aucun changement.

La façon dont nous décidons ce qui reste open source est simple : le moteur central, ce dont les ingénieurs ont besoin pour nous confier leurs données de production, reste ouvert. Nous facturons ce dont une entreprise a besoin une fois qu’elle fonctionne à grande échelle et a besoin de quelqu’un de responsable : la multi‑location, l’authentification d’entreprise, le support de conformité, un SLA CVE et un accès direct aux ingénieurs qui ont écrit le code plutôt qu’une file d’attente de support. Être financé par les clients signifie également que la feuille de route est dictée par les problèmes réels rencontrés en production, et non par ce qui est finançable dans un pitch deck.

Alors que les métriques, les journaux, les traces, la télémétrie des applications IA, la surveillance GPU et la détection d’anomalies automatisée convergent de plus en plus, à quoi pensez‑vous que la pile d’observabilité ressemblera dans les prochaines années, et quelles attentes les équipes d’ingénierie auront‑elles envers les plateformes qui souhaitent rester pertinentes ?

La pile converge opérationnellement avant de converger en un produit unique, et cette distinction est importante. La plupart des équipes ne veulent pas d’une plateforme monolithique avec une interface unique qui verrouille tout. Ce qu’elles souhaitent, ce sont des métriques, des journaux et des traces fonctionnant sur un même modèle opérationnel, un seul fournisseur et une histoire de licence unique, sans devoir renoncer à la possibilité d’exécuter chaque signal indépendamment si c’est ce dont une équipe a besoin. C’est la direction dans laquelle VictoriaMetrics se développe. Nous n’essayons pas d’assembler tout dans un seul binaire. Nous voulons nous assurer que les trois signaux partagent le même moteur et les mêmes caractéristiques d’efficacité, de sorte qu’ajouter un deuxième ou un troisième signal ne signifie pas adopter un deuxième ou troisième casse‑tête opérationnel.

Les plateformes qui restent pertinentes sont celles qui peuvent absorber la télémétrie IA et la surveillance GPU dans ce même modèle sans que la courbe de coût ne se brise. Les charges de travail IA génèrent une télémétrie à un volume pour lequel les tarifs legacy par métrique ou par hôte n’ont jamais été conçus. Les équipes arrêtent soit de collecter les données dont elles ont besoin, soit leur facture d’observabilité augmente plus rapidement que l’investissement IA qu’elle est censée surveiller. Les équipes d’ingénierie s’attendront à ce que les plateformes gèrent ce volume de la même façon qu’elles attendent que toute infrastructure s’évolue, sans leur demander de réarchitecturer ou de renégocier à chaque fois que la charge de travail augmente.

Merci pour cet excellent entretien, les lecteurs qui souhaitent en savoir plus devraient visiter VictoriaMetrics.