Lacunes silencieuses de traçage et gonflement du disque dans Langfuse auto-hébergé

Un développeur a découvert que sa plateforme d'observabilité Langfuse auto-hébergée ne captait qu'une fraction de l'activité de ses agents IA, entraînant des données de performance trompeuses. L'enquête a révélé que des négligences de configuration avaient provoqué des échecs silencieux de la surveillance sur la plupart des profils d'agents, tandis que la base de données sous-jacente accumulait des gigaoctets de journaux internes inutiles.

Ce qui s'est passé

Le problème est apparu lorsqu'un agent IA a mis vingt-cinq minutes pour répondre à une simple commande visant à publier une réponse sur un forum. Au lieu d'exécuter la tâche, le modèle a généré un résumé fictif de l'article cible. Le développeur a consulté ses traces Langfuse pour diagnostiquer le délai, s'attendant à voir des latences réseau ou des goulets d'étranglement dans l'exécution des outils. Les données de trace montraient que les outils web s'exécutaient en moins de cinq secondes, tandis que le modèle de langage local passait plus de vingt-cinq minutes à traiter. La cause racine n'était pas la performance, mais le contexte : la session de l'agent avait commencé avant que la compétence de publication ne soit disponible, ce qui a poussé le modèle à improviser plutôt qu'à utiliser un outil manquant.

Cet incident a incité à un audit plus approfondi de la configuration d'observabilité. Le développeur a comparé le nombre de sessions enregistrées dans la base de données interne de son agent avec les traces stockées dans Langfuse sur une période de quatorze jours. L'agent avait exécuté 1 387 appels de modèle répartis sur 188 sessions, alors que Langfuse ne contenait que 618 événements issus de 79 traces. Une analyse plus poussée a montré que le traçage n'était activé que sur un seul des dix profils d'agents, ce qui signifiait que le système surveillait environ 7 % du trafic total. Les profils les plus actifs, y compris ceux dédiés aux tâches de codage et de sécurité, étaient totalement invisibles pour la plateforme d'observabilité.

La deuxième découverte majeure concernait la consommation de stockage. La version 3 de Langfuse utilise ClickHouse comme magasin principal de traces, aux côtés de PostgreSQL et Redis. Alors que les données de trace réelles n'occupaient que 2,2 MiB, l'instance ClickHouse utilisait plus de 6 GiB d'espace disque. La majorité de cet espace était consommée par les tables de diagnostic système de ClickHouse elle-même, telles que les journaux de trace et les journaux de métriques, qui écrivaient en continu. Cette journalisation excessive créait une charge importante d'entrées-sorties sur la machine hôte, contribuant à des tempêtes de performances périodiques sur le disque dur.

Détails clés

• Le traçage n'était actif que sur un seul des dix profils d'agents, captant environ 7 % de tous les appels de modèle.
• Les profils non tracés incluaient des agents à fort volume pour les tâches de codage, de sécurité et d'administration informatique.
• Les journaux système de ClickHouse consommaient 6,03 GiB d'espace disque, tandis que les données de trace réelles n'utilisaient que 2,2 MiB.
• Le plugin de traçage échoue silencieusement lorsque les clés API sont manquantes, sans fournir de messages d'erreur ni d'avertissements dans les journaux.
• Les travaux ponctuels exécutés en mode sécurisé contournent entièrement les plugins, nécessitant une intégration SDK distincte pour le traçage.
• La suppression des tables de journaux système de ClickHouse via la configuration arrête les nouvelles écritures, mais ne supprime pas automatiquement les données existantes.

Contexte

Langfuse est une plateforme d'observabilité open source conçue pour les applications basées sur les grands modèles de langage. Elle aide les développeurs à suivre les coûts, la latence et les retours utilisateurs en enregistrant les traces des interactions entre les agents et les modèles. L'auto-hébergement de Langfuse donne aux équipes le contrôle de leurs données, mais nécessite la gestion de l'infrastructure sous-jacente, y compris la couche de base de données. Dans la version 3, Langfuse repose sur ClickHouse, un système de gestion de bases de données orienté colonnes optimisé pour le traitement analytique en ligne (OLAP). ClickHouse est puissant pour gérer de gros volumes de données de séries chronologiques, mais il inclut des fonctionnalités de journalisation interne étendues qui surveillent ses propres performances et opérations.

Les motifs de conception « fail-open » sont courants dans les plugins logiciels afin de garantir qu'une dépendance manquante ne fasse pas planter l'application principale. Dans ce contexte, si le plugin de traçage ne trouve pas de credentials API valides, il se désactive simplement au lieu de lever une erreur. Bien que cela empêche les plantages d'application, cela crée un angle mort où la surveillance cesse sans alerter l'opérateur. Comprendre la distinction entre les erreurs au niveau de l'application et les lacunes silencieuses de configuration est crucial pour maintenir une observabilité fiable dans les systèmes distribués.

Pourquoi c'est important

Pour les équipes gérant leur propre infrastructure IA, une observabilité incomplète peut conduire à des conclusions erronées sur les performances et les coûts du système. Dans ce cas, le développeur suspectait initialement des problèmes réseau en raison du temps de réponse long, mais la trace a révélé que le problème résidait dans le raisonnement du modèle au sein d'une session obsolète. Si le traçage avait été actif sur l'agent de codage, qui représentait la majorité des appels, l'équipe aurait eu une visibilité sur la fréquence à laquelle les modèles locaux atteignaient des queues de latence par rapport aux alternatives cloud. Sans un traçage complet, les décisions d'allocation des ressources sont basées sur des habitudes plutôt que sur des données, ce qui peut entraîner une utilisation inefficace de ressources GPU coûteuses ou d'API cloud.

La gestion du stockage est une autre préoccupation pratique pour les services auto-hébergés. Les journaux de diagnostic sont utiles pour dépanner les performances de la base de données, mais ils peuvent rapidement submerger les déploiements à petite échelle. Lorsque les journaux internes consomment des milliers de fois plus d'espace que les données réelles de l'application, ils dégradent les performances du disque et augmentent les temps de sauvegarde. Pour les opérateurs gérant des homelabs ou de petits clusters de serveurs, une croissance non contrôlée des journaux peut causer des interruptions de service ou nécessiter des nettoyages manuels fréquents. Configurer la base de données pour ne conserver que les données opérationnelles pertinentes garantit que la plateforme d'observabilité reste légère et durable.

Que pouvez-vous faire

• Comparez le nombre de requêtes enregistrées dans vos journaux d'application avec le nombre de traces dans votre plateforme d'observabilité pour identifier les lacunes de couverture.
• Vérifiez que les clés API et les plugins de traçage sont configurés pour chaque profil d'agent, worker et service, et pas seulement pour celui par défaut.
• Envoyez une requête de test depuis chaque profil d'agent distinct et confirmez qu'une trace taguée apparaît dans le tableau de bord.
• Inspectez les tables système de ClickHouse pour déterminer si les journaux de diagnostic consomment une part disproportionnée de l'espace disque par rapport à vos données.
• Appliquez un fichier de configuration personnalisé pour désactiver les journaux système inutiles de ClickHouse et définir des périodes de rétention appropriées pour les journaux de requêtes.
• Planifiez des audits réguliers des configurations de traçage, surtout après des changements d'infrastructure tels que des mises à jour d'adresses de serveur ou des rotations de credentials.