Monitorovací zásobník: Prometheus, Grafana, DCGM, Loki pre servery s umelou inteligenciou

Server s umelou inteligenciou, ktorý nikto nesleduje, je server, ktorý potichu obmedzuje výkon, uniká mu VRAM, hromadí chyby ECC alebo je OOM ukončený o 03:00 – a vy to zistíte o tri dni neskôr, keď sa niekto opýta, prečo jeho jemné doladenie spôsobilo odpad. Väčšina najhorších poruchových režimov na GPU je z aplikácie neviditeľná: tepelný throttle sa nezaznamenáva do stderr, korekcie ECC okamžite nič nezlyhajú, OOM killer zje proces a orchestrátor ho čisto reštartuje. Bez metrík na samotnom hardvéri nič z toho neuvidíte, kým to nestálo týždeň.

Štandardná sada nástrojov pre správcu systému (htop, df, uptime, syslog) to nepokrýva. GPU je najdrahší a najnáchylnejší komponent v šasi a má svoj vlastný telemetrický zásobník, ktorý vyžaduje explicitné nastavenie. Tento článok je názorovou zostavou pre tento zásobník – Prometheus, Grafana, DCGM-exporter, node_exporter, Loki a Alertmanager – zabalený ako jedno nasadenie docker-compose, ktoré prevádzkujeme na každom serveri Kentino AI, ktorý dodávame.

Publikum je niekto, kto stojí pred 4- alebo 8-GPU serverom s umelou inteligenciou, vie napísať súbor docker-compose a chce odpoveď na otázku „čo by som mal vlastne monitorovať a pri akej hranici by som mal spustiť alarm“.

Štandardný zásobník v roku 2026

Päť komponentov robí takmer všetku prácu. Všetko ostatné sa dá pripevniť skrutkami.

Celkovo výrazne menej ako 0.5 % jedného jadra CPU na 96-jadrovom EPYC a približne 700 MB RAM. Na serveri s 256 GB / 8 GPU ide o chybu zaokrúhľovania. Argument „monitorovanie kradne cykly z tréningu“ prestal byť pravdivý okolo roku 2019.

Jedno architektonické rozhodnutie, ktoré sa oplatí urobiť vopred: spúšťať zásobník na samostatnom virtuálnom počítači pre správu alebo na malom zariadení, nie na samotnom GPU serveri. Vyhradený mini-PC, NUC, servisný uzol EPYC alebo virtuálny počítač na hypervízore laboratória – čokoľvek, čo nie je GPU server. Dva dôvody: keď sa GPU server zrúti (panika jadra kvôli nedostatku pamäte, porucha zdroja, tepelné vypnutie), stále chcete, aby história metrík diagnostikovala, čo sa stalo, a nechcete, aby nekontrolovateľná trénovacia úloha súťažila s Prometheusom o pamäť a spúšťala vlastné upozornenie. DCGM-exporter a node_exporter bežia na hostiteľskom GPU (musia – čítajú lokálne zariadenia); Prometheus, Grafana, Loki a Alertmanager bežia na virtuálnom počítači pre správu a scrapingujú dovnútra.

DCGM-exporter – jedna vec, ktorú nemôžete vynechať

Správca dátových grafických procesorov (DCGM) od spoločnosti NVIDIA je podporovaný a autoritatívny zdroj telemetrie grafických procesorov. dcgm-exporter Kontajner sprístupňuje metriky DCGM vo formáte Prometheus na porte 9400. Je to najdôležitejší komponent v zásobníku a je to tá vec. nvidia-smi prieskumy nikdy nenahradia.

Inštalácia cez kontajner NGC (nvcr.io/nvidia/k8s/dcgm-exporter, aktuálne 4.x (od polovice roka 2026) alebo upstreamový Helm graf pre Kubernetes. Na holom Dockeri jeden docker run --gpus all --rm stačí; démon potom zverejní ~80 metrík na :9400/metricsTie, na ktorých skutočne záleží, zoradené podľa toho, ako často zachytávajú skutočné problémy:

Počítadlá škrtiacej klapky sú hlavnou funkciou. DCGM_FI_DEV_THERMAL_VIOLATION je monotónne počítadlo nanosekúnd, ktoré GPU strávilo škrtením. Vypočítajte jeho rýchlosť počas 5-minútového okna a získate presnú odpoveď na otázku „je môj server momentálne tepelne obmedzený“. Bez neho by ste hádali len na základe teploty, čo klame – 4090 sa pri trvalom zaťažení zahreje na 83 °C bez ohľadu na to, čo ukazuje teplotný panel.

Dve známe zvláštnosti vývozcov DCGM, ktoré sa oplatí poznať v roku 2026: niektoré kódy XID (najmä XID 62) sa nie vždy objavia prostredníctvom DCGM_FI_DEV_XID_ERRORSa metrika je mierkou posledný XID videný – takže po obnovení sa môže nepodariť resetovať bez reštartovania exportéra. Zmiernením problému je Tiež sledujte vyrovnávaciu pamäť jadra cez Loki pre doslovný význam NVRM: Xid šnúrka (viac o tom nižšie). Opasok a traky.

V prípade čisto spotrebiteľských kariet (RTX 4090, 5090) sú niektoré funkcie dátového centra DCGM čiastočné – chýba MIG, na spotrebiteľských komponentoch Blackwell chýba NVLink, niektoré počítadlá ECC vracajú nulu. DCGM stále funguje a hlási, čo je vystavené; ľahká komunitná alternatíva nvidia_gpu_exporter (ktorý škriabe nvidia-smi) je schodnou záložnou možnosťou, ak nechcete reťaz závislostí DCGM. Pre Pro 6000 Blackwell, L40 a L4 – čokoľvek v rade pre dátové centrá/pro – použite DCGM, nie wrapper.

node_exporter — systémová polovica

Metriky GPU hovoria len polovicu príbehu. node_exporter pokrýva zvyšok:

Zlyhanie „systémová RAM vyčerpaná, OOM killer preberá vLLM, kontajner sa reštartuje bez problémov“ je zachytené tu, nie DCGM. Sledujte node_memory_MemAvailable_bytes a spustí alarm, keď klesne pod 5 % z celkového počtu. V Linuxe sa killer štandardne spustí pri hodnote okolo 0 %, ale vtedy je váš proces mŕtvy.

Prometheus — konfigurácia, uchovávanie, dimenzovanie

Prometheus je databáza časových radov a orchestrátor scrape. Predvolené nastavenia sú rozumné; dve nastavenia, ktoré sa oplatí zmeniť hneď na začiatku, sú interval scrape a uchovávanie.

15-sekundový interval zoškrabávania je správnym východiskovým bodom pre server s umelou inteligenciou: dostatočne rýchly na zachytenie tepelného skoku predtým, ako sa stane trvalým škrtením, a dostatočne pomalý na to, aby náklady na časové rady zostali nízke. Predvolená doba udržania je 15 dní; 30 dní je lepšie číslo pre kontext sprievodcu zostavením, kde môžete porovnať dnešné správanie so zmenou ladenia z minulého mesiaca.

Rozpočet úložiska pri scrape 15 s, ~80 metrík DCGM × N GPU + ~400 metrík node_exporter + ~50 metrík vLLM: zhruba 1.5 – 2 GB týždenne, takže 30 dní pripadá na 6 – 10 GB na 8-GPU serveri. Ako obmedzenie nastavte uchovávanie podľa času aj podľa veľkosti:

command:
  - "--storage.tsdb.retention.time=30d"
  - "--storage.tsdb.retention.size=20GB"

Ktorýkoľvek limit spustí zhutnenie; vyhráva ten, ktorý je dosiahnutý skôr. Alokácia 100 GB vám poskytuje viac ako rok priestoru bez premýšľania.

Dashboardy Grafana – začnite s predpripravenými

Nevytvárajte dashboardy od nuly. Komunita to už urobila.

Najprv importujte 12239 a 1860. Pokrývajú ~90 % toho, čo si skutočne chcete pozrieť, a boli v priebehu rokov vylepšované. Svoje vlastné si zostavte až po mesiaci, keď budete vedieť, ktoré panely skutočne otvoríte. Menšie úpravy, ktoré sa oplatí urobiť pre hardvér Kentino AI, sú: nastavenie prahových teplôt GPU panelov na rozsahy vhodné pre Blackwell (5090 throttle blízko 87 °C, RTX Pro 6000 bližšie k 90 °C) a pridanie panela pre každý slot PCIe zobrazujúceho DCGM_FI_DEV_PCIE_LINK_GEN a DCGM_FI_DEV_PCIE_LINK_WIDTH takže na prvý pohľad vidíte, či sa výška stúpačky znížila z x16 na x8.

Loki – záznamy, ktoré vysvetľujú, čo ukazujú metriky

Metriky vám povedia , čo sa zmenilo; protokoly vám povedia prečo . Loki je databáza protokolov Grafany; Promtail je odosielateľ, ktorý sleduje súbory a odosiela ich. Nasmerujte Promtail na:

• /var/log/syslog a journalctl -k — správy OOM jadra, sťažnosti na ovládače NVIDIA, výpisy XID
• /var/log/nvidia-installer.log — stav inštalácie ovládača
• štandardný výstup kontajnera vLLM (prostredníctvom ovládača protokolu Docker JSON)
• Protokoly aplikácií zo všetkého, čo zákazník spúšťa

Jediný dopyt s najvyššou hodnotou na karte Preskúmať v Grafane je:

{job="syslog"} |= "NVRM:"

Toto zobrazí každú správu ovládača NVIDIA vo vyrovnávacej pamäti jadra – chyby XID, poruchy ventilátora, udalosti výpadku zbernice, časové limity GSP RPC. Spárujte to s DCGM_FI_DEV_XID_ERRORS Upozornenie Prometheus a máte štruktúrovanú metriku aj neštruktúrované podrobnosti v jednom paneli.

Štandardne neodosielame protokoly mimo hostiteľa. Loki ich uchováva lokálne s 30-dňovou archiváciou; SSH tunely na požiadanie sa v prípade potreby prenášajú do Grafany. Zákazníci, ktorí chcú centralizované protokoly na viacerých serveroch, môžu Loki nasmerovať na S3 alebo spustiť regionálnu inštanciu – to je otázka nasadenia, nie architektúry.

Metriky vLLM a SGLang – nástroj na aplikáciu, nielen na kov

DCGM vám oznámi, že GPU je zaneprázdnený. Nepovie vám, či sa požiadavky na inferenciu vrátia o 200 ms alebo 2 s. Na to použijete obslužnú vrstvu.

vLLM odhaľuje /metrics natívne na rovnakom porte ako OpenAI API. S predvolenými nastaveniami je koncový bod na :8000/metrics publikuje metriky Prometheus s vllm: predpona (ktorá sa stáva vllm_ (po Prometheusovom škrabaní). Tie, ktoré sa oplatí zoškrabať:

Kombinácia vllm:num_requests_waiting > 0 a DCGM_FI_DEV_GPU_UTIL < 90% znamená, že front sa zálohuje, kým je GPU nečinný – zvyčajne ide o úzke hrdlo tokenizátora alebo plánovača, nie o problém s výpočtami. Toto vidíte iba pri oboch metrikách na tom istom dashboarde, čo je celý zmysel zjednotenia telemetrie aplikácií a hardvéru v jednom Prometheus.

NVIDIA NIM sprístupňuje rovnaké metriky vLLM pod /v1/metrics bez ich premenovania, takže vaše existujúce dashboardy vLLM a pravidlá upozornení sa prenesú do nasadenia obsluhovaného NIM bez zmeny. SGLang publikuje podobnú sadu na svojom vlastnom porte (predvolene 30000); HTTP server llama.cpp sprístupňuje menšiu podmnožinu. Triton publikuje vlastnú taxonómiu. Nech už poskytujete čokoľvek, scrapingujte aplikáciu – nielen hardvér.

Pravidlá Alertmanageru – tie, ktoré skutočne doručujeme

Ovládacie panely sú pekné. Upozornenia sú užitočné. Nižšie uvedené pravidlá sú tie, ktoré odhalili skutočné problémy na hardvéri skutočných zákazníkov.

groups:
  - name: gpu
    interval: 30s
    rules:
      - alert: GPUTempCritical
        expr: DCGM_FI_DEV_GPU_TEMP > 87
        for: 30s
        labels: { severity: critical }
        annotations:
          summary: "GPU {{ $labels.gpu }} thermal critical ({{ $value }} °C)"

      - alert: GPUThermalThrottling
        expr: rate(DCGM_FI_DEV_THERMAL_VIOLATION[5m]) > 0
        for: 1m
        labels: { severity: warning }

      - alert: GPUECCUncorrectable
        expr: increase(DCGM_FI_DEV_ECC_DBE_VOL_TOTAL[10m]) > 0
        labels: { severity: critical }
        annotations:
          summary: "GPU {{ $labels.gpu }} uncorrectable ECC — schedule replacement"

      - alert: GPUXIDError
        expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
        labels: { severity: critical }

      - alert: GPUPowerEnvelopeExceeded
        expr: DCGM_FI_DEV_POWER_USAGE > 590  # 5090 nominal 575 W; alarm above sustained ceiling
        for: 5m
        labels: { severity: warning }

      - alert: GPUIdleDuringWork
        expr: DCGM_FI_DEV_GPU_UTIL < 5 and DCGM_FI_DEV_FB_USED > 1024
        for: 10m
        labels: { severity: warning }
        annotations:
          summary: "GPU {{ $labels.gpu }} idle with VRAM allocated — likely hung"

  - name: system
    interval: 30s
    rules:
      - alert: HostMemoryLow
        expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.05
        for: 2m
        labels: { severity: critical }

      - alert: OOMKillerFired
        expr: increase(node_vmstat_oom_kill[5m]) > 0
        labels: { severity: critical }

      - alert: ContainerRestartLoop
        expr: rate(container_start_time_seconds[15m]) > 3
        for: 10m
        labels: { severity: warning }

  - name: serving
    interval: 30s
    rules:
      - alert: vLLMQueueBacklog
        expr: vllm:num_requests_waiting > 10
        for: 5m
        labels: { severity: warning }

      - alert: vLLMHighLatency
        expr: histogram_quantile(0.95, rate(vllm:e2e_request_latency_seconds_bucket[5m])) > 10
        for: 5m
        labels: { severity: warning }

Názorové rozhodnutia v týchto pravidlách:

• 87 °C je kritických pre teplotu GPU. 5090 sa na väčšine dosiek otáča okolo 80 °C. Ak vaša miestnosť nedokáže udržať kartu pod 80 °C pri trvalom zaťažení, máte problém s HVAC, nie so softvérom.
• Akékoľvek neopraviteľné ECC vyvoláva pohotovostný hovor. Jedna dvojbitová ECC udalosť zneplatní všetko, čo sa nachádzalo na danej stránke VRAM – trénovací krok je nesprávny, výsledok inferencie je nesprávny. Karta potrebuje výmenu, nie reštart.
• GPUIdleDuringWork je detektor deadlocku. > 1 GiB alokované a < 5% využitie počas 10 minút znamená, že niečo je zaseknuté. Zachytáva zamrznutia na strane CUDA, ktoré aplikácia s radosťou ignoruje.
• Pravidlo OOM killer alert je najčastejšie zanedbávané pravidlo v každom nasadení. Linux potichu zabíja vašu tréningovú úlohu a Docker ju čisto reštartuje the,en poruchový režim, ktorý ročne stráca najviac hodín inžinierskej práce. Urobte to hlasno.
• Slučka reštartu kontajnera zachytáva cykly reštartu NIM a vLLM ktoré zvonku vyzerajú zdravo (kontajner „beží“), ale v skutočnosti padajú pri každom načítaní modelu.

Šasi a úložisko – IPMI a SMART

DCGM sa zastaví pri GPU. node_exporter sa zastaví pri OS. Zvyšok šasi – ventilátory, zdroje, teplota okolia, stav úložiska – potrebuje ďalšie dva exportéry.

ipmi_exporter (prometheus-community) komunikuje s BMC cez IPMI/RMCP a zobrazuje telemetriu na úrovni šasi: otáčky ventilátora, vstupné napätie a prúd zdroja, položky v denníku systémových udalostí, vstupnú teplotu okolia, stav watchdog BMC. Na šasi Supermicro alebo Bone64c s funkčným BMC je to pol dňa práce a zachytí veci, ktoré DCGM doslova nevidí – chybný zdroj na duálnej 8-GPU zostave sa prejaví ako pokles napätia v údajoch senzora IPMI niekoľko minút predtým, ako GPU prejde na XID 79. Spustite ho na hostiteľovi (potrebuje /dev/ipmi0) alebo vzdialene s uloženými prihlasovacími údajmi BMC pomocou vzoru exportéra pre viacero cieľov.

smartctl_exporter (alebo starší smart_exporter) číta atribúty NVMe a SATA SMART: indikátor opotrebovania médií, dostupné náhradné médiá, teplota, počet chýb. Záťažové zaťaženie umelou inteligenciou je na NVMe brutálne – načítavače dátových súborov, zápisy kontrolných bodov a vyrovnávacie pamäte HuggingFace posúvajú ciele opotrebovania podnikov o mesiace na diskoch spotrebiteľskej triedy. Metrika, ktorá by mala alarmovať, je nvme_available_spare klesnú pod 20 % a nvme_percentage_used (indikátor opotrebenia) stúpa nad 80 %. Porucha disku je druhou najčastejšou hardvérovou poruchou na vyťaženom serveri s umelou inteligenciou po poruche rozširujúceho zdroja/napájacieho zdroja.

Kompletné nasadenie monitorovania Kentino s umelou inteligenciou zahŕňa oboje. Hraničné náklady sú minúty; hodnota pri prvom tichom výpadku ventilátora alebo dosiahnutí limitu DWPD procesorom Samsung 990 Pro sú hodiny.

Skutočný docker-compose pre virtuálny stroj mangmt

Čo v skutočnosti nasadíme na riadiacom zariadení. Úprava host.docker.internal (alebo použite názov hostiteľa/IP adresu GPU servera) na nasmerovanie Prometheusa na exportné porty GPU hostiteľa.

version: "3.8"

networks:
  monitoring: { driver: bridge }

volumes:
  prometheus_data:
  grafana_data:
  loki_data:

services:
  prometheus:
    image: prom/prometheus:v3.0.0
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./rules:/etc/prometheus/rules:ro
      - prometheus_data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.path=/prometheus"
      - "--storage.tsdb.retention.time=30d"
      - "--storage.tsdb.retention.size=20GB"
      - "--web.enable-lifecycle"
    ports: ["9090:9090"]
    networks: [monitoring]

  grafana:
    image: grafana/grafana:11.4.0
    restart: unless-stopped
    environment:
      - GF_SECURITY_ADMIN_PASSWORD__FILE=/run/secrets/grafana_pw
      - GF_USERS_ALLOW_SIGN_UP=false
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning:ro
    secrets: [grafana_pw]
    ports: ["3000:3000"]
    networks: [monitoring]

  alertmanager:
    image: prom/alertmanager:v0.28.0
    restart: unless-stopped
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
    ports: ["9093:9093"]
    networks: [monitoring]

  loki:
    image: grafana/loki:3.3.0
    restart: unless-stopped
    command: -config.file=/etc/loki/loki.yml
    volumes:
      - ./loki.yml:/etc/loki/loki.yml:ro
      - loki_data:/loki
    ports: ["3100:3100"]
    networks: [monitoring]

secrets:
  grafana_pw: { file: ./secrets/grafana_pw.txt }

Na samotnom hostiteľovi GPU (samostatné písanie správ na serveri GPU):

services:
  dcgm-exporter:
    image: nvcr.io/nvidia/k8s/dcgm-exporter:4.5.1-4.8.0-ubuntu22.04
    restart: unless-stopped
    runtime: nvidia
    environment: [NVIDIA_VISIBLE_DEVICES=all]
    cap_add: [SYS_ADMIN]
    ports: ["9400:9400"]

  node-exporter:
    image: prom/node-exporter:v1.9.0
    restart: unless-stopped
    pid: host
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - "--path.procfs=/host/proc"
      - "--path.sysfs=/host/sys"
      - "--path.rootfs=/rootfs"
    ports: ["9100:9100"]

  ipmi-exporter:
    image: prometheuscommunity/ipmi-exporter:v1.10.0
    restart: unless-stopped
    privileged: true
    volumes: ["/dev/ipmi0:/dev/ipmi0"]
    ports: ["9290:9290"]

  smartctl-exporter:
    image: prometheuscommunity/smartctl-exporter:v0.13.0
    restart: unless-stopped
    privileged: true
    ports: ["9633:9633"]

  promtail:
    image: grafana/promtail:3.3.0
    restart: unless-stopped
    volumes:
      - /var/log:/var/log:ro
      - ./promtail.yml:/etc/promtail/promtail.yml:ro
    command: -config.file=/etc/promtail/promtail.yml

Konfigurácia scrape Prometheus na virtuálnom počítači mgmt:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - /etc/prometheus/rules/*.yml

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: dcgm
    static_configs:
      - targets: ["k-ai-01.lan:9400", "k-ai-02.lan:9400"]

  - job_name: node
    static_configs:
      - targets: ["k-ai-01.lan:9100", "k-ai-02.lan:9100"]

  - job_name: ipmi
    static_configs:
      - targets: ["k-ai-01.lan:9290", "k-ai-02.lan:9290"]

  - job_name: smart
    static_configs:
      - targets: ["k-ai-01.lan:9633", "k-ai-02.lan:9633"]

  - job_name: vllm
    metrics_path: /metrics
    static_configs:
      - targets: ["k-ai-01.lan:8000"]

Toto je pracovný stack pre laboratórium s jedným až tromi servermi. Po štyroch alebo piatich serveroch prepnite konfiguráciu scrape od Prometheus na vyhľadávanie služieb na základe súborov alebo – ak používate Kubernetes – na pribalený Helm graf DCGM-exporter od GPU Operator a Prometheus Operator. ServiceMonitor CRD.

OpenTelemetry, Pixie, eBPF — obraz z roku 2026

Poznámka k pohyblivým častiam, pretože otázka sa vždy vynára.

OpenTelemetry je štandard CNCF pre inštrumentáciu pozorovateľnosti a od začiatku roka 2026 sú všetky tri typy signálov (metriky, trasy, protokoly) stabilné. Kanál OTel Collector nahrádza v mnohých organizáciách agentov špecifických pre dodávateľov ako univerzálny telemetrický router. Pre server s umelou inteligenciou je pragmatickou odpoveďou v roku 2026: ponechať Prometheus pre metriky (DCGM-exporter a node_exporter hovoria natívne Prometheus a vaše pravidlá upozornení sú v PromQL) a pridať OTel Collector, ak a keď potrebujete distribuované sledovanie v grafe slúžiacom inferencii (požiadavka → brána API → vLLM → volanie nástroja → vektorová databáza → odpoveď). Pri inštalácii na jednom serveri s jedným modelom za nginx OTel pridáva náklady bez hodnoty. 71 % organizácií, ktoré „používajú oba“, používa Prometheus pre kovy a OTel pre trasy aplikácií – rozumné rozdelenie.

škriatok je nástroj na sledovanie údajov natívny pre Kubernetes, ktorý používa eBPF na zhromažďovanie metrík, stôp a protokolov na úrovni jadra bez zmien kódu. Vývoj, ktorý sa oplatí sledovať v roku 2026, je práca na eBPF na GPU (bpftime, eGPU, otvorené moduly jadra od NVIDIA), ktoré rozširujú inštrumentáciu eBPF do jadier GPU prostredníctvom injekcie PTX za behu. Toto je dnes na výskumnej úrovni a nie je súčasťou žiadneho produkčného balíka, ktorý dodávame. Momentálne je podporovaným riešením DCGM.

Nepretržité profilovanie (Grafana Phlare, Pyroscope) je tretím doplnkom, o ktorom sa oplatí vedieť. Pri inferenčných úlohách, kde ovládate kód frameworku (vlastné záplaty vLLM, optimalizácie tokenizéra), vám hovorí, ktoré funkcie zaťažujú CPU. Pre čisté poskytovanie modelov so zásobovacími kontajnermi je to prehnané.

Čo sa pokazí (monitorovacie vydanie)

Predvídateľné režimy zlyhania samotného zásobníka, zoradené podľa toho, ako často sa zaseknú:

• Prometheov disk sa naplní. Predvolená doba uchovávania je 15 dní; nastavili sme 30 so stropom 20 GB. Po 60 dňoch na vyťaženom zariadení plánujte desiatky GB. Nastavte dobu uchovávania podľa času aj veľkosti.
• DCGM-exporter stráca grafické karty po aktualizácii ovládača. Príznak: všetky panely GPU sa zobrazia prázdne. Oprava: reštartujte kontajner; znova ho spustite nvidia-ctk runtime configure ak sa behové prostredie posunulo.
• Správca upozornení nie je nakonfigurovaný pre prijímač, ktorý skutočne používate. Ľudia sa postavia proti Prometheovi a Grafane, zabudnú ukázať Alertmanageru e-mail alebo Slack a o šesť mesiacov neskôr zistia, že sa žiadne upozornenie nikdy nespustilo. Otestujte to zámerným vypnutím. GPUTempCritical so stresovou pracovnou záťažou alebo použitie amtool alert add spustiť syntetický výstražný signál v prvý deň.
• Výbuch kardinality z označení na požiadanie. Neoznačujte metriky vLLM pomocou user_id or request_idPrometheus nie je na to určený – databázu budete OOM.
• Únik hesla Grafana cez prostredie na písanie. Používajte Docker tajné kódy, nie GF_SECURITY_ADMIN_PASSWORD v bloku prostredia. docker inspect a protokoly unikajú hodnotám prostredia.
• Ukazovateľ XID, ktorý sa neresetuje. Ako už bolo uvedené, ukazovateľ XID exportéra DCGM sa môže po zotavení zastaviť na poslednej hodnote. Skombinujte metriku s Lokiho... NVRM: syslog tail, aby sa predišlo falošnej dôvere.

Úprimný pohľad

Väčšina laboratórií nainštaluje Grafanu raz, vytvorí dashboard, ktorý tím obdivuje týždeň, a už sa naň nikdy nepozrie. Dashboard je uspokojivý artefakt; nie je to to, čo zachytáva vaše problémy. Upozornenia sú to, čo zachytáva vaše problémy. Nastavte si Alertmanager so skutočným prijímačom (e-mail, Slack, PagerDuty) a malou sadou vysoko presných pravidiel – teplota GPU, ECC double-bit, XID, OOM killer, slučka reštartu kontajnera – a ladte ich, kým sa nespúšťajú iba vtedy, keď je niečo skutočne zle. Urobte to ako prvé. Potom vytvorte dashboardy pre príbeh ladenia po incidente.

Druhá polovica úprimného pohľadu: v Kentino systéme s jedným serverom dostanete z tohto zásobníka upozornenie možno raz za mesiac a väčšinu mesiacov to bude falošne pozitívny výsledok, ktorý si ignorujete. Takto systém funguje. Hodnota spočíva v upozornení, ktoré sa spustí v deň, keď sa rozširujúca karta začne ohrievať, dva dni predtým, ako karta dosiahne XID 79, keď je ešte čas na opätovné pripojenie kábla namiesto RMA GPU. Táto jediná udalosť zaplatí za celé monitorovacie úsilie a zaplatí sa to mnohonásobne.

---

Toto je súčasť Kentino Wiki, referenčnej série o umelej inteligencii, robotike a systémoch, ktoré ich spájajú. Pripomienky a opravy sú vítané na adrese info@kentino.com.