dcgm-exporter is dead and NVML answers N/A

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

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՝ սկզբնաղբյուր զեկույցը
• Սերվինգի բաղադրատոմսը, որին կոլեկտորը պատկանում է
• Ամբողջական հոդվածը՝ պարսինգի մանրամասներով, Habr-ում, ռուսերեն