Télémétrie DOCA

Par où commencer : Cette compétence suppose que DOCA est déjà installé et que l'utilisateur effectue un travail pratique de lecteur de compteurs matériels — ouverture d'un contexte doca_telemetry_<domain> par domaine sur un doca_dev et lecture du dernier snapshot de compteur matériel pour ce domaine. La bibliothèque est la moitié lecteur de compteurs de la télémétrie DOCA ; ce n'est PAS un collecteur NetFlow / IPFIX et ce n'est PAS un consommateur d'événements de schéma générique (le bundle l'avait précédemment présenté ainsi et ce cadrage était faux — il n'y a pas de surface de transport NetFlow / IPFIX / socket local dans l'en-tête public). Ouvrez TASKS.md si l'utilisateur veut faire quelque chose (configurer / compiler / modifier / exécuter / tester / déboguer) ; ouvrez CAPABILITIES.md quand la question porte sur quels domaines de compteurs matériels cet appareil peut-il lire sur cette installation (PCC, DPA, DIAG, ADP_RETX, PHY, PCI). Si l'utilisateur n'a pas encore installé DOCA, orientez-le vers doca-setup en premier. Si l'utilisateur hésite entre cette bibliothèque (lecteur de compteurs matériels sur un doca_dev) et doca-telemetry-exporter (le côté éditeur / exportation, qui est une bibliothèque séparée et publie de la télémétrie structurée / des métriques étiquetées / des logs OTLP), lisez la répartition des rôles lecteur/exportateur dans CAPABILITIES.md ## Capabilities and modes AVANT de configurer quoi que ce soit ; mélanger les deux est l'échec porteur de la première application pour cette compétence. Si l'utilisateur pose des questions sur le DOCA Telemetry Service (DTS) tel que déployé, orientez-le vers doca-public-knowledge-map — DTS est hors de portée pour ce bundle.

Audience

Cette compétence sert les développeurs externes construisant des applications qui LISENT les compteurs matériels DOCA à partir d'un doca_dev au travers d'une ou plusieurs des six bibliothèques lecteur DOCA Telemetry par domaine (doca_telemetry_pcc / _dpa / _diag / _adp_retx / _phy / _pci) — c'est-à-dire les utilisateurs dont le code d'application appelle doca_telemetry_<domain>_* (directement en C/C++, ou via FFI / bindings d'un autre langage) pour ouvrir un contexte par domaine sur un doca_dev, configurer la fenêtre d'échantillonnage par domaine, et lire le snapshot de compteur matériel pour ce domaine. Ce n'est pas pour les développeurs NVIDIA contribuant à DOCA Telemetry lui-même, et ce n'est pas pour les utilisateurs écrivant le côté publication / exportation — c'est doca-telemetry-exporter, une bibliothèque séparée et une compétence séparée.

Périmètre linguistique. Les bibliothèques lecteur DOCA Telemetry par domaine sont livrées comme une surface C avec le nom de module pkg-config doca-telemetry. Les exemples livrés sont écrits en C. Les lecteurs C et C++ sont le cas canonique ; les exemples travaillés dans TASKS.md supposent ce chemin. Les lecteurs dans d'autres langages (Rust, Go, Python, …) consomment le même *.so via FFI ou bindings spécifiques au langage ; la contribution de la compétence dans ce cas est de maintenir la distinction lecteur/exportateur, la discipline de requête de cap par domaine en premier, le cycle de vie DOCA Core par domaine sur le doca_dev, la discipline de fenêtre d'échantillonnage, et la guidance de taxonomie d'erreur agnostique du langage, et d'orienter l'agent vers la surface C ABI publique par domaine comme la surface faisant autorité que tout wrapper appellera finalement.

Quand charger cette compétence

Chargez cette compétence quand l'utilisateur effectue du travail lecteur de compteurs matériels DOCA Telemetry pratique, dans n'importe quel langage. Concrètement :

• Choisir le bon en-tête par domaine pour les compteurs souhaités (doca_telemetry_pcc.h pour les compteurs Programmable Congestion Control, _dpa.h pour les compteurs DPA, _diag.h pour les compteurs de diagnostic générique d'appareil, _adp_retx.h pour les compteurs de retransmission ADP, _phy.h pour les compteurs de couche physique, _pci.h pour les compteurs PCI / PCIe) et confirmer que l'appareil le supporte via la requête _cap_is_supported(devinfo) par domaine — sauf _pci, qui n'a pas de _cap_is_supported unique et expose plutôt des caps par fonctionnalité comme doca_telemetry_pci_cap_management_info_is_supported / _cap_perf_counters_1_is_supported.
• Ouverture d'un contexte doca_telemetry_<domain> par domaine sur un doca_dev, parcours du cycle de vie par domaine (doca_telemetry_<domain>_create(dev) → setters par domaine → doca_telemetry_<domain>_start), configuration de la fenêtre d'échantillonnage par domaine, et lecture du snapshot de compteur matériel pour ce domaine. Notez que c'est une surface _create/_start par domaine, pas le cycle de vie du moteur de progression générique doca_ctx_*.
• Lecture de la surface de capacité appareil + bibliothèque pour le lecteur par domaine via la requête doca_telemetry_<domain>_cap_is_supported avant de supposer qu'une famille de compteurs particulière est disponible sur cette installation / ce doca_dev.
• Gestion des retours DOCA_ERROR_* par domaine à partir d'une lecture de compteur (cycle de vie vs. appareil ne supporte pas ce domaine vs. AGAIN par domaine signifie snapshot pas prêt vs. permission / pilote) et le statut par lecture rapporté à l'application.
• Choix entre DOCA Telemetry (lecteur de compteurs matériels) et une option adjacente : doca-telemetry-exporter quand l'utilisateur veut réellement PUBLIER / EXPORTER les valeurs de compteur (OTLP / Prometheus / métriques étiquetées) ; doca-log quand la journalisation structurée simple en stdout suffit ; une bibliothèque client Prometheus / OpenTelemetry générique quand la source de compteur est un programme non-DOCA ; le DOCA Telemetry Service externalisé (DTS, hors de portée) quand l'utilisateur veut un agrégateur clé en main.
• Conception ou extension de bindings non-C (Rust, Go, Python, …) qui enveloppent l'ABI C lecteur par domaine — pour la distinction lecteur/exportateur, la règle de requête de cap par domaine en premier, le cycle de vie doca_dev par domaine, la discipline de fenêtre d'échantillonnage, et les règles d'erreur que le wrapper doit respecter.

N'CHARGEZ PAS cette compétence pour l'orientation générale DOCA, l'installation de DOCA lui-même, le côté publication / exportation (doca-telemetry-exporter a sa propre compétence), le DOCA Telemetry Service externalisé (DTS — hors de portée), ou les questions de bibliothèque non-lecteur. Pour ceux-ci, utilisez doca-public-knowledge-map.

Ce que cette compétence fournit

C'est un chargeur minimaliste. Le corps conserve seulement l'orientation nécessaire pour choisir le prochain fichier approprié. La matière substantielle lecteur de compteurs matériels réside dans deux fichiers compagnons :

• CAPABILITIES.md — ce que les lecteurs par domaine peuvent exprimer sur cette installation : la règle de répartition des rôles lecteur/exportateur, les six sous-bibliothèques livrées (doca_telemetry_pcc / _dpa / _diag / _adp_retx / _phy / _pci) et quelle famille de compteurs chacune expose, le cycle de vie DOCA Core par domaine sur un doca_dev, la requête de capacité par domaine (doca_telemetry_<domain>_cap_is_supported(devinfo)), la taxonomie d'erreur lecteur (mappée sur l'ensemble cross-bibliothèque DOCA_ERROR_*, avec la règle NOT_SUPPORTED signifie domaine non exposé sur cet appareil et la règle AGAIN signifie snapshot pas prêt explicitement appelées), la surface d'observabilité (statut par lecture + snapshot de requête de cap par domaine au moment de la configuration), la politique de sécurité qui ferme les lectures par domaine derrière le résultat de la requête de cap, et la règle de sélection de chemin contre doca-telemetry-exporter, doca-log, et Prometheus / OpenTelemetry / DTS autonomes.
• TASKS.md — workflows étape par étape pour les six verbes lecteur dans le périmètre : configure, build, modify, run, test, debug. Plus un bloc Deferred task verbs qui oriente les questions hors de portée vers la compétence suivante appropriée.

La compétence suppose un hôte où DOCA est déjà installé à l'emplacement standard et un doca_dev est ouvert contre un DPU BlueField ou une NIC ConnectX que la requête de cap par domaine retourne DOCA_SUCCESS pour. Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup — et elle ne couvre pas l'écriture du côté publication / exportation, qui est doca-telemetry-exporter.

Ordre de chargement

1. Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est dans le périmètre (spécifiquement, que l'utilisateur veut LIRE un compteur matériel par domaine via l'API lecteur par domaine sur un doca_dev — pas PUBLIER des compteurs, qui est doca-telemetry-exporter ; pas déployer DTS, qui est hors de portée ; et pas mettre en place un collecteur NetFlow / IPFIX, que cette bibliothèque n'expose pas une surface pour).
2. Pour la règle lecteur/exportateur, les six sous-bibliothèques par domaine, le cycle de vie DOCA Core par domaine sur un doca_dev, la requête de capacité par domaine, la taxonomie d'erreur (y compris la règle NOT_SUPPORTED signifie domaine non exposé sur cet appareil et la règle AGAIN signifie snapshot pas prêt), l'observabilité, la politique de sécurité, et la règle de sélection de chemin, voir CAPABILITIES.md.
3. Pour les workflows étape par étape — configure, build, modify, run, test, debug — voir TASKS.md.

Les deux fichiers compagnons se font des références croisées l'un l'autre, doca-version pour les règles canoniques de gestion de version, et doca-public-knowledge-map chaque fois que la bonne réponse est « cherchez-le dans les docs publiques ou la disposition du package installé » plutôt que « guidance spécifique au lecteur ».

Exemples de questions auxquelles cette compétence répond bien

Voir references/details.md.

Ce que cette compétence ne livre délibérément pas

Voir references/details.md.

Compétences connexes

Voir references/details.md.