# dcgm-exporter is dead and NVML answers N/A

> GB10-ի unified memory-ի վրա dcgm-exporter-ը չի գործում, իսկ NVML-ը N/A է վերադարձնում շատ դաշտերի համար, որոնց վրա օպերատորներն ալերտ են դնում. մենք nvidia-smi-ի ելքը systemd timer-ով պարսում ենք node-exporter-ի textfile collector-ի համար՝ հնացման ալերտով հենց կոլեկտորի վրա։

- Platform: DGX Spark (GB10)
- Runtime: dcgm-exporter / NVML
- Published: 2026-09-02
- Sources: https://agmind.ai/hy/reports/dgx-spark-gpu-monitoring/
- Canonical: https://agmind.ai/hy/symptoms/dcgm-exporter-dead-nvml-na-gb10/

## Ինչ եք տեսնում

vLLM-ը սպասարկում է, Grafana-ի դաշբորդը հավաքված է ճիշտ այնպես, ինչպես
ամեն CUDA տուփի վրա, և դաշբորդը կանաչ է։ Պանելներում կա՛մ տվյալ չկա, կա՛մ
գծիկներ են, և ոչ մի տեղ չի ասվում, թե ինչու։ `nvidia-smi`-ն և NVML-ի վրա
հենված Python սնիպետները վերադարձնում են

```
N/A
```

շատ դաշտերի համար, որոնց վրա օպերատորներն ալերտ են դնում, առաջին հերթին՝
հիշողության թվերի։ Exporter-ն աշխատում է։ Պարզապես դրա հետևում ոչինչ
չկա։

## Որտեղ ենք հանդիպել

DGX Spark, մեր լաբորատորիայի GB10 սարքերը, vLLM-ով սերվինգ՝ մեր
bring-up-ի պահին արդի firmware-ով և դրայվերային ստեկով։ Զեկույցը
թվագրված է 2026-08-16 և չի նշում ո՛չ դրայվերի, ո՛չ firmware-ի, ո՛չ
exporter-ի տարբերակը. այս քարտն էլ չի նշում։ Տուփն աշխատում էր
«Ապացույցներ» բաժնում հղված սերվինգի բաղադրատոմսով։

## Պատճառ

Unified memory։ GB10-ն առանձին VRAM պուլ չունի, իսկ NVML-ի տրամադրած
հաշվիչները կառուցվել են այն ենթադրությամբ, որ այդպիսին կա, ուստի պուլ
սպասող գործիքակազմը ոչինչ չի հաղորդում։ dcgm-exporter-ը Spark-ի
unified-memory դիզայնի վրա նույնպես չի գործում. զեկույցը դա գրանցում է
որպես առանձին խափանում և մեխանիզմ չի տալիս։ Աղմուկով չի էլ ընկնում.
աշխատում է, իսկ դրա հետևի դաշբորդը դատարկ է մնում։

Երկու խափանումներն իրար են թաքցնում։ Exporter-ը լուռ է, ուստի ստուգում
եք գրադարանը. գրադարանը N/A է պատասխանում, ուստի ենթադրում եք, որ
exporter-ն էլ նույնը կաներ, և դադարում եք խորանալ։ Բացակայող մետրիկան ոչ
մեկին չի արթնացնում։

## Լուծում

Սա շրջանցող լուծում է. ստանդարտ ստեկը մնում է կոտրված, և մենք շրջանցում
ենք այն։ Spark-ի վրա `nvidia-smi`-ի սովորական տեքստային ելքն ավելի ազնիվ
է, քան դրա տակի գրադարանները։ Դաշտերը, որոնք պատասխանում են,
պատասխանում են իրական արժեքներով։ Կոլեկտորը, որ մենք աշխատեցնում ենք.

1. systemd timer-ը կարճ ինտերվալով գործարկում է `nvidia-smi`-ն։
2. Փոքր սկրիպտը պարսում է միայն այն դաշտերը, որոնք GB10-ի վրա իրոք
   պատասխանում են, և գրում դրանք որպես Prometheus մետրիկաներ `.prom` ֆայլի
   մեջ։
3. node-exporter-ի textfile collector-ը ֆայլը վերցնում է հոսթի մնացած
   մետրիկաների հետ միասին։
4. Մեկ լրացուցիչ մետրիկա կրում է կոլեկտորի սեփական վերջին գործարկման
   timestamp-ը, և ալերտը գործում է, երբ այն հնանում է։

Ոչ մի դեմոն այն ամենից բացի, ինչ հոսթն արդեն աշխատեցնում է, ոչ մի
արտոնյալ sidecar։ Դաշբորդի ամեն մետրիկայի համար մարդ է ստուգել, որ այն
այս սարքաշարի վրա պատասխանում է։ Այս կայքի զեկույցը սխեման է տալիս.
պարսինգի մանրամասները «Ապացույցներ» բաժնում հղված Habr-ի հոդվածում են։

Spark-ի վրա որևէ պանելի վստահելուց առաջ երկու ստուգում. այս դաշտն այս տուփի
վրա պատասխանո՞ւմ է, և ե՞րբ է կոլեկտորը վերջին անգամ գործարկվել։

## Բա՞ց է դեռ upstream-ում

Մենք դրան չենք հետևում։ Զեկույցը նշում է միայն, որ մոնիտորինգի վարքը
կարող է փոխվել դրայվերների թողարկումների հետ, և որ կոլեկտորն այդպիսի
փոփոխություններին ավելի լավ է դիմանում, քան գրադարանային binding-ները։
Այստեղ ոչինչ չի վերաբերում տվյալների կենտրոնի Blackwell-ին, որտեղ
dcgm-exporter-ը ճիշտ պատասխանն է։

## Ապացույցներ

- [GPU մոնիտորինգ DGX Spark-ի վրա. երբ dcgm-exporter-ը մեռած է, իսկ NVML-ը պատասխանում է N/A](https://agmind.ai/hy/reports/dgx-spark-gpu-monitoring/)՝ սկզբնաղբյուր զեկույցը
- [Սերվինգի բաղադրատոմսը, որին կոլեկտորը պատկանում է](https://agmind.ai/hy/reports/deepseek-v4-flash-0731-dgx-spark-recipe/)
- [Ամբողջական հոդվածը՝ պարսինգի մանրամասներով, Habr-ում, ռուսերեն](https://habr.com/ru/articles/1030802/)

---

Machine-readable claim registry: https://agmind.ai/claims.json · llms.txt: https://agmind.ai/llms.txt