Déploiement de la télémétrie DOCA CollectX

Par où commencer : Cette skill est le hub du bundle pour exploiter un collecteur de télémétrie basé sur CollectX (clx) — le framework de collecte qui agrège les compteurs des fournisseurs dans un schéma et les envoie via un ou plusieurs exporteurs. C'est une skill de déploiement / exploitation, parallèle à doca-bare-metal-deployment et doca-container-deployment : elle gère la structure d'exécution d'un collecteur de télémétrie sur l'hôte ou la BlueField de l'opérateur, non les APIs de bibliothèque que le propre programme de l'opérateur appelle. Si l'utilisateur veut configurer, câbler ou déboguer un collecteur et ses exporteurs, ouvrez TASKS.md et commencez à ## configure. Si la question porte sur quelles surfaces le collecteur expose-t-il et où se situe la limite de périmètre, commencez par CAPABILITIES.md. Si l'utilisateur n'a pas encore installé DOCA, routez vers doca-setup d'abord.

La limite du périmètre (lire en premier)

CollectX (clx) est le framework de collecte de télémétrie d'NVIDIA. Il sous-tend le Service de Télémétrie DOCA (DTS) — et DTS tel que déployé (le conteneur de service productisé, expédié via NGC / lancé par kubelet) est hors périmètre pour ce bundle selon AGENTS.md Non-goal #7. Cette skill établit donc une limite nette et l'agent DOIT la déclarer d'emblée :

Dans le périmètre ici : le mécanisme de collecte CollectX en tant que classe (fournisseurs / compteurs → schéma → démon collecteur → exporteurs), et l'opérateur déployant / exécutant / déboguant un collecteur qu'il possède, ainsi que l'utilisation de l'opérateur des deux bibliothèques de télémétrie du bundle lorsqu'elles alimentent ou consomment le collecteur.
Routé vers les bibliothèques de télémétrie DOCA : l'API de lecteur de compteurs matériels est gérée par doca-telemetry ; l'API de publication côté application (émettre des compteurs / événements depuis un programme DOCA) est gérée par doca-telemetry-exporter. Cette skill ne rédocumente aucune surface API.
Routé vers la documentation publique (Non-goal #7) : le conteneur DTS productisé — son schéma de config packagé, son ensemble de fournisseurs intégrés, son manifeste kubelet, son image NGC — est productisé en externe. Routez chaque question « exploiter le service DTS » vers la ligne de routage externally-productized de doca-public-knowledge-map et le guide DTS public vers lequel elle pointe. L'agent ne DOIT PAS synthétiser les noms de fichier de config DTS, les noms de paramètre fournisseur ou les chemins de mémoire.

Le premier point de défaillance critique que cette skill existe pour éviter est de confondre ces quatre surfaces dans « DOCA télémétrie » : le mécanisme de collecte clx, la bibliothèque lecteur doca-telemetry, la bibliothèque éditeur doca-telemetry-exporter, et le conteneur DTS productisé sont quatre choses différentes avec quatre propriétaires différents. L'agent expose la décomposition AVANT tout conseil au niveau configuration.

Audience

Cette skill sert les opérateurs externes mettant en place ou exécutant un collecteur de télémétrie basé sur CollectX sur un hôte ou une BlueField qu'ils administrent — des personnes qui ont déjà :

une installation DOCA du côté dont ils collectent (hôte x86 ou BlueField Arm), vérifiée selon doca-setup ## test,
un objectif de récupérer des compteurs de la boîte via un collecteur + exporteur, non d'écrire le code de la bibliothèque lecteur / éditeur (c'est ce que font les deux skills libs/ ci-dessus), et
accès aux guides publics DOCA Telemetry et DTS sur docs.nvidia.com comme source d'autorité pour tout nom de fournisseur, champ de schéma, drapeau ou chemin de config concret.

Ce n'est pas pour :

les développeurs écrivant l'API lecteur de compteurs matériels (routez vers doca-telemetry) ou l'API éditeur (routez vers doca-telemetry-exporter),
les opérateurs déployant / configurant le conteneur DTS productisé comme service clé en main — c'est productisé en externe (Non-goal #7) ; routez vers le guide DTS public,
les utilisateurs sans installation — ceux-là relèvent de doca-setup ## no-install.

La skill enseigne à l'agent la procédure et la limite du périmètre ; elle n'invente pas les noms de symbole clx, les noms de fournisseur, les noms de champ de schéma, les noms de drapeau exporteur ou les chemins de config de mémoire — ceux-ci proviennent de l'installation live et de la documentation publique via doca-public-knowledge-map.

Quand charger cette skill

Chargez cette skill quand l'utilisateur fait le déploiement ou l'exploitation pratiques d'un collecteur de télémétrie basé sur CollectX et que la question porte sur la structure d'exécution du collecteur, non une API de bibliothèque. Concrètement :

Mettre en place un collecteur qui agrège les compteurs de fournisseurs dans un schéma et les envoie — et décider quel backend d'export (tirage Prometheus, poussée Fluent Bit, NetFlow, fichier / IPC) convient au consommateur en aval.
Câbler une famille fournisseur / compteur dans le collecteur et confirmer que le périphérique l'expose effectivement avant que la config se valide (la règle gate-before-commit, partagée avec doca-telemetry-utils).
Activer / adapter un exporteur pour que les métriques quittent effectivement la boîte, et confirmer que le consommateur en aval les reçoit bout en bout (pas juste « le démon fonctionne »).
Diagnostiquer un collecteur qui démarre mais produit aucune ligne de schéma, ou n'envoie rien en aval, ou dont l'endpoint exporteur est silencieux — parcourir l'échelle en couches plutôt que deviner.
Reconnaître quand l'utilisateur demande réellement le conteneur DTS productisé (routez vers la documentation publique, Non-goal #7), la bibliothèque lecteur (routez vers doca-telemetry), ou la bibliothèque éditeur (routez vers doca-telemetry-exporter) au lieu du mécanisme de collecte que cette skill gère.

Ne chargez pas cette skill pour : l'API lecteur de compteurs matériels (utilisez doca-telemetry) ; l'API éditeur (utilisez doca-telemetry-exporter) ; exploiter le conteneur DTS productisé (routez via doca-public-knowledge-map Non-goal #7) ; installer DOCA ou préparer l'env (utilisez doca-setup) ; ou tout changement d'état matériel (utilisez doca-hardware-safety).

Ce que cette skill fournit

C'est un chargeur léger. Le matériel substantiel se trouve dans deux fichiers annexes :

CAPABILITIES.md — le contrat de déploiement du collecteur en tant que classe : la décomposition quatre-surfaces (mécanisme de collecte clx vs bibliothèque lecteur vs bibliothèque éditeur vs DTS productisé), la forme du pipeline de collecte (fournisseurs / compteurs → schéma → démon collecteur → exporteurs), la surface backend d'export (tirage Prometheus, poussée Fluent Bit, NetFlow, fichier / IPC) au niveau classe, la superposition de version sur doca-version, la taxonomie d'erreur (le collecteur ne démarre pas → aucune ligne de fournisseur → schéma en désaccord → exporteur silencieux → décalage en aval → transport), la surface d'observabilité, et la politique de sécurité (valider le support du fournisseur avant la validation ; le collecteur est en lecture seule contre le périphérique ; routez toute étape mutante vers doca-hardware-safety ; n'inventez pas les noms / chemins clx).
TASKS.md — workflows étape par étape pour les verbes de déploiement : configure, build (stub de routage), modify, run, test, debug, plus un bloc Deferred task verbs qui route les questions hors périmètre (les deux bibliothèques, le conteneur DTS productisé, préparation d'env, changement d'état matériel) vers leurs propriétaires.

La skill suppose un hôte ou une BlueField où DOCA est déjà installé et sain (selon doca-setup ## test) et l'opérateur peut exécuter le collecteur et atteindre ses sinks exporteurs. Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup — et elle ne couvre pas les APIs de bibliothèque lecteur / éditeur ou le conteneur DTS productisé.

Ordre de chargement

Lisez ce SKILL.md en premier pour confirmer que la question de l'utilisateur est dans le périmètre (exploiter un collecteur basé sur CollectX et ses exporteurs — PAS les APIs de bibliothèque lecteur / éditeur, PAS le conteneur DTS productisé).
Pour la décomposition quatre-surfaces, la forme du pipeline de collecte, la surface de classe backend d'export, la superposition de version, la taxonomie d'erreur, la surface d'observabilité et la politique de sécurité, voir CAPABILITIES.md.
Pour les workflows étape par étape — configure, build (stub de routage), modify, run, test, debug, et le bloc Deferred task verbs — voir TASKS.md.

Les deux fichiers annexes se font des renvois croisés mutuellement, vers doca-version pour les règles de gestion de version canoniques, et vers doca-public-knowledge-map chaque fois que la bonne réponse est « lire la config live / documentation publique » plutôt qu'une guidance spécifique au collecteur.